Topic: Free transactions, spam, block reward and confirmation times - page 2. (Read 1384 times)

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.

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.

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.

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.

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.

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

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.

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

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

Ugly isn't it?

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

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

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

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?