Re: [Bitcoin-development] Bitcoin address TTL key expiration?
On Tue, Jul 15, 2014 at 10:00 AM, Jeff Garzik jgar...@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 -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin address TTL key expiration?
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 32d9d8942fe9461cce9db22a6cd86eacb5c18b415ebb649d signature.asc Description: Digital signature -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin address TTL key expiration?
On Tue, Jul 15, 2014 at 4:19 AM, Wladimir laa...@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/ -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin address TTL key expiration?
On Tue, Jul 15, 2014 at 10:23 AM, Jeff Garzik jgar...@bitpay.com wrote: On Tue, Jul 15, 2014 at 4:19 AM, Wladimir laa...@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 -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin address TTL key expiration?
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? -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin address TTL key expiration?
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. -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin address TTL key expiration?
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 m...@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/ -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin address TTL key expiration?
On Tue, Jul 15, 2014 at 4:02 PM, Jeff Garzik jgar...@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. -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin address TTL key expiration?
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 -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin address TTL key expiration?
On Tuesday, July 15, 2014 3:11:25 PM Jeff Garzik wrote: On Tue, Jul 15, 2014 at 10:48 AM, Luke Dashjr l...@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... -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin address TTL key expiration?
On Tue, Jul 15, 2014 at 11:41 AM, Luke Dashjr l...@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/ -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin address TTL key expiration?
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. -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
