DEROHE potential UX issue of outdated CLn and CRn when different users create multiple txs with same recipient ring members

Proposals
#1

hi dero. We have reviewed your code again, and we noticed a potential issue for user transactions. It is not a security issue, but more a User Experience bug when multiple users do transactions with common recipient ring members and most transactions will fail.

Let’s say we have two distinct users (user1, and user2) that will create each a tx payload (tx1 respectively tx2) with one common recipient ring member (same receiver for example, let’s suppose it is ring member i which is common in both txs ). Both users, will load the same ElGamal encrypted balances CLn[i] and CRn[i] when signing the tx (generating zk proofs). So both users will generate zether proofs for same the same homomorphic balance ( CLn[i] and CRn[i] ). Let’s say user1 will publish with 1 second the tx faster than the user2. So, user1 tx payload will get validated and get included in the mempool, while user2 tx will get rejected because the CLn[i] and CRn[i] from tx2 is outdated as the user2 tx should use the updated versions of CLn[i] and CRn[i] from the user1 (namely CLn[i] + C_tx1[i], CRn[i] + D_tx1 ) . So, the user2 tx will get rejected and he will have to recreate the transaction.

This is a simple scenario with just two users. Just think, for an NFT or ICO, when at the launch hundreds of users will want to send transactions to the same recipient. All of these users (except the first user), will get the same error because their transactions will have outdated CLn[i] and CRn[i].

Let me know about this. Am I missing anything ?

thanks for your time

#2

Single block can have multiple transactions for single receiver without any issues however senders need to be different for those transactions.
Single sender cannot send multiple transactions in single block but single sender can create single transaction with multiple receivers.

#3

Thanks for the reply! Maybe you didn’t understand my question. A block can have multiple transactions with same recipient, but here is the question I am asking. Let’s say two users create and sign transactions in the same time (simultaneously) that have the same recipient. Both of these users, fetch identical CLn[i[ and CRn[i] from the balance tree for the same recipient. Wouldn’t one tx be rejected because both of them have the same CLn[i] and CRn[i] ?

If so, how do you exactly solve it as I am missing something. Thanks

#4

Yes, One transaction will be rejected. This all depends on the probability, Bigger the network less are the chances of TX rejection.

#5

This is also what I understood from the code. It could be a major issue when there would be a mass adoption and tokens ICOs, NFTs launches or popular DEX smart contracts

Bigger the network less are the chances of TX rejection.

Not really. I was not talking about ring members, but real recipients. For example, at 12 noon, there is an NFT launch and thousands of people would like to send coins to get these NFTs. It will be the same address and all transactions except the fastest one will get through.

#6

We also came up with a simple solution that might solve this bottleneck. But there are a few assumptions which need to be verified… Would you be interested ?

1 Like
#7

You are more than welcome to suggest.