Re: [bitcoin-dev] Making AsicBoost irrelevant

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

Re: [bitcoin-dev] Making AsicBoost irrelevant

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

Re: [bitcoin-dev] Making AsicBoost irrelevant

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 11 May 2016 22:27:09 GMT-04:00, Tom Harding via bitcoin-dev 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

Re: [bitcoin-dev] Making AsicBoost irrelevant

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

Re: [bitcoin-dev] Making AsicBoost irrelevant

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 11 May 2016 21:23:21 GMT-04:00, Russell O'Connor via bitcoin-dev wrote: >Is the design and manufacturing processes for the most power efficient >ASICs otherwise patent unencumbered? If not, why do we

Re: [bitcoin-dev] Making AsicBoost irrelevant

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

Re: [bitcoin-dev] Making AsicBoost irrelevant

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,

Re: [bitcoin-dev] Making AsicBoost irrelevant

On Wed, May 11, 2016 at 11:01 PM, Peter Todd via bitcoin-dev 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

Re: [bitcoin-dev] Making AsicBoost irrelevant

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

Re: [bitcoin-dev] Making AsicBoost irrelevant

On Wed, May 11, 2016 at 10:42 PM, Timo Hanke via bitcoin-dev 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

Re: [bitcoin-dev] Making AsicBoost irrelevant

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

Re: [bitcoin-dev] Making AsicBoost irrelevant

On Wed, May 11, 2016 at 3:47 AM, Jannes Faber wrote: > On 11 May 2016 at 12:36, Henning Kopp 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 <

Re: [bitcoin-dev] Making AsicBoost irrelevant

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 wrote: > That's the reason for this post! All current major ASIC

Re: [bitcoin-dev] Making AsicBoost irrelevant

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

Re: [bitcoin-dev] Making AsicBoost irrelevant

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

Re: [bitcoin-dev] Making AsicBoost irrelevant

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

Re: [bitcoin-dev] Making AsicBoost irrelevant

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

Re: [bitcoin-dev] Making AsicBoost irrelevant

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

Re: [bitcoin-dev] Making AsicBoost irrelevant

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.ler...@gmail.com> wrote: > > You can find it here: > > https://bitslog.wordpress.com/2014/03/18/the-re-design-of-the-bitcoin-blo > > ck-header/ >

Re: [bitcoin-dev] Making AsicBoost irrelevant

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

Re: [bitcoin-dev] Making AsicBoost irrelevant

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

Re: [bitcoin-dev] Making AsicBoost irrelevant

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

Re: [bitcoin-dev] Making AsicBoost irrelevant

On Tue, May 10, 2016 at 6:43 PM, Sergio Demian Lerner < sergio.d.ler...@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

Re: [bitcoin-dev] Making AsicBoost irrelevant

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

Re: [bitcoin-dev] Making AsicBoost irrelevant

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

Re: [bitcoin-dev] Making AsicBoost irrelevant

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

Re: [bitcoin-dev] Making AsicBoost irrelevant

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

Re: [bitcoin-dev] Making AsicBoost irrelevant

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

Re: [bitcoin-dev] Making AsicBoost irrelevant

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

Re: [bitcoin-dev] Making AsicBoost irrelevant

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:

Re: [bitcoin-dev] Making AsicBoost irrelevant

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

Re: [bitcoin-dev] Making AsicBoost irrelevant

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