Bitcoin Forum

Iota will be the first coin to have free transactions (that I know of). This discussion is not specifically about Iota, but relates to all coin's with 0 transaction fees and no block reward.

They prevent spam by requiring a Proof of Work (PoW) with each transaction. But, how will they set the difficulty of the PoW such that it actually prevents spam, but doesn't cause mobile devices to drain their battery?

If they set it to (for example) 1ms worth of generation, then a spammer can send 1000 spam transactions per second, which is clearly unacceptable. If they set it to 250ms, a spammer can only manage 4 spam transactions per second, but does this have a big negative impact on battery life for mobile devices?

In addition, a block reward provides a useful metric for when a transaction is safe to spend; in bitcoin, I need wait only 1 block to accept up to 25 BTC sent to me because any rational double spend attack is unprofitable up to that amount, since the attacking miner might as well take the block reward instead. However, in a PoW coin with no block reward and no fees what can we use as a similar metric for when to accept a transaction?

Only the attacker can't scam multiple victims at the same time. 2.6 BTC each times 10 victims >25 BTC.

Doesn't that imply there is no safe number of blocks I can ever wait? Since the attacker can attack basically an infinite number of people (under a theoretical elastic block size) at the same time...

Ugly isn't it?

Discussed somewhat in section 6 here: https://bitcoil.co.il/Doublespend.pdf

I wonder if this problem goes away with a single transaction per block and some way to combat selfish mining?

A single transaction per block does mean only one victim can be scammed per block I suppose (unless multiple payees), but presumably those blocks would be very fast and you would want multiple/many block confirmations to accept a payment, so now back to multiple potential victims...

But at least the game theory works now? The only way I can see for the game theory to be broken in this case is by selfish mining, where the recipient cannot see the PoW being generated by the attacker.

It does allow you to bound k in the above paper.

What about coins with no block reward; doesn't that make this totally unsolvable, since there is no advantage to playing by the rules? The only motivation for the attacker is to double spend, and there is no way to value the PoW being generated.

I'd have to think about it some more, but it does seem plausible that these worst case security models become weaker or nonexistent.

Also, I meant to comment on:


I can't see how 250ms of calculating when you want to make a payment (not all the frequent usually?) is going to be a big impact on battery life for mobile devices.

Jumping away from what you two are discussing...

This is also my concern for implementations that use POW as a substitute for fees, mobile devices.

About 3 years ago, before I even announced the eMunie project, one of the first things I looked at was to move the POW from miners to the transaction creators and mobile devices were a big problem among others.

Should anything ever achieve a good amount of mass market penetration, 90%+ of all transactions are going to come from mobiles.  iPhones and Android already have awful battery life so requiring the CPU to run flat out for a few seconds or more isn't going to help.  Add in the fact that spammers will use PC's which are an order of magnitude faster than phones only makes it more tricky, what takes 1 second of CPU work on a PC is going to take a 10+ on a phone.  After a few transactions you're going to notice that battery use, not critical, but still a factor.

The primary problem IMO (and ALWAYS gets forgotten) is actually paying for stuff at the counter, anything over 10 seconds is going to start annoying other customers in the queue.  I've seen people pay for stuff in Bitcoin and its painful to watch all the other customers slowly coming to the boil wondering WTF is going on!  The merchant is going to get frustrated too as its slowing down his throughput of customers, so he either has to open another checkout desk or risk those customers not coming back because there is always a queue due to many people wanting to pay with XYZCoin.

I could go on and on :)

I find that a lot of the time everyone focuses and discusses only technical aspects to find a problem and determine whether some approach is worth considering. In actual fact, frequently just considering the practical aspects of some technical approach can give you an answer in double quick time.

This is a bit of a leap (prepare yourselves), but I have a suspicion that this will eventually lead to a proof that you cannot have consensus without centralisation of mining, which is a bit of a contradiction equivalent to saying that decentralisation requires centralisation.

Yes a few seconds to 10 seconds I would agree, but OP mentioned 250ms. I don't see it. Seems comparable to rendering a web page or many other normal operations on a smartphone. Should be acceptable.

Agree that 10 seconds would be an annoyance for usability too.

Also, the performance gap between desktop (especially mainstream to low end desktops) and mobile is closing fast. Some of those new 64 bit ARMs are damn impressive.

Indeed phones these days are getting fast, but that is only the high end of the market.  The long tail of devices will be mid - low end, cheap or obsolete hardware, and therein lies the issue in terms of usability.

Also as things become ever faster, the POW is going to have to become ever more difficult, so you'll always have this long tail spread of device performance requiring usability considerations.

Okay fair point. But still if you have say 1 second on a mobile and a high end desktop is 10x faster then it means a high end desktop can spam 10 tx/second. Not necessarily so bad.


I don't see this. Seems a reasonable tuning of PoW would leave the resulting time alone even if the amount of computation increased. I don't see why the tail would get longer either. I suspect shorter over time, in fact.

Yes thats correct, I was referring to the problem of time, that once you have the "checkout problem", you can never get rid of it.

If its required for arguments sake, that 1 second of PC time is the required tune of the POW, then mobiles are going to need 10+ seconds on highish end devices.  With increasing POW difficulty, you always need that 10 seconds of POW on these mobile devices, even though they too are always getting faster. The problem lies that you'll also always have the long tail distribution of mobile performance, where the lowest performance phones that are cheap or obsolete will be slower than the newest high end and more popular overall, even though everything is getting faster.  The low end devices of tomorrow are the high-end devices of today.

You might close the gap some, as technology advances, but you'll never remove it totally.

What I'm asking is why would you choose one second on a desktop and 10 seconds on mobile instead of 1 second on mobile and 1/10 second on a desktop. The former seems like a straw man.

Any quoted "choice" is just arbitrary at this time as no one as yet knows what the POW difficulty should be. I don't believe sufficient investigation and testing between desktop and mid-range phones has been made to determine what difficulty of POW is needed to provide sufficient security AND sufficient useability when fully considering the checkout use case.  Using high-end devices as your test case doesn't cut it, as 90% of devices will be slower by varying degrees.

If the POW required to provide security is low enough in difficulty, then the checkout problem on mobiles is of course mitigated.  

It still stands though that with transactional based POW, mobile devices across the range must be considered if the target market is mass market.

Security isn't at stake here, it's DoS via spam; you can always wait a little longer for a confirmation under a lower PoW difficulty to achieve the same security.

Yes and because it is arbitrary there is no reason to state that it takes 10 seconds at point-of-sale.

You earlier stated that "90%+ of all transactions are going to come from mobiles". So that being the case any sort of difficulty adjusting process would naturally have to target those devices (and not the 10%). I fail to see why any rational PoW design would result in 10 second point-of-sale transactions. It just makes no sense.

Yes there will be a range, but if the range makes the oldest devices unusable, people will upgrade them, or not use the payment app on older phones. Many older phone have limits on what apps they can use.

Maybe I'm missing something, but surely if the POW is too easy to do to account for mobile devices, then the amount of spam in the network will be incredible because its so cheap for some guy with a few PCs to create?

So then your reference to prevent DoS via spam is PCs, but your reference for usability is mobiles and the two don't play together well IMO.

If I wanted to severely disrupt the network, and the POW is low to cater for mobiles, say 250ms per POW on mid-range PCs I can do 4 per second per box.  I can purchase 2nd hand HP blade server boxes with 64CPUs for a couple of grand and be throwing 200-300 tx/s around in no time at $0.50 per hour electricity cost.

So what am I missing in this discussion? :(

I think you're missing nothing and now we are getting to the heart of it.

The distinction between PC and mobile just doesn't matter that much here. You could plug in your mobile and use that to spam the network too, albeit somewhat slower than a PC.

1 second, or 10 seconds or 60 seconds of computing on any devices just doesn't cost that much in terms of electricity. The idea that it will prevent spam is very questionable.

Using your numbers above, why stop at 50c/hour. For $100/hour of electricity you could spam 40k tx/second. How does this stop a motivated attacker at all?

Ahh, I've obviously made the mistake of entering this discussion with the mindset of "how do/would we do it?" as opposed to "is it a good idea?", thus my argument of having to consider mobile device usability.

As a means of just securing against spam, I agree that it is a questionable approach at best!  That and the checkout problem were the reasons I abandoned research into this and similar methods, its too cheap for any attacker to cause disruption.  If you make it expensive for attackers then you affect the mobile users.

The point must be that PoW has a financial cost associated with it, which can be equivalent to a transaction fee. So, a motivated attacker needs to pay to spam the network; whether the PoW required to be equivalent to, say 0.00001 BTC is vastly outside of the capabilities of a mobile device, or even a PC is the pertinent question.

0.00001 BTC is about 1/2 cent (which may still be too low to be a useful spam deterrent). An entire battery charge on an iPhone 6 costs about 10 cents 1/10 cent. So I'm pretty sure the answer is no, and given the relatively small performance gap between an iPhone 6 and a PC I pretty sure the answer is no on a PC as well.

EDIT: wrong cost to charge an iPhone 6

Well BTC is ~$390 right now, so 0.00001 BTC is 0.39 cents.   A modern mid-range CPU consumes what? 100w or so flat out.  Therefore if you are lucky that 1kw/h of electricity costs you $0.10, its 1 cent to run that CPU for an hour.  To have a POW that cost 0.00001 BTC would require that CPU to run flat out for 23.4 minutes.

The critical difference is though, is that fees in Bitcoin are not part of the security model, so you can't really compare the two models anyway.

Edit: as smooth says, very high end phones will be closer to a mid-range PC.  On mid -> low end phones, you'd have to run it for hours to create a POW that is equivalent to a PC in 23 minutes

Fees are part of the security model against spamming. Well fees and the block size which forces fees up if blocks fill up.

That's interesting. So, sending a PoW with a transaction is *not* an equivalent spam deterrent to bitcoin's transaction fee, in terms of cost at least.

Note, this is not directly related to the security model, though - if I am waiting for a transaction to confirm, I just wait for some amount of PoW to go  by; if that PoW is easy to generate, it gets generated more quickly than it would have otherwise, leading to a fairly consistent confirmation wait in real time whatever the difficulty.

Projects like Iota though use POW as "fees" and as part of the overall security, which is where I'm guessing the question in this thread was spawned from...hence that statement.

Clarification though is probably a good thing here :)

Its nowhere near enough IMO, Iota will have a lot of spam!

IoT supporting cryptos will have some serious issues to solve, as the cost of a transaction needs to be cheap, but the cheaper it gets the more open you are to spam.  

Its almost paradoxical, supporting IoT devices requires minimal work and fees requirements, which enables spam that you'll certainly get, so these IoT devices have to do more work to keep up!

If you want to mitigate the work that they have to do due to spam, perhaps by offloading the work of staying in sync to a 3rd party, then you are starting to centralize.

I see 5 solutions to your problem:

1. Send a transaction without PoW and let the beneficiary (e.g. a merchant) to do the work.
2. In a connected world you can use your desktop remotely to make it generate the PoW.
3. There are GPS modules, WiFi modules, why not have PoW modules which make PoW generation very efficient energy-wise?
4. Pay to a miner to do PoW for you (just like Bitcoin would do it without the 25 BTC subsidy).
5. Cooperate with other devices around for pooled "mining".

Surely these can only be feasible solutions outside of the tangle itself? Otherwise a spammer has literally no obstacle at all to placing transactions in the tangle, if say (1) implied the transaction was sent via the tangle to the merchant.

edit: apart from (4), which suggests that a fee is necessary somehow - but how to IoT devices pay a fee?

In (4) a transaction can have 2 outputs - to a beneficiary and to a miner.
Jinn team works on (3).