Bitcoin address TTL & key expiration?
16 messages, 15 Jul 2014. Started by Jeff Garzik.
Jeff Garzik (6), Mike Hearn (4), Wladimir J. van der Laan (2), Luke Dashjr (2), Peter Todd, Jeremy Spilman
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)
On Tue, Jul 15, 2014 at 10:00 AM, Jeff Garzik <jgarzik@bitpay•com> wrote:
Quoted text (5 lines)
> 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
On Tue, Jul 15, 2014 at 04:00:41AM -0400, Jeff Garzik wrote:
Quoted text (10 lines)
> 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.
Quoted text (12 lines)
> 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.
On Tue, Jul 15, 2014 at 4:19 AM, Wladimir <laanwj@gmail•com> wrote:
Quoted text (3 lines)
> 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.
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?
On Tue, Jul 15, 2014 at 10:23 AM, Jeff Garzik <jgarzik@bitpay•com> wrote:
Quoted text (6 lines)
> 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
Quoted text (3 lines)
> > 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.
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:
Quoted text (13 lines)
>> 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. > >
On Tue, Jul 15, 2014 at 4:02 PM, Jeff Garzik <jgarzik@bitpay•com> wrote:
Quoted text (2 lines)
> 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.
On Tuesday, July 15, 2014 8:00:41 AM Jeff Garzik wrote:
Quoted text (10 lines)
> 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.
Quoted text (5 lines)
> 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.
Quoted text (4 lines)
> 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.
Quoted text (2 lines)
> * 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
On Tue, Jul 15, 2014 at 10:48 AM, Luke Dashjr <luke@dashjr•org> wrote:
Quoted text (5 lines)
> 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
Quoted text (4 lines)
> > 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 :)
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:
Quoted text (21 lines)
>> 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 :)
On Tuesday, July 15, 2014 3:11:25 PM Jeff Garzik wrote:
Quoted text (12 lines)
> 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
Quoted text (1 line)
> * deposit addresses and deposit situations
There's no reason deposits cannot use a unique payment request or address every time...
On Tue, Jul 15, 2014 at 11:41 AM, Luke Dashjr <luke@dashjr•org> wrote:
Quoted text (2 lines)
> 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.
Quoted text (5 lines)
> > 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.
Quoted text (2 lines)
> 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.