mimblewimble team mailing list archive

[Myrtle Warren <MoaningMyrtle@xxxxxxxxxxxxxx>]

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