From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1RAaXN-0002iL-J2 for bitcoin-development@lists.sourceforge.net; Mon, 03 Oct 2011 04:53:57 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.216.47 as permitted sender) client-ip=209.85.216.47; envelope-from=gmaxwell@gmail.com; helo=mail-qw0-f47.google.com; Received: from mail-qw0-f47.google.com ([209.85.216.47]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1RAaXM-0002hR-SU for bitcoin-development@lists.sourceforge.net; Mon, 03 Oct 2011 04:53:57 +0000 Received: by qadc1 with SMTP id c1so1653009qad.34 for ; Sun, 02 Oct 2011 21:53:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.236.5 with SMTP id ki5mr10747496qcb.223.1317617631254; Sun, 02 Oct 2011 21:53:51 -0700 (PDT) Received: by 10.229.214.144 with HTTP; Sun, 2 Oct 2011 21:53:51 -0700 (PDT) Date: Mon, 3 Oct 2011 00:53:51 -0400 Message-ID: From: Gregory Maxwell To: Bitcoin Development Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.6 (-) 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 (gmaxwell[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 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: 1RAaXM-0002hR-SU Subject: [Bitcoin-development] Supermajority mining votes for valid->invalid changes. 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: Mon, 03 Oct 2011 04:53:57 -0000 It is possible to made changes to the distributed algorithm which make previously valid txn invalid without necessarily creating any lasting chain splits. This has been proposed for the addition of the eval opcode by using one of the existing NOPs. One challenge is that if transactions are emitted which are invalid under the new scheme but valid under the old after the block height that the rule is coded to take effect and a super-majority of miners are not yet upgraded the upgrade may cause a long reorganization and serious disruption. Here I explain one possible way of avoiding this. Upgraded nodes get the following rules: (0) Never forward or mine a txn which would be invalid under the new rule. (1) Apply old behavior before height X unconditionally. (X set far enough in the future to get reasonable deployment by large miners) (2) Begin applying the new rule only after the first point in the chain after X when none of the last Y blocks have contained an invalid transaction under the new rules. After the software has been released members of the bitcoin community then begin _intentionally_ transmitting transactions which are invalid under the new rules. (What would have been an attack under simplest deployment plan) By setting Y high enough that all major miners have a chance to mine in the window, this actually becomes an effective vote for the change by miners with a stochastic super-majority threshold. All nodes are able to exactly determine at what block the election has completed because it is an objective fact of the chain. With this scheme the new encoding will only become active when enough mining capacity supports it (or at least helpfully refuses to mine the who class of transactions) so that a large reorganization will not happen due to incompatible blocks during deployment. This could be further enhanced with conflicting block discouragement (e.g. refusing to extend or forward a rules violating block until it is burred) but I think this scheme is sufficient without that, and that this is generally superior to discouragement for this purpose. Cheers.