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

[Tom Trevethan <tom@commerceblock.com>]

[-- Attachment #1: Type: text/plain, Size: 4679 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 5488 bytes --]