Re: P2P Payment technologies & info (WAS Re: Is payment "timeliness" addressed in our work yet?)

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 <>*

* DaveLampton <> +DaveLampton

On Wed, Jun 4, 2014 at 2:45 AM, Joseph Potvin <> 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.
> Sample chapter (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:
> 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
> Mobile: 819-593-5983
> On Wed, Jun 4, 2014 at 12:07 AM, Dave Lampton <>
> wrote:
>> Hi Tim, the speech was the one Joseph had sent a link to previously:
>> 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
>> <> 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 <>*
>> * DaveLampton <>  +DaveLampton
>> <>*
>> On Tue, Jun 3, 2014 at 8:28 PM, Tim Holborn <>
>> 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: )
>>> 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 / 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 -
>>> GraphDB Technology vs. relational Databases -
>>> Socio-economics and the evolution of relational database technology -
>>> Don’t be afraid of ‘peer to peer’ -
>>> (any suggestions on my works, always welcome ;) )
>>> [1]
>>> [2]
>>> [3]
>>> [4]
>>> [5]
>>> On 4 Jun 2014, at 1:54 am, Dave Lampton <> 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 <>*
>>> * DaveLampton <>  +DaveLampton
>>> <>*
>>> On Tue, Jun 3, 2014 at 8:21 AM, Timothy Holborn <
>>>> 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
>>>> If you get a or 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 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 <> wrote:
>>>> Dave,
>>>> Take a look at "Immediate Funds Transfer: A Central Bank Perspective"
>>>> from the Federal Reserve Bank of Richmond
>>>> --
>>>> Joseph Potvin
>>>> Operations Manager | Gestionnaire des opérations
>>>> The Opman Company | La compagnie Opman
>>>> Mobile: 819-593-5983
>>>> On Tue, Jun 3, 2014 at 10:50 AM, Dave Lampton <>
>>>> 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 <>*
>>>>> * DaveLampton <>  +DaveLampton
>>>>> <>*
>>>>> On Tue, Jun 3, 2014 at 4:40 AM, Joseph Potvin <>
>>>>> 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: <>
>>>>>> Date: Tue, Jun 3, 2014 at 7:03 AM
>>>>>> Subject: We're transferring money to your bank
>>>>>> To: Joseph Potvin <>
>>>>>> 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
>>>>>> Mobile: 819-593-5983
>>>> --
>>>> Joseph Potvin
>>>> Operations Manager | Gestionnaire des opérations
>>>> The Opman Company | La compagnie Opman
>>>> Mobile: 819-593-5983
> <819-593-5983>

Received on Wednesday, 4 June 2014 10:34:40 UTC