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-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Um67k-00041Z-UM for bitcoin-development@lists.sourceforge.net; Mon, 10 Jun 2013 17:43:20 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.110 as permitted sender) client-ip=62.13.148.110; envelope-from=pete@petertodd.org; helo=outmail148110.authsmtp.com; Received: from outmail148110.authsmtp.com ([62.13.148.110]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1Um67j-00042Q-T7 for bitcoin-development@lists.sourceforge.net; Mon, 10 Jun 2013 17:43:20 +0000 Received: from mail-c226.authsmtp.com (mail-c226.authsmtp.com [62.13.128.226]) by punt7.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id r5AHhBIc082255; Mon, 10 Jun 2013 18:43:11 +0100 (BST) Received: from petertodd.org (petertodd.org [174.129.28.249]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r5AHh6VJ018338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 10 Jun 2013 18:43:09 +0100 (BST) Date: Mon, 10 Jun 2013 13:43:06 -0400 From: Peter Todd To: Alan Reiner Message-ID: <20130610174306.GA16549@petertodd.org> References: <51B602D8.5030706@monetize.io> <51B60BF1.3020701@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="y0ulUmNC+osPPQO6" Content-Disposition: inline In-Reply-To: <51B60BF1.3020701@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 370aa52d-d1f5-11e2-98a9-0025907ec6c5 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdwIUEkAaAgsB AmUbWlxeVF57WWo7 ag1VcwRfa1RMVxto VEFWR1pVCwQmQxlw fkYYNGNydg1Fe3Y+ bUJjXD5YW0QrJEN/ FlMAFDsDeGZhPWIC WUgJfh5UcAFPdx9C PwN5B3ZDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA4zBDkk QAsLGWdnI0oZSm00 KVQ6KlNUFkIWOUYp MEksEVYZNh4OQhJf A0EvSDdDIF4PAi0l SBhGVE0TWCNaXSZa DXUA X-Authentic-SMTP: 61633532353630.1020:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 174.129.28.249/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.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 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1Um67j-00042Q-T7 Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Proposal: Vote on the blocksize limit with proof-of-stake voting 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, 10 Jun 2013 17:43:21 -0000 --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 10, 2013 at 01:25:05PM -0400, Alan Reiner wrote: > to sign votes. Not only that, but it would require them to reveal their > public key, which while isn't technically so terrible, large amounts of > money intended to be kept in storage for 10+ years will prefer to avoid > any exposure at all, in the oft-chance that QCs come around a lot > earlier than we expected. Sure, the actual risk should be pretty much > non-existent, but some of the most paranoid folks are probably the same > ones who have a lot of funds and want 100.00% of the security that is > possible. They will see this as wildly inconvenient. Solving that problem is pretty easy actually: just add a voting only public key to your outputs. Specifically you would have an opcode called something like "OP_VOTE" and put a code-path in your script that only executes for that specific key. It'd work best if we implement merklized abstract syntax trees to allow you to reveal only the part of a script that is actually executed rather than the whole script, a feature useful for a lot of other things. Incidentally remember that we can implement as many new opcodes as we want with a soft-fork by redefining one of the OP_NOP's to be a OP_VERSION opcode that returns false for a given version: version OP_VERSION OP_IFNOT {new opcodes} OP_ENDIF Nodes with the existing codebase will think the script always succeeds, because the IFNOT branch isn't taken, leaving the non-false version on the stack, while new nodes will take that branch. --=20 'peter'[:-1]@petertodd.org 0000000000000109243df1322b7b5173c5796cf979318e933d887210c981c1f8 --y0ulUmNC+osPPQO6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlG2ECoACgkQpEFN739thoyWbQCeL/b/4FzPtUD2WQbc4Tzy5Xyg g4gAoI+DGF1rfxbE47jaF277S6JOlElV =MShO -----END PGP SIGNATURE----- --y0ulUmNC+osPPQO6--