From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 6F0C7C000E; Fri, 20 Aug 2021 05:45:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 5692B401B2; Fri, 20 Aug 2021 05:45:49 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYFCU00lCp00; Fri, 20 Aug 2021 05:45:45 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) by smtp2.osuosl.org (Postfix) with ESMTPS id 23E0E400D9; Fri, 20 Aug 2021 05:45:45 +0000 (UTC) Received: by mail-pj1-x1029.google.com with SMTP id n5so6599345pjt.4; Thu, 19 Aug 2021 22:45:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PrHBw3dx1oFexsTr4rXR24jU09QFyWORRvwRzEWEfHI=; b=Y3B1qdjMSXRSEjlkU69cpEmgujqFER0J0Shk2xjE0Cdhv39tbMgMn5adMQNQqSAZdK 09EADcgDgmB9BihHWmazrTZQQVY7I2EfrTb0ifJ56ZKjtNGhRR1m1jiPPell6A38IoXV K3RJk2t86cH7MbbPGAh4PJL9QLBV998iZrESbDQkKoXEIhBXBrBU004j/OMWixVCZQwm VtXbyCuk3r16UFJ8aDQJmnDa78oVY+P8T/uztMD3oYom4teVlCo3QvzwedfS/+zmzxV2 F/8/ajpeH2BRgrOJ1/qaDQB1o5KTqdHhpDYkTIzS+KshtVLDwK8XrqWl0plpVxZHt8Rf nCTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PrHBw3dx1oFexsTr4rXR24jU09QFyWORRvwRzEWEfHI=; b=LpRlWExWe0Jqf3gP85jHm/xk3OWfQE/Miagd3e+hk/quLrJiwxxe37g1DN03JreLWS h/COtCwaabFa3912LfZwy8E5YWAjmQ402ndFW463W8EG0uHQ9DFMK16dhbaBKvyNiH+q kljJ3USMUP+MNHcX23iua7EtxJIqKx6WEovmBtTZ4NMVgr8W/O3HR3st+u+ZHLPzTjXE wVPQ/If5F/jHfm4sGKJe9kbkk5biuidi4ncz63DZ/Os2BnNw5g0T7xiJlLMkjBac95fy g2ks4TkMQ3uTEvq9qiWTcb6my4GyWeCMbY2FI5mGhrVwitc7hrQbZiQkS3BM7aUfAb0g nGVg== X-Gm-Message-State: AOAM533vmxlSIweP1hj/ToPK4XSp73hlKQYMGuaWK/Cw+NMwjZNwwVTV l/sWcURmjJvhl0aJE4/MvjlX3SVGng2vnaz2xiE= X-Google-Smtp-Source: ABdhPJy8zrXxapQYvpEUR4PlDpyXqJEgUtHPyBCay5CUd9Ek9Rm59VBJTDcPh6X1jOzZIyRF4elKWrce9qWFSk6+P4Y= X-Received: by 2002:a17:90a:604e:: with SMTP id h14mr2844335pjm.181.1629438344531; Thu, 19 Aug 2021 22:45:44 -0700 (PDT) MIME-Version: 1.0 References: <20210810061441.6rg3quotiycomcp6@ganymede> <20210812220339.GA3416@erisian.com.au> In-Reply-To: From: shymaa arafat Date: Fri, 20 Aug 2021 07:45:31 +0200 Message-ID: To: Jeremy , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000b591ac05c9f72dee" X-Mailman-Approved-At: Fri, 20 Aug 2021 08:23:17 +0000 Cc: lightning-dev Subject: Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2021 05:45:49 -0000 --000000000000b591ac05c9f72dee Content-Type: text/plain; charset="UTF-8" On Fri, Aug 20, 2021, 06:52 Jeremy via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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. > -Here, u r assuming miners not running full nodes, or even stateless nodes as in Utreexo -otherwise they suffer from storing dust UTXOS/their effect on proof length, right? - 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. > Why not having dust limit improves Utreexo, I think (and tried to suggest many times) separate storing of dust&other non spendable UTXOS (and their hashes) so that they do not affect other UTXOS proofs ( and not brought into main memory unless called as a TXO) 2) it's hard to quantify the magnitude of the incentives, which does matter. > I honestly don't get the long term perspective of miners Incentivised to storing small dust UTXOS instead of having their values added to the fee. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000b591ac05c9f72dee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Aug 20, 2021, 06:52 Jeremy via bitcoin-dev <= ;bitcoin-dev@lists= .linuxfoundation.org> wrote:
one interesting point= that came up at the bitdevs in austin today that favors remove that i beli= eve 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 d= ust outputs given their cost of maintenance=C2=A0(storing the output potent= ially forever) is lower than their immediate reward in fees.
-Here, u=C2=A0 r assuming miners no= t running full nodes, or even stateless nodes as in Utreexo
-otherwise they suffer from storing dust UTXOS/their effect on pr= oof length, right?

- if txn relaying nodes censor something tha= t a miner would mine, users will seek a private/direct relay to the miner a= nd vice versa.
- if direct relay t= o 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 in= centive to increase network centralization=C2=A0(immediately)

t= he tradeoff is if a short term immediate incentive to promote network centr= alization is better or worse than a long term node operator overhead.
=


///////////////////

my take is that:

1)=C2=A0having a dust limit is worse= since we'd rather not have an incentive to produce or roll out central= izing software, whereas not having a dust limit creates an mild incentive f= or node operators to improve utreexo decentralizing software.
Why not having dust limit improves= Utreexo, I think (and tried to suggest many times) separate storing of dus= t&other non spendable UTXOS (and their hashes) so that they do not affe= ct other UTXOS proofs ( and not brought into main memory unless called as a= TXO)

2) it's hard to quantify the magnitude of the incenti= ves, which does matter.
I honestly don't get the long term perspective of miners Incentivise= d to storing small dust UTXOS instead of having their values added to the f= ee.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
--000000000000b591ac05c9f72dee--