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 7A6969B9 for ; Thu, 7 Sep 2017 09:56:21 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f42.google.com (mail-oi0-f42.google.com [209.85.218.42]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D6CB51BB for ; Thu, 7 Sep 2017 09:56:20 +0000 (UTC) Received: by mail-oi0-f42.google.com with SMTP id x190so40118473oix.3 for ; Thu, 07 Sep 2017 02:56:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=VE13RC6aCGt+MVe3iEB6xPCTBbX80RgxJKFXXjQPYNU=; b=ifDWICl3nQIS6eXhRXrwbNk+FNt4vBZgMi8Wd3HUUYaTae2RzoAGu3yTozf7VLUMYs qC1PDQQFYSCl9F/x1YYTioNmGtBvkzvDmWT9+ZCbAqHNKw8o8eoZhAkqfmQ1nWwwnnl8 XEeJhIIQ5uJm0OJivz67sQO/8ScEPMXsTgY3/LRpF0z9YImKAws0eGSeGIyofV2kVX8v +Pf8gzwWDsRMepcsI5Mo2meU6MNEoX0VX2nF+0Jr+aQPrQJ2skLwXutZklCm750H0YEV Vk1ilQSxSAZGXeL+NvDZXtmbRTKUWqYWlydJlHiGpFTszO+rfQceqSVdeUZKMyImj0/T 8oZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=VE13RC6aCGt+MVe3iEB6xPCTBbX80RgxJKFXXjQPYNU=; b=YaCHPDZmfAU/zK2et0kF1kEJaiJ9ptvHvg6/e2sv0jupOXywnb+GSEehN68jYc4GTW VHETYlYTpsPavrFsREz+9UBmIIOb+e3sTwfZdhSH0xpRuD/4Q5nvMhwbD25ISfzPsKm8 DldkoejfWOua9LJebifAZPSbddL+WOO9N47Wddvje2gduKuhp8rJYDFtyfSI+4G8qWVF 0VEbPAATohTohcklLoOvH0Zxb3/Lct6ie9a+o8Z4FllcvLx3ISVOJY6uTHUu2OH5EQXn YRzGIZTy7fGRzVPdMuWxOXx6k63xlftV2EwFEN+7LJfck0LOL0zcpgltLntA99aLVAe6 jOZw== X-Gm-Message-State: AHPjjUgi7ct+rbLlfkofQDXaRlk63QIECqLJX9iEHDVvD3LG9FZYgRBd fe+oJZN7nNF9wYf+Ei8fzoo14ZtlHg== X-Google-Smtp-Source: ADKCNb7u9/W7p+9k/gk2xnhgVub/BNUV0BNEGmYhHIzi3olxFBM7rr4cRgLA6TOeeyJJq1AE+oyYMDdqdcFKFbNhTSY= X-Received: by 10.202.87.135 with SMTP id l129mr2014788oib.293.1504778180183; Thu, 07 Sep 2017 02:56:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.1.136 with HTTP; Thu, 7 Sep 2017 02:56:19 -0700 (PDT) In-Reply-To: <1ffab7c0-7005-283e-07e5-4e85fc54de51@gmail.com> References: <1ffab7c0-7005-283e-07e5-4e85fc54de51@gmail.com> From: =?UTF-8?Q?Hampus_Sj=C3=B6berg?= Date: Thu, 7 Sep 2017 11:56:19 +0200 Message-ID: To: CryptAxe , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="001a113de4d6e54b250558967879" X-Spam-Status: No, score=0.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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 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 09:56:21 -0000 --001a113de4d6e54b250558967879 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Forbidding 0 satoshi outputs (I wasn't actually aware that it was possible, is 0 satoshi inputs also allowed?) would complicate a divisibility increase softfork (I'm working on an idea for >=3D 1 satoshi transactions, but now i= t seems like < 1 satoshi transactions would work too). I don't think it's a good idea to deploy this softfork. Hampus 2017-09-07 5:41 GMT+02:00 CryptAxe via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org>: > 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=3D0 are still allowed I don't see it being an issue for anythin= g. > >> > >> On Sep 5, 2017 2:52 PM, "Jorge Tim=C3=B3n 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 th= e > >>> 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 simpl= e. > >>> _______________________________________________ > >>> 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 > >> > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --001a113de4d6e54b250558967879 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Forbidding 0 satoshi outputs (I wasn't actua= lly aware that it was possible, is 0 satoshi inputs also allowed?) would co= mplicate a divisibility increase softfork (I'm working on an idea for &= gt;=3D 1 satoshi transactions, but now it seems like < 1 satoshi transac= tions would work too).

I don't think it's a goo= d idea to deploy this softfork.

Hampus

2017-09-07 5:41 GMT+02:00 Crypt= Axe via bitcoin-dev <bitcoin-dev@lists.linuxfoundation= .org>:
After reading
https://lists.linuxf= oundation.org/pipermail/bitcoin-dev/2016-January/012194.html<= br> 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:
=C2=A0 Ins:
=C2=A0 =C2=A0 All non-confidential inputs are valid
=C2=A0 Outs:
=C2=A0 - 0..N: (new confidential outputs)
=C2=A0 =C2=A0 amount: 0
=C2=A0 =C2=A0 scriptPubkey: OP_2 <0x{32-byte-hash-value}>
=C2=A0 =C2=A0 witnessOut: <0x{petersen-commitment}> <0x{range-proo= f}>
=C2=A0 - last:
=C2=A0 =C2=A0 amount: 0
=C2=A0 =C2=A0 scriptPubkey: OP_RETURN OP_2 {blinding-fee-amount}
=C2=A0 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<= br> 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
> <bitcoin-d= ev@lists.linuxfoundation.org> wrote:
>> As long as an unspendable outputs (OP_RETURN outputs for example) = with
>> amount=3D0 are still allowed I don't see it being an issue for= anything.
>>
>> On Sep 5, 2017 2:52 PM, "Jorge Tim=C3=B3n via bitcoin-dev&quo= t;
>> <bitco= in-dev@lists.linuxfoundation.org> wrote:
>>> This is not a priority, not very important either.
>>> Right now it is possible to create 0-value outputs that are sp= endable
>>> and thus stay in the utxo (potentially forever). Requiring at = least 1
>>> satoshi per output doesn't really do much against a spam a= ttack 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 out= puts
>>> with null amounts in them?
>>>
>>> If not, I'm happy to create a BIP with its code, this shou= ld be simple.
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitco= in-dev@lists.linuxfoundation.org
>>> https://lists.linuxfounda= tion.org/mailman/listinfo/bitcoin-dev
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-d= ev@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

--001a113de4d6e54b250558967879--