📅 Original date posted:2021-08-23 📝 Original message: The ...

2023-06-09T13:03:35Z

In reply to nevent1q…86w8
_________________________

📅 Original date posted:2021-08-23
📝 Original message:
The dust limit is required to prevent massive UTXO expansion. The details
around miner incentives to process dust are irrelevant to this because
there simply needs to be a buffer of friction to prevent spamming the UTXO
set to be much, much larger, as an *attack* and long-term overhead on both
storage size and resources in purposing UTXO data within
applications/servers.

Even if I were wrong, it is still silly to propose changing a thing no one
actually needs or wants changed for any practical application.

It ain't broke, don't fix it.

On Fri, Aug 20, 2021 at 7:00 AM <
lightning-dev-request at lists.linuxfoundation.org> wrote:

> Send Lightning-dev mailing list submissions to
> lightning-dev at lists.linuxfoundation.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> or, via email, send a message with subject or body 'help' to
> lightning-dev-request at lists.linuxfoundation.org
>
> You can reach the person managing the list at
> lightning-dev-owner at lists.linuxfoundation.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Lightning-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: [bitcoin-dev] Removing the Dust Limit (Jeremy)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 19 Aug 2021 23:51:31 -0500
> From: Jeremy <jlrubin at mit.edu>
> To: Bitcoin Protocol Discussion
> <bitcoin-dev at lists.linuxfoundation.org>
> Cc: lightning-dev <lightning-dev at lists.linuxfoundation.org>
> Subject: Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit
> Message-ID:
> <
> CAD5xwhiEDa2KjF265iDZ1ism4AFzh3S3D4cJSESVVKNwv9L7zA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> one interesting point that came up at the bitdevs in austin today that
> favors remove that i believe is new to this discussion (it was new to me):
>
> the argument can be reduced to:
>
> - dust limit is a per-node relay policy.
> - it is rational for miners to mine dust outputs given their cost of
> maintenance (storing the output potentially forever) is lower than their
> immediate reward in fees.
> - if txn relaying nodes censor something that a miner would mine, users
> will seek a private/direct relay to the miner and vice versa.
> - if direct relay to miner becomes popular, it is both bad for privacy and
> decentralization.
> - therefore the dust limit, should there be demand to create dust at
> prevailing mempool feerates, causes an incentive to increase network
> centralization (immediately)
>
> the tradeoff is if a short term immediate incentive to promote network
> centralization is better or worse than a long term node operator overhead.
>
>
> ///////////////////
>
> my take is that:
>
> 1) having a dust limit is worse since we'd rather not have an incentive to
> produce or roll out centralizing software, whereas not having a dust limit
> creates an mild incentive for node operators to improve utreexo
> decentralizing software.
> 2) it's hard to quantify the magnitude of the incentives, which does
> matter.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210819/831b9608/attachment-0001.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
> ------------------------------
>
> End of Lightning-dev Digest, Vol 72, Issue 18
> *********************************************
>

--
~ John Carvalho

Schedule: https://calendly.com/bitcoinerrorlog
Chat: https://t.me/bitcoinerrorlog
Social: https://twitter.com/bitcoinerrorlog
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210823/dfbbf45c/attachment.html>;

📅 Original date posted:2021-06-29 📝 Original message: ...

2023-06-09T13:02:47Z

In reply to nevent1q…gcg9
_________________________

📅 Original date posted:2021-06-29
📝 Original message:
Thanks for instigating this, Rusty! 0conf/turbo channels have been hackable
for a long time, and we would love to unlock new user experiences for our
platforms with it, formally if possible.

0conf is desired by every wallet, every LN exchange, and truly shows off
something only LN can uniquely offer as a UX.

We are happy to support how we can, and answer any questions from the
trenches.

On Tue, Jun 29, 2021 at 8:34 AM Rusty Russell <rusty at rustcorp.com.au> wrote:

> Hi all!
>
> John Carvalo recently pointed out that not every implementation
> accepts zero-conf channels, but they are useful. Roasbeef also recently
> noted that they're not spec'd.
>
> How do you all do it? Here's a strawman proposal:
>
> 1. Assign a new feature bit "I accept zeroconf channels".
> 2. If both negotiate this, you can send update_add_htlc (etc) *before*
> funding_locked without the peer getting upset.
> 3. Nodes are advised *not* to forward HTLCs from an unconfirmed channel
> unless they have explicit reason to trust that node (they can still
> send *out* that channel, because that's not their problem!).
>
> It's a pretty simple change, TBH (this zeroconf feature would also
> create a new set of channel_types, altering that PR).
>
> I can draft something this week?
>
> Thanks!
> Rusty.
>

--
~ John Carvalho

Schedule: https://calendly.com/bitcoinerrorlog
Chat: https://t.me/bitcoinerrorlog
Social: https://twitter.com/bitcoinerrorlog
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210629/9dd76388/attachment.html>;

Nostr notes by Bitcoin Error Log [ARCHIVE]

📅 Original date posted:2021-08-23 📝 Original message: The ...

📅 Original date posted:2021-06-29 📝 Original message: ...