mimblewimble team mailing list archive

[Ignotus Peverell <igno.peverell@xxxxxxxxxxxxxx>]

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


-------- Original Message --------
Subject: Re: [Mimblewimble] Chain syncing spec
Local Time: January 4, 2017 3:28 AM
UTC Time: January 4, 2017 11:28 AM
From: grindelwald@xxxxxxxxxxx
To: mimblewimble@xxxxxxxxxxxxxxxxxxx

> Hi all,
>
> Hope everyone had great holidays and is enjoying the new year so far. I
> wrote up a first description of the chain syncing algos we may use and I'd
> love reviews and feedback:
>
> https://github.com/ignopeverell/grin/blob/master/doc/chainsync.md
>
> 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?
>
> Thanks,
> Igno--
> Mailing list: https://launchpad.net/~mimblewimble
> Post to : mimblewimble@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~mimblewimble
> More help : https://help.launchpad.net/ListHelp
>

Greetings Ignotus Peverell,

The described chain sync document would certainly aid in the rate which
new nodes can be synced to the head block in the network, but would the
immutablity of the chain not be dependent on how large the block horizon
is? If I understand correctly, say an adversary wants to rewrite the
blockchain instead of forking from genesis they would only need to fork at
H - Z block and rewrite history from there. Since nodes are only concerned
with H - Z blocks this makes the block history much more trivial to
rewrite. For this to be an adequate solution we would need to determine
how large of a block horizon would be deemed safe and "unattackable" from
an adversial standpoint. Feel free to correct me if I am misunderstanding
something here.

Regards,
Gellert Grindelwald



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