Good morning Tom,

> Hi ZmnSCPxj,
>
> > I think the entire point of non-custodiality ***is*** trust minimization.
>
> There are also legal and regulatory implications. It is much easier for a 
> service to operate without requiring its users to be KYCed if it is 
> non-custodial and funds cannot be frozen/seized. 

Complying with the letter of the law without complying to its spirit seems 
rather hair-splitting to me.

Ideally, a law regarding any financial mechanisms would judge based on how much 
control the purported owner has over the actual coin and what risks it would 
entail for them, and protect citizens against risk of damage to their finances, 
not focus on whether storage is "custodial" or not.

So I still suggest that, for purposes of technical discussion, we should avoid 
the term "custodial" and instead consider technical risks.

>
> > The main objection against custodiality is that someone else can prevent 
> > you from spending the coin.
> > If I have to tr\*st the SE to not steal the funds, is it *really* 
> > non-custodial, when after a swap, a corrupted SE can, in collusion with 
> > other participants, take control of the coin and prevent me from spending 
> > it as I wish?
>
> I would argue that it is non-custodial if the SE performs the protocol as 
> specified (i.e. securely deleting expired key shares).

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.

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.

Thus, I believe this solution is inferior to these older solutions, at least in 
terms of financial security.

I admit the new solution is superior blockspace-wise, if you consider multiple 
mixing rounds.
However, multiple mixing rounds under this solution have increased exposure to 
the risk of theft noted above, and thus it would be better, risk-wise, to 
immediately withdraw after every round, and potentially seek other SEs (to 
reduce risks arising from a particular SE being corrupted), thus obviating the 
blockspace savings.


The above remain true regardless of what definition of "custodial" you have.

Regards,
ZmnSCPxj
_______________________________________________
bitcoin-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Reply via email to