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.

Cheers,

Tom

On Tue, Sep 22, 2020 at 2:00 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

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