From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Wczvz-00015y-SK for bitcoin-development@lists.sourceforge.net; Wed, 23 Apr 2014 16:22:07 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.170 as permitted sender) client-ip=209.85.214.170; envelope-from=mh.in.england@gmail.com; helo=mail-ob0-f170.google.com; Received: from mail-ob0-f170.google.com ([209.85.214.170]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Wczvx-0003Ek-SK for bitcoin-development@lists.sourceforge.net; Wed, 23 Apr 2014 16:22:07 +0000 Received: by mail-ob0-f170.google.com with SMTP id vb8so1299814obc.29 for ; Wed, 23 Apr 2014 09:21:56 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.55.65 with SMTP id q1mr2181446obp.70.1398270116763; Wed, 23 Apr 2014 09:21:56 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.96.180 with HTTP; Wed, 23 Apr 2014 09:21:56 -0700 (PDT) In-Reply-To: References: Date: Wed, 23 Apr 2014 18:21:56 +0200 X-Google-Sender-Auth: 32iz17FHSVxROPNEtuKzmRoJlWM Message-ID: From: Mike Hearn To: Christophe Biocca Content-Type: multipart/alternative; boundary=089e015388489c1e0004f7b821f7 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: 1Wczvx-0003Ek-SK Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks 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: Wed, 23 Apr 2014 16:22:08 -0000 --089e015388489c1e0004f7b821f7 Content-Type: text/plain; charset=UTF-8 I think the cost to mines is the same as what's possible today, actually. Consider a group of miners who wish to do this with no changes to the rule set. They can coordinate out of band and figure out if they have a majority of hashpower behind the decision to orphan a block, e.g. by signing a nonce with their coinbase keys. If they reach quorum, then they begin work on a parallel chain. Because they have majority they are guaranteed to eventually win, though depending on luck it may take a while. Because of this, assuming the external quorum system is public, the moment consensus is reached the other miners should all abandon the existing branch and start work on the parallel chain too, lest they waste work mining on a branch that is surely doomed. The end result would be that the chain stops making progress, disrupting end users and generally creating uncertainty as the new chain is forged. Also, miners who built on top of the orphaned block end up being punished even if they did nothing wrong. Both these side effects are undesirable and unnecessary. So the more I think about this scheme, the more it seems like a simple improvement on the current status quo. Miners can do what they could already do, but with a more reliable in-band signalling mechanism that doesn't require things like coinbase keys to be online, and them doing so does not disrupt existing users or waste energy. --089e015388489c1e0004f7b821f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think the cost to mines is th= e same as what's possible today, actually.

Consider a group of miners who wis= h to do this with no changes to the rule set. They can coordinate out of ba= nd and figure out if they have a majority of hashpower behind the decision = to orphan a block, e.g. by signing a nonce with their coinbase keys. If the= y reach quorum, then they begin work on a parallel chain. Because they have= majority they are guaranteed to eventually win, though depending on luck i= t may take a while. Because of this, assuming the external quorum system is= public, the moment consensus is reached the other miners should all abando= n the existing branch and start work on the parallel chain too, lest they w= aste work mining on a branch that is surely doomed.

The end res= ult would be that the chain stops making progress, disrupting end users and= generally creating uncertainty as the new chain is forged. Also, miners wh= o built on top of the orphaned block end up being punished even if they did= nothing wrong. Both these side effects are undesirable and unnecessary.

So the more= I think about this scheme, the more it seems like a simple improvement on = the current status quo. Miners can do what they could already do, but with = a more reliable in-band signalling mechanism that doesn't require thing= s like coinbase keys to be online, and them doing so does not disrupt exist= ing users or waste energy.
--089e015388489c1e0004f7b821f7--