Yes, I found that repo, however I am not confident it is possible to "prove" your server is using that specific code.
It is possible (with assumptions) using remote attestation and Intel's attestation service. Trust would still be required - but in Intel and their claims about their hardware - instead of the entity running the mercury server. Note that the current version of the wallet does not verify lockbox attestations (but it could do).
The user has a private key (new one for each coin/transfer, from a BIP32 seed) that is used for:
1) their share of the 'full' private key (of the UTXO) that no-one ever knows
2) their 'proof' key, that they use to sign the statechain to authorise a transfer/withdrawal,
3) The address of the backup transaction.
The owner must sign the statechain (to the public key of the new owner) in a transfer, before the server will co-sign the backup tx and complete the key share update process. Also, in the case of a withdrawal, the owner signs with their proof key that they are withdrawing and their withdrawal address, before the server will co-sign the withdrawal tx. If there is a valid transaction that spends the UTXO, then the server should be able to produce a signature authorising that specific transaction by the owner. If they cannot, in the case that they are accused of theft/collusion, then this is indication of guilt.
So my concern would be a scenario as below:
Alice currently owns a 1
BTC statecoin issued by a Mercury server
When Alice obtain her 1
BTC 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 1
BTC statecoin to Bob for 1
BTC 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.
[/quote]
The wallet does currently use the same public key for both the b
lackout/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).