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
|
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 1UbqOZ-0006dt-1w
for bitcoin-development@lists.sourceforge.net;
Mon, 13 May 2013 10:54:19 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.83.43 as permitted sender)
client-ip=74.125.83.43; envelope-from=adam.back@gmail.com;
helo=mail-ee0-f43.google.com;
Received: from mail-ee0-f43.google.com ([74.125.83.43])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UbqOX-000490-La
for bitcoin-development@lists.sourceforge.net;
Mon, 13 May 2013 10:54:19 +0000
Received: by mail-ee0-f43.google.com with SMTP id b15so3677028eek.16
for <bitcoin-development@lists.sourceforge.net>;
Mon, 13 May 2013 03:54:11 -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=vvYLdzB3b2aLRsG+wevMOjF+Ap4ayb7M0VQ4CtlGaDo=;
b=XTYtgIaU6Ag96QRhXvDt8bv7UeYs3T0mBhdQsoNAtX3i5gnxczLd9GoMB7egZJw3E/
DJwCcXP10XTjxIo9uv35fHkZdmcj3rPl4sGYMs7YWyRYhXKLx4tTUIDsmHXm2i/xB4TN
Dk2Oy1XfmMmJdoG984tPZ5htfrk7Ue4SIErUC0CQM7oUlC2Bxqx5e8UpVDgZYVs220+/
UaY8mlfi/OWWamvPu5L54jEVk4o2K9b7MOFx51UtHgb8CHyJKPwiKXNOgCNCJJLZr5TN
/Di+66/Gp3sxMcim31erqQPF6UQpd9jXodmXWsRhUO/151KaOOL4YQYMikFa7+4gED4r
wqAw==
X-Received: by 10.14.111.129 with SMTP id w1mr77085713eeg.13.1368442451310;
Mon, 13 May 2013 03:54:11 -0700 (PDT)
Received: from netbook (c83-90.i07-21.onvol.net. [92.251.83.90])
by mx.google.com with ESMTPSA id m4sm22038455eeu.15.2013.05.13.03.54.09
for <multiple recipients>
(version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Mon, 13 May 2013 03:54:10 -0700 (PDT)
Received: by netbook (Postfix, from userid 1000)
id ADB3B2E0442; Mon, 13 May 2013 12:54:09 +0200 (CEST)
Received: by flare (hashcash-sendmail, from uid 1000);
Mon, 13 May 2013 12:54:08 +0200
Date: Mon, 13 May 2013 12:54:08 +0200
From: Adam Back <adam@cypherspace.org>
To: John Dillon <john.dillon892@googlemail.com>
Message-ID: <20130513105408.GB3393@netbook.cypherspace.org>
References: <20130511045342.GA28588@petertodd.org>
<20130511102209.GA27823@netbook.cypherspace.org>
<CAPaL=UV7B2ULcUSBBQNWKc70PzGnveeF2WiWQE7msteZ6TZAbQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <CAPaL=UV7B2ULcUSBBQNWKc70PzGnveeF2WiWQE7msteZ6TZAbQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Hashcash: 1:20:130513:john.dillon892@googlemail.com::FWEWM/Rk8G+RXh+5:00000000
0000000000000000000000000hx9
X-Hashcash: 1:20:130513:pete@petertodd.org::MuEqU2e36ov/6z4Y:0000000000000000000
0000000000000000000000005JEZ
X-Hashcash: 1:20:130513:bitcoin-development@lists.sourceforge.net::tUezDIjBO1hIT
R2E:000000000000000000001ykG
X-Hashcash: 1:20:130513:adam@cypherspace.org::tdo6AV+IYjuXrGy0:00000000000000000
00000000000000000000000000T1
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: 1UbqOX-000490-La
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 10:54:19 -0000
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?)
Surely in 3 if you mine the bitcoin its no particular assurance a you will
do your best to make sure that it is *you* tht spends it, so it devolves to
merged-mine. (Eg delay revealing it for 10 seconds while you broadcast your
spend widely)
Peter talks about value, but the proof only proves cost equal to bitcoin.
Those are not the same thing. And they are so-far non-respendable.
I still dont understand what he was saying. If you do please speakup.
I think potentially a publicly auditable pooled mining protocol would be a
place to start thinking about respendble micropayments. I made a post
on the bitcointalk forum outlining how that could be done:
https://bitcointalk.org/index.php?topic=1976.msg2035637#msg2035637
if you have a publicly auditable pool, where users can prove to each other
outside of the bitcoin transaction log that they contributed a number of
shares to a block, those could be traded somehow. Possibly eg with the pool
keeping a double-spend db. If the payments are low value, people maybe
happy trusting a pool. If the pool cheats, everyone stops using the pool.
You rely on the pool not to spend the backing bitcoin blocks. But it
remains possible for the pool to cashout people who collected enough shares.
Probably you could do that with blinding if desired.
>> [probabilistic micro-payments]
>
>I think you are misremembering [...] It is not a probabalistic scheme.
You are right I was thinking of Rivest's peppercoin.
>> In this way one can merge mine bitcoin & hashcash to the benefit of the
>> recipient (or some beneficiary trusted not to be paying the proceeds to the
>> spammer). And in a way that scales to email scale, and does not involve
>> installing a bitcoin client in every client, nor mail server.
>
>Blockchain header data may very well be one of the most widely distributed
>single data sets in the history of mankind, and most of its closest cousins are
>definitions such as the ASCII table or near definitions like the DNS root
>servers. Not something with new data every 10 minutes.
Well there doesnt need to be a one-true-blockchain DNS, though the power to
output a hash at any reasonable rate is a big proportion of the network
power. And the outputs are instantly verifiable, so it forms a kind of
trapdoor hashchain (where the trap door is not a secret but havng a huge
amount of CPU power). And there can and should be many blockchain via DNS.
For namesaces in general another approach other than DHT/flood is numerous
competing hierarchical, heavily cached, but publicly auditable. Cheaters
are shunned. Same effect, more scalable, most people are not cheating most
of the time.
http://cypherspace.org/p2p/auditable-namespace.html
Adam
|
