From: Rusty Russell <rusty@rustcorp•com.au>
To: Peter Todd <pete@petertodd•org>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change
Date: Fri, 09 Oct 2015 12:08:06 +1030 [thread overview]
Message-ID: <87pp0okeip.fsf@rustcorp.com.au> (raw)
In-Reply-To: <20151008174120.GA9291@muck>
Peter Todd <pete@petertodd•org> writes:
> On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote:
>> Peter Todd via bitcoin-dev <bitcoin-dev@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.
next prev parent reply other threads:[~2015-10-09 4:31 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-03 14:30 Peter Todd
2015-10-03 18:49 ` jl2012
2015-10-04 8:35 ` Anthony Towns
2015-10-04 12:04 ` s7r
2015-10-05 22:03 ` Alex Morcos
2015-10-06 0:19 ` Mark Friedenbach
2015-10-06 11:09 ` Peter Todd
2015-10-06 0:28 ` Btc Drak
2015-10-06 1:58 ` Rusty Russell
2015-10-08 17:41 ` Peter Todd
2015-10-09 1:38 ` Rusty Russell [this message]
2015-10-15 13:47 ` Alex Morcos
2015-10-15 16:27 ` Btc Drak
2015-10-15 16:37 ` Adam Back
2015-10-15 16:41 ` Alex Morcos
2015-10-15 18:31 ` Mark Friedenbach
2015-10-15 23:18 ` Rusty Russell
2015-10-16 1:26 ` Rusty Russell
2015-10-19 10:43 ` Jorge Timón
2015-10-06 20:00 ` Joseph Poon
2015-10-08 17:43 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87pp0okeip.fsf@rustcorp.com.au \
--to=rusty@rustcorp$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pete@petertodd$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox