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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <john.dillon892@googlemail.com>) id 1UbnEH-0006hh-HM
for bitcoin-development@lists.sourceforge.net;
Mon, 13 May 2013 07:31:29 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of googlemail.com
designates 74.125.83.48 as permitted sender)
client-ip=74.125.83.48;
envelope-from=john.dillon892@googlemail.com;
helo=mail-ee0-f48.google.com;
Received: from mail-ee0-f48.google.com ([74.125.83.48])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UbnEG-0007qa-Ct
for bitcoin-development@lists.sourceforge.net;
Mon, 13 May 2013 07:31:29 +0000
Received: by mail-ee0-f48.google.com with SMTP id c4so3011706eek.35
for <bitcoin-development@lists.sourceforge.net>;
Mon, 13 May 2013 00:31:22 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.14.1.7 with SMTP id 7mr32755188eec.41.1368430282044; Mon, 13
May 2013 00:31:22 -0700 (PDT)
Received: by 10.223.101.82 with HTTP; Mon, 13 May 2013 00:31:21 -0700 (PDT)
In-Reply-To: <20130511102209.GA27823@netbook.cypherspace.org>
References: <20130511045342.GA28588@petertodd.org>
<20130511102209.GA27823@netbook.cypherspace.org>
Date: Mon, 13 May 2013 07:31:21 +0000
Message-ID: <CAPaL=UV7B2ULcUSBBQNWKc70PzGnveeF2WiWQE7msteZ6TZAbQ@mail.gmail.com>
From: John Dillon <john.dillon892@googlemail.com>
To: Adam Back <adam@cypherspace.org>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: -1.4 (-)
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
(john.dillon892[at]googlemail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
digit (john.dillon892[at]googlemail.com)
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1UbnEG-0007qa-Ct
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 07:31:29 -0000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Sat, May 11, 2013 at 10:22 AM, Adam Back <adam@cypherspace.org> wrote:
> I didnt quite understand the writeup and the references were ambiguous.
No you didn't. :)
What is special about what Peter is proposing is that it is *not* merge-mining.
You see, merge-mining is essentially where you use one PoW for two purposes,
two different blockchains. So you are getting more value from just one unit of
work.
But Peter's coinbase hashcash protocol carefully ensures that the act of mining
the hashcash is guaranteed to cost the miner at least some well-defined amount,
and that amount can be easily calculated by considering the probability that a
block could have been found with the effort required to generate the proof of
work, and the amount of value the miner would have then given away in a
"anyone-can-spend" output. (you may not realize this, but a scriptPubKey with a
single pushdata opcode is always evaluated as true, which means it can be
respent by anyone)
Don't feel bad though, I had to ask him to explain it to me too. :)
> Rivest's PayWord for people who dont know the reference in this context is
> the observation that for a low value micro-payment, you dont mind if you
> only receive a payment 1 time in k so long as the expected payment is n
> after receiving n (eg satoshi sized) payments. Eg like a penny tip jar so
> long as your expected payment is correct long term (win as often as you
> lose) you dont mind. And a fair 100% payout lottery can be fun of itself.
I think you are misremembering. I just checked the paper and PayWord is based
on chains of hashes and you give the receiver a digest and if after n repeated
hashes it is considered to have been worth n*k It is not a probabalistic
scheme.
Incedentally while it is an obvious enough idea, though I didn't see a
reference to it, PayWords can be easily extended with a time-bandwidth
trade-off by using a structure similar to a merkle tree. The roots could be
created from some fixed nonce K and a increaing integer, H(K | n) Then you
would provide a merkle path to the previously agreed upon final digest. So
proof size for your payment would be log(n), and time to check the proof
log(n). Unfortunately setting up the scheme is still 2*n however that only
needs to be done once.
> So let say each email client sends in an email header the head of the
I have to respect a man who after all these years is still thinking
about anti-spam for email. :)
> Maybe one can put the bitcoin hash in DNS with a 5min TTL and have mail
> clients read that to reduce scope for stale mining.
Peter actually made a blockchain headers over DNS system, and a blockchain
headers over twitter system as an April fools joke. See
https://twitter.com/blockheaders
> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJRkJZoAAoJEEWCsU4mNhiPtscIAL4eM+reWCfAjw0FAv5c5lwQ
tJvuVgmkCVyVurQLFbMt0hxXiYAFeTJ31uW0QBEdvitzIUAWR4QO/wfqNULAdZoA
RzTCOBTjfFFGQLd7UdRuDSSEvq23oeJCoixbtdGpAmM1ySRvCExkO+fYehNqXEDN
FF1PVv9VPc5KXbDw3mB6l8dkMCLEHmYpkdrNRvHHQMhyLXO8q3Q6H3zDy3YbztZC
rxibYprOtF1Z2dZzIYTWaGoA9ONLqSgOU2J1htj6kastsjW1d3XKIkdU/eRP2cEs
CG2EWyyrm59e4zpYL4BJj0zBMW9+pQQsSvrAtAoAFVdLojsAWBVL0PIQ8h8N6SY=
=+ptH
-----END PGP SIGNATURE-----
|
