public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

From: Jeremy <jlrubin@mit•edu>
To: Bitcoin development mailing list <bitcoin-dev@lists•linuxfoundation.org>
Cc: lightning-dev <lightning-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] Take 2: Removing the Dust Limit
Date: Tue, 7 Dec 2021 17:28:42 -0800	[thread overview]
Message-ID: <CAD5xwhid2OH0GzXPvqWgsMag4J9zidsewEquT-JoOweVD5pxZg@mail.gmail.com> (raw)

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

next             reply	other threads:[~2021-12-08  1:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-08  1:28 Jeremy [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAD5xwhid2OH0GzXPvqWgsMag4J9zidsewEquT-JoOweVD5pxZg@mail.gmail.com \
    --to=jlrubin@mit$(echo .)edu \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=lightning-dev@lists$(echo .)linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox