From: Peter Todd <pete@petertodd•org>
To: Mark Friedenbach <mark@friedenbach•org>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] CLTV/CSV/etc. deployment considerations due to XT/Not-BitcoinXT miners
Date: Wed, 19 Aug 2015 14:03:14 -0700 [thread overview]
Message-ID: <20150819210314.GA31482@muck> (raw)
In-Reply-To: <CAOG=w-uCPnSv9XxWLBteCFjU9B6Kg7RpFb=UknehMVPMUc0nag@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3201 bytes --]
On Wed, Aug 19, 2015 at 09:32:49AM -0700, Mark Friedenbach via bitcoin-dev wrote:
> I think you misunderstand my suggestion Tier. I am suggesting the same as
> BtcDrak, I think:
>
> Modify IsSuperMajority to take an (optional) mask field. Bits set in that
> mask are zero'd for the purpose of the IsSuperMajority calculation. For
> this vote we mask bits 0x20000007.
>
> Thus to signal support for CLTV/CSV/etc. (on Core, XT, or not-XT), you set
> bit 4. On Core this would mean a minimum version of 0x8, on XT/not-XT a
> minimum version of 0x20000008.
>
> However the vote is still over whether to enforce BIP 65, 68, etc. for
> blocks with nVersion>=4. So when this all clears up we haven't needlessly
> wasted an additional bit.
Ah, I see your point now re: wasting bits; my post was a bit incorrect
on that point.
So a subtle thing with the IsSuperMajority() mechanism, and the nVersion
bits proposal alternative, is one of the main objectives of the latter
proposal proposal is to allow forks to *fail* to be adopted cleanly.
To illustrate the problem, consider a hypothetical CLTV soft-fork,
implemented with IsSuperMajority() nVersion >= 4. We release Bitcoin
Core with that code, call it Bitcoin Core v0.12.0, however some
substantial fraction of the mining community refuses to upgrade,
believing CLTV to be a bad idea. This forms the community into Bitcoin
Core and Bitcoin Not-CLTV camps. The Not-CLTV camp then wants to do a
new soft-fork upgrade, say for CHECKSIG2
What now? If CHECKSIG2 is implemented via IsSuperMajority, nVersion >=
5, that'll falsely trigger Core nodes to think the upgrade has gone
though. You could safely define >= 5 semantics to be "OP_CLTV is now
disabled", but that's pretty ugly and unnecessarily uses up a NOP.
You can avoid this problem by assigning one bit out of nVersion for
every soft-fork, but then you can only do ~29 more soft-forks - ugly!
Come to think of it, if you're Really Sure™ the soft-fork will be
adopted, you can recycle those bits by using the following rule:
if (IsFlagBitMaskSuperMajority(1 << 4, pindex->pprev) || block.nMedianTime > CLTV_SOFTFORK_DEADLINE) {
flags |= SCRIPT_VERIFY_CLTV;
}
IsFlagBitMaskSuperMajority() is a masked version of the existing
IsSuperMajority() logic. CLTV_SOFTFORK_DEADLINE would be set some
reasonable amount of time in the future, perhaps 3 years.
This would probably be ok for non-controversial forks - implementing
DERSIG this way would have been fine - and an unlimited number of
soft-forks can be done this way safely. (even in parallel)
However, this idea still causes problems if forks ever fail to get
adoption, something the nVersion bits proposal handles cleanly, albeit
at the cost of a significantly more complex implementation. With a
sufficiently far off fork deadline in practice that may not be a big
issue - nearly everyone would have upgraded their software anyway - but
it's still technically creating hard-fork scenarios with respect to
older software whenever forks fail to get adoption.
--
'peter'[:-1]@petertodd.org
00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
next prev parent reply other threads:[~2015-08-19 21:03 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-19 5:50 Peter Todd
2015-08-19 6:10 ` Mark Friedenbach
2015-08-19 9:34 ` Jorge Timón
2015-08-19 10:20 ` Btc Drak
2015-08-19 10:31 ` Jorge Timón
2015-08-19 13:15 ` Btc Drak
2015-08-19 13:24 ` Tier Nolan
2015-08-19 17:25 ` Btc Drak
2015-08-19 18:17 ` Tier Nolan
2015-08-19 12:36 ` Matt Corallo
2015-08-19 13:22 ` Tier Nolan
2015-08-19 14:01 ` Jeff Garzik
2015-08-19 16:32 ` Mark Friedenbach
2015-08-19 21:03 ` Peter Todd [this message]
2015-08-20 17:32 ` jl2012
2015-08-20 17:42 ` Mark Friedenbach
2015-08-27 22:11 ` Btc Drak
-- strict thread matches above, loose matches on Subject: below --
2015-08-18 1:22 [bitcoin-dev] BIP: Using Median time-past as endpoint for locktime calculations Thomas Kerin
2015-08-19 1:04 ` Peter Todd
2015-08-19 1:08 ` Mark Friedenbach
2015-08-21 11:13 ` Thomas Kerin
2015-08-22 0:57 ` Peter Todd
2015-08-27 22:08 ` Btc Drak
2015-08-27 23:19 ` Peter Todd
2015-08-28 15:27 ` jl2012
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=20150819210314.GA31482@muck \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=mark@friedenbach$(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