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: [email protected]
To: Ignotus Peverell <[email protected]>
[email protected] <[email protected]>
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 : [email protected]
Unsubscribe : https://launchpad.net/~mimblewimble
More help : https://help.launchpad.net/ListHelp
