<div dir="ltr">Hi,<div><br></div><div>An quick update on progress with our statechain implementation which we are pressing ahead with - we have started work on a version in Rust (<a href="https://github.com/commerceblock/mercury">https://github.com/commerceblock/mercury</a>) that is based on the 2P ECDSA gotham-city wallet from KZen (<a href="https://github.com/KZen-networks/gotham-city">https://github.com/KZen-networks/gotham-city</a>), and using their implementation of Lindel's 2P ECDSA protocol, which is very fast (we can always swap to a different protocol later). Also, we are planning on using a sparse Merkle tree attested to a Mainstay slot (<a href="http://mainstay.xyz">mainstay.xyz</a>) for the proof-of-publication/proof-of-ownership - using the protocol described here: <a href="https://github.com/commerceblock/mercury/blob/master/doc/statechains.md">https://github.com/commerceblock/mercury/blob/master/doc/statechains.md</a> and <a href="https://github.com/thyeem/monotree">https://github.com/thyeem/monotree</a>. Any comments on these choices or on anything else are highly appreciated. </div><div><br></div><div>Tom</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Apr 5, 2020 at 10:25 PM Tom Trevethan <<a href="mailto:tom@commerceblock.com">tom@commerceblock.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Bob and Nadav,<div><br></div><div>There seems to be no way to prevent a malicious SE from stealing an output from the current owner by either colluding with (or being) a previous owner. But with a proof-of-publication (i.e. the statechain) it is possible for the current owner to have a proof that the SE has stolen from them. It seems to me that the statechain itself provides two functions: 1. Proof that an output has only a single owner at any time (preventing the SE from double-spending) and 2. a way for the current owner to prove their ownership, and require their permission to change ownership. 1. can just be a publication by the SE, but 2. requires that the output is transferred to a public key of the owner, and only via a signature of the previous owner (in this way the SE cannot re-assign ownership unilaterally). Therefore I think Nadav is right, and this needs to be a key that the SE can never know (even if they are malicious), but which can be used to prove ownership, and in turn prove fraud on the part of the SE. </div><div><br></div><div>I don't think that this should be too much of an issue: any wallet will have to use new keys for each output and transfer anyway. The statechain key (used for the ownership proof) and the output key share can be on different hardened HD paths (following on from a path derived from the outpoint of the UTXO, similar to the method in BIP175). </div><div><br></div><div>Tom</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Apr 5, 2020 at 3:17 PM Bob McElrath <<a href="mailto:bob@mcelrath.org" target="_blank">bob@mcelrath.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Note that this attack requires collaboration with the current UTXO owner.<br>
Generally if there's some form of address/payment request, the current holder is<br>
trying to transfer the UXTO to some other (non-statechain) entity, and he knows<br>
the target of the transfer, and participates in the protocol to authorize it.<br>
The current holder must obtain the target pubkey for the transfer out-of-band<br>
with respect to the SE, or the SE can MITM that.<br>
<br>
It's a stated security assumption that the sender or receiver do not collude<br>
with the SE. If either do, then your attack is generally possible and all bets<br>
are off. So what you've described is simply the SE colluding with the receiver.<br>
The receiver will *already* receive the UTXO, so the receiver here is assisting<br>
the SE in stealing his (the receiver's) funds, or the SE has done a MITM on the<br>
transfer. Various improvements including blind signing, a SE-federation, etc<br>
are valuable to consider to mitigate this. But the SE must be prevented, one way<br>
or another, from "buying the UTXO". The SE cannot be allowed to be both operator<br>
of the SE and a customer of it, as this clearly violates the no-receiver<br>
collusion principle.<br>
<br>
"Adding a new user key" doesn't change the situation. There's already a user key<br>
involved, and the user has already acquiesced to the transfer. Acquiescing with<br>
two keys doesn't change anything.<br>
<br>
As far as proving and tracing the fraud, this is where "single use seals" come<br>
in. Each SE transfer can involve an "opening" of a seal, followed by a "close"<br>
when it is transferred, creating a linear history of ownership. If the SE<br>
obtains the full private key x, one way or another, the spend of that UTXO will<br>
fall outside this seal-based history, and proof of fraud will be evident. It<br>
won't be possible to determine *which* of the old owners collaborated with the<br>
SE, but it gives clear proof that the SE is not to be trusted. A customer might<br>
demand that a seal-based system be in use as an independent entity from the SE,<br>
to audit the honesty of the SE. The seal system does not require any of the keys<br>
required for transfer. See <a href="https://mainstay.xyz" rel="noreferrer" target="_blank">https://mainstay.xyz</a> as a potential implementation.<br>
There are lots of reasons this might required as an AML solution for some<br>
businesses anyway.<br>
<br>
Nadav Kohen via bitcoin-dev [<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>] wrote:<br>
> Hey all,<br>
> <br>
> So my main concern with the proposal as written is that the Statechain Entity<br>
> (SE) can untraceably scam its users with the following attack:<br>
> <br>
> 1) Buy the utxo (have it transferred to a key it knows), this first step can be<br>
> skipped if the utxo was created by the SE.<br>
> 2) Transfer the UTXO to someone else, let it be for however long<br>
> 3) When it wishes to steal the UTXO, the SE now knows its own shard s_n and it <br>
> knows the full private key, x, from when it owned the UTXO (and had both<br>
> shards), and so it can compute x/s_n = the current users shard. It can then<br>
> sign for the current user, and forge a state transition to a key it owns before<br>
> spending the UTXO on chain.<br>
> <br>
> The main problem here is that the user who had their funds stolen cannot prove<br>
> to anyone that this has happened since the attack compromises their key.<br>
> That said, I think this problem is easily fixed by adding a new user key to the<br>
> protocol with which they must sign in order for the transfer to be considered<br>
> valid on the state chain. This way, if the SE wishes to steal the funds (which<br>
> they still can), at least it is traceable/provable that this SE is not<br>
> trustworthy as there is no evidence of a valid transfer for the funds that have<br>
> been stolen.<br>
> <br>
> Best,<br>
> Nadav<br>
> <br>
> On Thu, Apr 2, 2020 at 7:22 PM Tom Trevethan via bitcoin-dev <<br>
> <a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>
> <br>
> Thanks for all of the input and comments - I do now think that the<br>
> decrementing nSequence relative locktime backup system with kick-off<br>
> transaction is the way to go, including a fee penalty via CPFP to<br>
> disincentivise DoS, as suggested. <br>
> I have started a more detailed document specifying the proposed protocol in<br>
> more detail: <a href="https://github.com/commerceblock/mercury/blob/master/" rel="noreferrer" target="_blank">https://github.com/commerceblock/mercury/blob/master/</a><br>
> statechains.md which includes improvements to the transfer mechanism (and<br>
> an explanation of how this can be used to transfer/novate positions in<br>
> DLCs). Always happy to get more feedback or PRs. <br>
> <br>
> Tom<br>
> <br>
> On Tue, Mar 31, 2020 at 12:41 PM Tom Trevethan <<a href="mailto:tom@commerceblock.com" target="_blank">tom@commerceblock.com</a>><br>
> wrote:<br>
> <br>
> Hi David,<br>
> <br>
> Just for clarity, I left nChain over 2 years ago (having worked there<br>
> since 2016). While there, I (along with other researchers) were given<br>
> free rein to work on any ideas we wanted to. I had been interested in<br>
> the scaling of Bitcoin off-chain, and this was one of several things I<br>
> spent time on (including things like sidechains, pegs and threshold<br>
> signatures). This patent application came out of an idea I had to<br>
> transfer ownership of UTXOs off-chain that has some similarities to the<br>
> statechains proposal, which has shown there is interest and demand for<br>
> this type of system. <br>
> <br>
> Although I think the existence of this application is something to be<br>
> mindful of, there are several important things to note:<br>
> <br>
> 1. Although there are similarities, the current ideas are significantly<br>
> different to those in the application. <br>
> 2. The key transfer protocol as described in the application is not<br>
> secure (for several reasons, including as discussed above, by Albert<br>
> and Bob etc.) - and a different mechanism is required. <br>
> 3. Decrementing timelocks (as suggested in the application) are prior<br>
> art (Decker-Wattenhofer 2015), and in any case any implementation will<br>
> most likely use an 'invalidation tree' relative locktime backup<br>
> mechanism for open-ended UTXOs. <br>
> 4. The patent application has not been granted (it was made in May<br>
> 2017) and the international search report rejected it on the grounds of<br>
> prior art. <br>
> <br>
> Tom<br>
> <br>
> On Tue, Mar 31, 2020 at 11:36 AM David A. Harding <<a href="mailto:dave@dtrt.org" target="_blank">dave@dtrt.org</a>><br>
> wrote:<br>
> <br>
> On Wed, Mar 25, 2020 at 01:52:10PM +0000, Tom Trevethan via<br>
> bitcoin-dev wrote:<br>
> > Hi all,<br>
> ><br>
> > We are starting to work on an implementation of the statechains<br>
> concept (<br>
> > <a href="https://medium.com/@RubenSomsen/" rel="noreferrer" target="_blank">https://medium.com/@RubenSomsen/</a><br>
> statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39),<br>
> ><br>
> > [...]<br>
> > There are two main modifications we are looking at:<br>
> > [...]<br>
> ><br>
> > 2. Replacing the 2-of-2 multisig output (paying to statechain<br>
> entity SE key<br>
> > and transitory key) with a single P2(W)PKH output where the<br>
> public key<br>
> > shared between the SE and the current owner. The SE and the<br>
> current owner<br>
> > can then sign with a 2-of-2 ECDSA MPC.<br>
> <br>
> Dr. Trevethan,<br>
> <br>
> Would you be able to explain how your proposal to use statechains<br>
> with<br>
> 2P-ECDSA relates to your patent assigned to nChain Holdings for<br>
> "Secure<br>
> off-chain blockchain transactions"?[1] <br>
> <br>
> [1] <a href="https://patents.google.com/patent/US20200074464A1" rel="noreferrer" target="_blank">https://patents.google.com/patent/US20200074464A1</a><br>
> <br>
> Here are some excerpts from the application that caught my<br>
> attention in<br>
> the context of statechains in general and your proposal to this<br>
> list in<br>
> particular:<br>
> <br>
> > an exchange platform that is trusted to implement and operate the<br>
> > transaction protocol, without requiring an on-chain transaction.<br>
> The<br>
> > off-chain transactions enable one computer system to generate<br>
> multiple<br>
> > transactions that are recordable to a blockchain in different<br>
> > circumstances<br>
> ><br>
> > [...]<br>
> ><br>
> > at least some of the off-chain transactions are valid for<br>
> recording on<br>
> > the blockchain even in the event of a catastrophic failure of the<br>
> > exchange (e.g., exchange going permanently off-line or loosing<br>
> key<br>
> > shares).<br>
> ><br>
> > [...]<br>
> ><br>
> > there may be provided a computer readable storage medium<br>
> including a<br>
> > two-party elliptic curve digital signature algorithm (two-party<br>
> ECDSA)<br>
> > script comprising computer executable instructions which, when<br>
> > executed, configure a processor to perform functions of a<br>
> two-party<br>
> > elliptic curve digital signature algorithm described herein.<br>
> ><br>
> > [...]<br>
> ><br>
> > In this instance the malicious actor would then also have to<br>
> collude<br>
> > with a previous owner of the funds to recreate the full key.<br>
> Because<br>
> > an attack requires either the simultaneous theft of both exchange<br>
> and<br>
> > depositor keys or collusion with previous legitimate owners of<br>
> funds,<br>
> > the opportunities for a malicious attacker to compromise the<br>
> exchange<br>
> > platform are limited.<br>
> <br>
> Thank you,<br>
> <br>
> -Dave<br>
> <br>
> _______________________________________________<br>
> bitcoin-dev mailing list<br>
> <a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
> <a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
> <br>
> !DSPAM:5e87670a231323960034969!<br>
<br>
> _______________________________________________<br>
> bitcoin-dev mailing list<br>
> <a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
> <a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
> <br>
> <br>
> !DSPAM:5e87670a231323960034969!<br>
<br>
--<br>
Cheers, Bob McElrath<br>
<br>
"For every complex problem, there is a solution that is simple, neat, and wrong."<br>
-- H. L. Mencken <br>
<br>
</blockquote></div>
</blockquote></div>