Re: [Bitcoin-development] Fwd: Reusable payment codes
Payment codes establish the identity of the payer and allow for simpler methods for identifying the payee, and automatically provide the payee with the information they need to send a refund. If merchants and customers were using payment codes, they would not need the BIP70 equivalents. I think the best way to explain payment codes is that they add the missing from address to transactions which users want, but we've had to tell them they can't have. A payment code behaves much more like an email address than a traditional Bitcoin address. On Sun, Apr 26, 2015 at 2:58 PM, Mike Hearn m...@plan99.net wrote: Could you maybe write a short bit of text comparing this approach to extending BIP70 and combining it with a simple Subspace style store-and-forward network? -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: Reusable payment codes
Could you maybe write a short bit of text comparing this approach to extending BIP70 and combining it with a simple Subspace style store-and-forward network? -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Fwd: Reusable payment codes
On Fri, Apr 24, 2015 at 10:58 PM, Gregory Maxwell gmaxw...@gmail.com wrote: So this requires making dust payments to a constantly reused address in order to (ab)use the blockchain as a messaging layer. Indeed, this is more SPV compatible; but it seems likely to me that _in practice_ it would almost completely undermine the privacy the idea hoped to provide; because you'd have an observable linkage to a highly reused address. I agree that the output associated with notification transactions would require special handling to avoid privacy leaks. At a minimum they'd require mixing or being donated to miners as a transaction fee. It would also more than double the data sent for the application where 'stealth addresses' are most important: one-time anonymous donations (in other contexts; you have two way communication between the participants, and so you can just given them a one off address without singling in the public network.) Communication is only one way, except for the case in which the recipient wants to send a refund. Assuming no refund and only a single anonymous donation in the lifetime of the sender's identity, payment codes would require 65 bytes vs 40 bytes for stealth addresses. As soon as the sender sends more than one donation to the same recipient, payment codes show an space advantage over stealth addresses. This kind of binding was intentionally designed out of the stealth address proposal; I think this scheme can be made to work without any increase in size by reusing the payment code as the ephemeral public key (or actually being substantially smaller e.g. use the shared secret as the chain code, but I should give it more thought) With 97 byte standard OP_RETURN values the ephemeral public key could be appended to the chain code, but that's undesirable for other reasons. This is fundamentally more expensive to compute; please don't specify uncompressed. Taking the SHA512 of something less than 512 bits seemed wrong. This appears incompatible with multisignature; which is unfortunate. I agree. I could not find a straightforward way to express a multisignature payment code in less than 80 bytes. I'm disappointed that there isn't any thought given to solving the scanning privacy without forcing non-private pure-overhead messaging transactions on heavily reused addresses. Are you aware of the IBE approach that allows someone to request a third party scan for them with block by block control over their delegation of scanning? I suspect this is a case where we just can't have all the features we want. In this proposal I optimized for non-reliance on third party services and a guaranteed ability to recover spendable funds from a seed backup. Gaining those two features resulted in some tradeoffs as you noted, but I think there are enough benefits to make them worthwhile. In particular, payment codes could be the basis for a Heartbleed-free payment protocol that can positively identify customers and automatically provide refund capabilities in a merchant-customer relationship. A merchant only requires one payment code which they can safely use for all their customers, meaning they only ever need to associate 65 bytes with their identity to allow customers to make sure they are paying the right entity. Exchanges could restrict bitcoin withdrawals to a single payment code known to be associated with their identified customer. This would make thefts easier (without involving address reuse as in locking withdrawals to a single P2PKH address). In some jurisdictions the ability to prove that withdrawals are sent to a positively-identified party, rather than arbitrary third parties, might move some Bitcoin businesses out of money transmitter territory into less onerous regulatory situations. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Fwd: Reusable payment codes
I have pushed an updated version of the proposal which incorporates some of the received feedback and adds a note about the consequences of sharing a payment code-enabled walled on multiple devices: https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki https://github.com/justusranvier/rfc/commit/8c4d3429012eb15847c4ae68f212c8b2dcd1b521 On Sat, Apr 25, 2015 at 12:21 AM, Justus Ranvier justus.ranv...@monetas.net wrote: On Fri, Apr 24, 2015 at 10:58 PM, Gregory Maxwell gmaxw...@gmail.com wrote: So this requires making dust payments to a constantly reused address in order to (ab)use the blockchain as a messaging layer. Indeed, this is more SPV compatible; but it seems likely to me that _in practice_ it would almost completely undermine the privacy the idea hoped to provide; because you'd have an observable linkage to a highly reused address. I agree that the output associated with notification transactions would require special handling to avoid privacy leaks. At a minimum they'd require mixing or being donated to miners as a transaction fee. It would also more than double the data sent for the application where 'stealth addresses' are most important: one-time anonymous donations (in other contexts; you have two way communication between the participants, and so you can just given them a one off address without singling in the public network.) Communication is only one way, except for the case in which the recipient wants to send a refund. Assuming no refund and only a single anonymous donation in the lifetime of the sender's identity, payment codes would require 65 bytes vs 40 bytes for stealth addresses. As soon as the sender sends more than one donation to the same recipient, payment codes show an space advantage over stealth addresses. This kind of binding was intentionally designed out of the stealth address proposal; I think this scheme can be made to work without any increase in size by reusing the payment code as the ephemeral public key (or actually being substantially smaller e.g. use the shared secret as the chain code, but I should give it more thought) With 97 byte standard OP_RETURN values the ephemeral public key could be appended to the chain code, but that's undesirable for other reasons. This is fundamentally more expensive to compute; please don't specify uncompressed. Taking the SHA512 of something less than 512 bits seemed wrong. This appears incompatible with multisignature; which is unfortunate. I agree. I could not find a straightforward way to express a multisignature payment code in less than 80 bytes. I'm disappointed that there isn't any thought given to solving the scanning privacy without forcing non-private pure-overhead messaging transactions on heavily reused addresses. Are you aware of the IBE approach that allows someone to request a third party scan for them with block by block control over their delegation of scanning? I suspect this is a case where we just can't have all the features we want. In this proposal I optimized for non-reliance on third party services and a guaranteed ability to recover spendable funds from a seed backup. Gaining those two features resulted in some tradeoffs as you noted, but I think there are enough benefits to make them worthwhile. In particular, payment codes could be the basis for a Heartbleed-free payment protocol that can positively identify customers and automatically provide refund capabilities in a merchant-customer relationship. A merchant only requires one payment code which they can safely use for all their customers, meaning they only ever need to associate 65 bytes with their identity to allow customers to make sure they are paying the right entity. Exchanges could restrict bitcoin withdrawals to a single payment code known to be associated with their identified customer. This would make thefts easier (without involving address reuse as in locking withdrawals to a single P2PKH address). In some jurisdictions the ability to prove that withdrawals are sent to a positively-identified party, rather than arbitrary third parties, might move some Bitcoin businesses out of money transmitter territory into less onerous regulatory situations. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: Reusable payment codes
On Sat, Apr 25, 2015 at 3:30 AM, Gregory Maxwell gmaxw...@gmail.com wrote: On Sat, Apr 25, 2015 at 12:22 AM, Justus Ranvier justus.ranv...@monetas.net wrote: Taking the hash of the secret would then require an extra step to make sure the hash is valid for secp256k1. The x value may not be a valid member of the group, effectively the same as with a hash. Its also very unequally distributed, as only about half the possible values are points on the curve. ack With 97 byte standard OP_RETURN values the ephemeral public key could be appended to the chain code, but that's undesirable for other reasons. Can you elaborate? Storing a ~33 byte (deterministically generated) ephemeral key should be all that is required. Everything else, including the chain code could be derived from it. What reason do you have to include additional data? The goal of the notification transaction is to send the same payment code to every recipient, but obscure the identity of the sender of the notification transaction from third party blockchain observers. The shared secret is used for that purpose, and the sender's public key used for ECDH can't be one derived from the payment code since the recipient doesn't yet know the payment code. The notification transaction needs to communicate the 65 byte payment code along with one ephemeral public key used for ECDH. If that ephemeral key is not located in a signature script, it has to be somewhere else (such as in the same OP_RETURN output as the payment code.) Taking the SHA512 of something less than 512 bits seemed wrong. Why should it? Adding the Y does not increase the entropy at all. As an aside, I think this can be reformulated to only need 256 bits of output, and then the need for yet-another-hash-function could be avoided in some cases. Already fixed in https://github.com/justusranvier/rfc/commit/8c4d3429012eb15847c4ae68f212c8b2dcd1b521 but it would be good to get confirmation of whether the way I fixed it is valid. In this proposal I optimized for non-reliance on third party services The requirement for inputs is a guaranteed dependency on third party services; so if thats whats being optimized for here it must go (well, I think it must go for the reason of avoiding blocking users from using other schemes to control their coins too..). I'm not sure what you mean by the requirement for inputs is a guaranteed dependency on third party services At the proposal currently stands, an SPV wallet will have no trouble sending or receiving notification transactions without access to a third party service. The recipient just needs to see the transactions associated with its notification address. The point about restricting the types of scripts used as inputs is valid, but I think workarounds are available. If nothing else, the sender can make a suitable input using it's own (suitably mixed) coins first. I agree. I could not find a straightforward way to express a multisignature payment code in less than 80 bytes. A prior stealth address proposal here handled them fine with only a single ephemeral point in the op_return. It does result in a longer address (is that what you're referring to with '80 bytes'?) I considered defining an additional path level for deterministic m-of-n multisig and adding a few bytes to the payment code to express those parameters, but thought it would be too limiting since it would preclude multisig with truly independent keys. It is a thing that could be done, however. Exchanges could restrict bitcoin withdrawals to a single payment code known to be associated with their identified customer. In some jurisdictions the ability to prove that withdrawals are sent to a positively-identified party, rather than arbitrary third parties, might move some Bitcoin businesses out of money transmitter territory into less onerous regulatory situations. But this mandates horrible key management practices, reliance on a single hardcoded private key which you cannot change; even if it might be compromised or lost to the wind. It's less horrible than sticking to a single address because it doesn't wedge privacy, I agree; but care should be taken that a tortured dance for confused regulatory cargo-cult reasons doesn't mandate people not engage in sound practices like periodic key rotation. :) Cold storage is still available (if admittedly less convenient than in traditional wallets). I would expect exchanges in practice to allow for payment codes to be changed, just with non-trivial waiting periods and plenty of human overview. It would be an infrequent event compared to the frequency of withdrawals. Various schemes which use public key authentication instead of passwords for web site authentication could be used to continually verify that the user hasn't lost access to the key. -- One dashboard for servers and applications across
