Re: [bitcoin-dev] Statechain coinswap: assigning blame for failure in a two-stage transfer protocol.

[ZmnSCPxj <ZmnSCPxj@protonmail.com>]

Good morning Tom,

> Hi ZmnSCPxj,
>
> > The SE can run in a virtual environment that monitors deletion events and records them.
> > Such a virtual environment could be set up by a rootkit that has been installed on the SE hardware.
> > Thus, even if the SE is honest, corruption of the hardware it is running on can allow recovery of old privkeys and violation of the tr\*st assumption.
>
> This is true, but this threat can be mitigated with secured infrastructure and the use of hardware security modules/trusted execution environments that enable secure (and potentially attestable) deletion. 
>
> > Compare this to, for example, TumbleBit or Wasabi.
> > In those cases, even if the service providing the mixing is corrupted by a rootkit on the hardware running the honest service software in a virtual environment and monitoring all its internal state and communications, they cannot lead to loss of funds even with cooperation of previous participants.
> >They can at most be forced into denial-of-service, but not outright theft of coins.
>
> Yes, I agree. But on the other side of the scale is a comparison with centralised mixing services, which remain extremely popular. 
>
> > I admit the new solution is superior blockspace-wise, if you consider multiple mixing rounds. 
>
> The aim of the solution is to replicate the UX (in terms of speed) of a completely centralised mixer (i.e. where the server(s) explicitly holds the full key(s) to the deposits being swapped) but in a way that makes theft more difficult (requiring collusion with previous owners), has an in-built mechanism for users to get back their funds if the service is shut down/blown-up, provides users with proof of ownership/theft, and with the same privacy guarantees as the above mentioned trust-minimised protocols. 

I believe the slowness of TumbleBit and Wasabi have less to do with security than with gathering enough participants to get a reasonable anonymity set.

If the statechain entity itself does not participate and put up funds that its clients can acquire quickly, than a similar waiting period would be necessary anyway to gather enough participants to make the swapping worthwhile.
This would then fail your goal of speed.

If the statechain entity *does* act as a participant, then a client could acquire a new coin fairly quickly (as the statechain entity would be a "participant of last resort" with which it could swap right now), but the "previous participant" in that case would be the statechain entity itself, making its ability to outright steal funds absolutely certain, and thus not much better than a mixer that provides "put money in this address, I will send you money in your address" service.
(unless I can do a cut-and-choose on the hardware, i.e. buy multiple instances and reverse-engineer all except a randomly-selected one to check for hardware defects that may allow extraction of privkeys, and then use the hardware that remains, I do not think the security of TEEs/HSMs is at all high.
And the TEE/HSM would be directly possessed by the statechain entity and not me, presumably I as client of the statechain entity cannot audit that, so ---)

If you are going to have a maker-taker model, where takers spend money to get immediate swaps for the time that makers spend waiting, then I suggest that the SwapMarket plan by Chris Belcher would only require some number of confirmations of various transactions to get superior security, which would be a better tradeoff than what statechains provide.



Regards,
ZmnSCPxj