From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 1469B898 for ; 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 ; Mon, 15 Apr 2019 00:45:05 +0000 (UTC) Received: by mail-it1-f170.google.com with SMTP id f22so24103908ita.3 for ; 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: <816FFA03-B4D9-4ECE-AF15-85ACBFA4BA8F@jonasschnelli.ch> <20190413190925.peux7djbopy5xu3t@petertodd.org> In-Reply-To: <20190413190925.peux7djbopy5xu3t@petertodd.org> From: Dave Scotese Date: Sun, 14 Apr 2019 17:44:51 -0700 Message-ID: To: Peter Todd 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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
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.
<= br>
For example, I found this blog post 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 blockchain.com 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.

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.=C2= =A0 Block
> 569927's hash was VERY small (started with 21 zeros).=C2=A0 The ra= tio of block
> hash to difficulty requirement (0xffffffff - difficulty, I think) coul= d be
> used to identify blocks as "special," thus providing the opp= ortunity to
> popularize unimportant but memorable-and-therefore-useful details.=C2= =A0 How can
> they be useful if they are unimportant?=C2=A0 They are useful for sani= ty
> checking.=C2=A0 For example, if the drunken bishop walk (or some other= popular
> randomart) produced by block 569927's hash looked like a face, tha= t would
> be memorable: "The block with the smallest hash in 2019 (maybe ev= er?) 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 additi= onal
downsides of being harder to compute, and being likely to confuse people as= to
how the Bitcoin consensus works.

--
http= s://petertodd.org 'peter'[:-1]@petertodd.org

--0000000000009873ef058686f643--