From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 1C8CEC000D for ; Thu, 30 Sep 2021 22:07:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id F1E7B61461 for ; Thu, 30 Sep 2021 22:07:34 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=wuille.net Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvHTkPzb16ji for ; Thu, 30 Sep 2021 22:07:33 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from mail-41104.protonmail.ch (mail-41104.protonmail.ch [185.70.41.104]) by smtp3.osuosl.org (Postfix) with ESMTPS id 768A9613FD for ; Thu, 30 Sep 2021 22:07:33 +0000 (UTC) Received: from mail-0201.mail-europe.com (mail-0201.mail-europe.com [51.77.79.158]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by mail-41104.protonmail.ch (Postfix) with ESMTPS id 4HL6mg4Dlvz4x14M for ; Thu, 30 Sep 2021 22:07:31 +0000 (UTC) Authentication-Results: mail-41104.protonmail.ch; dkim=pass (2048-bit key) header.d=wuille.net header.i=@wuille.net header.b="lOh1rT6u" Date: Thu, 30 Sep 2021 22:07:08 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wuille.net; s=protonmail; t=1633039629; bh=hMhSxbuEAPx7XiOv8V2fNwspArKMAmOij5P+Yspq2XI=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=lOh1rT6uI2v1XyifQMO0xfDiKU01b2GfSvStQYA4U2xNCvy3yZlMkUOQYzCwJDaOT +5MYQ69ANQdeE0JyuEl5i7ysBxBUW/R8uvocjGZ+Syi5M4WK5ZA3aCg+eyQciZu4hJ K8Fmz8KuPtnlcp+tiUxHP3IRuDY3Ik2cQid3Oo8aJlxwSFC0BZi+2gF1Jfze/OC1Lr 1ggOs+KVhJ6f4PZYXdNg3NvyktUtrWkEkYX5z/d4YcMANSkkMTjc/LF2ckB9u8Nbnj kT6Cvq0XPXm68s1EUqTRmHZJGvcdErO3MeBfAGKssdJIjDwRxX7/uzKhq2uR6iQIox wsFx+t+DOfeBg== To: Bitcoin Protocol Discussion From: Pieter Wuille Reply-To: Pieter Wuille Message-ID: In-Reply-To: <20210808215101.wuaidu5ww63ajx6h@ganymede> References: <20210808215101.wuaidu5ww63ajx6h@ganymede> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 01 Oct 2021 07:45:03 +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: Thu, 30 Sep 2021 22:07:36 -0000 Jumping in late to this thread. I very much agree with how David Harding presents things, with a few commen= ts inline. =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Sunday, August 8th, 2021 at 5:51 PM, David A. Harding via bitcoin-dev wrote: > > 1. it's not our business what outputs people want to create > > Every additional output added to the UTXO set increases the amount of > work full nodes need to do to validate new transactions. For miners > for whom fast validation of new blocks can significantly affect their > revenue, larger UTXO sets increase their costs and so contributes > towards centralization of mining. > Allowing 0-value or 1-sat outputs minimizes the cost for polluting the > UTXO set during periods of low feerates. > If your stuff is going to slow down my node and possibly reduce my > censorship resistance, how is that not my business? Indeed - UTXO set size is an externality that unfortunately Bitcoin's conse= nsus rules fail to account for. Having a relay policy that avoids at the very least economically irrat= ional behavior makes perfect sense to me. It's also not obvious how consensus rules could deal with this, as you don'= t want consensus rules with hardcoded prices/feerates. There are possibilities with designs like t= ransactions getting a size/weight bonus/penalty, but that's both very hardforky, and hard to ge= t right without introducing bad incentives. > > 2. dust outputs can be used in various authentication/delegation smart > > contracts > > > 3. dust sized htlcs in lightning ( > > https://bitcoin.stackexchange.com/questions/46730/can-you-send-amou= nts-that-would-typically-be-considered-dust-through-the-light) > > force channels to operate in a semi-trusted mode > > > 4. thinly divisible colored coin protocols might make use of sats as v= alue > > markers for transactions. My personal, and possibly controversial, opinion is that colored coin proto= cols have no business being on the Bitcoin chain, possibly beyond committing to an occasional batched state update or so. Both because= there is little benefit for tokens with a trusted issuer already, and because it competes with using Bitcoin for BTC - the to= ken that pays for its security (at least as long as the subsidy doesn't run out). Of course, personal opinions are no reason to dictate what people should or= can use the chain for, but I do think it's reason to voice hesitancy to worsening the system's scalability properties only to be= nefit what I consider misguided use. > > 5. should we ever do confidential transactions we can't prevent it wit= hout > > compromising privacy / allowed transfers > > I'm not an expert, but it seems to me that you can do that with range > proofs. The range proof for >dust doesn't need to become part of the > block chain, it can be relay only. Yeah, range proofs have a non-hidden range; the lower bound can be nonzero,= which could be required as part of a relay policy. Cheers, -- Pieter