summaryrefslogtreecommitdiff
path: root/1e/b6ff0e985f217a62514213fd16f0a55eebf782
blob: 6e3116067d6643cb8254b53d5732d5e281e8961f (plain)
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
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
Return-Path: <keatonatron@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 6E590279
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  8 Aug 2016 21:41:41 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f174.google.com (mail-qk0-f174.google.com
	[209.85.220.174])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8864BAF
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  8 Aug 2016 21:41:39 +0000 (UTC)
Received: by mail-qk0-f174.google.com with SMTP id t7so59538345qkh.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 08 Aug 2016 14:41:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to; 
	bh=Q70b58tHLcfr4/xIjQRiGbuf2637SaQn0RcasLiSEUI=;
	b=kuKNIZPLXvhi/IaTUtqbob0+VT3fJRDkIM2tR9jI1Qdk24Eq5Ok//gJyWGkwvPxPIn
	92bNocgAa55Nz0Ps6gShjeTMSfjkyOX2UIC55sDIcgdHw4TKLzk5P3lqYJ/0DAfwERNa
	QSQ8ACQqBazLWELiTa/xYfSCWLjKAsj63UdyzMtYelFN/eOCidnCG8HR2MK31MtDWnEZ
	txlzPdBZRznR2t0pKUm4G4xqkNVjauGnM9PMR7Le6A0iDxtEPls3FOKPQnlCbITno4JM
	T9F1Y6dnKMIMDB36WSgWubpi2QEwdsHzU5jhxPQfXj4VhuLpi7nMS5QeFTMvcraqi55p
	f6Pg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:references:in-reply-to:from:date
	:message-id:subject:to;
	bh=Q70b58tHLcfr4/xIjQRiGbuf2637SaQn0RcasLiSEUI=;
	b=AiYRAGueg0dzzdu0GpVFR7rHNcAG6KqTfnorxCtdeK0JJmPsE1XM1F98eYrJj39Pna
	lZIn4VvOkMW4FdtT2bYQzDQi28taA+rKC+9cszMXciT5O7lGAWvbPMix945jKIkLg8DT
	Z1zsb0TgOg37jyUmxhP+jACZuIpkiu2X+RDBAxNjwyO3QJt+6bwvA8YAJ6epOcEcCU++
	SBcRJR02RS0os/dAa2q1rvi6No7xY/ieFjJfnxzxppTiE2XGm0Hbt1S2CGVWnZ/GAFRc
	/oyEms3ScQG3Sl25qssLXflVKqn20dmonN7ktsDWQ6oJKyPSaS6LFxl3Dsshb4v5c+kl
	7yHw==
X-Gm-Message-State: AEkoousxvL3MPOICHu84BM1JetziKbqI+149RwHg+rxlXvwEiRD9sAjFsqUG/jL9ksfvgE7hzjoH/xMOofwjcw==
X-Received: by 10.55.45.1 with SMTP id t1mr7352721qkh.182.1470692498719; Mon,
	08 Aug 2016 14:41:38 -0700 (PDT)
MIME-Version: 1.0
References: <CAL3p6zpADtYFQnQUr3Efk6V59+K+bB3tPQQMGT9weiafU=43zA@mail.gmail.com>
	<20160808154707.GB2196@banane.informatik.uni-ulm.de>
	<CAL3p6zo1xBEu90MDHSK4TNX0DL2QXxq5vC48a2cFnX0JCD=RvQ@mail.gmail.com>
In-Reply-To: <CAL3p6zo1xBEu90MDHSK4TNX0DL2QXxq5vC48a2cFnX0JCD=RvQ@mail.gmail.com>
From: James MacWhyte <macwhyte@gmail.com>
Date: Mon, 08 Aug 2016 21:41:27 +0000
Message-ID: <CAH+Axy6yJ3WotKjsMjo3o23V5Du1nniu8Bzd3gxYX5OuqeB6gw@mail.gmail.com>
To: tony.991@gmail.com, Tony Churyumoff <tony991@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, 
	Henning Kopp <henning.kopp@uni-ulm.de>
Content-Type: multipart/alternative; boundary=001a114f42dcf5ca45053996472c
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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
Subject: Re: [bitcoin-dev] Hiding entire content of on-chain transactions
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: Mon, 08 Aug 2016 21:41:41 -0000

--001a114f42dcf5ca45053996472c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Wouldn't you lose the ability to assume transactions in the blockchain are
verified as valid, since miners can't see the details of what is being
spent and how? I feel like this ability is bitcoin's greatest asset, and by
removing it you're creating an altcoin different enough to not be connected
to/supported by the main bitcoin project.

On Mon, Aug 8, 2016, 09:13 Tony Churyumoff via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Henning,
>
> 1. The fees are paid by the enclosing BTC transaction.
> 2. The hash is encoded into an OP_RETURN.
>
> > Regarding the blinding factor, I think you could just use HMAC.
> How exactly?
>
> Tony
>
>
> 2016-08-08 18:47 GMT+03:00 Henning Kopp <henning.kopp@uni-ulm.de>:
>
>> Hi Tony,
>>
>> I see some issues in your protocol.
>>
>> 1. How are mining fees handled?
>>
>> 2. Assume Alice sends Bob some Coins together with their history and
>> Bob checks that the history is correct. How does the hash of the txout
>> find its way into the blockchain?
>>
>> Regarding the blinding factor, I think you could just use HMAC.
>>
>> All the best
>> Henning
>>
>>
>> On Mon, Aug 08, 2016 at 06:30:21PM +0300, Tony Churyumoff via bitcoin-de=
v
>> wrote:
>> > This is a proposal about hiding the entire content of bitcoin
>> > transactions.  It goes farther than CoinJoin and ring signatures, whic=
h
>> > only obfuscate the transaction graph, and Confidential Transactions,
>> which
>> > only hide the amounts.
>> >
>> > The central idea of the proposed design is to hide the entire inputs a=
nd
>> > outputs, and publish only the hash of inputs and outputs in the
>> > blockchain.  The hash can be published as OP_RETURN.  The plaintext of
>> > inputs and outputs is sent directly to the payee via a private message=
,
>> and
>> > never goes into the blockchain.  The payee then calculates the hash an=
d
>> > looks it up in the blockchain to verify that the hash was indeed
>> published
>> > by the payer.
>> >
>> > Since the plaintext of the transaction is not published to the public
>> > blockchain, all validation work has to be done only by the user who
>> > receives the payment.
>> >
>> > To protect against double-spends, the payer also has to publish anothe=
r
>> > hash, which is the hash of the output being spent.  We=E2=80=99ll call=
 this
>> hash *spend
>> > proof*.  Since the spend proof depends solely on the output being spen=
t,
>> > any attempt to spend the same output again will produce exactly the sa=
me
>> > spend proof, and the payee will be able to see that, and will reject t=
he
>> > payment.  If there are several outputs consumed by the same transactio=
n,
>> > the payer has to publish several spend proofs.
>> >
>> > To prove that the outputs being spent are valid, the payer also has to
>> send
>> > the plaintexts of the earlier transaction(s) that produced them, then
>> the
>> > plaintexts of even earlier transactions that produced the outputs spen=
t
>> in
>> > those transactions, and so on, up until the issue (similar to coinbase=
)
>> > transactions that created the initial private coins.  Each new owner o=
f
>> the
>> > coin will have to store its entire history, and when he spends the
>> coin, he
>> > forwards the entire history to the next owner and extends it with his
>> own
>> > transaction.
>> >
>> > If we apply the existing bitcoin design that allows multiple inputs an=
d
>> > multiple outputs per transaction, the history of ownership transfers
>> would
>> > grow exponentially.  Indeed, if we take any regular bitcoin output and
>> try
>> > to track its history back to coinbase, our history will branch every
>> time
>> > we see a transaction that has more than one input (which is not
>> uncommon).
>> > After such a transaction (remember, we are traveling back in time),
>> we=E2=80=99ll
>> > have to track two or more histories, for each respective input.  Those
>> > histories will branch again, and the total number of history entries
>> grows
>> > exponentially.  For example, if every transaction had exactly two
>> inputs,
>> > the size of history would grow as 2^N where N is the number of steps
>> back
>> > in history.
>> >
>> > To avoid such rapid growth of ownership history (which is not only
>> > inconvenient to move, but also exposes too much private information
>> about
>> > previous owners of all the contributing coins), we will require each
>> > private transaction to have exactly one input (i.e. to consume exactly
>> one
>> > previous output).  This means that when we track a coin=E2=80=99s hist=
ory back
>> in
>> > time, it will no longer branch.  It will grow linearly with the number
>> of
>> > transfers of ownership.  If a user wants to combine several inputs, he
>> will
>> > have to send them as separate private transactions (technically, sever=
al
>> > OP_RETURNs, which can be included in a single regular bitcoin
>> transaction).
>> >
>> > Thus, we are now forbidding any coin merges but still allowing coin
>> > splits.  To avoid ultimate splitting into the dust, we will also requi=
re
>> > that all private coins be issued in one of a small number of
>> > denominations.  Only integer number of =E2=80=9Cbanknotes=E2=80=9D can=
 be transferred,
>> the
>> > input and output amounts must therefore be divisible by the
>> denomination.
>> > For example, an input of amount 700, denomination 100, can be split in=
to
>> > outputs 400 and 300, but not into 450 and 250.  To send a payment, the
>> > payer has to pick the unspent outputs of the highest denomination firs=
t,
>> > then the second highest, and so on, like we already do when we pay in
>> cash.
>> >
>> > With fixed denominations and one input per transaction, coin histories
>> > still grow, but only linearly, which should not be a concern in regard
>> to
>> > scalability given that all relevant computing resources still grow
>> > exponentially.  The histories need to be stored only by the current
>> owner
>> > of the coin, not every bitcoin node.  This is a fairer allocation of
>> > costs.  Regarding privacy, coin histories do expose private transactio=
ns
>> > (or rather parts thereof, since a typical payment will likely consist =
of
>> > several transactions due to one-input-per-transaction rule) of past co=
in
>> > owners to the future ones, and that exposure grows linearly with time,
>> but
>> > it is still much much better than having every transaction immediately
>> on
>> > the public blockchain.  Also, the value of this information for
>> potential
>> > adversaries arguably decreases with time.
>> >
>> > There is one technical nuance that I omitted above to avoid distractio=
n.
>> >  Unlike regular bitcoin transactions, every output in a private paymen=
t
>> > must also include a blinding factor, which is just a random string.
>> When
>> > the output is spent, the corresponding spend proof will therefore
>> depend on
>> > this blinding factor (remember that spend proof is just a hash of the
>> > output).  Without a blinding factor, it would be feasible to pre-image
>> the
>> > spend proof and reveal the output being spent as the search space of a=
ll
>> > possible outputs is rather small.
>> >
>> > To issue the new private coin, one can burn regular BTC by sending it =
to
>> > one of several unspendable bitcoin addresses, one address per
>> denomination.
>> >  Burning BTC would entitle one to an equal amount of the new private
>> coin,
>> > let=E2=80=99s call it *black bitcoin*, or *BBC*.
>> >
>> > Then BBC would be transferred from user to user by:
>> > 1. creating a private transaction, which consists of one input and
>> several
>> > outputs;
>> > 2. storing the hash of the transaction and the spend proof of the
>> consumed
>> > output into the blockchain in an OP_RETURN (the sender pays the
>> > corresponding fees in regular BTC)
>> > 3. sending the transaction, together with the history leading to its
>> input,
>> > directly to the payee over a private communication channel.  The first
>> > entry of the history must be a bitcoin transaction that burned BTC to
>> issue
>> > an equal amount of BCC.
>> >
>> > To verify the payment, the payee:
>> > 1. makes sure that the amount of the input matches the sum of outputs,
>> and
>> > all are divisible by the denomination
>> > 2. calculates the hash of the private transaction
>> > 3. looks up an OP_RETURN that includes this hash and is signed by the
>> > payee.  If there is more than one, the one that comes in the earlier
>> block
>> > prevails.
>> > 4. calculates the spend proof and makes sure that it is included in th=
e
>> > same OP_RETURN
>> > 5. makes sure the same spend proof is not included anywhere in the sam=
e
>> or
>> > earlier blocks (that is, the coin was not spent before).  Only
>> transactions
>> > by the same author are searched.
>> > 6. repeats the same steps for every entry in the history, except the
>> first
>> > entry, which should be a valid burning transaction.
>> >
>> > To facilitate exchange of private transaction data, the bitcoin networ=
k
>> > protocol can be extended with a new message type.  Unfortunately, it
>> lacks
>> > encryption, hence private payments are really private only when bitcoi=
n
>> is
>> > used over tor.
>> >
>> > There are a few limitations that ought to be mentioned:
>> > 1. After user A sends a private payment to user B, user A will know wh=
at
>> > the spend proof is going to be when B decides to spend the coin.
>> >  Therefore, A will know when the coin was spent by B, but nothing more=
.
>> >  Neither the new owner of the coin, nor its future movements will be
>> known
>> > to A.
>> > 2. Over time, larger outputs will likely be split into many smaller
>> > outputs, whose amounts are not much greater than their denominations.
>> > You=E2=80=99ll have to combine more inputs to send the same amount.  W=
hen you
>> want
>> > to send a very large amount that is much greater than the highest
>> available
>> > denomination, you=E2=80=99ll have to send a lot of private transaction=
s, your
>> > bitcoin transaction with so many OP_RETURNs will stand out, and their
>> > number will roughly indicate the total amount.  This kind of privacy
>> > leakage, however it applies to a small number of users, is easy to
>> avoid by
>> > using multiple addresses and storing a relatively small amount on each
>> > address.
>> > 3. Exchanges and large merchants will likely accumulate large coin
>> > histories.  Although fragmented, far from complete, and likely
>> outdated, it
>> > is still something to bear in mind.
>> >
>> > No hard or soft fork is required, BBC is just a separate privacy
>> preserving
>> > currency on top of bitcoin blockchain, and the same private keys and
>> > addresses are used for both BBC and the base currency BTC.  Every BCC
>> > transaction must be enclosed into by a small BTC transaction that stor=
es
>> > the OP_RETURNs and pays for the fees.
>> >
>> > Are there any flaws in this design?
>> >
>> > Originally posted to BCT
>> https://bitcointalk.org/index.php?topic=3D1574508.0,
>> > but got no feedback so far, apparently everybody was consumed with
>> bitfinex
>> > drama and now mimblewimble.
>> >
>> > Tony
>>
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev@lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>> --
>> Henning Kopp
>> Institute of Distributed Systems
>> Ulm University, Germany
>>
>> Office: O27 - 3402
>> Phone: +49 731 50-24138
>> Web: http://www.uni-ulm.de/in/vs/~kopp
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--001a114f42dcf5ca45053996472c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">Wouldn&#39;t you lose the ability to assume transactions in =
the blockchain are verified as valid, since miners can&#39;t see the detail=
s of what is being spent and how? I feel like this ability is bitcoin&#39;s=
 greatest asset, and by removing it you&#39;re creating an altcoin differen=
t enough to not be connected to/supported by the main bitcoin project.</p>
<br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Aug 8, 2016, 09:13 =
Tony Churyumoff via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.lin=
uxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi=C2=A0Henning,<div><=
br></div><div>1. The fees are paid by the enclosing BTC transaction.</div><=
div>2. The hash is encoded into an OP_RETURN.</div></div><div dir=3D"ltr"><=
div><br></div><div>&gt; Regarding the blinding factor, I think you could ju=
st use HMAC.<br></div></div><div dir=3D"ltr"><div>How exactly?</div></div><=
div dir=3D"ltr"><div><br></div><div>Tony</div></div><div dir=3D"ltr"><div><=
br><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">2016-08-08 18:=
47 GMT+03:00 Henning Kopp <span dir=3D"ltr">&lt;<a href=3D"mailto:henning.k=
opp@uni-ulm.de" target=3D"_blank">henning.kopp@uni-ulm.de</a>&gt;</span>:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Tony,<br>
<br>
I see some issues in your protocol.<br>
<br>
1. How are mining fees handled?<br>
<br>
2. Assume Alice sends Bob some Coins together with their history and<br>
Bob checks that the history is correct. How does the hash of the txout<br>
find its way into the blockchain?<br>
<br>
Regarding the blinding factor, I think you could just use HMAC.<br>
<br>
All the best<br>
Henning<br>
<br>
<br>
On Mon, Aug 08, 2016 at 06:30:21PM +0300, Tony Churyumoff via bitcoin-dev w=
rote:<br>
&gt; This is a proposal about hiding the entire content of bitcoin<br>
&gt; transactions.=C2=A0 It goes farther than CoinJoin and ring signatures,=
 which<br>
&gt; only obfuscate the transaction graph, and Confidential Transactions, w=
hich<br>
&gt; only hide the amounts.<br>
&gt;<br>
&gt; The central idea of the proposed design is to hide the entire inputs a=
nd<br>
&gt; outputs, and publish only the hash of inputs and outputs in the<br>
&gt; blockchain.=C2=A0 The hash can be published as OP_RETURN.=C2=A0 The pl=
aintext of<br>
&gt; inputs and outputs is sent directly to the payee via a private message=
, and<br>
&gt; never goes into the blockchain.=C2=A0 The payee then calculates the ha=
sh and<br>
&gt; looks it up in the blockchain to verify that the hash was indeed publi=
shed<br>
&gt; by the payer.<br>
&gt;<br>
&gt; Since the plaintext of the transaction is not published to the public<=
br>
&gt; blockchain, all validation work has to be done only by the user who<br=
>
&gt; receives the payment.<br>
&gt;<br>
&gt; To protect against double-spends, the payer also has to publish anothe=
r<br>
&gt; hash, which is the hash of the output being spent.=C2=A0 We=E2=80=99ll=
 call this hash *spend<br>
&gt; proof*.=C2=A0 Since the spend proof depends solely on the output being=
 spent,<br>
&gt; any attempt to spend the same output again will produce exactly the sa=
me<br>
&gt; spend proof, and the payee will be able to see that, and will reject t=
he<br>
&gt; payment.=C2=A0 If there are several outputs consumed by the same trans=
action,<br>
&gt; the payer has to publish several spend proofs.<br>
&gt;<br>
&gt; To prove that the outputs being spent are valid, the payer also has to=
 send<br>
&gt; the plaintexts of the earlier transaction(s) that produced them, then =
the<br>
&gt; plaintexts of even earlier transactions that produced the outputs spen=
t in<br>
&gt; those transactions, and so on, up until the issue (similar to coinbase=
)<br>
&gt; transactions that created the initial private coins.=C2=A0 Each new ow=
ner of the<br>
&gt; coin will have to store its entire history, and when he spends the coi=
n, he<br>
&gt; forwards the entire history to the next owner and extends it with his =
own<br>
&gt; transaction.<br>
&gt;<br>
&gt; If we apply the existing bitcoin design that allows multiple inputs an=
d<br>
&gt; multiple outputs per transaction, the history of ownership transfers w=
ould<br>
&gt; grow exponentially.=C2=A0 Indeed, if we take any regular bitcoin outpu=
t and try<br>
&gt; to track its history back to coinbase, our history will branch every t=
ime<br>
&gt; we see a transaction that has more than one input (which is not uncomm=
on).<br>
&gt; After such a transaction (remember, we are traveling back in time), we=
=E2=80=99ll<br>
&gt; have to track two or more histories, for each respective input.=C2=A0 =
Those<br>
&gt; histories will branch again, and the total number of history entries g=
rows<br>
&gt; exponentially.=C2=A0 For example, if every transaction had exactly two=
 inputs,<br>
&gt; the size of history would grow as 2^N where N is the number of steps b=
ack<br>
&gt; in history.<br>
&gt;<br>
&gt; To avoid such rapid growth of ownership history (which is not only<br>
&gt; inconvenient to move, but also exposes too much private information ab=
out<br>
&gt; previous owners of all the contributing coins), we will require each<b=
r>
&gt; private transaction to have exactly one input (i.e. to consume exactly=
 one<br>
&gt; previous output).=C2=A0 This means that when we track a coin=E2=80=99s=
 history back in<br>
&gt; time, it will no longer branch.=C2=A0 It will grow linearly with the n=
umber of<br>
&gt; transfers of ownership.=C2=A0 If a user wants to combine several input=
s, he will<br>
&gt; have to send them as separate private transactions (technically, sever=
al<br>
&gt; OP_RETURNs, which can be included in a single regular bitcoin transact=
ion).<br>
&gt;<br>
&gt; Thus, we are now forbidding any coin merges but still allowing coin<br=
>
&gt; splits.=C2=A0 To avoid ultimate splitting into the dust, we will also =
require<br>
&gt; that all private coins be issued in one of a small number of<br>
&gt; denominations.=C2=A0 Only integer number of =E2=80=9Cbanknotes=E2=80=
=9D can be transferred, the<br>
&gt; input and output amounts must therefore be divisible by the denominati=
on.<br>
&gt; For example, an input of amount 700, denomination 100, can be split in=
to<br>
&gt; outputs 400 and 300, but not into 450 and 250.=C2=A0 To send a payment=
, the<br>
&gt; payer has to pick the unspent outputs of the highest denomination firs=
t,<br>
&gt; then the second highest, and so on, like we already do when we pay in =
cash.<br>
&gt;<br>
&gt; With fixed denominations and one input per transaction, coin histories=
<br>
&gt; still grow, but only linearly, which should not be a concern in regard=
 to<br>
&gt; scalability given that all relevant computing resources still grow<br>
&gt; exponentially.=C2=A0 The histories need to be stored only by the curre=
nt owner<br>
&gt; of the coin, not every bitcoin node.=C2=A0 This is a fairer allocation=
 of<br>
&gt; costs.=C2=A0 Regarding privacy, coin histories do expose private trans=
actions<br>
&gt; (or rather parts thereof, since a typical payment will likely consist =
of<br>
&gt; several transactions due to one-input-per-transaction rule) of past co=
in<br>
&gt; owners to the future ones, and that exposure grows linearly with time,=
 but<br>
&gt; it is still much much better than having every transaction immediately=
 on<br>
&gt; the public blockchain.=C2=A0 Also, the value of this information for p=
otential<br>
&gt; adversaries arguably decreases with time.<br>
&gt;<br>
&gt; There is one technical nuance that I omitted above to avoid distractio=
n.<br>
&gt;=C2=A0 Unlike regular bitcoin transactions, every output in a private p=
ayment<br>
&gt; must also include a blinding factor, which is just a random string.=C2=
=A0 When<br>
&gt; the output is spent, the corresponding spend proof will therefore depe=
nd on<br>
&gt; this blinding factor (remember that spend proof is just a hash of the<=
br>
&gt; output).=C2=A0 Without a blinding factor, it would be feasible to pre-=
image the<br>
&gt; spend proof and reveal the output being spent as the search space of a=
ll<br>
&gt; possible outputs is rather small.<br>
&gt;<br>
&gt; To issue the new private coin, one can burn regular BTC by sending it =
to<br>
&gt; one of several unspendable bitcoin addresses, one address per denomina=
tion.<br>
&gt;=C2=A0 Burning BTC would entitle one to an equal amount of the new priv=
ate coin,<br>
&gt; let=E2=80=99s call it *black bitcoin*, or *BBC*.<br>
&gt;<br>
&gt; Then BBC would be transferred from user to user by:<br>
&gt; 1. creating a private transaction, which consists of one input and sev=
eral<br>
&gt; outputs;<br>
&gt; 2. storing the hash of the transaction and the spend proof of the cons=
umed<br>
&gt; output into the blockchain in an OP_RETURN (the sender pays the<br>
&gt; corresponding fees in regular BTC)<br>
&gt; 3. sending the transaction, together with the history leading to its i=
nput,<br>
&gt; directly to the payee over a private communication channel.=C2=A0 The =
first<br>
&gt; entry of the history must be a bitcoin transaction that burned BTC to =
issue<br>
&gt; an equal amount of BCC.<br>
&gt;<br>
&gt; To verify the payment, the payee:<br>
&gt; 1. makes sure that the amount of the input matches the sum of outputs,=
 and<br>
&gt; all are divisible by the denomination<br>
&gt; 2. calculates the hash of the private transaction<br>
&gt; 3. looks up an OP_RETURN that includes this hash and is signed by the<=
br>
&gt; payee.=C2=A0 If there is more than one, the one that comes in the earl=
ier block<br>
&gt; prevails.<br>
&gt; 4. calculates the spend proof and makes sure that it is included in th=
e<br>
&gt; same OP_RETURN<br>
&gt; 5. makes sure the same spend proof is not included anywhere in the sam=
e or<br>
&gt; earlier blocks (that is, the coin was not spent before).=C2=A0 Only tr=
ansactions<br>
&gt; by the same author are searched.<br>
&gt; 6. repeats the same steps for every entry in the history, except the f=
irst<br>
&gt; entry, which should be a valid burning transaction.<br>
&gt;<br>
&gt; To facilitate exchange of private transaction data, the bitcoin networ=
k<br>
&gt; protocol can be extended with a new message type.=C2=A0 Unfortunately,=
 it lacks<br>
&gt; encryption, hence private payments are really private only when bitcoi=
n is<br>
&gt; used over tor.<br>
&gt;<br>
&gt; There are a few limitations that ought to be mentioned:<br>
&gt; 1. After user A sends a private payment to user B, user A will know wh=
at<br>
&gt; the spend proof is going to be when B decides to spend the coin.<br>
&gt;=C2=A0 Therefore, A will know when the coin was spent by B, but nothing=
 more.<br>
&gt;=C2=A0 Neither the new owner of the coin, nor its future movements will=
 be known<br>
&gt; to A.<br>
&gt; 2. Over time, larger outputs will likely be split into many smaller<br=
>
&gt; outputs, whose amounts are not much greater than their denominations.<=
br>
&gt; You=E2=80=99ll have to combine more inputs to send the same amount.=C2=
=A0 When you want<br>
&gt; to send a very large amount that is much greater than the highest avai=
lable<br>
&gt; denomination, you=E2=80=99ll have to send a lot of private transaction=
s, your<br>
&gt; bitcoin transaction with so many OP_RETURNs will stand out, and their<=
br>
&gt; number will roughly indicate the total amount.=C2=A0 This kind of priv=
acy<br>
&gt; leakage, however it applies to a small number of users, is easy to avo=
id by<br>
&gt; using multiple addresses and storing a relatively small amount on each=
<br>
&gt; address.<br>
&gt; 3. Exchanges and large merchants will likely accumulate large coin<br>
&gt; histories.=C2=A0 Although fragmented, far from complete, and likely ou=
tdated, it<br>
&gt; is still something to bear in mind.<br>
&gt;<br>
&gt; No hard or soft fork is required, BBC is just a separate privacy prese=
rving<br>
&gt; currency on top of bitcoin blockchain, and the same private keys and<b=
r>
&gt; addresses are used for both BBC and the base currency BTC.=C2=A0 Every=
 BCC<br>
&gt; transaction must be enclosed into by a small BTC transaction that stor=
es<br>
&gt; the OP_RETURNs and pays for the fees.<br>
&gt;<br>
&gt; Are there any flaws in this design?<br>
&gt;<br>
&gt; Originally posted to BCT <a href=3D"https://bitcointalk.org/index.php?=
topic=3D1574508.0" rel=3D"noreferrer" target=3D"_blank">https://bitcointalk=
.org/index.php?topic=3D1574508.0</a>,<br>
&gt; but got no feedback so far, apparently everybody was consumed with bit=
finex<br>
&gt; drama and now mimblewimble.<br>
&gt;<br>
&gt; Tony<br>
<br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev</a><br>
<span><font color=3D"#888888"><br>
<br>
--<br>
Henning Kopp<br>
Institute of Distributed Systems<br>
Ulm University, Germany<br>
<br>
Office: O27 - 3402<br>
Phone: +49 731 50-24138<br>
Web: <a href=3D"http://www.uni-ulm.de/in/vs/~kopp" rel=3D"noreferrer" targe=
t=3D"_blank">http://www.uni-ulm.de/in/vs/~kopp</a><br>
</font></span></blockquote></div><br></div></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--001a114f42dcf5ca45053996472c--