mimblewimble team mailing list archive

[Ignotus Peverell <igno.peverell@xxxxxxxxxxxxxx>]

> > There is a denial-of-service option when a user downloads the chain,
> > the peer can give gigabytes of data and list the wrong unspent outputs.
> > The user will see that the result do not add up to 0, but cannot tell where
> > the problem is.

> which to be honest I do not quite understand. The user normally downloads
> the chain by requesting blocks from peers, starting with just the headers
> which can be checked for proof-of-work.

The paper here refers to the MimbleWimble-style fast sync (IBD), where you only get the block headers, the UTXO set with their range proofs and the kernels. You can validate the whole thing without getting the full history with an almost identical security model. In fast sync you don't get any actual block (practically you still want some recent history in case of reorg but let's gloss over that for now). This is actually one of the main attractions of MW, as you can make IBD very efficient this way.

First, the DoS angle mentioned in the paper isn't nearly at the top of the list of what gives me more grey hair. Download bandwidth is usually higher and cheaper than upload, so the attacker would incur non-negligible cost. You can also force-switch peer if it's too slow. And it's worth noting that no matter what, you definitely know you've been lied to. It's also a DoS angle that's limited in time and place, unlike say a spam attack that would impact everyone, potentially forever.

Second, the paper makes minimal assumptions about what the rest of the chain looks like. It turns out that in Grin we have Merkle-like trees (Merkle Mountain Ranges) that are reasonably compact and commit to the TXO set as well as the kernels. So we can definitely implement a more incremental IDB mode that gets the headers first (just like now), then the trees, then stream the UTXOs and kernels making sure each of them are present in the trees and there are no extras.

There's still one rather subtle way an attacker could be obnoxious, even with the incremental IBD. I'll leave that as an exercise to the reader, but it'd be fairly straightforward to fix as well if it became a problem, by committing to a (very small) UTXO bitset.

- Igno

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On 8 March 2018 4:17 PM, John Tromp john.tromp@xxxxxxxxx wrote:

> hi Luke,
> 
> > current crypto-currencies with the exception of monero are based
> > 
> > around the principle of hiding... so of course they are being hunted
> > 
> > and hounded. monero and i believe grin-coin at least provide both
> > 
> > privacy and traceability, such that an individual may prove to
> > 
> > their local tax authorities that yes they accepted the transaction,
> > 
> > but that they can also prove that the transaction was completed
> > 
> > outside of their jurisdiction.
> 
> Are you talking about transactions that the user reports to the authorities
> 
> in the first place? In that case the user would simply not report transactions
> 
> that are "inside the jurisdiction", whatever that means.
> 
> > in reading the mimblewimble whitepaper i noticed that it said that
> > 
> > spammers can carry out a denial-of-service attack by flooding the
> > 
> > network with "wrong unspent outputs". the proposed solution was to
> > 
> > download the blockchain from a torrent or from multiple users.
> 
> The whitepaper at
> 
> https://download.wpsoftware.net/bitcoin/wizardry/mimblewimble.txt has
> 
> this paragraph:
> 
> 3\. There is a denial-of-service option when a user downloads the
> 
> chain, the peer can give
> 
> gigabytes of data and list the wrong unspent outputs. The user will
> 
> see that the result
> 
> do not add up to 0, but cannot tell where the problem is.
> 
> which to be honest I do not quite understand. The user normally
> 
> downloads the chain
> 
> by requesting blocks from peers, starting with just the headers which
> 
> can be checked for proof-of-work.
> 
> Having identified the chain of headers with the most work (cumulative
> 
> difficulty), the user then requests
> 
> the full blocks one or a few at a time. If any of them have bad data,
> 
> then the user would reject them,
> 
> and ban the peer that provided it with the bad block. I don't see how
> 
> the user would receive "gigabytes"
> 
> of bad data in this model, unless all peers (s)he connects to are malicious.
> 
> regards,
> 
> -John
> 
> Mailing list: https://launchpad.net/~mimblewimble
> 
> Post to : mimblewimble@xxxxxxxxxxxxxxxxxxx
> 
> Unsubscribe : https://launchpad.net/~mimblewimble
> 
> More help : https://help.launchpad.net/ListHelp