đź“… Original date posted:2017-04-08
đź“ť Original message:Yes, you only need a few bits in the version number, probably less than 8.
If you encourage the overt method of using AsicBoost I would argue that you
no longer need to dis-encourage the couvert method anymore as in Greg's
proposal. Nobody would use the couvert method anyway because the overt
method is so much simpler. So maybe the proposals can be completely
disentangled?
On Fri, Apr 7, 2017 at 5:05 PM, Jimmy Song via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> 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.
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170408/47873dc2/attachment-0001.html>;
Timo Hanke [ARCHIVE] /
npub1dd…pgp9a
2023-06-07 17:59:46
in reply to nevent1q…4l0k
Author Public Key
npub1ddqaln8xsfmy6sxqplt9sz5ev99kh052sveqsh02q7hmc3a6n68shpgp9aPublished at
2023-06-07 17:59:46Event JSON
{
"id": "dd99ccf3ae77c4335edcf51652e2ba7319e7989e11e2a4f60ffa717a60e844e8",
"pubkey": "6b41dfcce682764d40c00fd6580a99614b6bbe8a8332085dea07afbc47ba9e8f",
"created_at": 1686160786,
"kind": 1,
"tags": [
[
"e",
"b3abda28c58fcdd36a7f3d79347d12387effc8cb5f326fca3c05e821d4348755",
"",
"root"
],
[
"e",
"5a1d949230b745d2a4e53719b848b3b445b260eb21a932296ad168962786a9b0",
"",
"reply"
],
[
"p",
"f38e3745cbc0df11360d95f78947ce7a35ff1510807f9fae029e4cdb2d8f039e"
]
],
"content": "📅 Original date posted:2017-04-08\n📝 Original message:Yes, you only need a few bits in the version number, probably less than 8.\n\nIf you encourage the overt method of using AsicBoost I would argue that you\nno longer need to dis-encourage the couvert method anymore as in Greg's\nproposal. Nobody would use the couvert method anyway because the overt\nmethod is so much simpler. So maybe the proposals can be completely\ndisentangled?\n\n\nOn Fri, Apr 7, 2017 at 5:05 PM, Jimmy Song via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e I've gotten feedback from Adam Back that you actually don't need all 32\n\u003e bits in the header for overt ASICBoost, so I'm modifying my proposal. Of\n\u003e the 32-bit version field, bits 16 to 23 are reserved for miners, the\n\u003e witness commitment stays as defined in BIP-141 except that it's now\n\u003e required. BIP9 then is modified so that bits 16 to 23 are now no longer\n\u003e usable.\n\u003e\n\u003e On Fri, Apr 7, 2017 at 3:06 PM, Jimmy Song \u003cjaejoon at gmail.com\u003e wrote:\n\u003e\n\u003e\u003e Hey everyone, This is an idea that I had about Segwit and Gregory's\n\u003e\u003e proposal from yesterday that I wanted to run by everyone on this list. I'm\n\u003e\u003e not at all sure what this would mean for non-upgraded nodes on the network\n\u003e\u003e and would like feedback on that. This is not a formal BIP as it's a\n\u003e\u003e modification to a previously submitted one, but I'm happy to formalize it\n\u003e\u003e if it would help.\n\u003e\u003e ----------------------------------------\n\u003e\u003e MotivationOne of the interesting aspects of Gregory Maxwell’s proposal\n\u003e\u003e is that it only precludes the covert version of ASICBoost. He\n\u003e\u003e specifically left the overt version alone.\n\u003e\u003e\n\u003e\u003e Overt ASICBoost requires grinding on the version bits of the Block\n\u003e\u003e header instead of the Merkle Root. This is likely more efficient than the\n\u003e\u003e Merkle Root grinding (aka covert ASICBoost) and requires way less\n\u003e\u003e resources (much less RAM, SHA256 calculations, no tx shuffling, etc).\n\u003e\u003e\n\u003e\u003e If we combine Gregory Maxwell’s proposal with BIP-141 (Segwit) and add a\n\u003e\u003e slight modification, this should, in theory, make ASICBoost a lot more\n\u003e\u003e useful to miners and appeal to their financial interests.\n\u003e\u003e The Modification\n\u003e\u003e\n\u003e\u003e Currently, the version bits (currently 4 bytes, or 32 bits) in the header\n\u003e\u003e are used for BIP9 signaling. We change the version bits to a nonce-space so\n\u003e\u003e the miners can use it for overt ASICBoost. The 32-bits are now moved\n\u003e\u003e over to the Coinbase transaction as part of the witness commitment. The\n\u003e\u003e witness commitment goes from 38 bytes to 42 bytes, with the last 4 bytes\n\u003e\u003e being used as the version bits in the block header previously. The witness\n\u003e\u003e commitment becomes required as per Gregory Maxwell’s proposal.\n\u003e\u003e Reasoning\n\u003e\u003e\n\u003e\u003e First, this brings ASICBoost out into the open. Covert ASICBoost becomes\n\u003e\u003e much more costly and overt ASICBoost is now encouraged.\n\u003e\u003e\n\u003e\u003e Second, we can make this change relatively quickly. Most of the Segwit\n\u003e\u003e testing stays valid and this change can be deployed relatively quickly.\n\u003e\u003e\n\u003e\u003e Note on SPV clients\n\u003e\u003e\n\u003e\u003e Currently Segwit stores the witness commitment in the Coinbase tx, so\n\u003e\u003e lightweight clients will need to get the Coinbase tx + Merkle proof to\n\u003e\u003e validate segwit transactions anyway. Putting block version information in\n\u003e\u003e the Coinbase tx will not impose an extra burden on upgraded light clients.\n\u003e\u003e\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170408/47873dc2/attachment-0001.html\u003e",
"sig": "136cf2404feb104f4811202fb8f32163a3e8a065b794080750bae04c47ac48472b1992e2a66631d0341b2834442798b320f904ae5be17074093e3557eb85af5f"
}