📅 Original date posted:2017-04-11
📝 Original message:On Tue, Apr 11, 2017 at 4:40 PM, Jimmy Song via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I've changed the proposal so only 8 bits are given to grinding so something
> like 20 bits are available for signaling.
>
> I have to say I'm at a loss here as to what's next? Should I make a new BIP
> or try to convince the authors of BIP141 to modify their BIP? Could someone
> inform me on the next part of the process?
See bip2, specifically
https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#bip-workflow
"Following a discussion, the proposal should be submitted to the BIPs
git repository as a pull request. This draft must be written in BIP
style as described below, and named with an alias such as
"bip-johndoe-infinitebitcoins" until the editor has assigned it a BIP
number (authors MUST NOT self-assign BIP numbers)."
But I think it's kind of late to modify bip141, given that there's
code out there with the current specification.
I guess you can propose extensions or alternatives to replace it. I'm
really not sure what's the next step, but I don't think you have
provided enough motivation as to why we would want to maintain
asicboost. You said it makes the network more secure, but that's not
the case, as explained, not even if all honest miners use it.
> On Tue, Apr 11, 2017 at 8:25 AM, Sancho Panza via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Tom Zander wrote:
>>
>> > The version field is still needed to actually allow future block version
>> > upgrades. We would cut off our road forward if that were to be blocked.
>>
>> I tend to agree, if all 32 bits were given up to grinding.
>>
>> But it's worth pointing out that BIP9 is purely informational, and the top
>> 3 bits are still reserved for other purposes. One of them could perhaps be
>> used to signal for an extended version field somewhere else, leaving the
>> bottom 29 as entropy?
>>
>> Not a direction I prefer, but just a technical possibility perhaps.
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
Jorge Timón [ARCHIVE] /
npub1fx…cl2d8
2023-06-07 17:59:54
in reply to nevent1q…ulm7
Author Public Key
npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8Published at
2023-06-07 17:59:54Event JSON
{
"id": "4260c8d8f349a3fee4adc7f3125ea51ba236361950ee14b8502a185b61890d24",
"pubkey": "498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84",
"created_at": 1686160794,
"kind": 1,
"tags": [
[
"e",
"b3abda28c58fcdd36a7f3d79347d12387effc8cb5f326fca3c05e821d4348755",
"",
"root"
],
[
"e",
"3977372d189add82868bc973ab9ffc481f4a061477df7935bf97f02011027169",
"",
"reply"
],
[
"p",
"f38e3745cbc0df11360d95f78947ce7a35ff1510807f9fae029e4cdb2d8f039e"
]
],
"content": "📅 Original date posted:2017-04-11\n📝 Original message:On Tue, Apr 11, 2017 at 4:40 PM, Jimmy Song via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e I've changed the proposal so only 8 bits are given to grinding so something\n\u003e like 20 bits are available for signaling.\n\u003e\n\u003e I have to say I'm at a loss here as to what's next? Should I make a new BIP\n\u003e or try to convince the authors of BIP141 to modify their BIP? Could someone\n\u003e inform me on the next part of the process?\n\nSee bip2, specifically\nhttps://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#bip-workflow\n\n\"Following a discussion, the proposal should be submitted to the BIPs\ngit repository as a pull request. This draft must be written in BIP\nstyle as described below, and named with an alias such as\n\"bip-johndoe-infinitebitcoins\" until the editor has assigned it a BIP\nnumber (authors MUST NOT self-assign BIP numbers).\"\n\nBut I think it's kind of late to modify bip141, given that there's\ncode out there with the current specification.\nI guess you can propose extensions or alternatives to replace it. I'm\nreally not sure what's the next step, but I don't think you have\nprovided enough motivation as to why we would want to maintain\nasicboost. You said it makes the network more secure, but that's not\nthe case, as explained, not even if all honest miners use it.\n\n\u003e On Tue, Apr 11, 2017 at 8:25 AM, Sancho Panza via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e Tom Zander wrote:\n\u003e\u003e\n\u003e\u003e \u003e The version field is still needed to actually allow future block version\n\u003e\u003e \u003e upgrades. We would cut off our road forward if that were to be blocked.\n\u003e\u003e\n\u003e\u003e I tend to agree, if all 32 bits were given up to grinding.\n\u003e\u003e\n\u003e\u003e But it's worth pointing out that BIP9 is purely informational, and the top\n\u003e\u003e 3 bits are still reserved for other purposes. One of them could perhaps be\n\u003e\u003e used to signal for an extended version field somewhere else, leaving the\n\u003e\u003e bottom 29 as entropy?\n\u003e\u003e\n\u003e\u003e Not a direction I prefer, but just a technical possibility perhaps.\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\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",
"sig": "961e60101b1c12df35a0027ca922d6ba04d9930634495f6d5766c13f3e6bf0394aba190fb8b5f6057d9a49f846f8ad462cd73d24b65fbee7f62d3544a1f2f797"
}