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
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
|
Return-Path: <oleganza@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C46354A3
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Apr 2017 00:43:53 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pf0-f176.google.com (mail-pf0-f176.google.com
[209.85.192.176])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 38E7E159
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Apr 2017 00:43:53 +0000 (UTC)
Received: by mail-pf0-f176.google.com with SMTP id s16so21020058pfs.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 12 Apr 2017 17:43:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=from:content-transfer-encoding:mime-version:subject:message-id:date
:to; bh=+NV6MI8tWdJ6QRRVhDvwZhUw/js4QKsVQ+6AooCYNSE=;
b=o9OGdiBVFNaC2Q38hm2bxFHkvy1xCoeN0djUfindH2WEXPQRrM4BXikpfIJD6xf3Bq
od0ItlbnAHUe+7Ncd81it3LUF7Rl4y3FU8VefIPOTF6Opiv0IPwZDAnBlOD1RLGS4ZX4
nwlychC1f07mYbCH6x1X1CXDuA90gRwLsfPFeg/fPNQXsYjKQZScWcYDNNt2ABXNuILF
0oIMCHrTug+EDEc/e0+PkahKH6hfIBBxKPnJkGjDElfFL2eirzjdHnWCWxj1gHthX7EA
G1ydPoSVuBxIe9+ZkYlUH+Z/ljO7GwlskQMu5ph7ZcjtMOEaEB4OBeAh7d/NlWxrDfyP
zRTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:content-transfer-encoding:mime-version
:subject:message-id:date:to;
bh=+NV6MI8tWdJ6QRRVhDvwZhUw/js4QKsVQ+6AooCYNSE=;
b=jU27dNZOWgKvpZZrD7ya102MySnAk+/J7WVqigv68a3IyYt+iARNTzcNQDmKDzoBLC
pQ1c10Jur3uXoIi6+xHsMwCcGoqTZr5EOlFA1KQlK/nvEOz8BtEYoRl1OYUPOwf1TGXs
xjxxICvo2MLPUKrMtiSwwGlnHwPlXOO5dAKmF2Lb9m0fhulhCJdle8PrwM4DNZ9qugUi
ethny0Tk0cbtcOI+4K7Y8zuHQ6I6p08od931yzUO1N88d0DYHy2uTS07xX7to8hx6/NP
eHHMDxpwxXGkAo1ML9m0rr2KdsX9cy2HQkZO6eMyru8al8qoSi+6ICPfDfmKKnknD11J
oSxQ==
X-Gm-Message-State: AN3rC/4z16UT92bvcQ6l8oNqCT27EhSl8ZKWBIcmTLpAjBveZ7Pw4xOX
Dt4Xm889LWDH3XUPY0w=
X-Received: by 10.98.59.9 with SMTP id i9mr521584pfa.50.1492044232416;
Wed, 12 Apr 2017 17:43:52 -0700 (PDT)
Received: from [192.168.1.126] ([52.119.113.96])
by smtp.gmail.com with ESMTPSA id
11sm38571702pgf.28.2017.04.12.17.43.51
for <bitcoin-dev@lists.linuxfoundation.org>
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Wed, 12 Apr 2017 17:43:51 -0700 (PDT)
From: Oleg Andreev <oleganza@gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Message-Id: <6DF303E6-E379-45FD-947B-BB5F938177E5@gmail.com>
Date: Wed, 12 Apr 2017 17:43:50 -0700
To: "bitcoin-dev@lists.linuxfoundation.org"
<bitcoin-dev@lists.linuxfoundation.org>
X-Mailer: Apple Mail (2.3273)
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: [bitcoin-dev] Deploying CT in Bitcoin without extension blocks?
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: Thu, 13 Apr 2017 00:43:53 -0000
(This is a sketch, not a fully-formed proposal, just to kick off the =
discussion.)
Confidential Transactions (by GMaxwell & Poelstra) require a new =
accounting model,=20
new representation of numbers (EC points as Pedersen commitments) and =
range proofs=20
per number. Setting aside performance and bandwidth concerns (3-4Kb per =
output,=20
50x more signature checks), how would we deploy that feature on Bitcoin =
network=20
in the most compatible manner?
I'll try to present a sketch of the proposal. I apologize if this =
discussion already
happened somewhere, although I couldn't find anything on this subject, =
apart from Elements=20
sidechain proposal, of course.
At first glance we could create a new extblock and transaction format, =
add a protocol to
"convert" money into and from such extblock, and commit to that extblock =
from the=20
outer block's coinbase transaction. Unfortunately, this opens gates to a =
flood of
debates such as what should be the block size limit in such block, =
should we=20
take opportunity to fix over 9000 of pet-peeve issues with existing =
transactions
and blocks, should we adjust inflation schedule, insert additional PoW, =
what would
Satoshi say etc. Federated sidechain suffers from the same issues, plus =
adds=20
concerns regarding governance, although it would be more decoupled, =
which is useful.
I tried to look at a possibility to make the change as compatible as =
possible,
sticking confidential values right into the existing transaction =
structure and
see how that would look like. As a nice bonus, confidential transactions =
would have=20
to fit into the hard-coded 1 Mb limit, preserving the drama around it =
:-P
We start with a segwit-enabled script versioning and introduce 2 new =
script versions:
version A has an actual program concatenated with the commitment, while =
version B=20
has only the commitment and allows mimblewimble usage (no signatures, =
non-interactive=20
cut-through etc). Legacy cleartext amount can nicely act as "min value" =
to minimize
the range proof size, and range proofs themselves are provided =
separately in the
segregated witness payload.
Then, we soft fork additional rules:
1. In non-coinbase tx, sum of commitments on inputs must balance with =
sum of commitments
on the outputs plus the cleartext mining fee in the witness.
2. Range proof can be confidential, based on borromean ring signature.
3. Range proof can be non-confidential, consisting of an amount and raw =
blinding factor.
4. Tx witness can have an excess value (cf. MW) and cleartext amount for =
a miner's fee.
5. In coinbase tx, total plaintext reward + commitments must balance =
with subsidy,=20
legacy fees and new fees in the witness.
6. Extra fees in the witness must be signed with the excess value's key.
The confidential transactions use the same UTXO set, can be co-authored =
with plaintext inputs/outputs
using legacy software and maybe even improve scalability by compressing =
on-chain transactions
using mimblewimble cut-through.
The rules above could have been made more complicated with export/import =
logic to allow users
converting their coins to and from confidential ones, but that would =
require
more complex support from miners to respect and merge outputs =
representing "plaintext value bank",
mutate export transactions, which in turn requires introduction of a =
non-malleable TxID
that excludes miner-adjustable export/import outputs.
The rules above have a nice side effect that miners, being the minters =
of confidential coins,=20
can sell them at a premium, which creates an incentive for them to =
actually support
that feature and work on improving performance of rangeproof validation =
(e.g. in GPUs).
Would love to hear comments and criticism of that approach.
Thanks!
Oleg.
|
