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 <zmnsc...@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 >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
