* [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