← Back to team overview

mimblewimble team mailing list archive

Re: Chain syncing spec

 

I'm just getting to this, a week late.

Never too late, especially when no syncing code has been written yet :)


I really don't like this "horizon" model.

There is some "horizon" model inherent to MW that you're ignoring: as of when does one get the full UTXO set? If you get it at block (head-100), what if there's a valid fork at (head-110)? There's some inherent complication in the security model there.


What does a node do in the presence of multiple forks who disagree at the horizon, but which have different total difficulties? How long after a node has made a decision on the real chain can this be modified?

In the presence of multiple forks a node backtracks, in the extreme case leading to what you suggest: the full header history.


At best this seems very hard to analyze. At worst it leads to DoS attacks

That's the argument I'm the most sympathetic to: it's harder to analyze. I'm still questioning whether it's worth it or not.

But even bitcoin's security model relies strongly on incentives. So if you're willing to spend 2 weeks worth of proof of work (for example) faster than the rest of the chain just to make new nodes fail bootstrapping, why not just do a 51% attack that can work immediately and gives you a lot more control?


it seems like you can trick a node into rewriting its history

No, not after bootstrap.


trick it into downloading and fully validating every block by conflicting at decreasing heights,

Not without proving more and more work, especially after a successful bootstrap.


In fact if the proposed security model is ok, I don't know what the point of MW is at all, you can just fork Bitcoin, add a horizon and magic "can't reach consensus" rule, and you'll get the same security model without so much research and development.

Now you're getting glib :D

I agree however that the security model becomes a little less clear and that may not be something we want as a default from the start but more something we can explore later on. However I'll make a couple more points:

- We're discussing the "limited history" mode right now, there's still a full node mode. I did ask in my first email whether we should have full nodes also do cut-through.

- I think the UTXO horizon is just as tricky as the header horizon: it's not as well understood and the DoS vectors could have more repercussion in terms of traffic.


And as always, thanks a lot for the review and analysis!

- Igno

Follow ups

References