- From: Joseph Potvin <jpotvin@opman.ca>
- Date: Wed, 4 Jun 2014 05:45:21 -0400
- To: Web Payments CG <public-webpayments@w3.org>
- Message-ID: <CAKcXiSpMW8G4dFiDfNgFubXT5bDPuLW8T1z5qZ2xNNjfRiT1MQ@mail.gmail.com>
Dave, For further reflection, see work by Geoffrey Ingham, since it matters "what" we're speaking about sending around when discussing a payments system. http://ca.wiley.com/WileyCDA/WileyTitle/productCd-074560997X,subjectCd-EC06.html http://cas.umkc.edu/econ/economics/faculty/wray/601wray/Ingham_ontology%20of%20Money.pdf http://www.twill.info/the-ontology-of-money/ http://www.palgraveconnect.com/pc/doifinder/10.1057/9781137302953.0007 Sample chapter http://www.palgrave.com/PDFs/9781137302946.pdf (The book was edited by my former thesis supervisor Geoff Harcourt. After the Paris workshop in April I travelled over to Cambridge UK to discuss some of the issues of payment with Ingham. The link I provided in another thread to an UNCITRAL document is well worth reading, to consider the significance of registry-based versus token-based ways of sending around the quantified entitlements and obligations that Ingham speaks of: http://www.uncitral.org/pdf/english/workinggroups/wg_4/wp_119_e.pdf For example, ACH (Automated Clearing House) is registry-based. BTC is token-based. XRP is token-based. I came to the conclusion that the only legitimate "value" of 1 BTC is zero. BTC is merely the message-bearing token, it's not an instantiation of "the value". It's limited supply is meaningless. For this reason I agree with the determination of courts in Finland, China and elsewhere that BTC is a digital commodity, a sort of electronic vehicle to transport information about the quantified entitlements and obligations that Ingham speaks of. A unit of BTC is therefore properly worth no more than the scanned image of a paper cheque. That scanned image is worth zero, and cannot be logically conflated with the value being exchanged. Some consider these matters "too academic". My response is that if what we were talking about was the development of standard specifications for international shipping containers, it would not be "too academic" to determine whether these containers had to be suitable to ship things like fresh tomatoes as well as steel bars. It matters just as much what this "web payments" system is supposed to be shipping around. -- Joseph Potvin Operations Manager | Gestionnaire des opérations The Opman Company | La compagnie Opman jpotvin@opman.ca Mobile: 819-593-5983 On Wed, Jun 4, 2014 at 12:07 AM, Dave Lampton <dave.lampton@gmail.com> wrote: > Hi Tim, the speech was the one Joseph had sent a link to previously: > http://www.richmondfed.org/press_room/speeches/president_jeff_lacker/2011/lacker_speech_20110907.cfm > > I guess I am fundamentally dissatisfied with credits or IOUs. I want a > real currency backed by a central bank that I can give to anyone I want to, > instantly, without a third party - just like I can do with cash today. > > btw, for the record, the idea that nothing is 100% secure... well, that's > the common thought, but when used properly there are some schemes > that actually do guarantee secrecy. A One-Time Pad > <http://en.wikipedia.org/wiki/Vernam_cipher> being an example. > > For the system of "digital money" I am putting together, however, I've > turned things upside down to avoid the burden of keeping everything secret. > I'm developing a simple security system that does NOT rely on encryption to > provide secrecy, but instead uses it identify and report on data that will > be widely shared public information instead. > > > Dave Lampton > * @dave_lampton <https://twitter.com/dave_lampton>* > > * DaveLampton <https://www.facebook.com/DaveLampton> +DaveLampton > <https://www.google.com/+DaveLampton>* > www.linkedin.com/in/davelampton/ > > > > > On Tue, Jun 3, 2014 at 8:28 PM, Tim Holborn <timothy.holborn@gmail.com> > wrote: > >> Hi Dave, >> >> Do you have a Link to the speech you refer to? >> >> (draft, i still have a great deal more to author, before editing… - but >> link: http://webarts.mediaprophet.net/?page_id=39 ) >> >> Personally; i agree that individuals should have their own domain names; >> and that whilst this is not and should not be a mandatory requirement for >> users, the ability to use existing WWW Systems (inc. DNS) with a domain >> provides enormous benefits. Perhaps the barrier is the methodologies in >> which existing CPANEL (or similar) systems work; and within that >> environment, webized [1] Cloud Storage [2] provides some of the underlying >> building blocks needed to create cloud-based user-environments, supporting >> an array of WWW applications… >> >> deiu wrote a paper [3] relating to his work on RWW.io / data.fm and >> related Linked Data [4] projects (of which deiu is involved…). Obviously, >> members encourage others to develop solutions in an array of ways, from >> use-case and standards; to working solutions. I think the main effort >> surrounds attempting to collaborate around the standards needed to support >> interoperability, supporting users through web-standards as best as >> possible. >> >> In your text, you’ve embedded a few economic models around how you >> envisage your service to be commercialised. Classical Web 2 models >> centralise data to a branded domain where CDN’s and related infrastructure >> then need to support user-growth. revenue models in-turn are supported >> often, by systems such as advertising and data-mining. Due to the nature >> of a centralised or funnel styled topology, the bulk of users are then >> served by a centralised management system that can support sophisticated >> internal business units, in-turn supporting commercial engagement with >> vendors supporting functions such as advertising aggregation and >> monitization. >> >> In distributed models - users would have their own accounts and their own >> hosting space. Perhaps some systems are sold / purchased / leased by the >> user on the basis of an economic awareness surrounding the use of >> advertising systems to make the cost to the user, of owning a service - >> cheaper or free. Ideally perhaps, these systems can be as cheap as is >> possible whilst also being highly secure - so that more sensitive data such >> as commercial objects, personal objects of a sensitive nature (medical >> records, financial accounts, etc.) are entirely secure save exceptional >> circumstances where a court-order may require disclosure on a specified >> account, or similar… >> >> anything that is 100% secure - actually doesn’t exist, from thereon its’ >> a slippery slope and i guess the gambit is to get close to that rating, >> without engaging in a conversation with those who believe they can obtain >> it. >> >> Another up-side of distributed applications, is that application >> developers do not need to fund the traffic requirements for growth. This >> in-turn democratises the capacity to build applications, and to >> successfully commercialise them, similar to the old industry of >> distributing open-source software on floppy disks / early internet systems. >> >> >> IMHO, it gets down to a philosophical layer, which i think is best >> described here [5]. If, as a community, we build standards and basic >> systems that support the needs of a person (natural legal entity); then the >> rest benefits, including our ability as persons to develop applications >> that we believe have a role to play in life, in some practical sense. It >> seems sensible to consider that Web2 portals will develop technologies to >> adapt their service to improve functionality, and support web3 >> capabilities. meanwhile new applications will develop using web3 >> functionality, requiring some form of cloud-storage that may or may not be >> hosted by a person on their own domain… >> >> I’m not sure how many people in future will store all their digital >> transaction receipts in Facebook, or on a google, iCloud or similar service >> - but i’m sure they’d all hope for millions… Equally, i believe >> individuals may benefit from the transparency and ease of understanding the >> data-privacy related risks incumbent upon the alternative of storing all of >> your personal data, on your own hosting system, connected to your own >> domain, using your own run-time of software solutions that incorporate a >> ‘data space’ as something that is owned by you legally, as it is connected >> to that specified domain of which you are responsible for its operations; >> or something along those lines… >> >> underlying that of course; is the need for security with regard to >> fiduciary responsibilities. AML, KYC are amongst the terms used in this >> space. I would argue that if a user has an institutionally approved Cloud >> Storage service (as described, in-part, by the references in this doc); >> then so long as a transaction is between two known entities; facilitated in >> a manner that maintains integrity between WWW Points of distribution >> (meaning, from one person to another person, without being intercepted, >> copied, redirected, etc.) then in-turn institutional systems should be able >> to honour those ‘IOU’s’. >> >> Whilst some may argue that users storing their own data is insecure; i’m >> aware of local police departments in countries other than the USA having >> difficulty accessing data from portals owned, operated & incorporated in >> the USA for good purpose. Perhaps two imaginary examples could be 1. like >> kids, publishing or promoting their suicide intentions, being ‘missing’ >> from loved ones at the time or 2. person gets into car accident and the >> emergency department has difficulty obtaining health data / records from >> the individuals mobile-phone application package provider, who delivers the >> application freely with advertising... >> >> I’ve started putting together documentation for my mid-year update; i >> know a bunch of typo’s, issues exist - am still working on it..); >> nonetheless, >> >> hopefully useful... >> >> What are WebCredits - http://webarts.mediaprophet.net/?page_id=39 >> GraphDB Technology vs. relational Databases - >> http://webarts.mediaprophet.net/?page_id=52 >> Socio-economics and the evolution of relational database technology - >> http://webarts.mediaprophet.net/?p=63 >> Don’t be afraid of ‘peer to peer’ - http://webarts.mediaprophet.net/?p=61 >> (any suggestions on my works, always welcome ;) ) >> >> [1] http://www.w3.org/DesignIssues/Webize.html >> [2] http://www.w3.org/DesignIssues/CloudStorage.html >> [3] http://myprofile-project.org/thesis/manuscript_en.pdf >> [4] http://github.com/linkeddata/ >> [5] http://www.w3.org/2007/09/map/main.jpg >> On 4 Jun 2014, at 1:54 am, Dave Lampton <dave.lampton@gmail.com> wrote: >> >> Not sure exactly what to make of the Lacker speech. He's still talking >> present day technologies with middle-men and discussing the perceived >> usefulness of trying to minimize transaction times to reduce float. I'm >> talking about negating the float altogether by allowing individuals to >> trade real digital currency, just like we can trade real physical currency >> without a middle man today. >> >> My concepts are akin to a peer-to-peer payment system with real-time >> clearing from the central bank of that currency. Similar to the Web Credits >> idea, having a "wallet" (or an "account" or a "generic money bag" etc.) at >> a particular URI is part of my thinking as well, however I have the >> software endpoints much more concretely defined to a standard. In my >> imagined system we'd actually be trading REAL dollars (or yen or francs or >> whatever that central bank issues) and the central bank clears transactions >> on its own currency in real time. Every digital dollar will always have a >> single "physical" home (an obfuscated URI) at any one time. Payers initiate >> transactions. Cost would be on the order of $10 to run a server like this >> for a whole year. There would be almost no cost to anyone who maintains >> their own currency server (just electricity and an Internet connection). >> The cost of maintaining a single server would be comparable to having an >> email server, to the point that it's likely people would be giving away >> these accounts as part of a loss-leader to upsell to some other service >> perhaps. >> >> Anyway, I know, I'm still just the new guy here... :) >> so I say it all with some humility... >> ...but I feel like I have yet to see a proposed system that does >> everything mine does. I guess I should try to find time to finish a working >> demo of it. I'm about a third of the way there already. >> >> Cheers. >> >> >> >> Dave Lampton >> * @dave_lampton <https://twitter.com/dave_lampton>* >> >> * DaveLampton <https://www.facebook.com/DaveLampton> +DaveLampton >> <https://www.google.com/+DaveLampton>* >> www.linkedin.com/in/davelampton/ >> >> >> >> >> On Tue, Jun 3, 2014 at 8:21 AM, Timothy Holborn < >> timothy.holborn@gmail.com> wrote: >> >>> Re: dave's post below... >>> >>> Webcredits is an alternative that seems to provide a functionally >>> similar capability (although, using rww systems), with an array of other >>> functional capabilities. >>> >>> See #webcredits in freenode, or >>> http://www.w3.org/community/webpayments/wiki/Web_Credits >>> >>> If you get a rww.io or data.fm account, and put a Testnet address into >>> your foaf document, I think melvster (in #webcredits, per above) has a bot >>> running that can provide some basic demonstrations. >>> >>> His also a walking library of knowledge in that area specifically.... >>> >>> Mind. Accelerating, and diminishing costs for transfers is one thing. >>> I figure once a transaction hits a financial bank to be converted into >>> traditional currency, it'll likely have requirements surrounding >>> identifying where the funds are sourced, etc. >>> >>> Much like existing payee relationships, once one payment has been made >>> between two accounts, additional transactions are easier. >>> >>> This is perhaps different for digital currencies, or IOU's / >>> accountability capabilities, and other purposes of stuff like block-chains, >>> and things that can be done with that geek... >>> >>> I don't think gold needed an identity, beyond being tested to ensure it >>> was gold. The ID has always lived with the accounts systems. Perhaps also >>> ensuring people don't taint the "gold" with a cheaper substitute, or >>> otherwise breach the terms of trade. More complex examples could be >>> asserting a value for use of an image, beyond the scope of a Creative >>> Commons license, perhaps all embedded in the image... The semantic >>> clipboard http://dig.csail.mit.edu/2009/Clipboard/ seems to consider >>> the Creative Commons elements quite well... >>> >>> Webcredits is well worth a look IMO... I'm really impressed with it, >>> understanding of course, it's still early days... >>> >>> Timh. >>> >>> Sent from my iPad >>> >>> On 4 Jun 2014, at 1:00 am, Joseph Potvin <jpotvin@opman.ca> wrote: >>> >>> Dave, >>> >>> Take a look at "Immediate Funds Transfer: A Central Bank Perspective" >>> from the Federal Reserve Bank of Richmond >>> >>> http://www.richmondfed.org/press_room/speeches/president_jeff_lacker/2011/lacker_speech_20110907.cfm >>> >>> http://www.chicagofed.org/webpages/publications/economic_perspectives/2011/summers_wells.cfm >>> >>> -- >>> Joseph Potvin >>> Operations Manager | Gestionnaire des opérations >>> The Opman Company | La compagnie Opman >>> jpotvin@opman.ca >>> Mobile: 819-593-5983 >>> >>> >>> On Tue, Jun 3, 2014 at 10:50 AM, Dave Lampton <dave.lampton@gmail.com> >>> wrote: >>> >>>> Since its inception, PayPal has primarily made their money "on the >>>> float" meaning that during those few days they have your money, they are >>>> able to invest it in short-term money markets, etc. When you're dealing >>>> with such a large number of transactions, these investments can be very >>>> large and the returns quite handsome. >>>> >>>> I'm new to this group, but I have joined because I've been developing >>>> my own solutions for "digital money" and wanted to see what else is going >>>> on. So far, I am gathering that both the current WebPayments (PaySwarm) >>>> platform as well as other proposed alternatives like OpenTransact are still >>>> all based on email for the sending/receiving of payments, is that right? >>>> >>>> There is STILL no way for me to send $5 directly to my brother, for >>>> example. There is still always going to be at least one third party >>>> involved, and often more than one, just for me to give my brother five >>>> bucks. Or have I missed something? >>>> >>>> ... >>>> >>>> Has anyone discussed the development of something entirely new like a >>>> protocol especially used for nothing but financial transactions? My feeling >>>> is that email servers don't know what a payment is and never will be able >>>> to do anything with one. End users are still dependent on a third-party to >>>> move money to/from their bank accounts. >>>> >>>> On the other hand, I have a much more complete system for digital money >>>> developed in my mind if anyone is interested. If our money were held by our >>>> own digital accounts, we could send money to one another just like we can >>>> already hand one another cash without any third-party involvement. (it >>>> would even put into question the need for banks!) A super brief overview >>>> follows: >>>> >>>> First off, this idea would actually require governments/central banks >>>> to issue the digital currency that could subsequently only live in my >>>> proposed digital accounts. Yes, I realize that's a huge hurdle to expect >>>> their involvement at any stage, but frankly, I think it is the only real >>>> way to solve the larger problems permanently. >>>> >>>> So, what if every financial account in the world were assigned a >>>> permanent URL (either a domain or subdomain that is owned by the account >>>> holder). Every website already requires a domain, so it's not a big leap to >>>> require every digital account to also have a domain or subdomain (and with >>>> the advent of IPv6 we'll have so many IP addresses at our disposal, it's >>>> absurd). Ownership of digital accounts and the transfer of their ownership >>>> would all be handled using the same mechanisms we use today to manage >>>> domains using registrars and DNS. In this case, every digital dollar must >>>> have a home in a digital account somewhere. Each digital dollar knows its >>>> issuing bank, its unique serial number, its current owner (holding account) >>>> and >>>> >>>> Essentially, a digital account would be a new type of Internet >>>> endpoint, one that is similar to the function of an email server, but only >>>> processes financial transactions. It would be addressed in much the same >>>> way that email servers have an MX record in DNS, the currency servers might >>>> have a CX record. In my mind, the easiest way to implement something like >>>> this would be with a Node.js server using secure WebSockets (wss://) and a >>>> simple NoSQL document store, most likely a MongoDB instance. The software >>>> itself could be so simple as to be mindless, not even needing >>>> configuration, knowing only how to either send or receive currency, nothing >>>> more. >>>> >>>> Lastly, my ideas to keep it all secure turn the traditional >>>> cryptographic methods upside-down. Rather than make every financial >>>> transaction in the world a big freakin' secret, I would instead make every >>>> transaction completely public and recorded by a whole lot of people at >>>> once. It would be impossible to fake because only the central banks will >>>> transmit transaction confirmations, but everyone will be keeping copies of >>>> them as they happen on their network segments, and records can be looked up >>>> by anyone at any time. However, to be fair to everyone, money must have no >>>> memory, and so only the current owner is known for a given piece of >>>> currency, previous owners are purged from the records when a new >>>> transaction is confirmed. >>>> >>>> There are lots more details to all of this if anyone is interested. >>>> >>>> Not sure if perhaps you're all more interested in forwarding the >>>> established ideas, but I wanted to throw this out there since I still do >>>> not yet see any proposals which would allow me to send that $5 directly to >>>> my brother!! :) >>>> >>>> thanks. >>>> >>>> >>>> Dave Lampton >>>> * @dave_lampton <https://twitter.com/dave_lampton>* >>>> >>>> * DaveLampton <https://www.facebook.com/DaveLampton> +DaveLampton >>>> <https://www.google.com/+DaveLampton>* >>>> www.linkedin.com/in/davelampton/ >>>> >>>> >>>> >>>> >>>> On Tue, Jun 3, 2014 at 4:40 AM, Joseph Potvin <jpotvin@opman.ca> wrote: >>>> >>>>> I don't recall seeing anything specific yet about basic timeliness of >>>>> web payments. >>>>> >>>>> Here's an example. In the course of having some funds reimbursed to me >>>>> by a business via PayPal, I then transferred the money from my PayPal >>>>> account to my bank account. Once that transaction was processed via >>>>> the PayPal site, I recieved the following emaIl message: >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: service@intl.paypal.com <service@intl.paypal.com> >>>>> Date: Tue, Jun 3, 2014 at 7:03 AM >>>>> Subject: We're transferring money to your bank >>>>> To: Joseph Potvin <jpotvin@opman.ca> >>>>> >>>>> We're transferring money from PayPal to your bank >>>>> Jun 3, 2014 07:03:36 GMT-04:00 >>>>> Hello Joseph Potvin, >>>>> You asked us to transfer $XXX.XX CAD from PayPal to your bank account, >>>>> and we're processing it now. It usually takes 3-5 business days for >>>>> transfers like this to go through, so you should see the money in your >>>>> bank account by Jun 10, 2014. >>>>> ----------------------------------------------- >>>>> >>>>> Huh? 3-5 business days? But the ACH system clears at least every >>>>> day. >>>>> >>>>> Does anyone here know in which organization's hands the money sits for >>>>> 3-5 days? And why? >>>>> >>>>> Is this a delay due to some slow anti-launderiing verification >>>>> processes mandated by government? >>>>> >>>>> Alternatively I can imagine there's a cloth bag tied with sisal >>>>> containing my $XXX.XX CAD being loaded onto a side-bag of a donkey, >>>>> getting ready to make the trek in this direction. I'm fine with that. >>>>> Just need to know though. >>>>> >>>>> -- >>>>> Joseph Potvin >>>>> Operations Manager | Gestionnaire des opérations >>>>> The Opman Company | La compagnie Opman >>>>> jpotvin@opman.ca >>>>> Mobile: 819-593-5983 >>>>> >>>>> >>>> >>> >>> >>> >>> >>> >>> >>> -- >>> Joseph Potvin >>> Operations Manager | Gestionnaire des opérations >>> The Opman Company | La compagnie Opman >>> jpotvin@opman.ca >>> Mobile: 819-593-5983 >>> >>> >> >> > <819-593-5983>
Received on Wednesday, 4 June 2014 09:46:13 UTC