What's the worst case vs. best case vs. avg case performance of the UTXO updating process?

Remember that we can't make it possible for a miner to intentionally make a block whose UTXO set modifications take an especially long amount of time to process to get an edge on the competition.

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?

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

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.

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

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.

Transactions

If you make multiple payments in a row you might wind up not having any confirmed coins to pay the merchant with, which is why the payment protocol lets a Payment message contain more than one transaction. Wallet software will need to determine what unconfirmed transactions are required to complete a given payment, and give the merchant the whole lot. Merchant-side you need to make sure your software considers the payment complete provided the requested txout scriptPubKey:value exists in the blockchain - it's quite possible that the transaction that actually ends up paying you is not the one the customer actually gave you. Note how this also means that every order must use a separate scriptPubKey for that reason.

Adding OpenPGP to the payment protocol

So you want to use the OpenPGP WoT to authenticate payment protocol requests... here's how you do it:

1) Set pki_type in PaymentRequest to 'openpgp'

2) Set signature in PaymentRequest to a detached OpenPGP signature of the serialized_payment_details

3) Set pki_data to an empty string. Why an empty string? Because OpenPGP signatures already specify the key doing the signing; if you don't already have that key there's a good chance the user never verified it anyway.

4) (client-side) Verify the payment request by checking that the signature is valid. If you don't already have the key, you should tell the user the PaymentRequest can't be used because you don't know who signed it; don't let them pay the request unless the key is already imported and GnuPG or whatever trusts it and don't do that for them.

As for implementing this, you can use the GPGME library for C/C++ code (like the reference client) On Python I've used the python-gnupg library with success. Dunno much about Java, but I'm sure you can find something.

But remember that crypto doesn't exist in a vacuum - the payment protocol is mostly useful for multi-factor wallets, where you need to authenticate the same payment request on multiple devices. If you want your hardware wallet to make use of OpenPGP-signed payment protocol requests, it needs to support OpenPGP and you need to securely import your web-of-trust database into it. You're probably going to find that something like the following is far simpler, and almost as likely for users to use securely:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Donations to the Keep Bitcoin Free project are accepted at Peter Todd's
donation address:

1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJRlePvAAoJEH+rEUJn5PoEBeoIAKiqyP+V9mCJXzzLxVY1MzJ6
Lvcx9qRvFVZ/r0F1ph3SwkcCBPvwV7nD0Ca7Dr5eat/SDo0u1i6NdznKcY87zADk
RqhT0JvhNCNSg3uKfqiYlXS6IJNZ4yGSDxJfAaATH9irw0fLHfPXX1rxqp529I9g
bEVi1PBnZx00UHUFAEbVP6uJqjICD8pGwz8K/l2mgGb/1Iw8p3HKxXEogstOILGO
dmX60VzPptm2HwcQ9JLSjgsNv2f6KRZoZwr6eXlbGteNgiXRpV4Lo2V14hBWqXTs
gKDFsZud93Osqj+A3XIr4qj5GtNFqDUXsVbAmmjNGzs4oyzt7YXneGObRsPm4tA=
=EoMU
-----END PGP SIGNATURE-----

How will chain consensus be determined? (what proof-of-foo algorithm will be used and what are the incentives involved?)

Yes, and if you are using something else, then use it - other ways of making Bitcoin transactions aren't going away. (although some poorly-written wallet software and Bitcoin libraries still haven't implemented P2SH addresses, which makes those other ways a bit inconvenient at times)

Meh, you already trust SSL whenever you copy a Bitcoin address off of a SSL-protected website, so the payment protocol is a strict improvement on that situation.

The enemy of better is perfect.

While no guarantee, the entire process by which the DNSSEC root authority was signed was filmed and is publicly available: http://www.youtube.com/watch?v=b9j-sfP9GUU

There's reams of documentation and video publicly available on ICANN's site, although that's still only the root keys, not the registrar keys.

So what % of orphans are you seeing?

The Android wallet already has the ability to use the camera to read QR codes.

FWIW if I think the best design for MasterCoin is to make use of the Bitcoin blockchain that's exactly what I'll recommend MasterCoin do, and I'll explain how to do it in a way that is as difficult as possible for Bitcoin to block. While I am known in the community for my hard-line stance on scalability and decentralization, I don't think we want to kid ourselves - if there are technical means and economic motivations to stuff data into the blockchain we should face that fact and understand the threat now in detail. Fortunately I think those incentives aren't there, or required, but I'd be fooling the Bitcoin community if I didn't consider all the possibilities carefully and in the interests of the MasterCoin community.

You're analysis is correct, although we have two solutions in the works:

1. Discourage fee sniping with nLockTime: If clients always create transactions such that only the next block can include them, it becomes less attractive to re-org blocks because you won't be able to cherry pick high-fee transactions that have been created since the last block. We can implement this right now, although it's relatively weak protection; I mostly wrote the patch because I don't want systems to start making assumptions about nLockTime now that prevent us from implementing that fix in the future.

2. Transaction checkpoints: Every transaction has a individual "checkpoint" block, and if included in a block in a chain that doesn't include that blockhash the block mining the transaction isn't allowed to collect its fee. You can still re-org a block to grab an individual transaction, but all the other transactions will then (probably) not be available to you. This change requires a soft-fork to implement, but is better protection than #1.

Finally a limited blocksize helps too: if transaction fees are roughly equal you eventually run out of space in the block anyway.

IMO the biggest problem with this re-org business isn't the re-orgs themselves, but rather that it gives incentives for mining pools to get bigger because only a large pool can profitably attempt re-orgs. This could be a serious problem if a significant portion of mining income in the future was in the form of fidelity bond fee sacrifices.


Correct.

I've got other paid and unpaid work competing for my time.

Interesting!

Some plastics are specifically designed to change color in aesthetically pleasing ways when hit by a laser for the purpose of cheap custom branding - possibly that's what they did here and Trader Joe's was just selling the part of the production run that hadn't been custom branded.

Posted my "Offer: Mastercoin analysis and transaction specification design" here https://bitcointalk.org/index.php?topic=299679.0