mimblewimble team mailing list archive

[Ignotus Peverell <igno.peverell@xxxxxxxxxxxxxx>]

Dear Gellert,

I agree on all points. I'll just add that the choice on the horizon length may not be as crucial as you think given that the node will back-track anyway and that this process should be fairly fast (only requiring a block header from each peer).

- Igno


-------- Original Message --------
Subject: Re: [Mimblewimble] Chain syncing spec
Local Time: January 5, 2017 6:22 AM
UTC Time: January 5, 2017 2:22 PM
From: grindelwald@xxxxxxxxxxx
To: mimblewimble@xxxxxxxxxxxxxxxxxxx

> Greetings Gellert Grindelwald,
>
> Thank you for the reading and the review. The attack you described is
> definitely something that comes to mind as a potential danger but it would
> require to both have a partial rewrite of the chain *and* a full sybil
> attack (where the attacker controls all the peers the new node is
> connected to). Pretty much all cryptocurrencies are vulnerable to a full
> sybil attack, including bitcoin, so it's not something I consider
> acceptable udner our security model.
>
> To elaborate, when a new node joins the network it does the following:
>
> - Connect to a certain number of peers (typically 6 to 10).
>
> - Ask for the latest head H.
>
> - Ask *all* peers for the horizon block header at h=H-O.
>
> - Check for consensus among *all* peers it's connected to on h.
>
>
>
> At this latest step, under the attack you describe, the new node would
> detect the attacker's fork. Not knowing which header to believe, it
> backtracks, increasing O until reaching agreement between all its peers.
>
> - Igno
>

Yeah basically worst case scenario in the full sybil attack scenario is
the bootstrapping node has a forged history of the chain which is pretty
disastrous but unlikely to occur in a mature decentralized network.

Best case scenario where only a couple peers are malicious this is a DoS
attack that forces the node to constantly keep back-tracking for consensus
among peers on a block. Once consensus is found on a block then banning
the peer who is DoSing would be warranted. I think if we gave the block
horizon a one month(or larger) period this would largely thwart any major
threat of adversaries being able to take advantage of the full sybil
scenario while still addressing the DoS attack which will always be
possible to a certain extent. This is under the assumption the network has
a strong hashrate and a one month block horizon is completely unreasonable
to rewrite from a work perspective.

Having pruned nodes only connect to full nodes for syncing past blocks
would make this attack disappear, forcing the attacker to completely
rewrite the blockchain history rather than just H - Z blocks, but as full
nodes go out of favour for pruned nodes this solution is not really
sustainable long term and bolsters the strength of the aforementioned full
sybil attack when full nodes with the entire chain history is scarce.
Choosing the length of the block horizon will be crucial to the security
of the network.

-Gellert



--
Mailing list: https://launchpad.net/~mimblewimble
Post to : mimblewimble@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~mimblewimble
More help : https://help.launchpad.net/ListHelp