From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Tom Trevethan <tom@commerceblock•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: Thu, 24 Sep 2020 00:19:48 +0000 [thread overview]
Message-ID: <CYPuSF4lMyhP0L21Z5fC45i_nIMdh2XLrFio4-BE3ci6YQ5CYbpjjq-aaimP3AuwND4ah6yN5PWcDGuKvg_jkBxwsXA9aWfQmK9YjJrB-RA=@protonmail.com> (raw)
In-Reply-To: <CAJvkSsfJ-ep_WA1gCCBUeLUF4FKoXiCQ+t+c6KnOUQx8xEbH_Q@mail.gmail.com>
Good morning Tom,
> 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.
I believe the slowness of TumbleBit and Wasabi have less to do with security than with gathering enough participants to get a reasonable anonymity set.
If the statechain entity itself does not participate and put up funds that its clients can acquire quickly, than a similar waiting period would be necessary anyway to gather enough participants to make the swapping worthwhile.
This would then fail your goal of speed.
If the statechain entity *does* act as a participant, then a client could acquire a new coin fairly quickly (as the statechain entity would be a "participant of last resort" with which it could swap right now), but the "previous participant" in that case would be the statechain entity itself, making its ability to outright steal funds absolutely certain, and thus not much better than a mixer that provides "put money in this address, I will send you money in your address" service.
(unless I can do a cut-and-choose on the hardware, i.e. buy multiple instances and reverse-engineer all except a randomly-selected one to check for hardware defects that may allow extraction of privkeys, and then use the hardware that remains, I do not think the security of TEEs/HSMs is at all high.
And the TEE/HSM would be directly possessed by the statechain entity and not me, presumably I as client of the statechain entity cannot audit that, so ---)
If you are going to have a maker-taker model, where takers spend money to get immediate swaps for the time that makers spend waiting, then I suggest that the SwapMarket plan by Chris Belcher would only require some number of confirmations of various transactions to get superior security, which would be a better tradeoff than what statechains provide.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2020-09-24 0:19 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
2020-09-24 0:19 ` ZmnSCPxj [this message]
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='CYPuSF4lMyhP0L21Z5fC45i_nIMdh2XLrFio4-BE3ci6YQ5CYbpjjq-aaimP3AuwND4ah6yN5PWcDGuKvg_jkBxwsXA9aWfQmK9YjJrB-RA=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=tom@commerceblock$(echo .)com \
/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