📅 Original date posted:2015-10-08
📝 Original message:Peter Todd <pete at petertodd.org> writes:
> On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote:
>> Peter Todd via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
>> writes:
>> > However I don't think we've done a good job showing why we need to
>> > implement this feature via nSequence.
>>
>> It could be implemented in other ways, but nSequence is the neatest and
>> most straightforward I've seen.
>>
>> - I'm not aware of any other (even vague) proposal for its use? Enlighten?
>
> There's three that immediately come to mind:
>
> Gregory Maxwell has proposed it as a way of discouraging miners from
> reorging chains, by including some of the low-order bits of a previous
> block header in nSequence.
>
> A few people have proposed implementing proof-of-stake blocksize voting
> with nSequence.
Excellent, thanks! It's good to have such ideas as a compass. PoS
voting seems like it won't be a problem in 5 bits.
The "prevbits" idea would want more bits; naively 64 would be good, but
I think there are some tricks we can use to make 32 work OK. We would
have to then split between nLocktime (if available) and multiple
nSequence fields, and it would weaken it for some txs.
There is one easy solution: change the BIP wording from:
-For transactions with an nVersion of 2 or greater,
+For transactions with an nVersion of 2,
And on every tx bump, we decide whether to keep this scheme (mempool
would enforce it always).
Cheers,
Rusty.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-07 17:42:28
in reply to nevent1q…gtfu
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-07 17:42:28Event JSON
{
"id": "05a0ed8541b75d35d20ee28642eda51001d77b61b34841bc2b157502051eae70",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686159748,
"kind": 1,
"tags": [
[
"e",
"cd753793d8b3cbb49eaba9a2f4a53184f03e5acc23bc580b4ff40cab73993d1e",
"",
"root"
],
[
"e",
"17f8f72752f3f661819da9d14d70f7e2ed28efcf610a7a5f2c5d62702d6e189a",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2015-10-08\n📝 Original message:Peter Todd \u003cpete at petertodd.org\u003e writes:\n\u003e On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote:\n\u003e\u003e Peter Todd via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e\u003e writes:\n\u003e\u003e \u003e However I don't think we've done a good job showing why we need to\n\u003e\u003e \u003e implement this feature via nSequence.\n\u003e\u003e \n\u003e\u003e It could be implemented in other ways, but nSequence is the neatest and\n\u003e\u003e most straightforward I've seen.\n\u003e\u003e \n\u003e\u003e - I'm not aware of any other (even vague) proposal for its use? Enlighten?\n\u003e\n\u003e There's three that immediately come to mind:\n\u003e\n\u003e Gregory Maxwell has proposed it as a way of discouraging miners from\n\u003e reorging chains, by including some of the low-order bits of a previous\n\u003e block header in nSequence.\n\u003e\n\u003e A few people have proposed implementing proof-of-stake blocksize voting\n\u003e with nSequence.\n\nExcellent, thanks! It's good to have such ideas as a compass. PoS\nvoting seems like it won't be a problem in 5 bits.\n\nThe \"prevbits\" idea would want more bits; naively 64 would be good, but\nI think there are some tricks we can use to make 32 work OK. We would\nhave to then split between nLocktime (if available) and multiple\nnSequence fields, and it would weaken it for some txs.\n\nThere is one easy solution: change the BIP wording from:\n\n-For transactions with an nVersion of 2 or greater,\n+For transactions with an nVersion of 2, \n\nAnd on every tx bump, we decide whether to keep this scheme (mempool\nwould enforce it always).\n\nCheers,\nRusty.",
"sig": "63ce70f587fd4a3e00b11393d25cd4f6d680bbf74ee0ccb65c56e8ea3c56201811ffc4c27e9af936390de0f1e04c959a6babe8f0c6a518199c9f66e839f572c1"
}