Jimmy Song [ARCHIVE] on Nostr: đź“… Original date posted:2017-04-08 đź“ť Original message:> > I think it might be ...
đź“… Original date posted:2017-04-08
đź“ť Original message:>
> 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 <jaejoon at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170408/0b4e08ad/attachment.html>;
đź“ť Original message:>
> 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 <jaejoon at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170408/0b4e08ad/attachment.html>;