4 ms·

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

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-unconfirmed-transactions-try-to-rescue-your-iota-wallet/ https://www.inowrx.de/iota-stolen-iota-stop-pending-unconfir...

etunity 9y ago
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.
- smrtfckr 9y ago
  Still not a double spend.
- elmar 9y ago
  >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
  - etunity 9y ago
    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 https://forum.iota.org/t/iota-consensus-masterclass/1193
- PinguTS 9y ago
  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.
smrtfckr 9y ago
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.
- kruhft 9y ago
  Is not a race a way to delay individual transactions and essentially an DOS for targeted members of the network?

etunity 9y ago

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.

smrtfckr 9y ago
Still not a double spend.
elmar 9y ago
>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
- etunity 9y ago
  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 https://forum.iota.org/t/iota-consensus-masterclass/1193
PinguTS 9y ago
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.

smrtfckr 9y ago

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.

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