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 A90098D9 for ; Thu, 7 Sep 2017 03:49:15 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pg0-f54.google.com (mail-pg0-f54.google.com [74.125.83.54]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5BC94140 for ; Thu, 7 Sep 2017 03:49:15 +0000 (UTC) Received: by mail-pg0-f54.google.com with SMTP id q68so2927787pgq.1 for ; Wed, 06 Sep 2017 20:49:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=WwVcbOldK82QCle8SQR8UMZz9+UAA62/Syf71enNIlI=; b=c8+wqXuhFjtM40tESRxiNa8Bw9szKNEdjduQB6ppHCn6KLzOtisVb61z/MU9l1cq0K CciQbKdpBY+ZldD9qdoo8dO4s7OG8qyT/D53bUmF4If3M0RMdKsDV+jTFnxeq7tpUNO8 G+N0Ly7jhOaVKfBTavz6NNyhr+lvkXOFm4YQpF5/HHuNAa97Zr9F7Tp/lQkxhrWEn7h7 j/YXcnTZ857PoVsxXsMdZBJ51kI51R8Malk9Fmlwlzg1WX1c0iwQbNoqz8FzkuUxPdxd apKvqc8cpYb2M/omC/E9Qqx1Qt5Z0peUvPeaeLDaGH2m9LYnyp2grK14eEZz2GyyG2Fz ILiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=WwVcbOldK82QCle8SQR8UMZz9+UAA62/Syf71enNIlI=; b=gn9/gRTUHPKfzpshEggsTeNpT+7jPXzEFTgRUjFK1LTH+v+A3iusojo7qMOfbf+Zkk GNsaBGxx0lsZdkB42eML3FIEylXefBjdwtCzp8wEteAvq8jXepLh4NgDEPhG4vex/nT6 l2PxBkO5qG6EdVBWUBpndmP5NP0nlDe4t/gnnwgn1oHKe6f6OWK+pABfaIYUhHNn55SY /u8pkMubXInw1FB0MYiisc0VznT1wwZC+kupTYsCntjffp6/cSJeopWECGYZSuG+9X7s Wa7IZHO8aOaS/8UMM6ADnzcjmxYUxzQvGRt7kaswc7rlPJZ8hoY3WzHSEiMVtzVBSjKR ngjw== X-Gm-Message-State: AHPjjUj8BGaJgtKcxmJWv7LwKJhSwnk273lf5eSt6whxYUTlkPtffRNn 6U8I6u3F9yBV6A== X-Google-Smtp-Source: ADKCNb7NzCixArDU7NeF2Svfisjr5jiTIkB60X+759L6VnQQSvXUOR5RSMy+In5JxUdD8y2LtXNa9g== X-Received: by 10.98.13.81 with SMTP id v78mr1353909pfi.61.1504756154874; Wed, 06 Sep 2017 20:49:14 -0700 (PDT) Received: from [192.168.1.3] (c-73-240-125-172.hsd1.or.comcast.net. [73.240.125.172]) by smtp.gmail.com with ESMTPSA id p88sm1556283pfi.164.2017.09.06.20.49.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Sep 2017 20:49:13 -0700 (PDT) To: adam@cypherspace.org, Bitcoin Protocol Discussion References: From: CryptAxe Message-ID: <1ffab7c0-7005-283e-07e5-4e85fc54de51@gmail.com> Date: Wed, 6 Sep 2017 20:41:49 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Spam-Status: No, score=0.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Thu, 07 Sep 2017 05:24:19 +0000 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: Thu, 07 Sep 2017 03:49:15 -0000 After reading https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012194.html I see that Adam is correct. Unfortunately this SF would make Felix's confidential transactions more complicated. The blinding and unblinding transactions would have to be created with minimal output values, and this will need to be considered when checking that the fee is equal to the total amount of input. (it would now be SUM(inputs) - SUM(minimalOutputs)) Blinding transaction: Ins: All non-confidential inputs are valid Outs: - 0..N: (new confidential outputs) amount: 0 scriptPubkey: OP_2 <0x{32-byte-hash-value}> witnessOut: <0x{petersen-commitment}> <0x{range-proof}> - last: amount: 0 scriptPubkey: OP_RETURN OP_2 {blinding-fee-amount} Fee: Sum of the all inputs value However, looking at the format of the blinding transaction, and how the GCTXO is added to the UTXO set by miners, it seems that a change to the blinding scriptPubKey could allow for the use of 0 value outputs. Even with the SF proposed by this email thread. OP_RETURN could be added to the scriptPubKey during blinding. The amount and scriptPubKey destination of unblinded funds is part of the witness and the outputs of an unblinded transaction are unspendable, so why not also make them unspendable in the blind transaction? As far as I can tell those outputs don't need to be spendable, they are really just encoding data. It doesn't seem like anything besides the confidential base transaction and the fee output from the blind transaction need to be in the UTXO set. Is it still possible to add this data to the witness if the scriptPubKey is unspendable? : witnessOut: <0x{petersen-commitment}> <0x{range-proof}> I think I'm missing something obvious, someone point out why this is stupid please :) On 09/06/2017 06:29 PM, Adam Back wrote: > The pattern used by Felix Weiss' BIP for Confidential Transactions > depends on or is tidier with 0-value outputs. > > Adam > > > On 7 September 2017 at 00:54, CryptAxe via bitcoin-dev > wrote: >> As long as an unspendable outputs (OP_RETURN outputs for example) with >> amount=0 are still allowed I don't see it being an issue for anything. >> >> On Sep 5, 2017 2:52 PM, "Jorge Timón via bitcoin-dev" >> wrote: >>> This is not a priority, not very important either. >>> Right now it is possible to create 0-value outputs that are spendable >>> and thus stay in the utxo (potentially forever). Requiring at least 1 >>> satoshi per output doesn't really do much against a spam attack to the >>> utxo, but I think it would be slightly better than the current >>> situation. >>> >>> Is there any reason or use case to keep allowing spendable outputs >>> with null amounts in them? >>> >>> If not, I'm happy to create a BIP with its code, this should be simple. >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>