Precomputed POW & DOS

Hello Nano community,

I chose to invest in Nano over Bitcoin because I believe Nano has many advantages over Bitcoin while being a valid & compliant consensus network.

The Advantages

  • Instant
  • Feeless

The Disadvantages

  • Availability

Upon research, I have discovered that Nano's advantages are true, and that its consensus is sound; nevertheless, I believe there is a flaw: availability. Someone, after having done enough work, could, at any given time, deny the network of service via precomputing the work and saturating the network.

Availability is key for the well-being of any payment infrastructure. It is my understanding that Nano has no notion of time in its ledger. So my question is: why not fork a notion of time in order to secure the availability of the network?

dearly
, OffsetGoose

1 Like

It's true we don't have a notion of time in the network right now. What do you mean by fork a notion of time?

To guarantee the availability of the protocol, introduce a time blockchain. Every second, a new time block is added to the chain, produced and validated by the representatives. Each time block contains a reference to the previous block, the UTC timestamp, a valid nonce, and a block hash. To publish a valid block, it must contain a reference to one of the latest N time blocks.

What is your view on this proposal, @clemahieu ?

In order for the next time block to be considered valid, it must:

a. Be ahead of the previous block's time.
b. Be behind the validating node's time.
c. Prove work with a valid nonce.

There would be no incentive to mine time blocks, besides securing the network.

If this is a single, shared chain of time blocks, one of the issues might be determining who publishes the block that ultimately gets added. Without a designated and identifiable leader for each block, you could have many attempts to push the next block and that would be inefficient to generate consensus around (similar to many forks on a chain now), possibly open up attack vectors too. It seems like this would need to be solved in a way that is resists sybil attacks on it. Thoughts on that?

What if only PR nodes could add to it and one of the fields, like link, could be a signature from their key? They could essentially just be change/epoch blocks or something similar.

I’m very much in favor of an idea like this for coordinated clock to prevent precomputing too far into the future as PoW could incorporate the hashes from this chain.

I’m not sure if every second is necessary, maybe 12-24 hours instead and would help reduce contention between PR’s if it’s spread out more. Maybe even dynamic interval based on number of PR nodes to try and spread the time out between new blocks.

@zach-atx,

I believe adding a block to the time chain could be permission-less through the use of the longest chain rule. If two valid blocks of time are published to the network simultaneously, the next valid block in whichever chain becomes the dominant chain, and the other a fork. Transactions referencing a forked block of time would also become forks. For best performance, I believe new blocks would benefit from referencing the 2nd or 3rd latest time block.

I don't think the longest chain rule could be used directly, that becomes a PoW stacking situation. If blocks become forks if they're on a forked timechain, PoW generation would have to be maximized like a normal PoW coin.

Right now people can precache 1 transaction to be sent and a lot of people exploit this, we want to impact that as little as possible.

1 Like

I wonder if this could be done by using a certain block hash as a flag. I.e. the nonce is a recent confirmed block hash that ends in "xyz123" which is rare enough to not constantly invalidate normal precomputed PoW (e.g. 1 block deep), but frequent enough to prevent precomputing for hours/days and then dumping them all at once.

Problems include attackers potentially brute forcing those block hashes, validating during bootstrapping, current CPS affecting the "time" between hashes, and randomization being randomization (waiting too long or too little).

Other potential pseudo-time indicators I've thought about: current block count (moves too fast, there isn't a way for other nodes to verify it easily, and nodes can all have different counts), current online vote weight (changes often, but not in a big enough range), picking a PR's vote weight, etc

Just brainstorming as usual :slight_smile:

I think all procomputed POW will eventually be invalidated if it's being benchmarked against some global time. I can't think of anyway to ensure there aren't any subsequently premined blocks.

I suggested using PoW (hashcash) to advance the notion of time on the network because that would make it a stochastic & leaderless process. Since there's no incentive to advance the notion time, I disagree with @clemahieu that this would introduce PoW maximalism.

One possible attack vector I could imagine would be someone premining a bunch of time blocks. This would probably be difficult to deploy since each block must include a reference to the previous block. The only advantage from precomputing the network time would be the ability to precompute a bunch spam transactions. All it would take to invalidate all of that precomputed work would be a fork with a few blocks from an honest participant. This makes me rethink whether the longest chain rule would work for keeping time on the network; ORV may have to quorum which block of time is the most recent.

Indeed, it doesn't seem like this upgrade is essential right now. Only time will tell :rofl:

I'm not sure I like the idea of completely invalidating work done, especially in shorter timeframes. It would put a lot of extra on-demand work generation pressure on services that try to provide a high quality response time for their transactions (or alternatively a very inefficient setup where pre-cache is done many times to ensure quick availability when an occasional user goes to make a send). Perhaps this can be avoided with:

  1. A consensus-based time chain as mentioned
  2. Blocks that reference a specific block on the time chain to indicate when they were produced
  3. A calculation against the work difficulty that reduces the prioritization of the block over time, but never invalidates it completely (or at least stretches out the invalidation to a more acceptable, longer timeframe) - even something as simple as ( (work difficulty - minimum difficulty)/(current time block height - referenced time block height) ) + minimum difficulty might be interesting, which would keep it above the threshold always but make it weaker over time.

This of course doesn't prevent someone from pre-computing and dumping a large amount of blocks on the network, but minimizes the effort to jump ahead of those blocks in priority if they took a while to produce, which preserves some Quality of Service otherwise lost.

3 Likes

^This + the option to attach a small tiny message to a TX would enable a ton of new use-cases for NANO. (Apologies, off topic but I believe it may be relevant).

I really like the idea improving availability in edge cases, especially if it enables extended usage.