From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Bob McElrath <bob@mcelrath•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Cc: Tom Trevethan <tom@commerceblock•com>
Subject: Re: [bitcoin-dev] Statechain implementations
Date: Sun, 05 Apr 2020 18:24:39 +0000 [thread overview]
Message-ID: <GfczaOA5Y47fxbr2edrFWY04-3lyviBjGT9kOIqVCtGSOC4bv068SNrCh6RCqjpA33c5twzP-hT0Ijtk0bVn-MKSMSOlDkHrwfmYi-IhuVU=@protonmail.com> (raw)
In-Reply-To: <20200405141717.GN28113@mcelrath.org>
Good morning Bob,
> Note that this attack requires collaboration with the current UTXO owner.
> Generally if there's some form of address/payment request, the current holder is
> trying to transfer the UXTO to some other (non-statechain) entity, and he knows
> the target of the transfer, and participates in the protocol to authorize it.
> The current holder must obtain the target pubkey for the transfer out-of-band
> with respect to the SE, or the SE can MITM that.
>
> It's a stated security assumption that the sender or receiver do not collude
> with the SE. If either do, then your attack is generally possible and all bets
> are off. So what you've described is simply the SE colluding with the receiver.
> The receiver will already receive the UTXO, so the receiver here is assisting
> the SE in stealing his (the receiver's) funds, or the SE has done a MITM on the
> transfer. Various improvements including blind signing, a SE-federation, etc
> are valuable to consider to mitigate this. But the SE must be prevented, one way
> or another, from "buying the UTXO". The SE cannot be allowed to be both operator
> of the SE and a customer of it, as this clearly violates the no-receiver
> collusion principle.
>
> "Adding a new user key" doesn't change the situation. There's already a user key
> involved, and the user has already acquiesced to the transfer. Acquiescing with
> two keys doesn't change anything.
The point is not that acquiescing with two keys is possible.
Instead, the point is that any past owner of the coin can collude with the statechain authority (who, in the new scheme, must be trusted to delete old keys), or anyone who manages to get backups of the statechain authority keys (such as by digging for backups in a landfill), in order to steal the onchain funds, regardless of who the current owner is, within the statechain.
Thus an amount of trust must still be put in the statechain authority.
So I think the security assumptions should be that:
* The statechain authority really does delete keys and does not make backups.
* No *past* or *current* owner of the coin colludes with the statechain authority.
* I think saying merely "sender" is not sufficient to capture the actual security assumption here.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2020-04-05 18:24 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-25 13:52 Tom Trevethan
2020-03-26 1:20 ` ZmnSCPxj
2020-03-26 3:55 ` Albert
2020-03-26 12:36 ` Ruben Somsen
2020-03-26 17:12 ` Christian Decker
2020-03-26 17:17 ` Greg Sanders
2020-03-26 18:53 ` Ruben Somsen
2020-03-27 1:46 ` ZmnSCPxj
2020-03-27 15:12 ` Ruben Somsen
2020-03-28 2:20 ` ZmnSCPxj
2020-03-26 14:52 ` Bob McElrath
2020-03-27 17:10 ` Bob McElrath
2020-03-28 2:42 ` ZmnSCPxj
2020-03-28 17:38 ` Ruben Somsen
2020-03-28 17:42 ` Ruben Somsen
2020-03-30 1:25 ` ZmnSCPxj
2020-03-31 10:35 ` David A. Harding
2020-03-31 11:41 ` Tom Trevethan
2020-04-02 22:56 ` Tom Trevethan
2020-04-03 16:37 ` Nadav Kohen
2020-04-04 12:07 ` ZmnSCPxj
2020-04-05 14:17 ` Bob McElrath
2020-04-05 18:24 ` ZmnSCPxj [this message]
2020-04-05 21:25 ` Tom Trevethan
2020-05-07 14:54 ` Tom Trevethan
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='GfczaOA5Y47fxbr2edrFWY04-3lyviBjGT9kOIqVCtGSOC4bv068SNrCh6RCqjpA33c5twzP-hT0Ijtk0bVn-MKSMSOlDkHrwfmYi-IhuVU=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=bob@mcelrath$(echo .)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