ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2020-09-21 📝 Original message:Good morning Tom, > Hi ...
📅 Original date posted:2020-09-21
📝 Original message: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
📝 Original message: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