From: Dave Scotese <dscotese@litmocracy.com>
To: Damian Williamson <willtech@live.com.au>
Cc: "bitcoin-dev@lists.linuxfoundation.org"
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [bitcoin-discuss] Checkpoints in the Blockchain.
Date: Mon, 21 May 2018 13:03:37 -0700 [thread overview]
Message-ID: <CAGLBAhcJLavbU+HVi2T+42xEAMGRfoMBJH_sU52YLzmJrn+iTw@mail.gmail.com> (raw)
In-Reply-To: <PS2P216MB01792E0070D82D4E155EDC139D960@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
[-- Attachment #1: Type: text/plain, Size: 12732 bytes --]
Our wetware memory is faulty at details, but a rendering that provides
features at which it isn't faulty makes it a decent backup in situations
where technology has been used to hide important differences from us. Some
of us may recall being in a situation where something seems off, and we
start to investigate, and then we discover that something was off. April
Fools jokes are good examples, as well as satire and news reports from The
Onion.
The point of storing the entire blockchain history is to prevent any of
that history being changed in a way that illicitly alters the UTXO Set.
Whenever a memorable enough rendering of the UTXO Set is produced (which
has happened exactly once - when Bitcoin started, it was empty, and after
that, it just looks like a bunch of random computer data), the risk of
altering the history before it goes up, even if you have the computing
power to make subsequent block headers follow all the rules (and even to
successfully execute a 51% attack!). In this announcement
<http://lists.mindrot.org/pipermail/openssh-unix-dev/2008-July/026693.html>,
the first item under "new features" has this, which follows the same
principle as my idea:
Introduce experimental SSH Fingerprint ASCII Visualisation to ssh(1) and
> ssh-keygen(1). Visual fingerprinnt display is controlled by a new
> ssh_config(5) option "VisualHostKey". The intent is to render SSH host keys
> in a visual form that is amenable to easy recall and rejection of changed
> host keys. This technique inspired by the graphical hash visualisation
> schemes known as "random art[*]", and by Dan Kaminsky's musings at 23C3 in
> Berlin.
>
On Sat, May 19, 2018 at 10:12 PM, Damian Williamson <willtech@live.com.au>
wrote:
> I do understand your point, however, 'something like stuxnet' cannot be
> used to create valid data without re-doing all the PoW. Provided some valid
> copies of the blockchain continue to exist, the network can re-synchronise.
>
>
> Unrelated, it would seem useful to have some kind of deep blockchain
> corruption recovery mechanism if it does not exist; where blocks are
> altered at a depth exceeding the re-scan on init, efficient recovery is
> possible *on detection*. Presumably, it would be possible for some
> stuxnet like thing to modify blocks by modifying the table data making
> blocks invalid but without causing a table corruption. I would also suppose
> that if the node is delving deep into the blockchain for transaction data,
> that is would also validate the block at least that it has a valid hash
> (apart from Merkle tree validation for the individual transaction?) and
> that the hash of its immediate ancestor is also valid.
>
>
> Regards,
>
> Damian Williamson
>
>
> ------------------------------
> *From:* bitcoin-discuss-bounces@lists.linuxfoundation.org <
> bitcoin-discuss-bounces@lists.linuxfoundation.org> on behalf of Dave
> Scotese via bitcoin-discuss <bitcoin-discuss@lists.linuxfoundation.org>
> *Sent:* Sunday, 20 May 2018 11:58 AM
> *To:* Scott Roberts
> *Cc:* Bitcoin Discuss
> *Subject:* Re: [bitcoin-discuss] Checkpoints in the Blockchain.
>
> I wouldn't limit my rendering to words, but that is a decent starting
> point. The richer the rendering, the harder it will be to forget, but it
> needn't all be developed at once. My goal here is to inspire the creation
> of art that is, at the same time, highly useful and based on randomness.
>
> Anyway, I asked what "premise that this is needed" you meant and I still
> don't know the answer.
>
> "The archive is a shared memory" - yes, a shared *computer* memory, and
> growing larger (ie more cumbersome) every day. If something like stuxnet is
> used to change a lot of the copies of it at some point, it seems likely
> that people will notice a change, but which history is correct won't be so
> obvious because for the *humans* whose memories are not so easily
> overwritten, computer data is remarkably non-memorable in it's normal form
> (0-9,a-f, whatever). If we ever want to abandon the historical transaction
> data, having a shared memory of the state of a recent UTXO Set will help to
> obviate the need for it. Yes, of course the blockchain is the perfect
> solution, as long as there is *exactly one* and everyone can see that
> it's the same one that everyone else sees. Any other number of archives
> presents a great difficulty.
>
> In that scenario, there's no other way to prove that the starting point is
> valid. Bitcoin has included a hardcoded-checkpoint in the code which
> served the same purpose, but this ignores the possibility that two versions
> of the code could be created, one with a fake checkpoint that is useful to
> a powerful attacker. If the checkpoint were rendered into something
> memorable at the first opportunity, there would be little question about
> which one is correct when the difference is discovered.
>
> On Sat, May 19, 2018 at 5:22 PM, Scott Roberts <wordsgalore@gmail.com>
> wrote:
>
> I just don't see the point of needing to know it any different from the
> hex value. Or maybe I should say I can't imagine it being useful because I
> can't imagine what you're after is possible. There might be a theoretical
> proof that what you're after is impossible. Hard to forget is almost the
> opposite of many options and what we're trying to do is decide between many
> options. I'll assume English because it's the only starting point I have
> that's even in the ballpark of being possible. You might need to constrain
> the word selection and the structure in which you put it. I can only
> imagine that you are talking about putting the words into some sort of
> story. The only kind of story that would be hard to forget is one that
> fits into an overall structure that we are familiar with but those types of
> structures are few compared to the possibilities that we're trying to
> encode. "Hard to deny" is a type of "hard to forget". Besides trying to
> connect it to external reality or history that we can all agree on there is
> also an internal consistency that could be used like a checksum such as the
> structure I mentioned. The only thing that seems to fit the bill is the
> blockchain itself. It's on everyone's computer so it's impossible to forget
> and it has internal consistency. Is the only shared memory we have that
> can't be subject to a Sybil attack or other hijacking of our memory of the
> true history. Our translation of the hash into words and a story could
> potentially be subject to hijacking if it's not done perfectly correct. It
> just seems best to me to use the hash itself. They archived existence of
> the prior parts of the blockchain are what make that particular hash hard
> to forget. Supposedly it can't be forged to reference a fake history. The
> archive is a shared memory that fits the encoding rules.
>
> On Sat, May 19, 2018, 4:30 PM Dave Scotese <dscotese@litmocracy.com>
> wrote:
>
> Did you mean the premise that we have "the need to retain the full
> blockchain in order to validate the UTXO Set"?
>
> I hadn't thought of just making it *easier* to remember, as your
> suggestion does (12-13 words), and that's a great idea. I have passphrases
> of that kind, but I noticed a kind of mandela effect
> <https://www.snopes.com/news/2016/07/24/the-mandela-effect/> just with
> myself. For example, I one of the words I chose was like "olfactory" but
> after a few months, what I remembered was like "ontology". The solution I
> came up with is to couple the data with far more items than we normally
> do. Every ten minutes, we get a new set of 256 bits that can be used to
> create something potential *very difficult* to forget, and that's what
> I'm after.
>
> An algorithm could be used to do this with the Bip39 word list. If we
> categorized the words according to parts of speech, the bits could be used
> to determine which word goes next in a kind of ad-lib, but this creates a
> phrase that is only memorable in the language for which the algorithm is
> developed. As a thought experiment, I'll try adjective noun verb(as past
> tense) noun preposition adjective adjective noun: Stuff would come out like
> "Able abstract abused accident across actual adult affair." not memorable
> at all, but sense can be made of it and sometimes the sense will be
> remarkable. As it is, I will have forgotten it in an hour or two.
>
> On Thu, May 17, 2018 at 4:29 PM, Scott Roberts <wordsgalore@gmail.com>
> wrote:
>
> I disagree with your premise that this is needed, I like the question.
> Humans are experts at language and I don't think we have another repository
> at hand that we can categorize for memory that is better than words. Using
> words is a common way of doing what you're thinking about. If the
> checkpoint could be a hash that meets a difficulty target the possibilities
> are 2^182 at the current hashrate instead of 2^256. So we need only 12 or
> 13 common words with their various possible endings (30,000). I would find
> it easier to insert a letter and 3 numbers after every 2 words so there
> would be only 8 words used. There are probably other tricks people have
> figured out but there can't be any kind of advanced encoding because it
> wouldn't benefit more than one word. There might be a way to convert the
> words into something that almost sounds like English sentences but it would
> probably come out a cost of at least doubling the number of words.
>
> On Thu, May 17, 2018, 12:13 PM Dave Scotese via bitcoin-discuss <
> bitcoin-discuss@lists.linuxfoundation.org> wrote:
>
> I got the idea that a SHA256 hash could be rendered into something
> difficult to forget. The rendering would involve using each of the 256
> bits to specify something important about the rendering - important in an
> instinctive human-memory way.
>
> Let's assume such a rendering is possible, and that at any time, any
> person can execute the rendering against the SHA256 hash of a consistent
> representation of the UTXO Set. Sometimes, someone will execute the
> rendering and discover that it is remarkable in some way (making it even
> more memorable), and therefore will publish it.
>
> The published, memorable rendering now becomes a kind of protection
> against any possible re-writing of the blockchain from any point prior to
> that UTXO Set. When everyone involved in Bitcoin recognizes this
> protection, it relieves us of the need to retain the full blockchain in
> order to validate the UTXO Set at that point, because enough people will
> recognize it, and it can be validated without reference to any kind of
> prior computer record.
>
> This does leave open the possibility that an attacker could create a more
> favorable UTXO Set that happens to have a rendering similar enough to fool
> people, or one that has exactly the same SHA256-hash, but that possibility
> is remote enough to ignore (just as we all ignore the possibility that
> whatever creates the master seed for our HD wallet will create a unique
> master seed).
>
> I've been working on how such a rendering could happen. It could describe
> music, characters, colors, plot points, memorable elements of characters,
> etc.
>
> Dave Scotese
>
> _______________________________________________
> bitcoin-discuss mailing list
> bitcoin-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-discuss
>
>
>
>
> --
> I like to provide some work at no charge to prove my value. Do you need a
> techie?
> I own Litmocracy <http://www.litmocracy.com> and Meme Racing
> <http://www.memeracing.net> (in alpha).
> I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com>
> which now accepts Bitcoin.
> I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
> "He ought to find it more profitable to play by the rules" - Satoshi
> Nakamoto
>
>
>
>
> --
> I like to provide some work at no charge to prove my value. Do you need a
> techie?
> I own Litmocracy <http://www.litmocracy.com> and Meme Racing
> <http://www.memeracing.net> (in alpha).
> I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com>
> which now accepts Bitcoin.
> I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
> "He ought to find it more profitable to play by the rules" - Satoshi
> Nakamoto
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
[-- Attachment #2: Type: text/html, Size: 19188 bytes --]
prev parent reply other threads:[~2018-05-21 20:03 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAGLBAhc6KoRNj-UB+Zo6D6NL-DcL++MM-qMMarTCOKjYLB_bPg@mail.gmail.com>
[not found] ` <CADtTMvnNTkWWwGw7_u5cvTf28LEKhxcRHb_n5qctf3oLidh=ng@mail.gmail.com>
[not found] ` <CAGLBAhfzrv5CD+ohEcQGXC=WzGs58+_UwaHup-e-rs-1WaFxug@mail.gmail.com>
[not found] ` <CADtTMv=tjQiaSDu5zMzHpmt_EX5Ku+RSrQAGOywA3S16sj78yQ@mail.gmail.com>
[not found] ` <CAGLBAhcBPJFEidtNA0UDva-=_0e5Zn0400O9i2nwV3W4HkWnfg@mail.gmail.com>
2018-05-20 5:12 ` [bitcoin-dev] [bitcoin-discuss] Checkpoints in the Blockchain Damian Williamson
2018-05-21 20:03 ` Dave Scotese [this message]
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=CAGLBAhcJLavbU+HVi2T+42xEAMGRfoMBJH_sU52YLzmJrn+iTw@mail.gmail.com \
--to=dscotese@litmocracy.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=willtech@live.com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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