Time-as-a-Currency & PoS4QoS - PoS-based Anti-spam via Timestamping

Which outlined scenario will lead to a fee market for Nano? Rob's or DPoW? I think the best move for global adoption would be to eliminate any fee market.

Let's keep our feet on the ground and realize these "attacks" are just about clogging up the network. Nothing that compromises accounts or creates double spends. I'm also still seriously doubting these comparisons (particularly for memory hard PoW). I'm seeing much lower numbers and the numbers your quoting would be capped far sooner by someone's available internet bandwidth (no one has a 100,000 GB/sec connetcion). It also seems rooted in that mobile phones have to produce their own PoW. I agree that's ideal but likely far from necessary. Also, isn't every internet system in the world, on some level, subject to this same sort of spam QofS attack? Let's not fall into a trap of thinking Nano has to be more resilient than anything else out there.

It's also a fair question to ask if someone is going to spend 10s of millions of dollars (or more) to develop, produce, and implement ASICs just so they can temporarily slowdown the network only to have it all for not with a change in the algorithm or some sort of legal enforcement (Colin's brought this up before, you can't just maliciously attack a network without some legal risks, same with short selling).

I'm still trying to find the time to break it down, but to me your proposed idea is very "anti-Nano". I was drawn to Nano by it's simplicity and elegance and turned off of other projects by their convoluted structures and dependence on multiple sources of information (here account balances, recent transactions, and most problematic time). I'm also a 100% supporter of the idea of keeping the protocol and blocks as streamlined as possible. Adding multiple new variables, creating multiple tiers of service, and bringing account balances into the equation really seems to complicate things exponentially. It's beyond my knowledge to know exactly how all this impacts the workload on nodes but I have to imagine it's significant (particularly for "hobby" nodes).

In the end I'm an engineer (though mechanical) and I'm good with the right solution to any problem. Maybe I'm wrong but I think it worthwhile to continue to search for simpler solutions to the potential spam QoS issue (preferably ones that don't introduce time into the equation).

2 Likes

dynPoW as means of prioritizing tx will likely lead to a fee market.

1 Like

For any other casual readers, M00N_R1D3R put together some additional discussion and analysis of this idea here:

1 Like

Yes. The beginning of the waterfall needs no defense - it is essentially a reasonable number of reasonably sized transactions - and P4Q limits the impact of the later stages of the attack to accounts with small balances. The trouble is that spamming only the poor wallets is sufficient for a "successful" attack.

We've discussed a somewhat different issue on reddit, that of the priority queue potentially being eternally full/the network running at saturation for a sustained period of time. I think we agreed that such spam sustained for extended periods would be very bad, and is potentially much easier, given sufficient stake, than that same level of spam is today. As such P4Q would need to function alongside the current PoW system to deter eternal saturation. And at that point, why not keep PoW prioritization among priority queue users instead of account balance prioritization? (Assuming the very problematic current issue I with dynPoW is resolved as proposed by Tuna and Plasma)

You can look to EOSIO for a PoS for QoS system (less elegant than this proposal, but effectively staking for a guaranteed portion of network resources under saturation conditions) that experienced a sustained saturation attack. It caused services and users to move away from the original EOS chain and to side chains. PoS for QoS is not sufficient in absolute terms - there still needs to be a way to dynamically admit some random subset of priority queue transactions in order to prevent the network from being fully stopped, even if the level of baseline priority queue that has been successfully spammed is very small, as would be the case in the waterfall attack.

As a baseline to what can be achieved using memory-hard PoW alone (like Equihash):

It is possible to set the "Open" transaction (the transaction required to open a new account) to use a different set of PoW parameters. Say, parameters that cause the PoW to only be efficiently solvable with at least 4GB of memory or more (using an AES-based hash may allow a hash pool of that size to be generated very quickly on commodity desktop and server hardware).

Now set up public servers (not necessarily the foundation - this can be done by anyone - the protocol is completely open) that require solving a captcha to receive a solution. This will only be needed in order to open a new account. The PoW for transactions of existing accounts will be much easier and would be solvable on a mobile device.

Edit: an alternative is to let the PoW computation be done on volunteer PCs (possibly in browsers) and the servers only act as middlemen to perform the CAPTCHA validation.

I've also suggested the idea of proof-of-recency which is an approach to prevent precomputed attacks that is trustless, timestamp-free and requires no node coordination or voting, but would require some extra metadata (at least 8-16 bytes) to be included in the block and would require the nodes to maintain a lookup table of hashes of recent high-stake transactions.

Hello, all!

I would like to suggest a slightly different implementation, where it isn't exactly time that prioritizes a transaction, but rather frequency.

When you break it down to the nitty-gritty, all "spam" really means is a high frequency rate, aka volume vs time.

Could nodes simply prioritize transactions from accounts with less frequency?

This philosophy is often used in competitive transactions, where people are incentivized to not make a transaction until "it's really worth it".

For those of you familiar with fantasy football, an example of this system is called the "waiver wire". When a fantasy owner wants to aquire a player not selected for any team, he puts forth his interest on the waiver wire. By default, he gets that player unless someone who has not taken a player before that "outbids" him, using their higher priority.

In this system, team owners are incentivized to only select a player when they are willing to spend their priority. Recklessly picking up players means that you miss out on another opportunity for a better opportunity, because a different owner will have higher priority due to their greater patience.

Within Nano, I think nodes could give priority to transactions coming from accounts that have not conducted a transaction more recently. The node would simply compare the order in which it last saw a transaction from account A versus account B. Whichever account it saw most recently would have second priority.

1 Like

Sadly that doesn't really help against spam, or prioritize legitimate use, respectively.
This is because a spammer can create a gazillion (ok, in fact slightly less) accounts and use them in parallel.

1 Like

It benefits the richest (in Nano) over the poorest (in Nano), but does not lead to centralization because it only benefits their own account. DynPoW benefits the richest (in USD) over the poorest (in USD), but does lead to centralization because it benefits everyone that uses the node.

The demand for higher power is due to DynPoW in the first place, though. And this is true of centralization VS decentralization in general. I see this as little other than advocating for centralization -- in the real world, that's why we use centralized architecture.. because using 1 ultra-specialized server is better than using 1000 shit servers that are all half-assing it.

Everything you said before this line was reasoning for why an exchange might use Nano, which... I don't necessarily agree with (because it's specialized and expensive hardware for just 1 coin on an exchange of presumably hundreds+...), but it doesn't support the conclusion above. ASIC's are the death of Nano's security if Nano's security hinges primarily on ASIC usage.

Even if an exchange put $1k into an ASIC, an attacker can put $1m into an ASIC. Same problem. We're securing against people who stand to gain billions of dollars by crashing the network or against people who are potentially nation-state funded. A price tag of "a few thousand" to "a few million" is basically "free" to them.

This is centralization by definition. Why not just add a small fee onto Nano in this case? Then there is incentive to run many nodes (better decentralization) and users can just pay a fraction of a Nano to send instead of paying for a representative that got the better hardware. Then we're just an XML rip-off.

In a goal to short-sell it. There's a profit to these attacks.

RAM is cheap as balls. You think 16GB of RAM is impressive? You can drop less than 10 grand to get a few terabytes of it.

If a Nano transaction is 32kb (can't remember) and someone is sending out 104 transactions per second as I outlined in my post, that's 320,000,000B/s, also known as 32 MB/s. I can do that on my internet, which is like... $50/month.

It's almost all the same variables, just re-used in a new way. User's account balance is already known. The only new variable introduced is time, which is a big ask by a lot of people anyway just because it's a good variable to have.

DynPoW is far harder on hobby nodes due to the hardware demands. This is a software solution and does not add complexity beyond O(logn), and maybe not even beyond O(1) since all of the data is already there and it just needs to be consumed. If you aren't familiar with O(1), it means that computationally it's basically free. O(logn) is basically the second best, computationally.

I am also an engineer (information security). Time in this case is actually quite elegant in its implementation, because it isn't trusted. This is a unicorn implementation where time is both used for security and untrusted at the same time, which is extremely Nano-ish if you ask me.

A waterfall attack is not unique in this case; it falls exactly in line with "Attack 2" where poor wallets were considered an acceptable target.

My goal is to ensure that you need 10% of the global currency to be able to spam out people who own < 0.1 Nano. I did data parsing on the ledger yesterday and it turns out that only 2,000 Nano is cumulatively owned by all wallets containing 0.1 or less Nano. This is effectively 0% of the market cap. Worst case scenario, sub-0.1 ultrapoor participants can centralize into a custodial wallet holding a whopping ~2300 Nano and they would be given an elevated QoS tier without affecting global centralization meaningfully (because it is only 2300 Nano in a 'centralized' place).

Even more importantly, however, is the idea of herd immunity. You say that spamming the poor wallets is "sufficient for a 'successful' attack" but I completely agree. A successful attack, to me, is defined as performing the attack for profit or gain. Spamming out the bottom ~2k Nano ultrapoors from the system won't affect the global market cap, which means you don't stand to gain meaningful revenue and the millions you invested into ASICs/whatever are wasted. Attacks are carried out more for profit than for fun.

In addition, nobody spends millions to rob poor people (except the global banking economy amirite guys?) whose cumulative net worth is ~2300 Nano. People aren't buying tanks to take over homeless tent cities.

I don't understand the argument. "Both is better than just one, so why not pick the inferior one as the primary"? DynPoW is good defense in depth whereas P4Q is good as primary defense. Yes, both are better than just one, but that isn't a reason to swap to primarily using DynPoW.

Consider this: Passwords with 2FA codes are better than passwords alone, but 2FA codes by themselves are not better than passwords.

If the threat is ASICs or farms that are capable of spamming out the network, then being primarily based on PoW is a backdoor to bypass QoS tiers. Someone with ~0 Nano invested in the network could just spam transactions with tons of PoW until they're blue in the face and lock up exchange withdrawals and the rich, which would drive down market price -> hence profits from shorting.

Also, the beauty of P4Q is that it works even during total saturation. It provides immunity to precomputation attacks as well since it's assuming attackers have infinite power anyway, without the need for yet another defense mechanism like time-blockchaining. Any DynPoW solution is also vulnerable to precomputed receive fork spam by wallets that have 0 Nano and are all triggering network voting to resolve the fork. P4Q ignores the congestion due to network voting by allowing richer users (basically everyone) to cut the line in front of the receive forkers because they have little/no stake in the network, and the only way an attacker can get meaningful stake in the network would be to purchase it, at which point they would be actively destroying their own investment in Nano.

This means that the more Nano's price increases, the more money would be required to launch an attack. Pretend that Nano were a 50T global currency and secured by PoW. You would stand to gain tens of trillions of dollars by shorting it during a spam attack by a custom farm that costed millions. However, if a successful attack required you to first purchase 20% of the global amount of Nano ($10T) on top of making an ASIC farm, you are now destroying your $10T investment in an effort to gain more than $10T by shorting it -- a much, much, much steeper requirement (both in initial investment capital as well as a much smaller profit margin -- you stand to 2x your money instead of 10000x it).

Do I think Nano will be worth 50T? Maybe, maybe not. But the point is that one solution is scalable and works better as Nano goes to infinity, while the other solution is a stopgap and works worse as Nano goes to infinity.

As mentioned before, PoW works for BTC because it is primarily secured through PoW. Its PoW protections get stronger as BTC's price goes up, because legitimate users stand to gain more profit and thus spend more money making bigger/better mining farms. OTOH, PoW in Nano is hard-capped at what a mobile phone could do (or, at best, what an average GPU can do). An attacker willing to drop $2mil to create a farm will have absurd advantages over these actors, and as Nano gets more expensive, this farm is a smaller relative cost to the potential benefits of the attack.

I'll just be repeating myself if I explain this any more, but suffice it to say that DynPoW/Equihash are fine stopgap measures and great defense-in-depth measures but they lack scalability and come with far more drawbacks.

My goal is to produce a system where a user with 1 Nano mathematically provably has a 1-hour or less SLA between sustained transactions. No matter how bad the network gets, if you have 1 Nano you will get a transaction within 1 hour. I believe that this is possible with no compromises if we can just get Nano's sustained global TPS to 100k. However, I'm working on some modifications with minimum compromises that will get us to that point even if Nano only has about ~800 TPS.

4GB of RAM is a lot to a cell phone or a low price EC2 instance. It's basically nothing to a dedicated attacker. Price tag of having a 10TB RAM farm is measured at around $10k-$20k or so, which would allow for the parallel creation of 10k / 4 = 2.5k equihash hashes, and you make it sound like this is the "upper" end because it's the "open" operation. After the attacker creates those 2.5k accounts in a single second, what stops them from just using send/receive between them?

RAM-hard doesn't matter. CPU-hard doesn't matter. At the end of the day, you're trying to let mobile phones sit at the same table as actors that have better hardware and motivated by hundred-thousand-bagger profit margins to attack the network. As Nano grows, their profit margins grow larger and larger. It's only a matter of time before it becomes so profitable that attackers are fools not to do it.

CAPTCHA's are great. But once the attacker has 10k accounts, they're done. They can pay out like $100 on Amazon Turk or whatever to have 10k CAPTCHA solves and then they're done. The one-time fee of 10k account creations is paid, and they can use them freely. You can't CAPTCHA general network transactions or the rate limit gets too extreme for exchanges to tolerate and the UX is terribly for everyday users.

I read through it. I dislike your use of the word "reputable" (in a decentralized system, nobody has reputation) but I assume you mean high stake.

I think that your conclusion that it would require "many accounts that all have high stake" is flawed. It would require 1 account with high stake ("reputable") and many accounts that all refer to its recent nonce.

I have some initial concerns, however, and it has absolutely no protection from ASICs (as they don't rely on precomputation), but I'll post my exact issues in the thread itself.

I don't believe this provides any protection from Sybil attacks. In addition, TaaC is about frequency. You spend time as a currency and the more frequently you spend it, the less currency you have.

6 Likes

If the PoW for the "open" transaction becomes, say, 100x more difficult than PoW for a transaction block of an existing account, this means that computing PoW for precomputed attacks would be up to 100x more computationally demanding (there's a limit to how fast existing accounts can post new blocks and it's not difficult to enforce it).

If the memory requirement is increased to several gigabytes as well this could make special-purpose hardware very expensive to produce and own for this purpose, which could make it comparatively even more difficult for attackers.

Most "honest" users only use a few accounts and will not be affected by this. Since the "open" block PoW would be too demanding to run on mobile devices, I suggested it would be computed by volunteers in exchange for solving a captcha. "Honest" users would only need to solve one captcha to open an account, so from their perspective it wouldn't be a real annoyance.

Attackers can, of course, buy captchas solutions from "captcha farms" and use them to acquire PoW solutions, but that would be primarily an abuse of the PoW service, not abuse of the network, and is a different topic altogether (even if the attacker is willing to spend a lot of money on buying captchas I'm not sure captcha farms will be able to produce a volume large enough to flood the network and I'm not sure the network of volunteers PCs would be able to compute enough PoWs). This issue isn't really that different than attackers abusing the current DPoW network, which is even more vulnerable since it doesn't even require captchas.

So it seems like the problem may be shifted to how to protect the PoW service from being abused, since the work it would be doing would be much more expensive (and valuable) than today. I guess fees could work, but it isn't really reasonable to take fees from users who haven't even started using the coin (they are opening a new account so most likely they don't own any Nanos..). Nothing is impossible though, that is just a different problem I guess :).

1 Like

100 is 102. A farm would outpace a mobile in computation, RAM, anything you want by 1010-20+. And this isn't even precomputation we're talking, but real time.

And once you made 10k accounts, you don't need to open more. You just send/rec with them.

"Very expensive" is relative. Owning terabytes of RAM is measured in the low thousands. This is nothing when you stand to profit millions or even billions of dollars by shorting the economy.

Again, as I said, attacker pays like $100 on Amazon Turk to have 10k CAPTCHA's solved and then never need to open an account. Did you read my reply? I addressed it right here:

I dunno why you think that all spam needs to happen in OPEN transactions. Once the attacker has 10k wallets, nothing stops them from simply sending 1 TPS to flood the network. Or 1 million wallets sending 0.001 TPS. A million CAPTCHA purchases is, what, $10k? And wait a few weeks at most? To have 1mil accounts to permanently flood the network with? This is chump change to an attacker who stands to gain millions from shorting the currency.

Or the problem is that PoW is a crap solution and shouldn't be used for anything other than defense-in-depth.

2 Likes

If attackers open many accounts and constantly spam with them, the blocks generated by each account would be throttled to the maximum rate nodes are willing to process them. If a single account attempts to send 1000 blocks in one minute then it is not difficult to simply notice that and deprioritize 995 out of those 1000 blocks for later processing.

That wouldn't be very good, but I'm not sure if that would qualify as a "precomputed attack". The various proposals here only try to address the case where there's a concentrated attack where an extreme surge of blocks saturates the network to the point where it stops functioning properly. To achieve that effectively (without any of these special measures in place) it would be most effective to open new accounts at a rapid rate.

Having 10,000 accounts individually spamming the network at the maximum rate could be maybe described as a form of a "worst-case scenario" the network should be prepared for.

This may not necessarily be only caused by "malicious" attackers, it could also be the result of a normal app that, for example, takes advantage of the lack of transaction fees and is programmed to automatically sends micro-payments from its users' accounts. Say, a chat app that instantly passes tiny amounts of funds between its users' wallets whenever they send emoticons to each other, or say, a twitch-like app where tiny donations are passed to the host at a rapid-fire pace.

I personally agree that a system of small transaction fees (most likely burnt) would have been much easier. Since there's no mining and the block confirmation process is super-efficient, there's no real reason why these fees would go sky-high like is happening with Bitcoin and Ethereum.

I don't think this is really what the developers have in mind so I guess I'm trying to work with what I have.

In all the back and forth, this really is the crux of the issue. All of the counterpoints to the P4Q proposal seem intent on finding a solution for PoW to limit spam, but the conversation is bigger than just spam reduction. The beauty of the P4Q proposal is that it considers things that could happen and accounts for them now. This is the very definition of "designing for evil," which is paramount in all financial applications, especially in cryptocurrencies looking to supplant existing fiat networks.

3 Likes

Agreed. I like the potential to improve QoS according to usual usage patterns. Even if it solves 50% of the problem, the cost to transactors is cut in half.

1 Like

From what I can tell it's easy to convert a sequence of N transactions from 1 account in to a set of 1 transactions from N accounts. The balance from one account can be halved in to two other accounts, and each of those can be halved and split in the same way. 2^N, so it's fairly fast to split this way.

I think this is where memory-hard compared to per-core strength comes in to play.

Memory bandwidth on LPDDR4 chips is only 1/2 that of the bandwidth available on desktop DDR4 chips, and only 1/10 that of high bandwidth HBM2 modules on GPUs:

"DDR4-3200 bandwidth: 25.6GB/s"

"An LPDDR4-3200 @32-bit SDRAM supports 12.8GB/s"

"HBM2 is able to reach 256 GB/s memory bandwidth per package"

Then it just becomes a constant factor cost-invested tradeoff.

1 Like

After thinking about it for a while, I think I underestimated how many accounts a determined attacker can open given enough time. Even if the PoW for the "open" transaction was 100x more difficult, the attacker could spend months accumulating accounts and then later use them to launch as many precomputed attacks as they want (the attack would transmit 1 block for each account, all at once). 10,000 accounts may not be enough though, maybe 50,000 or more (just a rough number).

Here's an interesting detail: even if transactions required fees (or had them as optional for QoS), the "open" transaction would still be possible to abuse. Since new accounts don't have any funds in them and can't pay for prioritization, attackers could try to "block" legitimate new users by flooding the network with "open" blocks. One solution would be to require a minimum fee to be passed to the new account from an existing one (similar to an "invite" system), PoW is of course another alternative.

From an environmental perspective I think fees would be more "green". If someone made an otherwise similar network that had no PoW but instead required fees to be burned for every transaction (and possibly a sort of "invite" system for new users based on a minimum fee) it would probably take the lead as the greenest cryptocurrency.

For the PoW-based approach, I think there's some potential to be explored with my proof-of-recency idea (an alternative anti-precomputed attack approach without timestamps or voting). It can be simplified so that only nodes or representatives would be able to generate special "tick" blocks (which would be empty and possibly pruned later). These "tick" blocks would be used as evidence for recency (I don't want to drag the discussion to a different idea so you can look at that thread for more info).

If you haven't yet can you take a look at my proof-of-recency suggestion? I should probably have opened a new topic for it because it seems like it isn't getting enough attention.

There are many variants. My current most simplified version is to have representives post an empty "tick" block every minute or so (which would be tiny and pruned later), where blocks would need to randomly refer to the hash of one of them (the entropy would be derived from the the seed used for the PoW) and this extra piece of information would be then mixed into the seed for the PoW and transmitted as an additional field in the block. This "evidence" field can be reduced to a size as small as 4 bytes (even the first 4 bytes of the tick block hash would be difficult to forge).

(I understand how memory-hardness works - I guess I meant that even with memory hardness 10,000 PoWs may be computed in an hour or so by a well-equiped attacker so I'm not sure if that counts as a precomputed attack - though with a technique like proof-of-recency [or any other effective alternative] the measure of "recency" can be reduced to a resolution of a few minutes or less)

In general I support this idea. There's a real problem with allowing a spammer to pre compute PoW for months prior. I'm not sure of the best way to implement this but it seems feasible to limit this window of time, even if only during high network traffic.

I don't see this as a solution at all.

  1. Timestamping is not possible in distributed systems. You can't rely on it, never. That is what you have Chandy Lamport and all of these fancy algorithms for.
  2. A spammer can also just calculate everything necessary months or even years in advance and destroy the network at some point. Yes, there is dynamic PoW, but if you time it right and you don't spam it like crazy, it is possible to combine it with a penny attack and bloat the network. You could even produce blockchains for certain scenarios in advance. Blockchains which can be sent when the network has that difficulty and a higher one. There are probably even smart ML Models you can design to predict the behavior of this in advance. Yes, it makes it a bit more difficult, but I don't think difficult enought.
  3. You are shooting yourself eventually in the foot. Once you have to think about sharding, you are eliminating every solution for this in the future, just because you used a timestamp.