mimblewimble team mailing list archive

[Andrew Poelstra <apoelstra@xxxxxxxxxxxxxx>]

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

I really don't like this "horizon" model. It has been suggested for Bitcoin many times and leads to an "incentive cliff" where rewriting past the horizon is as good as rewriting the entire chain. You suggest that a node will scan further back if it "can't reach consensus" at a given horizon, but I don't understand what this means? 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?

At best this seems very hard to analyze. At worst it leads to DoS attacks, it seems like you can trick a node into rewriting its history, trick it into downloading and fully validating every block by conflicting at decreasing heights, and probably other things I'm not thinking of. You're modifying the highest-work rule for selecting a consensus chain in a very unclear way.


The point of MimbleWimble is that given only:

 1. The entire chain of headers and excess values
 2. The UTXO set

you can do a full validation, up to splitting and combining of UTXOs, and you can't determine the age of UTXOs.


This proposal appears to drop (1), which will be a comparatively small amount of data (in Bitcoin, 15Gb vs 100Gb for the UTXO set) even without Schnorr aggregation or anything else which I think will save another 33% or so on it, and does so in exchange for a dramatic weakening of the MW security model and its comprehensibility. 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.



Andrew



On Mon, Jan 02, 2017 at 06:04:17PM -0500, Ignotus Peverell wrote:
> 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


-- 
Andrew Poelstra
Mathematics Department, Blockstream
Email: apoelstra at wpsoftware.net
Web:   https://www.wpsoftware.net/andrew

"A goose alone, I suppose, can know the loneliness of geese
 who can never find their peace,
 whether north or south or west or east"
       --Joanna Newsom

Attachment: signature.asc
Description: PGP signature