<unnamed>

Public Key

npub1d5urs8th2ucpnulvsjee27mv2j0qzd0m6pjra9lkf8l3semz64vs7y8svt

Profile Code

nprofile1qqsx6wpcr4m4wvqe70kgfvu40dk9f8spxhaaqep7jlmynlccva3d2kgpzpmhxue69uhkummnw3ezuamfdejsz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcpp4mhxue69uhkummn9ekx7mqpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhghd8fzg

Publishing to

Last Notes

2023-06-09 12:40:49 UTC

- reply

📅 Original date posted:2021-08-10
📝 Original message:
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. 😀
- Charlie
On Tue, Aug 10, 2021 at 5:38 AM ZmnSCPxj via bitcoin-dev <
bitcoin-dev at 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 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.
>
>
> 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210810/2943c106/attachment.html>