From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 18A35B9E for ; Wed, 13 Sep 2017 10:03:35 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail149058.authsmtp.co.uk (outmail149058.authsmtp.co.uk [62.13.149.58]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 57604A7 for ; Wed, 13 Sep 2017 10:03:34 +0000 (UTC) Received: from mail-c247.authsmtp.com (mail-c247.authsmtp.com [62.13.128.247]) by punt20.authsmtp.com (8.14.2/8.14.2/) with ESMTP id v8DA3WKZ071963; Wed, 13 Sep 2017 11:03:32 +0100 (BST) Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com [52.5.185.120]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id v8DA3TH9062166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Sep 2017 11:03:30 +0100 (BST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by petertodd.org (Postfix) with ESMTPSA id 5A8C940107; Wed, 13 Sep 2017 10:03:29 +0000 (UTC) Received: by localhost (Postfix, from userid 1000) id 91EE220435; Wed, 13 Sep 2017 06:03:28 -0400 (EDT) Date: Wed, 13 Sep 2017 06:03:28 -0400 From: Peter Todd To: Gregory Maxwell Message-ID: <20170913100328.GA1613@savin.petertodd.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="W/nzBZO5zC0uMSeA" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Server-Quench: cbe0a3db-986a-11e7-b1e8-0015176ca198 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdwEUC1AEAgsB AmEbWlVeUF57WmI7 bghPaBtcak9QXgdq T0pMXVMcUg0ccB9l fhceVBtzcQMIeX52 bEIsDSIOXBV5IRRg S0ZSRHAHZDJndTIe BUhFdwNVdQJNeEwU a1l3GhFYa3V6PyQl Aw46dzE3dR5jYCpS WEknLE4ZRkcNWHYD TgtQVQ4BVVUfQD00 NBUieBYEBkERM08z LTlpRFQDKxIUBgRU G0wFBzJFP0QdXGI0 DB9aFUcbFyBbXXIE agAA X-Authentic-SMTP: 61633532353630.1038:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 52.5.185.120/25 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Status: No, score=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Minutia in CT for Bitcoin. Was: SF proposal: prohibit unspendable outputs with amount=0 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 10:03:35 -0000 --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 13, 2017 at 09:39:28AM +0000, Gregory Maxwell wrote: > On Wed, Sep 13, 2017 at 9:24 AM, Peter Todd via bitcoin-dev > wrote: > > 2) Spending CT-shielded outputs to unshielded outputs > > > > Here one or more CT-shielded outputs will be spent. Since their value i= s zero, > > we make up the difference by spending one or more outputs from the CT p= ool, > > with the change - if any - assigned to a CT-pool output. >=20 > Can we solve the problem that pool inputs are gratuitously non-reorg > safe, without creating something like a maturity limit for shielded to > unshielded? So to be clear, we have two versions of this problem: 1) CT signatures do *not* sign which pool input they're using Here, obviously the inputs can be changed at will by miners. An implementat= ion could have the exact CT pool input be something miners add; the CT transact= ions broadcast on the P2P network wouldn't actually need them. 2) CT signatures *do* sign which pool input they're using Wallets would pick the input at random. This is required if you want to hav= e a transaction spending both CT and legacy inputs. This reduces the reorg risk= to double-spends. While double-spends are always a potential problem, the prob= lem is somewhat worse here, as even regular wallets are spending inputs that an= yone can choose to spend. > So far the best I have is this: Support unshielded coins in shielded > space too. So the only time you transition out of the pool is paying > to a legacy wallet. If support were phased in (e.g. addresses that > say you can pay me in the pool after its enabled), and the pool only > used long after wallets supported getting payments in it, then this > would be pretty rare and a maturity limit wouldn't be a big deal. So basically, you're essentially observing that in the event that everyone = uses CT, this isn't actually a problem; you're allowing everyone to "use" CT, by trying to allow even unshielded outputs to "use" it. Which means by "unshielded output", what you *actuall* mean is creating a CT transaction where the output - even though it's a zero-valued CT output - is constructed such that the value is public information. Or do you mean trying to have non-CT outputs in the pool somehow? I don't t= hink that makes sense, because the whole point of the pool is that the outputs i= n it are anyone-can-spend, and thus any CT transaction may spend them; which CT transaction spends them gives no information about the ownership of the coi= ns. This is incompatible with anything but anyone-can-spend outputs. > Can better be done? Note that the order in which outputs in the pool are spent can be deterministic. For example, you could say that each transaction must spend = the oldest outputs in the pool (that sum to the value needed). You could probab= ly come up with a scheme where the outputs that will be spent in the future in= the event that the output is spent back to an unshielded output is fixed when t= he output was created, for example, by picking a random index. While this woul= dn't prevent all collisions, it'd may be possible to make reorgs relatively safe= , by constraining how miners could txids. Specifically, you could imagine a scheme where if a given input set can onl= y be satisified by unspent pool outputs with index's >=3D i, then the miner woul= d need to have the ability to mine a conflicting transaction that also happened to have the same pool output set. Given a sufficiently large set of pool outpu= ts, this may be an impractical attack most of the time. --=20 https://petertodd.org 'peter'[:-1]@petertodd.org --W/nzBZO5zC0uMSeA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZuQJsAAoJECSBQD2l8JH72K8H/2xNHvF9K+t0sWF+ALvKcs0g o7cq64NpTduzkPRcfNk3ZjyuTJJ6wxwtOXVS+wRGq74OvcX8uCryAi4Ak8cfVn/X Ya6opzbZ82/Wo82nK5oyq/VR250wxvVNrLFIqF28ywQf2FoIbzLWNwxTO7R97J4w astJyZQYUcXdchKit2cFlJHZKGgW7yhlQ1xFj6iA0ZV+PdD2aY+nGWeiVkjUHQ6m HWyEG0qiiWod5r31wdfKo8TL7CKRBEhxNgtkDtLrE6obZhdo0GD/w0YFV9irQoPA 48UBdu6azMgnIvMC+EOgioJw2kpT4qtOv0FjMuYvuUb+9iH16TmliheE/bo5qMM= =CBVX -----END PGP SIGNATURE----- --W/nzBZO5zC0uMSeA--