From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 19BF7C000E; Tue, 10 Aug 2021 11:37:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id EE426606E8; Tue, 10 Aug 2021 11:37:53 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 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, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.com 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 Gt_EeKbULixb; Tue, 10 Aug 2021 11:37:49 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-4318.protonmail.ch (mail-4318.protonmail.ch [185.70.43.18]) by smtp3.osuosl.org (Postfix) with ESMTPS id 73655606A7; Tue, 10 Aug 2021 11:37:49 +0000 (UTC) Date: Tue, 10 Aug 2021 11:37:37 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1628595466; bh=mOoUYwmWt2AkhmYsSX7oHc48G8Uph+qRYY1aUixgi8w=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=MZ3AzS+fjQszuE5vPs4aH3OjXdtpTVrChNXzBTXX0BrbVxxKfp0vqld5lCnXfIGPj Aj3gqHMdHpcgKUontRlNX2NrUxUt0AlhOZFn9pGVcVuHHBkbpNbNHpvgv/njk13/Bj sp60Z1HinaP3kTrwXgx3CuRI0vSmm5EUPTqTOFjg= To: Billy Tetrud , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Tue, 10 Aug 2021 11:37:54 -0000 Good morning Billy, et al., > For sure, CT can be done with computational soundness. The advantage of u= nhidden amounts (as with current bitcoin) is that you get unconditional sou= ndness. My understanding is that it should be possible to have unconditional soundn= ess with the use of El-Gamal commitment scheme, am I wrong? Alternately, one possible softforkable design would be for Bitcoin to maint= ain a non-CT block (the current scheme) and a separately-committed CT block= (i.e. similar to how SegWit has a "separate" "block"/Merkle tree that incl= udes witnesses). When transferring funds from the legacy non-CT block, on the legacy block y= ou put it into a "burn" transaction that magically causes the same amount t= o be created (with a trivial/publicly known salt) in the CT block. Then to move from the CT block back to legacy non-CT you would match one of= those "burn" TXOs and spend it, with a proof that the amount you are remov= ing from the CT block is exactly the same value as the "burn" TXO you are n= ow spending. (for additional privacy, the values of the "burn" TXOs might be made into s= ome fixed single allowed value, so that transfers passing through the CT po= rtion would have fewer identifying features) The "burn" TXOs would be some trivial anyone-can-spend, such as ` <0> OP_EQUAL OP_NOT` with `` being what is used in the CT to c= over the value, and knowledge of the scalar behind this point would allow t= he CT output to be spent (assuming something very much like MimbleWimble is= used; otherwise it could be the hash of some P2WSH or similar analogue on = the CT side). Basically, this is "CT as a 'sidechainlike' that every fullnode runs". In the legacy non-CT block, the total amount of funds that are in all CT ou= tputs is known (it would be the sum total of all the "burn" TXOs) and will = have a known upper limit, that cannot be higher than the supply limit of th= e legacy non-CT block, i.e. 21 million BTC. At the same time, *individual* CT-block TXOs cannot have their values known= ; what is learnable is only how many BTC are in all CT block TXOs, which sh= ould be sufficient privacy if there are a large enough number of users of t= he CT block. This allows the CT block to use an unconditional privacy and computational = soundness scheme, and if somehow the computational soundness is broken then= the first one to break it would be able to steal all the CT coins, but not= *all* Bitcoin coins, as there would not be enough "burn" TXOs on the legac= y non-CT blockchain. This may be sufficient for practical privacy. On the other hand, I think the dust limit still makes sense to keep for now= , though. Regards, ZmnSCPxj