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@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