Hacker News Reader

Comment by PinguTS | Hacker News Reader

Even the double spending problem is not really resolved. Just with the current theft, there are recipes posted[1] on how to recover the stolen IOTA by basically enforcing the double spending and trying to give your spending a higher priority than the fraudulent transactions had. That means fraudulent transaction could try this themselves and just need to exploit that race condition. That means a fraud needs to somehow collect the data on pending transactions and just need to issue their own ones with the known collision problem on the hash.

[1] https://www.inowrx.de/iota-stolen-iota-stop-pending-unconfir...

View on HN

You're conflating a lot of things here. Racing a fraudulent transaction to have a legitimate one confirm faster is not a double spend, like at all. Up until the moment one of the transactions confirms, no funds have changed hands. What you're also conflating is the fact that the hash collision has no influence on transacting funds in the first place. The DCI report recently released their vulnerability exploiting code which demonstrated, that in order to actually use colliding transaction hashes to create fraudulent transactions, the fraudulent party would have to have access to the seed at which point the whole thing becomes moot anyway. Adding to all this, the hashing function has long since been replaced, further compounding the moot-icity.

Is not a race a way to delay individual transactions and essentially an DOS for targeted members of the network?

For the double spend to occur, you would need access to the seed ( private key) which the victims had and are trying to outrun the attacker in the case you were describing.

Still not a double spend.

>For the double spend to occur, you would need access to the seed ( private key) which the victims had and are trying to outrun the attacker in the case you were describing.

So it works a bit like replace-by-fee on bitcoin? There is no mining on IOTA so what is the possible time frame? do you have more detailed technical information how this works? Thanks

New transactions are selected randomly to be verified. So in case the attackers transaction is still not confirmed there is a chance to outspend him by having the private keys. I find this useful in understanding the confirmation/consensus mechanism. https://forum.iota.org/t/iota-consensus-masterclass/1193

You know how hash collisions work and why it is important to have an hashing algorithm for which it is hard to enforce collisions.

It is so you do not need to know the private key. So that you can forge fraudulent transactions without knowing the private key.

Reply on news.ycombinator.com