Good Afternoon,
'Avoiding a soft-fork' is a political concession. Consensus is none of
that.
KING JAMES HRMH
Great British Empire
Regards,
The Australian
LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
of Hougun Manor & Glencoe & British Empire
MR. Damian A. James Williamson
Wills
et al.
Willtech
www.willtech.com.au
www.go-overt.com
and other projects
earn.com/willtech
linkedin.com/in/damianwilliamson
m. 0487135719
f. +61261470192
This email does not constitute a general advice. Please disregard this
email if misdelivered.
On 2021-12-08 14:51, Ruben Somsen via bitcoin-dev wrote:
Hi Jeremy,
Thanks for sharing your thoughts.
To summarize your arguments: the intentionally malicious path to
getting the 0 sat output confirmed without being spent is uneconomical
compared to simply creating dust outputs. And even if it does happen,
the tx spending from the 0 sat output may still be valid (as long as
none of its inputs get spent elsewhere) and could eventually get
confirmed.
I think those are good points. I do still see a possibility where a
user non-maliciously happens to behave in a way that causes all of the
above to happen, but it does seem somewhat unlikely.
It could happen if all of the following occurs:
1. Another output happens to get spent at a higher feerate (e.g.
because an absolute timelock expires and the output gets used)
2. The tx spending the 0 sat output then happens to not make it into
the block due to the lower fees
3. The user then happens to invalidate the tx that was spending from
the 0 sat output (seems rational at that point)
Assuming this is the only scenario (I am at least not currently aware
of others), the question then becomes whether the above is acceptable
in order to avoid a soft fork.
Cheers,
Ruben
On Wed, Dec 8, 2021 at 6:41 PM Jeremy <[email protected]> wrote:
IMO this is not a big problem. The problem is not if a 0 value ever
enters the mempool, it's if it is never spent. And even if C2/P1
goes in, C1 still can be spent. In fact, it increases it's feerate
with P1's confirmation so it's somewhat likely it would go in. C2
further has to be pretty expensive compared to C1 in order to be
mined when C2 would not be, so the user trying to do this has to pay
for it.
If we're worried it might never be spent again since no incentive,
it's rational for miners *and users who care about bloat* to save to
disk the transaction spending it to resurrect it. The way this can
be broken is if the txn has two inputs and that input gets spent
separately.
That said, I think if we can say that taking advantage of keeping
the 0 value output will cost you more than if you just made it above
dust threshold, it shouldn't be economically rational to not just do
a dust threshold value output instead.
So I'm not sure the extent to which we should bend backwards to make
0 value outputs impossible v.s. making them inconvenient enough to
not be popular.
-------------------------------------
Consensus changes below:
-------------------------------------
Another possibility is to have a utxo with drop semantics; if UTXO X
with some flag on it is not spent in the block it is created, it
expires and can never be spent. This is essentially an inverse
timelock, but severely limited to one block and mempool evictions
can be handled as if a conflict were mined.
These types of 0 value outputs could be present just for attaching
fee in the mempool but be treated like an op_return otherwise. We
could add two cases for this: one bare segwit version (just the
number, no data) and one that's equivalent to taproot. This covers
OP_TRUE anchors very efficiently and ones that require a signature
as well.
This is relatively similar to how Transaction Sponsors works, but
without full tx graph de-linkage... obviously I think if we'll
entertain a consensus change, sponsors makes more sense, but
expiring utxos doesn't change as many properties of the tx-graph
validation so might be simpler.
_______________________________________________
bitcoin-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
