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 533D6B6C for ; Wed, 13 Sep 2017 09:24:47 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail148108.authsmtp.net (outmail148108.authsmtp.net [62.13.148.108]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A5BF913E for ; Wed, 13 Sep 2017 09:24:46 +0000 (UTC) Received: from mail-c245.authsmtp.com (mail-c245.authsmtp.com [62.13.128.245]) by punt23.authsmtp.com (8.14.2/8.14.2/) with ESMTP id v8D9OdYk043398; Wed, 13 Sep 2017 10:24:39 +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 v8D9Oav5053671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Sep 2017 10:24:37 +0100 (BST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by petertodd.org (Postfix) with ESMTPSA id A55864010B; Wed, 13 Sep 2017 09:24:35 +0000 (UTC) Received: by localhost (Postfix, from userid 1000) id DC8CE20435; Wed, 13 Sep 2017 05:24:34 -0400 (EDT) Date: Wed, 13 Sep 2017 05:24:34 -0400 From: Peter Todd To: Jorge =?iso-8859-1?Q?Tim=F3n?= Message-ID: <20170913092434.GA1094@savin.petertodd.org> References: <20170907180014.GA13727@fedora-23-dvm> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Server-Quench: 5cc7cbc5-9865-11e7-801f-9cb654bb2504 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdwEUC1AEAgsB AmEbWlReUll7WmQ7 bghPaBtcak9QXgdq T0pMXVMcUg0cCGNQ QBseVxp0cAQIcXl0 ZwhnDSNcDxYpcFt0 SkhRCGwHMGB9YGAe Bl1RJFFSdQcYLB1A alQxNiYHcQ5VPz4z GA41ejw8IwAXEwod WhsKNVUJSEJZViYm QBADFzQzVVADXD0+ KRAvIFoRVEEMLl0v LUBpRlMEM31aAwhZ AkdRVXcx X-Authentic-SMTP: 61633532353630.1039: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] 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 09:24:47 -0000 --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 09, 2017 at 11:11:57PM +0200, Jorge Tim=F3n wrote: > Tier Nolan, right, a new tx version would be required. >=20 > I have to look deeper into the CT as sf proposal. >=20 > What futures upgrades could this conflict with it's precisely the > question here. So that vague statement without providing any example > it's not very valuable. So with Confidential Transactions, the only thing that's changed relative t= o a normal Bitcoin transaction is that fact that the sum of input values is >= =3D the sum of output values is proven via a CT proof, rather than revealing the ac= tual sums. Other than that, CT transactions don't need to be any different from regular transactions. For CT to be a softfork, we have to ensure that each CT transaction's sum of inputs and outputs is valid. An obvious way to do this is to have a pool of "shielded" outputs, whose total value is the sum of all CT-protected output= s. Outputs in this pool would appear to be anyone-can-spend outputs to pre-CT nodes. This gives us three main cases: 1) Spending unshielded outputs to CT-shielded outputs Since the CT-shielded output's value is unknown, we can simply set their va= lue to zero. Secondly, we will add the newly CT-shielded value to the pool with= an additional output whose value is the sum of all newly created CT-shielded outputs. 2) Spending CT-shielded outputs to unshielded outputs Here one or more CT-shielded outputs will be spent. Since their value is ze= ro, we make up the difference by spending one or more outputs from the CT pool, with the change - if any - assigned to a CT-pool output. 3) Spending CT-shielded outputs to CT-shielded outputs Since both the inputs and outputs are zero-valued, to pre-CT nodes the transaction is perfectly valid: the sum of coins spent is 0 BTC, and the su= m of coins created is also 0 BTC. We do have the problem of paying miners fees, = but that could be done with an additional CT output that the miner can spend, a child-pays-for-parent transaction, or something else entirely that I haven't thought of. > Although TXO commitments are interesting, I don't think they make UTXO > growth a "non-issue" and I also don't think they justify not doing > this. >=20 > Yeah, the costs for spammers are very small and doesn't really improve > things all that much, as acknowledged in the initial post. Suppose zero-valued outputs are prohibited. In case #3 above, if there are = more outputs than inputs, we need to add an additional input from the CT-shielded pool to make up the difference, and an additional change output back to the CT-shielded pool. If shielded-to-shielded transactions are common, these extra outputs could consume a significant % of the total blockchain space - that's a significant cost. Meanwhile the benefit is so small it's essentially theoretical: an additional satoshi per output is an almost trivial cost to an attacker. Quite simply, I just don't think the cost-benefit tradeoff of what you're proposing makes sense. --=20 https://petertodd.org 'peter'[:-1]@petertodd.org --Nq2Wo0NMKNjxTN9z Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZuPlPAAoJECSBQD2l8JH7co4H/AxfpvIWpLMPbQaZKv98I0hS CAIq8Pu2eNtMfYFadnuHE/deTdhJGT1oIPU6Yn9aGieoGT8PGU5TcEZBKOn8n2+R ttWb64Kwpe78euXkPldldWUBD/sN312g1QhHLMo8ISotdGRnfjx/TlPhbsGCfWfU 6jIsjlZxfV5Q+rGEpP8rhgvxBgvhZG9RsVMT8FA7MOUWmRApQAtPTk0ldx2lP73k S0yafZprCsKbnSpFLsOU7U+b87owxxLPsnRi18x59Dm81uESsKfUEfSV/kII/odF lZo627ysqJBfXswgRJy90FfAqYGFZsIWM5dHTplVJzPNSHV2Gdh6fmjDMOITdZw= =ghij -----END PGP SIGNATURE----- --Nq2Wo0NMKNjxTN9z--