public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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 --]

  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 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$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=cryptaxe@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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