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: Tue, 22 Sep 2020 01:00:43 +0000 [thread overview]
Message-ID: <KRJoyx0BjttYJnlGVY3hu2T_1bTPcpU1Vq639OYyQptXx6Xm0vkrCN-23ngBK3fs0ti2dT4i4LHIxOaxqNMACJ9N27jPqoPqzaBpxiOIH8s=@protonmail.com> (raw)
In-Reply-To: <CAJvkSseWZYH-dOvkFXmtKJgJOfv09La8sTb4e+2nvZYKTxNafg@mail.gmail.com>
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
next prev parent reply other threads:[~2020-09-22 1:00 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 [this message]
2020-09-22 15:32 ` Tom Trevethan
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='KRJoyx0BjttYJnlGVY3hu2T_1bTPcpU1Vq639OYyQptXx6Xm0vkrCN-23ngBK3fs0ti2dT4i4LHIxOaxqNMACJ9N27jPqoPqzaBpxiOIH8s=@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