Re: [bitcoin-dev] [Bitcoin-development] Reusable payment codes

Re: [bitcoin-dev] [Bitcoin-development] Reusable payment codes

[Luke Dashjr]

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

Re: [bitcoin-dev] [Bitcoin-development] Reusable payment codes

[Justus Ranvier]

[-- 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 --]

Re: [bitcoin-dev] [Bitcoin-development] Reusable payment codes

[Luke Dashjr]

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

Re: [bitcoin-dev] [Bitcoin-development] Reusable payment codes

[Justus Ranvier]

[-- 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 --]

Re: [bitcoin-dev] [Bitcoin-development] Reusable payment codes

[Luke Dashjr]

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

Re: [bitcoin-dev] [Bitcoin-development] Reusable payment codes

[Justus Ranvier]

[-- 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 --]

Re: [bitcoin-dev] [Bitcoin-development] Reusable payment codes

[Peter Todd]

[-- 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 --]

Re: [bitcoin-dev] [Bitcoin-development] Reusable payment codes

[Justus Ranvier]

[-- 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 --]

Re: [bitcoin-dev] [Bitcoin-development] Reusable payment codes

[Kristov Atlas]

[-- 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 --]