Topic: FAQ on the payment protocol - page 4. (Read 47080 times)

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.

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.

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?

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.

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!

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.

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.

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.

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 )

Thank you for sharing !

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.


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:

-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

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

Thanks! This is the best explanation so far!

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.

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

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

You can still keep keys offline when using payment requests. It doesn't change anything in that respect.

With regards to increased complexity, yes it's a concern but for now it's only going to be merchants who deal with this (and it's optional of course). In future it'll be used more widely as well, but I think we can come up with simple user interfaces for that.

If a government seizes your domain then having to create unsigned payment requests is really the least of your problems. But at any rate, it means your payment requests wouldn't validate and you'd have to stop signing them (thus making your users less secure).

Merchants accepting multiple conflicting transactions is important for CoinJoin, because not all your inputs might be yours and thus it's possible they could get double-spent. You should give the merchant two transactions in this case, one being the CoinJoin tx spending yours and their inputs to their and the merchants txout, and another spending just your input. (second tx having a slightly lower fee so it's not the preferred one by miners)

Of course this does degrade privacy slightly as the merchant can figure out which inputs were yours, but the blockchain record remains anonymized and the next payment you make will come from inputs whose inputs a step back are anonymized.

Another example is multiple payments in a row: suppose I'm Alice and I first pay Bob, and then Charlie using the payment protocol. When I pay Bob I create and sign a transaction, tx1, and give it to Bob in my Payment message. That transaction has two txouts, one that pays Bob, and the other being my change address.

But when I pay Charlie I should actually create two transactions: the first is being a modified version of tx1 - tx1b - that double-spends tx1, (potentially adding new inputs) and adds Charlie's requested address as an additional txout. The second transaction, tx2, then depends on the change output of tx1 and pays Charlie that way. Normally the merged tx1b will be what confirms, efficiently paying both Bob and Charlie in a single transaction, but if tx1 confirms first Charlie still gets paid with tx2. (the order of transactions in the list given to the merchant in this case is tx1b, tx1, tx2)

Of course, if any of the above actually gets implemented I'll be pleasantly surprised.

Mike,

Please add Coinpunk to the list of clients that intend to support this. Thanks!

I need time to fully digest the implications of this, it's very interesting (and thank you for using protocol buffers here), but I'm initially a little skeptical as to whether this is a good approach. I think depending on central-server hot wallets has been demonstrated to be a dangerous approach to implementation of Bitcoin systems, as evidenced by the theft of millions of USD worth of Bitcoin over the last few years. I do feel like this system could potentially be just as dangerous as addresses, if not more so.

For example, as a merchant I could create a receive address on an offline computer, which is a design where your Bitcoins are very unlikely to be stolen. The trade-off is "privacy" of course, but from my chair, I'm way more concerned with security than I am with privacy. And the way I'm seeing most Bitcoins stolen right now are from server break-ins.

I also have concerns about increasing the complexity of Bitcoin transactions. This definitely increases the education curve, which is probably one of the main reasons why addresses became more popular: they are simple to understand.

It also introduces a non-Bitcoin system as a dependency, which may have far reaching consequences. What if that SSL certificate is revoked, or the government raids and confiscates the domain? If you need the domain to receive a transaction, that is quite a dependency introduced.

Again, very interesting, and I do like the CA approach, but I do have concerns about whether it is an improvement on the address system. It's my hope that there won't be a de-prioritization of the latter for the former.

My apologies in advance if I have not understood something, I have only had a chance to briefly skim over this so far and it's very possible I've misunderstood some of the machinations here and am talking nonsense.

Right, thanks for the correction. In the first deployment wallets will still be treating 1 tx == 1 payment. The ability to request multiple outputs and submit multiple transactions will get activated over time as wallets get smarter.