Bitcoin address TTL & key expiration?

Bitcoin address TTL & key expiration?
2014-07-15  8:19 ` Wladimir
                   ` (3 more replies)
  
From: Jeff Garzik @ 2014-07-15  8:00 UTC (permalink / raw)
  To: Bitcoin Dev

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/



 permalink raw reply	[|nested]
2014-07-15  8:19 ` 
                   ` 
  
From: Jeff Garzik @ 2014-07-15  8:00 UTC (permalink / raw)
  To: Bitcoin Dev

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/



 permalink raw reply	[|nested]
* 
  2014-07-15  8:00 [Bitcoin-development] Bitcoin address TTL & key expiration? Jeff Garzik

  2014-07-15  8:23   ` Jeff Garzik
  2014-07-15  8:20 ` 
                   ` 
  3 siblings, 1 reply; 16+ messages in thread
From: Wladimir @ 2014-07-15  8:19 UTC (permalink / raw)
  To: Jeff Garzik;  Bitcoin Dev

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



^ permalink raw reply	[|nested] 16+ messages in thread
2014-07-15  8:19 ` Wladimir

  2014-07-15  8:31     ` Jeremy Spilman
  2014-07-15  8:48     ` Wladimir
  
From: Jeff Garzik @ 2014-07-15  8:23 UTC (permalink / raw)
  To: Wladimir;  Bitcoin Dev

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/



 permalink raw reply	[|nested]
2014-07-15  8:23   ` Jeff Garzik

  2014-07-15  8:48     ` Wladimir
  
From: Jeremy Spilman @ 2014-07-15  8:31 UTC (permalink / raw)
  To: bitcoin-development

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?




 permalink raw reply	[|nested]
2014-07-15  8:23   ` Jeff Garzik
  2014-07-15  8:31     ` Jeremy Spilman

  
From: Wladimir @ 2014-07-15  8:48 UTC (permalink / raw)
  To: Jeff Garzik;  Bitcoin Dev

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



 permalink raw reply	[|nested]
2014-07-15  8:00 [Bitcoin-development] Bitcoin address TTL & key expiration? Jeff Garzik
  2014-07-15  8:19 ` Wladimir
  2014-07-15  8:20 ` Peter Todd

  2014-07-15 14:02   ` Jeff Garzik
  2014-07-15 14:48 ` Luke Dashjr
  
From: Mike Hearn @ 2014-07-15 10:25 UTC (permalink / raw)
  To: Jeff Garzik;  Bitcoin Dev

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

 permalink raw reply	[|nested]
2014-07-15 10:25 ` Mike Hearn

  2014-07-15 14:27     ` Mike Hearn
  
From: Jeff Garzik @ 2014-07-15 14:02 UTC (permalink / raw)
  To: Mike Hearn;  Bitcoin Dev

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/



 permalink raw reply	[|nested]
2014-07-15 14:02   ` Jeff Garzik

  
From: Mike Hearn @ 2014-07-15 14:27 UTC (permalink / raw)
  To: Jeff Garzik;  Bitcoin Dev

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

 permalink raw reply	[|nested]
2014-07-15  8:00 [Bitcoin-development] Bitcoin address TTL & key expiration? Jeff Garzik
                   ` (2 preceding siblings ...)
  2014-07-15 10:25 ` Mike Hearn

  2014-07-15 15:11   ` Jeff Garzik
  
From: Luke Dashjr @ 2014-07-15 14:48 UTC (permalink / raw)
  To: bitcoin-development

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



 permalink raw reply	[|nested]
2014-07-15 14:48 ` Luke Dashjr

  2014-07-15 15:18     ` Mike Hearn
  2014-07-15 15:41     ` Luke Dashjr
  
From: Jeff Garzik @ 2014-07-15 15:11 UTC (permalink / raw)
  To: Luke Dashjr, Mike Hearn;  Bitcoin Dev

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/



 permalink raw reply	[|nested]
2014-07-15 15:11   ` Jeff Garzik

  2014-07-15 15:35       ` Jeff Garzik
  2014-07-15 15:41     ` Luke Dashjr
  
From: Mike Hearn @ 2014-07-15 15:18 UTC (permalink / raw)
  To: Jeff Garzik;  Bitcoin Dev

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

 permalink raw reply	[|nested]
2014-07-15 15:18     ` Mike Hearn

  
From: Jeff Garzik @ 2014-07-15 15:35 UTC (permalink / raw)
  To: Mike Hearn;  Bitcoin Dev, Stephane Brossier, Pierre-Alexandre Meyer

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/



 permalink raw reply	[|nested]
2014-07-15 15:11   ` Jeff Garzik
  2014-07-15 15:18     ` Mike Hearn

  2014-07-15 15:55       ` Jeff Garzik
  
From: Luke Dashjr @ 2014-07-15 15:41 UTC (permalink / raw)
  To: Jeff Garzik;  Bitcoin Dev

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



 permalink raw reply	[|nested]
2014-07-15 15:41     ` Luke Dashjr

  2014-07-15 16:26         ` Mike Hearn
  
From: Jeff Garzik @ 2014-07-15 15:55 UTC (permalink / raw)
  To: Luke Dashjr;  Bitcoin Dev

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/



 permalink raw reply	[|nested]
2014-07-15 15:55       ` Jeff Garzik

  
From: Mike Hearn @ 2014-07-15 16:26 UTC (permalink / raw)
  To: Jeff Garzik;  Bitcoin Dev

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

 permalink raw reply	[|nested]