The server is configured to run on testnet, not mainnet, which is important because the server interacts with the network in order to collect fees. It has support for configuring it to run on mainnet later but it is not set to do so right now.
Client software could ask the testnet server to sign a mainnet tx, and since the server is blind, it wouldn't know the difference, but the Mercury CTO seems confident that no one is doing this yet:
"there were no mainnet users, so no funds were at risk" source
They keep records of signature requests and they can probably see that basically the only people requesting signatures from Mercury's server are their own testers. Certainly there is no publicly released client software configured for mainnet so it's unlikely a significant number of people modified the software to run on mainnet, and if they did, that's on them.
reply
Certainly there is no publicly released client software configured for mainnet
The mercury client code can be configured to use mainnet statecoins by simply setting
network = "bitcoin" in the client's Settings.toml file, so it's not that hard to set up. In fact, to demonstrate the vulns to mercury I double-spent some mainnet coins after ostensibly "transferring" the statecoin UTXO to Tom. But it would take a conscious effort to do that, in spite of blatant warnings to the contrary.Really I have no idea if there are any mainnet users, but I find it unlikely. See tom's post below for more info
reply
Client software could ask the testnet server to sign a mainnet tx, and since the server is blind, it wouldn't know the difference, but the Mercury CTO seems confident that no one is doing this yet:
Sure, if you’re vendor and there are plausible vulnerabilities affecting your soft, this can be very pragmatic to downside funds exposed. Giving time to people to deploy the fixes.
I don’t wish to sound too harsh on conduition here, I believe it’s great to have more folks doing vulnerabilities hunting in the ecosystem. On the other hand, in infosec rule of thumb is often to give 90 days to vendors. Unless there are clear hints that vendors do not wish to implement mitigations (or mitigations cannot be deployed easily).
I know 90 days can be a lot, so even if you think circumstances are worthy of less, in my opinion nothing displayed in the disclosure report warrants to give only 4 days to the vendors.
As of today, it’s indeed quite easy to go and burak a bitcoin L2. But I don’t think it is the culture we wish to nurture on the long-term in the ecosystem, if we wish seriously to take care of end-users financial wealth (or privacy). Failing to do so, that’s only going slowly towards the path were vulnerabilities are weaponized for other purposes...
reply
We are not aware of anyone else using the code or deploying a server.
The nature of blinded server means that we can't tell if it's being used for mainnet or testnet, but we run two public servers: One 'test' server that isn't secured and gets restarted regularly, and is free to use - we are clear in our docs that no-one should use this server for real money. This gets quite a bit of use.
We also run a 'production' server that is deployed using secured and replicated bare metal hardware - this currently requires a LN fee to use. We were considering this 'production ready' for an app that is being worked on, but it has not been advertised for public use.
So far, the only use of this server has been us testing it - so I believe we can be very confident that there were no user funds at risk.
reply
P1 = O1 + S1). If the statecoin is spent as a happy path, there shall be no mark in the blockchain logs.