> > I think it might be important that the mandatory commitment expire as in > Greg's proposal - when we do eventually hardfork, it will be simpler to do > in > a safe manner if such a commitment in the fake "old block" is not required. >
OK, that makes sense. I'll modify my proposal this way: Beginning block X and until block Y the coinbase transaction of each block MUST contain a BIP-141 segwit commitment > I don't like your proposal because it allows ASICBoost. ASICBoost > effectively > makes SHA2 semi-ASIC-resistant. ASIC-resistance raises the barrier of > entry to > new mining chip manufacturers, and gives a larger advantage to the miners > able > to make use of it. Instead, IMO we should fix the vulnerability exploited > by > ASICBoost entirely to keep SHA2 as ASIC-friendly as possible - or change > the > PoW to an algorithm that is more ASIC-friendly. > Overt ASICBoost is allowed on the network already. Until a proposal explicitly blocking overt ASICBoost as a soft fork is activated, this seems to be better than the current state which is that overt ASICBoost is allowed, but at a cost to BIP9 signals. Jimmy > That being said, I don't think I would oppose the proposal if it gained > notably better support than Segwit currently has (as yet another > compromise), > and the above concerns were addressed (eg, Bitfury and Canaan state they > can > compete using ASICBoost and the patents are licensed freely to everyone). > > Luke > > > On Saturday, April 08, 2017 12:05:16 AM Jimmy Song via bitcoin-dev wrote: > > I've gotten feedback from Adam Back that you actually don't need all 32 > > bits in the header for overt ASICBoost, so I'm modifying my proposal. Of > > the 32-bit version field, bits 16 to 23 are reserved for miners, the > > witness commitment stays as defined in BIP-141 except that it's now > > required. BIP9 then is modified so that bits 16 to 23 are now no longer > > usable. > > > > On Fri, Apr 7, 2017 at 3:06 PM, Jimmy Song <jaej...@gmail.com> wrote: > > > Hey everyone, This is an idea that I had about Segwit and Gregory's > > > proposal from yesterday that I wanted to run by everyone on this list. > > > I'm not at all sure what this would mean for non-upgraded nodes on the > > > network and would like feedback on that. This is not a formal BIP as > > > it's a modification to a previously submitted one, but I'm happy to > > > formalize it if it would help. > > > ---------------------------------------- > > > MotivationOne of the interesting aspects of Gregory Maxwell’s proposal > is > > > that it only precludes the covert version of ASICBoost. He specifically > > > left the overt version alone. > > > > > > Overt ASICBoost requires grinding on the version bits of the Block > header > > > instead of the Merkle Root. This is likely more efficient than the > Merkle > > > Root grinding (aka covert ASICBoost) and requires way less resources > > > (much less RAM, SHA256 calculations, no tx shuffling, etc). > > > > > > If we combine Gregory Maxwell’s proposal with BIP-141 (Segwit) and add > a > > > slight modification, this should, in theory, make ASICBoost a lot more > > > useful to miners and appeal to their financial interests. > > > The Modification > > > > > > Currently, the version bits (currently 4 bytes, or 32 bits) in the > header > > > are used for BIP9 signaling. We change the version bits to a > nonce-space > > > so the miners can use it for overt ASICBoost. The 32-bits are now moved > > > over to the Coinbase transaction as part of the witness commitment. The > > > witness commitment goes from 38 bytes to 42 bytes, with the last 4 > bytes > > > being used as the version bits in the block header previously. The > > > witness commitment becomes required as per Gregory Maxwell’s proposal. > > > Reasoning > > > > > > First, this brings ASICBoost out into the open. Covert ASICBoost > becomes > > > much more costly and overt ASICBoost is now encouraged. > > > > > > Second, we can make this change relatively quickly. Most of the Segwit > > > testing stays valid and this change can be deployed relatively quickly. > > > > > > Note on SPV clients > > > > > > Currently Segwit stores the witness commitment in the Coinbase tx, so > > > lightweight clients will need to get the Coinbase tx + Merkle proof to > > > validate segwit transactions anyway. Putting block version information > in > > > the Coinbase tx will not impose an extra burden on upgraded light > > > clients. >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
