đź“… Original date posted:2016-05-11
đź“ť Original message:There is no way to tell from a block if it was mined with AsicBoost or not.
So you don’t know what percentage of the hashrate uses AsicBoost at any
point in time. How can you risk forking that percentage out? Note that this
would be a GUARANTEED chain fork. Meaning that after you change the block
mining algorithm some percentage of hardware will no longer be able to
produce valid blocks. That hardware cannot “switch over” to the majority
chain even if it wanted to. Hence you are guaranteed to have two
co-existing bitcoin blockchains afterwards.
Again: this is unlike the hypothetical persistence of two chains after a
hardfork that is only contentious but doesn’t change the mining algorithm,
the kind of hardfork you are proposing would guarantee the persistence of
two chains.
Note that “AsicBoost” above is replaceable with “optimization X”. It’s
simply a logical argument: If you want to make optimization X impossible
and someone is already using optimization X you end up with two chains. So
unless you know exactly which optimizations are in use (and therefore also
know which ones are not in use) you can’t make these kind of changes.
AsicBoost is known at least since middle of 2013.
To be more precise, if you change the block validation ruleset R to block
validation ruleset S you have to make sure that every hardware that was
capable of mining R-valid blocks is also capable of mining S-valid blocks.
The problem is that chip manufacturers will not tell you which
optimizations they use. You would have to threaten to irreversibly fork
their hardware out by a rule change, only then would they start shouting
and reveal their optimization. It seems extremely dangerous to set the
precedence of a hardfork that irreversibly forks out a certain type of
mining hardware.
The part "Also the fix should be compatible with existing mining hardware."
is impossible to achieve because it's unclear what "existing mining
hardware" is. There has never been a specification of what mining hardware
should do. There are only acceptance rules.
The only way out is to go the exact opposite way and to embrace as many
optimizations as possible to the point where there are no more
optimizations left to do, or hopefully getting very close to that point.
Timo
On Tue, May 10, 2016 at 11:57 AM, Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> As part of the hard-fork proposed in the HK agreement(1) we'd like to make
> the
> patented AsicBoost optimisation useless, and hopefully make further similar
> optimizations useless as well.
>
> What's the best way to do this? Ideally this would be SPV compatible, but
> if it
> requires changes from SPV clients that's ok too. Also the fix this should
> be
> compatible with existing mining hardware.
>
>
> 1)
> https://medium.com/@bitcoinroundtable/bitcoin-roundtable-consensus-266d475a61ff
>
> 2)
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-April/012596.html
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160510/26eb0bad/attachment.html>;
Timo Hanke [ARCHIVE] /
npub1dd…pgp9a
2023-06-07 17:50:34
in reply to nevent1q…j5ep
Author Public Key
npub1ddqaln8xsfmy6sxqplt9sz5ev99kh052sveqsh02q7hmc3a6n68shpgp9aPublished at
2023-06-07 17:50:34Event JSON
{
"id": "de86e10487c674c4898fa5c5814dfe22a6021681d7af457d0c39ffd84f70ccd6",
"pubkey": "6b41dfcce682764d40c00fd6580a99614b6bbe8a8332085dea07afbc47ba9e8f",
"created_at": 1686160234,
"kind": 1,
"tags": [
[
"e",
"b74d6e3e945ee090c612026984f249efe6d61ca521fddbb0329fa69f81265a0b",
"",
"root"
],
[
"e",
"e865ed5ac29fb77a8d52eda458c2d0e4a269b5389a4de370920849b1b3bc10df",
"",
"reply"
],
[
"p",
"51fd953c910ff2fb29ea373b08dcb779126d0fac49b04c34b2ef3b33e2792879"
]
],
"content": "📅 Original date posted:2016-05-11\n📝 Original message:There is no way to tell from a block if it was mined with AsicBoost or not.\nSo you don’t know what percentage of the hashrate uses AsicBoost at any\npoint in time. How can you risk forking that percentage out? Note that this\nwould be a GUARANTEED chain fork. Meaning that after you change the block\nmining algorithm some percentage of hardware will no longer be able to\nproduce valid blocks. That hardware cannot “switch over” to the majority\nchain even if it wanted to. Hence you are guaranteed to have two\nco-existing bitcoin blockchains afterwards.\n\nAgain: this is unlike the hypothetical persistence of two chains after a\nhardfork that is only contentious but doesn’t change the mining algorithm,\nthe kind of hardfork you are proposing would guarantee the persistence of\ntwo chains.\n\nNote that “AsicBoost” above is replaceable with “optimization X”. It’s\nsimply a logical argument: If you want to make optimization X impossible\nand someone is already using optimization X you end up with two chains. So\nunless you know exactly which optimizations are in use (and therefore also\nknow which ones are not in use) you can’t make these kind of changes.\nAsicBoost is known at least since middle of 2013.\n\nTo be more precise, if you change the block validation ruleset R to block\nvalidation ruleset S you have to make sure that every hardware that was\ncapable of mining R-valid blocks is also capable of mining S-valid blocks.\n\nThe problem is that chip manufacturers will not tell you which\noptimizations they use. You would have to threaten to irreversibly fork\ntheir hardware out by a rule change, only then would they start shouting\nand reveal their optimization. It seems extremely dangerous to set the\nprecedence of a hardfork that irreversibly forks out a certain type of\nmining hardware.\n\nThe part \"Also the fix should be compatible with existing mining hardware.\"\nis impossible to achieve because it's unclear what \"existing mining\nhardware\" is. There has never been a specification of what mining hardware\nshould do. There are only acceptance rules.\n\nThe only way out is to go the exact opposite way and to embrace as many\noptimizations as possible to the point where there are no more\noptimizations left to do, or hopefully getting very close to that point.\n\nTimo\n\n\n\nOn Tue, May 10, 2016 at 11:57 AM, Peter Todd via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e As part of the hard-fork proposed in the HK agreement(1) we'd like to make\n\u003e the\n\u003e patented AsicBoost optimisation useless, and hopefully make further similar\n\u003e optimizations useless as well.\n\u003e\n\u003e What's the best way to do this? Ideally this would be SPV compatible, but\n\u003e if it\n\u003e requires changes from SPV clients that's ok too. Also the fix this should\n\u003e be\n\u003e compatible with existing mining hardware.\n\u003e\n\u003e\n\u003e 1)\n\u003e https://medium.com/@bitcoinroundtable/bitcoin-roundtable-consensus-266d475a61ff\n\u003e\n\u003e 2)\n\u003e http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-April/012596.html\n\u003e\n\u003e --\n\u003e https://petertodd.org 'peter'[:-1]@petertodd.org\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160510/26eb0bad/attachment.html\u003e",
"sig": "a5687726b60379828429b896af3f7adf73f9e2fa8c59f766908824ebedc1c801c89b49dbdd8ac03a8438fd68c66b94418e3ed3040676ed9bbfc362a8cd228564"
}