Date: Sun, 05 Apr 2020 18:24:39 +0000
To: Bob McElrath <bob@mcelrath.org>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <GfczaOA5Y47fxbr2edrFWY04-3lyviBjGT9kOIqVCtGSOC4bv068SNrCh6RCqjpA33c5twzP-hT0Ijtk0bVn-MKSMSOlDkHrwfmYi-IhuVU=@protonmail.com>
In-Reply-To: <20200405141717.GN28113@mcelrath.org>
References: <CAJvkSseW9OZ50yQiS7e0zt9tQt4v9aoikgGs_54_kMN-ORkQgw@mail.gmail.com>
 <20200331103508.asvxujkhtifj6n7i@ganymede>
 <CAJvkSsfWoTTUOUYjQDrP-xrwB8FwAGUaDKSrYX3=-+wAE3yDLA@mail.gmail.com>
 <CAJvkSseMqFUJD7rj1AAZPMy0Hf6tufkvrHFgzsViPEirWMWx_A@mail.gmail.com>
 <CALGTLwOu+R6ZmzYb4ESc9kjgrpspmmdWogF_Z=msQB8dTqD0xQ@mail.gmail.com>
 <20200405141717.GN28113@mcelrath.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Tom Trevethan <tom@commerceblock.com>
Subject: Re: [bitcoin-dev] Statechain implementations
Precedence: list

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 ho=
lder 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 coll=
ude
> 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 rec=
eiver.
> The receiver will already receive the UTXO, so the receiver here is assis=
ting
> 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 o=
perator
> 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 u=
ser key
> involved, and the user has already acquiesced to the transfer. Acquiescin=
g 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 ke=
ys (such as by digging for backups in a landfill), in order to steal the on=
chain 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 backup=
s.
* No *past* or *current* owner of the coin colludes with the statechain aut=
hority.
  * I think saying merely "sender" is not sufficient to capture the actual =
security assumption here.


Regards,
ZmnSCPxj