mimblewimble team mailing list archive

["Gellert Grindelwald" <grindelwald@xxxxxxxxxxx>]

> 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