* Re: [bitcoin-dev] [Bitcoin-development] Reusable payment codes
@ 2015-10-22 5:53 Luke Dashjr
2015-10-22 14:55 ` Justus Ranvier
0 siblings, 1 reply; 9+ messages in thread
From: Luke Dashjr @ 2015-10-22 5:53 UTC (permalink / raw)
To: Justus Ranvier, Bitcoin Dev
On Friday, April 24, 2015 8:00:46 PM Justus Ranvier wrote:
> This link contains an RFC for a new type of Bitcoin address called a
> "payment code"
Sorry for the late review. I'm concerned with the "notification address"
requirement, which entails address reuse and blockchain spam. Since it entails
address reuse, the recipient is forced to either leave them unspent forever
(bloating the UTXO set), or spend it which potentially compromises the private
key, and (combined with the payment code) possibly as much as the entire
wallet.
Instead, I suggest making it a single zero-value OP_RETURN output with two
pushes: 1) a hash of the recipient's payment code, and 2) the encrypted
payment code. This can be searched with standard bloom filters, or indexed
with whatever other optimised algorithms are desired. At the same time, it
never uses any space in the UTXO set, and never needs to be
spent/mixed/dusted.
Luke
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [bitcoin-dev] [Bitcoin-development] Reusable payment codes 2015-10-22 5:53 [bitcoin-dev] [Bitcoin-development] Reusable payment codes Luke Dashjr @ 2015-10-22 14:55 ` Justus Ranvier 2015-10-22 20:43 ` Luke Dashjr 0 siblings, 1 reply; 9+ messages in thread From: Justus Ranvier @ 2015-10-22 14:55 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1.1: Type: text/plain, Size: 1401 bytes --] On 22/10/15 00:53, Luke Dashjr wrote: > Sorry for the late review. I'm concerned with the "notification address" > requirement, which entails address reuse and blockchain spam. Since it entails > address reuse, the recipient is forced to either leave them unspent forever > (bloating the UTXO set), or spend it which potentially compromises the private > key, and (combined with the payment code) possibly as much as the entire > wallet. > > Instead, I suggest making it a single zero-value OP_RETURN output with two > pushes: 1) a hash of the recipient's payment code, and 2) the encrypted > payment code. This can be searched with standard bloom filters, or indexed > with whatever other optimised algorithms are desired. At the same time, it > never uses any space in the UTXO set, and never needs to be > spent/mixed/dusted. The notification transaction portion is my least-favorite portion of the spec, but I don't see any alternatives that provide an unambiguous improvement, including your suggestion. One of the most highly-weighted goals of this proposal is to be usable on as many mobile/light wallets as possible. I know for sure that all existing platforms for balance querying index by address. Support for bloom filters or other querying methods is less comprehensive, meaning the set of wallets that can support payment codes would be smaller. [-- Attachment #1.2: 0xEAD9E623.asc --] [-- Type: application/pgp-keys, Size: 18729 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] [Bitcoin-development] Reusable payment codes 2015-10-22 14:55 ` Justus Ranvier @ 2015-10-22 20:43 ` Luke Dashjr 2015-10-22 20:58 ` Justus Ranvier 2015-10-22 21:05 ` Kristov Atlas 0 siblings, 2 replies; 9+ messages in thread From: Luke Dashjr @ 2015-10-22 20:43 UTC (permalink / raw) To: Justus Ranvier; +Cc: Bitcoin Dev On Thursday, October 22, 2015 2:55:14 PM Justus Ranvier wrote: > On 22/10/15 00:53, Luke Dashjr wrote: > > Sorry for the late review. I'm concerned with the "notification address" > > requirement, which entails address reuse and blockchain spam. Since it > > entails address reuse, the recipient is forced to either leave them > > unspent forever (bloating the UTXO set), or spend it which potentially > > compromises the private key, and (combined with the payment code) > > possibly as much as the entire wallet. > > > > Instead, I suggest making it a single zero-value OP_RETURN output with > > two pushes: 1) a hash of the recipient's payment code, and 2) the > > encrypted payment code. This can be searched with standard bloom > > filters, or indexed with whatever other optimised algorithms are > > desired. At the same time, it never uses any space in the UTXO set, and > > never needs to be > > spent/mixed/dusted. > > The notification transaction portion is my least-favorite portion of the > spec, but I don't see any alternatives that provide an unambiguous > improvement, including your suggestion. > > One of the most highly-weighted goals of this proposal is to be usable > on as many mobile/light wallets as possible. > > I know for sure that all existing platforms for balance querying index > by address. Support for bloom filters or other querying methods is less > comprehensive, meaning the set of wallets that can support payment codes > would be smaller. No, they just need to improve their software, and only to support receiving with payment codes (not sending to them). BIPs should in general not be designed around current software, especially in this case where there is no benefit to doing so (since it requires software upgrades anyway). Luke ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] [Bitcoin-development] Reusable payment codes 2015-10-22 20:43 ` Luke Dashjr @ 2015-10-22 20:58 ` Justus Ranvier 2015-10-22 21:47 ` Luke Dashjr 2015-10-23 1:22 ` Peter Todd 2015-10-22 21:05 ` Kristov Atlas 1 sibling, 2 replies; 9+ messages in thread From: Justus Ranvier @ 2015-10-22 20:58 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1.1: Type: text/plain, Size: 1098 bytes --] On 22/10/15 15:43, Luke Dashjr wrote: > BIPs should in general not be > designed around current software I strongly disagree with this statement. There is a version byte in the payment code specification for a reason. Version 1 payment codes are designed to be deployable by wallet implementers today, without requiring them to wait on any network-level changes whatsoever, which includes IsStandard() redefinitions, or yet-to-be-invented-and-deployed filtering schemes. As far as I know, multi-push OP_RETURN outputs are not standard transactions and so wallet users can not rely on transactions containing them to be relayed through the network, therefore any improvement to the protocol which requires that feature is not appropriate for version 1. When additional capabilities are deployed in the network such that Bitcoin users can rely on their existence, that would be a great time to specify a version 2 payment code that uses those features and encourage users to upgrade (which should be a fairly smooth process since their actual keys don't need to change). [-- Attachment #1.2: 0xEAD9E623.asc --] [-- Type: application/pgp-keys, Size: 18729 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] [Bitcoin-development] Reusable payment codes 2015-10-22 20:58 ` Justus Ranvier @ 2015-10-22 21:47 ` Luke Dashjr 2015-10-22 22:01 ` Justus Ranvier 2015-10-23 1:22 ` Peter Todd 1 sibling, 1 reply; 9+ messages in thread From: Luke Dashjr @ 2015-10-22 21:47 UTC (permalink / raw) To: Justus Ranvier; +Cc: Bitcoin Dev On Thursday, October 22, 2015 8:58:58 PM Justus Ranvier wrote: > I strongly disagree with this statement. Well, I strongly disagree with adopting the BIP as it stands. > Version 1 payment codes are designed to be deployable by wallet > implementers today, without requiring them to wait on any network-level > changes whatsoever, which includes IsStandard() redefinitions, or > yet-to-be-invented-and-deployed filtering schemes. No, those are not network-level changes. They are mere software changes that can be deployed along with the rest of the proposal. > As far as I know, multi-push OP_RETURN outputs are not standard > transactions and so wallet users can not rely on transactions containing > them to be relayed through the network, therefore any improvement to the > protocol which requires that feature is not appropriate for version 1. "Standard" means defined in a BIP. To date, there are no standard transactions using OP_RETURN period. IsStandard is a node policy that should have no influence on future BIPs. > When additional capabilities are deployed in the network such that > Bitcoin users can rely on their existence, that would be a great time to > specify a version 2 payment code that uses those features and encourage > users to upgrade (which should be a fairly smooth process since their > actual keys don't need to change). Such changes should not be made until there is a standard for them. Luke ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] [Bitcoin-development] Reusable payment codes 2015-10-22 21:47 ` Luke Dashjr @ 2015-10-22 22:01 ` Justus Ranvier 0 siblings, 0 replies; 9+ messages in thread From: Justus Ranvier @ 2015-10-22 22:01 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1.1: Type: text/plain, Size: 1469 bytes --] On 22/10/15 16:47, Luke Dashjr wrote: > Well, I strongly disagree with adopting the BIP as it stands. That's fine. Nobody is required to adopt an informational BIP if they do not wish to do so. > No, those are not network-level changes. They are mere software changes that > can be deployed along with the rest of the proposal. They are "mere software changes" outside the control of the users and wallet developers who may wish to use and implement payment codes, so are indistinguishable from a network-level change. > "Standard" means defined in a BIP. To date, there are no standard > transactions using OP_RETURN period. IsStandard is a node policy that should > have no influence on future BIPs. Since Bitcoin Core 0.11, 80 byte OP_RETURN transactions are standard, so that's what payment codes use: https://github.com/bitcoin/bitcoin/commit/fcf646c Whether or not it "should" have an influence, it is an absolute fact that Bitcoin users are affected by it. A user whose transactions are not relayed or mined doesn't care about the politics surrounding node policy. Designing standards without putting the needs of its intended users first is a great way to see the standard fail. > Such changes should not be made until there is a standard for them. Have you ever heard the term "permissionless innovation" by chance? Particularly in reference to Bitcoin? If you don't like payment codes, then don't use them. [-- Attachment #1.2: 0xEAD9E623.asc --] [-- Type: application/pgp-keys, Size: 18729 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] [Bitcoin-development] Reusable payment codes 2015-10-22 20:58 ` Justus Ranvier 2015-10-22 21:47 ` Luke Dashjr @ 2015-10-23 1:22 ` Peter Todd 2015-10-23 15:57 ` Justus Ranvier 1 sibling, 1 reply; 9+ messages in thread From: Peter Todd @ 2015-10-23 1:22 UTC (permalink / raw) To: Justus Ranvier; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1104 bytes --] On Thu, Oct 22, 2015 at 03:58:58PM -0500, Justus Ranvier via bitcoin-dev wrote: > On 22/10/15 15:43, Luke Dashjr wrote: > > BIPs should in general not be > > designed around current software > > I strongly disagree with this statement. > > There is a version byte in the payment code specification for a reason. > > Version 1 payment codes are designed to be deployable by wallet > implementers today, without requiring them to wait on any network-level > changes whatsoever, which includes IsStandard() redefinitions, or > yet-to-be-invented-and-deployed filtering schemes. > > As far as I know, multi-push OP_RETURN outputs are not standard > transactions and so wallet users can not rely on transactions containing > them to be relayed through the network, therefore any improvement to the > protocol which requires that feature is not appropriate for version 1. FWIW multi-push OP_RETURN outputs will be standard in v0.12.0: https://github.com/bitcoin/bitcoin/pull/6424 -- 'peter'[:-1]@petertodd.org 0000000000000000066dc6b040d8be42153f784df37745b46c4ad667e0788781 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 650 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] [Bitcoin-development] Reusable payment codes 2015-10-23 1:22 ` Peter Todd @ 2015-10-23 15:57 ` Justus Ranvier 0 siblings, 0 replies; 9+ messages in thread From: Justus Ranvier @ 2015-10-23 15:57 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin Dev [-- Attachment #1.1: Type: text/plain, Size: 664 bytes --] On 22/10/15 20:22, Peter Todd wrote: > FWIW multi-push OP_RETURN outputs will be standard in v0.12.0: > > https://github.com/bitcoin/bitcoin/pull/6424 > As I said before, once the prerequisites for a better notification method are usable in the network, I'd love to define a version 2 payment code that uses such an better notification system. In the meantime. every block mined shows very consistent 70% address reuse. Anything that can bring that number down is a good thing. Even if version 1 payment codes could only potentially drop that number from 70% to 30% instead of to 0%, they'd still be worth using while we wait for version 2. [-- Attachment #1.2: 0xEAD9E623.asc --] [-- Type: application/pgp-keys, Size: 18729 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] [Bitcoin-development] Reusable payment codes 2015-10-22 20:43 ` Luke Dashjr 2015-10-22 20:58 ` Justus Ranvier @ 2015-10-22 21:05 ` Kristov Atlas 1 sibling, 0 replies; 9+ messages in thread From: Kristov Atlas @ 2015-10-22 21:05 UTC (permalink / raw) To: Luke Dashjr; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2478 bytes --] The consequence of previous ECDH address proposals "not designing around current software" is a sustained ~70% of transactions reusing addresses, as you saw in my Reddit post recently. If you have a fear that an inferior proposal will gain popularity, you can always propose a superior one. If it's *actually* superior, it will win out. On Thu, Oct 22, 2015 at 4:43 PM, Luke Dashjr via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > On Thursday, October 22, 2015 2:55:14 PM Justus Ranvier wrote: > > On 22/10/15 00:53, Luke Dashjr wrote: > > > Sorry for the late review. I'm concerned with the "notification > address" > > > requirement, which entails address reuse and blockchain spam. Since it > > > entails address reuse, the recipient is forced to either leave them > > > unspent forever (bloating the UTXO set), or spend it which potentially > > > compromises the private key, and (combined with the payment code) > > > possibly as much as the entire wallet. > > > > > > Instead, I suggest making it a single zero-value OP_RETURN output with > > > two pushes: 1) a hash of the recipient's payment code, and 2) the > > > encrypted payment code. This can be searched with standard bloom > > > filters, or indexed with whatever other optimised algorithms are > > > desired. At the same time, it never uses any space in the UTXO set, and > > > never needs to be > > > spent/mixed/dusted. > > > > The notification transaction portion is my least-favorite portion of the > > spec, but I don't see any alternatives that provide an unambiguous > > improvement, including your suggestion. > > > > One of the most highly-weighted goals of this proposal is to be usable > > on as many mobile/light wallets as possible. > > > > I know for sure that all existing platforms for balance querying index > > by address. Support for bloom filters or other querying methods is less > > comprehensive, meaning the set of wallets that can support payment codes > > would be smaller. > > No, they just need to improve their software, and only to support receiving > with payment codes (not sending to them). BIPs should in general not be > designed around current software, especially in this case where there is no > benefit to doing so (since it requires software upgrades anyway). > > Luke > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 3360 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2015-10-23 16:04 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-10-22 5:53 [bitcoin-dev] [Bitcoin-development] Reusable payment codes Luke Dashjr 2015-10-22 14:55 ` Justus Ranvier 2015-10-22 20:43 ` Luke Dashjr 2015-10-22 20:58 ` Justus Ranvier 2015-10-22 21:47 ` Luke Dashjr 2015-10-22 22:01 ` Justus Ranvier 2015-10-23 1:22 ` Peter Todd 2015-10-23 15:57 ` Justus Ranvier 2015-10-22 21:05 ` Kristov Atlas
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox