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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <adam.back@gmail.com>) id 1UclJL-0004hC-F7
for bitcoin-development@lists.sourceforge.net;
Wed, 15 May 2013 23:40:43 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.175 as permitted sender)
client-ip=209.85.215.175; envelope-from=adam.back@gmail.com;
helo=mail-ea0-f175.google.com;
Received: from mail-ea0-f175.google.com ([209.85.215.175])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UclJK-0007t4-9l
for bitcoin-development@lists.sourceforge.net;
Wed, 15 May 2013 23:40:43 +0000
Received: by mail-ea0-f175.google.com with SMTP id h10so1233393eaj.34
for <bitcoin-development@lists.sourceforge.net>;
Wed, 15 May 2013 16:40:36 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=20120113;
h=x-received:date:from:to:cc:subject:message-id:references
:mime-version:content-type:content-disposition:in-reply-to
:user-agent:x-hashcash:x-hashcash:x-hashcash;
bh=pzy8VVtia2EUFSdgL4zIt5PTk7tkn18hXJskmvTej+Y=;
b=Y29tVU21znsccWbZjlSEyp/K/T7agqCNehzhCdiwN0M2Zg2hT6yNmmureo2Km2rvNi
fRps2DSxyCP5PzYx/jizGjcvfXyoQUFC9F6uIWUcIUceSZn/6kMA68XtDOPBQqbthJiJ
cu7ZLIPAjiyxUHm4lGB9LSGWei9P5GH30gVToiDQclifA7vK5/mcyyq7G4U41JzKUDv0
wTYPhyMSHskWf8HVAybAra1d9k1KMZsYVn2DmX0GPA9pPQagw3/Q3hdX/paIaMsukYFd
WSCGkZtw/XdKLPSRJWX4+gMGsrfilAafdtwgdzcgL8/8DwZEPlHnBHKYGn+OU/mZAWfv
cg1g==
X-Received: by 10.14.111.5 with SMTP id v5mr109527072eeg.27.1368661235943;
Wed, 15 May 2013 16:40:35 -0700 (PDT)
Received: from netbook (c83-90.i07-21.onvol.net. [92.251.83.90])
by mx.google.com with ESMTPSA id y10sm7004773eev.3.2013.05.15.16.40.34
for <multiple recipients>
(version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Wed, 15 May 2013 16:40:35 -0700 (PDT)
Received: by netbook (Postfix, from userid 1000)
id 4A07B2E04CB; Thu, 16 May 2013 01:40:32 +0200 (CEST)
Received: by flare (hashcash-sendmail, from uid 1000);
Thu, 16 May 2013 01:40:30 +0200
Date: Thu, 16 May 2013 01:40:30 +0200
From: Adam Back <adam@cypherspace.org>
To: Caleb James DeLisle <calebdelisle@lavabit.com>
Message-ID: <20130515234030.GA17920@netbook.cypherspace.org>
References: <20130514115151.GA21600@netbook.cypherspace.org>
<20130514140902.GA22447@netbook.cypherspace.org>
<20130515102509.GA3401@netbook.cypherspace.org>
<20130515111906.GA26020@savin>
<20130515114956.GA5863@netbook.cypherspace.org>
<5193825B.20909@lavabit.com>
<20130515162129.GB6156@netbook.cypherspace.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <20130515162129.GB6156@netbook.cypherspace.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Hashcash: 1:20:130515:calebdelisle@lavabit.com::xG+lxO59WLW1qpLC:0000000000000
0000000000000000000000000N6q
X-Hashcash: 1:20:130515:bitcoin-development@lists.sourceforge.net::GPe8eVqdFN/3E
GAR:000000000000000000009YBR
X-Hashcash: 1:20:130515:adam@cypherspace.org::1g1La2HzZE6AHF6E:00000000000000000
0000000000000000000000000faV
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(adam.back[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1UclJK-0007t4-9l
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] blind symmetric commitment for stronger
byzantine voting resilience (Re: bitcoin taint & unilateral revocability)
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 15 May 2013 23:40:43 -0000
btw I posted some of this thread on the dev forum:
https://bitcointalk.org/index.php?topic=206303.msg2157994#msg2157994
A related idea is occuring to me that maybe these committed transactions
could actually as a side effect make bitcoin scale slightly better by
reducing the p2p flood filled transaction size.
As I said on the forum:
> Note committed transactions are more compact than regular transactions -
> they are just two hashes, so they reduce network bandwidth and make
> bitcoin more scalable to the extent that transaction reveals stay off
> network. (As well as more secure against centralization policy risks).
Surely its lower bandwidth for nodes to send only committed transactions to
the p2p network, and pass committed payment chains direct to recipients.
Say committed transaction size is c (20bytes+32bytes+16bytes +header ~ 72
bytes?) And full transaction smallest size is t (txin=20bytes, amount out
4bytes, sender pub key 32bytes, recip address 20bytes, change address
20bytes, formatting 5 bytes, ECDSA signature 64bytes, script 10 byte surely
~ 175bytes)? Thats over twice the size. Probably average more, and it is
sent to every node. Its always going to be lower bandwidth to send
transactions to the recipients than to send to the network, even if you have
to increase the transaction size with each respend. The alternative is for
the entire network to see the same transaction.
I think the commitment needs to bind the two parts together eg
(blind-sender, auth-tag, tx-commit)
blind-sender = SHA1( SHA256( 1, pub ) )
auth = HMAC-SHA256-128( K, tx-commit )
tx-commit = SHA-256( tx )
Or some variantion, and you must not reuse the pub key, and must send change
if any to a different address, otherwise chain recipients or malicious
forwarders could lock your coin, by putting random junk onto the network
which would be unverifiable, and non-disclaimable - you cant prove you dont
know the preimage of some junk. The MAC prevents it. Maybe there's a more
compact way to do it even, but that works efficient demonstration of
security feasibility.
Other public key variants could be possible, P = xG is the ECDSA public key,
x the private key, G base point. Sender could reveal P' = cP, c some fixed
constant (computing c from cP is ECDL problem considered oneway & hard), and
a signature by private key x' = cx over the tx-commit. That is a publicly
auditable commitment also, but one tht can make an ECDSA signature over the
tx-commit hash, and can be revealed by revealing P later. However that
imposes public key computation on the validation (which it already currently
does, but faster validation as above is nicer). With that one you dont even
have to verify the transaction signature on reveal :) You already did it,
just provide the tx that hashes to the signed hash, and P for the recipient
to verify the signature was made by cP.
Adam
|
