From: Dave Scotese <dscotese@litmocracy•com>
To: Peter Todd <pete@petertodd•org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] assumeutxo and UTXO snapshots
Date: Sun, 14 Apr 2019 17:44:51 -0700 [thread overview]
Message-ID: <CAGLBAhcAxwWHZz-dLnsGNtu=-0QLv=RNM=V42cD9yRkwKzpj0w@mail.gmail.com> (raw)
In-Reply-To: <20190413190925.peux7djbopy5xu3t@petertodd.org>
[-- Attachment #1: Type: text/plain, Size: 2791 bytes --]
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
>
[-- Attachment #2: Type: text/html, Size: 3453 bytes --]
next prev parent reply other threads:[~2019-04-15 0:45 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-02 20:43 James O'Beirne
2019-04-03 6:37 ` Jonas Schnelli
2019-04-03 15:39 ` Ethan Scruples
2019-04-03 21:39 ` Dave Scotese
2019-04-04 3:01 ` Luke Dashjr
2019-04-04 5:59 ` Jim Posen
2019-04-04 14:36 ` James O'Beirne
2019-04-13 19:09 ` Peter Todd
2019-04-15 0:44 ` Dave Scotese [this message]
2019-04-04 2:48 ` Luke Dashjr
2019-04-04 3:04 ` Ethan Scruples
2019-04-03 19:51 ` James O'Beirne
2019-04-03 9:55 ` Luke Dashjr
2019-04-03 23:03 ` Jim Posen
2019-04-14 13:16 ` Omar Shibli
2019-04-23 14:17 ` James O'Beirne
[not found] <mailman.2593.1554248572.29810.bitcoin-dev@lists.linuxfoundation.org>
2019-04-03 7:51 ` Nicolas Dorier
2019-04-04 10:27 ` Kulpreet Singh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAGLBAhcAxwWHZz-dLnsGNtu=-0QLv=RNM=V42cD9yRkwKzpj0w@mail.gmail.com' \
--to=dscotese@litmocracy$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pete@petertodd$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox