From: Tom Trevethan <tom@commerceblock•com>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Statechain coinswap: assigning blame for failure in a two-stage transfer protocol.
Date: Tue, 22 Sep 2020 16:32:06 +0100 [thread overview]
Message-ID: <CAJvkSsfJ-ep_WA1gCCBUeLUF4FKoXiCQ+t+c6KnOUQx8xEbH_Q@mail.gmail.com> (raw)
In-Reply-To: <KRJoyx0BjttYJnlGVY3hu2T_1bTPcpU1Vq639OYyQptXx6Xm0vkrCN-23ngBK3fs0ti2dT4i4LHIxOaxqNMACJ9N27jPqoPqzaBpxiOIH8s=@protonmail.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 --]
next prev parent reply other threads:[~2020-09-22 15:32 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-13 22:14 Tom Trevethan
2020-09-16 1:04 ` ZmnSCPxj
2020-09-21 0:54 ` Tom Trevethan
2020-09-21 1:14 ` ZmnSCPxj
2020-09-21 21:52 ` Tom Trevethan
2020-09-22 1:00 ` ZmnSCPxj
2020-09-22 15:32 ` Tom Trevethan [this message]
2020-09-24 0:19 ` ZmnSCPxj
2020-09-21 22:18 ` Karl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJvkSsfJ-ep_WA1gCCBUeLUF4FKoXiCQ+t+c6KnOUQx8xEbH_Q@mail.gmail.com \
--to=tom@commerceblock$(echo .)com \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox