[Bitcoin-development] Bitcoin address TTL & key expiration?

[Bitcoin-development] Bitcoin address TTL & key expiration?

[Jeff Garzik]

Proxying another's idea, from CoinSummit.

The request:   It would be useful to limit the lifetime of a bitcoin
address.  Intentionally prevent (somehow) bitcoins being sent to a
pubkey/pkh after the key expires.

You could append "don't ["permit"|confirm] after X [time|block]"  to
the address I suppose.  The metadata would not be digitally signed,
but it would be hash-sealed.  As "address" is a client-side notion,
wallet clients would be the ones enforcing such a rule.

Bitcoin protocol of course knows about keys, and key expiration is a
well known and useful concept in public key cryptography.  The best
insertion point in the protocol for key expiration is an open
question, if it's even a good idea at that level at all.  Some flag
"no more TxOuts exactly like this [after X block?]"?

I readily admit I don't have good answers, but it does seem valuable IMO to
* Prevent users from accidentally sending to an "expired" TxOut/pkh.
This happens in the field.
* Discourage address reuse
* Enable sites that generate lots of keys to rotate ancient keys off
their core systems.  (HD wallets mitigate this)

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

Re: [Bitcoin-development] Bitcoin address TTL & key expiration?

[Wladimir]

On Tue, Jul 15, 2014 at 10:00 AM, Jeff Garzik <jgarzik@bitpay.com> wrote:
> Proxying another's idea, from CoinSummit.
>
> The request:   It would be useful to limit the lifetime of a bitcoin
> address.  Intentionally prevent (somehow) bitcoins being sent to a
> pubkey/pkh after the key expires.

Payment request expiration was meant to address this.

Adding an optional expiration timestamp to addresses would be
possible, however, it would be a non-backward-compatible change and
lots of software would have to be changed at this point.

In my opinion encouraging the use of the payment protocol and
deprecating the use of addresses is the best way forward, and not just
for this reason.

Wladimir

Re: [Bitcoin-development] Bitcoin address TTL & key expiration?

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 2630 bytes --]

On Tue, Jul 15, 2014 at 04:00:41AM -0400, Jeff Garzik wrote:
> Proxying another's idea, from CoinSummit.
> 
> The request:   It would be useful to limit the lifetime of a bitcoin
> address.  Intentionally prevent (somehow) bitcoins being sent to a
> pubkey/pkh after the key expires.
> 
> You could append "don't ["permit"|confirm] after X [time|block]"  to
> the address I suppose.  The metadata would not be digitally signed,
> but it would be hash-sealed.  As "address" is a client-side notion,
> wallet clients would be the ones enforcing such a rule.

Note that "digitally signed" has no value here without some kind of
PKI/WoT/something else to know what key is doing the signing. I believe
Jeff is really referring to the checksum by "hash-sealed" here, which is
as good as is worth getting.

> Bitcoin protocol of course knows about keys, and key expiration is a
> well known and useful concept in public key cryptography.  The best
> insertion point in the protocol for key expiration is an open
> question, if it's even a good idea at that level at all.  Some flag
> "no more TxOuts exactly like this [after X block?]"?
> 
> I readily admit I don't have good answers, but it does seem valuable IMO to
> * Prevent users from accidentally sending to an "expired" TxOut/pkh.
> This happens in the field.
> * Discourage address reuse
> * Enable sites that generate lots of keys to rotate ancient keys off
> their core systems.  (HD wallets mitigate this)

A few months ago I looked into what low-level details it'd take to add
Bitcoin addresses to OpenPGP keys a few months ago; one of the
requirements we came up with was to make sure the standard OpenPGP
expiration machinery would still work. Basically in that model the
Bitcoin address - most likely a stealth address for privacy - is added
to the key as signed data. All signatures in OpenPGP have optional
expiration times, and additionally they can be revoked after the fact if
needed as well.

Of course, such ideas aren't limited to OpenPGP - all payment protocols
should consider adopting them.


As for protocol level hacks, keep in mind that anything that makes a
transaction invalid because of the presence of a specific scriptPubKey
in a txout has the potential to make a whole chain of transactions
become invalid during a reorg. Adding such protection in the form of
IsStandard() policy would be ok, but as a protocol rule it'd be pretty
dangerous. IMO much better to just solve the problem at the UI level.

-- 
'peter'[:-1]@petertodd.org
000000000000000032d9d8942fe9461cce9db22a6cd86eacb5c18b415ebb649d

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

Re: [Bitcoin-development] Bitcoin address TTL & key expiration?

[Jeff Garzik]

On Tue, Jul 15, 2014 at 4:19 AM, Wladimir <laanwj@gmail.com> wrote:
> In my opinion encouraging the use of the payment protocol and
> deprecating the use of addresses is the best way forward, and not just
> for this reason.

There are major gaps that the payment protocol doesn't cover.

There are several deployed use cases where you are provided/request an
address, an API provides one, and one or more incoming payments arrive
as the user sends them over minutes/hours/days/weeks.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

Re: [Bitcoin-development] Bitcoin address TTL & key expiration?

[Jeremy Spilman]

Payment Protocol would probably be the communication format for any new  
meta-data.

What's the likelihood of something like this every making it on the  
blockchain?

Re: [Bitcoin-development] Bitcoin address TTL & key expiration?

[Wladimir]

On Tue, Jul 15, 2014 at 10:23 AM, Jeff Garzik <jgarzik@bitpay.com> wrote:
> On Tue, Jul 15, 2014 at 4:19 AM, Wladimir <laanwj@gmail.com> wrote:
> There are major gaps that the payment protocol doesn't cover.
>
> There are several deployed use cases where you are provided/request an
> address, an API provides one, and one or more incoming payments arrive
> as the user sends them over minutes/hours/days/weeks.

Couldn't these services return a payment message instead of an address?

I agree that there is currently an UI issue here: there is no way in
current wallets to store a payment message and pay to it later. We
will need something like that for recurring payments as well.

Bitcoin addresses were never designed with extensibility in mind.
Before the payment protocol there have been lots of ideas to add
functionality to them, but the underlying idea that they have to be
handled by users manually means that they have to be as short as
possible, which is a conflicting aim with extensibility...

Wladimir

Re: [Bitcoin-development] Bitcoin address TTL & key expiration?

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 503 bytes --]

>
> The request:   It would be useful to limit the lifetime of a bitcoin
> address.


Not only useful but essential! Otherwise mobile clients can run out of RAM
and have to cycle around and reuse addresses.

Which is indeed why BIP70 has this feature. It was thought about quite some
time ago. Addresses are an evolutionary dead end, they will never do
everything we need them to do. If there's somewhere that's using addresses,
that's somewhere we will eventually need to upgrade to use BIP70 instead.

[-- Attachment #2: Type: text/html, Size: 797 bytes --]

Re: [Bitcoin-development] Bitcoin address TTL & key expiration?

[Jeff Garzik]

BIP70 does not work well for unknown number of future payments of
unknown, unpredictable value.


On Tue, Jul 15, 2014 at 6:25 AM, Mike Hearn <mike@plan99.net> wrote:
>> The request:   It would be useful to limit the lifetime of a bitcoin
>> address.
>
>
> Not only useful but essential! Otherwise mobile clients can run out of RAM
> and have to cycle around and reuse addresses.
>
> Which is indeed why BIP70 has this feature. It was thought about quite some
> time ago. Addresses are an evolutionary dead end, they will never do
> everything we need them to do. If there's somewhere that's using addresses,
> that's somewhere we will eventually need to upgrade to use BIP70 instead.
>
>



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

Re: [Bitcoin-development] Bitcoin address TTL & key expiration?

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 499 bytes --]

On Tue, Jul 15, 2014 at 4:02 PM, Jeff Garzik <jgarzik@bitpay.com> wrote:

> BIP70 does not work well for unknown number of future payments of
> unknown, unpredictable value.


You can specify zero as an output value, in which case it's the same as "no
value specified". You can then just reuse the PaymentRequest until it
expires. So I think it provides the same functionality already.

Now sure, you'll get address reuse in this scenario, but that's no worse
than with an extended textual address.

[-- Attachment #2: Type: text/html, Size: 861 bytes --]

Re: [Bitcoin-development] Bitcoin address TTL & key expiration?

[Luke Dashjr]

On Tuesday, July 15, 2014 8:00:41 AM Jeff Garzik wrote:
> Proxying another's idea, from CoinSummit.
> 
> The request:   It would be useful to limit the lifetime of a bitcoin
> address.  Intentionally prevent (somehow) bitcoins being sent to a
> pubkey/pkh after the key expires.
> 
> You could append "don't ["permit"|confirm] after X [time|block]"  to
> the address I suppose.  The metadata would not be digitally signed,
> but it would be hash-sealed.  As "address" is a client-side notion,
> wallet clients would be the ones enforcing such a rule.

I agree this would be useful for the "permit" case, but not the "confirm" case 
- it's important that transactions valid in block X also be equally valid in 
block X+1 to avoid reorg issues.

> Bitcoin protocol of course knows about keys, and key expiration is a
> well known and useful concept in public key cryptography.  The best
> insertion point in the protocol for key expiration is an open
> question, if it's even a good idea at that level at all.  Some flag
> "no more TxOuts exactly like this [after X block?]"?

This would force every wallet to keep an index of all TXOs ever.

> I readily admit I don't have good answers, but it does seem valuable IMO to
> * Prevent users from accidentally sending to an "expired" TxOut/pkh.
> This happens in the field.
> * Discourage address reuse

Actually, I think this may make address reuse easier, as with base58 adding 
data will make it impossible to tell at a glance when someone is reusing a key 
with just a different expiration... I suppose something other than base58 
*could* be used to resolve this, however.

> * Enable sites that generate lots of keys to rotate ancient keys off
> their core systems.  (HD wallets mitigate this)

They can already do this. It's perfectly valid for wallets/services to ignore 
(and not consider as payment) transactions using an address more than once. 
There might be race attacks if this is implemented in an immediate fashon 
(attacker transaction gets mined first to kill a payment), but should be 
pretty safe after a few blocks.

Luke

Re: [Bitcoin-development] Bitcoin address TTL & key expiration?

[Jeff Garzik]

On Tue, Jul 15, 2014 at 10:48 AM, Luke Dashjr <luke@dashjr.org> wrote:
> They can already do this. It's perfectly valid for wallets/services to ignore
> (and not consider as payment) transactions using an address more than once.
> There might be race attacks if this is implemented in an immediate fashon
> (attacker transaction gets mined first to kill a payment), but should be
> pretty safe after a few blocks.

Sure it's valid.  However, few users will appreciate "you ignored my
deposit" as a feature.

Payment protocol just doesn't well the use cases of,
* an on-going payment stream from, e.g. Eligius to coinbase
* deposit addresses and deposit situations

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

Re: [Bitcoin-development] Bitcoin address TTL & key expiration?

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1060 bytes --]

>
> Payment protocol just doesn't well the use cases of,
> * an on-going payment stream from, e.g. Eligius to coinbase
> * deposit addresses and deposit situations


This seems to be the key point of disagreement here. Wladimir and I think
it satisfies your requirement just fine. You disagree. Let's get to the
bottom of that.

A PaymentRequest with a zero valued pay-to-address output and an expiration
time, base58 encoded, would look very much like your extended address form.
I don't suggest anyone actually represents PaymentRequest's using base58
but it helps to see the conceptual analogue. There'd be a bit more stuff in
there like some varint and wiretype codes but we're talking a handful of
bytes. Functionally, it'd be identical.

Places like protocols or APIs that require a piece of text and cannot
handle a piece of binary data could be retrofitted into the new world by
accepting base58 encoded PaymentRequest's. This would be kind of silly
because it's fundamentally binary data, but we already do this so it's at
least consistently silly :)

[-- Attachment #2: Type: text/html, Size: 1380 bytes --]

Re: [Bitcoin-development] Bitcoin address TTL & key expiration?

[Jeff Garzik]

This is a well known problem of BIP 70 from day one, because BIP 70
functions at too-low a level.

What needs to be negotiated between parties is a _payment
relationship_ that exchanges HD wallet data. This is what is necessary
to establish and maintain an ongoing payment relationship.

BIP 70 is focused on singular payments with specific outputs and
values.  BIP 70 wants to transmit an actual transaction.  That does
not fit the use cases described.

Adding in a hack that makes zero-valued outputs behave different does
not change the granularity at which BIP 70 operates.

This is a key reason why I have not just ACK'd the BIP 70 subscription
stuff.  Subscriptions are another example of a longer term payment
relationship.  For such case, you want to exchange HD wallet payment
details.  You do not send or receive outputs.  You might not send
transactions directly to the party (coming instead asynchronously &
unpredictably via blockchain).

BIP 70 marries the _relationship_ with payment transmittal, and the
subscription extension does not change that.

Our "contract" language must get a bit smarter, and include HD wallet
payment details, not necessarily focus on outputs.


On Tue, Jul 15, 2014 at 11:18 AM, Mike Hearn <mike@plan99.net> wrote:
>> Payment protocol just doesn't well the use cases of,
>> * an on-going payment stream from, e.g. Eligius to coinbase
>> * deposit addresses and deposit situations
>
>
> This seems to be the key point of disagreement here. Wladimir and I think it
> satisfies your requirement just fine. You disagree. Let's get to the bottom
> of that.
>
> A PaymentRequest with a zero valued pay-to-address output and an expiration
> time, base58 encoded, would look very much like your extended address form.
> I don't suggest anyone actually represents PaymentRequest's using base58 but
> it helps to see the conceptual analogue. There'd be a bit more stuff in
> there like some varint and wiretype codes but we're talking a handful of
> bytes. Functionally, it'd be identical.
>
> Places like protocols or APIs that require a piece of text and cannot handle
> a piece of binary data could be retrofitted into the new world by accepting
> base58 encoded PaymentRequest's. This would be kind of silly because it's
> fundamentally binary data, but we already do this so it's at least
> consistently silly :)



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

Re: [Bitcoin-development] Bitcoin address TTL & key expiration?

[Luke Dashjr]

On Tuesday, July 15, 2014 3:11:25 PM Jeff Garzik wrote:
> On Tue, Jul 15, 2014 at 10:48 AM, Luke Dashjr <luke@dashjr.org> wrote:
> > They can already do this. It's perfectly valid for wallets/services to
> > ignore (and not consider as payment) transactions using an address more
> > than once. There might be race attacks if this is implemented in an
> > immediate fashon (attacker transaction gets mined first to kill a
> > payment), but should be pretty safe after a few blocks.
> 
> Sure it's valid.  However, few users will appreciate "you ignored my
> deposit" as a feature.
> 
> Payment protocol just doesn't well the use cases of,
> * an on-going payment stream from, e.g. Eligius to coinbase

https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Serialization_format

> * deposit addresses and deposit situations

There's no reason deposits cannot use a unique payment request or address 
every time...

Re: [Bitcoin-development] Bitcoin address TTL & key expiration?

[Jeff Garzik]

On Tue, Jul 15, 2014 at 11:41 AM, Luke Dashjr <luke@dashjr.org> wrote:
> There's no reason deposits cannot use a unique payment request or address
> every time...

Actually, and this is key, there _are_ reasons why deposits might not
be able to use PaymentRequests.  Payments happen even when
wallets/computers are offline.

If you have negotiated HD wallet details, you can use a new address
every time, as mentioned.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

Re: [Bitcoin-development] Bitcoin address TTL & key expiration?

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 887 bytes --]

>
> Actually, and this is key, there _are_ reasons why deposits might not
> be able to use PaymentRequests.  Payments happen even when
> wallets/computers are offline.
>

I don't understand this point. It's the *sender* that is parsing the
PaymentRequest and following the instructions. By definition the sender
must be online. A computer that is switched off cannot sign a transaction
at all.


> If you have negotiated HD wallet details, you can use a new address
> every time, as mentioned.


Yes, and an extension to BIP 70 to allow for this (or stealth addresses or
whatever) has been discussed several times.

This thread started by proposing (I think) an expiry time for addresses.
BIP70 satisfies this use case, I think we all agree on that. Now for cases
where someone can't use BIP70 for whatever reason, or it's suboptimal,
absolutely we should design extensions to fix that.

[-- Attachment #2: Type: text/html, Size: 1336 bytes --]