Hi Igno (and list):
Really cool to see this specification getting fleshed out!
I have mixed feelings about the full node mode. While archival is desirable for
later checks (included from new nodes), we would get stronger privacy
guarantees if cut-through still happened on full nodes. I think the "right to
be forgotten" is an important part of the design. Any strong opinion either way?
I agree with your preference for the "right to be forgotten". However, given
that: 1) there can be no guarantee that a custom node is not recording
transactions in full since genesis and 2) full block sync may be an important
fallback under adversarial conditions, I'm not sure it would be possible to
exclude this functionality completely in the default node implementation. I do
think it makes sense to take reasonable measures to prevent or actively
obfuscate this full history from being maintained and easily exported from the
node, however.
Re: the spec itself:
At a high level, I really like the partial history sync to facilitate
bootstrapping. If bootstrapping can be extremely fast and still very secure,
that opens up the possibility for extremely light applications throughout the
ecosystem, from wallets to short-lived web applications, that don't sacrifice
much of the security model.
As someone new to the project, I feel like one piece of context I'm missing is
the form of the cut-through blocks themselves. From glancing at the pruning doc
and the mimblewimble spec, my guess is that the cut-through block would contain
all the block headers, plus the abridged utxo set. Is this an accurate
assumption?
Another question I have is with regards to the interaction between the moving
horizon and discarding block history via cut-through. Given the example from
the doc:
> The new node also has prior knowledge of the genesis block. It connects to
> other peers and learns about the head of the most worked chain. It asks for
> the block header at the horizon block, requiring peer agreement. If consensus
> is not reached at h = H - Z, the node gradually increases the horizon Z,
> moving h backward until consensus is reached. Then it gets the full UTXO set
> at the horizon block.
If most (if not all) of the nodes on the network are pruning their history, it
seems like there would be an upper bound of the horizon Z- a node with pruned
history at horizon Z cannot provide a cut-through block at Z' > Z, nor can it
provide the full history. Even if the node's internal cut-through horizon is
many multiples greater than the bootstrapping horizon, there is still an
effective minimum height that this peer can bootstrap back to given any
disagreement. Additionally, even if some nodes are full nodes which are capable
of providing full history, as written it seems necessary to consider the sybil
attack probability as the likelihood of an attacker controlling all the full
nodes the peer is connected to, which may be significantly easier than a
generalized sybil attack (depending on the ratio of pruning nodes to full
nodes).
My first thought is: How much does this actually matter? Assuming that the
block headers are included in the cut-through block, proof of work is
validated, and the longest/valid chain is determined by total work, forging an
entirely invalid cut-through block from genesis would require at the minimum
the same amount of total work as the valid chain has accumulated thus far. An
adversary could build on top of the valid chain, perhaps adding a handful of
"difficulty adjustment" blocks with forged timestamps to drive down the
difficulty, but the total work of the forged chain would still need to exceed
that of the main chain to be deemed valid. Given this, does it make sense to
amend the spec to seek more peers and go with the majority agreement chain with
the most work, rather than push back the horizon? That removes the requirement
for a significant number of non-pruning peers in the network, which helps your
"right to be forgotten" point from your email.
-MW
--
Mailing list: https://launchpad.net/~mimblewimble
Post to : mimblewimble@lists.launchpad.net
Unsubscribe : https://launchpad.net/~mimblewimble
More help : https://help.launchpad.net/ListHelp
