From: "Hampus Sjöberg" <hampus.sjoberg@gmail.com>
To: CryptAxe <cryptaxe@gmail.com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] SF proposal: prohibit unspendable outputs with amount=0
Date: Thu, 7 Sep 2017 11:56:19 +0200 [thread overview]
Message-ID: <CAFMkqK8t+iADAbpWeTLZy+YjLQC5DsxHPFAWCcp063k-Dc9DYg@mail.gmail.com> (raw)
In-Reply-To: <1ffab7c0-7005-283e-07e5-4e85fc54de51@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4180 bytes --]
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 >= 1 satoshi transactions, but now it
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
> > <bitcoin-dev@lists.linuxfoundation.org> 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"
> >> <bitcoin-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 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
> >>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 5935 bytes --]
next prev parent reply other threads:[~2017-09-07 9:56 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-05 21:51 [bitcoin-dev] SF proposal: prohibit unspendable outputs with amount=0 Jorge Timón
2017-09-06 22:20 ` Tier Nolan
2017-09-06 23:54 ` CryptAxe
2017-09-07 1:29 ` Adam Back
2017-09-07 3:41 ` CryptAxe
2017-09-07 9:56 ` Hampus Sjöberg [this message]
2017-09-07 10:31 ` Tier Nolan
2017-09-07 18:00 ` Peter Todd
2017-09-09 21:11 ` Jorge Timón
2017-09-13 9:24 ` Peter Todd
2017-09-13 9:34 ` Gregory Maxwell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAFMkqK8t+iADAbpWeTLZy+YjLQC5DsxHPFAWCcp063k-Dc9DYg@mail.gmail.com \
--to=hampus.sjoberg@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=cryptaxe@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox