Free transactions, spam, block reward and confirmation times

[monsterer]

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?

[1714133052]

1714133052

[1714133052]

1714133052

[1714133052]

1714133052

[1714133052]

1714133052

[smooth]

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.

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

[monsterer]

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.

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...

[smooth]

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.

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

[monsterer]

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?

[smooth]

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...

[monsterer]

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.

[smooth]

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.

[monsterer]

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.

[smooth]

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:

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?

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.

[Fuserleer]

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.

[monsterer]

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.

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.

[smooth]

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.

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.

[Fuserleer]

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.

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.

[smooth]

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 and therein lies the issue in terms of usability.

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.

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.

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.

[Fuserleer]

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.

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.

[smooth]

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.

[Fuserleer]

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.

[monsterer]

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

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.

[smooth]

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.

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.