0 conf issues

[Gingeropolous]

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]

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]

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]

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]

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