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 _______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
