* [bitcoin-dev] Create a BIP to implement Confidential Transactions in Bitcoin Core
@ 2018-12-27 20:15 Kenshiro []
0 siblings, 0 replies; 4+ messages in thread
From: Kenshiro [] @ 2018-12-27 20:15 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 550 bytes --]
Hi,
I think Confidential Transactions (CT) are a great idea to provide enough privacy for normal users (hidden amounts) and fungibility.
I would like to request the creation of a BIP to implement CT in Bitcoin Core. I read that CT are already implemented in Grin and Monero so it looks that CT are enough mature to be implemented in Bitcoin.
If the CT transaction size is 3x the size of a normal transaction the block size could be increased by 3x too, or just keep the current block size and make CT transactions optional.
Thank you!
[-- Attachment #2: Type: text/html, Size: 1512 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] Create a BIP to implement Confidential Transactions in Bitcoin Core
2018-12-29 11:56 ` Kenshiro []
@ 2019-01-02 13:39 ` ZmnSCPxj
0 siblings, 0 replies; 4+ messages in thread
From: ZmnSCPxj @ 2019-01-02 13:39 UTC (permalink / raw)
To: Kenshiro \[\], Bitcoin Protocol Discussion; +Cc: SomberNight
Good morning SomberNight,
> "Bulletproofs ... are computationally binding. An adversary that could
> break the discrete logarithm assumption could generate acceptable range
> proofs for a value outside the correct range. ... An adversary that can
> break the binding property of the commitment scheme or the soundness of
> the proof system can generate coins out of thin air and thus create
> uncontrolled but undetectable inflation rendering the currency useless"
>
> I don't have the domain knowledge to debate whether quantum computers will
> ever exist but AFAICT their emergence would easily kill a currency that
> uses these kind of range proofs for confidential transactions.
This can be mitigated by splitting the blockchain into a public part and a confidential-transactions part (i.e. extension block).
This may be necessary for softforking of CT onto the blockchain anyway; existing pre-CT coins remain in the public part.
When moving from public to CT, you send to some special "lockbox address" on the public part, then they will now be put in a coinbase-like transaction on the CT part.
You then do some mixing and splitting in the CT part to obscure which of your UTXOs have what value.
Then to move from CT to public, you can claim any of the lockboxes on the public part, by revealing the values of your CT UTXOs (and destroying them) and showing that they are equal or less than the lockboxes you are claiming on the public part, and putting back any remainder between the lockboxes total and your own CT UTXOs into another lockbox UTXO.
This is essentially the same concept as sidechains, but with the "side" chain here being part of the consensus, and thus an extension block instead of a true sidechain.
In this way, the amount of total money in the CT part is the sum of all the lockboxes.
In case of a cryptographic break in the CT rangeproof protocol, then the first owner of a quantum computer can claim all the lockboxes, but at least the damage is bounded to only those UTXOs in the CT part.
UTXOs in the public part retain their money.
In addition, since creation of new coins remains in the public part, coin supply is protected, which I believe is the most important property.
The weakness in this scheme is that there is incentive not to put your money for long in the CT part.
Note that CT only hides transaction values.
Structure of transactions from payers to payees remains visible onchain.
I would suggest rather to use MimbleWimble, since at least under MimbleWimble transaction structure will need to be stored by the monitors of the blockchain rather than by the blockchain itself, which would help reduce their ability to see into historical data (they would only be able to see data they recorded themselves, and MimbleWimble allows third-party trustless CoinJoin so they might not even record accurate transaction structure).
Drawback is lack of SCRIPT, but Scriptless Script should be sufficient for e.g. LN.
Regards,
ZmnSCPxj
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] Create a BIP to implement Confidential Transactions in Bitcoin Core
2018-12-28 21:41 SomberNight
@ 2018-12-29 11:56 ` Kenshiro []
2019-01-02 13:39 ` ZmnSCPxj
0 siblings, 1 reply; 4+ messages in thread
From: Kenshiro [] @ 2018-12-29 11:56 UTC (permalink / raw)
To: bitcoin-dev, SomberNight
[-- Attachment #1: Type: text/plain, Size: 1842 bytes --]
I understand, thank you! :)
From: SomberNight <somber.night@protonmail•com>
Sent: Friday, December 28, 2018 22:41
To: bitcoin-dev@lists•linuxfoundation.org; tensiam@hotmail•com
Subject: [bitcoin-dev] Create a BIP to implement Confidential Transactions in Bitcoin Core
Hi Kenshiro,
That is not how the BIP process works. Instead of requesting the creation
of a BIP, you just create one. :)
Re CT in Bitcoin, I have my doubts whether you can get consensus for that.
From section 4.6 of the Bulletproofs paper [0]:
"Bulletproofs ... are computationally binding. An adversary that could
break the discrete logarithm assumption could generate acceptable range
proofs for a value outside the correct range. ... An adversary that can
break the binding property of the commitment scheme or the soundness of
the proof system can generate coins out of thin air and thus create
uncontrolled but undetectable inflation rendering the currency useless"
I don't have the domain knowledge to debate whether quantum computers will
ever exist but AFAICT their emergence would easily kill a currency that
uses these kind of range proofs for confidential transactions.
[0]: https://eprint.iacr.org/2017/1066.pdf
> From: "Kenshiro []" tensiam@hotmail•com
>
> Hi,
>
> I think Confidential Transactions (CT) are a great idea to provide enough privacy for normal users (hidden amounts) and fungibility.
>
> I would like to request the creation of a BIP to implement CT in Bitcoin Core. I read that CT are already implemented in Grin and Monero so it looks that CT are enough mature to be implemented in Bitcoin.
>
> If the CT transaction size is 3x the size of a normal transaction the block size could be increased by 3x too, or just keep the current block size and make CT transactions optional.
>
> Thank you!
[-- Attachment #2: Type: text/html, Size: 3027 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* [bitcoin-dev] Create a BIP to implement Confidential Transactions in Bitcoin Core
@ 2018-12-28 21:41 SomberNight
2018-12-29 11:56 ` Kenshiro []
0 siblings, 1 reply; 4+ messages in thread
From: SomberNight @ 2018-12-28 21:41 UTC (permalink / raw)
To: bitcoin-dev, tensiam
Hi Kenshiro,
That is not how the BIP process works. Instead of requesting the creation
of a BIP, you just create one. :)
Re CT in Bitcoin, I have my doubts whether you can get consensus for that.
From section 4.6 of the Bulletproofs paper [0]:
"Bulletproofs ... are computationally binding. An adversary that could
break the discrete logarithm assumption could generate acceptable range
proofs for a value outside the correct range. ... An adversary that can
break the binding property of the commitment scheme or the soundness of
the proof system can generate coins out of thin air and thus create
uncontrolled but undetectable inflation rendering the currency useless"
I don't have the domain knowledge to debate whether quantum computers will
ever exist but AFAICT their emergence would easily kill a currency that
uses these kind of range proofs for confidential transactions.
[0]: https://eprint.iacr.org/2017/1066.pdf
> From: "Kenshiro []" tensiam@hotmail•com
>
> Hi,
>
> I think Confidential Transactions (CT) are a great idea to provide enough privacy for normal users (hidden amounts) and fungibility.
>
> I would like to request the creation of a BIP to implement CT in Bitcoin Core. I read that CT are already implemented in Grin and Monero so it looks that CT are enough mature to be implemented in Bitcoin.
>
> If the CT transaction size is 3x the size of a normal transaction the block size could be increased by 3x too, or just keep the current block size and make CT transactions optional.
>
> Thank you!
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-01-02 13:40 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-12-27 20:15 [bitcoin-dev] Create a BIP to implement Confidential Transactions in Bitcoin Core Kenshiro []
2018-12-28 21:41 SomberNight
2018-12-29 11:56 ` Kenshiro []
2019-01-02 13:39 ` ZmnSCPxj
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox