Talk:Hardfork Wishlist - Revision history

Luke-jr: Undo revision 47340 by Bestbitcoincasino (talk)

2014-05-13T22:35:38Z

Undo revision 47340 by Bestbitcoincasino (talk)

← Older revision		Revision as of 22:35, 13 May 2014
Line 52:		Line 52:

	This new categorical directive would not be understood by older nodes/mining software, so they'd reject blocks containing the directive. Even if it could be crafted to be ignored by older nodes... they'd then accept transactions/blocks which spend outputs from the 'dead' key according to old rules, leaving contradictory info in the shared chain. Thus as far as I can tell, to work this feature requires a hard fork. Of course, if there's a way to implement the same benefit in a compatible way, I'd appreciate hearing about it here on the talk page or elsewhere on the wiki. [[User:WargeGeoshington\|WargeGeoshington]] ([[User talk:WargeGeoshington\|talk]]) 10:52, 13 June 2013 (GMT)		This new categorical directive would not be understood by older nodes/mining software, so they'd reject blocks containing the directive. Even if it could be crafted to be ignored by older nodes... they'd then accept transactions/blocks which spend outputs from the 'dead' key according to old rules, leaving contradictory info in the shared chain. Thus as far as I can tell, to work this feature requires a hard fork. Of course, if there's a way to implement the same benefit in a compatible way, I'd appreciate hearing about it here on the talk page or elsewhere on the wiki. [[User:WargeGeoshington\|WargeGeoshington]] ([[User talk:WargeGeoshington\|talk]]) 10:52, 13 June 2013 (GMT)

			* Something like this really makes sense as a higher level of abstraction - part of a merged-mined timestamp block, for example. Clients would just consult this database for forwarding information when sending, and use the output for the new destination instead. It doesn't need to involve miners or other nodes at all. Even if you wanted miners to block sending to the forwarded output, that would be at most a soft-fork (making something formerly legal, now illegal). BUT, since addresses are single-use, I'm not sure it makes sense to do this at the address level at all - and it's effectively "default" in the payment protocol. --[[User:Luke-jr\|Luke-jr]] ([[User talk:Luke-jr\|talk]]) 19:11, 13 June 2013 (GMT)

	:: The idea that it's sender's responsibility to check some database is interesting... but makes senders reliant on having a full copy of this arbitrarily-large database. (It destroys the useful property, "all I need is to know my own inputs", for sending.) And what of old clients/nodes/miners that don't know to check the forwarding-database? They issue bad transactions to dead addresses. They'll mine/forward bad blocks with transactions related to dead-addresses, rejected by newer software. Meanwhile, even if the forwarding notation is squeezed into blocks in a backward-compatible (or by-indirect-reference) fashion, as soon as someone spends an auto-forwarded-by-rule amount, that transaction looks illegal to old nodes, causing old nodes to reject post-forwarding blocks. Pre-feature and post-feature software can't understand each others' blockchains, and grow indepedently if people keep running the old software. Isn't that the very definition of a 'hard fork'? (If not, can you fill me in with a better definition?)		:: The idea that it's sender's responsibility to check some database is interesting... but makes senders reliant on having a full copy of this arbitrarily-large database. (It destroys the useful property, "all I need is to know my own inputs", for sending.) And what of old clients/nodes/miners that don't know to check the forwarding-database? They issue bad transactions to dead addresses. They'll mine/forward bad blocks with transactions related to dead-addresses, rejected by newer software. Meanwhile, even if the forwarding notation is squeezed into blocks in a backward-compatible (or by-indirect-reference) fashion, as soon as someone spends an auto-forwarded-by-rule amount, that transaction looks illegal to old nodes, causing old nodes to reject post-forwarding blocks. Pre-feature and post-feature software can't understand each others' blockchains, and grow indepedently if people keep running the old software. Isn't that the very definition of a 'hard fork'? (If not, can you fill me in with a better definition?)
Line 58:		Line 60:

	:: So, you (and several others I've floated this to) think this is an "interesting idea". Maybe there's a way to do it with a soft fork (though I don't yet see it; it seems any such approach would be fragile or not offer the full benefits). There's a way to get the full benefits if it were in a 'hard fork'. So why shouldn't this idea appear on a page that's a unprioritized "wishlist", about changes that "might be desirable"? By deleting it you prevent evaluation and discussion of its possible value and possible implementations. --[[User:WargeGeoshington\|WargeGeoshington]] ([[User talk:WargeGeoshington\|talk]]) 05:15, 15 June 2013 (GMT)		:: So, you (and several others I've floated this to) think this is an "interesting idea". Maybe there's a way to do it with a soft fork (though I don't yet see it; it seems any such approach would be fragile or not offer the full benefits). There's a way to get the full benefits if it were in a 'hard fork'. So why shouldn't this idea appear on a page that's a unprioritized "wishlist", about changes that "might be desirable"? By deleting it you prevent evaluation and discussion of its possible value and possible implementations. --[[User:WargeGeoshington\|WargeGeoshington]] ([[User talk:WargeGeoshington\|talk]]) 05:15, 15 June 2013 (GMT)

			*** You can break address-compatibility without a hardfork. A soft-fork is sufficient to ban usage of forwarded addresses, as well. As new features such as HD wallets and the payment protocol becomes more widespread, address reuse should quickly decline out of usage anyway, making this a solution begging for a problem in the long-term (and remember, a hardfork is a long-term thing...). --[[User:Luke-jr\|Luke-jr]] ([[User talk:Luke-jr\|talk]]) 02:50, 16 June 2013 (GMT)

	:::: Maybe we're using different definitions of hard vs. soft forks. I see a 'hard fork' as a situation where old software, if it keeps running as nodes/miners, generates transactions and blocks that are not accepted by the post-hard-fork mainline. (A compatibility break that forces upgrades.) Is this definition wrong or imprecise? If not, how would a soft fork prevent someone with non-upgraded software from (a) sending a payment to an obsolete address which is then (b) minted into a block by miners running the old software? [[User:WargeGeoshington\|WargeGeoshington]] ([[User talk:WargeGeoshington\|talk]]) 18:42, 12 August 2013 (GMT)		:::: Maybe we're using different definitions of hard vs. soft forks. I see a 'hard fork' as a situation where old software, if it keeps running as nodes/miners, generates transactions and blocks that are not accepted by the post-hard-fork mainline. (A compatibility break that forces upgrades.) Is this definition wrong or imprecise? If not, how would a soft fork prevent someone with non-upgraded software from (a) sending a payment to an obsolete address which is then (b) minted into a block by miners running the old software? [[User:WargeGeoshington\|WargeGeoshington]] ([[User talk:WargeGeoshington\|talk]]) 18:42, 12 August 2013 (GMT)

			***** A hard fork is where the blockchain protocol changes such that blocks which were considered invalid previously, are now considered valid. Addresses are a concept that don't even enter into the equation really. --[[User:Luke-jr\|Luke-jr]] ([[User talk:Luke-jr\|talk]]) 07:27, 13 August 2013 (GMT)

	:::::: Exactly, so a public, permanent forwarding order, via a new directive in the blockchain, would be seen as invalid to (or cause malfunction by) old software. Alternatively, a block created by old software, illegally spending from an address that's been permanently-forwarded, because the old software didn't recognize the forwarding-order, would be considered invalid to later software. Strong forwarding support means incompatible blocks. The wishlist idea is for this kind of strong protocol-support for irreversible forwarding; how can that happen short of a hard fork? -[[User:WargeGeoshington\|WargeGeoshington]] ([[User talk:WargeGeoshington\|talk]]) 02:14, 15 August 2013 (GMT)		:::::: Exactly, so a public, permanent forwarding order, via a new directive in the blockchain, would be seen as invalid to (or cause malfunction by) old software. Alternatively, a block created by old software, illegally spending from an address that's been permanently-forwarded, because the old software didn't recognize the forwarding-order, would be considered invalid to later software. Strong forwarding support means incompatible blocks. The wishlist idea is for this kind of strong protocol-support for irreversible forwarding; how can that happen short of a hard fork? -[[User:WargeGeoshington\|WargeGeoshington]] ([[User talk:WargeGeoshington\|talk]]) 02:14, 15 August 2013 (GMT)

Bestbitcoincasino at 09:35, 13 May 2014

2014-05-13T09:35:22Z

← Older revision		Revision as of 09:35, 13 May 2014
Line 52:		Line 52:

	This new categorical directive would not be understood by older nodes/mining software, so they'd reject blocks containing the directive. Even if it could be crafted to be ignored by older nodes... they'd then accept transactions/blocks which spend outputs from the 'dead' key according to old rules, leaving contradictory info in the shared chain. Thus as far as I can tell, to work this feature requires a hard fork. Of course, if there's a way to implement the same benefit in a compatible way, I'd appreciate hearing about it here on the talk page or elsewhere on the wiki. [[User:WargeGeoshington\|WargeGeoshington]] ([[User talk:WargeGeoshington\|talk]]) 10:52, 13 June 2013 (GMT)		This new categorical directive would not be understood by older nodes/mining software, so they'd reject blocks containing the directive. Even if it could be crafted to be ignored by older nodes... they'd then accept transactions/blocks which spend outputs from the 'dead' key according to old rules, leaving contradictory info in the shared chain. Thus as far as I can tell, to work this feature requires a hard fork. Of course, if there's a way to implement the same benefit in a compatible way, I'd appreciate hearing about it here on the talk page or elsewhere on the wiki. [[User:WargeGeoshington\|WargeGeoshington]] ([[User talk:WargeGeoshington\|talk]]) 10:52, 13 June 2013 (GMT)

	* Something like this really makes sense as a higher level of abstraction - part of a merged-mined timestamp block, for example. Clients would just consult this database for forwarding information when sending, and use the output for the new destination instead. It doesn't need to involve miners or other nodes at all. Even if you wanted miners to block sending to the forwarded output, that would be at most a soft-fork (making something formerly legal, now illegal). BUT, since addresses are single-use, I'm not sure it makes sense to do this at the address level at all - and it's effectively "default" in the payment protocol. --[[User:Luke-jr\|Luke-jr]] ([[User talk:Luke-jr\|talk]]) 19:11, 13 June 2013 (GMT)

	:: The idea that it's sender's responsibility to check some database is interesting... but makes senders reliant on having a full copy of this arbitrarily-large database. (It destroys the useful property, "all I need is to know my own inputs", for sending.) And what of old clients/nodes/miners that don't know to check the forwarding-database? They issue bad transactions to dead addresses. They'll mine/forward bad blocks with transactions related to dead-addresses, rejected by newer software. Meanwhile, even if the forwarding notation is squeezed into blocks in a backward-compatible (or by-indirect-reference) fashion, as soon as someone spends an auto-forwarded-by-rule amount, that transaction looks illegal to old nodes, causing old nodes to reject post-forwarding blocks. Pre-feature and post-feature software can't understand each others' blockchains, and grow indepedently if people keep running the old software. Isn't that the very definition of a 'hard fork'? (If not, can you fill me in with a better definition?)		:: The idea that it's sender's responsibility to check some database is interesting... but makes senders reliant on having a full copy of this arbitrarily-large database. (It destroys the useful property, "all I need is to know my own inputs", for sending.) And what of old clients/nodes/miners that don't know to check the forwarding-database? They issue bad transactions to dead addresses. They'll mine/forward bad blocks with transactions related to dead-addresses, rejected by newer software. Meanwhile, even if the forwarding notation is squeezed into blocks in a backward-compatible (or by-indirect-reference) fashion, as soon as someone spends an auto-forwarded-by-rule amount, that transaction looks illegal to old nodes, causing old nodes to reject post-forwarding blocks. Pre-feature and post-feature software can't understand each others' blockchains, and grow indepedently if people keep running the old software. Isn't that the very definition of a 'hard fork'? (If not, can you fill me in with a better definition?)
Line 60:		Line 58:

	:: So, you (and several others I've floated this to) think this is an "interesting idea". Maybe there's a way to do it with a soft fork (though I don't yet see it; it seems any such approach would be fragile or not offer the full benefits). There's a way to get the full benefits if it were in a 'hard fork'. So why shouldn't this idea appear on a page that's a unprioritized "wishlist", about changes that "might be desirable"? By deleting it you prevent evaluation and discussion of its possible value and possible implementations. --[[User:WargeGeoshington\|WargeGeoshington]] ([[User talk:WargeGeoshington\|talk]]) 05:15, 15 June 2013 (GMT)		:: So, you (and several others I've floated this to) think this is an "interesting idea". Maybe there's a way to do it with a soft fork (though I don't yet see it; it seems any such approach would be fragile or not offer the full benefits). There's a way to get the full benefits if it were in a 'hard fork'. So why shouldn't this idea appear on a page that's a unprioritized "wishlist", about changes that "might be desirable"? By deleting it you prevent evaluation and discussion of its possible value and possible implementations. --[[User:WargeGeoshington\|WargeGeoshington]] ([[User talk:WargeGeoshington\|talk]]) 05:15, 15 June 2013 (GMT)

	*** You can break address-compatibility without a hardfork. A soft-fork is sufficient to ban usage of forwarded addresses, as well. As new features such as HD wallets and the payment protocol becomes more widespread, address reuse should quickly decline out of usage anyway, making this a solution begging for a problem in the long-term (and remember, a hardfork is a long-term thing...). --[[User:Luke-jr\|Luke-jr]] ([[User talk:Luke-jr\|talk]]) 02:50, 16 June 2013 (GMT)

	:::: Maybe we're using different definitions of hard vs. soft forks. I see a 'hard fork' as a situation where old software, if it keeps running as nodes/miners, generates transactions and blocks that are not accepted by the post-hard-fork mainline. (A compatibility break that forces upgrades.) Is this definition wrong or imprecise? If not, how would a soft fork prevent someone with non-upgraded software from (a) sending a payment to an obsolete address which is then (b) minted into a block by miners running the old software? [[User:WargeGeoshington\|WargeGeoshington]] ([[User talk:WargeGeoshington\|talk]]) 18:42, 12 August 2013 (GMT)		:::: Maybe we're using different definitions of hard vs. soft forks. I see a 'hard fork' as a situation where old software, if it keeps running as nodes/miners, generates transactions and blocks that are not accepted by the post-hard-fork mainline. (A compatibility break that forces upgrades.) Is this definition wrong or imprecise? If not, how would a soft fork prevent someone with non-upgraded software from (a) sending a payment to an obsolete address which is then (b) minted into a block by miners running the old software? [[User:WargeGeoshington\|WargeGeoshington]] ([[User talk:WargeGeoshington\|talk]]) 18:42, 12 August 2013 (GMT)

	***** A hard fork is where the blockchain protocol changes such that blocks which were considered invalid previously, are now considered valid. Addresses are a concept that don't even enter into the equation really. --[[User:Luke-jr\|Luke-jr]] ([[User talk:Luke-jr\|talk]]) 07:27, 13 August 2013 (GMT)

	:::::: Exactly, so a public, permanent forwarding order, via a new directive in the blockchain, would be seen as invalid to (or cause malfunction by) old software. Alternatively, a block created by old software, illegally spending from an address that's been permanently-forwarded, because the old software didn't recognize the forwarding-order, would be considered invalid to later software. Strong forwarding support means incompatible blocks. The wishlist idea is for this kind of strong protocol-support for irreversible forwarding; how can that happen short of a hard fork? -[[User:WargeGeoshington\|WargeGeoshington]] ([[User talk:WargeGeoshington\|talk]]) 02:14, 15 August 2013 (GMT)		:::::: Exactly, so a public, permanent forwarding order, via a new directive in the blockchain, would be seen as invalid to (or cause malfunction by) old software. Alternatively, a block created by old software, illegally spending from an address that's been permanently-forwarded, because the old software didn't recognize the forwarding-order, would be considered invalid to later software. Strong forwarding support means incompatible blocks. The wishlist idea is for this kind of strong protocol-support for irreversible forwarding; how can that happen short of a hard fork? -[[User:WargeGeoshington\|WargeGeoshington]] ([[User talk:WargeGeoshington\|talk]]) 02:14, 15 August 2013 (GMT)

Airbreather: Isn't this "bug fix" obsolete as of BIP 34?

2014-02-09T19:06:29Z

Isn't this "bug fix" obsolete as of BIP 34?

← Older revision		Revision as of 19:06, 9 February 2014
Line 1:		Line 1:
			==Obsolete item in "Bug Fixes"?==
			* Use the previous block hash as an explicit or implicit prev_in in coinbases when hashing them to make it ~impossible to get a duplicate coinbase, thus removing the need for a pruning node to remember coinbase hashes to prevent duplicates consistently with the rest of the network
			As of [https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki BIP 34], isn't this item obsolete? --[[User:Airbreather\|Airbreather]] ([[User talk:Airbreather\|talk]]) 19:06, 9 February 2014 (GMT)

	==Proposals which reduce security==		==Proposals which reduce security==
	"Difficulty adjustment should adapt to sudden hashrate loss"		"Difficulty adjustment should adapt to sudden hashrate loss"

WargeGeoshington: /* 'Permanent Forwarding' */ clarifying wording of last comment inplace

2013-08-15T02:17:05Z

'Permanent Forwarding': clarifying wording of last comment inplace

← Older revision		Revision as of 02:17, 15 August 2013
Line 63:		Line 63:
	***** A hard fork is where the blockchain protocol changes such that blocks which were considered invalid previously, are now considered valid. Addresses are a concept that don't even enter into the equation really. --[[User:Luke-jr\|Luke-jr]] ([[User talk:Luke-jr\|talk]]) 07:27, 13 August 2013 (GMT)		***** A hard fork is where the blockchain protocol changes such that blocks which were considered invalid previously, are now considered valid. Addresses are a concept that don't even enter into the equation really. --[[User:Luke-jr\|Luke-jr]] ([[User talk:Luke-jr\|talk]]) 07:27, 13 August 2013 (GMT)

	:::::: Exactly, so a public, permanent forwarding order via a new ~~feature~~ in the blockchain would be seen as invalid to old software. (Alternatively, a block created by old software, spending from an address that's been permanently-forwarded because it didn't recognize the forwarding-order, would be considered invalid to later software.) The wishlist idea is for protocol-support for irreversible forwarding; how can that happen short of a hard fork? -[[User:WargeGeoshington\|WargeGeoshington]] ([[User talk:WargeGeoshington\|talk]]) 02:14, 15 August 2013 (GMT)		:::::: Exactly, so a public, permanent forwarding order, via a new directive in the blockchain, would be seen as invalid to (or cause malfunction by) old software. Alternatively, a block created by old software, illegally spending from an address that's been permanently-forwarded, because the old software didn't recognize the forwarding-order, would be considered invalid to later software. Strong forwarding support means incompatible blocks. The wishlist idea is for this kind of strong protocol-support for irreversible forwarding; how can that happen short of a hard fork? -[[User:WargeGeoshington\|WargeGeoshington]] ([[User talk:WargeGeoshington\|talk]]) 02:14, 15 August 2013 (GMT)

WargeGeoshington: /* 'Permanent Forwarding' */

2013-08-15T02:14:42Z

'Permanent Forwarding'

← Older revision		Revision as of 02:14, 15 August 2013
Line 62:		Line 62:

	***** A hard fork is where the blockchain protocol changes such that blocks which were considered invalid previously, are now considered valid. Addresses are a concept that don't even enter into the equation really. --[[User:Luke-jr\|Luke-jr]] ([[User talk:Luke-jr\|talk]]) 07:27, 13 August 2013 (GMT)		***** A hard fork is where the blockchain protocol changes such that blocks which were considered invalid previously, are now considered valid. Addresses are a concept that don't even enter into the equation really. --[[User:Luke-jr\|Luke-jr]] ([[User talk:Luke-jr\|talk]]) 07:27, 13 August 2013 (GMT)

			:::::: Exactly, so a public, permanent forwarding order via a new feature in the blockchain would be seen as invalid to old software. (Alternatively, a block created by old software, spending from an address that's been permanently-forwarded because it didn't recognize the forwarding-order, would be considered invalid to later software.) The wishlist idea is for protocol-support for irreversible forwarding; how can that happen short of a hard fork? -[[User:WargeGeoshington\|WargeGeoshington]] ([[User talk:WargeGeoshington\|talk]]) 02:14, 15 August 2013 (GMT)

Luke-jr: /* 'Permanent Forwarding' */

2013-08-13T07:27:35Z

'Permanent Forwarding'

← Older revision		Revision as of 07:27, 13 August 2013
Line 60:		Line 60:

	:::: Maybe we're using different definitions of hard vs. soft forks. I see a 'hard fork' as a situation where old software, if it keeps running as nodes/miners, generates transactions and blocks that are not accepted by the post-hard-fork mainline. (A compatibility break that forces upgrades.) Is this definition wrong or imprecise? If not, how would a soft fork prevent someone with non-upgraded software from (a) sending a payment to an obsolete address which is then (b) minted into a block by miners running the old software? [[User:WargeGeoshington\|WargeGeoshington]] ([[User talk:WargeGeoshington\|talk]]) 18:42, 12 August 2013 (GMT)		:::: Maybe we're using different definitions of hard vs. soft forks. I see a 'hard fork' as a situation where old software, if it keeps running as nodes/miners, generates transactions and blocks that are not accepted by the post-hard-fork mainline. (A compatibility break that forces upgrades.) Is this definition wrong or imprecise? If not, how would a soft fork prevent someone with non-upgraded software from (a) sending a payment to an obsolete address which is then (b) minted into a block by miners running the old software? [[User:WargeGeoshington\|WargeGeoshington]] ([[User talk:WargeGeoshington\|talk]]) 18:42, 12 August 2013 (GMT)

			***** A hard fork is where the blockchain protocol changes such that blocks which were considered invalid previously, are now considered valid. Addresses are a concept that don't even enter into the equation really. --[[User:Luke-jr\|Luke-jr]] ([[User talk:Luke-jr\|talk]]) 07:27, 13 August 2013 (GMT)

WargeGeoshington: /* 'Permanent Forwarding' */

2013-08-12T18:42:19Z

'Permanent Forwarding'

← Older revision		Revision as of 18:42, 12 August 2013
Line 58:		Line 58:

	*** You can break address-compatibility without a hardfork. A soft-fork is sufficient to ban usage of forwarded addresses, as well. As new features such as HD wallets and the payment protocol becomes more widespread, address reuse should quickly decline out of usage anyway, making this a solution begging for a problem in the long-term (and remember, a hardfork is a long-term thing...). --[[User:Luke-jr\|Luke-jr]] ([[User talk:Luke-jr\|talk]]) 02:50, 16 June 2013 (GMT)		*** You can break address-compatibility without a hardfork. A soft-fork is sufficient to ban usage of forwarded addresses, as well. As new features such as HD wallets and the payment protocol becomes more widespread, address reuse should quickly decline out of usage anyway, making this a solution begging for a problem in the long-term (and remember, a hardfork is a long-term thing...). --[[User:Luke-jr\|Luke-jr]] ([[User talk:Luke-jr\|talk]]) 02:50, 16 June 2013 (GMT)

			:::: Maybe we're using different definitions of hard vs. soft forks. I see a 'hard fork' as a situation where old software, if it keeps running as nodes/miners, generates transactions and blocks that are not accepted by the post-hard-fork mainline. (A compatibility break that forces upgrades.) Is this definition wrong or imprecise? If not, how would a soft fork prevent someone with non-upgraded software from (a) sending a payment to an obsolete address which is then (b) minted into a block by miners running the old software? [[User:WargeGeoshington\|WargeGeoshington]] ([[User talk:WargeGeoshington\|talk]]) 18:42, 12 August 2013 (GMT)

Luke-jr: /* 'Permanent Forwarding' */

2013-06-16T02:50:04Z

'Permanent Forwarding'

← Older revision		Revision as of 02:50, 16 June 2013
Line 56:		Line 56:

	:: So, you (and several others I've floated this to) think this is an "interesting idea". Maybe there's a way to do it with a soft fork (though I don't yet see it; it seems any such approach would be fragile or not offer the full benefits). There's a way to get the full benefits if it were in a 'hard fork'. So why shouldn't this idea appear on a page that's a unprioritized "wishlist", about changes that "might be desirable"? By deleting it you prevent evaluation and discussion of its possible value and possible implementations. --[[User:WargeGeoshington\|WargeGeoshington]] ([[User talk:WargeGeoshington\|talk]]) 05:15, 15 June 2013 (GMT)		:: So, you (and several others I've floated this to) think this is an "interesting idea". Maybe there's a way to do it with a soft fork (though I don't yet see it; it seems any such approach would be fragile or not offer the full benefits). There's a way to get the full benefits if it were in a 'hard fork'. So why shouldn't this idea appear on a page that's a unprioritized "wishlist", about changes that "might be desirable"? By deleting it you prevent evaluation and discussion of its possible value and possible implementations. --[[User:WargeGeoshington\|WargeGeoshington]] ([[User talk:WargeGeoshington\|talk]]) 05:15, 15 June 2013 (GMT)

			*** You can break address-compatibility without a hardfork. A soft-fork is sufficient to ban usage of forwarded addresses, as well. As new features such as HD wallets and the payment protocol becomes more widespread, address reuse should quickly decline out of usage anyway, making this a solution begging for a problem in the long-term (and remember, a hardfork is a long-term thing...). --[[User:Luke-jr\|Luke-jr]] ([[User talk:Luke-jr\|talk]]) 02:50, 16 June 2013 (GMT)

WargeGeoshington: /* 'Permanent Forwarding' */ why proper 'forwarding' needs a 'hard fork' to work well

2013-06-15T05:15:17Z

'Permanent Forwarding': why proper 'forwarding' needs a 'hard fork' to work well

← Older revision		Revision as of 05:15, 15 June 2013
Line 50:		Line 50:

	* Something like this really makes sense as a higher level of abstraction - part of a merged-mined timestamp block, for example. Clients would just consult this database for forwarding information when sending, and use the output for the new destination instead. It doesn't need to involve miners or other nodes at all. Even if you wanted miners to block sending to the forwarded output, that would be at most a soft-fork (making something formerly legal, now illegal). BUT, since addresses are single-use, I'm not sure it makes sense to do this at the address level at all - and it's effectively "default" in the payment protocol. --[[User:Luke-jr\|Luke-jr]] ([[User talk:Luke-jr\|talk]]) 19:11, 13 June 2013 (GMT)		* Something like this really makes sense as a higher level of abstraction - part of a merged-mined timestamp block, for example. Clients would just consult this database for forwarding information when sending, and use the output for the new destination instead. It doesn't need to involve miners or other nodes at all. Even if you wanted miners to block sending to the forwarded output, that would be at most a soft-fork (making something formerly legal, now illegal). BUT, since addresses are single-use, I'm not sure it makes sense to do this at the address level at all - and it's effectively "default" in the payment protocol. --[[User:Luke-jr\|Luke-jr]] ([[User talk:Luke-jr\|talk]]) 19:11, 13 June 2013 (GMT)

			:: The idea that it's sender's responsibility to check some database is interesting... but makes senders reliant on having a full copy of this arbitrarily-large database. (It destroys the useful property, "all I need is to know my own inputs", for sending.) And what of old clients/nodes/miners that don't know to check the forwarding-database? They issue bad transactions to dead addresses. They'll mine/forward bad blocks with transactions related to dead-addresses, rejected by newer software. Meanwhile, even if the forwarding notation is squeezed into blocks in a backward-compatible (or by-indirect-reference) fashion, as soon as someone spends an auto-forwarded-by-rule amount, that transaction looks illegal to old nodes, causing old nodes to reject post-forwarding blocks. Pre-feature and post-feature software can't understand each others' blockchains, and grow indepedently if people keep running the old software. Isn't that the very definition of a 'hard fork'? (If not, can you fill me in with a better definition?)

			:: In idealized theory -- and perhaps in Satoshi's vision -- addresses are single-use. But that's not protocol-required and in practice, many users/apps reuse addresses and advertise long-lived addresses... which gives rise to the exact security/usability problem this proposal attempts to address.

			:: So, you (and several others I've floated this to) think this is an "interesting idea". Maybe there's a way to do it with a soft fork (though I don't yet see it; it seems any such approach would be fragile or not offer the full benefits). There's a way to get the full benefits if it were in a 'hard fork'. So why shouldn't this idea appear on a page that's a unprioritized "wishlist", about changes that "might be desirable"? By deleting it you prevent evaluation and discussion of its possible value and possible implementations. --[[User:WargeGeoshington\|WargeGeoshington]] ([[User talk:WargeGeoshington\|talk]]) 05:15, 15 June 2013 (GMT)

Luke-jr: /* 'Permanent Forwarding' */

2013-06-13T19:11:26Z

'Permanent Forwarding'

← Older revision		Revision as of 19:11, 13 June 2013
Line 48:		Line 48:

	This new categorical directive would not be understood by older nodes/mining software, so they'd reject blocks containing the directive. Even if it could be crafted to be ignored by older nodes... they'd then accept transactions/blocks which spend outputs from the 'dead' key according to old rules, leaving contradictory info in the shared chain. Thus as far as I can tell, to work this feature requires a hard fork. Of course, if there's a way to implement the same benefit in a compatible way, I'd appreciate hearing about it here on the talk page or elsewhere on the wiki. [[User:WargeGeoshington\|WargeGeoshington]] ([[User talk:WargeGeoshington\|talk]]) 10:52, 13 June 2013 (GMT)		This new categorical directive would not be understood by older nodes/mining software, so they'd reject blocks containing the directive. Even if it could be crafted to be ignored by older nodes... they'd then accept transactions/blocks which spend outputs from the 'dead' key according to old rules, leaving contradictory info in the shared chain. Thus as far as I can tell, to work this feature requires a hard fork. Of course, if there's a way to implement the same benefit in a compatible way, I'd appreciate hearing about it here on the talk page or elsewhere on the wiki. [[User:WargeGeoshington\|WargeGeoshington]] ([[User talk:WargeGeoshington\|talk]]) 10:52, 13 June 2013 (GMT)

			* Something like this really makes sense as a higher level of abstraction - part of a merged-mined timestamp block, for example. Clients would just consult this database for forwarding information when sending, and use the output for the new destination instead. It doesn't need to involve miners or other nodes at all. Even if you wanted miners to block sending to the forwarded output, that would be at most a soft-fork (making something formerly legal, now illegal). BUT, since addresses are single-use, I'm not sure it makes sense to do this at the address level at all - and it's effectively "default" in the payment protocol. --[[User:Luke-jr\|Luke-jr]] ([[User talk:Luke-jr\|talk]]) 19:11, 13 June 2013 (GMT)

← Older revision		Revision as of 22:35, 13 May 2014
Line 52:		Line 52:

	This new categorical directive would not be understood by older nodes/mining software, so they'd reject blocks containing the directive. Even if it could be crafted to be ignored by older nodes... they'd then accept transactions/blocks which spend outputs from the 'dead' key according to old rules, leaving contradictory info in the shared chain. Thus as far as I can tell, to work this feature requires a hard fork. Of course, if there's a way to implement the same benefit in a compatible way, I'd appreciate hearing about it here on the talk page or elsewhere on the wiki. [[User:WargeGeoshington\|WargeGeoshington]] ([[User talk:WargeGeoshington\|talk]]) 10:52, 13 June 2013 (GMT)		This new categorical directive would not be understood by older nodes/mining software, so they'd reject blocks containing the directive. Even if it could be crafted to be ignored by older nodes... they'd then accept transactions/blocks which spend outputs from the 'dead' key according to old rules, leaving contradictory info in the shared chain. Thus as far as I can tell, to work this feature requires a hard fork. Of course, if there's a way to implement the same benefit in a compatible way, I'd appreciate hearing about it here on the talk page or elsewhere on the wiki. [[User:WargeGeoshington\|WargeGeoshington]] ([[User talk:WargeGeoshington\|talk]]) 10:52, 13 June 2013 (GMT)

			* Something like this really makes sense as a higher level of abstraction - part of a merged-mined timestamp block, for example. Clients would just consult this database for forwarding information when sending, and use the output for the new destination instead. It doesn't need to involve miners or other nodes at all. Even if you wanted miners to block sending to the forwarded output, that would be at most a soft-fork (making something formerly legal, now illegal). BUT, since addresses are single-use, I'm not sure it makes sense to do this at the address level at all - and it's effectively "default" in the payment protocol. --[[User:Luke-jr\|Luke-jr]] ([[User talk:Luke-jr\|talk]]) 19:11, 13 June 2013 (GMT)

	:: The idea that it's sender's responsibility to check some database is interesting... but makes senders reliant on having a full copy of this arbitrarily-large database. (It destroys the useful property, "all I need is to know my own inputs", for sending.) And what of old clients/nodes/miners that don't know to check the forwarding-database? They issue bad transactions to dead addresses. They'll mine/forward bad blocks with transactions related to dead-addresses, rejected by newer software. Meanwhile, even if the forwarding notation is squeezed into blocks in a backward-compatible (or by-indirect-reference) fashion, as soon as someone spends an auto-forwarded-by-rule amount, that transaction looks illegal to old nodes, causing old nodes to reject post-forwarding blocks. Pre-feature and post-feature software can't understand each others' blockchains, and grow indepedently if people keep running the old software. Isn't that the very definition of a 'hard fork'? (If not, can you fill me in with a better definition?)		:: The idea that it's sender's responsibility to check some database is interesting... but makes senders reliant on having a full copy of this arbitrarily-large database. (It destroys the useful property, "all I need is to know my own inputs", for sending.) And what of old clients/nodes/miners that don't know to check the forwarding-database? They issue bad transactions to dead addresses. They'll mine/forward bad blocks with transactions related to dead-addresses, rejected by newer software. Meanwhile, even if the forwarding notation is squeezed into blocks in a backward-compatible (or by-indirect-reference) fashion, as soon as someone spends an auto-forwarded-by-rule amount, that transaction looks illegal to old nodes, causing old nodes to reject post-forwarding blocks. Pre-feature and post-feature software can't understand each others' blockchains, and grow indepedently if people keep running the old software. Isn't that the very definition of a 'hard fork'? (If not, can you fill me in with a better definition?)
Line 58:		Line 60:

	:: So, you (and several others I've floated this to) think this is an "interesting idea". Maybe there's a way to do it with a soft fork (though I don't yet see it; it seems any such approach would be fragile or not offer the full benefits). There's a way to get the full benefits if it were in a 'hard fork'. So why shouldn't this idea appear on a page that's a unprioritized "wishlist", about changes that "might be desirable"? By deleting it you prevent evaluation and discussion of its possible value and possible implementations. --[[User:WargeGeoshington\|WargeGeoshington]] ([[User talk:WargeGeoshington\|talk]]) 05:15, 15 June 2013 (GMT)		:: So, you (and several others I've floated this to) think this is an "interesting idea". Maybe there's a way to do it with a soft fork (though I don't yet see it; it seems any such approach would be fragile or not offer the full benefits). There's a way to get the full benefits if it were in a 'hard fork'. So why shouldn't this idea appear on a page that's a unprioritized "wishlist", about changes that "might be desirable"? By deleting it you prevent evaluation and discussion of its possible value and possible implementations. --[[User:WargeGeoshington\|WargeGeoshington]] ([[User talk:WargeGeoshington\|talk]]) 05:15, 15 June 2013 (GMT)

			*** You can break address-compatibility without a hardfork. A soft-fork is sufficient to ban usage of forwarded addresses, as well. As new features such as HD wallets and the payment protocol becomes more widespread, address reuse should quickly decline out of usage anyway, making this a solution begging for a problem in the long-term (and remember, a hardfork is a long-term thing...). --[[User:Luke-jr\|Luke-jr]] ([[User talk:Luke-jr\|talk]]) 02:50, 16 June 2013 (GMT)

	:::: Maybe we're using different definitions of hard vs. soft forks. I see a 'hard fork' as a situation where old software, if it keeps running as nodes/miners, generates transactions and blocks that are not accepted by the post-hard-fork mainline. (A compatibility break that forces upgrades.) Is this definition wrong or imprecise? If not, how would a soft fork prevent someone with non-upgraded software from (a) sending a payment to an obsolete address which is then (b) minted into a block by miners running the old software? [[User:WargeGeoshington\|WargeGeoshington]] ([[User talk:WargeGeoshington\|talk]]) 18:42, 12 August 2013 (GMT)		:::: Maybe we're using different definitions of hard vs. soft forks. I see a 'hard fork' as a situation where old software, if it keeps running as nodes/miners, generates transactions and blocks that are not accepted by the post-hard-fork mainline. (A compatibility break that forces upgrades.) Is this definition wrong or imprecise? If not, how would a soft fork prevent someone with non-upgraded software from (a) sending a payment to an obsolete address which is then (b) minted into a block by miners running the old software? [[User:WargeGeoshington\|WargeGeoshington]] ([[User talk:WargeGeoshington\|talk]]) 18:42, 12 August 2013 (GMT)

			***** A hard fork is where the blockchain protocol changes such that blocks which were considered invalid previously, are now considered valid. Addresses are a concept that don't even enter into the equation really. --[[User:Luke-jr\|Luke-jr]] ([[User talk:Luke-jr\|talk]]) 07:27, 13 August 2013 (GMT)

	:::::: Exactly, so a public, permanent forwarding order, via a new directive in the blockchain, would be seen as invalid to (or cause malfunction by) old software. Alternatively, a block created by old software, illegally spending from an address that's been permanently-forwarded, because the old software didn't recognize the forwarding-order, would be considered invalid to later software. Strong forwarding support means incompatible blocks. The wishlist idea is for this kind of strong protocol-support for irreversible forwarding; how can that happen short of a hard fork? -[[User:WargeGeoshington\|WargeGeoshington]] ([[User talk:WargeGeoshington\|talk]]) 02:14, 15 August 2013 (GMT)		:::::: Exactly, so a public, permanent forwarding order, via a new directive in the blockchain, would be seen as invalid to (or cause malfunction by) old software. Alternatively, a block created by old software, illegally spending from an address that's been permanently-forwarded, because the old software didn't recognize the forwarding-order, would be considered invalid to later software. Strong forwarding support means incompatible blocks. The wishlist idea is for this kind of strong protocol-support for irreversible forwarding; how can that happen short of a hard fork? -[[User:WargeGeoshington\|WargeGeoshington]] ([[User talk:WargeGeoshington\|talk]]) 02:14, 15 August 2013 (GMT)

← Older revision		Revision as of 09:35, 13 May 2014
Line 52:		Line 52:

	This new categorical directive would not be understood by older nodes/mining software, so they'd reject blocks containing the directive. Even if it could be crafted to be ignored by older nodes... they'd then accept transactions/blocks which spend outputs from the 'dead' key according to old rules, leaving contradictory info in the shared chain. Thus as far as I can tell, to work this feature requires a hard fork. Of course, if there's a way to implement the same benefit in a compatible way, I'd appreciate hearing about it here on the talk page or elsewhere on the wiki. [[User:WargeGeoshington\|WargeGeoshington]] ([[User talk:WargeGeoshington\|talk]]) 10:52, 13 June 2013 (GMT)		This new categorical directive would not be understood by older nodes/mining software, so they'd reject blocks containing the directive. Even if it could be crafted to be ignored by older nodes... they'd then accept transactions/blocks which spend outputs from the 'dead' key according to old rules, leaving contradictory info in the shared chain. Thus as far as I can tell, to work this feature requires a hard fork. Of course, if there's a way to implement the same benefit in a compatible way, I'd appreciate hearing about it here on the talk page or elsewhere on the wiki. [[User:WargeGeoshington\|WargeGeoshington]] ([[User talk:WargeGeoshington\|talk]]) 10:52, 13 June 2013 (GMT)

	* Something like this really makes sense as a higher level of abstraction - part of a merged-mined timestamp block, for example. Clients would just consult this database for forwarding information when sending, and use the output for the new destination instead. It doesn't need to involve miners or other nodes at all. Even if you wanted miners to block sending to the forwarded output, that would be at most a soft-fork (making something formerly legal, now illegal). BUT, since addresses are single-use, I'm not sure it makes sense to do this at the address level at all - and it's effectively "default" in the payment protocol. --[[User:Luke-jr\|Luke-jr]] ([[User talk:Luke-jr\|talk]]) 19:11, 13 June 2013 (GMT)

	:: The idea that it's sender's responsibility to check some database is interesting... but makes senders reliant on having a full copy of this arbitrarily-large database. (It destroys the useful property, "all I need is to know my own inputs", for sending.) And what of old clients/nodes/miners that don't know to check the forwarding-database? They issue bad transactions to dead addresses. They'll mine/forward bad blocks with transactions related to dead-addresses, rejected by newer software. Meanwhile, even if the forwarding notation is squeezed into blocks in a backward-compatible (or by-indirect-reference) fashion, as soon as someone spends an auto-forwarded-by-rule amount, that transaction looks illegal to old nodes, causing old nodes to reject post-forwarding blocks. Pre-feature and post-feature software can't understand each others' blockchains, and grow indepedently if people keep running the old software. Isn't that the very definition of a 'hard fork'? (If not, can you fill me in with a better definition?)		:: The idea that it's sender's responsibility to check some database is interesting... but makes senders reliant on having a full copy of this arbitrarily-large database. (It destroys the useful property, "all I need is to know my own inputs", for sending.) And what of old clients/nodes/miners that don't know to check the forwarding-database? They issue bad transactions to dead addresses. They'll mine/forward bad blocks with transactions related to dead-addresses, rejected by newer software. Meanwhile, even if the forwarding notation is squeezed into blocks in a backward-compatible (or by-indirect-reference) fashion, as soon as someone spends an auto-forwarded-by-rule amount, that transaction looks illegal to old nodes, causing old nodes to reject post-forwarding blocks. Pre-feature and post-feature software can't understand each others' blockchains, and grow indepedently if people keep running the old software. Isn't that the very definition of a 'hard fork'? (If not, can you fill me in with a better definition?)
Line 60:		Line 58:

	:: So, you (and several others I've floated this to) think this is an "interesting idea". Maybe there's a way to do it with a soft fork (though I don't yet see it; it seems any such approach would be fragile or not offer the full benefits). There's a way to get the full benefits if it were in a 'hard fork'. So why shouldn't this idea appear on a page that's a unprioritized "wishlist", about changes that "might be desirable"? By deleting it you prevent evaluation and discussion of its possible value and possible implementations. --[[User:WargeGeoshington\|WargeGeoshington]] ([[User talk:WargeGeoshington\|talk]]) 05:15, 15 June 2013 (GMT)		:: So, you (and several others I've floated this to) think this is an "interesting idea". Maybe there's a way to do it with a soft fork (though I don't yet see it; it seems any such approach would be fragile or not offer the full benefits). There's a way to get the full benefits if it were in a 'hard fork'. So why shouldn't this idea appear on a page that's a unprioritized "wishlist", about changes that "might be desirable"? By deleting it you prevent evaluation and discussion of its possible value and possible implementations. --[[User:WargeGeoshington\|WargeGeoshington]] ([[User talk:WargeGeoshington\|talk]]) 05:15, 15 June 2013 (GMT)

	*** You can break address-compatibility without a hardfork. A soft-fork is sufficient to ban usage of forwarded addresses, as well. As new features such as HD wallets and the payment protocol becomes more widespread, address reuse should quickly decline out of usage anyway, making this a solution begging for a problem in the long-term (and remember, a hardfork is a long-term thing...). --[[User:Luke-jr\|Luke-jr]] ([[User talk:Luke-jr\|talk]]) 02:50, 16 June 2013 (GMT)

	:::: Maybe we're using different definitions of hard vs. soft forks. I see a 'hard fork' as a situation where old software, if it keeps running as nodes/miners, generates transactions and blocks that are not accepted by the post-hard-fork mainline. (A compatibility break that forces upgrades.) Is this definition wrong or imprecise? If not, how would a soft fork prevent someone with non-upgraded software from (a) sending a payment to an obsolete address which is then (b) minted into a block by miners running the old software? [[User:WargeGeoshington\|WargeGeoshington]] ([[User talk:WargeGeoshington\|talk]]) 18:42, 12 August 2013 (GMT)		:::: Maybe we're using different definitions of hard vs. soft forks. I see a 'hard fork' as a situation where old software, if it keeps running as nodes/miners, generates transactions and blocks that are not accepted by the post-hard-fork mainline. (A compatibility break that forces upgrades.) Is this definition wrong or imprecise? If not, how would a soft fork prevent someone with non-upgraded software from (a) sending a payment to an obsolete address which is then (b) minted into a block by miners running the old software? [[User:WargeGeoshington\|WargeGeoshington]] ([[User talk:WargeGeoshington\|talk]]) 18:42, 12 August 2013 (GMT)

	***** A hard fork is where the blockchain protocol changes such that blocks which were considered invalid previously, are now considered valid. Addresses are a concept that don't even enter into the equation really. --[[User:Luke-jr\|Luke-jr]] ([[User talk:Luke-jr\|talk]]) 07:27, 13 August 2013 (GMT)

	:::::: Exactly, so a public, permanent forwarding order, via a new directive in the blockchain, would be seen as invalid to (or cause malfunction by) old software. Alternatively, a block created by old software, illegally spending from an address that's been permanently-forwarded, because the old software didn't recognize the forwarding-order, would be considered invalid to later software. Strong forwarding support means incompatible blocks. The wishlist idea is for this kind of strong protocol-support for irreversible forwarding; how can that happen short of a hard fork? -[[User:WargeGeoshington\|WargeGeoshington]] ([[User talk:WargeGeoshington\|talk]]) 02:14, 15 August 2013 (GMT)		:::::: Exactly, so a public, permanent forwarding order, via a new directive in the blockchain, would be seen as invalid to (or cause malfunction by) old software. Alternatively, a block created by old software, illegally spending from an address that's been permanently-forwarded, because the old software didn't recognize the forwarding-order, would be considered invalid to later software. Strong forwarding support means incompatible blocks. The wishlist idea is for this kind of strong protocol-support for irreversible forwarding; how can that happen short of a hard fork? -[[User:WargeGeoshington\|WargeGeoshington]] ([[User talk:WargeGeoshington\|talk]]) 02:14, 15 August 2013 (GMT)