Adaptive difficulty - Revision history

Ids: capitalisation of Bitcoin when it means the system as a whole

2012-11-25T02:51:07Z

capitalisation of Bitcoin when it means the system as a whole

← Older revision		Revision as of 02:51, 25 November 2012
Line 1:		Line 1:
	'''Adaptive difficulty''' is a ~~bitcoin~~ protocol change proposal by [[User:Ids\|Iain Stewart]], with the goal of letting the typical time interval from one block to the next adjust smoothly to prevailing network latency, while not compromising the strength of the blockchain, or the decentralized character of the network.		'''Adaptive difficulty''' is a Bitcoin protocol change proposal by [[User:Ids\|Iain Stewart]], with the goal of letting the typical time interval from one block to the next adjust smoothly to prevailing network latency, while not compromising the strength of the blockchain, or the decentralized character of the network.

	'''''EDIT 2012-11-22:''' My idea is essentially the same as that proposed by [http://en.wikipedia.org/wiki/User:Meni_Rosenfeld Meni Rosenfeld] on the [https://bitcointalk.org/index.php?board=6.0 Bitcoin forums]. Please read and enjoy and critique [https://bitcointalk.org/index.php?topic=79837.0 his adaptive difficulty proposal]! (I'll leave this page here for historical completeness, but not continue working on it.) [[User:Ids\|Iain Stewart]] 01:00, 23 November 2012 (GMT)''		'''''EDIT 2012-11-22:''' My idea is essentially the same as that proposed by [http://en.wikipedia.org/wiki/User:Meni_Rosenfeld Meni Rosenfeld] on the [https://bitcointalk.org/index.php?board=6.0 Bitcoin forums]. Please read and enjoy and critique [https://bitcointalk.org/index.php?topic=79837.0 his adaptive difficulty proposal]! (I'll leave this page here for historical completeness, but not continue working on it.) [[User:Ids\|Iain Stewart]] 01:00, 23 November 2012 (GMT)''
Line 7:		Line 7:
	The world is being wired up with ever faster connectivity. A merchant location in particular, where any kind of online transaction is desired, will usually have a fast link to either the net or specific counterparty bank(s), with paid-for higher bandwidth and lower latency than the usual domestic speeds. All but the smallest businesses where an internet presence is de rigeur now routinely choose to pay for a fast connection, sometimes choosing to pay a little extra for a guarantee of quick repair ("five nines" cover and the like).		The world is being wired up with ever faster connectivity. A merchant location in particular, where any kind of online transaction is desired, will usually have a fast link to either the net or specific counterparty bank(s), with paid-for higher bandwidth and lower latency than the usual domestic speeds. All but the smallest businesses where an internet presence is de rigeur now routinely choose to pay for a fast connection, sometimes choosing to pay a little extra for a guarantee of quick repair ("five nines" cover and the like).

	It will therefore remain an expectation of customers that a merchant can process their transaction quickly as a matter of course. (With ~~bitcoin~~, we do have the sub-community of users who desire strong anonymity and may use Tor/i2p, coin mixing services, and the like. They are tech-savvy and accept that these choices cause slowness. We can't expect that to become the broader expectation, however.)		It will therefore remain an expectation of customers that a merchant can process their transaction quickly as a matter of course. (With Bitcoin, we do have the sub-community of users who desire strong anonymity and may use Tor/i2p, coin mixing services, and the like. They are tech-savvy and accept that these choices cause slowness. We can't expect that to become the broader expectation, however.)

	The average 10-minute interval between blocks, and the need to wait a few blocks (6 is often cited) to achieve acceptable closeness to irreversibility of one's transaction, will likely be a barrier to ease of use in cases where an expectation of speed is firmly embedded in customers' and merchants' culture. (Even people who choose to slow down the ''submission'' of their transaction, in exchange for better anonymity for example, would still benefit from fast ''handling'' of their transaction once it has been submitted. They too may well grumble at the tens of minutes' to hours' delay on top of that of their own choosing.)		The average 10-minute interval between blocks, and the need to wait a few blocks (6 is often cited) to achieve acceptable closeness to irreversibility of one's transaction, will likely be a barrier to ease of use in cases where an expectation of speed is firmly embedded in customers' and merchants' culture. (Even people who choose to slow down the ''submission'' of their transaction, in exchange for better anonymity for example, would still benefit from fast ''handling'' of their transaction once it has been submitted. They too may well grumble at the tens of minutes' to hours' delay on top of that of their own choosing.)
Line 31:		Line 31:
	== ''...and now for something completely different! (unpolished teaser for now...)'' ==		== ''...and now for something completely different! (unpolished teaser for now...)'' ==

	''(Just to explain - I'm neglecting this adaptive difficulty stuff for a while [sorry!] because I '''seem''' to have almost accidentally invented [the bare beginnings of] a different system which protects against even a '''considerably-greater-than-50% attack'''! I don't want to create a page on it just yet before I thoroughly check that I'm not making a fool of myself... [well, I'll allow myself a stub, as a home for this teaser stuff: "[[Proof_of_blockchain_fair_sharing\|proof of blockchain fair sharing]]"] ...but as a teaser description: it's of proof-of-stake flavour [which makes me nervous in some ways, but that's another story], and it relies on the fact that stakeholders are '''pseudonymously trackable''', unlike proof-of-work contributors, and therefore a formula for blockchain height can reward '''closeness to fair-share proportions''' in such a way that a 90% attacker finds they can't stop the honest 10% contributing too-expensive-for-attacker-to-reverse blocks which, to the attacker's chagrin, '''incorporate''' the accumulated transactions the attacker has been endlessly reversing and re-excluding in an effort to ruin the credibility of ~~bitcoin~~. [And any change to the attacker's pseudonymous identity/identities destroys their bitcoin-days' stake and takes them out of the running as a big attacker for a long time.] - More to follow real soon now hopefully!)''		''(Just to explain - I'm neglecting this adaptive difficulty stuff for a while [sorry!] because I '''seem''' to have almost accidentally invented [the bare beginnings of] a different system which protects against even a '''considerably-greater-than-50% attack'''! I don't want to create a page on it just yet before I thoroughly check that I'm not making a fool of myself... [well, I'll allow myself a stub, as a home for this teaser stuff: "[[Proof_of_blockchain_fair_sharing\|proof of blockchain fair sharing]]"] ...but as a teaser description: it's of proof-of-stake flavour [which makes me nervous in some ways, but that's another story], and it relies on the fact that stakeholders are '''pseudonymously trackable''', unlike proof-of-work contributors, and therefore a formula for blockchain height can reward '''closeness to fair-share proportions''' in such a way that a 90% attacker finds they can't stop the honest 10% contributing too-expensive-for-attacker-to-reverse blocks which, to the attacker's chagrin, '''incorporate''' the accumulated transactions the attacker has been endlessly reversing and re-excluding in an effort to ruin the credibility of Bitcoin. [And any change to the attacker's pseudonymous identity/identities destroys their bitcoin-days' stake and takes them out of the running as a big attacker for a long time.] - More to follow real soon now hopefully!)''

	''(To expand a little on the above teaser: One might think that by reductio ad absurdum '''no''' system can protect against a >50% attack, because in a purported proof of immunity of the honest <50% from the malicious >50%, the labels "honest" and "malicious" ultimately have no technical meaning, and so just swapping the labels would, absurdly, give a second proof, saying that the <50% community can't "attack" [i.e. save us all from] the >50% community, in contradiction to the first proof. That reductio argument is false here - '''there is an asymmetry''' between the two communities' goals, as follows. [I'm talking about an attack to destroy the usability of ~~bitcoin~~. An attack to achieve double spending is a much lower-impact event, the analysis of which I'm therefore postponing, although on general grounds the situation is probably neither especially better nor worse than with other protocols.] The >50% "community" [the attacker(s)] is trying to exclude transactions - perhaps all of them, perhaps those of specific people it wants to harass, perhaps random ones just to create fear that "I could be next" - from entering the winning blockchain. Thus it has to achieve '''total''' exclusion of the would-be blocks originating from the <50% community, who keep including the transactions to try and earn an honest profit from the fees. By contrast, the <50% community [the just-trying-to-earn-a-living honest miners] '''doesn't''' have to achieve exclusion of the attacker's blocks - they're happy with a mixed blockchain where, reasonably often, another honest block gets in and stays in. So long as they can get transactions bedded down into the blockchain, they've avoided the ruining of ~~bitcoin~~ as a usable system. It's this crucial asymmetry between the two communities which lets the honest miners win - a chain height formula which suitably rewards diversity of pseudonymous composition will stop even a 90% attacker "community" from achieving its, tougher, goal. I hope this indicates the general direction I'm headed. [[User:Ids\|Iain Stewart]] 02:15, 21 May 2012 (GMT))''		''(To expand a little on the above teaser: One might think that by reductio ad absurdum '''no''' system can protect against a >50% attack, because in a purported proof of immunity of the honest <50% from the malicious >50%, the labels "honest" and "malicious" ultimately have no technical meaning, and so just swapping the labels would, absurdly, give a second proof, saying that the <50% community can't "attack" [i.e. save us all from] the >50% community, in contradiction to the first proof. That reductio argument is false here - '''there is an asymmetry''' between the two communities' goals, as follows. [I'm talking about an attack to destroy the usability of Bitcoin. An attack to achieve double spending is a much lower-impact event, the analysis of which I'm therefore postponing, although on general grounds the situation is probably neither especially better nor worse than with other protocols.] The >50% "community" [the attacker(s)] is trying to exclude transactions - perhaps all of them, perhaps those of specific people it wants to harass, perhaps random ones just to create fear that "I could be next" - from entering the winning blockchain. Thus it has to achieve '''total''' exclusion of the would-be blocks originating from the <50% community, who keep including the transactions to try and earn an honest profit from the fees. By contrast, the <50% community [the just-trying-to-earn-a-living honest miners] '''doesn't''' have to achieve exclusion of the attacker's blocks - they're happy with a mixed blockchain where, reasonably often, another honest block gets in and stays in. So long as they can get transactions bedded down into the blockchain, they've avoided the ruining of Bitcoin as a usable system. It's this crucial asymmetry between the two communities which lets the honest miners win - a chain height formula which suitably rewards diversity of pseudonymous composition will stop even a 90% attacker "community" from achieving its, tougher, goal. I hope this indicates the general direction I'm headed. [[User:Ids\|Iain Stewart]] 02:15, 21 May 2012 (GMT))''

Ids: removed nonexistent talk page link, added automatically by the ~~~~ expansion

2012-11-24T22:27:11Z

removed nonexistent talk page link, added automatically by the ~~~~ expansion

← Older revision		Revision as of 22:27, 24 November 2012
Line 1:		Line 1:
	'''Adaptive difficulty''' is a bitcoin protocol change proposal by [[User:Ids\|Iain Stewart]], with the goal of letting the typical time interval from one block to the next adjust smoothly to prevailing network latency, while not compromising the strength of the blockchain, or the decentralized character of the network.		'''Adaptive difficulty''' is a bitcoin protocol change proposal by [[User:Ids\|Iain Stewart]], with the goal of letting the typical time interval from one block to the next adjust smoothly to prevailing network latency, while not compromising the strength of the blockchain, or the decentralized character of the network.

	'''''EDIT 2012-11-22:''' My idea is essentially the same as that proposed by [http://en.wikipedia.org/wiki/User:Meni_Rosenfeld Meni Rosenfeld] on the [https://bitcointalk.org/index.php?board=6.0 Bitcoin forums]. Please read and enjoy and critique [https://bitcointalk.org/index.php?topic=79837.0 his adaptive difficulty proposal]! (I'll leave this page here for historical completeness, but not continue working on it.) [[User:Ids\|Iain Stewart]] ~~([[User talk:Ids\|talk]])~~ 01:00, 23 November 2012 (GMT)''		'''''EDIT 2012-11-22:''' My idea is essentially the same as that proposed by [http://en.wikipedia.org/wiki/User:Meni_Rosenfeld Meni Rosenfeld] on the [https://bitcointalk.org/index.php?board=6.0 Bitcoin forums]. Please read and enjoy and critique [https://bitcointalk.org/index.php?topic=79837.0 his adaptive difficulty proposal]! (I'll leave this page here for historical completeness, but not continue working on it.) [[User:Ids\|Iain Stewart]] 01:00, 23 November 2012 (GMT)''

	== Background ==		== Background ==

Ids: changed forum link to development and technical discussion sub-forum, rather than top-level

2012-11-23T01:06:20Z

changed forum link to development and technical discussion sub-forum, rather than top-level

← Older revision		Revision as of 01:06, 23 November 2012
Line 1:		Line 1:
	'''Adaptive difficulty''' is a bitcoin protocol change proposal by [[User:Ids\|Iain Stewart]], with the goal of letting the typical time interval from one block to the next adjust smoothly to prevailing network latency, while not compromising the strength of the blockchain, or the decentralized character of the network.		'''Adaptive difficulty''' is a bitcoin protocol change proposal by [[User:Ids\|Iain Stewart]], with the goal of letting the typical time interval from one block to the next adjust smoothly to prevailing network latency, while not compromising the strength of the blockchain, or the decentralized character of the network.

	'''''EDIT 2012-11-22:''' My idea is essentially the same as that proposed by [http://en.wikipedia.org/wiki/User:Meni_Rosenfeld Meni Rosenfeld] on the [https://bitcointalk.org/ Bitcoin forums]. Please read and enjoy and critique [https://bitcointalk.org/index.php?topic=79837.0 his adaptive difficulty proposal]! (I'll leave this page here for historical completeness, but not continue working on it.) [[User:Ids\|Iain Stewart]] ([[User talk:Ids\|talk]]) 01:00, 23 November 2012 (GMT)''		'''''EDIT 2012-11-22:''' My idea is essentially the same as that proposed by [http://en.wikipedia.org/wiki/User:Meni_Rosenfeld Meni Rosenfeld] on the [https://bitcointalk.org/index.php?board=6.0 Bitcoin forums]. Please read and enjoy and critique [https://bitcointalk.org/index.php?topic=79837.0 his adaptive difficulty proposal]! (I'll leave this page here for historical completeness, but not continue working on it.) [[User:Ids\|Iain Stewart]] ([[User talk:Ids\|talk]]) 01:00, 23 November 2012 (GMT)''

	== Background ==		== Background ==

Ids: layout

2012-11-23T01:01:40Z

layout

← Older revision		Revision as of 01:01, 23 November 2012
Line 1:		Line 1:
	'''Adaptive difficulty''' is a bitcoin protocol change proposal by [[User:Ids\|Iain Stewart]], with the goal of letting the typical time interval from one block to the next adjust smoothly to prevailing network latency, while not compromising the strength of the blockchain, or the decentralized character of the network.		'''Adaptive difficulty''' is a bitcoin protocol change proposal by [[User:Ids\|Iain Stewart]], with the goal of letting the typical time interval from one block to the next adjust smoothly to prevailing network latency, while not compromising the strength of the blockchain, or the decentralized character of the network.

	'''''EDIT 2012-11-22:''' My idea is essentially the same as that proposed by [http://en.wikipedia.org/wiki/User:Meni_Rosenfeld Meni Rosenfeld] on the [https://bitcointalk.org/ Bitcoin forums]. Please read and enjoy and critique [https://bitcointalk.org/index.php?topic=79837.0 his adaptive difficulty proposal]! (I'll leave this page here for historical completeness, but not continue working on it.)[[User:Ids\|Iain Stewart]] ([[User talk:Ids\|talk]]) 01:00, 23 November 2012 (GMT)''		'''''EDIT 2012-11-22:''' My idea is essentially the same as that proposed by [http://en.wikipedia.org/wiki/User:Meni_Rosenfeld Meni Rosenfeld] on the [https://bitcointalk.org/ Bitcoin forums]. Please read and enjoy and critique [https://bitcointalk.org/index.php?topic=79837.0 his adaptive difficulty proposal]! (I'll leave this page here for historical completeness, but not continue working on it.) [[User:Ids\|Iain Stewart]] ([[User talk:Ids\|talk]]) 01:00, 23 November 2012 (GMT)''

	== Background ==		== Background ==

Ids: advertised Meni Rosenfeld's proposal, now that I see how similar our ideas are!

2012-11-23T01:00:15Z

advertised Meni Rosenfeld's proposal, now that I see how similar our ideas are!

← Older revision		Revision as of 01:00, 23 November 2012
Line 1:		Line 1:
	'''Adaptive difficulty''' is a bitcoin protocol change proposal by [[User:Ids\|Iain Stewart]], with the goal of letting the typical time interval from one block to the next adjust smoothly to prevailing network latency, while not compromising the strength of the blockchain, or the decentralized character of the network.		'''Adaptive difficulty''' is a bitcoin protocol change proposal by [[User:Ids\|Iain Stewart]], with the goal of letting the typical time interval from one block to the next adjust smoothly to prevailing network latency, while not compromising the strength of the blockchain, or the decentralized character of the network.

			'''''EDIT 2012-11-22:''' My idea is essentially the same as that proposed by [http://en.wikipedia.org/wiki/User:Meni_Rosenfeld Meni Rosenfeld] on the [https://bitcointalk.org/ Bitcoin forums]. Please read and enjoy and critique [https://bitcointalk.org/index.php?topic=79837.0 his adaptive difficulty proposal]! (I'll leave this page here for historical completeness, but not continue working on it.)[[User:Ids\|Iain Stewart]] ([[User talk:Ids\|talk]]) 01:00, 23 November 2012 (GMT)''

	== Background ==		== Background ==

Ids: /* ...and now for something completely different! (unpolished teaser for now...) */ made it clear I'm fully aware p.o.b.f.s. is hopelessly unfinished

2012-08-07T23:06:12Z

...and now for something completely different! (unpolished teaser for now...): made it clear I'm fully aware p.o.b.f.s. is hopelessly unfinished

← Older revision		Revision as of 23:06, 7 August 2012
Line 29:		Line 29:
	== ''...and now for something completely different! (unpolished teaser for now...)'' ==		== ''...and now for something completely different! (unpolished teaser for now...)'' ==

	''(Just to explain - I'm neglecting this adaptive difficulty stuff for a while [sorry!] because I '''seem''' to have almost accidentally invented a different system which protects against even a '''considerably-greater-than-50% attack'''! I don't want to create a page on it just yet before I thoroughly check that I'm not making a fool of myself... [well, I'll allow myself a stub, as a home for this teaser stuff: "[[Proof_of_blockchain_fair_sharing\|proof of blockchain fair sharing]]"] ...but as a teaser description: it's of proof-of-stake flavour [which makes me nervous in some ways, but that's another story], and it relies on the fact that stakeholders are '''pseudonymously trackable''', unlike proof-of-work contributors, and therefore a formula for blockchain height can reward '''closeness to fair-share proportions''' in such a way that a 90% attacker finds they can't stop the honest 10% contributing too-expensive-for-attacker-to-reverse blocks which, to the attacker's chagrin, '''incorporate''' the accumulated transactions the attacker has been endlessly reversing and re-excluding in an effort to ruin the credibility of bitcoin. [And any change to the attacker's pseudonymous identity/identities destroys their bitcoin-days' stake and takes them out of the running as a big attacker for a long time.] - More to follow real soon now hopefully!)''		''(Just to explain - I'm neglecting this adaptive difficulty stuff for a while [sorry!] because I '''seem''' to have almost accidentally invented [the bare beginnings of] a different system which protects against even a '''considerably-greater-than-50% attack'''! I don't want to create a page on it just yet before I thoroughly check that I'm not making a fool of myself... [well, I'll allow myself a stub, as a home for this teaser stuff: "[[Proof_of_blockchain_fair_sharing\|proof of blockchain fair sharing]]"] ...but as a teaser description: it's of proof-of-stake flavour [which makes me nervous in some ways, but that's another story], and it relies on the fact that stakeholders are '''pseudonymously trackable''', unlike proof-of-work contributors, and therefore a formula for blockchain height can reward '''closeness to fair-share proportions''' in such a way that a 90% attacker finds they can't stop the honest 10% contributing too-expensive-for-attacker-to-reverse blocks which, to the attacker's chagrin, '''incorporate''' the accumulated transactions the attacker has been endlessly reversing and re-excluding in an effort to ruin the credibility of bitcoin. [And any change to the attacker's pseudonymous identity/identities destroys their bitcoin-days' stake and takes them out of the running as a big attacker for a long time.] - More to follow real soon now hopefully!)''

	''(To expand a little on the above teaser: One might think that by reductio ad absurdum '''no''' system can protect against a >50% attack, because in a purported proof of immunity of the honest <50% from the malicious >50%, the labels "honest" and "malicious" ultimately have no technical meaning, and so just swapping the labels would, absurdly, give a second proof, saying that the <50% community can't "attack" [i.e. save us all from] the >50% community, in contradiction to the first proof. That reductio argument is false here - '''there is an asymmetry''' between the two communities' goals, as follows. [I'm talking about an attack to destroy the usability of bitcoin. An attack to achieve double spending is a much lower-impact event, the analysis of which I'm therefore postponing, although on general grounds the situation is probably neither especially better nor worse than with other protocols.] The >50% "community" [the attacker(s)] is trying to exclude transactions - perhaps all of them, perhaps those of specific people it wants to harass, perhaps random ones just to create fear that "I could be next" - from entering the winning blockchain. Thus it has to achieve '''total''' exclusion of the would-be blocks originating from the <50% community, who keep including the transactions to try and earn an honest profit from the fees. By contrast, the <50% community [the just-trying-to-earn-a-living honest miners] '''doesn't''' have to achieve exclusion of the attacker's blocks - they're happy with a mixed blockchain where, reasonably often, another honest block gets in and stays in. So long as they can get transactions bedded down into the blockchain, they've avoided the ruining of bitcoin as a usable system. It's this crucial asymmetry between the two communities which lets the honest miners win - a chain height formula which suitably rewards diversity of pseudonymous composition will stop even a 90% attacker "community" from achieving its, tougher, goal. I hope this indicates the general direction I'm headed. [[User:Ids\|Iain Stewart]] 02:15, 21 May 2012 (GMT))''		''(To expand a little on the above teaser: One might think that by reductio ad absurdum '''no''' system can protect against a >50% attack, because in a purported proof of immunity of the honest <50% from the malicious >50%, the labels "honest" and "malicious" ultimately have no technical meaning, and so just swapping the labels would, absurdly, give a second proof, saying that the <50% community can't "attack" [i.e. save us all from] the >50% community, in contradiction to the first proof. That reductio argument is false here - '''there is an asymmetry''' between the two communities' goals, as follows. [I'm talking about an attack to destroy the usability of bitcoin. An attack to achieve double spending is a much lower-impact event, the analysis of which I'm therefore postponing, although on general grounds the situation is probably neither especially better nor worse than with other protocols.] The >50% "community" [the attacker(s)] is trying to exclude transactions - perhaps all of them, perhaps those of specific people it wants to harass, perhaps random ones just to create fear that "I could be next" - from entering the winning blockchain. Thus it has to achieve '''total''' exclusion of the would-be blocks originating from the <50% community, who keep including the transactions to try and earn an honest profit from the fees. By contrast, the <50% community [the just-trying-to-earn-a-living honest miners] '''doesn't''' have to achieve exclusion of the attacker's blocks - they're happy with a mixed blockchain where, reasonably often, another honest block gets in and stays in. So long as they can get transactions bedded down into the blockchain, they've avoided the ruining of bitcoin as a usable system. It's this crucial asymmetry between the two communities which lets the honest miners win - a chain height formula which suitably rewards diversity of pseudonymous composition will stop even a 90% attacker "community" from achieving its, tougher, goal. I hope this indicates the general direction I'm headed. [[User:Ids\|Iain Stewart]] 02:15, 21 May 2012 (GMT))''

Ids: /* ...and now for something completely different! (unpolished teaser for now...) */ advertised "proof of blockchain fair sharing" page (stub/teaser for now)

2012-05-21T10:57:35Z

...and now for something completely different! (unpolished teaser for now...): advertised "proof of blockchain fair sharing" page (stub/teaser for now)

← Older revision		Revision as of 10:57, 21 May 2012
Line 29:		Line 29:
	== ''...and now for something completely different! (unpolished teaser for now...)'' ==		== ''...and now for something completely different! (unpolished teaser for now...)'' ==

	''(Just to explain - I'm neglecting this adaptive difficulty stuff for a while [sorry!] because I '''seem''' to have almost accidentally invented a different system which protects against even a '''considerably-greater-than-50% attack'''! I don't want to create a page on it just yet before I thoroughly check that I'm not making a fool of myself... but as a teaser description: it's of proof-of-stake flavour [which makes me nervous in some ways, but that's another story], and it relies on the fact that stakeholders are '''pseudonymously trackable''', unlike proof-of-work contributors, and therefore a formula for blockchain height can reward '''closeness to fair-share proportions''' in such a way that a 90% attacker finds they can't stop the honest 10% contributing too-expensive-for-attacker-to-reverse blocks which, to the attacker's chagrin, '''incorporate''' the accumulated transactions the attacker has been endlessly reversing and re-excluding in an effort to ruin the credibility of bitcoin. [And any change to the attacker's pseudonymous identity/identities destroys their bitcoin-days' stake and takes them out of the running as a big attacker for a long time.] - More to follow real soon now hopefully!)''		''(Just to explain - I'm neglecting this adaptive difficulty stuff for a while [sorry!] because I '''seem''' to have almost accidentally invented a different system which protects against even a '''considerably-greater-than-50% attack'''! I don't want to create a page on it just yet before I thoroughly check that I'm not making a fool of myself... [well, I'll allow myself a stub, as a home for this teaser stuff: "[[Proof_of_blockchain_fair_sharing\|proof of blockchain fair sharing]]"] ...but as a teaser description: it's of proof-of-stake flavour [which makes me nervous in some ways, but that's another story], and it relies on the fact that stakeholders are '''pseudonymously trackable''', unlike proof-of-work contributors, and therefore a formula for blockchain height can reward '''closeness to fair-share proportions''' in such a way that a 90% attacker finds they can't stop the honest 10% contributing too-expensive-for-attacker-to-reverse blocks which, to the attacker's chagrin, '''incorporate''' the accumulated transactions the attacker has been endlessly reversing and re-excluding in an effort to ruin the credibility of bitcoin. [And any change to the attacker's pseudonymous identity/identities destroys their bitcoin-days' stake and takes them out of the running as a big attacker for a long time.] - More to follow real soon now hopefully!)''

	''(To expand a little on the above teaser: One might think that by reductio ad absurdum '''no''' system can protect against a >50% attack, because in a purported proof of immunity of the honest <50% from the malicious >50%, the labels "honest" and "malicious" ultimately have no technical meaning, and so just swapping the labels would, absurdly, give a second proof, saying that the <50% community can't "attack" [i.e. save us all from] the >50% community, in contradiction to the first proof. That reductio argument is false here - '''there is an asymmetry''' between the two communities' goals, as follows. [I'm talking about an attack to destroy the usability of bitcoin. An attack to achieve double spending is a much lower-impact event, the analysis of which I'm therefore postponing, although on general grounds the situation is probably neither especially better nor worse than with other protocols.] The >50% "community" [the attacker(s)] is trying to exclude transactions - perhaps all of them, perhaps those of specific people it wants to harass, perhaps random ones just to create fear that "I could be next" - from entering the winning blockchain. Thus it has to achieve '''total''' exclusion of the would-be blocks originating from the <50% community, who keep including the transactions to try and earn an honest profit from the fees. By contrast, the <50% community [the just-trying-to-earn-a-living honest miners] '''doesn't''' have to achieve exclusion of the attacker's blocks - they're happy with a mixed blockchain where, reasonably often, another honest block gets in and stays in. So long as they can get transactions bedded down into the blockchain, they've avoided the ruining of bitcoin as a usable system. It's this crucial asymmetry between the two communities which lets the honest miners win - a chain height formula which suitably rewards diversity of pseudonymous composition will stop even a 90% attacker "community" from achieving its, tougher, goal. I hope this indicates the general direction I'm headed. [[User:Ids\|Iain Stewart]] 02:15, 21 May 2012 (GMT))''		''(To expand a little on the above teaser: One might think that by reductio ad absurdum '''no''' system can protect against a >50% attack, because in a purported proof of immunity of the honest <50% from the malicious >50%, the labels "honest" and "malicious" ultimately have no technical meaning, and so just swapping the labels would, absurdly, give a second proof, saying that the <50% community can't "attack" [i.e. save us all from] the >50% community, in contradiction to the first proof. That reductio argument is false here - '''there is an asymmetry''' between the two communities' goals, as follows. [I'm talking about an attack to destroy the usability of bitcoin. An attack to achieve double spending is a much lower-impact event, the analysis of which I'm therefore postponing, although on general grounds the situation is probably neither especially better nor worse than with other protocols.] The >50% "community" [the attacker(s)] is trying to exclude transactions - perhaps all of them, perhaps those of specific people it wants to harass, perhaps random ones just to create fear that "I could be next" - from entering the winning blockchain. Thus it has to achieve '''total''' exclusion of the would-be blocks originating from the <50% community, who keep including the transactions to try and earn an honest profit from the fees. By contrast, the <50% community [the just-trying-to-earn-a-living honest miners] '''doesn't''' have to achieve exclusion of the attacker's blocks - they're happy with a mixed blockchain where, reasonably often, another honest block gets in and stays in. So long as they can get transactions bedded down into the blockchain, they've avoided the ruining of bitcoin as a usable system. It's this crucial asymmetry between the two communities which lets the honest miners win - a chain height formula which suitably rewards diversity of pseudonymous composition will stop even a 90% attacker "community" from achieving its, tougher, goal. I hope this indicates the general direction I'm headed. [[User:Ids\|Iain Stewart]] 02:15, 21 May 2012 (GMT))''

Ids: /* ...and now for something completely different! (unpolished teaser for now...) */ explicit postponement, with apologia, of double-spending attack analysis

2012-05-21T10:44:46Z

...and now for something completely different! (unpolished teaser for now...): explicit postponement, with apologia, of double-spending attack analysis

← Older revision		Revision as of 10:44, 21 May 2012
Line 31:		Line 31:
	''(Just to explain - I'm neglecting this adaptive difficulty stuff for a while [sorry!] because I '''seem''' to have almost accidentally invented a different system which protects against even a '''considerably-greater-than-50% attack'''! I don't want to create a page on it just yet before I thoroughly check that I'm not making a fool of myself... but as a teaser description: it's of proof-of-stake flavour [which makes me nervous in some ways, but that's another story], and it relies on the fact that stakeholders are '''pseudonymously trackable''', unlike proof-of-work contributors, and therefore a formula for blockchain height can reward '''closeness to fair-share proportions''' in such a way that a 90% attacker finds they can't stop the honest 10% contributing too-expensive-for-attacker-to-reverse blocks which, to the attacker's chagrin, '''incorporate''' the accumulated transactions the attacker has been endlessly reversing and re-excluding in an effort to ruin the credibility of bitcoin. [And any change to the attacker's pseudonymous identity/identities destroys their bitcoin-days' stake and takes them out of the running as a big attacker for a long time.] - More to follow real soon now hopefully!)''		''(Just to explain - I'm neglecting this adaptive difficulty stuff for a while [sorry!] because I '''seem''' to have almost accidentally invented a different system which protects against even a '''considerably-greater-than-50% attack'''! I don't want to create a page on it just yet before I thoroughly check that I'm not making a fool of myself... but as a teaser description: it's of proof-of-stake flavour [which makes me nervous in some ways, but that's another story], and it relies on the fact that stakeholders are '''pseudonymously trackable''', unlike proof-of-work contributors, and therefore a formula for blockchain height can reward '''closeness to fair-share proportions''' in such a way that a 90% attacker finds they can't stop the honest 10% contributing too-expensive-for-attacker-to-reverse blocks which, to the attacker's chagrin, '''incorporate''' the accumulated transactions the attacker has been endlessly reversing and re-excluding in an effort to ruin the credibility of bitcoin. [And any change to the attacker's pseudonymous identity/identities destroys their bitcoin-days' stake and takes them out of the running as a big attacker for a long time.] - More to follow real soon now hopefully!)''

	''(To expand a little on the above teaser: One might think that by reductio ad absurdum '''no''' system can protect against a >50% attack, because in a purported proof of immunity of the honest <50% from the malicious >50%, the labels "honest" and "malicious" ultimately have no technical meaning, and so just swapping the labels would, absurdly, give a second proof, saying that the <50% community can't "attack" [i.e. save us all from] the >50% community, in contradiction to the first proof. That reductio argument is false here - '''there is an asymmetry''' between the two communities' goals, as follows. [I'm talking about an attack to destroy the usability of bitcoin. An attack to achieve double spending is ~~already not~~ a ~~plausible motive~~.] The >50% "community" [the attacker(s)] is trying to exclude transactions - perhaps all of them, perhaps those of specific people it wants to harass, perhaps random ones just to create fear that "I could be next" - from entering the winning blockchain. Thus it has to achieve '''total''' exclusion of the would-be blocks originating from the <50% community, who keep including the transactions to try and earn an honest profit from the fees. By contrast, the <50% community [the just-trying-to-earn-a-living honest miners] '''doesn't''' have to achieve exclusion of the attacker's blocks - they're happy with a mixed blockchain where, reasonably often, another honest block gets in and stays in. So long as they can get transactions bedded down into the blockchain, they've avoided the ruining of bitcoin as a usable system. It's this crucial asymmetry between the two communities which lets the honest miners win - a chain height formula which suitably rewards diversity of pseudonymous composition will stop even a 90% attacker "community" from achieving its, tougher, goal. I hope this indicates the general direction I'm headed. [[User:Ids\|Iain Stewart]] 02:15, 21 May 2012 (GMT))''		''(To expand a little on the above teaser: One might think that by reductio ad absurdum '''no''' system can protect against a >50% attack, because in a purported proof of immunity of the honest <50% from the malicious >50%, the labels "honest" and "malicious" ultimately have no technical meaning, and so just swapping the labels would, absurdly, give a second proof, saying that the <50% community can't "attack" [i.e. save us all from] the >50% community, in contradiction to the first proof. That reductio argument is false here - '''there is an asymmetry''' between the two communities' goals, as follows. [I'm talking about an attack to destroy the usability of bitcoin. An attack to achieve double spending is a much lower-impact event, the analysis of which I'm therefore postponing, although on general grounds the situation is probably neither especially better nor worse than with other protocols.] The >50% "community" [the attacker(s)] is trying to exclude transactions - perhaps all of them, perhaps those of specific people it wants to harass, perhaps random ones just to create fear that "I could be next" - from entering the winning blockchain. Thus it has to achieve '''total''' exclusion of the would-be blocks originating from the <50% community, who keep including the transactions to try and earn an honest profit from the fees. By contrast, the <50% community [the just-trying-to-earn-a-living honest miners] '''doesn't''' have to achieve exclusion of the attacker's blocks - they're happy with a mixed blockchain where, reasonably often, another honest block gets in and stays in. So long as they can get transactions bedded down into the blockchain, they've avoided the ruining of bitcoin as a usable system. It's this crucial asymmetry between the two communities which lets the honest miners win - a chain height formula which suitably rewards diversity of pseudonymous composition will stop even a 90% attacker "community" from achieving its, tougher, goal. I hope this indicates the general direction I'm headed. [[User:Ids\|Iain Stewart]] 02:15, 21 May 2012 (GMT))''

Ids: /* ...and now for something completely different! (unpolished teaser for now...) */ crisper, clearer wordings in places

2012-05-21T07:01:05Z

...and now for something completely different! (unpolished teaser for now...): crisper, clearer wordings in places

← Older revision		Revision as of 07:01, 21 May 2012
Line 29:		Line 29:
	== ''...and now for something completely different! (unpolished teaser for now...)'' ==		== ''...and now for something completely different! (unpolished teaser for now...)'' ==

	''(~~just~~ to explain - I'm neglecting this adaptive difficulty stuff for a while [sorry!] because I '''seem''' to have almost accidentally invented a different system which protects against even a '''considerably-greater-than-50% attack'''! I don't want to create a page on it just yet before I thoroughly check that I'm not making a fool of myself... but as a teaser description: it's of proof-of-stake flavour [which makes me nervous in some ways, but that's another story], and it relies on the fact that stakeholders are '''pseudonymously trackable''', unlike proof-of-work contributors, and therefore a formula for blockchain height can reward '''closeness to fair-share proportions''' in such a way that a 90% attacker finds they can't stop the honest 10% contributing too-expensive-for-attacker-to-reverse blocks which, to the attacker's chagrin, '''incorporate''' the accumulated transactions the attacker has been endlessly reversing and re-excluding in an effort to ruin the credibility of bitcoin. [And any change to the attacker's pseudonymous identity/identities destroys their bitcoin-days' stake and takes them out of the running as a big attacker for a long time.] - ~~There! That'll have to do for now!~~ More to follow real soon now hopefully!)''		''(Just to explain - I'm neglecting this adaptive difficulty stuff for a while [sorry!] because I '''seem''' to have almost accidentally invented a different system which protects against even a '''considerably-greater-than-50% attack'''! I don't want to create a page on it just yet before I thoroughly check that I'm not making a fool of myself... but as a teaser description: it's of proof-of-stake flavour [which makes me nervous in some ways, but that's another story], and it relies on the fact that stakeholders are '''pseudonymously trackable''', unlike proof-of-work contributors, and therefore a formula for blockchain height can reward '''closeness to fair-share proportions''' in such a way that a 90% attacker finds they can't stop the honest 10% contributing too-expensive-for-attacker-to-reverse blocks which, to the attacker's chagrin, '''incorporate''' the accumulated transactions the attacker has been endlessly reversing and re-excluding in an effort to ruin the credibility of bitcoin. [And any change to the attacker's pseudonymous identity/identities destroys their bitcoin-days' stake and takes them out of the running as a big attacker for a long time.] - More to follow real soon now hopefully!)''

	''(to expand a little on the above teaser ~~- yeah, I know, this is becoming something of a page-within-a-page, but I don't feel ready to give it a page of its own yet~~: ~~one~~ might think that by reductio ad absurdum '''no''' system can protect against a >50% attack, because the labels "honest" and "malicious" ultimately have no technical meaning, and so just swapping the labels would, absurdly, give a second proof, saying that the <50% community can't "attack" [i.e. save us all from] the >50% community, in contradiction to the first proof. ~~This~~ is ~~not so. The~~ asymmetry is as follows. [I'm talking about an attack to destroy the usability of bitcoin. An attack to achieve double spending is already not a plausible motive.] The >50% "community" [the attacker(s)] is trying to exclude transactions - perhaps all of them, perhaps those of specific people it wants to harass, perhaps random ones just to create fear that "~~gosh,~~ I could be next" - from entering the winning blockchain. Thus it has to achieve '''total''' exclusion of the would-be blocks originating from the <50% community, who keep including the transactions to try and earn an honest profit from the fees. By contrast, the <50% community [the just-trying-to-earn-a-living honest miners] '''doesn't''' have to achieve exclusion of the attacker's blocks - they're happy with a mixed blockchain where, reasonably often, another honest block gets in and stays in. So long as they can get transactions bedded down into the blockchain, they've avoided the ruining of bitcoin as a usable system. It's this crucial asymmetry between the two communities which lets the honest miners win - a chain height formula which suitably rewards diversity of pseudonymous composition will stop even a 90% attacker "community" from achieving its, tougher, goal. I hope this indicates the general direction I'm headed. [[User:Ids\|Iain Stewart]] 02:15, 21 May 2012 (GMT))''		''(To expand a little on the above teaser: One might think that by reductio ad absurdum '''no''' system can protect against a >50% attack, because in a purported proof of immunity of the honest <50% from the malicious >50%, the labels "honest" and "malicious" ultimately have no technical meaning, and so just swapping the labels would, absurdly, give a second proof, saying that the <50% community can't "attack" [i.e. save us all from] the >50% community, in contradiction to the first proof. That reductio argument is false here - '''there is an asymmetry''' between the two communities' goals, as follows. [I'm talking about an attack to destroy the usability of bitcoin. An attack to achieve double spending is already not a plausible motive.] The >50% "community" [the attacker(s)] is trying to exclude transactions - perhaps all of them, perhaps those of specific people it wants to harass, perhaps random ones just to create fear that "I could be next" - from entering the winning blockchain. Thus it has to achieve '''total''' exclusion of the would-be blocks originating from the <50% community, who keep including the transactions to try and earn an honest profit from the fees. By contrast, the <50% community [the just-trying-to-earn-a-living honest miners] '''doesn't''' have to achieve exclusion of the attacker's blocks - they're happy with a mixed blockchain where, reasonably often, another honest block gets in and stays in. So long as they can get transactions bedded down into the blockchain, they've avoided the ruining of bitcoin as a usable system. It's this crucial asymmetry between the two communities which lets the honest miners win - a chain height formula which suitably rewards diversity of pseudonymous composition will stop even a 90% attacker "community" from achieving its, tougher, goal. I hope this indicates the general direction I'm headed. [[User:Ids\|Iain Stewart]] 02:15, 21 May 2012 (GMT))''

Ids: /* ...and now for something completely different! (unpolished teaser for now...) */ wording tweak

2012-05-21T06:45:00Z

...and now for something completely different! (unpolished teaser for now...): wording tweak

← Older revision		Revision as of 06:45, 21 May 2012
Line 31:		Line 31:
	''(just to explain - I'm neglecting this adaptive difficulty stuff for a while [sorry!] because I '''seem''' to have almost accidentally invented a different system which protects against even a '''considerably-greater-than-50% attack'''! I don't want to create a page on it just yet before I thoroughly check that I'm not making a fool of myself... but as a teaser description: it's of proof-of-stake flavour [which makes me nervous in some ways, but that's another story], and it relies on the fact that stakeholders are '''pseudonymously trackable''', unlike proof-of-work contributors, and therefore a formula for blockchain height can reward '''closeness to fair-share proportions''' in such a way that a 90% attacker finds they can't stop the honest 10% contributing too-expensive-for-attacker-to-reverse blocks which, to the attacker's chagrin, '''incorporate''' the accumulated transactions the attacker has been endlessly reversing and re-excluding in an effort to ruin the credibility of bitcoin. [And any change to the attacker's pseudonymous identity/identities destroys their bitcoin-days' stake and takes them out of the running as a big attacker for a long time.] - There! That'll have to do for now! More to follow real soon now hopefully!)''		''(just to explain - I'm neglecting this adaptive difficulty stuff for a while [sorry!] because I '''seem''' to have almost accidentally invented a different system which protects against even a '''considerably-greater-than-50% attack'''! I don't want to create a page on it just yet before I thoroughly check that I'm not making a fool of myself... but as a teaser description: it's of proof-of-stake flavour [which makes me nervous in some ways, but that's another story], and it relies on the fact that stakeholders are '''pseudonymously trackable''', unlike proof-of-work contributors, and therefore a formula for blockchain height can reward '''closeness to fair-share proportions''' in such a way that a 90% attacker finds they can't stop the honest 10% contributing too-expensive-for-attacker-to-reverse blocks which, to the attacker's chagrin, '''incorporate''' the accumulated transactions the attacker has been endlessly reversing and re-excluding in an effort to ruin the credibility of bitcoin. [And any change to the attacker's pseudonymous identity/identities destroys their bitcoin-days' stake and takes them out of the running as a big attacker for a long time.] - There! That'll have to do for now! More to follow real soon now hopefully!)''

	''(to expand a little on the above teaser - yeah, I know, this is becoming something of a page-within-a-page, but I don't feel ready to give it a page of its own yet: one might think that by reductio ad absurdum '''no''' system can protect against a >50% attack, because the labels "honest" and "malicious" ultimately have no technical meaning, and so just swapping the labels would, absurdly, give a second proof, saying that the <50% community can't "attack" [i.e. save us all from] the >50% community, in contradiction to the first proof. This is not so. The asymmetry is as follows. [I'm talking about an attack to destroy the usability of bitcoin. An attack to achieve double spending is already not a plausible motive.] The >50% "community" [the attacker(s)] is trying to exclude transactions - perhaps all of them, perhaps those of specific people it wants to harass, perhaps random ones just to create fear that "gosh, I could be next" - from entering the winning blockchain. Thus it has to achieve '''total''' exclusion of the would-be blocks originating from the <50% community, who keep including the transactions to try and earn an honest profit from the fees. By contrast, the <50% community [the just-trying-to-earn-a-living honest miners] '''doesn't''' have to achieve exclusion of the attacker's blocks - they're happy with a mixed blockchain where another honest block gets in and stays in ~~reasonably often~~. So long as they can get transactions bedded down into the blockchain, they've avoided the ruining of bitcoin as a usable system. It's this crucial asymmetry between the two communities which lets the honest miners win - a chain height formula which suitably rewards diversity of pseudonymous composition will stop even a 90% attacker "community" from achieving its, tougher, goal. I hope this indicates the general direction I'm headed. [[User:Ids\|Iain Stewart]] 02:15, 21 May 2012 (GMT))''		''(to expand a little on the above teaser - yeah, I know, this is becoming something of a page-within-a-page, but I don't feel ready to give it a page of its own yet: one might think that by reductio ad absurdum '''no''' system can protect against a >50% attack, because the labels "honest" and "malicious" ultimately have no technical meaning, and so just swapping the labels would, absurdly, give a second proof, saying that the <50% community can't "attack" [i.e. save us all from] the >50% community, in contradiction to the first proof. This is not so. The asymmetry is as follows. [I'm talking about an attack to destroy the usability of bitcoin. An attack to achieve double spending is already not a plausible motive.] The >50% "community" [the attacker(s)] is trying to exclude transactions - perhaps all of them, perhaps those of specific people it wants to harass, perhaps random ones just to create fear that "gosh, I could be next" - from entering the winning blockchain. Thus it has to achieve '''total''' exclusion of the would-be blocks originating from the <50% community, who keep including the transactions to try and earn an honest profit from the fees. By contrast, the <50% community [the just-trying-to-earn-a-living honest miners] '''doesn't''' have to achieve exclusion of the attacker's blocks - they're happy with a mixed blockchain where, reasonably often, another honest block gets in and stays in. So long as they can get transactions bedded down into the blockchain, they've avoided the ruining of bitcoin as a usable system. It's this crucial asymmetry between the two communities which lets the honest miners win - a chain height formula which suitably rewards diversity of pseudonymous composition will stop even a 90% attacker "community" from achieving its, tougher, goal. I hope this indicates the general direction I'm headed. [[User:Ids\|Iain Stewart]] 02:15, 21 May 2012 (GMT))''