FAQ on the payment protocol

[Peter Todd]

It just sounds too complicated. Raised level of complexity normally will have unforeseeable consequence if something went wrong. Maybe this feature could be modularized and called from the official protocol

What, my pie in the sky ideas or something else? Note that the stuff about tx replacement, on the merchant side, actually just assumes merchants have the simplest possible implementation and implement it correctly. Basically a merchant wanting to accept a payment needs to do the following:

for tx in payment.transactions:
    node.broadcast(tx)

and in their "have I been paid yet logic":

def IsOrderPaid(order, min_confirmations=6):
    requested_output_scriptPubKey = order.payment_request.output_scriptPubKey
    requested_output_value = order.payment_request.value
    if requested_output_scriptPubKey in wallet_outputs:
        for outputs in wallet_outputs[requested_output_scriptPubKey]:
            if outputs.value >= requested_output_value:
                return True
    return False

Thing is, if you're implementation doesn't look like this you will occasionally see payments get stuck due to things like transaction mutability. All you should care about is that an output you can spend with greater or equal the requested amount exists in the UTXO set with a sufficient number of confirmations. That's it. Testing for anything more complex than that just gives more opportunities for something to fail because you got paid in a way you didn't expect too.

[1714832229]

1714832229

[1714832229]

1714832229

[1714832229]

1714832229

[1714832229]

1714832229

[1714832229]

1714832229

[1714832229]

1714832229

[super3]

Thanks! This is the best explanation so far!

[johnyj]

Cut-thru payments

A future version of the payment protocol can allow the receiver to give the sender a BIP32 seed, and a total amount requested value. The receiver then considers the payment satisfied once outputs with addresses derived from that seed exist in the blockchain with a total value >= the total amount requested.

This means a merchant with debts to someone else, like their employees or suppliers, can get PaymentRequests from whomever they are in debt to and in effect have their customers pay those debts directly.

If those suppliers in turn have debts to other parties the process can repeat again. This time the supplier to the merchant just gives the merchant a list of addresses to pay, addresses that happen to belong to whomever the supplier owes a debt too. (maybe their employees?) Now two steps in the whole payment process have been skipped, and the customers of the merchant could very well be actually paying into wallets owned by employees of the merchant's suppliers!

In the business world 'Net 30 days' accounts are very commonly used, so this kind of arrangement could actually be quite practical and useful. Everyone in between saves on transactions fees, there would be a lot less demand for blockchain space, and privacy is improved for everyone.

Of course, it'd be a bit surprising if you went to pay a bill on Thursday night and the moment you paid it your wallet told you your employer had paid the exact same amount as part of your upcoming Friday paycheck...

I don't understand how come the debt creep into the picture? Bitcoin is a payment system, but it seems these are some accounting function, more like a clearing house. But shouldn't the settlement be handled off-chain by some bitcoin clearing house, and all the merchants have business relationship in one area connect to this clearing house instead?

I'm concerned about the block size limit   There are so many accounting software out there, maybe no need to re-invent the wheel

[Peter Todd]

Cut-thru payments

A future version of the payment protocol can allow the receiver to give the sender a BIP32 seed, and a total amount requested value. The receiver then considers the payment satisfied once outputs with addresses derived from that seed exist in the blockchain with a total value >= the total amount requested.

This means a merchant with debts to someone else, like their employees or suppliers, can get PaymentRequests from whomever they are in debt to and in effect have their customers pay those debts directly.

If those suppliers in turn have debts to other parties the process can repeat again. This time the supplier to the merchant just gives the merchant a list of addresses to pay, addresses that happen to belong to whomever the supplier owes a debt too. (maybe their employees?) Now two steps in the whole payment process have been skipped, and the customers of the merchant could very well be actually paying into wallets owned by employees of the merchant's suppliers!

In the business world 'Net 30 days' accounts are very commonly used, so this kind of arrangement could actually be quite practical and useful. Everyone in between saves on transactions fees, there would be a lot less demand for blockchain space, and privacy is improved for everyone.

Of course, it'd be a bit surprising if you went to pay a bill on Thursday night and the moment you paid it your wallet told you your employer had paid the exact same amount as part of your upcoming Friday paycheck...

I don't understand how come the debt creep into the picture? Bitcoin is a payment system, but it seems these are some accounting function, more like a clearing house. But shouldn't the settlement be handled off-chain by some bitcoin clearing house, and all the merchants have business relationship in one area connect to this clearing house instead?

Debt crept into the picture because the parties in it agreed too. Note how what I'm describing is much more organic than any centralized clearing house: it's just showing how what businesses do routinely - extend 30 day credit relationships to each other - can turn into a way for them to organically, indeed, accidentally, create something akin to the Ripple network with the help of suitable accounting/wallet software. Note how that as long as everyone involved has some mechanism to tell a third party "pay me these amounts at these addresses to settle our debt", and accounting/wallet software keeping track of the payments as they happen, the result can be a cut-thru payment system. The parties don't have to use the same software, or for that matter the "official Payment Protocol", and in fact in theory everyone involved could be doing it all manually.

I'm concerned about the block size limit  

Yes you should be. Notice how all of the above would have never happened if transactions are free or nearly free - why bother? Instead every step would be just done with individual transactions; certainly easier but the cost is a centralized system with bandwidth and storage requirements that only a select few miners can keep up with, and importantly, afford to audit fully. Or in the words of core developer Jeff Garzik:

(g.2) Competition for space encourages efficient solutions, whereas a too-loose block size policy incentivizes the opposite: dumping into the block chain
[...]
    And very importantly, (i) it is a mistake to increase block size simply because people are too lazy to implement layers on top of bitcoin.  Bitcoin will forever be a zen balance of applications and layers that sit on top of the blockchain, and those that directly use the blockchain itself as their comm/functional layer (c.f. SatoshiDICE).

-http://garzikrants.blogspot.ca/2013/02/bitcoin-block-size-thoughts.html

Mike's post on the consequences of centralized mining is interesting too: Freezing BitCoin addresses by regulating miners

[bittop100]

Thank you for sharing !

[johnyj]

Debt crept into the picture because the parties in it agreed too. Note how what I'm describing is much more organic than any centralized clearing house: it's just showing how what businesses do routinely - extend 30 day credit relationships to each other - can turn into a way for them to organically, indeed, accidentally, create something akin to the Ripple network with the help of suitable accounting/wallet software. Note how that as long as everyone involved has some mechanism to tell a third party "pay me these amounts at these addresses to settle our debt", and accounting/wallet software keeping track of the payments as they happen, the result can be a cut-thru payment system. The parties don't have to use the same software, or for that matter the "official Payment Protocol", and in fact in theory everyone involved could be doing it all manually.

Due to the deflative and unregulated nature of bitcoin, I doubt anyone are going to have a debt in bitcoin (you might need to work 200% more to payback that debt in a month )

[davout]

The PKI is still horribly broken, if I read the FAQ correctly (correct me if I don't) it means that currently anyone compromising a CA (as in any of them) can easily MITM and steal your money.

[apetersson]

The PKI is still horribly broken, if I read the FAQ correctly (correct me if I don't) it means that currently anyone compromising a CA (as in any of them) can easily MITM and steal your money.

maybe it is time to start up a new PKI cartel, specifically for bitcoin applications. bitcoin wallet apps could ship their own version of the root certs.

[Mike Hearn]

They could impersonate an entity you genuinely want to pay and redirect the payment, yes. Fixing that is the point of certificate transparency. If a CA issued a certificate in your name that you didn't request, you could see it and report it for revocation.

I think it's stupid to say the PKI is "horribly broken". There aren't any cryptographic systems that do a better job. Andreas' suggestion is the kind of thing that is easy to suggest, but there is no reason to believe some Bitcoin-specific set of CA's would somehow be more secure or harder to compromise than the existing set. These problems are just fundamentally hard.

[Deafboy]

For big online merchants, the customers could sign the shop's public key in process of payment and easily create the trust line.
Or even better, they could sign it after the order arrive. As a form of review - I like the shop, they're fast, cheap and reliable therefore I'm going to sign their key with my key so all my friends who trust me can see this shop is legit.

All it takes is one dialog box showed to user after X blocks after the payment: "I see you paid for this order from company XY. Do you like it? |Yes| |No|"

Is there any flaw in my proposal?

edit: btw. thanks for the FAQ, Mike!

[giszmo]

Mike thank you for the explanation.

Unfortunately I don't have time to dig deep enough to answer this for myself:
How does this relate to micro transaciton channels. You know I see micro transaction channels as the next big thing to solve

• instant payment
• micro payment
• privacy
• transaction fees
• blockchain size growth

between arbitrary parties via a small set of facilitators (micro transaction gateways or whatever you want to call them).

As a merchant will I be able to send a payment request "update the micro transaction channel xy to grant me 0.5BTC more" or how would that work? Especially if the transaction is a three-hop channel one. A – A's gateway – B's gateway – B.

[Peter Todd]

For big online merchants, the customers could sign the shop's public key in process of payment and easily create the trust line.
Or even better, they could sign it after the order arrive. As a form of review - I like the shop, they're fast, cheap and reliable therefore I'm going to sign their key with my key so all my friends who trust me can see this shop is legit.

All it takes is one dialog box showed to user after X blocks after the payment: "I see you paid for this order from company XY. Do you like it? |Yes| |No|"

Is there any flaw in my proposal?

What happens if I the attacker substitute the shop's address for my own, and then use those funds to pay the shop? You've just used your reputation to sign my key rather than the legit merchant's key, and you didn't even know it.

Bonus points: how does this scenario relate to The Silkroad when it comes to PGP communications with your anonymous vendor?

[Peter Todd]

Mike thank you for the explanation.

Unfortunately I don't have time to dig deep enough to answer this for myself:
How does this relate to micro transaciton channels. You know I see micro transaction channels as the next big thing to solve

• instant payment
• micro payment
• privacy
• transaction fees
• blockchain size growth

between arbitrary parties via a small set of facilitators (micro transaction gateways or whatever you want to call them).

As a merchant will I be able to send a payment request "update the micro transaction channel xy to grant me 0.5BTC more" or how would that work? Especially if the transaction is a three-hop channel one. A – A's gateway – B's gateway – B.

Jeremy Spilman/Mike Hearn style micro-transaction channels are just a mechanism to send funds from one person to another in such a way that the amount being transferred can be increased (renegotiated) gradually over time in a secure fashion. They're a clever mechanism, but with a very niche application; frankly I'd be very surprised to see them get all that much use. User's are never going to like or really understand why setting up a micro-payment channel has all this complex stuff about locking funds and what not, compared to just clicking the "Pay with your inputs.io/easywallet/whatever account!" button; only if those services are consistently shutdown by government forces will alternatives be attractive, and if they can't find at least one friendly country to operate from we've got serious problems...

Remember that micro-transaction channels can-not enable individual micro-transactions between arbitrary parties, and there are no facilitators involved.

Off-chain transactions is what you're thinking of, and mechanisms to use them haven't been standardized in any way - it's premature to talk about the payment protocol in relation to them because the payment protocol is only really useful in conjunction with multi-signature wallets. (when your PC and phone co-operate to authorize a transaction) The other features of the payment protocol are kinda nice, like refund addresses and messages, but they're incidental.

No off-chain tx system - like inputs.io - has plans yet to do true multi-factor authorization of payments AFAIK so the payment protocol doesn't yet add any value.

[Realpra]

It just sounds too complicated. Raised level of complexity normally will have unforeseeable consequence if something went wrong. Maybe this feature could be modularized and called from the official protocol

I agree this proposal is honestly not that good:

Sure sign addresses and sure have signed receipts - brilliant - but keep it away from the blockhain.

http://www.zdnet.com/has-the-nsa-broken-ssl-tls-aes-7000020312/

We don't need arcane CAs from the 90's, Bitcoin works BETTER.


The example given with the paycheck is really weak and doesn't even BEGIN to justify this: Just send your own money around a bit, say you paid using an online wallet or use coin-mixing TOR and the whole shebang.

With Bitcoin it is SOO easy to hide.

EDIT:
And when buying: If the buyer doesn't send, give him a bad review and crush his business.

[Mike Hearn]

For big online merchants, the customers could sign the shop's public key in process of payment and easily create the trust line.

It doesn't work like that. You don't know any of the other customers, most likely, so being presented with 100 signatures that are claimed to be 100 random people doesn't help. What if they are all fake?

So then you say, OK, customers can sign other customers! We'll make a web of trust!

Well, see the last question in the FAQ for why that sort of scheme eventually turns into the regular PKI.

I'll say it again - these are fundamentally difficult problems. If you think you've found a magic quick fix, then you are saying you found something lots of very bright cryptographers didn't. Probably you're wrong.

[Mike Hearn]

Mike thank you for the explanation.

Unfortunately I don't have time to dig deep enough to answer this for myself:
How does this relate to micro transaciton channels. You know I see micro transaction channels as the next big thing to solve

Currently they are unrelated. You could at some point extend the payment protocol to be a starting point for the micropayment channels protocol, and that way you'd get the benefits of the authentication, but it isn't supported today.

Doing a network of payment channels is rather complicated. I'm still beating the bugs out of the existing micropayments code and working on an example app and other important APIs for it. So we didn't even nail down the "A pays B" case yet.

That said I'm actually very close to having a nice, easy to use GUI for micropayment based file downloads/servers.  I think it will be the first truly end-user oriented contracts based app, which will be a great milestone. There are some bugs and some other things that need fixing, but I'm almost done. Perhaps if I can work at the same time as listening to the talks I'll even get it finished by the end of the Amsterdam conference. If you're here you could see it

I'm not sure paid-for file downloads are really that big a deal, but the code is really simple so I'm hoping that someone will think it's cool and run with it, like by adding file upload capability, a simple P2P discovery network and so on. A few more features like that and we have the very beginnings of Gregory Maxwells StorJ vision. More importantly I want to turn it into a tutorial app, so everyone can see how we went from a protocol writeup on a wiki page to an actual working, reasonably attractive and professional looking GUI app usable (and programmable!) by mere mortals.

Once people see how we did it and that it's not really so hard, my dream is that we'll see real growth in slick, usable contract-based pure P2P applications. But Peter might be right - perhaps it won't work out like that. Only one way to find out! Up up and away! :-)

[johnyj]

The example given with the paycheck is really weak and doesn't even BEGIN to justify this: Just send your own money around a bit, say you paid using an online wallet or use coin-mixing TOR and the whole shebang.

I also think that salary example is not that convincing

You will never get your salary paid in bitcoin if its price continuously rise, your boss will not be so stupid to pay you a deflative currency, he will pay you fiat money as long as he can get them, unless fiat money disappear from the world, bitcoin will not be used for purchasing at large scale. Employers will mortgage the bitcoin and get fiat loans to pay their employee  

And I just did two polls, it seems most of the people's action is save the coin instead of spend it, or only spend a very small part of it in a much later time, and this ensured bitcoin's exchange rate will rise forever
https://bitcointalk.org/index.php?topic=295753.0

Anyway, I can see the purpose of this payment protocol is to extend the functionality in payment. But people might just ignore it like before, using that 34 character address makes people feel much more secure so that they might accept the inconvenience comes with that. And it is so cool   A web address? The first reaction is a phishing site

[WikileaksDude]

this should be a sticky thread, no doubt.

Thanks for this FAQ Mike!

[Maged]

The example given with the paycheck is really weak and doesn't even BEGIN to justify this: Just send your own money around a bit, say you paid using an online wallet or use coin-mixing TOR and the whole shebang.

I also think that salary example is not that convincing

You will never get your salary paid in bitcoin if its price continuously rise, your boss will not be so stupid to pay you a deflative currency, he will pay you fiat money as long as he can get them, unless fiat money disappear from the world, bitcoin will not be used for purchasing at large scale. Employers will mortgage the bitcoin and get fiat loans to pay their employee  

And I just did two polls, it seems most of the people's action is save the coin instead of spend it, or only spend a very small part of it in a much later time, and this ensured bitcoin's exchange rate will rise forever
https://bitcointalk.org/index.php?topic=295753.0

Anyway, I can see the purpose of this payment protocol is to extend the functionality in payment. But people might just ignore it like before, using that 34 character address makes people feel much more secure so that they might accept the inconvenience comes with that. And it is so cool   A web address? The first reaction is a phishing site

Damn, it's truly a shame that it's impossible to buy bitcoins with fiat or vice-versa, because then the employer could just convert the paycheck to whatever the employee wants it as at the time of payment, regardless of what the merchant keeps their money as. /sarcasm

If you would like to learn more about deflation and bitcoin, read the many topics linked here:
https://www.google.com/cse?cx=016660200577587308545%3Aesf40ml9aag&ie=UTF-8&q=deflation&sa=Google+search#gsc.tab=0&gsc.q=deflation&gsc.page=1

Further discussion about deflation in this thread will be considered off-topic, so please refrain from replying to this post.

[marcus_of_augustus]

Could it be extensible to SSL certificate fingerprints stored in Namecoin blockchain, instead of X.509 (centralised) option?