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: Mon, 21 Sep 2020 01:14:29 +0000 [thread overview]
Message-ID: <TC2UtcaDKCIkjtn41sIutqApciyqaGCD3SBSEWLBk4OT12siSkWIsp2LMmlmA0CLzUNuG1W8w-hB4Pq3ko1uGwbxpjxezFWKPq4C7OLUQo8=@protonmail.com> (raw)
In-Reply-To: <CAJvkSse5GDxzrDc0OeNSoHV90tsSvr-oCgY_P+p4O4T6PDUNpA@mail.gmail.com>
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 prev parent reply other threads:[~2020-09-21 1:14 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 [this message]
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
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='TC2UtcaDKCIkjtn41sIutqApciyqaGCD3SBSEWLBk4OT12siSkWIsp2LMmlmA0CLzUNuG1W8w-hB4Pq3ko1uGwbxpjxezFWKPq4C7OLUQo8=@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