PoW² explored — A post-launch look at some of the security implications

Gulden
12 min readDec 6, 2018

This is the first in a series of articles I’ll be doing that focus on various aspects of the latest gulden release and PoW² specifically; I’ll be releasing more articles over the coming weeks each focusing on different aspects of the system or from a different perspective — so follow me if you want to know more.

NOTE: For the technical, this article glosses over various more in depth details that exist in order to be accessible; it also uses simplified calculations that are good enough for the average person to get a ballpark idea but are not exact, so should be read as such. Please do not attempt to nitpick at these things, an updated copy of the whitepaper will be available in the near future where more detailed/technical calculations are available.

Roughly a year ago I released the initial white paper for PoW². It has been a long, hard and incredibly challenging (but also rewarding) development cycle to bring this concept to reality but since July 16th we live in a world where PoW² is active on the Gulden blockchain.
The whitepaper talked about various ways in which PoW² would enhance the security of Gulden, however:

1. The whitepaper is a long and technical read.
2. Whitepaper is focused from a developer perspective and not an end user perspective.
3. There were unknowns in the whitepaper that we now know better once launched.

This article takes a look at the immediate security implications of PoW² from an end user or merchant point of view.

The main attack vector or area of concern for the day to day user of a blockchain based currency like Gulden is known as a “double spend”.

How double spend works:

1. I create two valid transactions one that sends some funds to your address and the other to an address of my own.
2. I send you the first transaction, while keeping the second hidden from you.
3. You release the goods or services to me thinking you have been paid.
4. I ensure that it is my second transaction (that pays to me) and not the first transaction (that pays to you) which enters the final block chain.

The key/difficult part that is meant to stop this attack from being practical is item (4) this is not meant to be easy to do.

Double spending a PoW based currency

So lets evaluate what “not easy” means here for a regular PoW based currency.

– We will use the average Gulden network hashrate from slightly before PoW² activated (600 gh/s) for this.
– A current market price of 1 NLG = 0.046 Euro.
– And a scrypt hash rental rate of 0.45 Euro per gh/s per hour

If you accept my transaction as valid before a block is mined containing it (called a 0-confirm transaction) then all that (4) takes is that I ensure I mine the next block before anybody else and then I can ensure that my alternative transaction is in that block. (Note there are other ways to attack 0-conf as well; but also other ways to defend against these attacks — these are left out as they are not of interest in this specific assessment.)
If you accept my transaction after a single confirm (block is mined containing it) then I need to ensure I mine 2x blocks before the network mines another block after the first one and to ensure my alternate transaction is in one of these two blocks.
If you accept my transaction after two confirms (a single block is mined containing it and then another block mined by the network after that) then I need to ensure I mine 3x blocks before the network mines the third block, and so on for increasing number of confirms.

If I am happy with my attack succeeding only some of the time I can execute an attack on a 0-conf transaction with very low amounts of hash rate. e.g. a ~10% chance of success for only ~60 gh/s or similar. I can also attack with a reasonably high (but not guaranteed) chance of success by obtaining some multiple of the networks hashrate. e.g. 1800 gh/s. As analyzing such an attack is technical we won’t go into in depth details here.

To guarantee success however is simpler; the simplest way is to acquire >50% of the hashrate and instead of attempting to overtake in a single block to instead attempt to mine multiple blocks faster than the network; at this point an attack is statistically guaranteed eventual success it is only a matter of time. This is also a more practical attack in terms of actually executing in the real world.

The easiest and most guaranteed way to double spend a PoW coin — assuming affordability, and no matter the number of confirmations being attacked — therefore is simply acquire enough hash to exceed 50% (a bit of a margin is probably advisable to be sure) and to out mine the network over a period of time.

Using our hash rate of 600 gh/s as an example an attacker could simply acquire a rental of 800 gh/s — at a cost of only 360 euro for a time period of 1 hour. And at current prices could even potentially expect to make back 110 euro or more of the attack cost in mining rewards!

As we can expect to find ~24 blocks in an hour, 20 confs is not really any more secure than 1 conf, increasing to e.g. 100 confs or 200 confs as many exchanges do raises the attack cost somewhat due to the rental time increasing but even then is far from being immune to attack.

Note: While this is actually possible on many PoW coins right now — it was not possible on Gulden even before PoW² was implemented due to our use of check pointing — check pointing itself though far better than allowing attacks like this, is not without downsides, but lets save that for a different article.

This is obviously a far from ideal situation, and the worst part about it is there is essentially no way to tell that an attack is about to take place, it simply comes out of nowhere.

Double spending a PoW² based currency

So how have things changes since witnessing was implemented?
Well firstly our network hash rate is now more along the lines of 500 gh/s instead of the 600 gh/s we had before — this is to be expected as mining rewards were reduced by 20%…

At present we have an amazing 775 witness accounts created; with a combined amount of 56’900’209 NLG locked in them for various differing time periods with combined “lock weight” of 311921918.

So what does this mean for a would be attacker?

The basics remain unchanged, to attack a 0-conf transaction an attacker still needs to mine 1 or more of the next blocks faster than the network, for 1-conf 2 or more blocks, 2-conf 3 or more blocks and so on.

For a non-guaranteed attack on 0-conf transaction this changes very little security wise, assuming an attacker wants to attack with only a single block and a 10% to 50% chance of success — all he has to do is acquire the appropriate amount of hash rate and attempt the attack if he mines the block first he can submit to the network and the witnesses will witness it so there is no specific extra protection for a 0-conf transaction in this case.

If the attacker wants a >50% chance of success, or to attack a 1-conf or more transaction, however this is where things begin to get a bit different from before. To do this the attacker will need to acquire his own witness accounts, as each witness account can witness at most once every 100 blocks it is necessary for at attacker to have 1 witness account per confirmation that he wishes to attack.

To create at present a single witness account that holds 1% of the network weight an attacker would need to lock up 500’000 NLG (23000 Euro) for a period of 1 month — this would give him a 1% chance of witnessing any block he mines.
If he were to acquire 100x the network hash rate (50 th/s), he could mine roughly 100 blocks for every 1 the main network mines, as he would have a 1% chance of being the selected witness for each of these blocks this would give him a reasonable but not guaranteed chance of mining and witnessing a block before the main network.
The total cost ~23’000 Euro (witness); ~23’000 Euro (mining); ~46’000 Euro in total a ~128x increase in attack cost with the added “inconvenience” that the attacker must sit with 23’000 Euro of his funds locked up in a coin he just attacked…

However a few problems:
1) 50 th/s is either close to the upper limit of, or more likely exceeds the total amount of scrypt hashrate available for rental — especially at the quoted price. Actually acquiring 50 th/s would therefore likely be considerably more expensive.

2) In order to perform this attack the attack first needs to acquire 500000 NLG — this is a considerable amount and the very act of doing this is likely to cause a market price increase. A market price increase in turn will increase the hash rate. If we adjust for this we end up with something more like 30’000 Euro (witness);

3) These unknowns mean that the attacker may find themselves acquiring huge amounts of Gulden only to find they no longer have enough money or hash rate to actually accomplish the attack.
Factoring in the above it seems likely that to stand a reasonable chance the actual cost is likely in excess of 80000 Euro if not more.

The above considers only a 1-conf, for 2-conf he will need 2 witnessing accounts at 500000 NLG each — an attack cost well in excess of 100000 Euro. Or he could try with two accounts of 350000 NLG each and 200x the network hashrate (100 th/s) however the price of this is likely to be even more considerable as this is well in excess of available rental hashrate (The largest scrypt coin has 300 th/s of network hashrate for comparison purposes).

By 3-conf we are up in region of needing 150 th/s and/or well over 1’500’000 NLG. This would require most of the hash to be purchased which is enormously expensive and difficult to do.

By 2 or 3 confirms even with a rather modest network hash rate of 500 gh/s the cost of attacking even fairly large transactions on the Gulden network is prohibitively expensive to the point that it is not practically achievable, and is competitive with much larger coins that have much larger hashrate.

Earlier I mentioned that on a PoW based currency of the same specs attacking 20 confirms would cost no more than attacking 2 or 3 confirms.

On Gulden 20 confirms would require the attacker to have at least 20 witness accounts of 1% network weight or a total of 10’000’000 NLG (460000 Euro before considering market effects) that he would have to purchase and lock up along with an exorbitant amount of hash rate required likely 200–300 th/s or even more after considering the effect on price.
This would only give the attacker a chance of success not a guarantee, if halfway through he noticed the attack was failing it would be too late for him to do anything about it, a failed attack would irreversibly lose the attacker all money spent on the mining part of the attack.

To attempt to sustain an attack for longer than 100 blocks would require that the attacker have in excess of 100 accounts; for example 101 accounts each with 200000 NLG (0.02% of the network weight each — 20% of the network weight in total) — a total cost of 20’200’000 and as he can never have 100% of the network weight he would need a truly vast amount of hash power in excess of 500 th/s which exceeds all scrypt hash currently actively mining across all scrypt currencies.

This is not however the end of the pain for the attacker — witness accounts are required to witness periodically to remain active, they are also in “cool down” for 100 blocks when last they witnessed. An attacker with 20 accounts needs therefore not only to create these accounts, but orchestrate that all of the accounts are all in the delicate window period of not in “cool down” but also not about to expire from not witnessing for too long, with witnessing being random in a way that cannot be determined in advance or controlled by the attacker this is quite hard to achieve, it also almost inevitably means that one or more of his accounts will have to avoid witnessing even though they have been selected to do so.

Why is this a problem for the attacker? Well this is an event that the network can detect — while it is not yet in existence it is both absolutely possible and an inevitability to build a monitoring system that “witnesses the witnesses” this monitoring system can watch for key events — one or more witnesses of high weight forgoing witnessing a block recently; statistical anomalies that indicate several or more such accounts might have been trying to synchronize their window periods in the past; the creation date or even funding address of witness accounts corresponding; past behavior of witness accounts and various other network factors as the designer of such a system saw fit.
Such a service could easily be used to pre-warn users of even a slight risk of a successful attack — before the attack executes, so on top of a PoW² being basically impractical to begin with its actually possible to detect and therefore stop an attempt while it is in progress! And as the attacker cannot know the exact criteria that such a system would be using evading it would be very tricky indeed.

(Note: The attacker can lower the currency costs of some of the above attacks somewhat by opting for the maximal 3 year lock period instead of the shorter 1 month lock period — however it is debatable whether or not an attacker is likely to want to tie up vast amounts of currency for such a long time period so I won’t analyse that in more depth for now)

Bribery based attacks

There exists however a potentially cheaper way to attack larger PoW coins and that is bribery. If hash power is highly concentrated between only a few large pools (as it is for many larger currencies) then simply bribing one or more large pools (or being the owner of said pools) and mining a side chain in this manner is another possible avenue of performing the same attack but with minimal expense.

PoW² is resilient against this however as witnessing is not pooled and witnesses are numerous and difficult to track down or bribe. Without a majority of witnesses participating mining a private side chain would be subject to the same constraints as a regular attack (a huge amount of additional hash power needed rather than just 50%

The effects of price on security

The price of a PoW based currency directly impacts the security of the currency, as mining is mostly done for profit double the price effectively means double the network hashrate.

The same effect applies to a PoW² coin however as the base costs are higher the effect is even more pronounced.

Based on current pricing and looking at our analysis in previous section we can see that at 2–3 conf Gulden already approaches Litecoin in security, and at 20 conf or 100 conf vastly exceeds it. This despite Litecoin being the coin with the 7th largest marketcap and a current marketprice of 54,78 Euro.

Gulden already exceeds most currencies in security in only a few confirms and almost all with a little more, but the Gulden price need only double from 0.046 to 10 Euro cent to vastly exceed even much larger currencies like Bitcoin despite still being a fraction of the price.

PoW² provides substantial security at even low prices and this only gets better as the price increases.

Sustainability and electricity consumption

Currencies like Bitcoin face a massive problem, in order to maintain the same level of security they have now they need their price to stay the same or constantly continue to increase over time. This is not sustainable in the long term as nothing can increase forever.
This ultimately means that the network has actually quite possibly seen its peak level of security and that over time it will become less and less secure; if not the case now then almost certainly this will be the case at some point in the future.

Another criticism leveled at PoW coins is the massive power consumption. Bitcoin is estimated by some to use 200,332,771 KWh per day. At 500 gh/s on the scrypt algorithm Guldens power consumption is likely only in the region of 19200 KWh per day and yet is still capable of achieving security levels that are comparible.

PoW² therefore places Gulden in a situation where it is the first decentralised and secure block chain that can be sustained at reasonable prices and at reasonable levels of resource usage over the long term while at the same time being way less wasteful.

Source: https://medium.com/@MacLeod_MJ_za/pow²-explored-a-post-launch-look-at-some-of-the-security-implications-2773fc11e50c

--

--