* Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit Message-ID:
@ 2021-08-10 21:03 John Tromp
0 siblings, 0 replies; only message in thread
From: John Tromp @ 2021-08-10 21:03 UTC (permalink / raw)
To: Bitcoin Protocol Discussion, ZmnSCPxj
> Alternately, one possible softforkable design would be for Bitcoin to maintain 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 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 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 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 `<saltpoint> <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 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 limit 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 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.
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
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2021-08-10 21:03 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-10 21:03 [bitcoin-dev] [Lightning-dev] Removing the Dust Limit Message-ID: John Tromp
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox