Just for information for people that are reading this thread without all the background, Tromp has no instance of such an attack. And I am accusing him of lying. And i am ready he puts one instance to speak about it with him.
And I mean, concrete instance that actually works and for example allows the theft of coins, using technical arguments as opposed to authority arguments, which has become a bit too frequent.
@kurt You are doing yourself no favors at all with this aggressive and confrontational approach.
Can I ask you politely to tone it down a bit. We can debate this without baseless accusations and challenges.
People are not going to take the time to debate this with you if you act like this.
I have the reasonable expectation that people use not too much autority arguments and be technologicaly honest in technical debates. Which i don’t find is the case with Tromp. Don’t expect me to act as the Dalai Lama if otherwise as it makes people losing a lot of time and it is super irritating.
Consider Bitcoin.
I create a simple transaction that spends a single output and creates a single output.
Rather than broadcasting this transaction I give the transaction to another party.
What can I do to prevent a future “play” attack from occurring on this, as yet, unspent output?
As far as I understand, this is the simplest demonstration of a “play attack”.
It is not specific to Grin. What is specific in the Grin case is the likelihood of the other party having possession of the un-broadcast transaction.
The only way to mitigate this is to spend the at risk output with another transaction.
Sounds reasonable, but another solution is to have the slates expire. Also, couldnt a play attack occur in stem phase? You may have to consider having the wallet be able to ask the node to broadcast immediately and bypass dandelion
Can you define this likelyhood?
With 1 2 3 and 4 implemented?
Also, instead of giving the transaction to another party, you can give him your private key.
Or to wait for the kernel to expire (using unique kernels) before sending again.
Ok yes that makes sense.
So without tx expiry you would be at risk indefinitely and would want to mitigate by spending.
With tx expiry you are at risk for a limited period of time after which the tx would expire. But during this window you would may still want to mitigate by spending, rather than risk waiting for expiration.
So tx expiration limits the time you are at risk, but you are still at risk during this window.
Is there a usecase to give tx to another party?
I prefer to broadcast transactions rather than giving them. Same for my private key, prefer to keep it rather than give it.
It is not a “risk” or an “attack” when you willfully interact in a transaction and at some later time you finally lose control of the UTXO. This is how it works… In fact, try interacting with most exchanges and you’ll find that this happens all the time. You regularly have to ask the exchanges to broadcast the tx (after they already suggested that they did). Everyone is responsible for the interactions they make and should be aware that there is not instant finality, making it into blocks is what matters.
If I interact with you in building a tx and partway through I tell you my computer died and we need to restart the tx building from scratch - you are at “risk”. You need to take action to mitigate this risk.
Good transaction building includes:
Please provide details Antioch with your technical claims, I discovered the play attacks and this is something I have looked into.
it would be good instead of claiming things without justification like you do here to keep it simple and be precise. Otherwise I am sorry but at some point it becomes like trolling and this is super annoying, when you have people that have spent time and energy to study the issues, participate and back their claim with precision.
I am keen to re-explain the attacks if 1. and 2. are not implemented if you want, and the reasons also why they should suffice for a good and secure transaction building that makes it to the mempool without being censored and as a consequence subject to play.
Computer dying in the middle of tx is not a risk if 1. and 2., very simple rules, are followed. You are literally imagining stuff rather than using reasoning.
To be clear, what you said above is totally false.
The only thing I’ll add here is this only works for the simple case of “1 sender -> 1 receiver”.
This cannot be guaranteed for anything involving multiple senders.
As soon as multiple senders are involved then one or more senders are susceptible to the “play attack”. Regardless of how the tx is built, somebody ends up with the finalized tx and can decide what to do with it.
One alternative might be to guarantee all participants get the finalized tx somehow, but this would presumably add significant complexity to the tx building protocol.
If you completed your side then you arent at risk. You fix your computer/wallet and it would scan for UTXOs and update to the correct balance. You know your check book balance may be different than the balance when you log-in to your bank, right? It is the interacting parties responsibilities to know they interacted and it is the blockchains responsibility to resolve the disputes. It is equally plausible to say the recipient of funds is at risk of not getting what they were promised because the tx wasnt broadcasted and instead the sender broadcasted a different TX to steal the UTXOs. The “risk” goes both ways and it is resolved on chain, that is the entire point of the chain.
There is no risk of play attacks even for multiple senders Antioch 
I can explain in another post but basically it is due to the fact that, similarly to the case 1 sender and 1 receiver you can make a round protocol where nobody knows the partial offset of the other parties.
Let me explain:
The sender, party A, chooses a random number s and gives it to party B. the party B adds his partial offset offsetB to s. he gives s + offsetB to party C. Party C does the same. Up to party D (let’s say that there are 4 parties). then D gives
x = s + offsetB + offsetC + offsetD to party A.
Then A does x - s + offsetA, which is precisely equal the total offset of the transaction.
Nobody learned the partial offsets of any other parties, making the transaction at NO risk of replay.
Again, please, for the love of God, Jesus and Mary, or TEJ, please back your claims with precise technical content. It would be super helpful.
Correct me if I am wrong @antioch @tromp but I dont believe this is what they are trying to say Kurt. You are suggesting they could steal your UTXO without a tx you willfully completed with the counter party?
I believe they are simply saying that your wallet balance will be “wrong” in the event of a “play attack” where the counter party chooses to not broadcast the final tx that you willfully participated in. In which case, you will have UTXOs that are locked up and “held hostage” by the counter party. If you restored your wallet or had another instance on another device you would show that this UTXO is apart of your balance and the counter-party could broadcast the tx and your balance would change “unexpectedly”
I’m not sure what you are arguing here. The “risk” is that an output gets spent at some time in the future.
Between (1) and (2) the output A is effectively an unknown state.
The blockchain cannot resolve any dispute until (3) occurs, possibly preceded by (2).
Between (1) and (2) you cannot know with any certainty what will happen to A.
I am using the term “at risk” here, specifically in the scenario where the recipient says they will not broadcast the tx (they claim they lost it, but maybe they lied).
To mitigate this risk and reclaim output A you can spend it, assuming the new tx is broadcast and accepted in a block before the original tx.
If A is spent to produce a new output B and no transaction is known to exist that can spend B then B is in a known state.
I think you dont understand yet what is a play attack.
It a vulmerability that is a consequence of somebody being able to censor a tx.
Please give concrete example of such case when 1 2 and 3 are implemented. Like precise.
I explained to you in the post above why your autority argument for several senders is totally wrong. Please stop using autority argument it becomes super annoying and alienating.
The big problems is when a partial offset is known by someone in the case of multiple tx, and known by the receiver in case of a tx with one sender and one receiver.
The sender should also absolutely CHECK mw tx balance before sending, because the receiver can give a dishonest offset to the sender of tx, and then the tx is refused and the receiver can learn the partial offset of the sender, which, together with the knowledge of the excess and sender tx inputs allow a play attack.
I dont consider this a risk because the sender is always in possession of the output until it is spent in a block on chain. The sender agreed to send the output so they shouldnt be surprised when it ends up on chain. If, for some reason, the recipient really doesnt want the funds and is holding the output hostage, the sender can cancel the tx in their wallet and spend it again, or wait for forever because they agreed to spend it, or use the solution that Tromp suggested if they intend on securing the output while maintaining possession of the output. All of the above are solutions, but I just dont consider it a risk or an attack for an output that I have marked to be spent ends up being spent some time in the future, I already okayed this. It would be a concern if it made it impossible to use your wallet because you need the change from that output, but that used to happen all the time when grin-wallet spent all UTXOs, so the solution was just to cancel the tx and then use the wallet, everything was secure afterwards.
At risk of what? You just consider the invoice paid unless it officially expires. What is the real concern with play attacks? I thought it was that the receiver could arbitrarily play the transaction far in the future after claiming it failed? Just forbid canceling the transaction unless it’s expired (and shorter expiration times could be used for invoices, if necessary).