From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Xa9vw-00068c-EX for bitcoin-development@lists.sourceforge.net; Fri, 03 Oct 2014 20:58:36 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.218.54 as permitted sender) client-ip=209.85.218.54; envelope-from=mh.in.england@gmail.com; helo=mail-oi0-f54.google.com; Received: from mail-oi0-f54.google.com ([209.85.218.54]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Xa9vu-0001VC-JG for bitcoin-development@lists.sourceforge.net; Fri, 03 Oct 2014 20:58:36 +0000 Received: by mail-oi0-f54.google.com with SMTP id v63so1355108oia.13 for ; Fri, 03 Oct 2014 13:58:29 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.94.167 with SMTP id dd7mr10131970oeb.4.1412369909060; Fri, 03 Oct 2014 13:58:29 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.69.135 with HTTP; Fri, 3 Oct 2014 13:58:28 -0700 (PDT) In-Reply-To: <201410031750.27323.luke@dashjr.org> References: <20141001130826.GM28710@savin.petertodd.org> <1987325.zKPNeYyO8K@crushinator> <201410031750.27323.luke@dashjr.org> Date: Fri, 3 Oct 2014 22:58:28 +0200 X-Google-Sender-Auth: tBwvZR-cfhD8Lyipp0G01HkjZiw Message-ID: From: Mike Hearn To: Luke Dashjr Content-Type: multipart/alternative; boundary=089e01183cbab8f95605048afec1 X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1Xa9vu-0001VC-JG Cc: Bitcoin Dev , Flavien Charlon Subject: Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 20:58:37 -0000 --089e01183cbab8f95605048afec1 Content-Type: text/plain; charset=UTF-8 Alright. It seems there's no real disagreement about how the opcode behaves. Perhaps a time limit would be appropriate to stop people creating outputs locked for 100 years .... is bitcoin even likely to exist in 100 years? The entire history of computing is not even that old, seems hard to imagine that it'd be good for anything beyond wasting space in the database. But this is a minor point. So I guess it's time to start the deployment discussion. Bitcoin is a consensus system. It works best when everyone is following exactly the same rules at the same time. A soft fork works against this principle by allowing nodes to think they're following the majority ruleset, even if they aren't, effectively downgrading them to something a bit like SPV security without them realising. A hard fork has multiple desirable properties. Most importantly, it means a node can detect it's no longer in the consensus because it'll find its own chain height has diverged significantly from its peers. Core already has code that knows how to detect this condition and log errors about it as well as running the alertnotify script i.e. emailing the admin. Ideally it would also stop serving work so miners shut down or fail over, but this is easily added to the CheckForkWarningConditions() function. In other words, this gives the cleanest failure we can give, such that any procedures a node operator has put in place to alert them of divergence will be triggered. Any code which is waiting for confirmations will wait forever at this point, thus minimising the risk of loss. Additionally, forcing old peers to fall behind means SPV clients will pick the right chain, and not end up downloading transactions or blocks that are about to be doomed at the next re-org. They can easily choose to ignore transactions relayed by peers that are too far behind and thus not end up accepting transactions that are no longer valid according to the majority (a scenario which can cause monetary loss). I don't think hard forks should be scary. Mechanisms are in place to warn people and they can be scheduled with plenty of time in advance. The main stated justification for a soft fork is backwards compatibility, but in a system like Bitcoin you really don't want to be running behind the consensus and it's hard to imagine any node operator deliberately choosing to stay on the wrong side of the fork. It's not like other software where people can choose to skip an upgrade and things still work just like before. --089e01183cbab8f95605048afec1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Alright. It seems there's n= o real disagreement about how the opcode behaves. Perhaps a time limit woul= d be appropriate to stop people creating outputs locked for 100 years .... = is bitcoin even likely to exist in 100 years? The entire history of computi= ng is not even that old, seems hard to imagine that it'd be good for an= ything beyond wasting space in the database. But this is a minor point.

So I gues= s it's time to start the deployment discussion.

Bitcoin is a consensus system= . It works best when everyone is following exactly the same rules at the sa= me time. A soft fork works against this principle by allowing nodes to thin= k they're following the majority ruleset, even if they aren't, effe= ctively downgrading them to something a bit like SPV security without them = realising.

A hard fork has multiple desirable properties. Most importantly, it me= ans a node can detect it's no longer in the consensus because it'll= find its own chain height has diverged significantly from its peers. Core = already has code that knows how to detect this condition and log errors abo= ut it as well as running the alertnotify script i.e. emailing the admin. Id= eally it would also stop serving work so miners shut down or fail over, but= this is easily added to the CheckForkWarningConditions() function.

In other word= s, this gives the cleanest failure we can give, such that any procedures a = node operator has put in place to alert them of divergence will be triggere= d.=C2=A0 Any code which is waiting for confirmations will wait forever at t= his point, thus minimising the risk of loss.

Additionally, forcing old peers to f= all behind means SPV clients will pick the right chain, and not end up down= loading transactions or blocks that are about to be doomed at the next re-o= rg. They can easily choose to ignore transactions relayed by peers that are= too far behind and thus not end up accepting transactions that are no long= er valid according to the majority (a scenario which can cause monetary los= s).

I = don't think hard forks should be scary. Mechanisms are in place to warn= people and they can be scheduled with plenty of time in advance. The main = stated justification for a soft fork is backwards compatibility, but in a s= ystem like Bitcoin you really don't want to be running behind the conse= nsus and it's hard to imagine any node operator deliberately choosing t= o stay on the wrong side of the fork. It's not like other software wher= e people can choose to skip an upgrade and things still work just like befo= re.
--089e01183cbab8f95605048afec1--