📅 Original date posted:2021-12-08
📝 Original message:
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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211208/58427839/attachment.html>;
Bastien TEINTURIER [ARCHIVE] /
npub17f…ntr0s
2023-06-09 13:04:43
in reply to nevent1q…wcpe
Author Public Key
npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0sPublished at
2023-06-09 13:04:43Event JSON
{
"id": "f3dc5bbfaa27b2cf81f20b7d3ed0624f09c3e8e1f24ef5969659d1c50b875aab",
"pubkey": "f26569a10f83f6935797b8b53a87974fdcc1de6abd31e3b1a3a19bdaed8031cb",
"created_at": 1686315883,
"kind": 1,
"tags": [
[
"e",
"5dcb5d377dd1b91522b473139889dc28f90fdc219b06fae8bf32d96102eb8ce4",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2021-12-08\n📝 Original message:\nHi Jeremy,\n\nRight now, lightning anchor outputs use a 330 sats amount. Each commitment\ntransaction has two such outputs, and only one of them is spent to help the\ntransaction get confirmed, so the other stays there and bloats the utxo set.\nWe allow anyone to spend them after a csv of 16 blocks, in the hope that\nsomeone will claim a batch of them when the fees are low and remove them\nfrom the utxo set. However, that trick wouldn't work with 0-value outputs,\nas\nno-one would ever claim them (doesn't make economical sense).\n\nWe actually need to have two of them to avoid pinning: each participant is\nable to spend only one of these outputs while the parent tx is unconfirmed.\nI believe N-party protocols would likely need N such outputs (not sure).\n\nYou mention a change to the carve-out rule, can you explain it further?\nI believe it would be a necessary step, otherwise 0-value outputs for\nCPFP actually seem worse than low-value ones...\n\nThanks,\nBastien\n\nLe mer. 8 déc. 2021 à 02:29, Jeremy via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e a écrit :\n\n\u003e Bitcoin Devs (+cc lightning-dev),\n\u003e\n\u003e Earlier this year I proposed allowing 0 value outputs and that was shot\n\u003e down for various reasons, see\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-August/019307.html\n\u003e\n\u003e I think that there can be a simple carve out now that package relay is\n\u003e being launched based on my research into covenants from 2017\n\u003e https://rubin.io/public/pdfs/multi-txn-contracts.pdf.\n\u003e\n\u003e Essentially, if we allow 0 value outputs BUT require as a matter of policy\n\u003e (or consensus, but policy has major advantages) that the output be used as\n\u003e an Intermediate Output (that is, in order for the transaction to be\n\u003e creating it to be in the mempool it must be spent by another tx) with the\n\u003e additional rule that the parent must have a higher feerate after CPFP'ing\n\u003e the parent than the parent alone we can both:\n\u003e\n\u003e 1) Allow 0 value outputs for things like Anchor Outputs (very good for not\n\u003e getting your eltoo/Decker channels pinned by junk witness data using Anchor\n\u003e Inputs, very good for not getting your channels drained by at-dust outputs)\n\u003e 2) Not allow 0 value utxos to proliferate long\n\u003e 3) It still being valid for a 0 value that somehow gets created to be\n\u003e spent by the fee paying txn later\n\u003e\n\u003e Just doing this as a mempool policy also has the benefits of not\n\u003e introducing any new validation rules. Although in general the IUTXO concept\n\u003e is very attractive, it complicates mempool :(\n\u003e\n\u003e I understand this may also be really helpful for CTV based contracts (like\n\u003e vault continuation hooks) as well as things like spacechains.\n\u003e\n\u003e Such a rule -- if it's not clear -- presupposes a fully working package\n\u003e relay system.\n\u003e\n\u003e I believe that this addresses all the issues with allowing 0 value outputs\n\u003e to be created for the narrow case of immediately spendable outputs.\n\u003e\n\u003e Cheers,\n\u003e\n\u003e Jeremy\n\u003e\n\u003e p.s. why another post today? Thank Greg\n\u003e https://twitter.com/JeremyRubin/status/1468390561417547780\n\u003e\n\u003e\n\u003e --\n\u003e @JeremyRubin \u003chttps://twitter.com/JeremyRubin\u003e\n\u003e \u003chttps://twitter.com/JeremyRubin\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211208/58427839/attachment.html\u003e",
"sig": "76935bb95b745b4197185d0b97cafac3b8aa481b6e0276f46c63e08f01714b3adf5cb2b1e498ba57614e61e4e54f9a43303e4d56e77039be502f0788b2a69207"
}