Making AsicBoost irrelevant
39 messages, 10 to 12 May 2016. Started by Peter Todd.
Peter Todd (5), Matt Corallo (5), Timo Hanke (5), Sergio Demian Lerner (4), Jannes Faber (3), Jorge Timón (2), Gregory Maxwell (2), Tom Harding (2), +11 more
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
The various chunks in the double SHA256 are
Chunk 1: 64 bytes version previous_block_digest merkle_root[31:4]
Chunk 2: 64 bytes merkle_root[3:0] nonce timestamp target
Chunk 3: 64 bytes digest from first sha pass
Their improvement requires that all data in Chunk 2 is identical except for the nonce. With 4 bytes, the birthday paradox means collisions can be found reasonable easily.
If hard forks are allowed, then moving more of the merkle root into the 2nd chunk would make things harder. The timestamp and target could be moved into chunk 1. This increases the merkle root to 12 bytes in the 2nd chunk. Finding collisions would be made much more difficult.
If ASIC limitations mean that the nonce must stay where it is, this would mean that the merkle root would be split into two pieces.
On Tue, May 10, 2016 at 7:57 PM, Peter Todd via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (27 lines)
> 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@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >
Yea, I think in any hardfork that we should be talking about, a part of it should include 1) fix the version field so its a static constant, 2) the merkle root becomes hash of the real block header 3) swap first 2 bytes of the merkle root with the timestamp's two high-order bits, 4) swap the next 4 bytes of the merkle root with the difficulty field.
I believe this should be compatible with all existing ASICs, with the exception, possibly, of some 21 Inc hardware. I believe this fixes AsicBoost (without thinking about it tooo much, so please critique).
While this is somewhat nasty, the risks of AsicBoost and the precedent that should be set necessitates a response, and it should be included in any hardfork.
Matt
On 05/10/16 20:27, Tier Nolan via bitcoin-dev wrote:
Quoted text (68 lines)
> The various chunks in the double SHA256 are > > Chunk 1: 64 bytes > version > previous_block_digest > merkle_root[31:4] > > Chunk 2: 64 bytes > merkle_root[3:0] > nonce > timestamp > target > > Chunk 3: 64 bytes > digest from first sha pass > > Their improvement requires that all data in Chunk 2 is identical except > for the nonce. With 4 bytes, the birthday paradox means collisions can > be found reasonable easily. > > If hard forks are allowed, then moving more of the merkle root into the > 2nd chunk would make things harder. The timestamp and target could be > moved into chunk 1. This increases the merkle root to 12 bytes in the > 2nd chunk. Finding collisions would be made much more difficult. > > If ASIC limitations mean that the nonce must stay where it is, this > would mean that the merkle root would be split into two pieces. > > On Tue, May 10, 2016 at 7:57 PM, Peter Todd via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation•org > <mailto:bitcoin-dev@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@lists•linuxfoundation•org > <mailto:bitcoin-dev@lists.linuxfoundation.org> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
Your idea of moving the Merkle root to the second chunk does not work.
The AsicBoost can change the version bits and it does not need to find a collision. (However *Spondoolies patent *only mentions Merkle collisions: https://patentscope.wipo.int/search/docservicepdf_pct/id00000032873338/PAMPH/WO2016046820.pdf )
Back in 2014 I designed a ASIC-compatible block header that prevents AsicBoost in all its forms.
You can find it here: https://bitslog.wordpress.com/2014/03/18/the-re-design-of-the-bitcoin-block-header/
Basically, the idea is to put in the first 64 bytes a 4 byte hash of the second 64-byte chunk. That design also allows increased nonce space in the first 64 bytes.
But it you want to do a simpler change, you can more easily use the first 32 bits of the Parent Block Hash (now currently zero) to store the first 4 bytes of the SHA256 of the last 16 bytes of the header. That way to "tie" the two header chunks. It's a minimal change (but a hard-fork)
But some ASIC companies already have cores that are better (on power, cost, rate, temperature, etc.) than competing companies ASICs. Why do you think a 10% improvement from AsicBoost is different from many of other improvements they already have (secretly) added? Maybe we (?) should only allow ASICs that have a 100% open source designs?
If we change the protocol then the message to the ecosystem is that ASIC optimizations should be kept secret. It is fair to change the protocol because we don't like that certain ASIC manufacturer has better chips, if the chips are sold in the market and anyone can buy them? And what about using approximate adders (30% improvement), or dual rail asynchronous adders (also more than 10% improvement) ? How do we repair those?
Disclaimer: I have stake in AsicBoost, but I'm not sure about this.
On Tue, May 10, 2016 at 5:27 PM, Tier Nolan via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (66 lines)
> The various chunks in the double SHA256 are > > Chunk 1: 64 bytes > version > previous_block_digest > merkle_root[31:4] > > Chunk 2: 64 bytes > merkle_root[3:0] > nonce > timestamp > target > > Chunk 3: 64 bytes > digest from first sha pass > > Their improvement requires that all data in Chunk 2 is identical except > for the nonce. With 4 bytes, the birthday paradox means collisions can be > found reasonable easily. > > If hard forks are allowed, then moving more of the merkle root into the > 2nd chunk would make things harder. The timestamp and target could be > moved into chunk 1. This increases the merkle root to 12 bytes in the 2nd > chunk. Finding collisions would be made much more difficult. > > If ASIC limitations mean that the nonce must stay where it is, this would > mean that the merkle root would be split into two pieces. > > On Tue, May 10, 2016 at 7:57 PM, Peter Todd via bitcoin-dev < > bitcoin-dev@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@lists•linuxfoundation•org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >
On Tue, May 10, 2016 at 8:57 PM, Peter Todd via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (5 lines)
> 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. >
Just in the interest of clarity, I think you should clarify who you are including in the "we".
Bye!
On Tue, May 10, 2016 at 3:57 PM, Peter Todd via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (7 lines)
> 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. > > > You say that you want to make patented optimization useless, but you point
to a link that doesn't say anything about ASIC improvements or patents, which means that you have been planning to change the protocol rules with some miners (but not all the community).
All changes to the protocol should be discussed in public here. If you want to make "further similar optimizations useless as well" then maybe you should propose a switch to EquiHash.
Quoted text (16 lines)
> > 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@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >
The second like "2)" has a link to the paper: http://www.math.rwth-aachen.de/~Timo.Hanke/AsicBoostWhitepaperrev5.pdf
which does discuss the fact that it is "patent-pending". Likewise it discusses ASIC improvements. Avoiding patents that impact bitcoin and are not freely licensed, is something that is worthwhile for discussion.
On Tue, May 10, 2016 at 6:17 PM, Sergio Demian Lerner via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (46 lines)
> > > On Tue, May 10, 2016 at 3:57 PM, Peter Todd via bitcoin-dev < > bitcoin-dev@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. >> >> >> You say that you want to make patented optimization useless, but you > point to a link that doesn't say anything about ASIC improvements or > patents, which means that you have been planning to change the protocol > rules with some miners (but not all the community). > > All changes to the protocol should be discussed in public here. If you > want to make "further similar optimizations useless as well" then maybe you > should propose a switch to EquiHash. > > > >> >> 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@lists•linuxfoundation•org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >
Replies inline.
On 05/10/16 21:43, Sergio Demian Lerner via bitcoin-dev wrote: -snip-
Quoted text (5 lines)
> But some ASIC companies already have cores that are better (on power, > cost, rate, temperature, etc.) than competing companies ASICs. Why do > you think a 10% improvement from AsicBoost is different from many of > other improvements they already have (secretly) added? Maybe we (?) > should only allow ASICs that have a 100% open source designs?
One is patented and requires paying a license fee to a group, or more likely, ends up with it being impossible to import hardware from other jurisdictions into the US/western world. The other requires more investment in R&D, and over the long run, there is no guaranteed advantage to such groups.
Quoted text (2 lines)
> If we change the protocol then the message to the ecosystem is that ASIC > optimizations should be kept secret.
To some extent, this is the case, but there is a strong difference between a guaranteed advantage enforced by the legal system and one that is true due to intellectual superiority. In the long run, I am confident the second will not remain the case. For example, AsicBoost was independently discovered by at least two companies/individuals within a year or two.
Quoted text (6 lines)
> It is fair to change the protocol > because we don't like that certain ASIC manufacturer has better chips, > if the chips are sold in the market and anyone can buy them? And what > about using approximate adders (30% improvement), or dual rail > asynchronous adders (also more than 10% improvement) ? How do we repair > those?
As far as I'm aware neither of these are patented. Is this not the case?
Quoted text (85 lines)
> Disclaimer: I have stake in AsicBoost, but I'm not sure about this. > > > On Tue, May 10, 2016 at 5:27 PM, Tier Nolan via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation•org > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: > > The various chunks in the double SHA256 are > > Chunk 1: 64 bytes > version > previous_block_digest > merkle_root[31:4] > > Chunk 2: 64 bytes > merkle_root[3:0] > nonce > timestamp > target > > Chunk 3: 64 bytes > digest from first sha pass > > Their improvement requires that all data in Chunk 2 is identical > except for the nonce. With 4 bytes, the birthday paradox means > collisions can be found reasonable easily. > > If hard forks are allowed, then moving more of the merkle root into > the 2nd chunk would make things harder. The timestamp and target > could be moved into chunk 1. This increases the merkle root to 12 > bytes in the 2nd chunk. Finding collisions would be made much more > difficult. > > If ASIC limitations mean that the nonce must stay where it is, this > would mean that the merkle root would be split into two pieces. > > On Tue, May 10, 2016 at 7:57 PM, Peter Todd via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation•org > <mailto:bitcoin-dev@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@lists•linuxfoundation•org > <mailto:bitcoin-dev@lists.linuxfoundation.org> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > <mailto:bitcoin-dev@lists.linuxfoundation.org> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
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@lists•linuxfoundation•org> wrote:
Quoted text (27 lines)
> 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@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >
On 11 May 2016 at 05:14, Timo Hanke via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (14 lines)
> 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. >
Assuming AsicBoost miners are in the minority, their chain will constantly get overtaken. So it will not be one endless hard fork as you claim, but rather AsicBoost blocks will continue to be ignored (orphaned) until they stop making them.
That hardware cannot “switch over” to the majority chain even if it wanted
Quoted text (2 lines)
> to. >
They will in fact continually "switch over" to the majority, they just are unable to extend that majority chain themselves.
On Wed, May 11, 2016 at 11:21:10AM +0200, Jannes Faber via bitcoin-dev wrote:
Quoted text (22 lines)
> On 11 May 2016 at 05:14, Timo Hanke via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation•org> 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. > > > > Assuming AsicBoost miners are in the minority, their chain will constantly > get overtaken. So it will not be one endless hard fork as you claim, but > rather AsicBoost blocks will continue to be ignored (orphaned) until they > stop making them.
At least until a difficulty adjustment on the AsicBoost chain takes place. From that point on, both chains, the AsicBoost one and the forked one will grow approximately at the same speed.
All the best Henning
On 11 May 2016 at 12:36, Henning Kopp <henning.kopp@uni-ulm•de> wrote:
Quoted text (39 lines)
> On Wed, May 11, 2016 at 11:21:10AM +0200, Jannes Faber via bitcoin-dev > wrote: > > On 11 May 2016 at 05:14, Timo Hanke via bitcoin-dev < > > bitcoin-dev@lists•linuxfoundation•org> 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. > > > > > > > Assuming AsicBoost miners are in the minority, their chain will > constantly > > get overtaken. So it will not be one endless hard fork as you claim, but > > rather AsicBoost blocks will continue to be ignored (orphaned) until they > > stop making them. > > At least until a difficulty adjustment on the AsicBoost chain takes > place. From that point on, both chains, the AsicBoost one and the > forked one will grow approximately at the same speed. > >
No: you are still assuming AsicBoost miners would reject normal blocks. They don't now and they would have to specifically code for that as a reply to AsicBoost being banned. So there won't be two chains at all, only the main chain with a lot (more than usual) of short (few blocks) forks. Each forks starts anew, it's not one long fork. Therefore there is no "difficulty adjustment on the AiscBoost chain".
Now if they do decide to ban non-AsicBoost blocks as a response to being banned themselves, they're just another altcoin with a different PoW and no one would have a reason to use them over Bitcoin (apart from maybe selling those forked coins asap).
You're confused about what "longest" means as well: it's not just the number of blocks, it's the aggregate difficulty that counts: so AsicBoost would never become "longer" (more total work) either.
Hope this helps clear things up.
On Tue, May 10, 2016 at 6:43 PM, Sergio Demian Lerner < sergio.d.lerner@gmail•com> wrote:
Quoted text (10 lines)
> > > You can find it here: > https://bitslog.wordpress.com/2014/03/18/the-re-design-of-the-bitcoin-block-header/ > > Basically, the idea is to put in the first 64 bytes a 4 byte hash of the > second 64-byte chunk. That design also allows increased nonce space in the > first 64 bytes. > > My mistake here. I didn't recalled correctly my own idea. The idea is to
include in the second 64-byte chunk a 4-byte hash of the first chunk, not the opposite.
Ehm, I though those discussions about "ASICs are bad, because X" ended years ago by starting "ASIC unfriendly" altcoins. ASIC industry is twisted even without AsicBoost. I don't see any particular reason why to change rules just because of 10% edge.
This is opening Pandora box and it is potentially extremely dangerous for the health of the network. You cannot know in advance what you'll break by changing the rules.
Disclaimer: I don't have any stake in any ASIC company/facility.
slush
On Wed, May 11, 2016 at 2:20 PM, Sergio Demian Lerner via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (25 lines)
> > > On Tue, May 10, 2016 at 6:43 PM, Sergio Demian Lerner < > sergio.d.lerner@gmail•com> wrote: > >> >> >> You can find it here: >> https://bitslog.wordpress.com/2014/03/18/the-re-design-of-the-bitcoin-block-header/ >> >> Basically, the idea is to put in the first 64 bytes a 4 byte hash of the >> second 64-byte chunk. That design also allows increased nonce space in the >> first 64 bytes. >> >> My mistake here. I didn't recalled correctly my own idea. The idea is to > include in the second 64-byte chunk a 4-byte hash of the first chunk, not > the opposite. > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >
On May 11, 2016 05:15, "Timo Hanke via bitcoin-dev" < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (2 lines)
> > 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.
If all users abandon the old rules, why would asicboost miners continue to spend energy on a chain that everybody else is ignoring?
Quoted text (1 line)
> 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.
Why? No, this proposal, for example, may make patented asicboost hardware obsolete. I don't accept this claim as true, this is just your opinion.
Quoted text (2 lines)
> > 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.
What do you mean by "embrace" in the context of a patented optimization that one miner can prevent the rest from using?
Jorge Timón said..
Quoted text (1 line)
> What do you mean by "embrace" in the context of a patented optimization
that one miner can prevent the rest from using?
Everyone seems to assume that one ASIC manufacturer will get the advantage of AsicBoost while others won't. If a patent license is non-exclusive, then all can.
On Wednesday, May 11, 2016 12:20:55 PM Sergio Demian Lerner via bitcoin-dev wrote:
Quoted text (13 lines)
> On Tue, May 10, 2016 at 6:43 PM, Sergio Demian Lerner < > sergio.d.lerner@gmail•com> wrote: > > You can find it here: > > https://bitslog.wordpress.com/2014/03/18/the-re-design-of-the-bitcoin-blo > > ck-header/ > > > > Basically, the idea is to put in the first 64 bytes a 4 byte hash of the > > second 64-byte chunk. That design also allows increased nonce space in > > the first 64 bytes. > > My mistake here. I didn't recalled correctly my own idea. The idea is to > include in the second 64-byte chunk a 4-byte hash of the first chunk, not > the opposite.
What if we XOR bytes 64..76 with the first 12 bytes of the SHA2 midstate? Would that work?
Luke
On 11 May 2016 at 16:18, Sergio Demian Lerner via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (9 lines)
> Jorge Timón said.. > > What do you mean by "embrace" in the context of a patented optimization > that one miner can prevent the rest from using? > > Everyone seems to assume that one ASIC manufacturer will get the advantage > of AsicBoost while others won't. If a patent license is non-exclusive, then > all can. > >
1. Whatever way you look at it, it will be an extra barrier of entry (cost, legal hassle, more complex chip design) for any new ASIC manufacturer trying to enter the market. That counters free competition and thus decentralization.
2. Why would you want to put yourself in the central spot of the big decider on who gets access to the technology (and therefore the whole mining game) and who doesn't. You're not afraid of NSA knocking on your door to politely hand you their blacklist? You don't think this counters all the years of hard work that went into Bitcoin exactly to avoid any such central points of authority?
P.S. I'm not decided yet on being for or against a HF to ban AsicBoost myself, nor does my opinion count for much. But I think I do see real problems, like the above.
Luke, do you mean to replace the first 4 bytes of the second chunk (bytes 64..67 in 0-based counting) by the XOR of those 4 bytes with the first 4 bytes of the midstate? (I assume you don't care about 12 bytes but rather those 4 bytes.)
This does not work. All it does is adding another computational step before you can check for a collision in those 4 bytes. It makes finding a collision only marginally harder.
On Wed, May 11, 2016 at 7:28 AM, Luke Dashjr via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (27 lines)
> On Wednesday, May 11, 2016 12:20:55 PM Sergio Demian Lerner via bitcoin-dev > wrote: > > On Tue, May 10, 2016 at 6:43 PM, Sergio Demian Lerner < > > sergio.d.lerner@gmail•com> wrote: > > > You can find it here: > > > > https://bitslog.wordpress.com/2014/03/18/the-re-design-of-the-bitcoin-blo > > > ck-header/ > > > > > > Basically, the idea is to put in the first 64 bytes a 4 byte hash of > the > > > second 64-byte chunk. That design also allows increased nonce space in > > > the first 64 bytes. > > > > My mistake here. I didn't recalled correctly my own idea. The idea is to > > include in the second 64-byte chunk a 4-byte hash of the first chunk, not > > the opposite. > > What if we XOR bytes 64..76 with the first 12 bytes of the SHA2 midstate? > Would that work? > > Luke > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
Sorry, you must have meant all 12 bytes. That makes finding a collision substantially harder. However, you may have to restrict yourself to 10 bytes because you don't know if any hardware does timestamp rolling on-chip. Also you create an incentive to mess around with the version bits instead, so you would have to fix that as well. So it basically means a new mining header with the real blockheader as a child header.
On Wed, May 11, 2016 at 9:24 AM, Timo Hanke <timo.hanke@web•de> wrote:
Quoted text (43 lines)
> Luke, do you mean to replace the first 4 bytes of the second chunk (bytes > 64..67 in 0-based counting) by the XOR of those 4 bytes with the first 4 > bytes of the midstate? (I assume you don't care about 12 bytes but rather > those 4 bytes.) > > This does not work. All it does is adding another computational step > before you can check for a collision in those 4 bytes. It makes finding a > collision only marginally harder. > > On Wed, May 11, 2016 at 7:28 AM, Luke Dashjr via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation•org> wrote: > >> On Wednesday, May 11, 2016 12:20:55 PM Sergio Demian Lerner via >> bitcoin-dev >> wrote: >> > On Tue, May 10, 2016 at 6:43 PM, Sergio Demian Lerner < >> > sergio.d.lerner@gmail•com> wrote: >> > > You can find it here: >> > > >> https://bitslog.wordpress.com/2014/03/18/the-re-design-of-the-bitcoin-blo >> > > ck-header/ >> > > >> > > Basically, the idea is to put in the first 64 bytes a 4 byte hash of >> the >> > > second 64-byte chunk. That design also allows increased nonce space in >> > > the first 64 bytes. >> > >> > My mistake here. I didn't recalled correctly my own idea. The idea is to >> > include in the second 64-byte chunk a 4-byte hash of the first chunk, >> not >> > the opposite. >> >> What if we XOR bytes 64..76 with the first 12 bytes of the SHA2 midstate? >> Would that work? >> >> Luke >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation•org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > >
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:
Quoted text (86 lines)
> 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@lists•linuxfoundation•org > <mailto:bitcoin-dev@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@lists•linuxfoundation•org > <mailto:bitcoin-dev@lists.linuxfoundation.org> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
Indeed, I think the "ASICs are bad, because 1-CPU-1-vote" arguments mostly died out long ago, and, indeed, the goal that many making those arguments had of building "unoptimizeable" ASICs failed with them.
I think everyone understands that there will always be some ability to iterate on ASIC designs, however, a patented optimization breaks that assumption. Instead of being freely able to optimize their ASIC design, patented optimizations require that people who discover such optimizations themselves do not use them, giving one manufacturer/licenser a huge influence in who is successful in a market that we're all relying on remaining rather flat. Indeed, with AsicBoost, we saw Spondoolies independently discover the same optimization, but with the current legal system they would not have been able to sell such systems without licensing AsicBoost.
Matt
On 05/11/16 13:08, Marek Palatinus via bitcoin-dev wrote:
Quoted text (50 lines)
> Ehm, I though those discussions about "ASICs are bad, because X" ended > years ago by starting "ASIC unfriendly" altcoins. ASIC industry is > twisted even without AsicBoost. I don't see any particular reason why to > change rules just because of 10% edge. > > This is opening Pandora box and it is potentially extremely dangerous > for the health of the network. You cannot know in advance what you'll > break by changing the rules. > > Disclaimer: I don't have any stake in any ASIC company/facility. > > slush > > On Wed, May 11, 2016 at 2:20 PM, Sergio Demian Lerner via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation•org > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: > > > > On Tue, May 10, 2016 at 6:43 PM, Sergio Demian Lerner > <sergio.d.lerner@gmail•com <mailto:sergio.d.lerner@gmail.com>> wrote: > > > > You can find it here: > https://bitslog.wordpress.com/2014/03/18/the-re-design-of-the-bitcoin-block-header/ > > Basically, the idea is to put in the first 64 bytes a 4 byte > hash of the second 64-byte chunk. That design also allows > increased nonce space in the first 64 bytes. > > My mistake here. I didn't recalled correctly my own idea. The idea > is to include in the second 64-byte chunk a 4-byte hash of the first > chunk, not the opposite. > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > <mailto:bitcoin-dev@lists.linuxfoundation.org> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
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@lists•linuxfoundation•org> wrote:
Quoted text (104 lines)
> 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@lists•linuxfoundation•org >> <mailto:bitcoin-dev@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@lists•linuxfoundation•org >> <mailto:bitcoin-dev@lists.linuxfoundation.org> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation•org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
On 05/11/2016 02:01 PM, Matt Corallo via bitcoin-dev wrote:
Quoted text (3 lines)
> Indeed, I think the "ASICs are bad, because 1-CPU-1-vote" arguments > mostly died out long ago, and, indeed, the goal that many making those > arguments had of building "unoptimizeable" ASICs failed with them.
Discussion quietened down but never went away. With centralization of mining in China, the topic is up for discussion again. For example, Z.Cash will now use Equihash as their proof-of-work scheme.
Quoted text (3 lines)
> giving one > manufacturer/licenser a huge influence in who is successful in a market > that we're all relying on remaining rather flat.
Central planning is a slippery slope. Let the market decide the winners and losers. It's not feasible to hard fork every time an innovation or perceived unfair advantage appears in the space.
--Simon
On Wed, May 11, 2016 at 3:47 AM, Jannes Faber <jannes.faber@gmail•com> wrote:
Quoted text (54 lines)
> On 11 May 2016 at 12:36, Henning Kopp <henning.kopp@uni-ulm•de> wrote: > >> On Wed, May 11, 2016 at 11:21:10AM +0200, Jannes Faber via bitcoin-dev >> wrote: >> > On 11 May 2016 at 05:14, Timo Hanke via bitcoin-dev < >> > bitcoin-dev@lists•linuxfoundation•org> 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. >> > > >> > >> > Assuming AsicBoost miners are in the minority, their chain will >> constantly >> > get overtaken. So it will not be one endless hard fork as you claim, but >> > rather AsicBoost blocks will continue to be ignored (orphaned) until >> they >> > stop making them. >> >> At least until a difficulty adjustment on the AsicBoost chain takes >> place. From that point on, both chains, the AsicBoost one and the >> forked one will grow approximately at the same speed. >> >> > No: you are still assuming AsicBoost miners would reject normal blocks. > They don't now and they would have to specifically code for that as a reply > to AsicBoost being banned. So there won't be two chains at all, only the > main chain with a lot (more than usual) of short (few blocks) forks. Each > forks starts anew, it's not one long fork. Therefore there is no > "difficulty adjustment on the AiscBoost chain". > > Now if they do decide to ban non-AsicBoost blocks as a response to being > banned themselves, they're just another altcoin with a different PoW and no > one would have a reason to use them over Bitcoin (apart from maybe selling > those forked coins asap). >
This is what I meant. If existing hardware gets forked-out it will inevitably lead to the creation of an altcoin. Simply because the hardware exists and can't be used for anything else both chains will survive. I was only comparing the situation to a contentious hardfork that does not fork out any hardware. If the latter one is suspected to lead to the permanent existence of two chains then a hardfork that forks out hardware is even more likely to do so (I claim it's guaranteed).
Quoted text (9 lines)
> You're confused about what "longest" means as well: it's not just the > number of blocks, it's the aggregate difficulty that counts: so AsicBoost > would never become "longer" (more total work) either. > > Hope this helps clear things up. > > -- > Jannes >
Ups, I forgot that you take the midstate which of course depends on the version number. So forget everything I said about the version bits. You are right. But why take the midstate? It can be any hash of the first chunk. So you probably want to take a hash function that's available in standard software libraries. And I suppose midstate() is not.
On Wed, May 11, 2016 at 11:28 AM, Timo Hanke <timo.hanke@web•de> wrote:
Quoted text (55 lines)
> Sorry, you must have meant all 12 bytes. That makes finding a collision > substantially harder. However, you may have to restrict yourself to 10 > bytes because you don't know if any hardware does timestamp rolling > on-chip. Also you create an incentive to mess around with the version bits > instead, so you would have to fix that as well. So it basically means a new > mining header with the real blockheader as a child header. > > On Wed, May 11, 2016 at 9:24 AM, Timo Hanke <timo.hanke@web•de> wrote: > >> Luke, do you mean to replace the first 4 bytes of the second chunk (bytes >> 64..67 in 0-based counting) by the XOR of those 4 bytes with the first 4 >> bytes of the midstate? (I assume you don't care about 12 bytes but rather >> those 4 bytes.) >> >> This does not work. All it does is adding another computational step >> before you can check for a collision in those 4 bytes. It makes finding a >> collision only marginally harder. >> >> On Wed, May 11, 2016 at 7:28 AM, Luke Dashjr via bitcoin-dev < >> bitcoin-dev@lists•linuxfoundation•org> wrote: >> >>> On Wednesday, May 11, 2016 12:20:55 PM Sergio Demian Lerner via >>> bitcoin-dev >>> wrote: >>> > On Tue, May 10, 2016 at 6:43 PM, Sergio Demian Lerner < >>> > sergio.d.lerner@gmail•com> wrote: >>> > > You can find it here: >>> > > >>> https://bitslog.wordpress.com/2014/03/18/the-re-design-of-the-bitcoin-blo >>> > > ck-header/ >>> > > >>> > > Basically, the idea is to put in the first 64 bytes a 4 byte hash of >>> the >>> > > second 64-byte chunk. That design also allows increased nonce space >>> in >>> > > the first 64 bytes. >>> > >>> > My mistake here. I didn't recalled correctly my own idea. The idea is >>> to >>> > include in the second 64-byte chunk a 4-byte hash of the first chunk, >>> not >>> > the opposite. >>> >>> What if we XOR bytes 64..76 with the first 12 bytes of the SHA2 midstate? >>> Would that work? >>> >>> Luke >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists•linuxfoundation•org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >> >> >
On Wed, May 11, 2016 at 03:16:58PM -0700, Simon Liu via bitcoin-dev wrote:
Quoted text (7 lines)
> > giving one > > manufacturer/licenser a huge influence in who is successful in a market > > that we're all relying on remaining rather flat. > > Central planning is a slippery slope. Let the market decide the winners > and losers. It's not feasible to hard fork every time an innovation or > perceived unfair advantage appears in the space.
That's why we're asking the market right now, and any actual hard-fork to make AsicBoost irrelevant would be voted on by miners themselves and in turn, the economic majority, again letting the market collectively decide.
On Wed, May 11, 2016 at 10:42 PM, Timo Hanke via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (7 lines)
> This is what I meant. If existing hardware gets forked-out it will > inevitably lead to the creation of an altcoin. Simply because the hardware > exists and can't be used for anything else both chains will survive. I was > only comparing the situation to a contentious hardfork that does not fork > out any hardware. If the latter one is suspected to lead to the permanent > existence of two chains then a hardfork that forks out hardware is even more > likely to do so (I claim it's guaranteed).
There are already many altcoins out there, we could not prevent that even if we wanted to. New ones are created all the time.
A 20% inherent advantage, in perfect competition, is likely to lead to an eventual monopoly of mining if monopoly patent right prohibit competitions-- if mining profits go are under the level of that enhancement everyone without it would be operating at a loss.
Preserving a vulnerability that will ultimately harm the system's decentralization for just the betterment of some miners does not seem like a rational decision for the users of Bitcoin-- no more than it would reasonable to add a rule that all blocks must be signed by a particular private key.
As an altcoin the "asicboost" altcoin would be one of the least interesting altcoins ever created... after all, no other altcoin has ever been created that required licensing in order to mine.
I don't know if forking it out is the best move here and now, but I'm happy some people are thinking carefully about what it would take to do that.
On Tue, May 10, 2016 at 08:14:33PM -0700, Timo Hanke wrote:
Quoted text (8 lines)
> 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.
First of all, we can easily do this in a way where miners show their support for this change, say with the usual 95% approval threshold we've been using for soft-forks. That gets the % of hashing power on a AsicBoost chain fork down to 5% at most.
Secondly, we can probably make the consensus PoW allow blocks to be mined using both the existing PoW algorithm, and a very slightly tweaked version where implementing AsicBoost gives no advantage. That removes any incentive to implement AsicBoost, without making any hardware obsolete (such as 21inc's hardware). This means that no hashing power at all needs to use the AsicBoost patent.
Obviously, the fact that miners can support such a change (assuming of course the economic majority approves it as well) changes the negotiation position re: licensing fees; the actual outcome may simply be you guys make the patent 100% public for all to use at a much reduced price, given you're lack of negotiation strength.
Quoted text (6 lines)
> 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.
I think _patented_ optimizations where one party has a monopoly are very different than optimizations that anyone can independently rediscover - AsicBoost itself looks to be something that two or three parties independently discovered.
Quoted text (3 lines)
> 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.
...which is a scenario that may result in a dozen patented optimizations, with new ASIC manufacturers needing a dozen licenses, from potentially hostile entities.
For instance, it's not clear to me if you actually own this patent, or Cointerra's creditors. Obviously in the latter case, it'd be quite possible that some kind of bankrupcy court ruling results in the patent getting sold to a hostile entity who will use it against all of Bitcoin. Equally, even if it is 100% owned by you and Sergio, it'd be very easy for a personal bankrupcy to result in the same scenario (suppose you get into a car accident and lose a negligence lawsuit over it).
On Wed, May 11, 2016 at 11:01 PM, Peter Todd via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (4 lines)
> Secondly, we can probably make the consensus PoW allow blocks to be mined using > both the existing PoW algorithm, and a very slightly tweaked version where > implementing AsicBoost gives no advantage. That removes any incentive to > implement AsicBoost, without making any hardware obsolete
Taking that a step further, the old POW could continue to be accepted but with a 20% target penalty. (or vice versa, with the new POW having a 20% target boost.)
Is the design and manufacturing processes for the most power efficient ASICs otherwise patent unencumbered? If not, why do we care so much about this one patent over all the others that stand on the road between pen and paper computation and thermodynamically ideal computation?
On Wed, May 11, 2016 at 8:02 PM, Gregory Maxwell via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (17 lines)
> On Wed, May 11, 2016 at 11:01 PM, Peter Todd via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation•org> wrote: > > Secondly, we can probably make the consensus PoW allow blocks to be > mined using > > both the existing PoW algorithm, and a very slightly tweaked version > where > > implementing AsicBoost gives no advantage. That removes any incentive to > > implement AsicBoost, without making any hardware obsolete > > Taking that a step further, the old POW could continue to be accepted > but with a 20% target penalty. (or vice versa, with the new POW having > a 20% target boost.) > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
On 11 May 2016 21:23:21 GMT-04:00, Russell O'Connor via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (6 lines)
>Is the design and manufacturing processes for the most power efficient >ASICs otherwise patent unencumbered? If not, why do we care so much >about >this one patent over all the others that stand on the road between pen >and >paper computation and thermodynamically ideal computation?
If others are found that are significant I think we'd definitely consider fighting them as well.
Aside from patents related to the silicon manufacturing process itself and patents not yet published, yes, the process is unencumbered, and setting the correct precedent (that the community will fight large centralization risks) is important in the first case.
Matt
On May 11, 2016 9:23:21 PM EDT, Russell O'Connor via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (38 lines)
>Is the design and manufacturing processes for the most power efficient >ASICs otherwise patent unencumbered? If not, why do we care so much >about >this one patent over all the others that stand on the road between pen >and >paper computation and thermodynamically ideal computation? > >On Wed, May 11, 2016 at 8:02 PM, Gregory Maxwell via bitcoin-dev < >bitcoin-dev@lists•linuxfoundation•org> wrote: > >> On Wed, May 11, 2016 at 11:01 PM, Peter Todd via bitcoin-dev >> <bitcoin-dev@lists•linuxfoundation•org> wrote: >> > Secondly, we can probably make the consensus PoW allow blocks to be >> mined using >> > both the existing PoW algorithm, and a very slightly tweaked >version >> where >> > implementing AsicBoost gives no advantage. That removes any >incentive to >> > implement AsicBoost, without making any hardware obsolete >> >> Taking that a step further, the old POW could continue to be accepted >> but with a 20% target penalty. (or vice versa, with the new POW >having >> a 20% target boost.) >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation•org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > > >------------------------------------------------------------------------ > >_______________________________________________ >bitcoin-dev mailing list >bitcoin-dev@lists•linuxfoundation•org >https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
On 5/10/2016 2:43 PM, Sergio Demian Lerner via bitcoin-dev wrote:
Quoted text (3 lines)
> > If we change the protocol then the message to the ecosystem is that > ASIC optimizations should be kept secret.
Further to that point, if THIS optimization had been kept secret, nobody would be talking about doing anything, as with countless other optimizations.
And anyone who would have discovered it independently would have been free to implement it. That's the issue, not that there's an optimization.
On Wed, May 11, 2016 at 9:27 PM, Tom Harding via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (14 lines)
> On 5/10/2016 2:43 PM, Sergio Demian Lerner via bitcoin-dev wrote: > > > > If we change the protocol then the message to the ecosystem is that > > ASIC optimizations should be kept secret. > > Further to that point, if THIS optimization had been kept secret, nobody > would be talking about doing anything, as with countless other > optimizations. > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
On 11 May 2016 22:27:09 GMT-04:00, Tom Harding via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (9 lines)
>On 5/10/2016 2:43 PM, Sergio Demian Lerner via bitcoin-dev wrote: >> >> If we change the protocol then the message to the ecosystem is that >> ASIC optimizations should be kept secret. > >Further to that point, if THIS optimization had been kept secret, >nobody >would be talking about doing anything, as with countless other >optimizations.
The optimisation has been independently discovered two or three times (Spondoolies and maybe Bitmain).
On May 11, 2016 7:33 PM, "Peter Todd" <pete@petertodd•org> wrote:
Quoted text (1 line)
> The optimisation has been independently discovered two or three times
(Spondoolies and maybe Bitmain).
The idea that a precedent can be set, whereby those who seek or are awarded mining optimization patents risk retaliatory consensus changes, is very unrealistic, and such a precedent would actually encode a dependency on the insane patent systems of the world into the protocol development process.
On Wednesday 11 May 2016 22:58:48 Gregory Maxwell via bitcoin-dev wrote:
Quoted text (13 lines)
> On Wed, May 11, 2016 at 10:42 PM, Timo Hanke via bitcoin-dev > > <bitcoin-dev@lists•linuxfoundation•org> wrote: > > This is what I meant. If existing hardware gets forked-out it will > > inevitably lead to the creation of an altcoin. Simply because the hardware > > exists and can't be used for anything else both chains will survive. I was > > only comparing the situation to a contentious hardfork that does not fork > > out any hardware. If the latter one is suspected to lead to the permanent > > existence of two chains then a hardfork that forks out hardware is even > > more likely to do so (I claim it's guaranteed). > > There are already many altcoins out there, we could not prevent that > even if we wanted to. New ones are created all the time.
Comparing apples and oranges.
Altcoins have their own genesis block, the example Timo was talking about was a fork in the Bitcoin blockchain.
But its good to know you don't mind a fork in the Bitcoin chain, I'll remember that.
On May 12, 2016 00:43, "Timo Hanke via bitcoin-dev" < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (1 line)
> This is what I meant. If existing hardware gets forked-out it will
inevitably lead to the creation of an altcoin. Simply because the hardware exists and can't be used for anything else both chains will survive. I was only comparing the situation to a contentious hardfork that does not fork out any hardware. If the latter one is suspected to lead to the permanent existence of two chains then a hardfork that forks out hardware is even more likely to do so (I claim it's guaranteed).
You are wrong. Whether 2 chains survive in parallel or not depends SOLELY in whether both chains maintain demand (aka users). Anyway, this is a discussion I had with Gavin and Rusty on bitcoin-discuss already. I suggest we move this particular point there since it is more philosophical than technical.