MIME-Version: 1.0
From: John Tromp <john.tromp@gmail.com>
Date: Tue, 10 Aug 2021 23:03:11 +0200
Message-ID: <CAOU__fx0ajVfuEyoYCOkf8nZPOkbuYDctTfuzhCDdoU=jcA0Tg@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, 
 ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit
	Message-ID:
Precedence: list

> Alternately, one possible softforkable design would be for Bitcoin to mai=
ntain a non-CT block (the current scheme) and a separately-committed CT blo=
ck (i.e. similar to how SegWit has a "separate" "block"/Merkle tree that in=
cludes 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 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 rem=
oving 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 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 `<saltpoi=
nt> <0> OP_EQUAL OP_NOT` with `<saltpoint>` being what is used in 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 o=
n 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 wil=
l have a known upper limit, that cannot be higher than the supply limit of =
the legacy non-CT block, i.e. 21 million BTC.
> At the same time, *individual* CT-block TXOs cannot have their values kno=
wn; 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 n=
ot *all* Bitcoin coins, as there would not be enough "burn" TXOs on the leg=
acy non-CT blockchain.
>
> This may be sufficient for practical privacy.

This is pretty much the Mimble Wimble Extension Block (MWEB) design
for Litecoin, as described at
https://vaultoro.com/what-is-mweb-on-litecoin/

True to the Harry Potter background theme of Mimblewimble, the regular
Litecoin transaction responsible for pegging into and out of the
extension block is call the Hogwarts Express (hogex).

If all goes well, it may activate as early as the end of this year...

regards,
-John