Quote from: nicosey on November 10, 2021, 02:02:04 PM

Quote from: Quickseller on October 29, 2021, 12:04:48 PM

At the end of the first paragraph of the "statechains" section, it says that any collusion between the "SE" and an old owner of a UTXO that results in theft of a UTXO can be trivially proven. This does not explain any consequences of this collusion. If someone were to buy up all the 0.0001 BTC UTXOs one at a time, and sell each UTXO before buying the next one, if they are colluding with the "SE" what would prevent them from being able to have a tx confirmed to an arbitrary address? I don't see anything in the documentation that would.

The "fraud proof" paragraph again says that it can be trivially proven if the "SE" is corrupt, and alludes that the ability to prove a "SE" is corrupt is an incentive to be "honest". Again, the documentation does not explain the actual consequences for the "SE" for being corrupt. The LN protocol for example, has concrete consequences for publishing an old channel state to close the channel -- the other party is able to recover the entire channel balance of both parties. There does not appear to be any financial consequences for a corrupt "SE" that I can see.

I am curious if you are in any way associated with this project.

First all mercury uses an HSM on the back end:

https://github.com/commerceblock/lockbox

The HSM deletes all the key shares for each transaction. So the HSM would have to be broken for the scenario you mention.
The latest user always has an updated "blackout transaction", therefore this is proof on who should be the current owner.

Thank you for responding. A lot of what I had posted had already been addressed/discussed by others in this thread, so there is no need to rehash those issues.

Yes, I found that repo, however I am not confident it is possible to "prove" your server is using that specific code.

Except for the issue of "blackout transactions" (below), I don't think deleting an old key or using specific code is a big deal, because as your documentation says, the statechain is signed in a way that proves if the SE is colluding with an old owner of a statecoin.

Quote from: tomt1664 on November 10, 2021, 02:59:45 PM

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

I am not sure if there is anything in the protocol that ensures the SE gave every user a "backup" closing transaction with the correct nLockTime.

The server enforces this. You must trust it to do so.

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

Step 1 says that the private key used for the backup transaction is different than the statechain private key, so if a backup transaction was broadcast and sent to the wrong address, I don't know if it could be proven the SE was acting maliciously.

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 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.