@JOFLITO 's query: Bob can verify Alice’s tx. Since Bob’s box already enforces the script of Alice’s tx output. He only needs to check:
- script in the output box is correct
- tx is accepted as valid by node without broadcasting (can also be mocked via app-kit)
Analysis and Fixes
Consider the following possible attacks for the original proposal:
- From Bob’s point of view, Alice should not be able to broadcast an older tx and get away with it.
- From Alice’s point of view, Bob should not be able to broadcast an older tx and blame Alice for it.
(in case I missed any, please let me know)
Attack 1. can be prevented in the same approach as in standard payment channels, using a dispute mechanism. However, it doesn’t prevent 2.
In order to prevent 2 and to have an trustless dispute resolution, the following modification is proposed:
Trustless dispute resolution
Bob’s box script is modified as follows:
- Instead of multiple bob-tokens, we instead have a singleton token, an NFT (called bob-NFT) to identify the box.
- When spending the box, the NFT must be stored in an unspendable Receipt box. Unspendable implies that its script is simply the proposition
false. - The Receipt box’s R4 contains the Schnorr signature of Alice on the value x, which is the value being transferred.
- The spender is Alice
Alice’s box script is modified as follows (for the path before height h):
- There is a data input with script
falseand bob-NFT - The context variable 0 contains a Schnorr signature on some value x by Alice.
- Exactly x assets are sent to Bob and remaining to Alice
- The spender is Bob.
Considering the attacks again, if Alice broadcasts an older tx, with less amount, it does not matter because while spending Alice’s box, Bob should provide the newer Schnorr signature in the context variable, which is set by the spender.
Bob cannot later blame Alice because he is responsible for providing the correct signature at the time of spending