public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [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
@ 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