Date: Tue, 10 Aug 2021 11:37:37 +0000
To: Billy Tetrud <billy.tetrud@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <JaAZipQkFFuBwE0ZQoFpmBe3K2WAOEUSNiGqQTx8ak5FqCPXSOZzjvjFAhaUX9e5i-TLnT8LmdzrUsLXi_RE3R3WsFEhybXiCJrg2YEyHdM=@protonmail.com>
In-Reply-To: <CAGpPWDYsRSv0Teiq5JD1iHJnAbRdCmr+e6UGvV5JDpoXL-7M0w@mail.gmail.com>
References: <CAD5xwhjFBjvkMKev_6HFRuRGcZUi7WjO5d963GNXWN4n-06Pqg@mail.gmail.com>
 <CALZpt+F9FScaLsvXUozdBL4Ss8r71-gtUS_Fh9i53cK_rSGBeA@mail.gmail.com>
 <CAGpPWDZn6dcuEJXRjUP4VYvJbL9u4mmVoS9xTVzBrGWOM5CeZw@mail.gmail.com>
 <CAD5xwhi_Sf1NRPBSAcWWFiAjyFsnmWbtowBF96j=EM4NXxfOKw@mail.gmail.com>
 <CAGpPWDYsRSv0Teiq5JD1iHJnAbRdCmr+e6UGvV5JDpoXL-7M0w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: lightning-dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit
Precedence: list

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 `<saltpoint=
> <0> OP_EQUAL OP_NOT` with `<saltpoint>` 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