diff options
| author | Anthony Towns <aj@erisian.com.au> | 2015-10-08 01:00:14 +1000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-10-07 15:00:22 +0000 |
| commit | b82dc80a989d48e73bda642f043d04fb4499a90d (patch) | |
| tree | af44a2799953304176e907ab87d19b120c9e887b | |
| parent | 494ca22afc51c671dfa7be8a8d4bcbb30dbe501d (diff) | |
| download | pi-bitcoindev-b82dc80a989d48e73bda642f043d04fb4499a90d.tar.gz pi-bitcoindev-b82dc80a989d48e73bda642f043d04fb4499a90d.zip | |
Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
| -rw-r--r-- | 72/b51cc96e500b900bcbcca15ffd83f6527cd387 | 172 |
1 files changed, 172 insertions, 0 deletions
diff --git a/72/b51cc96e500b900bcbcca15ffd83f6527cd387 b/72/b51cc96e500b900bcbcca15ffd83f6527cd387 new file mode 100644 index 000000000..82d172464 --- /dev/null +++ b/72/b51cc96e500b900bcbcca15ffd83f6527cd387 @@ -0,0 +1,172 @@ +Return-Path: <aj@erisian.com.au> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 5CC651B8C + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 7 Oct 2015 15:00:22 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 +Received: from azure.erisian.com.au (cerulean.erisian.com.au [106.187.51.212]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7523211A + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 7 Oct 2015 15:00:21 +0000 (UTC) +Received: from aj@azure.erisian.com.au (helo=navy.erisian.com.au) + by azure.erisian.com.au with esmtpsa (Exim 4.84 #2 (Debian)) + id 1ZjqCX-0003Sq-Ii for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 08 Oct 2015 01:00:19 +1000 +Received: by navy.erisian.com.au (sSMTP sendmail emulation); + Thu, 08 Oct 2015 01:00:14 +1000 +Date: Thu, 8 Oct 2015 01:00:14 +1000 +From: Anthony Towns <aj@erisian.com.au> +To: bitcoin-dev@lists.linuxfoundation.org +Message-ID: <20151007150014.GA21849@navy> +References: <20150927185031.GA20599@savin.petertodd.org> + <CA+w+GKRCVr-9TVk66utp7xLRgTxNpxYoj3XQE-6y_N8JS6eO6Q@mail.gmail.com> + <CAAS2fgSEDGBd67m7i8zCgNRqtmQrZyZMj7a5TsYo41Dh=tdhHQ@mail.gmail.com> +MIME-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +In-Reply-To: <CAAS2fgSEDGBd67m7i8zCgNRqtmQrZyZMj7a5TsYo41Dh=tdhHQ@mail.gmail.com> +User-Agent: Mutt/1.5.24 (2015-08-30) +X-Spam-Score: -1.9 +X-Spam-Score-int: -18 +X-Spam-Bar: - +X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD, + UNPARSEABLE_RELAY autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY! +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +Precedence: list +List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Wed, 07 Oct 2015 15:00:22 -0000 + +On Tue, Sep 29, 2015 at 06:31:28PM +0000, Gregory Maxwell via bitcoin-dev wrote: +> On Mon, Sep 28, 2015 at 10:48 AM, Mike Hearn via bitcoin-dev +> <bitcoin-dev@lists.linuxfoundation.org> wrote: +> > There is no consensus on using a soft fork to deploy this feature. It will +> > result in the same problems as all the other soft forks - SPV wallets will +> > become less reliable during the rollout period. I am against that, as it's +> > entirely avoidable. +> > Make it a hard fork and my objection will be dropped. +> I'm surprised to see this response-- [...] +> I am having a little difficulty making sense of this complaint. [...] + +I think I finally understand this objection. + +For a hard fork, activated by a majority of nodes/hashpower upgrading +to a new bitcoin release, the behaviour is: + + - upgraded bitcoin nodes: everything works fine + + - non-upgraded bitcoin nodes: total breakage. there will be a push + alert telling you to upgrade. anyone who doesn't will think they're + tracking "bitcoin" but will actually be tracking a new "bitcoin-old" + altcoin. most non-upgraded miners will presumably realise they're + wasting hashpower and stop doing this pretty quick; and remaining + miners will only create blocks very slowly due to sudden reduced + hashpower, without possibility of difficulty adjustment. users who + don't uprade will try to do transactions, but won't see them confirm + for hours or days due to lack of hashpower. + + - SPV nodes: they track the upgraded majority, everything works fine + even if they don't upgrade + +For a soft fork, again activated by the majority of upgraded hashpower, +the behaviour is: + + - upgraded bitcoin nodes: everything works fine + + - non-upgraded bitcoin miners willing to mine newly unacceptable txs: + may produce orphaned blocks; may be able to be forced into producing + blocks that will be orphaned + + - other non-upgraded bitcoin nodes: everything works fine + + - SPV nodes: partial breakage -- may track invalid blocks for 1-2 + confirmations until the set of "non-upgraded bitcoin miners willing + to produce newly unacceptable txs" becomes vanishingly few. + +In the hard fork case, all non-upgraded nodes get a DoS attack, but +aren't likey to be hit by doublespends. That's inconvenient, but it's +not too bad. + +In the soft fork case, if there's likely to be old nodes mining +previously invalid transactions, SPV clients become very unreliable, +to the point of possibly seeing semi-regular double-spends with 1 or +2 confirmation, until miners that aren't paying attention notice their +blocks are getting orphaned and upgrade. That is pretty bad IMHO; and +there are a lot more *people* running SPV clients than bitcoin nodes, +so its impact is potentially worse in both ways. + +Comparing generic hard forks versus generic soft forks, the above says +to me that a hard fork would be less harmful to users in general, and +thus a better approach. + +*But* a soft fork that only forbids transactions that would previously +not have been mined anyway should be the best of both worlds, as it +automatically reduces the liklihood of old miners building newly invalid +blocks to a vanishingly small probability; which means that upgraded +bitcoin nodes, non-upgraded bitcoin nodes, /and/ SPV clients *all* +continuing to work fine during the upgrade. + +AFAICS, that's what BIP65 achieves, as will similar OP_NOP* replacements +like BIP112. + +But that only applies to a subset of potential soft forks, not every +soft fork. + +Maybe a good way to think about it is something like this. Consensus +(IsValid) is always less restrictive than (default) policy (previously +IsStandard, not sure how to summarise it now, maybe it's just OP_NOP +redefinition?). So choosing a new consensus rule will be one of: + + * even less restrictive than consensus (hard fork) + + * more restrictive than consensus, but less restrictive than policy + (safe soft fork) + + * more restrictive than IsStandard etc (damaging soft fork) + +Hmm, in particular, following this line of thinking it's not clear to +me that BIP68 is actually less restrictive than current policy? At +least, I can't see anything that prevents txs with nSequence set to +something other than 0 or ~0 from being relayed? + +If it's not, and nodes currently happily mine and relay transactions +with nSequence set without caring what it's set to, doesn't this mean +BIP68 is of the "damaging soft fork" variety? That is, if it activated +as a soft-fork with a majority of miners using it, but a minority of ~5% +not upgraded, then + + - someone could construct an tx with nSequence set to sometime in + the future, but not using OP_CSV + + - this tx would get relayed by old nodes (but not upgraded nodes + due to CheckLockTime) + + - non-upgraded miners would mine it into a block immediately, which + would then get orphaned by majority hashpower + + - before it got orphaned, non-upgraded nodes and SPV clients would + be misled and vulnerable to double spend attacks of txs with 0, 1 or + maybe 2 confirmations + +(BIP65 with OP_CLTV and BIP112 with OP_CSV don't have that problem as +they both redefine a non-standard opcode and would not get relayed or +mined by old, non-upgraded nodes, and are thus "safe soft forks" per +above terminology. This is just BIP68) + +Can anyone confirm or refute the above? + +Cheers, +aj + + |