Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 8CC99C000E; Tue, 10 Aug 2021 18:39:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 68A1A81DCA; Tue, 10 Aug 2021 18:39:55 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=litecoin-org.20150623.gappssmtp.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 nqrw58oeCdPC; Tue, 10 Aug 2021 18:39:51 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) by smtp1.osuosl.org (Postfix) with ESMTPS id 50E4E81D34; Tue, 10 Aug 2021 18:39:51 +0000 (UTC) Received: by mail-ot1-x32e.google.com with SMTP id d10-20020a9d4f0a0000b02904f51c5004e3so190993otl.9; Tue, 10 Aug 2021 11:39:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litecoin-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xUvVXKVBYt/M5Y9Ry1oYUGNDRziAI8XsgMz6YWyamzk=; b=jBMcoIW/6MbD4z2KAAOqOnxuh5u12VtplyHeEkuGD/YIsFQ8UkEfyQNSFX71skmTQh oCNKeoNPHw716/Xu1oTBUSxYjyvF/MReIPPxK+xhCUzDU0wBfWLeiq7HoEPfocHW3duS n3VbXiMraE5Ak3jZ6qAkw+fN53mqV+w+YPe63znywtQVlKQzdqrzdKenlQL//WVSZ1/7 qUnjTPEkmWnHamcdOmSTf6P9OO3YBt6DXBZPpnhGkaykbKbgwwI7beWCwdnR0r7Iy/Hd fLufBT3Cs4tQD0+Nvdybzn2WhfHF34nNRqpk5gunTLy0foTo1OvBTpiTudYPChf79Zn6 DjkA== 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=xUvVXKVBYt/M5Y9Ry1oYUGNDRziAI8XsgMz6YWyamzk=; b=Udm259mnjCETDLy7e/qMNjzpBiioT+Gd98z96u5WKFcCtgC7jiT+4l+0z2WtXKuz8N 5WrISli8j+TMH5FVeC8rfgEuED3D8HSzv9DxwUjyPmFg4w3ALgqxAXd1ryTqptIAiIDL Xb0fXD6+U4bMLJrdIYc9oLpV8r3xlKkY5etl5c2faCS8D4nY1bIKIKX8idxAiYVVdiY4 RdJOuA/yed37FPmqzoxWS/Gv6LTOLHQNXDqB+NrtU8us7nhcZOJUivPwveLPMYiBNbXk /GoNkGZY9GJTCyhnV44VRqfe12jiMvlSI66TB4SGtZbM14+T1y614s+Nu+wnR7OnAhof KvSw== X-Gm-Message-State: AOAM533j+tfbfVCKfEt2FxA4Yrb9tQcZ9VEsNCR/eeDkrs+JYUQuNJW5 9a9Vx1HIwvab043DhQIfkUp/l+3Kb0EFhFEH9is= X-Google-Smtp-Source: ABdhPJziGljWkOHmWHPeNQeLtnX/mgvlDd5FfHwDQUvc5985eNvZ2wGCGRESb14u3imMCm1dbGg3y/QUFWkNvNq6O2E= X-Received: by 2002:a05:6830:2102:: with SMTP id i2mr8320477otc.51.1628620790193; Tue, 10 Aug 2021 11:39:50 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Charlie Lee Date: Tue, 10 Aug 2021 12:39:39 -0600 Message-ID: To: ZmnSCPxj , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000acaff405c938d359" X-Mailman-Approved-At: Wed, 11 Aug 2021 20:26:36 +0000 Cc: lightning-dev , Billy Tetrud 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 18:39:55 -0000 --000000000000acaff405c938d359 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ZmnSCPxj, what you are describing is pretty much what Litecoin is doing with MWEB. Basically MimbleWimble (which has CT) with extension blocks. If you are interested: https://github.com/litecoin-project/lips/blob/master/lip-0002.mediawiki https://github.com/litecoin-project/lips/blob/master/lip-0003.mediawiki Sorry to derail the conversation with non-Bitcoin stuff. =F0=9F=98=80 - Charlie On Tue, Aug 10, 2021 at 5:38 AM ZmnSCPxj via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Good morning Billy, et al., > > > For sure, CT can be done with computational soundness. The advantage of > unhidden amounts (as with current bitcoin) is that you get unconditional > soundness. > > My understanding is that it should be possible to have unconditional > soundness with the use of El-Gamal commitment scheme, am I wrong? > > Alternately, one possible softforkable design would be for Bitcoin to > maintain a non-CT block (the current scheme) and a separately-committed C= T > block (i.e. similar to how SegWit has a "separate" "block"/Merkle tree th= at > includes witnesses). > When transferring funds from the legacy non-CT block, on the legacy block > you put it into a "burn" transaction that magically causes the same amoun= t > to 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 > removing from the CT block is exactly the same value as the "burn" TXO yo= u > are now spending. > > (for additional privacy, the values of the "burn" TXOs might be made into > some fixed single allowed value, so that transfers passing through the CT > portion 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 i= n > the CT to cover the value, and knowledge of the scalar behind this point > would allow the 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 > outputs 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 limi= t > of the 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 should be sufficient privacy if there are a large enough number of > users of the CT block. > > This allows the CT block to use an unconditional privacy and computationa= l > soundness scheme, and if somehow the computational soundness is broken th= en > the first one to break it would be able to steal all the CT coins, but no= t > *all* Bitcoin coins, as there would not be enough "burn" TXOs on the lega= cy > 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 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000acaff405c938d359 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
ZmnSCPxj, what you are describing is pretty much what Lite= coin is doing with MWEB. Basically MimbleWimble (which has CT) with extensi= on blocks. If you are interested:

Sorry to derail the conversation with non-Bitcoin= stuff.=C2=A0=F0=9F=98=80

- Charlie


On Tue, Aug 10, 2021 at 5:38 A= M ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
=
Good morning Billy, et al= .,

> For sure, CT can be done with computational soundness. The advantage o= f unhidden amounts (as with current bitcoin) is that you get unconditional = soundness.

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"/M= erkle tree that includes 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 sam= e amount to 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 removing from the CT block is exactly the same value as the "burn= " TXO you are now spending.

(for additional privacy, the values of the "burn" TXOs might be m= ade into some fixed single allowed value, so that transfers passing through= the CT portion would have fewer identifying features)

The "burn" TXOs would be some trivial anyone-can-spend, such as `= <saltpoint> <0> OP_EQUAL OP_NOT` with `<saltpoint>` being= what is used in the CT to cover the value, and knowledge of the scalar beh= ind this point would allow the CT output to be spent (assuming something ve= ry much like MimbleWimble is used; otherwise it could be the hash of some P= 2WSH or similar analogue on the CT side).

Basically, this is "CT as a 'sidechainlike' that every fullnod= e 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 l= imit of the 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 legacy 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
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000acaff405c938d359--