Discussion:
[bitcoin-dev] SF proposal: prohibit unspendable outputs with amount=0
Jorge Timón via bitcoin-dev
2017-09-05 21:51:45 UTC
Permalink
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.
Tier Nolan via bitcoin-dev
2017-09-06 22:20:02 UTC
Permalink
On Tue, Sep 5, 2017 at 10:51 PM, Jorge Timón via bitcoin-dev <
Post by Jorge Timón via bitcoin-dev
Is there any reason or use case to keep allowing spendable outputs
with null amounts in them?
Someone could have created a timelocked transaction that depends on a zero
value output.

This could be protected by requiring a tx version number change. Only zero
outputs in the new version would be affected.

I am not sure how strictly people are sticking to that rule though.
CryptAxe via bitcoin-dev
2017-09-06 23:54:03 UTC
Permalink
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" <
Post by Jorge Timón via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Adam Back via bitcoin-dev
2017-09-07 01:29:55 UTC
Permalink
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
Post by CryptAxe via bitcoin-dev
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"
Post by Jorge Timón via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
CryptAxe via bitcoin-dev
2017-09-07 03:41:49 UTC
Permalink
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 :)
Post by Adam Back via bitcoin-dev
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
Post by CryptAxe via bitcoin-dev
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"
Post by Jorge Timón via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Hampus Sjöberg via bitcoin-dev
2017-09-07 09:56:19 UTC
Permalink
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 <
Post by CryptAxe via bitcoin-dev
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))
All non-confidential inputs are valid
- 0..N: (new confidential outputs)
amount: 0
scriptPubkey: OP_2 <0x{32-byte-hash-value}>
witnessOut: <0x{petersen-commitment}> <0x{range-proof}>
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
witnessOut: <0x{petersen-commitment}> <0x{range-proof}>
I think I'm missing something obvious, someone point out why this is
stupid please :)
Post by Adam Back via bitcoin-dev
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
Post by CryptAxe via bitcoin-dev
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"
Post by Jorge Timón via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Tier Nolan via bitcoin-dev
2017-09-07 10:31:41 UTC
Permalink
You could have a timelocked transaction that has a zero value input (and
other non-zero inputs). If the SF happened, that transaction would become
unspendable.

The keys to the outputs may be lost or the co-signer may refuse to
cooperate.

There seems to be some objections to long term timelocked transactions.

If someone asked me about it, I would recommend that any timelocked
transactions should very carefully make sure that they use forms that are
popular.

I think the fairest rule would be that any change which makes some
transactions invalid should be opt-in and only apply to new transaction
version numbers.

If you create a timelocked transactions with an undefined version number,
then you have little to complain about.

If the version number is defined and in-use, then transactions should not
suddenly lose validity.

A refusal to commit to that makes long term locktime use much more risky.

On Thu, Sep 7, 2017 at 12:54 AM, CryptAxe via bitcoin-dev <
Post by CryptAxe via bitcoin-dev
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.
Post by Jorge Timón via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Peter Todd via bitcoin-dev
2017-09-07 18:00:14 UTC
Permalink
Post by Jorge Timón via bitcoin-dev
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.
Given that this has a very minimal cost for spammers - just a single satoshi -
I don't think this is worth the risk of making future upgrades more complex as
other posters have brought up.

Secondly, I think we have good reason to think that things like my own TXO
commitments and Bram's related work will make UTXO growth a non-issue in the
future.

So, I'd NACK such a proposal myself.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
Jorge Timón via bitcoin-dev
2017-09-09 21:11:57 UTC
Permalink
Tier Nolan, right, a new tx version would be required.

I have to look deeper into the CT as sf proposal.

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.

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.

Yeah, the costs for spammers are very small and doesn't really improve
things all that much, as acknowledged in the initial post.
Post by Peter Todd via bitcoin-dev
Post by Jorge Timón via bitcoin-dev
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.
Given that this has a very minimal cost for spammers - just a single satoshi -
I don't think this is worth the risk of making future upgrades more complex as
other posters have brought up.
Secondly, I think we have good reason to think that things like my own TXO
commitments and Bram's related work will make UTXO growth a non-issue in the
future.
So, I'd NACK such a proposal myself.
--
Peter Todd via bitcoin-dev
2017-09-13 09:24:34 UTC
Permalink
Post by Jorge Timón via bitcoin-dev
Tier Nolan, right, a new tx version would be required.
I have to look deeper into the CT as sf proposal.
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 to a
normal Bitcoin transaction is that fact that the sum of input values is >= the
sum of output values is proven via a CT proof, rather than revealing the actual
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 outputs.
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 value
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 zero,
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 sum 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.
Post by Jorge Timón via bitcoin-dev
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.
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.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
Gregory Maxwell via bitcoin-dev
2017-09-13 09:34:37 UTC
Permalink
On Wed, Sep 13, 2017 at 9:24 AM, Peter Todd via bitcoin-dev
Post by Peter Todd via bitcoin-dev
Quite simply, I just don't think the cost-benefit tradeoff of what you're
proposing makes sense.
I agree that dropping zero value outputs is a needless loss of
flexibility. In addition to the CT example, something similar could
be done for increased precision (nanobitcoin!).

Maybe if in the future the value of 1e-8 btc is high enough then an
argument could be made that requiring one is a meaningful reduction in
a miner's ability to spam up the network... but the argument doesn't
fly today... the cost in lost fee income from the spam just totally
dwarfs it.

Loading...