1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id F153C927
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 2 Jan 2019 13:40:05 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch
[185.70.40.133])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0606327B
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 2 Jan 2019 13:40:04 +0000 (UTC)
Date: Wed, 02 Jan 2019 13:39:57 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1546436402;
bh=gz00p0izGEt/AAs8Zav0XOQRW+mklLBtLq9hUk+Zc4o=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=hCGIA8uD8ttyfuVRhw3gDVoSdEihFVfZtiizgIthA/ISSWE0/fOHx7C0YO7Mr4qD3
kAicV6lRQC2RqSCyGZq2DV5pIxeRfbgvCsaL0kYWirYQ2bSaB24lGCeOepDJtz97d8
WDOizlR39qhmSvbFY1NFHCMn91Tck4pt6o/exu8E=
To: "Kenshiro \\[\\]" <tensiam@hotmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <knV3VcCBvchmrBDvcYs8I2mImVR7_fbYmtWPY1GOxHkhKlYsMjFCReM1d3_me13YekyI4NZYRovD8s103Yj6wLWBMir6SOBYlrCdS1tLqgo=@protonmail.com>
In-Reply-To: <DB6PR10MB1832A1A6EB2628CAB0035192A6B00@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
References: <3VIFGj5yxFpKlSgjMAlPCuTJOSzYkZI2l7tMwtQq4LStjiXgfS7A61jdZ5ZoyalJmjo71EQtNC_F06JgpQ1m046fWbq_6Nhe3BGkMOU-17I=@protonmail.com>
<DB6PR10MB1832A1A6EB2628CAB0035192A6B00@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,
RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 02 Jan 2019 16:20:26 +0000
Cc: SomberNight <somber.night@protonmail.com>
Subject: Re: [bitcoin-dev] Create a BIP to implement Confidential
Transactions in Bitcoin Core
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Jan 2019 13:40:06 -0000
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 wil=
l
> 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; exi=
sting pre-CT coins remain in the public part.
When moving from public to CT, you send to some special "lockbox address" o=
n 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 yo=
ur UTXOs have what value.
Then to move from CT to public, you can claim any of the lockboxes on the p=
ublic 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 t=
otal and your own CT UTXOs into another lockbox UTXO.
This is essentially the same concept as sidechains, but with the "side" cha=
in 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 fi=
rst owner of a quantum computer can claim all the lockboxes, but at least t=
he 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 s=
upply is protected, which I believe is the most important property.
The weakness in this scheme is that there is incentive not to put your mone=
y 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 MimbleWimb=
le transaction structure will need to be stored by the monitors of the bloc=
kchain 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 th=
ey recorded themselves, and MimbleWimble allows third-party trustless CoinJ=
oin 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
|
