mimblewimble team mailing list archive

[Andrew Poelstra <apoelstra@xxxxxxxxxxxxxx>]

On Tue, Jan 10, 2017 at 06:55:33PM -0500, Myrtle Warren wrote:
> 
> What becomes increasingly tricky to reason about is that we now have a 2x2 matrix of capabilities. On one axis, we have full vs partial header verification; on the other, we have full vs partial UTXO history (whether to perform cut-through). Nodes of the set (partial, partial) have extremely limited utility bootstrapping other nodes as they do not present byzantine fault-tolerance (they become incapable of proving their validity past a certain point) and cannot fork past the cut-through horizon on their own, nor can they assist other nodes in doing so. Nodes of the (full [headers], partial [utxo]) capability set can prove work but again cannot provide history assistance for forking. Nodes of the (full, full) capability set can provide both forking and bootstrapping support to other nodes. (I'm not sure the (partial, full) case makes any sense so I'm leaving it out here).
>

Nodes that do cut-through are still able to bootstrap other nodes. Once a block's full data has been dropped it is never needed again.

There is no need to keep old full block data except to make reorgs past those blocks more efficient (as they can be rewound instead of requiring a full re-sync).

> 
> Given the complexity of the 2x2 grid and its repercussions for thinking of the defensibility of grin, perhaps it makes sense to leave the partial headers sync as a potential future improvement. It seems that its security model depends on a relatively mature coin of sufficient active and sustained hashpower to resist short-term rewriting of history.
>

I agree with this.
 
> Regarding cut-through of the UTXO set on full nodes (basically doing away with the (full, full) configuration), I'm torn. Given 2), it seems logical to build towards a significant population of pruning nodes. However, doing so does have some repercussions on the ability of nodes to recover from forks. If the vast majority of the network obeys an internal cut-through horizon, even if that horizon is extremely conservative, the network will have difficulty forking past this horizon- you are forced to rely on a small portion of full, history-maintaining nodes to help inform you of the fork. If you make it a rule that nodes should not fork past the most conservative horizon, you've introduced a de-facto checkpoint: a new node bootstrapping might have a different answer about the current chain than a node at steady-state, if the most-worked chain involved a fork from before this conservative horizon.
>

You don't need full, history-maintaining nodes. If somebody forks the network they are then responsible for IBD'ing other peers, who will then be able to IBD other peers.

Having full blocks means you can shortcut this a bit by rewind-and-play-forward rather than doing a full IBD. It's purely for efficiency.

Actually pruning, as in dropping entire blocks, does have this problem of course.

> I tend to err on the side of practicality personally, so my preference would probably be to accept that a valid, extremely long fork (on the order of 6 months or more) would represent severe economic issues beyond just the engineering challenges of handling a long fork. I would also err on the side of not including explicit checkpoints in the code, as IMHO that raises questions about the role of developers (given that a different checkpoint could force new nodes on a lesser-worked chain). I think you can arrive at a fairly reasonable solution that is extremely conservative with its first cut-through horizon and uses some system of leveled compaction in order to cut through progressively larger chunks of blocks as blocks are buried further in history.
>

Checkpointing like this either has no effect on consensus or a bad one. I agree that we may want checkpoints, though far enough back to get into the "no effect" arena, for efficiency. (Bitcoin does this to prevent certain DoS attacks during IBD; I think we have an even stronger case for doing this.)


-- 
Andrew Poelstra
Mathematics Department, Blockstream
Email: apoelstra at wpsoftware.net
Web:   https://www.wpsoftware.net/andrew

"A goose alone, I suppose, can know the loneliness of geese
 who can never find their peace,
 whether north or south or west or east"
       --Joanna Newsom

Attachment: signature.asc
Description: PGP signature