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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <adam.back@gmail.com>) id 1Y39Ez-0003MC-0E
for bitcoin-development@lists.sourceforge.net;
Mon, 22 Dec 2014 20:06:05 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.192.47 as permitted sender)
client-ip=209.85.192.47; envelope-from=adam.back@gmail.com;
helo=mail-qg0-f47.google.com;
Received: from mail-qg0-f47.google.com ([209.85.192.47])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Y39Ef-0000Je-Nf
for bitcoin-development@lists.sourceforge.net;
Mon, 22 Dec 2014 20:06:04 +0000
Received: by mail-qg0-f47.google.com with SMTP id q108so3710689qgd.20
for <bitcoin-development@lists.sourceforge.net>;
Mon, 22 Dec 2014 12:05:40 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.229.178.67 with SMTP id bl3mr39593146qcb.18.1419278740220;
Mon, 22 Dec 2014 12:05:40 -0800 (PST)
Sender: adam.back@gmail.com
Received: by 10.96.189.10 with HTTP; Mon, 22 Dec 2014 12:05:40 -0800 (PST)
In-Reply-To: <20141220144800.GA26284@savin.petertodd.org>
References: <20141212090551.GA8259@muck>
<20141220144800.GA26284@savin.petertodd.org>
Date: Mon, 22 Dec 2014 20:05:40 +0000
X-Google-Sender-Auth: EGPkUTxOYtP7mwGoaZYX7aI_h28
Message-ID: <CALqxMTEjYsYs6uTfYKKAx_VCi1L8fHRX-MMKpYbMB56FNnHgqQ@mail.gmail.com>
From: Adam Back <adam@cypherspace.org>
To: Peter Todd <pete@petertodd.org>
Content-Type: text/plain; charset=UTF-8
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
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
0.0 T_FILL_THIS_FORM_SHORT Fill in a short form with personal
information
0.0 TIME_LIMIT_EXCEEDED Exceeded time limit / deadline
X-Headers-End: 1Y39Ef-0000Je-Nf
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] The relationship between
Proof-of-Publication and Anti-Replay Oracles
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, 22 Dec 2014 20:06:05 -0000
(Again nothing new to say here, just putting my notes in this
discussion, where I started with an earlier discussion that Peter
wrote up with a subject of "disentangling" blockchain design).
In the discussion last year that started the analysis of
"disentangling" blockchain design I had broken out the candidate layer
properties that one could use as building blocks to construct a
decentralised PoW-chain assured immutable history based ecash system
as:
- time-stamping (really just time-ordered as network time is weak)
- namespace (first come first served name value pairs)
I thought it was interesting to look at potential minimum enabling
functionality in order to explore whether the consensus critical code
could be simplified for security, and also to understand the tradeoffs
towards seeing if there were any improvements that could be found.
(And it seems its pretty hard to find any improvements was my
conclusion).
Time-stamping (or time-ordering) at a requirements level does not have
to imply that there is a uniqueness guarantee, or even that the nodes
see what they are time-stamping (it could be committed with a random
nonce) and indeed hiding the committed data from the service and
public view is a common property of time-stamping. Time-ordering just
creates an immutable (and not strongly deduplicated) stream of data
items that came from various users and had a time-ordering placed on
them.
Minimally the person who submitted the data item would need to know
the merkle path to it, and that might be achieved by publishing the
merkle tree, where some or all of the leaves are hidden commitments.
For bitcoin composability purposes you might require that there be no
hidden commitments, and then other miners and full nodes could
download all the merkle trees for each PoW-interval and ignore
duplicates.
Namespace service adds the uniqueness and first-come first-served
property up-front (as its more efficient for people catching up to not
have to download and discard duplicates/double-spends), and this more
strict rule requires miners to know about (and presumably index) all
previous information to avoid violating this rule. I assume name
attributes to hold information like a public key to approve changes in
ownership, an IP address, an email address etc. For efficient proof
reasons there is still a merkle tree per PoW time-interval binding
names into a hash-chain.
For bitcoin re-described using a namespace the unique coins are the
names, and values and ownership public key etc are attributes of the
name; names (coins) are only added (via mining) or after deletion
(spend/transfer) of previous names. Transfers are approved via
digital signature.
The additional property bitcoin requires is that the values add up.
I presume the phrase proof of publication means to draw out separately
that the full-node version of bitcoin requires a rule that miners
should not build on top of blocks unless they have copies of all data
committed to. Otherwise a malicious party can hide ownership
transfers that can be revealed later, so that no one is assured of
ownership: any possibility for a gap in the ownership chain calls into
question ownership. So from that perspective a miner consensus rule
that it should not build on top of blocks that it hasnt seen a full
gap-free history for makes the PoW chain a kind of proof that the
miner population at one time saw all data hashed into it.
I think you need one more thing which is that the miners (and other
full nodes who have copies of the data) are willing to share that
historic data with you. There is some meta-incentive for bitcoin
holders to help others catchup and be assured of the history and
information has to be broadcast as there are many miners and
full-nodes.
I presume anti-relay term is meant at system level, rather than node
level, though technically bitcoin nodes in the current protocol
version dont relay double-spent transactions. Particularly that
miners wont bless double-spent transactions (and will do PoW only over
non double-spent transfers).
While there does seem to be some confusion from some people perhaps
not realising that it is essential that there are no gaps in the
ownership chain, I am not sure there are necessarily any practical
implication of philosophical differences between proof of publication
& anti-relay (or namespace for that matter). It is also important
that there is no way to attack the insertion logic so that eg someone
cant get a hash into an internal nor leaf node of the merkle tree
without the miners first seeing that data.
Presumably as they are all describing ways to think about bitcoin and
assuming no one is confused about how bitcoin works, the distinction
just comes down to what features are assumed to be naturally included
in the layer definition, and what features have to be added. For
example I think its relatively normally assumed that people can look
up names.
I suppose it might be possible to put a self-authenticating access
handle for the data item into the data set which points into a
redundant immutable data store. In effect that is what the bitcoin
nodes do provide (with full redundancy). But, more efficiently though
perhaps with less redundancy and assurance, one could put the data
into tahoe-lafs which implements immutability, append-only and
self-authenticating urls and such properties. From that perspective
it does make sense to say there is a layer that provides assurance of
availability of history; the PoW-chain and merkle-tree in the header
assures already immutability. The remaining thing that has to be
assured is availability.
Adam
On 20 December 2014 at 14:48, Peter Todd <pete@petertodd.org> wrote:
> Gregory Maxwell recently pointed out to me in private conservation that
> there potentially existed a fundemental disagreement between him and I
> on our philosophical approaches to blockchains, in that he prioritised
> the notion of the blockchain as an anti-replay oracle, and I prioritised
> it as a publication layer. Here I'll talk about the differences and
> simularities between those two approaches.
|
