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 

Re: [bitcoin-dev] Making OP_TRUE standard?

[Peter Todd via bitcoin-dev]

On Mon, May 21, 2018 at 01:14:06PM +0930, Rusty Russell via bitcoin-dev wrote:
> Jim Posen  writes:
> > I believe OP_CSV with a relative locktime of 0 could be used to enforce RBF
> > on the spending tx?
> 
> Marco points out that if the parent is RBF, this child inherits it, so
> we're actually good here.
> 
> However, Matt Corallo points out that you can block RBF will a
> large-but-lowball tx, as BIP 125 points out:
> 
>will be replaced by a new transaction...:
> 
>3. The replacement transaction pays an absolute fee of at least the sum
>   paid by the original transactions.
> 
> I understand implementing a single mempool requires these kind of
> up-front decisions on which tx is "better", but I wonder about the
> consequences of dropping this heuristic?  Peter?

We've discussed this before: that rule prevents bandwidth usage DoS attacks on
the mempool; it's not a "heuristic". If you drop it, an attacker can repeatedly
broadcast and replace a series of transactions to use up tx relay bandwidth for
significantly lower cost than otherwise.

Though these days with relatively high minimum fees that may not matter.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Making OP_TRUE standard?

[Rusty Russell via bitcoin-dev]

Jim Posen  writes:
> I believe OP_CSV with a relative locktime of 0 could be used to enforce RBF
> on the spending tx?

Marco points out that if the parent is RBF, this child inherits it, so
we're actually good here.

However, Matt Corallo points out that you can block RBF will a
large-but-lowball tx, as BIP 125 points out:

   will be replaced by a new transaction...:

   3. The replacement transaction pays an absolute fee of at least the sum
  paid by the original transactions.

I understand implementing a single mempool requires these kind of
up-front decisions on which tx is "better", but I wonder about the
consequences of dropping this heuristic?  Peter?

Thanks!
Rusty.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev