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 1U5GFN-0000go-AE for bitcoin-development@lists.sourceforge.net; Tue, 12 Feb 2013 13:50:09 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.215.44 as permitted sender) client-ip=209.85.215.44; envelope-from=raphfrk@gmail.com; helo=mail-la0-f44.google.com; Received: from mail-la0-f44.google.com ([209.85.215.44]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1U5GFH-0002Ud-Nx for bitcoin-development@lists.sourceforge.net; Tue, 12 Feb 2013 13:50:09 +0000 Received: by mail-la0-f44.google.com with SMTP id eb20so89109lab.31 for ; Tue, 12 Feb 2013 05:49:57 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.152.123.34 with SMTP id lx2mr16619601lab.52.1360676997023; Tue, 12 Feb 2013 05:49:57 -0800 (PST) Received: by 10.112.64.7 with HTTP; Tue, 12 Feb 2013 05:49:56 -0800 (PST) Date: Tue, 12 Feb 2013 13:49:56 +0000 Message-ID: From: Raph Frank To: bitcoin-development@lists.sourceforge.net Content-Type: text/plain; charset=ISO-8859-1 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 (raphfrk[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: 1U5GFH-0002Ud-Nx Subject: [Bitcoin-development] Incorporating block validation rule modifications into the block chain 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: Tue, 12 Feb 2013 13:50:09 -0000 Has this been considered? If made sufficiently general, older clients could support any extension of the rules. Various "hard" parameters within the protocol are defined in main.h of the official client. In BIP-34, there is a suggested way to make changes, based on consensus. https://en.bitcoin.it/wiki/BIP_0034 These could be made into a rule for changing the parameters directly. The process for updating could be handled by adding a new field to the coinbase transaction, in the same way the height was added in BIP-34. Something like - miner proposed a change by by including proposal in a block (name of parameter and new value) - seconded by at least 6 of the next 10 blocks (proposal dies otherwise) - active if 750 of the last 1000 blocks voted yes, or 950 of any successive 1000 previous blocks voted yes (with reduced thresholds on testnet) - dies if more than 500 of the previous 1000 voted No - blocks which don't reference the proposal are considered to abstain This could also be used to update NOPs. Complex signing algorithms could be incorporated. However, that would require a more complex scripting language for defining opcode functions. The proposal would have opcode number + script description of algorithm. This would also allow methods +