[bitcoin-dev] Statechain coinswap: assigning blame for failure in a two-stage transfer protocol.

[Tom Trevethan]

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.

> 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). If users do trust
that it is doing this, then they don't need to worry about the SE being
shut down or even hacked - assuming the SE has deleted *old* keys (in the
past) then there is no way the current owner can have their funds stolen -
this is a sort of 'forward security' that makes the protocol much more
secure than a fully custodial one which stores the full key(s) at all times
(and I would argue therefore has higher trust requirements). The SE cannot
decide or be compelled to seize any specific coin without conspiring in
advance to: 1. Keep the expired key shares and 2. Collude with a previous
owner of that coin. We have designed a scheme to ensure secure deletion of
shares using HSMs, and are exploring the possibility of using remote
attestation to prove key share deletion on the HSM to users.

These are different properties compared to a federated sidechain, which
while lowering trust requirements with an m-of-n peg, remains custodial (if
the m-of-n collude at any point they can steal ALL the money, and if (n -
m + 1) are shut down/disappear then the money is gone forever). However, in
the same way as a federated sidechain, users retain a verifiable proof of
their unique ownership of a coin and must sign a peg-out transaction to
withdraw on-chain. The publication of this peg-out transaction is proof
that the current owner authenticated the on-chain spend, and so any absence
of this is a signal that the SE should not be trusted.

Cheers,

Tom

On Mon, Sep 21, 2020 at 2:14 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:

> Good morning Tom,
>
> > Hi ZmnSCPxj,
> >
> > Thanks for the reply.
> >
> > > Okay, I suppose this is much too high-level a view, and I have no idea
> what you mean by "statecoin" exactly.
> >
> > Sorry, most of the protocol details are in the links, but terminology
> should be made clearer. A "statecoin" is a UTXO that is a 2-of-2 between
> the owner and SE (the tr*sted signing server) i.e. can be transferred
> off-chain.
> >
> > Also, should have been clear that `addr1` is the 'statecoin address'
> which is different from the on-chain address (the shared public key the
> bitcoin is paid to). The on-chain address does not change, whereas
> the 'statecoin address' changes with each new owner and is used to
> authenticate owners to the SE and act as proof of ownership on
> the statechain - it is not related to the onchain address/pubkey and
> controlled by the owner only.
> >
> > > So it seems to me that this requires tr\*st that the coordinator is
> not going to collude with other participants.
> >
> > This is correct. The SE also must be trusted to not actively defraud
> users. The main advantage of this scheme is that assuming the SE can be
> trusted, it is strictly non-custodial.
> >
> > > This is strictly worse than say Wasabi, where the coordinator
> colluding with other participants only allows the coordinator to break
> privacy, not outright steal funds.
> > > It seems to me that the trust-minimized CoinSwap plan by belcher_ is
> superior to this, with reduced scope for theft.
> >
> > This is true if the overriding aim is trust minimisation, but not if the
> aim is speed and cost while staying non-custodial. Off-chain SE
> transactions are near instant and orders of magnitude cheaper than
> on-chain. Probably best thought of as a non-custodial centralised mixer.
>
>
> I think the entire point of non-custodiality ***is*** trust minimization.
>
> 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?
>
> So I think touting "non-custodial" is relatively pointless if tr\*st is
> not minimized.
>
> (I am aware there is an update mechanism, either Decker-Russell-Osuntokun
> or Decker-Wattenhofer, that is anchored off he onchain transaction output,
> but anyone who can recover the raw keys for signing the funding transaction
> output --- such as a previous participant and a corrupt SE --- can very
> easily bypass the mechanism.)
>
> For example, in my previous description of [implementing investment
> aggregation](
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-July/018055.html),
> while I admit you need tr\*st in the business owners who you are investing
> in, it does not require tr\*st in the aggregator, due to the n-of-n, which
> cannot be reconstructed by the aggregator and all other participants
> without you.
>
> Regards,
> ZmnSCPxj
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200921/5d3538a2/attachment-0001.html>