← Back to team overview

mimblewimble team mailing list archive

Re: Chain syncing spec

 

Hi Myrtle,

Thanks a lot for the review and the thoughtful reply! I'm overdue on a writeup about the main concepts of MimbleWimble and how they apply to Grin, including block and transaction formats. That would likely simplify the reading of the block sync doc as well as others.

The cut-through block is a concept. Practically it's a block header as well as the full UTXO set (and accompanying data, like tx signatures) matching that block. But it doesn't need to ever be fully materialized. Another useful piece of information is that the total difficulty up to a given block is present in every block header. So once fully synced, a node can make informed decisions on new forks and their respective work.

You are correct that a node with horizon O cannot help another node with horizon O' > O for bootstrap. Practically that shouldn't be much of an issue as long as running nodes keep their horizons longer than the default one used for initial syncing. And full nodes can help any node bootstrap, at any horizon. So for the purpose of finding nodes to sync with, this scheme should behave even better than Bitcoin SPV.


As far as syncing all block headers, I'd like to start with the assumption that we can do without them and see if any serious attack vector can be formulated. It seems that a fair amount of cryptographic optimization can be made on both signatures (sinking-type) and range proof, which would make header size more significant. As I mentioned, all current blockchains are sensitive to sybil attacks (even local). So my preference would be to try a little harder to do without headers before giving up.

Another alternative would be to also embed compact proofs, similarly to what Andrew Poelstra uses in his paper [1] or the "Proofs of Proofs" paper [2] but both add significant complexity.

Let's try to push hard for privacy, fungibility and scalability while keeping everything as simple as possible!

- Igno

[1] https://download.wpsoftware.net/bitcoin/wizardry/mimblewimble.pdf
[2] http://fc16.ifca.ai/bitcoin/papers/KLS16.pdf


-------- Original Message --------
Subject: Re: [Mimblewimble] Chain syncing spec
Local Time: January 4, 2017 1:48 PM
UTC Time: January 4, 2017 9:48 PM
From: MoaningMyrtle@xxxxxxxxxxxxxx
To: Ignotus Peverell <igno.peverell@xxxxxxxxxxxxxx>
mimblewimble@xxxxxxxxxxxxxxxxxxx <mimblewimble@xxxxxxxxxxxxxxxxxxx>

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

References