š
Original date posted:2015-10-08
š Original message: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.
> - BIP68 reserves much of it for future use already.
Well, a few low-order bits, if you want to use RCLTV functionality; pure
RCLTV would save a lot more bits.
> If we apply infinite caution we could never use nSequence, as there
> might be a better use tommorrow.
Indeed! But lets make sure we have a good argument in the BIP.
--
'peter'[:-1]@petertodd.org
00000000000000000de60f807a5fd32057510e7715038ecbc888052861b6a5c1
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151008/f6069c67/attachment.sig>;
Peter Todd [ARCHIVE] /
npub1m2ā¦a2np2
2023-06-07 17:42:28
in reply to nevent1qā¦7htl
Author Public Key
npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2Published at
2023-06-07 17:42:28Event JSON
{
"id": "17f8f72752f3f661819da9d14d70f7e2ed28efcf610a7a5f2c5d62702d6e189a",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1686159748,
"kind": 1,
"tags": [
[
"e",
"cd753793d8b3cbb49eaba9a2f4a53184f03e5acc23bc580b4ff40cab73993d1e",
"",
"root"
],
[
"e",
"3a7b4ca2befdae7aa008ba7ce40068eb29b0fe2d97333f920f9781850e32cd08",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "š
Original date posted:2015-10-08\nš Original message:On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote:\n\u003e Peter Todd via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e writes:\n\u003e \u003e However I don't think we've done a good job showing why we need to\n\u003e \u003e implement this feature via nSequence.\n\u003e \n\u003e It could be implemented in other ways, but nSequence is the neatest and\n\u003e most straightforward I've seen.\n\u003e \n\u003e - I'm not aware of any other (even vague) proposal for its use? Enlighten?\n\nThere's three that immediately come to mind:\n\nGregory Maxwell has proposed it as a way of discouraging miners from\nreorging chains, by including some of the low-order bits of a previous\nblock header in nSequence.\n\nA few people have proposed implementing proof-of-stake blocksize voting\nwith nSequence.\n\n\u003e - BIP68 reserves much of it for future use already.\n\nWell, a few low-order bits, if you want to use RCLTV functionality; pure\nRCLTV would save a lot more bits.\n\n\u003e If we apply infinite caution we could never use nSequence, as there\n\u003e might be a better use tommorrow.\n\nIndeed! But lets make sure we have a good argument in the BIP.\n\n-- \n'peter'[:-1]@petertodd.org\n00000000000000000de60f807a5fd32057510e7715038ecbc888052861b6a5c1\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 650 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151008/f6069c67/attachment.sig\u003e",
"sig": "4898a94ac04ca6c02ebc44fe987fb2c14795514c1c904a68055793beb2a31f2492427aab0e2f984d74c2a7eec87ac61dc4aa3ab0e2faf15a278f371b0107b47e"
}