The sender can change the script of a UTXO before submitting to the blockchain

[stringhandler]

Problem:

In the negotiation of the transaction between Alice and Bob, when Bob sends the UTXO to Alice, Alice can change the script before signing the UTXO with the script offset key.

History:

This is a continuation of a discussion on PR #2988.
In the initial version of Tari script, the script and other parts of the UTXO was included in the rangeproof as beta. Due to another vulnerability noted in https://gist.github.com/DavidBurkett/b2ace786c6298179607b1337c3657a78, a signature by Alice was added to the UTXO, and beta was removed. After it was removed, it is now possible for Alice to change the script before she signs it.

Possible solutions:

1. Add beta back as suggested by PR Revert #2987 to bring back beta in the range proof #2988
2. Add a new signature, possibly a comsig by Bob that signs the script before sending it to Alice
3. Other suggestions?

[stringhandler]

I may be misrepresenting @SWvheerden and @philipr-za on this, but their view in the discussion on #2988 is that this is not an issue, and we can allow it.

Some counter points to that:

1. If the protocol/RFC does not strictly forbid Alice from changing the script, it should be viewed that it is an allowed interaction for her to change it. It should not be ambiguous whether this is allowed or disallowed, because wallets should know whether to accept this transaction or not.
2. In standard MW, Bob already can decide whether to receive the funds in a single UTXO or multiple UTXOs, if the fees would allow it (perhaps the mempool is empty), and Alice only has the power to continue with the transaction or abort. She has no power to alter, remove or combine the UTXOs Bob has chosen. If we allow Alice to change that, the power dynamic has shifted. I would suggest it makes more sense to leave the power of crafting the UTXO in it's entirety to Bob, and leaving Alice with the power of continuing or aborting
3. The original MW and tari script implementations before beta was removed had gone through rounds of review and this was not possible, so allowing Alice to change the script now feels like a regression
4. Since Alice has the power to change the script, Bob should never suggest a script at all. This could lead to the situation that the only times scripts are used is in one-sided payments and self spends. This makes interactions that could be simplified by scripts, much more complicated and involve more steps.

Lastly, this one is more of a gut feel, but Alice is mostly not going to be involved when this UTXO is spent. This may be years down the line and Bob may require a specific wallet to spend it. It feels wrong that Alice has the power to dictate how this UTXO can be spent when she has no interest in it, and will not be involved in that interaction. Bob's wallet that negotiates the transaction inherently knows it's capabilities, and will only choose scripts that it knows how to spend. Once the transaction is mined with an incompatible script, the process is irreversible, when this could have easily been avoided during the negotiation stage.

[stringhandler]

My suggestion is to add a comsig field to the UTXO instead of adding beta. I don't know all of the attack vectors on bulletproofs, so I'm not sure how solid the beta approach would be. A comsig signing the script and features would prove that the owner of the blinding factor has agreed to the script that is eventually published on the blockchain and cannot falsely accuse Alice of changing the script

[philipr-za]

I far prefer doing this using a signature meant for the job rather than the addition of Beta to the range proof as that is adding complexity to an already complex cryptographic element of a transaction where the problem is really one that a Signature should be solving.

Upfront, I will say that I agree that its addition is useful as an error checking step so that the script doesn't accidentally get mangled before the Sender publishes it. I can also see how this could be part of the strategy for when Bob needs to supply parameters for the script to Alice, to project from a 3rd party changing those parameters before Alice constructs the final transaction. I do think that when we get to those more complex negotiations we will still need to implement more security around the extra rounds of communications than this but this can contribute to that.

My critique of your points that follow is primarily due to the fact that I think we disagree on some fundamentals of the game theory of the interaction between a Sender and a Receiver.

1. If the protocol/RFC does not strictly forbid Alice from changing the script, it should be viewed that it is an allowed interaction for her to change it. It should not be ambiguous whether this is allowed or disallowed, because wallets should know whether to accept this transaction or not.

I disagree with the statement that the Protocol (between sender and receiver) doesn't strictly forbid this. This has been my contention during this entire discussion that the Receiver does not trust the Sender at all and that the only when the Receiver sees the outputs, as they expect it to be, on the blockchain can they trust it. This final verification by the Receiver is very much part of the protocol! It is how it exists in our code right now and the addition of this signature doesn't remove the need for this to be part of the protocol.

2. In standard MW, Bob already can decide whether to receive the funds in a single UTXO or multiple UTXOs, if the fees would allow it (perhaps the mempool is empty), and Alice only has the power to continue with the transaction or abort. She has no power to alter, remove or combine the UTXOs Bob has chosen. If we allow Alice to change that, the power dynamic has shifted. I would suggest it makes more sense to leave the power of crafting the UTXO in it's entirety to Bob, and leaving Alice with the power of continuing or aborting

Ok, you prefer this mental model of the interaction but because Bob can detect when Alice has not collaborated in good faith I don't think it changes the security levels at all.

3. The original MW and tari script implementations before `beta` was removed had gone through rounds of review and this was not possible, so allowing Alice to change the script now feels like a regression

The original addition of Beta was to solve a different problem (That Bob could alter his script after the transaction is in the mempool) so I don't feel like this is a material argument to whether this is needed in our current system.

4. Since Alice has the power to change the script, Bob should never suggest a script at all. This could lead to the situation that the only times scripts are used is in one-sided payments and self spends. This makes interactions that could be simplified by scripts, much more complicated and involve more steps.

This is the main statement that I disagree with because I feel like we are on different pages when it comes to what the two parties in this negotiation care about. Why would Bob ever suggest a script? Bob would always prefer a script with no conditions. It is not Bob that wants to apply the script to his output. It is ALICE that wants to apply a condition to her payment to Bob.

An application of the proposed commitment to the script by Bob could be useful in situations where Bob needs to supply parameters to Alice for inclusion in the script (such as a Public Key or a Hash) to protect those values from being interfered with by a 3rd party. But, it is not to protect Bob from Alice! If Alice were to change one of those parameters then during the final stage of verification by Bob he will not find that output on the blockchain and so will never consider the transaction complete. If Alice wants Bob to see the transaction as successfully completed she has to include the output EXACTLY as he would expect it. If she doesn't then she has essentially burned that output with no loss to Bob. In a distributed system she cannot say "Well I paid you...with this extra condition". Bob must just not accept that as a matter of course. In fact as the system is currently built his wallet will not even be able to find that output by its hash and his wallet would not have marked the transaction as complete.

Lastly, this one is more of a gut feel, but Alice is mostly not going to be involved when this UTXO is spent. This may be years down the line and Bob may require a specific wallet to spend it. It feels wrong that Alice has the power to dictate how this UTXO can be spent when she has no interest in it, and will not be involved in that interaction. Bob's wallet that negotiates the transaction inherently knows it's capabilities, and will only choose scripts that it knows how to spend. Once the transaction is mined with an incompatible script, the process is irreversible, when this could have easily been avoided during the negotiation stage.

I feel this view is incorrect. Alice is the only party who cares how Bob can spend the output (other than Bob keeping track of how he can spend it). She is the only party that would ever want Bob to have anything other than a Nop.

---

So I do see some benefits in including this change as I stated at the start of this response. I would prefer it is done as a CommSig rather than by adding a Beta to the rangeproof.

My arguments have mainly been so that we can build up a shared mental model of the dynamics and threat models of the Sender and Receiver as they interact in our decentralized system.

[SWvheerden]

I agree with @philipr-za here, I think the main "problem" point here is the power play that Alice can dictate how Bob spends "his" UTXO. Which I feel is no problem as Alice is the provider of these funds, she has the final say over what conditions it can be spent. Let us consider the following examples:

1. Alice pays Bob, her child. But she only wants him to be able to spend the money when he is 21. Therefore she gives him the money but attaches a script to block spending before he is 21. In this case, Bob cannot be allowed to change the script as he would obviously choose a script that would allow him to change it right now.
2. Alice pays Bob who is a merchant. Alice wants to be malicious here and tries to revert the payment back to herself. Alice completes the interaction but in the script, she changes the script to be, claim Pubkey bob or after 20 blocks, claim Pubkey Alice. So Bob only has 20 blocks to claim his payment. Because Bob can read the script and see that it is not the script they agreed on in the transaction dance, he considered the payment not complete. And he does not ship any goods to Alice. And this whole scheme only costs Alice fee's so she loses in the end and Bob loses nothing.
3. Let's consider Alice and Bob want a lighting channel funded by Alice. They would agree on a script for HTLC but Bob waits till the UTXO that Alice supplied has the agreed script on it and crucially is mined. Even if it forces Alice to use a singed script by Bob, there are many games Alice can play to not mine the tx. So Bob has to wait until it's mined to confirm the conditions are correct so they can start their lightning channel.

In a blockchain world, the security lies in the mined transactions, and only the mined transactions. We cannot trust any transactions that are just signed. For example what if Alice sends you a perfectly normal-looking signed transaction, with everything fine, but the utxo was already spent? The only security Bob has for his transaction to know its correct is to check if it's mined. And with this check, he does not check if Alice spent her UTXO's he checked if his UTXO's are on the blockchain. He does not check the commitment, he checks the UTXO. He does not own a commitment, he owns a UTXO that contains a commitment.

[hansieodendaal]

My suggestion is to add a comsig field to the UTXO instead of adding beta. I don't know all of the attack vectors on bulletproofs, so I'm not sure how solid the beta approach would be. A comsig signing the script and features would prove that the owner of the blinding factor has agreed to the script that is eventually published on the blockchain and cannot falsely accuse Alice of changing the script

I do not believe we would gain anything using a comsig for Bob here, just adding more space to the blockchain, as the modified Bulletproof already contains the zero-knowledge proof.

C_hat(v, k; beta) = C(v, k) + C(0, beta)
                  = (v*H + k*G) + (0*H + beta*G)
                  = v*H + (k + beta)G

Private: (v, k)
Public: C(v, k), beta, C(0, beta), Bulletproof(C_hat(v, k; beta))

In this setting knowledge about (v, k) cannot be gained by the verifier by virtue of the prover calculating a Bulletproof range proof for C_hat(v, k; beta) instead of for C(v, k), or with the prover calculating (k + beta) for the modified Bulletproof.

[hansieodendaal]

An application of the proposed commitment to the script by Bob could be useful in situations where Bob needs to supply parameters to Alice for inclusion in the script (such as a Public Key or a Hash) to protect those values from being interfered with by a 3rd party. But, it is not to protect Bob from Alice! If Alice were to change one of those parameters then during the final stage of verification by Bob he will not find that output on the blockchain and so will never consider the transaction complete. If Alice wants Bob to see the transaction as successfully completed she has to include the output EXACTLY as he would expect it. If she doesn't then she has essentially burned that output with no loss to Bob. In a distributed system she cannot say "Well I paid you...with this extra condition". Bob must just not accept that as a matter of course. In fact as the system is currently built his wallet will not even be able to find that output by its hash and his wallet would not have marked the transaction as complete.

I think this is a flaw as well in our wallet code; identification of a UTXO should be based on the value commitment alone. This is how wallet recovery works in any case; Bulletproof rewinding only looks at the ability to open the value commitment inside a UTXO, not at the UTXOs hash.

[hansieodendaal]

This is the main statement that I disagree with because I feel like we are on different pages when it comes to what the two parties in this negotiation care about. Why would Bob ever suggest a script? Bob would always prefer a script with no conditions. It is not Bob that wants to apply the script to his output. It is ALICE that wants to apply a condition to her payment to Bob.

We can never know what the out-of-band agreement between Alice and Bob will be, which will be reflected in the script as far as possible, so it is incorrect to assume Bob would always prefer a script with no conditions.

[philipr-za]

We can never know what the out-of-band agreement between Alice and Bob will be, which will be reflected in the script as far as possible, so it is incorrect to assume Bob would always prefer a script with no conditions.

As the Receiver he would though. He and Alice might come to some out of band agreement on how he will receive his payment but because it is Alice's funds that are being received by him it is in her interest to apply the script. He is the one who will be spending it in the future, not her. So for him the conditions are a nuisance. The only reason he accepts the conditions on how he can spend it is because that is his deal with Alice.

Can you name a scenario where Bob is the receiver only and would prefer a script on his output? I mean he will accept a payment from Alice with conditions if the alternative is not getting anything but he would still prefer no conditions.

[hansieodendaal]

Examples with out-of-band agreements:

• Bob needs to prove to a 3rd party that he has a time lock script on his UTXO that he receives from Alice.
• Alice sends funds to a special wallet Bob created that he will bequeath (in full) to his children:
  • It contains time-locked scripts on some UTXOs.
  • It contains m-of-n spend scripts on some UTXOs.
• Bob takes part in a betting scheme where he has to lock up some of his own funds in a different wallet he owns with an HTLC like type script and has to prove it.

[SWvheerden]

But this the great thing about a decentralized blockchain, you don't need out-of-band agreements. With all of the above examples, if the UTXO is not correct, then it did not happen.

• The proof is the time-locked utxo on the blockchain. If it's not there Bob can create one as proof for the 3rd party.
• Alice will never just send a UTXO to Bob's children if there is no external pressure to do so. This will ensure Alice chooses the correct scripts. For example, Alice is Bob's lawyer, so she has a legal obligation to do so.
• Bob is the sender here. So yes he chooses the script and has to ensure it's locked up. The betting scheme organizer can search the blockchain and be sure of his UTXO and script in it.

As with any blockchain. Of these are only provable and we know they are correct if they are mined on the blockchain. Never before.

[hansieodendaal]

@stringhandler, did the introduction of the metadata signature not close this issue, as the script Bob agrees to is signed?

[stringhandler]

100%.