Re: [bitcoin-dev] Making AsicBoost irrelevant

2016-05-10 Thread Tier Nolan via bitcoin-dev
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

Re: [bitcoin-dev] Making AsicBoost irrelevant

2016-05-10 Thread Sergio Demian Lerner via bitcoin-dev
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

Re: [bitcoin-dev] Making AsicBoost irrelevant

2016-05-10 Thread Chris Riley via bitcoin-dev
The second like "2)" has a link to the paper: http://www.math.rwth-aachen.de/~Timo.Hanke/AsicBoostWhitepaperrev5.pdf which does discuss the fact that it is "patent-pending". Likewise it discusses ASIC improvements. Avoiding patents that impact bitcoin and are not freely licensed, is something

Re: [bitcoin-dev] Making AsicBoost irrelevant

2016-05-10 Thread Marco Pontello via bitcoin-dev
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

2016-05-10 Thread Matt Corallo via bitcoin-dev
Yea, I think in any hardfork that we should be talking about, a part of it should include 1) fix the version field so its a static constant, 2) the merkle root becomes hash of the real block header 3) swap first 2 bytes of the merkle root with the timestamp's two high-order bits, 4) swap the next

Re: [bitcoin-dev] Making AsicBoost irrelevant

2016-05-10 Thread Sergio Demian Lerner via bitcoin-dev
Your idea of moving the Merkle root to the second chunk does not work. The AsicBoost can change the version bits and it does not need to find a collision. (However *Spondoolies patent *only mentions Merkle collisions:

Re: [bitcoin-dev] Making AsicBoost irrelevant

2016-05-10 Thread Matt Corallo via bitcoin-dev
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] Compact Block Relay BIP

2016-05-10 Thread Rusty Russell via bitcoin-dev
Gregory Maxwell writes: > On Tue, May 10, 2016 at 5:28 AM, Rusty Russell via bitcoin-dev > wrote: >> I used variable-length bit encodings, and used the shortest encoding >> which is unique to you (including mempool). It's a little more work,

Re: [bitcoin-dev] Compact Block Relay BIP

2016-05-10 Thread Matt Corallo via bitcoin-dev
Replies inline. On May 10, 2016 5:23:55 PM EDT, Rusty Russell via bitcoin-dev wrote: >Gregory Maxwell writes: >> On Tue, May 10, 2016 at 5:28 AM, Rusty Russell via bitcoin-dev >> wrote: >>> I used

Re: [bitcoin-dev] Making AsicBoost irrelevant

2016-05-10 Thread Timo Hanke via bitcoin-dev
There is no way to tell from a block if it was mined with AsicBoost or not. So you don’t know what percentage of the hashrate uses AsicBoost at any point in time. How can you risk forking that percentage out? Note that this would be a GUARANTEED chain fork. Meaning that after you change the block