đź“… Original date posted:2016-05-11
đź“ť Original message:I was told that the patent appears to be owned exclusively by Bitmain
in China https://www.google.com/patents/CN105245327A?cl=en
On Wed, May 11, 2016 at 4:50 PM, Matt Corallo via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> That's the reason for this post! All current major ASIC manufacturers
> have made warrants that they are not using AsicBoost (with the exception
> of the 21 Inc Bitcoin computer).
>
> The fact that the optimization was patented is what has required that we
> work to hardfork it out, not that people might have such private
> optimizations. The fact that AsicBoost was independently discovered by
> at least two (if not three) organizations seems to lend credence to the
> idea that private optimizations will only provide a temporary win over
> competitors.
>
> Matt
>
> On 05/11/16 03:14, Timo Hanke via bitcoin-dev wrote:
>> 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
>> <mailto: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 <http://petertodd.org>;
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
James Hilliard [ARCHIVE] /
npub10r…kgk2d
2023-06-07 17:50:38
in reply to nevent1q…6a34
Author Public Key
npub10r9d6edmnrljk59wsf06zqp494l3qtjpa3w245hy6t5euqxlzw2qdkgk2dPublished at
2023-06-07 17:50:38Event JSON
{
"id": "3915b64325458d471a46c254a2f0d070a8f5888d86a2af24e864d7b99e57415a",
"pubkey": "78cadd65bb98ff2b50ae825fa100352d7f102e41ec5caad2e4d2e99e00df1394",
"created_at": 1686160238,
"kind": 1,
"tags": [
[
"e",
"b74d6e3e945ee090c612026984f249efe6d61ca521fddbb0329fa69f81265a0b",
"",
"root"
],
[
"e",
"f68c22540fd9e1032298afda840b5bec410b34ac4fc9a3ceb8f6c5d13462c434",
"",
"reply"
],
[
"p",
"cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba"
]
],
"content": "📅 Original date posted:2016-05-11\n📝 Original message:I was told that the patent appears to be owned exclusively by Bitmain\nin China https://www.google.com/patents/CN105245327A?cl=en\n\nOn Wed, May 11, 2016 at 4:50 PM, Matt Corallo via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e That's the reason for this post! All current major ASIC manufacturers\n\u003e have made warrants that they are not using AsicBoost (with the exception\n\u003e of the 21 Inc Bitcoin computer).\n\u003e\n\u003e The fact that the optimization was patented is what has required that we\n\u003e work to hardfork it out, not that people might have such private\n\u003e optimizations. The fact that AsicBoost was independently discovered by\n\u003e at least two (if not three) organizations seems to lend credence to the\n\u003e idea that private optimizations will only provide a temporary win over\n\u003e competitors.\n\u003e\n\u003e Matt\n\u003e\n\u003e On 05/11/16 03:14, Timo Hanke via bitcoin-dev wrote:\n\u003e\u003e There is no way to tell from a block if it was mined with AsicBoost or\n\u003e\u003e not. So you don’t know what percentage of the hashrate uses AsicBoost at\n\u003e\u003e any point in time. How can you risk forking that percentage out? Note\n\u003e\u003e that this would be a GUARANTEED chain fork. Meaning that after you\n\u003e\u003e change the block mining algorithm some percentage of hardware will no\n\u003e\u003e longer be able to produce valid blocks. That hardware cannot “switch\n\u003e\u003e over” to the majority chain even if it wanted to. Hence you are\n\u003e\u003e guaranteed to have two co-existing bitcoin blockchains afterwards.\n\u003e\u003e\n\u003e\u003e Again: this is unlike the hypothetical persistence of two chains after a\n\u003e\u003e hardfork that is only contentious but doesn’t change the mining\n\u003e\u003e algorithm, the kind of hardfork you are proposing would guarantee the\n\u003e\u003e persistence of two chains.\n\u003e\u003e\n\u003e\u003e Note that “AsicBoost” above is replaceable with “optimization X”. It’s\n\u003e\u003e simply a logical argument: If you want to make optimization X impossible\n\u003e\u003e and someone is already using optimization X you end up with two chains.\n\u003e\u003e So unless you know exactly which optimizations are in use (and therefore\n\u003e\u003e also know which ones are not in use) you can’t make these kind of\n\u003e\u003e changes. AsicBoost is known at least since middle of 2013.\n\u003e\u003e\n\u003e\u003e To be more precise, if you change the block validation ruleset R to\n\u003e\u003e block validation ruleset S you have to make sure that every hardware\n\u003e\u003e that was capable of mining R-valid blocks is also capable of mining\n\u003e\u003e S-valid blocks.\n\u003e\u003e\n\u003e\u003e The problem is that chip manufacturers will not tell you which\n\u003e\u003e optimizations they use. You would have to threaten to irreversibly fork\n\u003e\u003e their hardware out by a rule change, only then would they start shouting\n\u003e\u003e and reveal their optimization. It seems extremely dangerous to set the\n\u003e\u003e precedence of a hardfork that irreversibly forks out a certain type of\n\u003e\u003e mining hardware.\n\u003e\u003e\n\u003e\u003e The part \"Also the fix should be compatible with existing mining\n\u003e\u003e hardware.\" is impossible to achieve because it's unclear what \"existing\n\u003e\u003e mining hardware\" is. There has never been a specification of what mining\n\u003e\u003e hardware should do. There are only acceptance rules.\n\u003e\u003e\n\u003e\u003e The only way out is to go the exact opposite way and to embrace as many\n\u003e\u003e optimizations as possible to the point where there are no more\n\u003e\u003e optimizations left to do, or hopefully getting very close to that point.\n\u003e\u003e\n\u003e\u003e Timo\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e On Tue, May 10, 2016 at 11:57 AM, Peter Todd via bitcoin-dev\n\u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e\u003e\n\u003e\u003e As part of the hard-fork proposed in the HK agreement(1) we'd like\n\u003e\u003e to make the\n\u003e\u003e patented AsicBoost optimisation useless, and hopefully make further\n\u003e\u003e similar\n\u003e\u003e optimizations useless as well.\n\u003e\u003e\n\u003e\u003e What's the best way to do this? Ideally this would be SPV\n\u003e\u003e compatible, but if it\n\u003e\u003e requires changes from SPV clients that's ok too. Also the fix this\n\u003e\u003e should be\n\u003e\u003e compatible with existing mining hardware.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e 1)\n\u003e\u003e https://medium.com/@bitcoinroundtable/bitcoin-roundtable-consensus-266d475a61ff\n\u003e\u003e\n\u003e\u003e 2)\n\u003e\u003e http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-April/012596.html\n\u003e\u003e\n\u003e\u003e --\n\u003e\u003e https://petertodd.org 'peter'[:-1]@petertodd.org \u003chttp://petertodd.org\u003e\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\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",
"sig": "0b7839d96f6f7f265db1ce5185a257823b319d8f9df0a2b2c7ced64d40c777abcf6d5a7256e65d72dcdb87a17faa8b10ad183b2d763c3cf0d6b5c51193a65102"
}