[bitcoin-dev] Making AsicBoost irrelevant

[bitcoin-dev] Making AsicBoost irrelevant

[Peter Todd]

[-- 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 --]

Re: [bitcoin-dev] Making AsicBoost irrelevant

[Tier Nolan]

[-- 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 --]

Re: [bitcoin-dev] Making AsicBoost irrelevant

[Matt Corallo]

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
> 

Re: [bitcoin-dev] Making AsicBoost irrelevant

[Sergio Demian Lerner]

[-- 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 --]

Re: [bitcoin-dev] Making AsicBoost irrelevant

[Matt Corallo]

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
> 

Re: [bitcoin-dev] Making AsicBoost irrelevant

[Sergio Demian Lerner]

[-- 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 --]

Re: [bitcoin-dev] Making AsicBoost irrelevant

[Marek Palatinus]

[-- 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 --]

Re: [bitcoin-dev] Making AsicBoost irrelevant

[Matt Corallo]

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
> 

Re: [bitcoin-dev] Making AsicBoost irrelevant

[Simon Liu]

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

Re: [bitcoin-dev] Making AsicBoost irrelevant

[Peter Todd]

[-- 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 --]

Re: [bitcoin-dev] Making AsicBoost irrelevant

[Luke Dashjr]

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

Re: [bitcoin-dev] Making AsicBoost irrelevant

[Timo Hanke]

[-- 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 --]

Re: [bitcoin-dev] Making AsicBoost irrelevant

[Timo Hanke]

[-- 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 --]

Re: [bitcoin-dev] Making AsicBoost irrelevant

[Timo Hanke]

[-- 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 --]

Re: [bitcoin-dev] Making AsicBoost irrelevant

[Tom Harding]

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.

Re: [bitcoin-dev] Making AsicBoost irrelevant

[Allen Piscitello]

[-- 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 --]

Re: [bitcoin-dev] Making AsicBoost irrelevant

[Peter Todd]

-----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-----

Re: [bitcoin-dev] Making AsicBoost irrelevant

[Tom Harding]

[-- 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 --]

Re: [bitcoin-dev] Making AsicBoost irrelevant

[Marco Pontello]

[-- 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 --]

Re: [bitcoin-dev] Making AsicBoost irrelevant

[Sergio Demian Lerner]

[-- 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 --]

Re: [bitcoin-dev] Making AsicBoost irrelevant

[Chris Riley]

[-- 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 --]

Re: [bitcoin-dev] Making AsicBoost irrelevant

[Timo Hanke]

[-- 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 --]

Re: [bitcoin-dev] Making AsicBoost irrelevant

[Jannes Faber]

[-- 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 --]

Re: [bitcoin-dev] Making AsicBoost irrelevant

[Henning Kopp]

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

Re: [bitcoin-dev] Making AsicBoost irrelevant

[Jannes Faber]

[-- 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 --]

Re: [bitcoin-dev] Making AsicBoost irrelevant

[Timo Hanke]

[-- 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 --]

Re: [bitcoin-dev] Making AsicBoost irrelevant

[Gregory Maxwell]

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.

Re: [bitcoin-dev] Making AsicBoost irrelevant

[Tom]

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.

Re: [bitcoin-dev] Making AsicBoost irrelevant

[Jorge Timón]

[-- 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 --]

Re: [bitcoin-dev] Making AsicBoost irrelevant

[Jorge Timón]

[-- 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 --]

Re: [bitcoin-dev] Making AsicBoost irrelevant

[Sergio Demian Lerner]

[-- 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 --]

Re: [bitcoin-dev] Making AsicBoost irrelevant

[Jannes Faber]

[-- 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 --]

Re: [bitcoin-dev] Making AsicBoost irrelevant

[Matt Corallo]

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
> 

Re: [bitcoin-dev] Making AsicBoost irrelevant

[James Hilliard]

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

Re: [bitcoin-dev] Making AsicBoost irrelevant

[Peter Todd]

[-- 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 --]

Re: [bitcoin-dev] Making AsicBoost irrelevant

[Gregory Maxwell]

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.)

Re: [bitcoin-dev] Making AsicBoost irrelevant

[Russell O'Connor]

[-- 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 --]

Re: [bitcoin-dev] Making AsicBoost irrelevant

[Peter Todd]

-----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-----

Re: [bitcoin-dev] Making AsicBoost irrelevant

[Matt Corallo]

[-- 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 --]