- From: Dave Lampton <dave.lampton@gmail.com>
- Date: Wed, 4 Jun 2014 04:16:07 -0700
- To: Joseph Potvin <jpotvin@opman.ca>
- Cc: Web Payments CG <public-webpayments@w3.org>
- Message-ID: <CAHbN0ex64iat-Ky=NQ4EK2gMFwbjEqGAbMQt7KYAdETYaNWndA@mail.gmail.com>
Short answer: long enough to remember the oldest transaction. More generally, it will depend on a few things. How many wallets are working together at any given time? To what degree should those servers be partitioned (sharded)? The whole of distributed data will contain at least two copies of the record for each & every piece of digital currency in circulation. In real-time it only takes two servers to confirm a prior transaction. Any invalidated ownership record can and should be purged from the databases as soon as is prudent. Depending on how many wallets exist and how many transactions occur daily the amount of data could be significant in which case something like Kafka may be better suited. Transactions need to be broadcast, but in theory, they don't really have to be heard immediately and the system will continue to operate. Kafka can do this well handling terabytes of data if necessary. 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 Wed, Jun 4, 2014 at 3:58 AM, Joseph Potvin <jpotvin@opman.ca> wrote: > During the period of the payment, surely. > > And then... what's the expected persistence of the information in a > digital wallet? > > Joseph > > > On Wed, Jun 4, 2014 at 6:47 AM, Dave Lampton <dave.lampton@gmail.com> > wrote: > >> Intentionally NOT keeping track of any accumulated "quantified >> entitlements & obligations" over time. >> >> >> 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 Wed, Jun 4, 2014 at 3:45 AM, Joseph Potvin <jpotvin@opman.ca> wrote: >> >>> Dave, Define "simple". >>> >>> Joseph >>> >>> >>> >>> >>> On Wed, Jun 4, 2014 at 6:34 AM, Dave Lampton <dave.lampton@gmail.com> >>> wrote: >>> >>>> Thanks Joseph, lots of good stuff to read. >>>> >>>> In the case of my little proof of concepts system... I just want to >>>> keep things literally as simple as possible so I'm ignoring the concept of >>>> "quantified entitlements & obligations", and only dealing with the >>>> real-time transfer of already possessed "digital cash" between any two >>>> parties that have control of compliant "wallets"/"accounts". >>>> >>>> >>>> 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 Wed, Jun 4, 2014 at 2:45 AM, Joseph Potvin <jpotvin@opman.ca> wrote: >>>> >>>>> 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> >>>>> >>>> >>>> >>> >>> >>> -- >>> 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 >
Received on Wednesday, 4 June 2014 11:16:37 UTC