From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 584D1C000E; Sun, 8 Aug 2021 21:41:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 3B1BE82C1E; Sun, 8 Aug 2021 21:41:40 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_SBL_A=0.1] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NU3012s8v8lt; Sun, 8 Aug 2021 21:41:36 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) by smtp1.osuosl.org (Postfix) with ESMTPS id 4758C82B8C; Sun, 8 Aug 2021 21:41:36 +0000 (UTC) Received: by mail-lf1-x131.google.com with SMTP id g30so25523909lfv.4; Sun, 08 Aug 2021 14:41:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=mNK0307j768H64ykGqRAPi5daBIAEI97NetP5yxO8p4=; b=WbZhD6PGOhCSJ0EnREuR0hWrcYWH7cwpcRTN0WUJrbxKjyHz2aSSjaCCABwZbetqPM av2QOS6a44VaN99R0bNkS+ZjTGHO8QLP24Bycg2/IKf5vFY6aSk6jEkiY9KV3Yo1QU6o BfRGywDoVnQT8pnC8JZDgaUhuIrqSaVhfW8FbGgD3t+YQcg7SoqTQLdDawrQutd4Im0W pTlkzzpz7wo2lzHrfGYu2006VopOMKJYHGeib3yvkVoF+yinIfBGzK5++6C3Hh55S8sb 8Y5AwbdCAysmwGbygBgzNGJTUm48tpXw55vHAumWCME+0fnrEDO3nGbz+zxkqddMhj41 acNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=mNK0307j768H64ykGqRAPi5daBIAEI97NetP5yxO8p4=; b=rxjRtqJsQGMJWmHfUbafgUU9iOaxcRcMN2OIp3xvfJrfCYP+lXrdA4mPy5HrihepbL Ess86+201/JCIuRROcCOgCcu+GXR4iRmS0I0PLI9ldjC1iAIrpS5ozxlNKr95qRK0Stq bKJutpNIbF0kre5GNm9K1CE4qUvK3cZAuZiSjj63xuAzLeeRsH60QajJZajoWLN4p8AS 6lZaLkuiIPhjqxVb4raKLdjUu2e6GsD3sRFqzg4nUidWxHUs24CreXtfCfvmr97zfk5f Ew2jStNYj571yNgEaWVomoPDnk4hq8FxVSeD5+1Rngz+bEPjyVtLtG+p3cJmUYWbIWJ3 jJWw== X-Gm-Message-State: AOAM532EvNhY9TLINLuShVPdfc3qDJAvqMdx1KtGd7eeS+QAhPCFz2lJ d0aAz19qjbr3ctTrB21bNJE= X-Google-Smtp-Source: ABdhPJwGaRuPfwAaGuf7M0TqUL1IZAGBLaGL6+cTQQmwOxE4Fu7tMrCirZY7Bh+OO8tX/QV8eHjxQw== X-Received: by 2002:ac2:446a:: with SMTP id y10mr14816100lfl.489.1628458894230; Sun, 08 Aug 2021 14:41:34 -0700 (PDT) Received: from smtpclient.apple ([94.25.229.253]) by smtp.gmail.com with ESMTPSA id c13sm1527118lfv.133.2021.08.08.14.41.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 08 Aug 2021 14:41:33 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Oleg Andreev Mime-Version: 1.0 (1.0) Date: Mon, 9 Aug 2021 00:41:32 +0300 Message-Id: <29C08A0C-E9DA-4D9A-B27A-A5479D2B434E@gmail.com> References: In-Reply-To: To: Matt Corallo , Bitcoin Protocol Discussion X-Mailer: iPhone Mail (18G69) Cc: lightning-dev Subject: Re: [bitcoin-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: Sun, 08 Aug 2021 21:41:40 -0000 I agree with Jeremy. Dust limit works due to design accident: that outputs a= re not encrypted. But outputs are private business and the real issue is onl= y the cost of utxo set storage born by every user. There are two ways to add= ress this: 1) either make ppl pay for renting that storage (which creates a ton of prob= lems of its own) 2) or make storage extremely cheap so it remains cheap at any scale. This is= perfectly solved by Utreexo. But looking at the private data because you can is a hack that creates issue= s of its own. > On 9 Aug 2021, at 00:16, Matt Corallo via bitcoin-dev wrote: >=20 > =EF=BB=BFIf it weren't for the implications in changing standardness here,= I think we should consider increasing the dust limit instead. >=20 > The size of the UTXO set is a fundamental scalability constraint of the sy= stem. In fact, with proposals like assume-utxo/background history sync it is= arguably *the* fundamental scalability constraint of the system. Today's du= st limit is incredibly low - its based on a feerate of only 3 sat/vByte in o= rder for claiming the UTXO to have *any* value, not just having enough value= to be worth bothering. As feerates have gone up over time, and as we expect= them to go up further, we should be considering drastically increasing the 3= sat/vByte basis to something more like 20 sat/vB. >=20 > Matt >=20 >> On 8/8/21 14:52, Jeremy via bitcoin-dev wrote: >> We should remove the dust limit from Bitcoin. Five reasons: >> 1) it's not our business what outputs people want to create >=20 > It is precisely our business - the costs are born by us, not the creator. I= f someone wants to create outputs which don't make sense to spend, they can d= o so using OP_RETURN, since they won't spend it anyway. >=20 >> 2) dust outputs can be used in various authentication/delegation smart co= ntracts >=20 > So can low-value-but-enough-to-be-worth-spending-when-you're-done-with-the= m outputs. >=20 >> 3) dust sized htlcs in lightning (https://bitcoin.stackexchange.com/quest= ions/46730/can-you-send-amounts-that-would-typically-be-considered-dust-thro= ugh-the-light ) force c= hannels to operate in a semi-trusted mode which has implications (AFAIU) for= the regulatory classification of channels in various jurisdictions; agnosti= c treatment of fund transfers would simplify this (like getting a 0.01 cent d= ividend check in the mail) >=20 > This is unrelated to the consensus dust limit. This is related to the prac= tical question about the value of claiming an output. Again, the appropriate= way to solve this instead of including spendable dust outputs would be an O= P_RETURN output (though I believe this particular problem is actually better= solved elsewhere in the lightning protocol). >=20 >> 4) thinly divisible colored coin protocols might make use of sats as valu= e markers for transactions. >=20 > These schemes can and should use values which make them economical to spen= d. The whole *point* of the dust limit is to encourage people to use values w= hich make sense economically to "clean up" after they're done with them. If p= eople want to use outputs which they will not spend/"clean up" later, they s= hould be using OP_RETURN. >=20 >> 5) should we ever do confidential transactions we can't prevent it withou= t compromising privacy / allowed transfers >=20 > This is the reason the dust limit is not a *consensus* limit. If and when C= T were to happen we can and would relax the standardness rules around the du= st limit to allow for CT. >=20 >> The main reasons I'm aware of not allow dust creation is that: >> 1) dust is spam >> 2) dust fingerprinting attacks >=20 > 3) The significant costs to every miner and full node operator. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev