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
|
Return-Path: <dscotese@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 1469B898
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 15 Apr 2019 00:45:06 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it1-f170.google.com (mail-it1-f170.google.com
[209.85.166.170])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 30F7D6C5
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 15 Apr 2019 00:45:05 +0000 (UTC)
Received: by mail-it1-f170.google.com with SMTP id f22so24103908ita.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 14 Apr 2019 17:45:05 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=eg+SMM13VNUcnjyNr2QX/tvw6Ao2O6ozcpmMju4mbAU=;
b=cJ1cA+DNL0bNtt7RV6yap4L/PRpFGUc6xPu0aoO7hfP/RDTzCypAN/WPiaEUqSS+Ls
8UMLcX5K4K0tnfj0GS+wP2AGtPylAM1aqk9pPBtL5Mjk2NfDsAXGcyQSj9g05CsxToDz
d5P3NKPi5TDBcDvtdx1tqQbem6q735bHUxJhuMpow/wtGibrKHYCQxbT+/+aW4Hv6Jhm
4EPZLsZ9JkGNNavgXWueTp1h1MaPH+Q2zW1fRMCs7omFCLgmeMjpqo5qWjSHN8BQxFdL
tHD9RLQVaXn9K6laBPUeJ5gkIsG1z0QIQDlgRB3+8gKsWObNdDxRN7Gi3fVqFEfPHHgw
Wozg==
X-Gm-Message-State: APjAAAXWyUGkJilWUnxigb4RLE5M1BYtd0Iz/HLE6N2T8wCBzlkDA+Jw
RYtpgB0aCzScOX+JIZuuJMBt5IUiwwKbMRcgwsw=
X-Google-Smtp-Source: APXvYqzFHgTaisVeJbAQ6PmHOHhWYVJ2FY//JmG4Dh8eiH0Ex3QVdqEfBKAUMXrPrs/9JsqCe2hoPe/bT2NWawqeWe4=
X-Received: by 2002:a24:c942:: with SMTP id h63mr22863373itg.128.1555289104477;
Sun, 14 Apr 2019 17:45:04 -0700 (PDT)
MIME-Version: 1.0
References: <CAPfvXf+JS6ZhXUieWVxiaNa4uhhWwafCk3odMKy5F_yi=XwngA@mail.gmail.com>
<816FFA03-B4D9-4ECE-AF15-85ACBFA4BA8F@jonasschnelli.ch>
<CACiOHGxxqm5Qn8J9u5oDE5Ek5smqB4E4iz4PJOZHpJO5kwP=-A@mail.gmail.com>
<CAGLBAhf1NZfT9TunhHAb==mFTfaAacjekQh6Pqn4yBS+90Zw6A@mail.gmail.com>
<20190413190925.peux7djbopy5xu3t@petertodd.org>
In-Reply-To: <20190413190925.peux7djbopy5xu3t@petertodd.org>
From: Dave Scotese <dscotese@litmocracy.com>
Date: Sun, 14 Apr 2019 17:44:51 -0700
Message-ID: <CAGLBAhcAxwWHZz-dLnsGNtu=-0QLv=RNM=V42cD9yRkwKzpj0w@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary="0000000000009873ef058686f643"
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
HTML_MESSAGE,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Mon, 15 Apr 2019 02:05:37 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] assumeutxo and UTXO snapshots
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Apr 2019 00:45:06 -0000
--0000000000009873ef058686f643
Content-Type: text/plain; charset="UTF-8"
No piece of data that does have significance to the Bitcoin consensus can
be memorable because it occurs (about) every ten minutes. In order to get
something memorable to provide sanity (let's say, anti-sybil-attack)
checking, it has to be rare, but recurrent. The opportunity is actually
already there, but it usually goes by without providing the benefits.
For example, I found this blog post
<http://www.righto.com/2014/02/ascii-bernanke-wikileaks-photographs.html>
by Ken Shirriff who describes artifacts that can be found in the
blockchain. These artifacts are not intimately tied to their location in
the blockchain, so anyone building an alternative blockchain can relatively
easily add the artifacts with the same timestamp and at the same height,
masking the counterfeit. In order to prevent that, the memorable thing has
to be intimately tied to work-intensive results, like the ratio of the hash
to the target. Nelson Mandela's image appearing in the blockchain does NOT
prove to me it's the blockchain I can see at blockchain.com right now, but
if the smallest block hash in that blockchain, on 12/13/13, after all the
zeroes, starts with 3da1 (144 * 65536 times as much work) and is one of the
three block hashes from that day that have two occurrences of a double-e
(about 256 times more work), then it will. The problem is that I'll
probably forget most of those details - but not that Mandela's image went
in the blockchain near the end of 2013.
On Sat, Apr 13, 2019 at 12:09 PM Peter Todd <pete@petertodd.org> wrote:
> On Wed, Apr 03, 2019 at 02:39:32PM -0700, Dave Scotese via bitcoin-dev
> wrote:
> > Every block's hash is smaller than the difficulty at that time. Block
> > 569927's hash was VERY small (started with 21 zeros). The ratio of block
> > hash to difficulty requirement (0xffffffff - difficulty, I think) could
> be
> > used to identify blocks as "special," thus providing the opportunity to
> > popularize unimportant but memorable-and-therefore-useful details. How
> can
> > they be useful if they are unimportant? They are useful for sanity
> > checking. For example, if the drunken bishop walk (or some other popular
> > randomart) produced by block 569927's hash looked like a face, that would
> > be memorable: "The block with the smallest hash in 2019 (maybe ever?)
> looks
> > like a face after the drunken bishop walk."
>
> As hashest smaller than the target have no significance to the Bitcoin
> consensus I'd suggest not basing any features on that property. It's just
> as
> arbitrary as picking whole decimal number block heights, yet has the
> additional
> downsides of being harder to compute, and being likely to confuse people
> as to
> how the Bitcoin consensus works.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
--0000000000009873ef058686f643
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>No piece of data that does have significance to the B=
itcoin consensus can be memorable because it occurs (about) every ten minut=
es. In order to get something memorable to provide=20
sanity (let's say, anti-sybil-attack) checking,
it has to be rare, but recurrent.=C2=A0 The opportunity is actually alread=
y there, but it usually goes by without providing the benefits.</div><div><=
br></div><div>For example, I found <a href=3D"http://www.righto.com/2014/02=
/ascii-bernanke-wikileaks-photographs.html">this blog post</a> by Ken Shirr=
iff who describes artifacts that can be found in the blockchain. These arti=
facts are not intimately tied to their location in the blockchain, so anyon=
e building an alternative blockchain can relatively easily add the artifact=
s with the same timestamp and at the same height, masking the counterfeit.=
=C2=A0 In order to prevent that, the memorable thing has to be intimately t=
ied to work-intensive results, like the ratio of the hash to the target.=C2=
=A0 Nelson Mandela's image appearing in the blockchain does NOT prove t=
o me it's the blockchain I can see at <a href=3D"http://blockchain.com"=
>blockchain.com</a> right now, but if the smallest block hash in that block=
chain, on 12/13/13, after all the zeroes, starts with 3da1 (144 * 65536 tim=
es as much work) and is one of the three block hashes from that day that ha=
ve two occurrences of a double-e (about 256 times more work), then it will.=
=C2=A0 The problem is that I'll probably forget most of those details -=
but not that Mandela's image went in the blockchain near the end of 20=
13.</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_att=
r">On Sat, Apr 13, 2019 at 12:09 PM Peter Todd <<a href=3D"mailto:pete@p=
etertodd.org">pete@petertodd.org</a>> wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">On Wed, Apr 03, 2019 at 02:39:32PM -0700, =
Dave Scotese via bitcoin-dev wrote:<br>
> Every block's hash is smaller than the difficulty at that time.=C2=
=A0 Block<br>
> 569927's hash was VERY small (started with 21 zeros).=C2=A0 The ra=
tio of block<br>
> hash to difficulty requirement (0xffffffff - difficulty, I think) coul=
d be<br>
> used to identify blocks as "special," thus providing the opp=
ortunity to<br>
> popularize unimportant but memorable-and-therefore-useful details.=C2=
=A0 How can<br>
> they be useful if they are unimportant?=C2=A0 They are useful for sani=
ty<br>
> checking.=C2=A0 For example, if the drunken bishop walk (or some other=
popular<br>
> randomart) produced by block 569927's hash looked like a face, tha=
t would<br>
> be memorable: "The block with the smallest hash in 2019 (maybe ev=
er?) looks<br>
> like a face after the drunken bishop walk."<br>
<br>
As hashest smaller than the target have no significance to the Bitcoin<br>
consensus I'd suggest not basing any features on that property. It'=
s just as<br>
arbitrary as picking whole decimal number block heights, yet has the additi=
onal<br>
downsides of being harder to compute, and being likely to confuse people as=
to<br>
how the Bitcoin consensus works.<br>
<br>
-- <br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">http=
s://petertodd.org</a> 'peter'[:-1]@<a href=3D"http://petertodd.org"=
rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br>
</blockquote></div><br></div>
--0000000000009873ef058686f643--
|
