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-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Uc50T-0007Df-SH for bitcoin-development@lists.sourceforge.net; Tue, 14 May 2013 02:30:25 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of googlemail.com designates 74.125.83.54 as permitted sender) client-ip=74.125.83.54; envelope-from=john.dillon892@googlemail.com; helo=mail-ee0-f54.google.com; Received: from mail-ee0-f54.google.com ([74.125.83.54]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Uc50S-0007cG-Qd for bitcoin-development@lists.sourceforge.net; Tue, 14 May 2013 02:30:25 +0000 Received: by mail-ee0-f54.google.com with SMTP id e50so3899eek.41 for ; Mon, 13 May 2013 19:30:18 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.15.24.72 with SMTP id i48mr64738982eeu.37.1368498618273; Mon, 13 May 2013 19:30:18 -0700 (PDT) Received: by 10.223.61.65 with HTTP; Mon, 13 May 2013 19:30:18 -0700 (PDT) In-Reply-To: <20130513211244.GA9550@netbook.cypherspace.org> References: <20130511045342.GA28588@petertodd.org> <20130511102209.GA27823@netbook.cypherspace.org> <20130513105408.GB3393@netbook.cypherspace.org> <20130513211244.GA9550@netbook.cypherspace.org> Date: Tue, 14 May 2013 02:30:18 +0000 Message-ID: From: John Dillon To: Adam Back Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -1.4 (-) 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 (john.dillon892[at]googlemail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (john.dillon892[at]googlemail.com) -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: 1Uc50S-0007cG-Qd Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] merged mining hashcash & bitcoin (Re: Coinbase TxOut Hashcash) 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, 14 May 2013 02:30:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > - what about if a pool could lock the reward (rather than receive it or > destroy it) eg some kind of merkle root instead of a public key hash in > the reward recipient address field in the coinbase. Sorry I don't have time for a full reply due to some other commitments, but you remind me of an idea bouncing around to use a Merkle Sum tree as a way to split one sacrifice among an arbitrarily large set of users. Credit goes to Gregory Maxwell (according to the wiki) and the idea is to have the roots of the tree be account "numbers" (pubkeys here) and account amounts. He proposed it for off-chain transaction account ledgers, but the idea works equally well here to split some initial sacrifice into lots of little bits. For instance a on-chain sacrifice to an anyone-can-pay output could be split into enough parts to make it useful even when tx fees become large. Incidentally all this stuff about rivest paywords is probably silly, why not just commit your sacrifice to a pubkey and make signatures saying what your new balance is for each message and how much you intended to spend? This allows for easy fraud proof creation, and gives you a choice of either lying to some nodes, and getting poor propagation, or being honest and spending the amount you should have. For DoS protection it seems to me that mostly trusting nodes to give accurate balances, enforced with a fraud proof system to halt double-spending, is perfectly adequate. But no sense implementing so much complexity right at the start of the effort! Just a thought for where things can go in the future. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJRkaGUAAoJEEWCsU4mNhiPKsoH/1zhTBS/rINhF8oxxFoScD6i 0ybiUarIQEmmpAr3i46oMcSrw0SiOoiUzj6zvJorA21ddoErkTDVpMWI18RnKFos bTC4NVzvcegLdnbYb+76XKOCMc1dchFXq+WEGRdu/WKzOL7ODUUKAl/hG2Fk4lPU 3x8mHq0k2pqMAYX5/TX0w0pDnS227L+V1O3EoZD86MjR/CliHsZyBnXIqyqV4rY8 354JswKQ/XWb85gwZwFq1WXsFIZAep+eRVqmOluu3Ol97c5G85utNYDkg2hALURy gfpwmXKPFGm8h2lE1cMaOxkvQHOOPH8v7WdoBx08/ojhsyQNMpND4xej5FP/e5c= =vrFC -----END PGP SIGNATURE-----