Re: [bitcoin-dev] [bitcoin-discuss] Checkpoints in the Blockchain.

[Dave Scotese via bitcoin-dev]

 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
,
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 
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-boun...@lists.linuxfoundation.org <
> bitcoin-discuss-boun...@lists.linuxfoundation.org> on behalf of Dave
> Scotese via bitcoin-discuss 
> *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 
> wrote:
>
> I just don't see the point of 

Re: [bitcoin-dev] [bitcoin-discuss] Checkpoints in the Blockchain.

[Damian Williamson via bitcoin-dev]

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-boun...@lists.linuxfoundation.org 
 on behalf of Dave Scotese 
via bitcoin-discuss 
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 
> 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