Each time a statecoin is transferred, the backup transaction used in the event the SE becomes uncooperative has the nLockTime value decline by one.
There is nothing saying the nLockTime value must decrease by 1, and indeed, doing so leaves it open for previous owners to steal transactions which are RBF enabled.
Additionally, the transfer can incorporate the cooperative signing of a new backup transaction paying to an address controlled by Owner 2 which can be confirmed after an nLocktime block height, which is shortened (by an accepted confirmation interval) from the previous owners backup transaction nLocktime.
You're right.
It does appear that the nLockTime interval is done on the server level, not protocol level. I have never coded in rust, so I am having a little difficultly following what is happening, however there is a
config file that appears to set the nLockTime interval as an integer, and according to the [ur=https://github.com/commerceblock/mercury/blob/a78f57c24cd4a8d80d760ad0040f1fcf09c039ec/server/Settings.toml]settings file[/url] it is prefilled to 10 blocks, but is set to 100 by default if it is not in the settings file.
Also lower transaction costs and liquidity provided by third parties, but that benefits the service more than the users.
I suppose the next question is what fees are Mercury going to be taking for running this service? They don't actually have any transaction costs as far as I can see, since the person depositing the coins to the split key address pays the transaction fee there, and the person ultimately withdrawing the coins will pay the transaction fee on that end. But they will obviously need to pay for running and maintenance of there servers. And when is that fee taken? There's a privacy implication there too if a deposit or withdrawal transaction also has to pay a small amount to an address which can be identified as belonging to Mercury.
Also in the settings file is a fixed address for "fees" to be received at. It is unclear how the fees are paid.
If this is a centralized service using a protocol they designed, it would resolve most of my concerns. Although one concern that would remain would be the fact that I was attacked by a shill when I tried to ask questions.
You made up the nonsense about the wallet connecting to random fraudulent nodes, and the shill accusation. Don't expect everyone to just roll over and not talk back when you do shit like that.
I'm sorry, but asking questions is not making up nonsense.
I do think it is strange that dkbit98 starts attacking me when I ask questions about a project asking to be trusted with people's money. If you disagree, then you are blinded by your bias.