* [bitcoin-dev] SF proposal: prohibit unspendable outputs with amount=0
@ 2017-09-05 21:51 Jorge Timón
2017-09-06 22:20 ` Tier Nolan
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Jorge Timón @ 2017-09-05 21:51 UTC (permalink / raw)
To: 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.
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [bitcoin-dev] SF proposal: prohibit unspendable outputs with amount=0 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 18:00 ` Peter Todd 2 siblings, 0 replies; 11+ messages in thread From: Tier Nolan @ 2017-09-06 22:20 UTC (permalink / raw) To: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 507 bytes --] On Tue, Sep 5, 2017 at 10:51 PM, Jorge Timón via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > 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. [-- Attachment #2: Type: text/html, Size: 879 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] SF proposal: prohibit unspendable outputs with amount=0 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 10:31 ` Tier Nolan 2017-09-07 18:00 ` Peter Todd 2 siblings, 2 replies; 11+ messages in thread From: CryptAxe @ 2017-09-06 23:54 UTC (permalink / raw) To: Jorge Timón, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 977 bytes --] 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 > [-- Attachment #2: Type: text/html, Size: 1501 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] SF proposal: prohibit unspendable outputs with amount=0 2017-09-06 23:54 ` CryptAxe @ 2017-09-07 1:29 ` Adam Back 2017-09-07 3:41 ` CryptAxe 2017-09-07 10:31 ` Tier Nolan 1 sibling, 1 reply; 11+ messages in thread From: Adam Back @ 2017-09-07 1:29 UTC (permalink / raw) To: CryptAxe, Bitcoin Protocol Discussion 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 > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] SF proposal: prohibit unspendable outputs with amount=0 2017-09-07 1:29 ` Adam Back @ 2017-09-07 3:41 ` CryptAxe 2017-09-07 9:56 ` Hampus Sjöberg 0 siblings, 1 reply; 11+ messages in thread From: CryptAxe @ 2017-09-07 3:41 UTC (permalink / raw) To: adam, Bitcoin Protocol Discussion 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 >> ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] SF proposal: prohibit unspendable outputs with amount=0 2017-09-07 3:41 ` CryptAxe @ 2017-09-07 9:56 ` Hampus Sjöberg 0 siblings, 0 replies; 11+ messages in thread From: Hampus Sjöberg @ 2017-09-07 9:56 UTC (permalink / raw) To: CryptAxe, Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] SF proposal: prohibit unspendable outputs with amount=0 2017-09-06 23:54 ` CryptAxe 2017-09-07 1:29 ` Adam Back @ 2017-09-07 10:31 ` Tier Nolan 1 sibling, 0 replies; 11+ messages in thread From: Tier Nolan @ 2017-09-07 10:31 UTC (permalink / raw) To: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 2245 bytes --] 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 < 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 > > [-- Attachment #2: Type: text/html, Size: 3456 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] SF proposal: prohibit unspendable outputs with amount=0 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 18:00 ` Peter Todd 2017-09-09 21:11 ` Jorge Timón 2 siblings, 1 reply; 11+ messages in thread From: Peter Todd @ 2017-09-07 18:00 UTC (permalink / raw) To: Jorge Timón, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 888 bytes --] On Tue, Sep 05, 2017 at 11:51:45PM +0200, 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. 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 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 455 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] SF proposal: prohibit unspendable outputs with amount=0 2017-09-07 18:00 ` Peter Todd @ 2017-09-09 21:11 ` Jorge Timón 2017-09-13 9:24 ` Peter Todd 0 siblings, 1 reply; 11+ messages in thread From: Jorge Timón @ 2017-09-09 21:11 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin Protocol Discussion 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. On Thu, Sep 7, 2017 at 8:00 PM, Peter Todd <pete@petertodd•org> wrote: > On Tue, Sep 05, 2017 at 11:51:45PM +0200, 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. > > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] SF proposal: prohibit unspendable outputs with amount=0 2017-09-09 21:11 ` Jorge Timón @ 2017-09-13 9:24 ` Peter Todd 2017-09-13 9:34 ` Gregory Maxwell 0 siblings, 1 reply; 11+ messages in thread From: Peter Todd @ 2017-09-13 9:24 UTC (permalink / raw) To: Jorge Timón; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 3104 bytes --] On Sat, Sep 09, 2017 at 11:11:57PM +0200, Jorge Timón wrote: > 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. > 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 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 455 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] SF proposal: prohibit unspendable outputs with amount=0 2017-09-13 9:24 ` Peter Todd @ 2017-09-13 9:34 ` Gregory Maxwell 0 siblings, 0 replies; 11+ messages in thread From: Gregory Maxwell @ 2017-09-13 9:34 UTC (permalink / raw) To: Peter Todd, Bitcoin Protocol Discussion On Wed, Sep 13, 2017 at 9:24 AM, Peter Todd via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2017-09-13 9:34 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox