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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <adam.back@gmail.com>) id 1Uc03F-0003Jn-L2
for bitcoin-development@lists.sourceforge.net;
Mon, 13 May 2013 21:12:57 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.174 as permitted sender)
client-ip=209.85.215.174; envelope-from=adam.back@gmail.com;
helo=mail-ea0-f174.google.com;
Received: from mail-ea0-f174.google.com ([209.85.215.174])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Uc03D-0002GF-M4
for bitcoin-development@lists.sourceforge.net;
Mon, 13 May 2013 21:12:57 +0000
Received: by mail-ea0-f174.google.com with SMTP id z7so2834953eaf.5
for <bitcoin-development@lists.sourceforge.net>;
Mon, 13 May 2013 14:12:49 -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:x-hashcash;
bh=hzeuDJBjmw3JmDHtf7FUsB6gxqW7naol13FTlR2+1Mc=;
b=M62tLFEI90h7Pqi3AikqvZE5ENX6nB4hm7f/pED2ztJZgPur8HMho79YBF5gMJiFEf
MH7FW96FHdnlsf49azYAFyVLJDJvB4Nt7XCshkVaaVgv6qrCtXEpC11s95dvA/HMMfgO
xaQAJ22RHmHSR/Ds/4xcqwaCl/FGJfLOo69JBPIbbgNXz4G/rAmZjkwDjDz4JauRLX8O
P7l2Hpa8fwgjrMror//g6PqDb0myqnH2TzXHgFBLoR6UR4b3rUCTsef0CGE0fGvQnVo/
lv7+DjrY5xWk9dYLiPvE14k29lvlBBbqFacRPtakAHPYs0JBLbK2AaHCsHnHfTTMHkBP
YjoA==
X-Received: by 10.14.221.67 with SMTP id q43mr36944837eep.1.1368479569310;
Mon, 13 May 2013 14:12:49 -0700 (PDT)
Received: from netbook (c83-90.i07-21.onvol.net. [92.251.83.90])
by mx.google.com with ESMTPSA id
bp51sm25482284eeb.5.2013.05.13.14.12.47 for <multiple recipients>
(version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Mon, 13 May 2013 14:12:48 -0700 (PDT)
Received: by netbook (Postfix, from userid 1000)
id 5F6522E0619; Mon, 13 May 2013 23:12:47 +0200 (CEST)
Received: by flare (hashcash-sendmail, from uid 1000);
Mon, 13 May 2013 23:12:44 +0200
Date: Mon, 13 May 2013 23:12:44 +0200
From: Adam Back <adam@cypherspace.org>
To: Jeff Garzik <jgarzik@exmulti.com>
Message-ID: <20130513211244.GA9550@netbook.cypherspace.org>
References: <20130511045342.GA28588@petertodd.org>
<20130511102209.GA27823@netbook.cypherspace.org>
<CAPaL=UV7B2ULcUSBBQNWKc70PzGnveeF2WiWQE7msteZ6TZAbQ@mail.gmail.com>
<20130513105408.GB3393@netbook.cypherspace.org>
<CA+8xBpdmxpCPO77Nr=vDwsKAKTEU4PM4ButT3bDUkhA5tzc3Zw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <CA+8xBpdmxpCPO77Nr=vDwsKAKTEU4PM4ButT3bDUkhA5tzc3Zw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Hashcash: 1:20:130513:jgarzik@exmulti.com::cuvIqcCFmrSxF4b+:000000000000000000
000000000000000000000000A0Jf
X-Hashcash: 1:20:130513:john.dillon892@googlemail.com::h+hGgidkB/ipAceZ:00000000
0000000000000000000000000sJX
X-Hashcash: 1:20:130513:bitcoin-development@lists.sourceforge.net::zkKq8NJ54nlDU
PZ8:000000000000000000005VL9
X-Hashcash: 1:20:130513:adam@cypherspace.org::AlbJKmXccS0j2Kvg:00000000000000000
0000000000000000000000000DA8
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: 1Uc03D-0002GF-M4
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] merged mining hashcash & bitcoin (Re:
Coinbase TxOut Hashcash)
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: Mon, 13 May 2013 21:12:57 -0000
Some musings about the differences between Peter's proof-of-sacrifice (you
did the work but elected to make the small reward chance unclaimable), vs
conventional actually doing the work but then destroying the bitcoin!
- proof-of-sacrifice seems similiar to hashcash except its difficulty is
time stamped and measured against the bitcoins dynamic difficulty,
(coordinated inflation control being something posited but never
implemented in hashcash). So thats kind of interesting, particularly if
you can do it with very low bandwidth, and decentralized; unclear.
- with proof-of-sacrifice its more offline because you do not need an on
block-chain double spend protection (via flood-fill, validation, and block
chain mining) because it is simply "unspendable", though you could show
the same proof to multiple people. In any case the values are far too low
to spam the block chain with.
- because proof-of-sacrifice is small you can afford to mine them on the
spot and make them payable to the identity of the recipient, like cheques:
they identify the recipient, so they are automaticaly non-respendable in
the eyes of the recipient (he keeps his own double-spend db, and people
wont accept cheques made payabe to other people). This is how hashcash
works for email. Also a time-stamp ensures you dont even need a big
double-spend db, as you can prune it if you reject expired cheqes.
- you could give a proof-of-sacrifice a private key, just like bitcoins;
then they could be pre-mined and identity or other info could be signed
later. However then you have double spending issues again. You can
- I mentioned amortizable hashcash under-contribution feature you can make
it so the recipient uncovers the actual value of the coin (if it is
merge-mined). (Put recipient public key in coinbase, hash for min share
size eg 32-bits leading 0s call that "collision"; send to recipient, he
decrypts the hash with private key, so the decryption is verifiable with
public key. Then the full value of the coin is
zerobit( collision ) + zerobits( decrypt( collision ) )
if that alternate validation was allowed in bitcoin.
- what about if a pool could lock the reward (rather than receive it or
destroy it) eg some kind of merkle root instead of a public key hash in
the reward recipient address field in the coinbase. Then the miners who
created that block have actual share proofs that are claims against
something eventually redeemable. Maybe if they collect enough
share-proofs to reach a minimum bitcoin transaction size, they can redeem
a big strip of shares for a few mBTC, but claims below that are rejected
by the network due to tx fee. (btw I think it seems possible to have a
publicly auditable pool so it cant skim nor disclaim shares.)
>I've been thinking about a decentralized way to create an anonymous
>identity, something I think it key to any number of decentralized, P2P
>and anonymous markets.
There were some systems that charged hashcash for pseudonyms i2p names (i2p
is a ToR like system)... see htp://www.i2p2.e/naming.html then there was of
course namecoin. There was some remailer/email nymserver integration as
well.
>Getting back on topic, somewhat, one idea I had for creation cost of a
>SIN was associating the creation cost of a SIN with a bitcoin
>transaction's miner fee. Anybody in the world could, therefore,
>create a SIN in a decentralized fashion, simply by following a
>published protocol for burning a specified amount of bitcoins via
>miner fee. It can be cryptographically proven with 100% certainty who
Yes it seems that having a proof-of-sacrifice that hardens the block chain
is the important part.
When you said destroy-via-miner-fee:
>Don't forget: 4. destroy-via-miner-fee, which is useful because it
>provides funding for a public service (bitcoin transaction
>verification).
Is that directly possible? Because the reward transaction has no source,
and no fee? Or can you put a 25BTC fee in the reward transaction in the
coinbase?
If so that seems like the best option for proof-of-sacrifice rather than
proving destroying the possibility of reward. But alternatively the bitcoin
foundation as recipient, or EFF etc. 25BTC is a big reward might have some
double roll-over lottery effects - everyone piles in for the occasional
25BTC!
Adam
On Mon, May 13, 2013 at 02:38:15PM -0400, Jeff Garzik wrote:
>On Mon, May 13, 2013 at 6:54 AM, Adam Back <adam@cypherspace.org> wrote:
>> On Mon, May 13, 2013 at 07:31:21AM +0000, John Dillon wrote:
>>>[with] merge-mining [you get] more value from just one unit of work.
>>
>> correct.
>>
>>>But Peter's coinbase hashcash protocol carefully ensures [...] the amount
>>>of value the miner would have then given away in a "anyone-can-spend"
>>>output.
>>
>> I think there are 3 choices:
>>
>> 1. merged-mine (almost zero incremental cost as the bitcoin mining return is
>> still earned)
>>
>> 2. destroy bitcoin (hash of public key is all 00s so no computible private
>> key)
>>
>> 3. anyone-can-spend (= first to spend gets coin?)
>
>Don't forget: 4. destroy-via-miner-fee, which is useful because it
>provides funding for a public service (bitcoin transaction
>verification).
>
>(a tangent, but related)
>
>I've been thinking about a decentralized way to create an anonymous
>identity, something I think it key to any number of decentralized, P2P
>and anonymous markets. My main focus, for this identity project, is
>to develop a decentralized protocol for generating a UUID-like unique
>identifier (bitstring), in a way that has some amount of creation cost
>attached (to prevent creating a billion of such tokens etc.). I call
>it a system identifier, or SIN.
>
>Once you have a SIN, you may associate the SIN with a GPG fingerprint,
>email address, real name, login credentials, etc. eBay-like
>marketplaces publish SIN ratings (though it displays on screen as
>"jgarzik" not "1234-abcd-5678-def0"). Standard-and-Poors style
>ratings agencies would similarly rate a business's SIN. SIN's build a
>reputation and trust over time, while controlling their own anonymity
>(or lack thereof). Anybody may abandon a SIN at any time. Ownership
>of a SIN is cryptographically proven via digital signature.
>
>Getting back on topic, somewhat, one idea I had for creation cost of a
>SIN was associating the creation cost of a SIN with a bitcoin
>transaction's miner fee. Anybody in the world could, therefore,
>create a SIN in a decentralized fashion, simply by following a
>published protocol for burning a specified amount of bitcoins via
>miner fee. It can be cryptographically proven with 100% certainty who
>made such a transaction, and the miner fee attaches a creation cost to
>ensure that SINs are not -too- cheap.
>
>Burn-via-miner-fee is a useful tool outside of this example. It funds
>a public service, providing a positive feedback loop for miners who
>receive fees via such services.
>
>--
>Jeff Garzik
>exMULTI, Inc.
>jgarzik@exmulti.com
|
