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

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

[Tom Trevethan]

[-- Attachment #1: Type: text/plain, Size: 5237 bytes --]

We are designing an off-chain coin-swap protocol that will work with the
statechain implementation we are developing (
https://github.com/commerceblock/mercury). The general idea is that coins
deposited with a statechain entity (statecoins) can be transacted
peer-to-peer off-chain in a way that the statechain entity (SCE) is
trusted, but the statecoins always remain in the custody of the owners. A
statecoin swapping service would enable owners to mix their coins with
other users, giving the same privacy benefits of on-chain CoinSwap
protocols, but by being off-chain statecoin swaps would be much faster and
cheaper.

The swapping service (conductor) would not have custody of the statecoins
at any point. The aim is to have the conductor coordinate the swap amongst
a group of statecoins (i.e. determine the which statecoin should be sent to
which new random owner in the group) without being able to learn the link
between owners and their provided addresses. To do this we will use a blind
signature scheme in a similar way to the zerolink protocol.

Here is a high-level description of how this blinding can operate - with
the aim that the conductor does learn how the ownership of individual coins
has changed.
For example, imagine 4 individuals (A,B,C and D) who own equal value
statecoins utxo1, utxo2, utxo3 and utxo4 respectively. They want to swap
ownership privately, trusting the conductor/SCE to enforce atomicity. In
other words, the conductor will randomly assign each statecoin to one of
the owners (the mix), but will not be able to gain knowledge of that
assignment.
1. A,B,C and D signal their participation by signing the swap_token (which
has details of the swap) with the proof-key of their input coin. (A
statecoin address is formed of a concatenation of the proof key and backup
address).
2. Each of A,B,C and D then generate a new statecoin address (where they
what to receive the swapped coin), which they blind (encrypt) and sign with
the proof key of their input coin: add1, add2, add3 and add4 and send to
the conductor.
3. The conductor authenticates each signature and then signs each payload
(i.e. the blinded destination addresses) with a blinded signature scheme
and returns these signatures to A,B,C and D.
4. Each of A,B,C and D then reconnects over TOR with a new identity.
5. Each of A,B,C and D then send their unblinded destination address with
the conductor signature to the conductor (the conductor now knows that
these 4 addresses belong to A,B,C and D, but not which ones map to each
input.)
6. The conductor randomly assigns each address to one of utxo1, utxo2,
utxo3 and utxo4 (e.g. utxo1:add3, utxo2:add1, utxo3:add4 and utxo4:add2)
and requests each participant to initiate the transfer to the given
address.
7. Each participant then finalises each transfer - if any transfer fails
(due to a participant disappearing or acting maliciously) then all
transfers are reverted - here atomicity is guaranteed by the SCE.

The interesting problem we have with this protocol is how to assign blame
in the case that one or more participants in the swap causes it to fail, so
that the corresponding statecoins can be penalized (prevented from
participating in further swaps for some timeout) to make any DoS attack
costly. In the case of an on-chain coinjoin, this is easy: whoever didn't
sign their input is to blame. However, in our statechain system a statecoin
transfer is a two stage process (to update the private key shares): the
sender performs an operation with the SCE (transfer_sender) and then sends
an encrypted value to the receiver, who then performs the second operation
with the SCE (transfer_reciever) which updates the UTXO private key shares
for the new owner (
https://github.com/commerceblock/mercury/blob/master/doc/statechains.md for
more details). If the second stage fails (i.e. the values used for the key
update protocol are wrong) this could be due to either the sender sending a
bad/manipulated value to the receiver, or the receiver using bad values in
the second operation with the SCE. Essentially, either the sender or the
receiver can cause the transfer to fail, and it is not possible to
determine which one is malicious without revealing the encrypted value sent
between the sender and receiver (which must be kept secret from the SCE).

All this means that if a multi-party coinswap fails, we will know which
statecoin was involved in the failure, but we cannot determine whether the
sender or receiver of that coin caused the failure. One potential solution
to this is to have each sender generate a zero knowledge proof that the
encrypted value sent to the receiver is correct/valid (see last section in
https://github.com/commerceblock/mercury/blob/master/doc/swaps.md for more
details) which can be used to assign blame in a failure. This proof could
be generated and verified using a zkSNARK/zkSTARK framework, but this is
not trivial to implement and would likely add significant computational
burden to user wallets to generate proofs - so we would like to avoid this
if possible, and we are trying to come up with a simpler solution.

Any comments on the above are welcome, and happy to provide more details if
anyone is interested.

Cheers,

Tom

[-- Attachment #2: Type: text/html, Size: 5558 bytes --]

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

[ZmnSCPxj]

Good morning Tom,


> Here is a high-level description of how this blinding can operate - with the aim that the conductor does learn how the ownership of individual coins has changed.
> For example, imagine 4 individuals (A,B,C and D) who own equal value statecoins utxo1, utxo2, utxo3 and utxo4 respectively. They want to swap ownership privately, trusting the conductor/SCE to enforce atomicity. In other words, the conductor will randomly assign each statecoin to one of the owners (the mix), but will not be able to gain knowledge of that assignment.
> 1. A,B,C and D signal their participation by signing the swap_token (which has details of the swap) with the proof-key of their input coin. (A statecoin address is formed of a concatenation of the proof key and backup address).
> 2. Each of A,B,C and D then generate a new statecoin address (where they what to receive the swapped coin), which they blind (encrypt) and sign with the proof key of their input coin: add1, add2, add3 and add4 and send to the conductor.
> 3. The conductor authenticates each signature and then signs each payload (i.e. the blinded destination addresses) with a blinded signature scheme and returns these signatures to A,B,C and D.
> 4. Each of A,B,C and D then reconnects over TOR with a new identity.
> 5. Each of A,B,C and D then send their unblinded destination address with the conductor signature to the conductor (the conductor now knows that these 4 addresses belong to A,B,C and D, but not which ones map to each input.)
> 6. The conductor randomly assigns each address to one of utxo1, utxo2, utxo3 and utxo4 (e.g. utxo1:add3, utxo2:add1, utxo3:add4 and utxo4:add2) and requests each participant to initiate the transfer to the given address.
> 7. Each participant then finalises each transfer - if any transfer fails (due to a participant disappearing or acting maliciously) then all transfers are reverted - here atomicity is guaranteed by the SCE.

Okay, I suppose this is much too high-level a view, and I have no idea what you mean by "statecoin" exactly.

Let me try to fill in the details and correct me if I am wrong okay?

I imagine that the `add1` etc. are implemented as 2-of-2 between the purported owner and the tr\*sted signing module.
The owner of that address can easily create this knowing only the pubkey of the tr\*sted signing module.

The initial `utxo1`... are also in similar 2-of-2s.

(they cannot be unilateral control, since then a participant can broadcast a replacement transaction, even without RBF, almost directly to miners.)

So when the coordinator talks to Alice, who owns `utxo1` and destination `addr1`, it provides partially-signed transactions of `utxo#:addr#`.
Alice then checks that its `addr1` is on one of those transactions, with the correct amount, then provides a signature for the `utxo1:addr#` transaction.

However, then the coordinator, who happens to be in cahoots with Bob, Charlie, and Dave, simply broadcasts that transaction without soliciting the `utxo#:addr1` transaction.

So it seems to me that this requires tr\*st that the coordinator is not going to collude with other participants.
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.
The plan by belcher_ is potentially compatible with using watchtowers that can be used for both CoinSwap and Lightning as well (if we design it well) with the watchtower potentially not even learning whether it is watching a CoinSwap or a Lightning channel.

Though of course I could be misunderstanding the scheme itself.
Is my understanding correct?

Regards,
ZmnSCPxj

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

[Tom Trevethan]

[-- Attachment #1: Type: text/plain, Size: 5700 bytes --]

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.

Tom

On Wed, Sep 16, 2020 at 2:04 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> Good morning Tom,
>
>
> > Here is a high-level description of how this blinding can operate - with
> the aim that the conductor does learn how the ownership of individual coins
> has changed.
> > For example, imagine 4 individuals (A,B,C and D) who own equal value
> statecoins utxo1, utxo2, utxo3 and utxo4 respectively. They want to swap
> ownership privately, trusting the conductor/SCE to enforce atomicity. In
> other words, the conductor will randomly assign each statecoin to one of
> the owners (the mix), but will not be able to gain knowledge of that
> assignment.
> > 1. A,B,C and D signal their participation by signing the swap_token
> (which has details of the swap) with the proof-key of their input coin. (A
> statecoin address is formed of a concatenation of the proof key and backup
> address).
> > 2. Each of A,B,C and D then generate a new statecoin address (where they
> what to receive the swapped coin), which they blind (encrypt) and sign with
> the proof key of their input coin: add1, add2, add3 and add4 and send to
> the conductor.
> > 3. The conductor authenticates each signature and then signs each
> payload (i.e. the blinded destination addresses) with a blinded signature
> scheme and returns these signatures to A,B,C and D.
> > 4. Each of A,B,C and D then reconnects over TOR with a new identity.
> > 5. Each of A,B,C and D then send their unblinded destination address
> with the conductor signature to the conductor (the conductor now knows that
> these 4 addresses belong to A,B,C and D, but not which ones map to each
> input.)
> > 6. The conductor randomly assigns each address to one of utxo1, utxo2,
> utxo3 and utxo4 (e.g. utxo1:add3, utxo2:add1, utxo3:add4 and utxo4:add2)
> and requests each participant to initiate the transfer to the given address.
> > 7. Each participant then finalises each transfer - if any transfer fails
> (due to a participant disappearing or acting maliciously) then all
> transfers are reverted - here atomicity is guaranteed by the SCE.
>
> Okay, I suppose this is much too high-level a view, and I have no idea
> what you mean by "statecoin" exactly.
>
> Let me try to fill in the details and correct me if I am wrong okay?
>
> I imagine that the `add1` etc. are implemented as 2-of-2 between the
> purported owner and the tr\*sted signing module.
> The owner of that address can easily create this knowing only the pubkey
> of the tr\*sted signing module.
>
> The initial `utxo1`... are also in similar 2-of-2s.
>
> (they cannot be unilateral control, since then a participant can broadcast
> a replacement transaction, even without RBF, almost directly to miners.)
>
> So when the coordinator talks to Alice, who owns `utxo1` and destination
> `addr1`, it provides partially-signed transactions of `utxo#:addr#`.
> Alice then checks that its `addr1` is on one of those transactions, with
> the correct amount, then provides a signature for the `utxo1:addr#`
> transaction.
>
> However, then the coordinator, who happens to be in cahoots with Bob,
> Charlie, and Dave, simply broadcasts that transaction without soliciting
> the `utxo#:addr1` transaction.
>
> So it seems to me that this requires tr\*st that the coordinator is not
> going to collude with other participants.
> 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.
> The plan by belcher_ is potentially compatible with using watchtowers that
> can be used for both CoinSwap and Lightning as well (if we design it well)
> with the watchtower potentially not even learning whether it is watching a
> CoinSwap or a Lightning channel.
>
> Though of course I could be misunderstanding the scheme itself.
> Is my understanding correct?
>
> Regards,
> ZmnSCPxj
>

[-- Attachment #2: Type: text/html, Size: 6362 bytes --]

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

[ZmnSCPxj]

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

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

[Tom Trevethan]

[-- Attachment #1: Type: text/plain, Size: 5386 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 6291 bytes --]

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

[Karl]

[-- Attachment #1: Type: text/plain, Size: 5953 bytes --]

Coinswap has been a struggling goal for many years now.  Consider that
bitshares' dexbot just recently lost their funding.

Please make your projects usable before you announce you are working on
them, to keep your work safe from distraction or harm.

On Sun, Sep 13, 2020, 7:11 PM Tom Trevethan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> We are designing an off-chain coin-swap protocol that will work with the
> statechain implementation we are developing (
> https://github.com/commerceblock/mercury). The general idea is that coins
> deposited with a statechain entity (statecoins) can be transacted
> peer-to-peer off-chain in a way that the statechain entity (SCE) is
> trusted, but the statecoins always remain in the custody of the owners. A
> statecoin swapping service would enable owners to mix their coins with
> other users, giving the same privacy benefits of on-chain CoinSwap
> protocols, but by being off-chain statecoin swaps would be much faster and
> cheaper.
>
> The swapping service (conductor) would not have custody of the statecoins
> at any point. The aim is to have the conductor coordinate the swap amongst
> a group of statecoins (i.e. determine the which statecoin should be sent to
> which new random owner in the group) without being able to learn the link
> between owners and their provided addresses. To do this we will use a blind
> signature scheme in a similar way to the zerolink protocol.
>
> Here is a high-level description of how this blinding can operate - with
> the aim that the conductor does learn how the ownership of individual coins
> has changed.
> For example, imagine 4 individuals (A,B,C and D) who own equal value
> statecoins utxo1, utxo2, utxo3 and utxo4 respectively. They want to swap
> ownership privately, trusting the conductor/SCE to enforce atomicity. In
> other words, the conductor will randomly assign each statecoin to one of
> the owners (the mix), but will not be able to gain knowledge of that
> assignment.
> 1. A,B,C and D signal their participation by signing the swap_token (which
> has details of the swap) with the proof-key of their input coin. (A
> statecoin address is formed of a concatenation of the proof key and backup
> address).
> 2. Each of A,B,C and D then generate a new statecoin address (where they
> what to receive the swapped coin), which they blind (encrypt) and sign with
> the proof key of their input coin: add1, add2, add3 and add4 and send to
> the conductor.
> 3. The conductor authenticates each signature and then signs each payload
> (i.e. the blinded destination addresses) with a blinded signature scheme
> and returns these signatures to A,B,C and D.
> 4. Each of A,B,C and D then reconnects over TOR with a new identity.
> 5. Each of A,B,C and D then send their unblinded destination address with
> the conductor signature to the conductor (the conductor now knows that
> these 4 addresses belong to A,B,C and D, but not which ones map to each
> input.)
> 6. The conductor randomly assigns each address to one of utxo1, utxo2,
> utxo3 and utxo4 (e.g. utxo1:add3, utxo2:add1, utxo3:add4 and utxo4:add2)
> and requests each participant to initiate the transfer to the given
> address.
> 7. Each participant then finalises each transfer - if any transfer fails
> (due to a participant disappearing or acting maliciously) then all
> transfers are reverted - here atomicity is guaranteed by the SCE.
>
> The interesting problem we have with this protocol is how to assign blame
> in the case that one or more participants in the swap causes it to fail, so
> that the corresponding statecoins can be penalized (prevented from
> participating in further swaps for some timeout) to make any DoS attack
> costly. In the case of an on-chain coinjoin, this is easy: whoever didn't
> sign their input is to blame. However, in our statechain system a statecoin
> transfer is a two stage process (to update the private key shares): the
> sender performs an operation with the SCE (transfer_sender) and then sends
> an encrypted value to the receiver, who then performs the second operation
> with the SCE (transfer_reciever) which updates the UTXO private key shares
> for the new owner (
> https://github.com/commerceblock/mercury/blob/master/doc/statechains.md
> for more details). If the second stage fails (i.e. the values used for the
> key update protocol are wrong) this could be due to either the sender
> sending a bad/manipulated value to the receiver, or the receiver using bad
> values in the second operation with the SCE. Essentially, either the sender
> or the receiver can cause the transfer to fail, and it is not possible to
> determine which one is malicious without revealing the encrypted value sent
> between the sender and receiver (which must be kept secret from the SCE).
>
> All this means that if a multi-party coinswap fails, we will know which
> statecoin was involved in the failure, but we cannot determine whether the
> sender or receiver of that coin caused the failure. One potential solution
> to this is to have each sender generate a zero knowledge proof that the
> encrypted value sent to the receiver is correct/valid (see last section in
> https://github.com/commerceblock/mercury/blob/master/doc/swaps.md for
> more details) which can be used to assign blame in a failure. This proof
> could be generated and verified using a zkSNARK/zkSTARK framework, but this
> is not trivial to implement and would likely add significant computational
> burden to user wallets to generate proofs - so we would like to avoid this
> if possible, and we are trying to come up with a simpler solution.
>
> Any comments on the above are welcome, and happy to provide more details
> if anyone is interested.
>
> Cheers,
>
> Tom
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 6780 bytes --]

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

[ZmnSCPxj]

Good morning Tom,

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

Complying with the letter of the law without complying to its spirit seems rather hair-splitting to me.

Ideally, a law regarding any financial mechanisms would judge based on how much control the purported owner has over the actual coin and what risks it would entail for them, and protect citizens against risk of damage to their finances, not focus on whether storage is "custodial" or not.

So I still suggest that, for purposes of technical discussion, we should avoid the term "custodial" and instead consider technical risks.

>
> > 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).

The SE can run in a virtual environment that monitors deletion events and records them.
Such a virtual environment could be set up by a rootkit that has been installed on the SE hardware.
Thus, even if the SE is honest, corruption of the hardware it is running on can allow recovery of old privkeys and violation of the tr\*st assumption.

Compare this to, for example, TumbleBit or Wasabi.
In those cases, even if the service providing the mixing is corrupted by a rootkit on the hardware running the honest service software in a virtual environment and monitoring all its internal state and communications, they cannot lead to loss of funds even with cooperation of previous participants.
They can at most be forced into denial-of-service, but not outright theft of coins.

Thus, I believe this solution is inferior to these older solutions, at least in terms of financial security.

I admit the new solution is superior blockspace-wise, if you consider multiple mixing rounds.
However, multiple mixing rounds under this solution have increased exposure to the risk of theft noted above, and thus it would be better, risk-wise, to immediately withdraw after every round, and potentially seek other SEs (to reduce risks arising from a particular SE being corrupted), thus obviating the blockspace savings.


The above remain true regardless of what definition of "custodial" you have.

Regards,
ZmnSCPxj

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

[Tom Trevethan]

[-- Attachment #1: Type: text/plain, Size: 4679 bytes --]

Hi ZmnSCPxj,

> The SE can run in a virtual environment that monitors deletion events and
records them.
> Such a virtual environment could be set up by a rootkit that has been
installed on the SE hardware.
> Thus, even if the SE is honest, corruption of the hardware it is running
on can allow recovery of old privkeys and violation of the tr\*st
assumption.

This is true, but this threat can be mitigated with secured infrastructure
and the use of hardware security modules/trusted execution environments
that enable secure (and potentially attestable) deletion.

> Compare this to, for example, TumbleBit or Wasabi.
> In those cases, even if the service providing the mixing is corrupted by
a rootkit on the hardware running the honest service software in a virtual
environment and monitoring all its internal state and communications, they
cannot lead to loss of funds even with cooperation of previous participants.
>They can at most be forced into denial-of-service, but not outright theft
of coins.

Yes, I agree. But on the other side of the scale is a comparison with
centralised mixing services, which remain extremely popular.

> I admit the new solution is superior blockspace-wise, if you consider
multiple mixing rounds.

The aim of the solution is to replicate the UX (in terms of speed) of a
completely centralised mixer (i.e. where the server(s) explicitly holds the
full key(s) to the deposits being swapped) but in a way that makes theft
more difficult (requiring collusion with previous owners), has an in-built
mechanism for users to get back their funds if the service is shut
down/blown-up, provides users with proof of ownership/theft, and with the
same privacy guarantees as the above mentioned trust-minimised protocols.

Cheers,

Tom

On Tue, Sep 22, 2020 at 2:00 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> Good morning Tom,
>
> > 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.
>
> Complying with the letter of the law without complying to its spirit seems
> rather hair-splitting to me.
>
> Ideally, a law regarding any financial mechanisms would judge based on how
> much control the purported owner has over the actual coin and what risks it
> would entail for them, and protect citizens against risk of damage to their
> finances, not focus on whether storage is "custodial" or not.
>
> So I still suggest that, for purposes of technical discussion, we should
> avoid the term "custodial" and instead consider technical risks.
>
> >
> > > 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).
>
> The SE can run in a virtual environment that monitors deletion events and
> records them.
> Such a virtual environment could be set up by a rootkit that has been
> installed on the SE hardware.
> Thus, even if the SE is honest, corruption of the hardware it is running
> on can allow recovery of old privkeys and violation of the tr\*st
> assumption.
>
> Compare this to, for example, TumbleBit or Wasabi.
> In those cases, even if the service providing the mixing is corrupted by a
> rootkit on the hardware running the honest service software in a virtual
> environment and monitoring all its internal state and communications, they
> cannot lead to loss of funds even with cooperation of previous participants.
> They can at most be forced into denial-of-service, but not outright theft
> of coins.
>
> Thus, I believe this solution is inferior to these older solutions, at
> least in terms of financial security.
>
> I admit the new solution is superior blockspace-wise, if you consider
> multiple mixing rounds.
> However, multiple mixing rounds under this solution have increased
> exposure to the risk of theft noted above, and thus it would be better,
> risk-wise, to immediately withdraw after every round, and potentially seek
> other SEs (to reduce risks arising from a particular SE being corrupted),
> thus obviating the blockspace savings.
>
>
> The above remain true regardless of what definition of "custodial" you
> have.
>
> Regards,
> ZmnSCPxj
>

[-- Attachment #2: Type: text/html, Size: 5488 bytes --]

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

[ZmnSCPxj]

Good morning Tom,

> Hi ZmnSCPxj,
>
> > The SE can run in a virtual environment that monitors deletion events and records them.
> > Such a virtual environment could be set up by a rootkit that has been installed on the SE hardware.
> > Thus, even if the SE is honest, corruption of the hardware it is running on can allow recovery of old privkeys and violation of the tr\*st assumption.
>
> This is true, but this threat can be mitigated with secured infrastructure and the use of hardware security modules/trusted execution environments that enable secure (and potentially attestable) deletion. 
>
> > Compare this to, for example, TumbleBit or Wasabi.
> > In those cases, even if the service providing the mixing is corrupted by a rootkit on the hardware running the honest service software in a virtual environment and monitoring all its internal state and communications, they cannot lead to loss of funds even with cooperation of previous participants.
> >They can at most be forced into denial-of-service, but not outright theft of coins.
>
> Yes, I agree. But on the other side of the scale is a comparison with centralised mixing services, which remain extremely popular. 
>
> > I admit the new solution is superior blockspace-wise, if you consider multiple mixing rounds. 
>
> The aim of the solution is to replicate the UX (in terms of speed) of a completely centralised mixer (i.e. where the server(s) explicitly holds the full key(s) to the deposits being swapped) but in a way that makes theft more difficult (requiring collusion with previous owners), has an in-built mechanism for users to get back their funds if the service is shut down/blown-up, provides users with proof of ownership/theft, and with the same privacy guarantees as the above mentioned trust-minimised protocols. 

I believe the slowness of TumbleBit and Wasabi have less to do with security than with gathering enough participants to get a reasonable anonymity set.

If the statechain entity itself does not participate and put up funds that its clients can acquire quickly, than a similar waiting period would be necessary anyway to gather enough participants to make the swapping worthwhile.
This would then fail your goal of speed.

If the statechain entity *does* act as a participant, then a client could acquire a new coin fairly quickly (as the statechain entity would be a "participant of last resort" with which it could swap right now), but the "previous participant" in that case would be the statechain entity itself, making its ability to outright steal funds absolutely certain, and thus not much better than a mixer that provides "put money in this address, I will send you money in your address" service.
(unless I can do a cut-and-choose on the hardware, i.e. buy multiple instances and reverse-engineer all except a randomly-selected one to check for hardware defects that may allow extraction of privkeys, and then use the hardware that remains, I do not think the security of TEEs/HSMs is at all high.
And the TEE/HSM would be directly possessed by the statechain entity and not me, presumably I as client of the statechain entity cannot audit that, so ---)

If you are going to have a maker-taker model, where takers spend money to get immediate swaps for the time that makers spend waiting, then I suggest that the SwapMarket plan by Chris Belcher would only require some number of confirmations of various transactions to get superior security, which would be a better tradeoff than what statechains provide.



Regards,
ZmnSCPxj