Quote from: nicosey on Today at 09:48:23 AM

Quote from: Quickseller on November 17, 2021, 06:51:43 PM

Quote from: tomt1664 on November 17, 2021, 01:21:28 PM

Quote from: Quickseller on October 31, 2021, 01:40:48 PM

So my concern would be a scenario as below:

Alice currently owns a 1BTC statecoin issued by a Mercury server
When Alice obtain her 1BTC statecoin, she also received a "blackout transaction" with an nLockTime expiration of block 710,000.
Alice and the Mercury server agree to collude with eachother to steal the statecoin, so they create a new "blackout transaction" with an nLockTime expiration of 709,050
Alice "sells" her 1BTC statecoin to Bob for 1BTC that is transferred on-chain.
As part of the above transfer, Alice uses her private key to sign the Statechain with Bob's public key, and with the help of the Mercury server, creates a "blackout transaction" payable to Bob's "blackout" address that is different and distinct from the public key she just signed. The "blackout transaction" payable to Bob has a nLockTime expiration of block 709,994 (710,000 minus 6).
Now Alice has a "blackout transaction" with a nLockTime expiration of 709,050 and Bob has a "blackout transaction" with a nLockTime expiration of 709,994.

If Alice were to broadcast her "blackout transaction" at block 709,065, based on the current protocol, there is no way for Bob to prove he had been scammed.

Using the same public key for both the "blackout transaction" output, and as documentation to be the "owner" of the statecoin would be one way to address the above issue. This issue could also be addressed by having the output address of the "blackout transaction" and the nLockTime expiration be "signed" and be part of the statechain.

The wallet does currently use the same public key for both the blackout/backup transaction output and the statechain signature - and this is the intended rule - so that there should always be a statechain signature from the current owner corresponding to the address of every backout transaction that is co-signed (withdrawal txs require that the destination address is signed by the current owner for this exact reason).

Perhaps I am misunderstanding something. I found this in the documentation, specifically under the "transfer" section, step 1:

Quote

The receiver (Owner 2) generates a backup private key b2 and a statechain (proof) private key c2 (separate keys are used for privacy). They then compute the corresponding public keys B2 = b2.G and C2 = c2.G.

My reading of the above makes me believe the statechain will be signed with one key and the "blackout" transaction will be sent to another key.

Apologies the documentation is out of date. We realised there were no privacy issue here so are fine with the statechain using the same key as the blackout TX.

Great! That is the last of my concerns. Obviously you will need to earn trust in order for people to be willing to use your service. With that change, I don't believe it would be possible for you to steal money without the end user being able to prove the theft.