* [bitcoin-dev] Making AsicBoost irrelevant
@ 2016-05-10 18:57 Peter Todd
2016-05-10 20:27 ` Tier Nolan
` (3 more replies)
0 siblings, 4 replies; 39+ messages in thread
From: Peter Todd @ 2016-05-10 18:57 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 622 bytes --]
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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply [flat|nested] 39+ messages in thread* Re: [bitcoin-dev] Making AsicBoost irrelevant 2016-05-10 18:57 [bitcoin-dev] Making AsicBoost irrelevant Peter Todd @ 2016-05-10 20:27 ` Tier Nolan 2016-05-10 21:35 ` Matt Corallo 2016-05-10 21:43 ` Sergio Demian Lerner 2016-05-10 21:49 ` Marco Pontello ` (2 subsequent siblings) 3 siblings, 2 replies; 39+ messages in thread From: Tier Nolan @ 2016-05-10 20:27 UTC (permalink / raw) To: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1742 bytes --] 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 > > [-- Attachment #2: Type: text/html, Size: 2997 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [bitcoin-dev] Making AsicBoost irrelevant 2016-05-10 20:27 ` Tier Nolan @ 2016-05-10 21:35 ` Matt Corallo 2016-05-10 21:43 ` Sergio Demian Lerner 1 sibling, 0 replies; 39+ messages in thread From: Matt Corallo @ 2016-05-10 21:35 UTC (permalink / raw) To: Tier Nolan, Bitcoin Protocol Discussion 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: > 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 > ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [bitcoin-dev] Making AsicBoost irrelevant 2016-05-10 20:27 ` Tier Nolan 2016-05-10 21:35 ` Matt Corallo @ 2016-05-10 21:43 ` Sergio Demian Lerner 2016-05-10 22:59 ` Matt Corallo ` (2 more replies) 1 sibling, 3 replies; 39+ messages in thread From: Sergio Demian Lerner @ 2016-05-10 21:43 UTC (permalink / raw) To: Tier Nolan, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 3934 bytes --] 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: > 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 > > [-- Attachment #2: Type: text/html, Size: 6163 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [bitcoin-dev] Making AsicBoost irrelevant 2016-05-10 21:43 ` Sergio Demian Lerner @ 2016-05-10 22:59 ` Matt Corallo 2016-05-11 12:20 ` Sergio Demian Lerner 2016-05-12 2:27 ` Tom Harding 2 siblings, 0 replies; 39+ messages in thread From: Matt Corallo @ 2016-05-10 22:59 UTC (permalink / raw) To: Sergio Demian Lerner, Bitcoin Protocol Discussion, Tier Nolan Replies inline. On 05/10/16 21:43, Sergio Demian Lerner via bitcoin-dev wrote: -snip- > 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. > 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. > 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? > 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 > ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [bitcoin-dev] Making AsicBoost irrelevant 2016-05-10 21:43 ` Sergio Demian Lerner 2016-05-10 22:59 ` Matt Corallo @ 2016-05-11 12:20 ` Sergio Demian Lerner 2016-05-11 13:08 ` Marek Palatinus 2016-05-11 14:28 ` Luke Dashjr 2016-05-12 2:27 ` Tom Harding 2 siblings, 2 replies; 39+ messages in thread From: Sergio Demian Lerner @ 2016-05-11 12:20 UTC (permalink / raw) To: Tier Nolan, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 542 bytes --] 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. [-- Attachment #2: Type: text/html, Size: 1081 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [bitcoin-dev] Making AsicBoost irrelevant 2016-05-11 12:20 ` Sergio Demian Lerner @ 2016-05-11 13:08 ` Marek Palatinus 2016-05-11 21:01 ` Matt Corallo 2016-05-11 14:28 ` Luke Dashjr 1 sibling, 1 reply; 39+ messages in thread From: Marek Palatinus @ 2016-05-11 13:08 UTC (permalink / raw) To: Sergio Demian Lerner, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1368 bytes --] 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: > > > 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 > > [-- Attachment #2: Type: text/html, Size: 2504 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [bitcoin-dev] Making AsicBoost irrelevant 2016-05-11 13:08 ` Marek Palatinus @ 2016-05-11 21:01 ` Matt Corallo 2016-05-11 22:16 ` Simon Liu 0 siblings, 1 reply; 39+ messages in thread From: Matt Corallo @ 2016-05-11 21:01 UTC (permalink / raw) To: Marek Palatinus, Bitcoin Protocol Discussion, Sergio Demian Lerner 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: > 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 > ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [bitcoin-dev] Making AsicBoost irrelevant 2016-05-11 21:01 ` Matt Corallo @ 2016-05-11 22:16 ` Simon Liu 2016-05-11 22:50 ` Peter Todd 0 siblings, 1 reply; 39+ messages in thread From: Simon Liu @ 2016-05-11 22:16 UTC (permalink / raw) To: Matt Corallo, Bitcoin Protocol Discussion, Marek Palatinus, Sergio Demian Lerner On 05/11/2016 02:01 PM, Matt Corallo via bitcoin-dev wrote: > 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. > 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [bitcoin-dev] Making AsicBoost irrelevant 2016-05-11 22:16 ` Simon Liu @ 2016-05-11 22:50 ` Peter Todd 0 siblings, 0 replies; 39+ messages in thread From: Peter Todd @ 2016-05-11 22:50 UTC (permalink / raw) To: Simon Liu, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 713 bytes --] On Wed, May 11, 2016 at 03:16:58PM -0700, Simon Liu via bitcoin-dev wrote: > > 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. -- https://petertodd.org 'peter'[:-1]@petertodd.org [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 455 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [bitcoin-dev] Making AsicBoost irrelevant 2016-05-11 12:20 ` Sergio Demian Lerner 2016-05-11 13:08 ` Marek Palatinus @ 2016-05-11 14:28 ` Luke Dashjr 2016-05-11 16:24 ` Timo Hanke 1 sibling, 1 reply; 39+ messages in thread From: Luke Dashjr @ 2016-05-11 14:28 UTC (permalink / raw) To: bitcoin-dev, Sergio Demian Lerner 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [bitcoin-dev] Making AsicBoost irrelevant 2016-05-11 14:28 ` Luke Dashjr @ 2016-05-11 16:24 ` Timo Hanke 2016-05-11 18:28 ` Timo Hanke 0 siblings, 1 reply; 39+ messages in thread From: Timo Hanke @ 2016-05-11 16:24 UTC (permalink / raw) To: Luke Dashjr, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1495 bytes --] 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 > [-- Attachment #2: Type: text/html, Size: 2390 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [bitcoin-dev] Making AsicBoost irrelevant 2016-05-11 16:24 ` Timo Hanke @ 2016-05-11 18:28 ` Timo Hanke 2016-05-11 22:49 ` Timo Hanke 0 siblings, 1 reply; 39+ messages in thread From: Timo Hanke @ 2016-05-11 18:28 UTC (permalink / raw) To: Luke Dashjr, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 2047 bytes --] 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 >> > > [-- Attachment #2: Type: text/html, Size: 3225 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [bitcoin-dev] Making AsicBoost irrelevant 2016-05-11 18:28 ` Timo Hanke @ 2016-05-11 22:49 ` Timo Hanke 0 siblings, 0 replies; 39+ messages in thread From: Timo Hanke @ 2016-05-11 22:49 UTC (permalink / raw) To: Luke Dashjr, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 2539 bytes --] 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: > 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 >>> >> >> > [-- Attachment #2: Type: text/html, Size: 3980 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [bitcoin-dev] Making AsicBoost irrelevant 2016-05-10 21:43 ` Sergio Demian Lerner 2016-05-10 22:59 ` Matt Corallo 2016-05-11 12:20 ` Sergio Demian Lerner @ 2016-05-12 2:27 ` Tom Harding 2016-05-12 2:31 ` Allen Piscitello 2016-05-12 2:33 ` Peter Todd 2 siblings, 2 replies; 39+ messages in thread From: Tom Harding @ 2016-05-12 2:27 UTC (permalink / raw) To: bitcoin-dev 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [bitcoin-dev] Making AsicBoost irrelevant 2016-05-12 2:27 ` Tom Harding @ 2016-05-12 2:31 ` Allen Piscitello 2016-05-12 2:33 ` Peter Todd 1 sibling, 0 replies; 39+ messages in thread From: Allen Piscitello @ 2016-05-12 2:31 UTC (permalink / raw) To: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 791 bytes --] 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: > 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 > [-- Attachment #2: Type: text/html, Size: 1398 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [bitcoin-dev] Making AsicBoost irrelevant 2016-05-12 2:27 ` Tom Harding 2016-05-12 2:31 ` Allen Piscitello @ 2016-05-12 2:33 ` Peter Todd 2016-05-12 4:01 ` Tom Harding 1 sibling, 1 reply; 39+ messages in thread From: Peter Todd @ 2016-05-12 2:33 UTC (permalink / raw) To: Tom Harding, Bitcoin Protocol Discussion, Tom Harding via bitcoin-dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11 May 2016 22:27:09 GMT-04:00, Tom Harding via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: >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). -----BEGIN PGP SIGNATURE----- iQE9BAEBCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJXM+tK AAoJEGOZARBE6K+yz4MH/j9TstqbVNG3nU+SJ9+Q9aZ0mZSQfR+4qgybGridjo7H TzGCnBVCLHt0LnbmZheFv/k9p+m2PojvGGKfODLIDFDHVPHv2wKflKIANIqxpXh/ Bl1SObDoKlRyby4fT22dW5SVSJsjVwTrYwTr2fmRfroeCLgJrHrr03AD7qmMf7CN MPrlpitLHZiEoSThTas3pTEEgL2EBgfZnxaaj96jQaMJloz0WjQaocllahl/gsme 40BQ9TnSHZ02bBf9iEN/FqGhrEN8m2JL7AEyOCuGwrWJtfQ5b9kSpL2QSpuXSfQ7 1d+OialY2G2L3QMPlnBMKdWGscUyapkYax3FmyA6wxI= =j9k+ -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [bitcoin-dev] Making AsicBoost irrelevant 2016-05-12 2:33 ` Peter Todd @ 2016-05-12 4:01 ` Tom Harding 0 siblings, 0 replies; 39+ messages in thread From: Tom Harding @ 2016-05-12 4:01 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 471 bytes --] On May 11, 2016 7:33 PM, "Peter Todd" <pete@petertodd•org> wrote: > 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. [-- Attachment #2: Type: text/html, Size: 594 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [bitcoin-dev] Making AsicBoost irrelevant 2016-05-10 18:57 [bitcoin-dev] Making AsicBoost irrelevant Peter Todd 2016-05-10 20:27 ` Tier Nolan @ 2016-05-10 21:49 ` Marco Pontello 2016-05-10 22:17 ` Sergio Demian Lerner 2016-05-11 3:14 ` Timo Hanke 3 siblings, 0 replies; 39+ messages in thread From: Marco Pontello @ 2016-05-10 21:49 UTC (permalink / raw) To: Peter Todd, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 407 bytes --] On Tue, May 10, 2016 at 8: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. > Just in the interest of clarity, I think you should clarify who you are including in the "we". Bye! [-- Attachment #2: Type: text/html, Size: 828 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [bitcoin-dev] Making AsicBoost irrelevant 2016-05-10 18:57 [bitcoin-dev] Making AsicBoost irrelevant Peter Todd 2016-05-10 20:27 ` Tier Nolan 2016-05-10 21:49 ` Marco Pontello @ 2016-05-10 22:17 ` Sergio Demian Lerner 2016-05-10 22:27 ` Chris Riley 2016-05-11 3:14 ` Timo Hanke 3 siblings, 1 reply; 39+ messages in thread From: Sergio Demian Lerner @ 2016-05-10 22:17 UTC (permalink / raw) To: Peter Todd, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1181 bytes --] 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 > > [-- Attachment #2: Type: text/html, Size: 2383 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [bitcoin-dev] Making AsicBoost irrelevant 2016-05-10 22:17 ` Sergio Demian Lerner @ 2016-05-10 22:27 ` Chris Riley 0 siblings, 0 replies; 39+ messages in thread From: Chris Riley @ 2016-05-10 22:27 UTC (permalink / raw) To: Sergio Demian Lerner, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1875 bytes --] 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: > > > 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 > > [-- Attachment #2: Type: text/html, Size: 4171 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [bitcoin-dev] Making AsicBoost irrelevant 2016-05-10 18:57 [bitcoin-dev] Making AsicBoost irrelevant Peter Todd ` (2 preceding siblings ...) 2016-05-10 22:17 ` Sergio Demian Lerner @ 2016-05-11 3:14 ` Timo Hanke 2016-05-11 9:21 ` Jannes Faber ` (3 more replies) 3 siblings, 4 replies; 39+ messages in thread From: Timo Hanke @ 2016-05-11 3:14 UTC (permalink / raw) To: Peter Todd, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 3307 bytes --] 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: > 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 > > [-- Attachment #2: Type: text/html, Size: 4533 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [bitcoin-dev] Making AsicBoost irrelevant 2016-05-11 3:14 ` Timo Hanke @ 2016-05-11 9:21 ` Jannes Faber 2016-05-11 10:36 ` Henning Kopp 2016-05-11 14:07 ` Jorge Timón ` (2 subsequent siblings) 3 siblings, 1 reply; 39+ messages in thread From: Jannes Faber @ 2016-05-11 9:21 UTC (permalink / raw) To: Timo Hanke, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1419 bytes --] 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. That hardware cannot “switch over” to the majority chain even if it wanted > to. > They will in fact continually "switch over" to the majority, they just are unable to extend that majority chain themselves. -- Jannes [-- Attachment #2: Type: text/html, Size: 1993 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [bitcoin-dev] Making AsicBoost irrelevant 2016-05-11 9:21 ` Jannes Faber @ 2016-05-11 10:36 ` Henning Kopp 2016-05-11 10:47 ` Jannes Faber 0 siblings, 1 reply; 39+ messages in thread From: Henning Kopp @ 2016-05-11 10:36 UTC (permalink / raw) To: Jannes Faber, Bitcoin Protocol Discussion 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. All the best Henning -- Henning Kopp Institute of Distributed Systems Ulm University, Germany Office: O27 - 3402 Phone: +49 731 50-24138 Web: http://www.uni-ulm.de/in/vs/~kopp ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [bitcoin-dev] Making AsicBoost irrelevant 2016-05-11 10:36 ` Henning Kopp @ 2016-05-11 10:47 ` Jannes Faber 2016-05-11 22:42 ` Timo Hanke 0 siblings, 1 reply; 39+ messages in thread From: Jannes Faber @ 2016-05-11 10:47 UTC (permalink / raw) To: Henning Kopp; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 2585 bytes --] 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). 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 [-- Attachment #2: Type: text/html, Size: 3302 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [bitcoin-dev] Making AsicBoost irrelevant 2016-05-11 10:47 ` Jannes Faber @ 2016-05-11 22:42 ` Timo Hanke 2016-05-11 22:58 ` Gregory Maxwell 2016-05-12 11:05 ` Jorge Timón 0 siblings, 2 replies; 39+ messages in thread From: Timo Hanke @ 2016-05-11 22:42 UTC (permalink / raw) To: Jannes Faber; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 3250 bytes --] On Wed, May 11, 2016 at 3:47 AM, Jannes Faber <jannes.faber@gmail•com> wrote: > 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). > 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 > [-- Attachment #2: Type: text/html, Size: 4469 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [bitcoin-dev] Making AsicBoost irrelevant 2016-05-11 22:42 ` Timo Hanke @ 2016-05-11 22:58 ` Gregory Maxwell 2016-05-12 7:29 ` Tom 2016-05-12 11:05 ` Jorge Timón 1 sibling, 1 reply; 39+ messages in thread From: Gregory Maxwell @ 2016-05-11 22:58 UTC (permalink / raw) To: Timo Hanke, Bitcoin Protocol Discussion 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. 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [bitcoin-dev] Making AsicBoost irrelevant 2016-05-11 22:58 ` Gregory Maxwell @ 2016-05-12 7:29 ` Tom 0 siblings, 0 replies; 39+ messages in thread From: Tom @ 2016-05-12 7:29 UTC (permalink / raw) To: bitcoin-dev, Gregory Maxwell On Wednesday 11 May 2016 22:58:48 Gregory Maxwell via bitcoin-dev wrote: > 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [bitcoin-dev] Making AsicBoost irrelevant 2016-05-11 22:42 ` Timo Hanke 2016-05-11 22:58 ` Gregory Maxwell @ 2016-05-12 11:05 ` Jorge Timón 1 sibling, 0 replies; 39+ messages in thread From: Jorge Timón @ 2016-05-12 11:05 UTC (permalink / raw) To: Timo Hanke, Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 891 bytes --] On May 12, 2016 00:43, "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). 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. [-- Attachment #2: Type: text/html, Size: 1027 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [bitcoin-dev] Making AsicBoost irrelevant 2016-05-11 3:14 ` Timo Hanke 2016-05-11 9:21 ` Jannes Faber @ 2016-05-11 14:07 ` Jorge Timón 2016-05-11 14:18 ` Sergio Demian Lerner 2016-05-11 20:50 ` Matt Corallo 2016-05-11 23:01 ` Peter Todd 3 siblings, 1 reply; 39+ messages in thread From: Jorge Timón @ 2016-05-11 14:07 UTC (permalink / raw) To: Timo Hanke, Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1205 bytes --] On May 11, 2016 05:15, "Timo Hanke via bitcoin-dev" < bitcoin-dev@lists•linuxfoundation.org> wrote: > > 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? > 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. > > 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? [-- Attachment #2: Type: text/html, Size: 1425 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [bitcoin-dev] Making AsicBoost irrelevant 2016-05-11 14:07 ` Jorge Timón @ 2016-05-11 14:18 ` Sergio Demian Lerner 2016-05-11 14:30 ` Jannes Faber 0 siblings, 1 reply; 39+ messages in thread From: Sergio Demian Lerner @ 2016-05-11 14:18 UTC (permalink / raw) To: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 310 bytes --] 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. [-- Attachment #2: Type: text/html, Size: 365 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [bitcoin-dev] Making AsicBoost irrelevant 2016-05-11 14:18 ` Sergio Demian Lerner @ 2016-05-11 14:30 ` Jannes Faber 0 siblings, 0 replies; 39+ messages in thread From: Jannes Faber @ 2016-05-11 14:30 UTC (permalink / raw) To: Sergio Demian Lerner, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1250 bytes --] On 11 May 2016 at 16:18, Sergio Demian Lerner via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > 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. [-- Attachment #2: Type: text/html, Size: 1754 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [bitcoin-dev] Making AsicBoost irrelevant 2016-05-11 3:14 ` Timo Hanke 2016-05-11 9:21 ` Jannes Faber 2016-05-11 14:07 ` Jorge Timón @ 2016-05-11 20:50 ` Matt Corallo 2016-05-11 22:00 ` James Hilliard 2016-05-11 23:01 ` Peter Todd 3 siblings, 1 reply; 39+ messages in thread From: Matt Corallo @ 2016-05-11 20:50 UTC (permalink / raw) To: Timo Hanke, Bitcoin Protocol Discussion, Peter Todd 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 > ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [bitcoin-dev] Making AsicBoost irrelevant 2016-05-11 20:50 ` Matt Corallo @ 2016-05-11 22:00 ` James Hilliard 0 siblings, 0 replies; 39+ messages in thread From: James Hilliard @ 2016-05-11 22:00 UTC (permalink / raw) To: Matt Corallo, Bitcoin Protocol Discussion 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: > 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [bitcoin-dev] Making AsicBoost irrelevant 2016-05-11 3:14 ` Timo Hanke ` (2 preceding siblings ...) 2016-05-11 20:50 ` Matt Corallo @ 2016-05-11 23:01 ` Peter Todd 2016-05-12 0:02 ` Gregory Maxwell 3 siblings, 1 reply; 39+ messages in thread From: Peter Todd @ 2016-05-11 23:01 UTC (permalink / raw) To: Timo Hanke; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 3255 bytes --] On Tue, May 10, 2016 at 08:14:33PM -0700, Timo Hanke 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. 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. > 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. > 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). -- https://petertodd.org 'peter'[:-1]@petertodd.org [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 455 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [bitcoin-dev] Making AsicBoost irrelevant 2016-05-11 23:01 ` Peter Todd @ 2016-05-12 0:02 ` Gregory Maxwell 2016-05-12 1:23 ` Russell O'Connor 0 siblings, 1 reply; 39+ messages in thread From: Gregory Maxwell @ 2016-05-12 0:02 UTC (permalink / raw) To: Peter Todd, Bitcoin Protocol Discussion 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.) ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [bitcoin-dev] Making AsicBoost irrelevant 2016-05-12 0:02 ` Gregory Maxwell @ 2016-05-12 1:23 ` Russell O'Connor 2016-05-12 1:58 ` Peter Todd 2016-05-12 1:58 ` Matt Corallo 0 siblings, 2 replies; 39+ messages in thread From: Russell O'Connor @ 2016-05-12 1:23 UTC (permalink / raw) To: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1167 bytes --] 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 > [-- Attachment #2: Type: text/html, Size: 1836 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [bitcoin-dev] Making AsicBoost irrelevant 2016-05-12 1:23 ` Russell O'Connor @ 2016-05-12 1:58 ` Peter Todd 2016-05-12 1:58 ` Matt Corallo 1 sibling, 0 replies; 39+ messages in thread From: Peter Todd @ 2016-05-12 1:58 UTC (permalink / raw) To: Russell O'Connor, Bitcoin Protocol Discussion, Russell O'Connor via bitcoin-dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11 May 2016 21:23:21 GMT-04:00, Russell O'Connor via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: >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. -----BEGIN PGP SIGNATURE----- iQE9BAEBCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJXM+Mh AAoJEGOZARBE6K+yz4MH/RwBknvWv+/sXLcJop59gTgfphMlt2KRRDs37bOm+ptc 7eUK+70K6kT64gNEUqZPnYrdV/u1qMad6bo+5Xb3VYEN9jkaQfw6FnKbVJ2oRVSz 2iDgO+bAe92n72bEJobmMxBpvD8lv+OjCMkWANHT8wr2/toFa2+V7JPipeXkZzvq E5qxhfCHNgoIS55S3LkgAI1cUFMVeYf5yc0MsSzmU3sO29OPuqEWTOgVeDwKF3GS aNvMSEJeyZb0D4C7XPfwQmqhH6aWsno/7no/D7qYppgSWaP8JpwPW/ULGzfU9Fr9 WdwgD2bX3zgAA3dcNM1nJ4lkoqCuEm2I0dO6Cj39HjE= =M5NE -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [bitcoin-dev] Making AsicBoost irrelevant 2016-05-12 1:23 ` Russell O'Connor 2016-05-12 1:58 ` Peter Todd @ 2016-05-12 1:58 ` Matt Corallo 1 sibling, 0 replies; 39+ messages in thread From: Matt Corallo @ 2016-05-12 1:58 UTC (permalink / raw) To: Russell O'Connor, Bitcoin Protocol Discussion, Russell O'Connor via bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 1835 bytes --] 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: >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 [-- Attachment #2: Type: text/html, Size: 2813 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
end of thread, other threads:[~2016-05-12 11:05 UTC | newest] Thread overview: 39+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-05-10 18:57 [bitcoin-dev] Making AsicBoost irrelevant Peter Todd 2016-05-10 20:27 ` Tier Nolan 2016-05-10 21:35 ` Matt Corallo 2016-05-10 21:43 ` Sergio Demian Lerner 2016-05-10 22:59 ` Matt Corallo 2016-05-11 12:20 ` Sergio Demian Lerner 2016-05-11 13:08 ` Marek Palatinus 2016-05-11 21:01 ` Matt Corallo 2016-05-11 22:16 ` Simon Liu 2016-05-11 22:50 ` Peter Todd 2016-05-11 14:28 ` Luke Dashjr 2016-05-11 16:24 ` Timo Hanke 2016-05-11 18:28 ` Timo Hanke 2016-05-11 22:49 ` Timo Hanke 2016-05-12 2:27 ` Tom Harding 2016-05-12 2:31 ` Allen Piscitello 2016-05-12 2:33 ` Peter Todd 2016-05-12 4:01 ` Tom Harding 2016-05-10 21:49 ` Marco Pontello 2016-05-10 22:17 ` Sergio Demian Lerner 2016-05-10 22:27 ` Chris Riley 2016-05-11 3:14 ` Timo Hanke 2016-05-11 9:21 ` Jannes Faber 2016-05-11 10:36 ` Henning Kopp 2016-05-11 10:47 ` Jannes Faber 2016-05-11 22:42 ` Timo Hanke 2016-05-11 22:58 ` Gregory Maxwell 2016-05-12 7:29 ` Tom 2016-05-12 11:05 ` Jorge Timón 2016-05-11 14:07 ` Jorge Timón 2016-05-11 14:18 ` Sergio Demian Lerner 2016-05-11 14:30 ` Jannes Faber 2016-05-11 20:50 ` Matt Corallo 2016-05-11 22:00 ` James Hilliard 2016-05-11 23:01 ` Peter Todd 2016-05-12 0:02 ` Gregory Maxwell 2016-05-12 1:23 ` Russell O'Connor 2016-05-12 1:58 ` Peter Todd 2016-05-12 1:58 ` Matt Corallo
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox