search

amiuhle / kasisto

A Monero Point of Sale payment system
https://amiuhle.github.io/kasisto/
MIT License
159 stars 39 forks source link

0 conf issues #30

Open Gingeropolous opened 6 years ago

Gingeropolous commented 6 years ago

It might be possible for a bad actor to submit a transaction to the network that never has a chance of being mined. Currently, a transaction that has too low of a ringsize is still relayed through the network, so it will look like a valid transaction waiting in the txpool to get mined into a block. However, it will never get mined into a block.

Also, kasisto should have a way of verifying that a transaction has been relayed to some other nodes - a quorum of random nodes. Just because a transaction is in the kasisto's daemon's txpool doesn't mean it will relay - I'm imagining a scenario where the customer uses the kasisto's daemon as a remote node to push a transaction. A transaction with too low of a fee will just get stuck on the kasisto's daemon, so it looks like a 0 conf, but it will never get mined.

amiuhle commented 6 years ago

Thanks!

Monerujo's minimum ringsize is 5, are there any mobile wallets allowing a lower ringsize? I'm going to check monero-project/monero for pending issues on that and submit one if necessary.

As for your second point, the setup instructions will recommend running your own daemon. The perfect setup would be to run the node on your local network, but even if it's on a VM that's acessible from the internet monerod should not be a listening on the public IP. Again, the user will be restricted to the possibilities of mobile wallets out there. Since a new payment id is used for every payment, a bad actor can't prepare a transaction beforehand, he would have to do all this while making the payment.

Gingeropolous commented 6 years ago

Monerujo's minimum ringsize is 5, are there any mobile wallets allowing a lower ringsize?

No... but who knows what people will develop and hack and use?

iamsmooth commented 6 years ago

I'm imagining a scenario where the customer uses the kasisto's daemon as a remote node to push a transaction

This greatly increases the risks and should not be done. If a remote node is to be offered for customer service purposes it should not be the same node used for receiving payments.

You do raise a good point about transactions that might not get mined, for example because the fee is too low. We don't have any kind of CFPF to help push the transaction along as exists in Bitcoin.

emesik commented 6 years ago

Shouldn't we identify ways of generating invalid transactions, and update the daemon's checking code to purge them from mempool ASAP?