* [bitcoin-dev] Take 2: Removing the Dust Limit
@ 2021-12-08 1:28 Jeremy
2021-12-08 8:34 ` Bastien TEINTURIER
0 siblings, 1 reply; 8+ messages in thread
From: Jeremy @ 2021-12-08 1:28 UTC (permalink / raw)
To: Bitcoin development mailing list; +Cc: lightning-dev
[-- Attachment #1: Type: text/plain, Size: 1957 bytes --]
Bitcoin Devs (+cc lightning-dev),
Earlier this year I proposed allowing 0 value outputs and that was shot
down for various reasons, see
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-August/019307.html
I think that there can be a simple carve out now that package relay is
being launched based on my research into covenants from 2017
https://rubin.io/public/pdfs/multi-txn-contracts.pdf.
Essentially, if we allow 0 value outputs BUT require as a matter of policy
(or consensus, but policy has major advantages) that the output be used as
an Intermediate Output (that is, in order for the transaction to be
creating it to be in the mempool it must be spent by another tx) with the
additional rule that the parent must have a higher feerate after CPFP'ing
the parent than the parent alone we can both:
1) Allow 0 value outputs for things like Anchor Outputs (very good for not
getting your eltoo/Decker channels pinned by junk witness data using Anchor
Inputs, very good for not getting your channels drained by at-dust outputs)
2) Not allow 0 value utxos to proliferate long
3) It still being valid for a 0 value that somehow gets created to be spent
by the fee paying txn later
Just doing this as a mempool policy also has the benefits of not
introducing any new validation rules. Although in general the IUTXO concept
is very attractive, it complicates mempool :(
I understand this may also be really helpful for CTV based contracts (like
vault continuation hooks) as well as things like spacechains.
Such a rule -- if it's not clear -- presupposes a fully working package
relay system.
I believe that this addresses all the issues with allowing 0 value outputs
to be created for the narrow case of immediately spendable outputs.
Cheers,
Jeremy
p.s. why another post today? Thank Greg
https://twitter.com/JeremyRubin/status/1468390561417547780
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
[-- Attachment #2: Type: text/html, Size: 5392 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Take 2: Removing the Dust Limit
2021-12-08 1:28 [bitcoin-dev] Take 2: Removing the Dust Limit Jeremy
@ 2021-12-08 8:34 ` Bastien TEINTURIER
2021-12-08 10:46 ` [bitcoin-dev] [Lightning-dev] " Ruben Somsen
2021-12-08 17:18 ` [bitcoin-dev] " Jeremy
0 siblings, 2 replies; 8+ messages in thread
From: Bastien TEINTURIER @ 2021-12-08 8:34 UTC (permalink / raw)
To: Jeremy, Bitcoin Protocol Discussion; +Cc: lightning-dev
[-- Attachment #1: Type: text/plain, Size: 3369 bytes --]
Hi Jeremy,
Right now, lightning anchor outputs use a 330 sats amount. Each commitment
transaction has two such outputs, and only one of them is spent to help the
transaction get confirmed, so the other stays there and bloats the utxo set.
We allow anyone to spend them after a csv of 16 blocks, in the hope that
someone will claim a batch of them when the fees are low and remove them
from the utxo set. However, that trick wouldn't work with 0-value outputs,
as
no-one would ever claim them (doesn't make economical sense).
We actually need to have two of them to avoid pinning: each participant is
able to spend only one of these outputs while the parent tx is unconfirmed.
I believe N-party protocols would likely need N such outputs (not sure).
You mention a change to the carve-out rule, can you explain it further?
I believe it would be a necessary step, otherwise 0-value outputs for
CPFP actually seem worse than low-value ones...
Thanks,
Bastien
Le mer. 8 déc. 2021 à 02:29, Jeremy via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> a écrit :
> Bitcoin Devs (+cc lightning-dev),
>
> Earlier this year I proposed allowing 0 value outputs and that was shot
> down for various reasons, see
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-August/019307.html
>
> I think that there can be a simple carve out now that package relay is
> being launched based on my research into covenants from 2017
> https://rubin.io/public/pdfs/multi-txn-contracts.pdf.
>
> Essentially, if we allow 0 value outputs BUT require as a matter of policy
> (or consensus, but policy has major advantages) that the output be used as
> an Intermediate Output (that is, in order for the transaction to be
> creating it to be in the mempool it must be spent by another tx) with the
> additional rule that the parent must have a higher feerate after CPFP'ing
> the parent than the parent alone we can both:
>
> 1) Allow 0 value outputs for things like Anchor Outputs (very good for not
> getting your eltoo/Decker channels pinned by junk witness data using Anchor
> Inputs, very good for not getting your channels drained by at-dust outputs)
> 2) Not allow 0 value utxos to proliferate long
> 3) It still being valid for a 0 value that somehow gets created to be
> spent by the fee paying txn later
>
> Just doing this as a mempool policy also has the benefits of not
> introducing any new validation rules. Although in general the IUTXO concept
> is very attractive, it complicates mempool :(
>
> I understand this may also be really helpful for CTV based contracts (like
> vault continuation hooks) as well as things like spacechains.
>
> Such a rule -- if it's not clear -- presupposes a fully working package
> relay system.
>
> I believe that this addresses all the issues with allowing 0 value outputs
> to be created for the narrow case of immediately spendable outputs.
>
> Cheers,
>
> Jeremy
>
> p.s. why another post today? Thank Greg
> https://twitter.com/JeremyRubin/status/1468390561417547780
>
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
> <https://twitter.com/JeremyRubin>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 7423 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] Take 2: Removing the Dust Limit
2021-12-08 8:34 ` Bastien TEINTURIER
@ 2021-12-08 10:46 ` Ruben Somsen
2021-12-08 17:41 ` Jeremy
2021-12-08 17:18 ` [bitcoin-dev] " Jeremy
1 sibling, 1 reply; 8+ messages in thread
From: Ruben Somsen @ 2021-12-08 10:46 UTC (permalink / raw)
To: Bitcoin Protocol Discussion, lightning-dev
[-- Attachment #1: Type: text/plain, Size: 5587 bytes --]
Hi Jeremy,
I brought up the exact same thing at coredev, but unfortunately I came up
with a way in which the 0 sat output could still enter the UTXO set under
those rules:
- Parent P1 (0 sat per byte) has 2 outputs, one is 0 sat
- Child C1 spends the 0 sat output for a combined feerate of 1 sat per byte
and they enter the mempool as a package
- Child C2 spends the other output of P1 with a really high feerate and
enters the mempool
- Fees rise and child C1 falls out of the mempool, leaving the 0 sat output
unspent
For this to not be a problem, the 0 sat output needs to provably be the
only spendable output. As you pointed out to me a few days ago, having a
relative timelock on the other outputs would do the trick (and this happens
to be true for spacechains), but that will only be provable if all script
conditions are visible prior to spending time (ruling out p2sh and taproot,
and conflicting with standardness rules for transactions).
It's worth noting out that you can't really make a policy rule that says
the 0 sat output can't be left unspent (i.e. C1 can't be evicted without
also evicting P1), as this would not mirror economically rational behavior
for miners (they would get more fees if they evicted C1, so we must assume
they will, if the transaction ever reaches them).
This last example really points out the tricky situation we're dealing
with. In my opinion, we'd only want to relay 0 sat outputs if we can
guarantee that it's never economically profitable to mine them without them
getting spent in the same block.
Finally, here's a timestamped link to a diagram that shows where 0 sat
outputs would be helpful for spacechains (otherwise someone would have to
pay the dust up front for countless outputs):
https://youtu.be/N2ow4Q34Jeg?t=2556
Cheers,
Ruben
On Wed, Dec 8, 2021 at 9:35 AM Bastien TEINTURIER <bastien@acinq•fr> wrote:
> Hi Jeremy,
>
> Right now, lightning anchor outputs use a 330 sats amount. Each commitment
> transaction has two such outputs, and only one of them is spent to help the
> transaction get confirmed, so the other stays there and bloats the utxo
> set.
> We allow anyone to spend them after a csv of 16 blocks, in the hope that
> someone will claim a batch of them when the fees are low and remove them
> from the utxo set. However, that trick wouldn't work with 0-value outputs,
> as
> no-one would ever claim them (doesn't make economical sense).
>
> We actually need to have two of them to avoid pinning: each participant is
> able to spend only one of these outputs while the parent tx is unconfirmed.
> I believe N-party protocols would likely need N such outputs (not sure).
>
> You mention a change to the carve-out rule, can you explain it further?
> I believe it would be a necessary step, otherwise 0-value outputs for
> CPFP actually seem worse than low-value ones...
>
> Thanks,
> Bastien
>
> Le mer. 8 déc. 2021 à 02:29, Jeremy via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> a écrit :
>
>> Bitcoin Devs (+cc lightning-dev),
>>
>> Earlier this year I proposed allowing 0 value outputs and that was shot
>> down for various reasons, see
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-August/019307.html
>>
>> I think that there can be a simple carve out now that package relay is
>> being launched based on my research into covenants from 2017
>> https://rubin.io/public/pdfs/multi-txn-contracts.pdf.
>>
>> Essentially, if we allow 0 value outputs BUT require as a matter of
>> policy (or consensus, but policy has major advantages) that the output be
>> used as an Intermediate Output (that is, in order for the transaction to be
>> creating it to be in the mempool it must be spent by another tx) with the
>> additional rule that the parent must have a higher feerate after CPFP'ing
>> the parent than the parent alone we can both:
>>
>> 1) Allow 0 value outputs for things like Anchor Outputs (very good for
>> not getting your eltoo/Decker channels pinned by junk witness data using
>> Anchor Inputs, very good for not getting your channels drained by at-dust
>> outputs)
>> 2) Not allow 0 value utxos to proliferate long
>> 3) It still being valid for a 0 value that somehow gets created to be
>> spent by the fee paying txn later
>>
>> Just doing this as a mempool policy also has the benefits of not
>> introducing any new validation rules. Although in general the IUTXO concept
>> is very attractive, it complicates mempool :(
>>
>> I understand this may also be really helpful for CTV based contracts
>> (like vault continuation hooks) as well as things like spacechains.
>>
>> Such a rule -- if it's not clear -- presupposes a fully working package
>> relay system.
>>
>> I believe that this addresses all the issues with allowing 0 value
>> outputs to be created for the narrow case of immediately spendable outputs.
>>
>> Cheers,
>>
>> Jeremy
>>
>> p.s. why another post today? Thank Greg
>> https://twitter.com/JeremyRubin/status/1468390561417547780
>>
>>
>> --
>> @JeremyRubin <https://twitter.com/JeremyRubin>
>> <https://twitter.com/JeremyRubin>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
[-- Attachment #2: Type: text/html, Size: 10335 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Take 2: Removing the Dust Limit
2021-12-08 8:34 ` Bastien TEINTURIER
2021-12-08 10:46 ` [bitcoin-dev] [Lightning-dev] " Ruben Somsen
@ 2021-12-08 17:18 ` Jeremy
1 sibling, 0 replies; 8+ messages in thread
From: Jeremy @ 2021-12-08 17:18 UTC (permalink / raw)
To: Bastien TEINTURIER; +Cc: Bitcoin Protocol Discussion, lightning-dev
[-- Attachment #1: Type: text/plain, Size: 1024 bytes --]
Bastien,
The issue is that with Decker Channels you either use SIGHASH_ALL / APO and
don't allow adding outs (this protects against certain RBF pinning on the
root with bloated wtxid data) and have anchor outputs or you do allow them
and then are RBF pinnable (but can have change).
Assuming you use anchor outs, then you really can't use dust-threshold
outputs as it either breaks the ratcheting update validity (if the specific
amount paid to output matters) OR it allows many non-latest updates to
fully drain the UTXO of any value.
You can get around the needing for N of them by having a congestion-control
tree setup in theory; then you only need log(n) data for one bumper, and
(say) 1.25x the data if all N want to bump. This can be a nice trade-off
between letting everyone bump and not. Since these could be chains of
IUTXO, they don't need to carry any weight directly.
The carve out would just be to ensure that CPFP 0 values are known how to
be spent.
--
@JeremyRubin <https://twitter.com/JeremyRubin>
[-- Attachment #2: Type: text/html, Size: 2898 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] Take 2: Removing the Dust Limit
2021-12-08 10:46 ` [bitcoin-dev] [Lightning-dev] " Ruben Somsen
@ 2021-12-08 17:41 ` Jeremy
2021-12-08 22:51 ` Ruben Somsen
0 siblings, 1 reply; 8+ messages in thread
From: Jeremy @ 2021-12-08 17:41 UTC (permalink / raw)
To: Ruben Somsen; +Cc: Bitcoin Protocol Discussion, lightning-dev
[-- Attachment #1: Type: text/plain, Size: 2127 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 4826 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] Take 2: Removing the Dust Limit
2021-12-08 17:41 ` Jeremy
@ 2021-12-08 22:51 ` Ruben Somsen
2021-12-09 6:27 ` damian
0 siblings, 1 reply; 8+ messages in thread
From: Ruben Somsen @ 2021-12-08 22:51 UTC (permalink / raw)
To: Jeremy; +Cc: Bitcoin Protocol Discussion, lightning-dev
[-- Attachment #1: Type: text/plain, Size: 3453 bytes --]
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 <jlrubin@mit•edu> 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.
>
>
>
>
>
[-- Attachment #2: Type: text/html, Size: 7843 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] Take 2: Removing the Dust Limit
2021-12-08 22:51 ` Ruben Somsen
@ 2021-12-09 6:27 ` damian
0 siblings, 0 replies; 8+ messages in thread
From: damian @ 2021-12-09 6:27 UTC (permalink / raw)
To: Ruben Somsen, Bitcoin Protocol Discussion; +Cc: lightning-dev
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 <jlrubin@mit•edu> 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
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Take 2: Removing the Dust Limit
@ 2022-01-21 12:16 shymaa arafat
0 siblings, 0 replies; 8+ messages in thread
From: shymaa arafat @ 2022-01-21 12:16 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1229 bytes --]
Dear Sir,
Regarding your message
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-December/019636.html
Specifically the part
*"Right now, lightning anchor outputs use a 330 sats amount. Each
commitment*
*transaction has two such outputs, and only one of them is spent"*
I was wondering *is there a way to distinguish those 2 dust UTXOs?*
I mean does(or could) the protocol force the user to always spend the first
not any of them at random?
-My point is to distinguish between them when inserted in the UTXO set to
know in advance which will be spent so fast in the next transaction, and
which is gonna stay there for a while?
-If you look at the number of addresses holding ≤1$ here (by subtracting
total from >1$), you would find it doesn't change very much with days
https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html
-Meaning not that just official dust value, but values ≤1$ are rarely spent
unless one forced to. I always had the idea of storing them separately
(along with non-standard & burned ones at least from public addresses,
these should be separated too as they're not expected be spent ever)
.
So the answer may make a difference,
Thank you
Shymaa M Arafat
[-- Attachment #2: Type: text/html, Size: 2003 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2022-01-21 12:16 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-12-08 1:28 [bitcoin-dev] Take 2: Removing the Dust Limit Jeremy
2021-12-08 8:34 ` Bastien TEINTURIER
2021-12-08 10:46 ` [bitcoin-dev] [Lightning-dev] " Ruben Somsen
2021-12-08 17:41 ` Jeremy
2021-12-08 22:51 ` Ruben Somsen
2021-12-09 6:27 ` damian
2021-12-08 17:18 ` [bitcoin-dev] " Jeremy
2022-01-21 12:16 shymaa arafat
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox