Re: [bitcoin-dev] Blinded 2-party Musig2
An update on progress on the development of the blinded two-party Schnorr scheme for statechains. As stated previously, we believe that one-more-signature and Wagner attacks are mitigated by the client committing the values of the blinding nonce used (labeled f) and the value of R2 used in a signing session to the server before the server responds with their value of R1. Then each time the generated signature is verified (in our application this is a new statecoin owner), the verifier retrieves the commitments and blinded challenge value from the server (c, SHA256(f) and SHA256(R2)) and f and R2 from the co-signer, and verifies that the blinded challenge value c = f + SHA256(X, R1 + R2 + f.X, m) and the commitments match f,R2. This ensures the signer cannot have chosen the values of f and R2 after the value of R1 is randomly generated by the server. This scheme has been implemented in a forked version of the secp256k1-zkp library: https://github.com/ssantos21/secp256k1-zkp where a new function has been added secp256k1_blinded_musig_nonce_process ( https://github.com/ssantos21/secp256k1-zkp/blob/ed08ad7603f211fdf39b5f6db9d7e99cf048a56c/src/modules/musig/session_impl.h#L580 ) which is required for the client generation of the blinded challenge value. One issue that came up and had to be solved was ensuring the R (curve point) is even (in MuSig2 the secret nonce is negated if R is odd) with the point f.X added (and f committed to). We will add a complete explanation of this to the updated spec. The scheme is implemented in a blind server: https://github.com/ssantos21/blinded-musig-sgx-server And client: https://github.com/ssantos21/blinded-musig2-client Any comments or questions appreciated. On Mon, Aug 7, 2023 at 1:55 AM Tom Trevethan wrote: > A follow up to this, I have updated the blinded statechain protocol > description to include the mitigation to the Wagner attack by requiring the > server to send R1 values only after commitments made to the server of the > R2 values used by the user, and that all the previous computed c values are > verified by each new statecoin owner. > https://github.com/commerceblock/mercury/blob/master/layer/protocol.md > > Essentially, the attack is possible because the server cannot verify that > the blinded challenge (c) value it has been sent by the user has been > computed honestly (i.e. c = SHA256(X1 + X2, R1 + R2, m) ), however this CAN > be verified by each new owner of a statecoin for all the previous > signatures. > > Each time an owner cooperates with the server to generate a signature on a > backup tx, the server will require that the owner send a commitment to > their R2 value: e.g. SHA256(R2). The server will store this value before > responding with it's R1 value. This way, the owner cannot choose the value > of R2 (and hence c). > > When the statecoin is received by a new owner, they will receive ALL > previous signed backup txs for that coin from the sender, and all the > corresponding R2 values used for each signature. They will then ask the > server (for each previous signature), the commitments SHA256(R2) and the > corresponding server generated R1 value and c value used. The new owner > will then verify that each backup tx is valid, and that each c value was > computed c = SHA256(X1 + X2, R1 + R2, m) and each commitment equals > SHA256(R2). This ensures that a previous owner could not have generated > more valid signatures than the server has partially signed. > > On Thu, Jul 27, 2023 at 2:25 PM Tom Trevethan > wrote: > >> >> On Thu, Jul 27, 2023 at 9:08 AM Jonas Nick wrote: >> >>> No, proof of knowledge of the r values used to generate each R does not >>> prevent >>> Wagner's attack. I wrote >>> >>> > Using Wagner's algorithm, choose R2[0], ..., R2[K-1] such that >>> >c[0] + ... + c[K-1] = c[K]. >>> >>> You can think of this as actually choosing scalars r2[0], ..., r2[K-1] >>> and >>> define R2[i] = r2[i]*G. The attacker chooses r2[i]. The attack wouldn't >>> make >>> sense if he didn't. >>> >> ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Blinded 2-party Musig2
HI Lloyd, Yes, the blind signatures are for bitcoin transactions (these are timelocked 'backup txs' if the server disappears). This is not standard 'Schnorr blind signature' (like https://suredbits.com/schnorr-applications-blind-signatures/) but a 2-of-2 MuSig where two keys are required to generate the full signature, but one of them (the server) does not learn of either the full key, message (tx) or final signature. The server is explicitly trusted to report the total number of partial signatures it has generated for a specific key. If you can verify that ALL the signatures generated for a specific key were generated correctly, and the total number of them matches the number reported by the server, then there can be no other malicious valid signatures in existence. In this statechain protocol, the receiver of a coin must check all previous backup txs are valid, and that the total number of them matches the server reported signature count before accepting it. On Thu, Aug 10, 2023 at 4:30 AM Lloyd Fournier wrote: > Hi Tom, > > These questions might be wrongheaded since I'm not familiar enough with > the statechain protocol. Here goes: > > Why do you need to use schnorr blind signatures for this? Are the blind > signatures being used to produce on-chain tx signatures or are they just > for credentials for transferring ownership (or are they for both). If they > are for on-chain txs then you won't be able to enforce that the signature > used was not generated maliciously so it doesn't seem to me like your trick > above would help you here. I can fully verify that the state chain > signatures were all produced non-maliciously but then there may be another > hidden forged signature that can take the on-chain funds that were produced > by malicious signing sessions I was never aware of (or how can you be sure > this isn't the case). > > Following on from that point, is it not possible to enforce sequential > blind signing in the statechain protocol under each key. With that you > don't have the problem of wagner's attack. > > LL > > On Wed, 9 Aug 2023 at 23:34, Tom Trevethan via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> @moonsettler >> >> When anyone receives a coin (either as payment or as part of a swap) they >> need to perform a verification of all previous signatures and >> corresponding backup txs. If anything is missing, then the verification >> will fail. So anyone 'breaking the chain' by signing something >> incorrectly simply cannot then send that coin on. >> >> The second point is important. All the 'transfer data' (i.e. new and all >> previous backup txs, signatures and values) is encrypted with the new owner >> public key. But the server cannot know this pubkey as this would enable it >> to compute the full coin pubkey and identify it on-chain. Currently, the >> server identifies individual coins (shared keys) with a statechain_id >> identifier (unrelated to the coin outpoint), which is used by the coin >> receiver to retrieve the transfer data via the API. But this means the >> receiver must be sent this identifier out-of-band by the sender, and also >> that if anyone else learns it they can corrupt the server key >> share/signature chain via the API. One solution to this is to have a second >> non-identifying key used only for authenticating with the server. This >> would mean a 'statchain address' would then be composed of 2 separate >> pubkeys 1) for the shared taproot address and 2) for server authentication. >> >> Thanks, >> >> Tom >> >> On Tue, Aug 8, 2023 at 6:44 PM moonsettler >> wrote: >> >>> Very nice! Is there an authentication mechanism to avoid 'breaking the >>> chain' with an unverifiable new state by a previous owner? Can the current >>> owner prove the knowledge of a non-identifying secret he learned as >>> recipient to the server that is related to the statechain tip? >>> >>> BR, >>> moonsettler >>> >>> --- Original Message --- >>> On Monday, August 7th, 2023 at 2:55 AM, Tom Trevethan via bitcoin-dev < >>> bitcoin-dev@lists.linuxfoundation.org> wrote: >>> >>> A follow up to this, I have updated the blinded statechain protocol >>> description to include the mitigation to the Wagner attack by requiring the >>> server to send R1 values only after commitments made to the server of the >>> R2 values used by the user, and that all the previous computed c values are >>> verified by each new statecoin owner. >>> https://github.com/commerceblock/m
Re: [bitcoin-dev] Blinded 2-party Musig2
@moonsettler When anyone receives a coin (either as payment or as part of a swap) they need to perform a verification of all previous signatures and corresponding backup txs. If anything is missing, then the verification will fail. So anyone 'breaking the chain' by signing something incorrectly simply cannot then send that coin on. The second point is important. All the 'transfer data' (i.e. new and all previous backup txs, signatures and values) is encrypted with the new owner public key. But the server cannot know this pubkey as this would enable it to compute the full coin pubkey and identify it on-chain. Currently, the server identifies individual coins (shared keys) with a statechain_id identifier (unrelated to the coin outpoint), which is used by the coin receiver to retrieve the transfer data via the API. But this means the receiver must be sent this identifier out-of-band by the sender, and also that if anyone else learns it they can corrupt the server key share/signature chain via the API. One solution to this is to have a second non-identifying key used only for authenticating with the server. This would mean a 'statchain address' would then be composed of 2 separate pubkeys 1) for the shared taproot address and 2) for server authentication. Thanks, Tom On Tue, Aug 8, 2023 at 6:44 PM moonsettler wrote: > Very nice! Is there an authentication mechanism to avoid 'breaking the > chain' with an unverifiable new state by a previous owner? Can the current > owner prove the knowledge of a non-identifying secret he learned as > recipient to the server that is related to the statechain tip? > > BR, > moonsettler > > --- Original Message --- > On Monday, August 7th, 2023 at 2:55 AM, Tom Trevethan via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > A follow up to this, I have updated the blinded statechain protocol > description to include the mitigation to the Wagner attack by requiring the > server to send R1 values only after commitments made to the server of the > R2 values used by the user, and that all the previous computed c values are > verified by each new statecoin owner. > https://github.com/commerceblock/mercury/blob/master/layer/protocol.md > > Essentially, the attack is possible because the server cannot verify that > the blinded challenge (c) value it has been sent by the user has been > computed honestly (i.e. c = SHA256(X1 + X2, R1 + R2, m) ), however this CAN > be verified by each new owner of a statecoin for all the previous > signatures. > > Each time an owner cooperates with the server to generate a signature on a > backup tx, the server will require that the owner send a commitment to > their R2 value: e.g. SHA256(R2). The server will store this value before > responding with it's R1 value. This way, the owner cannot choose the value > of R2 (and hence c). > > When the statecoin is received by a new owner, they will receive ALL > previous signed backup txs for that coin from the sender, and all the > corresponding R2 values used for each signature. They will then ask the > server (for each previous signature), the commitments SHA256(R2) and the > corresponding server generated R1 value and c value used. The new owner > will then verify that each backup tx is valid, and that each c value was > computed c = SHA256(X1 + X2, R1 + R2, m) and each commitment equals > SHA256(R2). This ensures that a previous owner could not have generated > more valid signatures than the server has partially signed. > > On Thu, Jul 27, 2023 at 2:25 PM Tom Trevethan > wrote: > >> >> On Thu, Jul 27, 2023 at 9:08 AM Jonas Nick wrote: >> >>> No, proof of knowledge of the r values used to generate each R does not >>> prevent >>> Wagner's attack. I wrote >>> >>> > Using Wagner's algorithm, choose R2[0], ..., R2[K-1] such that >>> > c[0] + ... + c[K-1] = c[K]. >>> >>> You can think of this as actually choosing scalars r2[0], ..., r2[K-1] >>> and >>> define R2[i] = r2[i]*G. The attacker chooses r2[i]. The attack wouldn't >>> make >>> sense if he didn't. >>> >> > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Blinded 2-party Musig2
A follow up to this, I have updated the blinded statechain protocol description to include the mitigation to the Wagner attack by requiring the server to send R1 values only after commitments made to the server of the R2 values used by the user, and that all the previous computed c values are verified by each new statecoin owner. https://github.com/commerceblock/mercury/blob/master/layer/protocol.md Essentially, the attack is possible because the server cannot verify that the blinded challenge (c) value it has been sent by the user has been computed honestly (i.e. c = SHA256(X1 + X2, R1 + R2, m) ), however this CAN be verified by each new owner of a statecoin for all the previous signatures. Each time an owner cooperates with the server to generate a signature on a backup tx, the server will require that the owner send a commitment to their R2 value: e.g. SHA256(R2). The server will store this value before responding with it's R1 value. This way, the owner cannot choose the value of R2 (and hence c). When the statecoin is received by a new owner, they will receive ALL previous signed backup txs for that coin from the sender, and all the corresponding R2 values used for each signature. They will then ask the server (for each previous signature), the commitments SHA256(R2) and the corresponding server generated R1 value and c value used. The new owner will then verify that each backup tx is valid, and that each c value was computed c = SHA256(X1 + X2, R1 + R2, m) and each commitment equals SHA256(R2). This ensures that a previous owner could not have generated more valid signatures than the server has partially signed. On Thu, Jul 27, 2023 at 2:25 PM Tom Trevethan wrote: > > On Thu, Jul 27, 2023 at 9:08 AM Jonas Nick wrote: > >> No, proof of knowledge of the r values used to generate each R does not >> prevent >> Wagner's attack. I wrote >> >> > Using Wagner's algorithm, choose R2[0], ..., R2[K-1] such that >> >c[0] + ... + c[K-1] = c[K]. >> >> You can think of this as actually choosing scalars r2[0], ..., r2[K-1] and >> define R2[i] = r2[i]*G. The attacker chooses r2[i]. The attack wouldn't >> make >> sense if he didn't. >> > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Fwd: Blinded 2-party Musig2
@Jonas OK, thanks, I get the logic now. I believe this attack can be mitigated (at least in the case of using this scheme for statechains) by the receiver of a coin verifying the construction of all previous challenges. So in this case, the sender of a coin would record R2[K-1] in addition to m (and any c blinding nonce used) for the signature it generates with the server. It would then send this (and all previous R2 values i = 0, ..., K-2) to the receiver. The receiver would then query the server for the full set (i = 0, ..., K-1) of R1[i] values it has generated, and the corresponding (blinded) c[i] values used for each co-signing it has performed on this key. The receiver would then verify that each previous c[i] (i = 0, ... K-1) has been correctly formed and includes the server generated R1[i]. If any of the c values fail to verify against the values of R1 provided by the server, then the coin is invalid. On Thu, Jul 27, 2023 at 9:08 AM Jonas Nick wrote: > No, proof of knowledge of the r values used to generate each R does not > prevent > Wagner's attack. I wrote > > > Using Wagner's algorithm, choose R2[0], ..., R2[K-1] such that > >c[0] + ... + c[K-1] = c[K]. > > You can think of this as actually choosing scalars r2[0], ..., r2[K-1] and > define R2[i] = r2[i]*G. The attacker chooses r2[i]. The attack wouldn't > make > sense if he didn't. > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Blinded 2-party Musig2
Not 'signing' but 'secret' i.e. the r values (ephemeral keys). Proof of knowledge of the r values used to generate each R used prevents the Wagner attack, no? On Wed, Jul 26, 2023 at 8:59 PM Jonas Nick wrote: > None of the attacks mentioned in this thread so far (ZmnSCPxj mentioned an > attack on the nonces, I mentioned an attack on the challenge c) can be > prevented > by proving knowledge of the signing key (usually known as proof of > possession, > PoP). > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Blinded 2-party Musig2
@moonsettler Your scheme for blinding the challenge (e in your notation) works as far as I can tell. It is better than the way I suggested as it doesn't require modifying the aggregated pubkey (and the blinding nonce can be different for each signature). @AdamISZ and @Jonas It is not necessarily the server that would need to verify that the challenge is 'well formed', but the receiver of a statecoin. The concept of having a blinded statechain server is that each signature generated for a shared public key must be verified by the receiver of the corresponding coin. So a receiver would retrieve the number of co-signings performed by the server (K) and then verify each of the K signatures, and K transactions that they have received from the sender. They can additionally verify that each of the K R values has been correctly formed with a proof of secret value for creating R2 (along with the R1 from the server). ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Blinded 2-party Musig2
Thanks for the replies. As I understand it, the v=2 nonces signing protocol of musig2 prevents the Wagner attack. Also, that the challenge value c must be blinded from the server to prevent the server from being able to determine the signature from the on-chain state. In addition, in order to update the server (party 1) keyshare when a statecoin is transferred between users, the key aggregation coefficient must be set to 1 for each key. The purpose of this coefficient in the Musig2 protocol is to prevent 'rogue key attacks' where one party can choose a public key derived from both their own secret key and the inverse of the other party's public key giving them the ability to unilaterally produce a valid signature over the aggregate key. However this can be prevented by the party producing a proof of knowledge of the private key corresponding to their supplied public key. This can be a signature, which is produced in any case by signing the statechain state in the mercury protocol. This signature must be verified by the receiver of a coin (who must also verify the server pubkey combines with the sender pubkey to get the coin address) which proves that the server is required to co-sign to generate any signature for this address. Here is a modified protocol: Keygen: Server generates private key x1 and public key X1 = x1.G and sends X1 to user (party 2) User generates private key x2 and public key X2 = x2.G and (random) blinding nonce z and computes the aggregate public key X = z.(X1 + X2) (server never learns of X, X2 or z). Signing: Server generates nonces r11 and r12 and R11 = r11.G and R12 = r12.G and sends R11 and R12 to the user. User generates nonces r21 and r22 and R21 = r21.G and R22 = r22.G User computes R1 = R11 + R21 and R2 = R12 + R22 and b = H(X,(R1,R2),m) and R = R1 + b.R2 and c = (X,R,m) User sends the values y = cz and b to the server. Server computes s1 = yx1 + r11 + br12 and sends it to the user. User computes s2 = yx2 + r21 + br22 and s = s1 + s2 and signature (s,R) Transfer: In a statecoin transfer, when receiving a statecoin, in order to verify that the coin address (i.e. aggregate public key) is shared correctly between the previous owner and the server, the client must verify the following: Retrieve the CURRENT public key from the server for this coin X1. Retrieve the public key X2 and the blinding nonce z from the sender. Verify that z.X1 + X2 = P the address of the statecoin. Verify that the sender has the private key used to generate X2: this is done by verifying the statechain signature over the receiver public key X3 from X2. This proves that the address P was generated (aggregated) with the server and can only be signed with cooperation with the server, i.e. no previous owner can hold the full key. In order to update the key shares on transfer, the following protocol can be used: Server (party 1) generates a random blinding nonce e and sends it to user. User adds their private key to the nonce: t1 = e + x2 Client sends t1 and z to the reciever as part of transfer_msg (encrypted with the receiver public key X3 = x3.G). Receiver client decrypts t1 and then subtracts their private key x3: t2 = e + x2 - x3. Receiver client sends t2 to the server as part of transfer_receiver. Server the updates the private key share x1_2 = x1 + t2 - e = x1 + e + x2 - x3 - e = x1 + x2 - x3 So now, x1_2 + x3 (the aggregation of the new server key share with the new client key share) is equal to x1 + x2 (the aggregation of the old server key share with the old client key share). The server deletes x1. On Tue, Jul 25, 2023 at 3:12 PM Erik Aronesty wrote: > posk is "proof of secret key". so you cannot use wagner to select R > > On Mon, Jul 24, 2023 at 1:59 PM AdamISZ via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> @ZmnSCPxj: >> >> yes, Wagner is the attack you were thinking of. >> >> And yeah, to avoid it, you should have the 3rd round of MuSig1, i.e. the >> R commitments. >> >> @Tom: >> As per above it seems you were more considering MuSig1 here, not MuSig2. >> At least in this version. So you need the initial commitments to R. >> >> Jonas' reply clearly has covered a lot of what matters here, but I wanted >> to mention (using your notation): >> >> in s1 = c * a1 * x1 + r1, you expressed the idea that the challenge c >> could be given to the server, to construct s1, but since a1 = H(L, X1) and >> L is the serialization of all (in this case, 2) keys, that wouldn't work >> for blinding the final key, right? >> But, is it possible that this addresses the other problem? >> If the server is given c1*a1 instead as the challenge for signing (with >> their "pure" key x1), then perhaps it avoids the issue? Given what's on the >> blockchain ends up allowing calculation of 'c' and the aggregate key a1X1 + >> a2X2, is it the case that you cannot find a1 and therefore you cannot >> correlate the transaction with just the quantity 'c1*a1' which the server >> sees? >> >> But I agree
Re: [bitcoin-dev] Blinded 2-party Musig2
Hi ZmnSCPxj,
Yes, you are correct - the full scheme (
https://eprint.iacr.org/2020/1261.pdf) should have two or more nonces (and
also compute b). I don't think this changes the approach to blinding
however.
On Mon, Jul 24, 2023 at 11:50 AM ZmnSCPxj wrote:
> Good morning Tom,
>
> Would this allow party 2 to itself be composed of N >= 2 parties?
>
> MuSig2 (as opposed to MuSig1) requires that signatories provide multiple
> `R` points, not just one each, which are finally aggregated by first
> combining them using the MuSig() public key compose function.
> This prevents party 2 from creating an `R` that may allow it to perform
> certain attacks whose name escapes me right now but which I used to know.
> (it is the reason why MuSig1 requires 3 round trips, and why MuSig2
> requires at least 2 `R` nonces per signatory)
>
> Your scheme has only one `R` per party, would it not be vulnerably to that
> attack?
>
> Regards,
> ZmnSCPxj
>
>
> Sent with Proton Mail secure email.
>
> ------- Original Message -------
> On Monday, July 24th, 2023 at 7:46 AM, Tom Trevethan via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>
> > We are implementing a version of 2-of-2 Schnorr Musig2 for statechains
> where the server (party 1 in the 2-of-2) will be fully 'blinded' - in that
> it can hold a private key that is required to generate an aggregate
> signature on an aggregate public key, but that it does not learn either: 1)
> The aggregate public key 2) The aggregate signature and 3) The message (m)
> being signed.
> >
> > In the model of blinded statechains, the security rests on the
> statechain server being trusted to report the NUMBER of partial signatures
> it has generated for a particular key (as opposed to being trusted to
> enforce rules on WHAT it has signed in the unblinded case) and the full set
> of signatures generated being verified client side
> https://github.com/commerceblock/mercury/blob/master/doc/merc_blind.md#blinding-considerations
> >
> > Given the 2-of-2 musig2 protocol operates as follows (in the following
> description, private keys (field elements) are denoted using lower case
> letters, and elliptic curve points as uppercase letters. G is the generator
> point and point multiplication denoted as X = xG and point addition as A =
> G + G):
> >
> > Party 1 generates private key x1 and public key X1 = x1G. Party 2
> generates private key x2 and public key X2 = x2G. The set of pubkeys is L =
> {X1,X2}. The key aggregation coefficient is KeyAggCoef(L,X) = H(L,X). The
> shared (aggregate) public key X = a1X1 + a2X2 where a1 = KeyAggCoef(L,X1)
> and a2 = KeyAggCoef(L,X2).
> >
> > To sign a message m, party 1 generates nonce r1 and R1 = r1G. Party 2
> generates nonce r2 and R2 = r2G. These are aggregated into R = R1 + R2.
> >
> > Party 1 then computes 'challenge' c = H(X||R||m) and s1 = c.a1.x1 + r1
> > Party 2 then computes 'challenge' c = H(X||R||m) and s2 = c.a2.x2 + r2
> >
> > The final signature is then (R,s1+s2).
> >
> > In the case of blinding this for party 1:
> >
> > To prevent party 1 from learning of either the full public key or final
> signature seems straightforward, if party 1 doesn't not need to
> independently compute and verify c = H(X||R||m) (as they are blinded from
> the message in any case).
> >
> > 1) Key aggregation is performed only by party 2. Party 1 just sends X1
> to party 2.
> > 2) Nonce aggregation is performed only by party 2. Party 1 just sends R1
> to party 2.
> > 3) Party 2 computes c = H(X||R||m) and sends it to party 1 in order to
> compute s1 = c.a1.x1 + r1
> >
> > Party 1 never learns the final value of (R,s1+s2) or m.
> >
> > Any comments on this or potential issues would be appreciated.
> >
> > Tom
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Blinded 2-party Musig2
Hi Jonas, Seems you are right: for every tx, compute c from the on-chain data, and the server can match the c to the m (tx). So there would need to be a method for blinding the value of c. On Mon, Jul 24, 2023 at 4:39 PM Jonas Nick wrote: > > Party 1 never learns the final value of (R,s1+s2) or m. > > Actually, it seems like a blinding step is missing. Assume the server > (party 1) > received some c during the signature protocol. Can't the server scan the > blockchain for signatures, compute corresponding hashes c' = H(R||X||m) as > in > signature verification and then check c == c'? If true, then the server > has the > preimage for the c received from the client, including m. > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Blinded 2-party Musig2
Hi Eric,
Yes, this was my thinking. The current statechain protocol requires that
the sender of a coin sign the statechain with their public key, which is
then verified by the receiver. The receiver also verifies that this
(sender) public key aggregated with the current server public key
corresponds to the public key (TR address) of the coin. This prevents a
'rogue key' attack by the sender and verifies that this coin cannot be
spent without cooperation of the server.
On Mon, Jul 24, 2023 at 3:25 PM Erik Aronesty wrote:
> as long as all parties provide a proof of secret key along with their
> public key, that should not be possible
>
> or you can do it as a two-step process where all parties provide a
> commitment to the public key and nobody reveals a public key until that
> commitment is received
>
> or if you want to be paranoid you can do both
>
> On Mon, Jul 24, 2023, 7:00 AM ZmnSCPxj via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Good morning Tom,
>>
>> Would this allow party 2 to itself be composed of N >= 2 parties?
>>
>> MuSig2 (as opposed to MuSig1) requires that signatories provide multiple
>> `R` points, not just one each, which are finally aggregated by first
>> combining them using the MuSig() public key compose function.
>> This prevents party 2 from creating an `R` that may allow it to perform
>> certain attacks whose name escapes me right now but which I used to know.
>> (it is the reason why MuSig1 requires 3 round trips, and why MuSig2
>> requires at least 2 `R` nonces per signatory)
>>
>> Your scheme has only one `R` per party, would it not be vulnerably to
>> that attack?
>>
>> Regards,
>> ZmnSCPxj
>>
>>
>> Sent with Proton Mail secure email.
>>
>> --- Original Message ---
>> On Monday, July 24th, 2023 at 7:46 AM, Tom Trevethan via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>
>> > We are implementing a version of 2-of-2 Schnorr Musig2 for statechains
>> where the server (party 1 in the 2-of-2) will be fully 'blinded' - in that
>> it can hold a private key that is required to generate an aggregate
>> signature on an aggregate public key, but that it does not learn either: 1)
>> The aggregate public key 2) The aggregate signature and 3) The message (m)
>> being signed.
>> >
>> > In the model of blinded statechains, the security rests on the
>> statechain server being trusted to report the NUMBER of partial signatures
>> it has generated for a particular key (as opposed to being trusted to
>> enforce rules on WHAT it has signed in the unblinded case) and the full set
>> of signatures generated being verified client side
>> https://github.com/commerceblock/mercury/blob/master/doc/merc_blind.md#blinding-considerations
>> >
>> > Given the 2-of-2 musig2 protocol operates as follows (in the following
>> description, private keys (field elements) are denoted using lower case
>> letters, and elliptic curve points as uppercase letters. G is the generator
>> point and point multiplication denoted as X = xG and point addition as A =
>> G + G):
>> >
>> > Party 1 generates private key x1 and public key X1 = x1G. Party 2
>> generates private key x2 and public key X2 = x2G. The set of pubkeys is L =
>> {X1,X2}. The key aggregation coefficient is KeyAggCoef(L,X) = H(L,X). The
>> shared (aggregate) public key X = a1X1 + a2X2 where a1 = KeyAggCoef(L,X1)
>> and a2 = KeyAggCoef(L,X2).
>> >
>> > To sign a message m, party 1 generates nonce r1 and R1 = r1G. Party 2
>> generates nonce r2 and R2 = r2G. These are aggregated into R = R1 + R2.
>> >
>> > Party 1 then computes 'challenge' c = H(X||R||m) and s1 = c.a1.x1 + r1
>> > Party 2 then computes 'challenge' c = H(X||R||m) and s2 = c.a2.x2 + r2
>> >
>> > The final signature is then (R,s1+s2).
>> >
>> > In the case of blinding this for party 1:
>> >
>> > To prevent party 1 from learning of either the full public key or final
>> signature seems straightforward, if party 1 doesn't not need to
>> independently compute and verify c = H(X||R||m) (as they are blinded from
>> the message in any case).
>> >
>> > 1) Key aggregation is performed only by party 2. Party 1 just sends X1
>> to party 2.
>> > 2) Nonce aggregation is performed only by party 2. Party 1 just sends
>> R1 to party 2.
>> > 3) Party 2 computes c = H(X||R||m) and sends it to party 1 in order to
>> compute s1 = c.a1.x1 + r1
>> >
>> > Party 1 never learns the final value of (R,s1+s2) or m.
>> >
>> > Any comments on this or potential issues would be appreciated.
>> >
>> > Tom
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Blinded 2-party Musig2
We are implementing a version of 2-of-2 Schnorr Musig2 for statechains
where the server (party 1 in the 2-of-2) will be fully 'blinded' - in that
it can hold a private key that is required to generate an aggregate
signature on an aggregate public key, but that it does not learn either: 1)
The aggregate public key 2) The aggregate signature and 3) The message (m)
being signed.
In the model of blinded statechains, the security rests on the statechain
server being trusted to report the NUMBER of partial signatures it has
generated for a particular key (as opposed to being trusted to enforce
rules on WHAT it has signed in the unblinded case) and the full set of
signatures generated being verified client side
https://github.com/commerceblock/mercury/blob/master/doc/merc_blind.md#blinding-considerations
Given the 2-of-2 musig2 protocol operates as follows (in the following
description, private keys (field elements) are denoted using lower case
letters, and elliptic curve points as uppercase letters. G is the generator
point and point multiplication denoted as X = xG and point addition as A =
G + G):
Party 1 generates private key x1 and public key X1 = x1G. Party 2 generates
private key x2 and public key X2 = x2G. The set of pubkeys is L = {X1,X2}.
The key aggregation coefficient is KeyAggCoef(L,X) = H(L,X). The shared
(aggregate) public key X = a1X1 + a2X2 where a1 = KeyAggCoef(L,X1) and a2 =
KeyAggCoef(L,X2).
To sign a message m, party 1 generates nonce r1 and R1 = r1G. Party 2
generates nonce r2 and R2 = r2G. These are aggregated into R = R1 + R2.
Party 1 then computes 'challenge' c = H(X||R||m) and s1 = c.a1.x1 + r1
Party 2 then computes 'challenge' c = H(X||R||m) and s2 = c.a2.x2 + r2
The final signature is then (R,s1+s2).
In the case of blinding this for party 1:
To prevent party 1 from learning of either the full public key or final
signature seems straightforward, if party 1 doesn't not need to
independently compute and verify c = H(X||R||m) (as they are blinded from
the message in any case).
1) Key aggregation is performed only by party 2. Party 1 just sends X1 to
party 2.
2) Nonce aggregation is performed only by party 2. Party 1 just sends R1 to
party 2.
3) Party 2 computes c = H(X||R||m) and sends it to party 1 in order to
compute s1 = c.a1.x1 + r1
Party 1 never learns the final value of (R,s1+s2) or m.
Any comments on this or potential issues would be appreciated.
Tom
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Package Relay Proposal
The submitpackage RPC is available on regtest in the current core release. Is there any plan or timeline for deploying this on mainnet in the next release? Can't find any recent discussion. It would be very helpful given current (and likely future) issues with mempool purge. Tom ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] LN/mercury integrations
A couple of features we are considering for the mercury statechain wallet/service and would be good to get comments/feedback on. 1. In the current setup (https://github.com/commerceblock/mercury), deposits are free and permissionless (i.e. no authentication required to generate a shared key deposit addresses) and the mercury server fee (as a fixed percentage of the coin value) is collected in the withdrawal transaction as a UTXO paid to a fixed, specified bitcoin address. This has the advantage of making the deposit process low friction and user friendly, but has some disadvantages: The withdrawal transaction fee output is typically a small fraction of the coin value and for the smallest coin values is close to the dust limit (i.e. these outputs may not be spendable in a high tx fee environment). The on-chain mercury fee explicitly labels all withdrawn coins as mercury statechain withdrawals, which is a privacy concern for many users. The alternative that mitigates these issues is to charge the fee up-front, via a LN invoice, before the shared key deposit address is generated. In this approach, a user would specify in the wallet that they wanted to deposit a specific amount into a statecoin, and instead of performing a shared key generation with the server, would request a LN invoice for the withdrawal fee from the server, which would be returned to the wallet and displayed to the user. The user would then copy this invoice (by C&P or QR code) into a third party LN wallet and pay the fee. A LN node running on the mercury server back end would then verify that the payment had been made, and enable the wallet to continue with the deposit keygen and deposit process. This coin would be labeled as ‘fee paid’ by the wallet and server, and not be subject to an on-chain fee payment on withdrawal. 2. Withdrawal directly into LN channel. Currently the wallet can send the coin to any type of bitcoin address (except Taproot - P2TR - which is a pending straightforward upgrade). To create a dual funded channel (i.e. a channel where the counterparty provides BTC in addition to the mercury user) the withdrawal transaction process and co-signing with the server must support the handling of PSBTs. In this case, the withdrawal step would involve the mercury wallet co-signing (with the mercury server), a PSBT created by a LN wallet. To enable this, the mercury wallet should be able to both create a PSBT on the withdrawal page, and then co-sign it with the server, and then send it to the channel counterparty out of band (or via the third party LN wallet/node), and import a PSBT created by the channel counterparty and sign it, and export and/or broadcast the fully signed PSBT. This seems to be possible (i.e. paying directly to a dual funded channel opening tx from a third party wallet) with c-lightning and lnd via RPC, but I’m not aware of any LN wallet that would support this kind of thing. It has the potential to eliminate an on-chain tx, which could be valuable in a high-fee environment. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Statechain coinswap: assigning blame for failure in a two-stage transfer protocol.
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 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 > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Statechain coinswap: assigning blame for failure in a two-stage transfer protocol.
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 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 > ag
Re: [bitcoin-dev] Statechain coinswap: assigning blame for failure in a two-stage transfer protocol.
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 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 st
[bitcoin-dev] Statechain coinswap: assigning blame for failure in a two-stage transfer protocol.
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 wa
Re: [bitcoin-dev] Blind Statechains
t; to > achieve what I described. > > I'm not sure whether this can also apply to 2P-ECDSA, but with Schnorr the > statechain entity wouldn't even learn the address for the funding > transaction, so it wouldn't be able to tell which UTXO it controls by > watching the blockchain. Ideally, this functionality would be preserved to > ensure the statechain entity can't be aware of the funds it's holding. > > Another thing to note is that you won't know when a statechain has been > pegged out, so pruning will be impossible. You may wish to consider some > kind of liveness rule where one statechain transaction needs to be made per > year. If they miss the deadline, they're just forced on-chain, which is not > terrible, in any case. > > Hope this helps! > > Cheers, > Ruben > > > > On Fri, Jun 12, 2020 at 9:23 PM Tom Trevethan via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Hello, >> >> A statechain implementation and service co-signs 'backup' (off-chain) >> transactions to transfer ownership of a UTXO from one owner to the next. A >> suggested here >> https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39 >> , this service (the statechain entity or SE) can be engineered to be >> 'blind' to the transactions it is signing (i.e. it does not and cannot know >> the details of the transactions it is signing) which can give significant >> privacy benefits. It would enable more private off-chain coin-swaps, and >> make collusion more difficult. >> >> The only downside of a blind SE is that it can no longer enforce the >> rules governing the sequence of backup transactions it co-signs as owners >> can ask the SE to cosign any transaction. So each new owner of a UTXO must >> receive, store and verify the full sequence of previous owner backup >> transactions to make sure that no previous owner has asked the SE to sign a >> transaction that could be used to steal the UTXO. This may end up making >> wallets more bloated and clunky, given that ownership of a UTXO could >> change hands thousands of times off-chain. >> >> In the case of a multisig, and Schnorr signatures, existing blind Schnorr >> protocols could be used to implement a blind SE, however we are opting to >> use two-party ECDSA (because there is no Schnorr yet, and in any case ECDSA >> will give a much bigger anonymity set). There is no current 2P ECDSA >> protocol that enables one of the two signers to be completely blinded, but >> it seems that this would require only minor modifications to an existing 2P >> ECDSA scheme (outlined here >> https://github.com/commerceblock/mercury/blob/master/doc/blind_2p_ecdsa.md >> based on Lindell 2017 https://eprint.iacr.org/2017/552 ). >> >> Any comments on any of this gratefully received. >> >> Tom >> ___ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Blind Statechains
Hello, A statechain implementation and service co-signs 'backup' (off-chain) transactions to transfer ownership of a UTXO from one owner to the next. A suggested here https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39 , this service (the statechain entity or SE) can be engineered to be 'blind' to the transactions it is signing (i.e. it does not and cannot know the details of the transactions it is signing) which can give significant privacy benefits. It would enable more private off-chain coin-swaps, and make collusion more difficult. The only downside of a blind SE is that it can no longer enforce the rules governing the sequence of backup transactions it co-signs as owners can ask the SE to cosign any transaction. So each new owner of a UTXO must receive, store and verify the full sequence of previous owner backup transactions to make sure that no previous owner has asked the SE to sign a transaction that could be used to steal the UTXO. This may end up making wallets more bloated and clunky, given that ownership of a UTXO could change hands thousands of times off-chain. In the case of a multisig, and Schnorr signatures, existing blind Schnorr protocols could be used to implement a blind SE, however we are opting to use two-party ECDSA (because there is no Schnorr yet, and in any case ECDSA will give a much bigger anonymity set). There is no current 2P ECDSA protocol that enables one of the two signers to be completely blinded, but it seems that this would require only minor modifications to an existing 2P ECDSA scheme (outlined here https://github.com/commerceblock/mercury/blob/master/doc/blind_2p_ecdsa.md based on Lindell 2017 https://eprint.iacr.org/2017/552 ). Any comments on any of this gratefully received. Tom ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Statechain implementations
t the honesty of the SE. The seal system does not require any of >> the keys >> required for transfer. See https://mainstay.xyz as a potential >> implementation. >> There are lots of reasons this might required as an AML solution for some >> businesses anyway. >> >> Nadav Kohen via bitcoin-dev [bitcoin-dev@lists.linuxfoundation.org] >> wrote: >> > Hey all, >> > >> > So my main concern with the proposal as written is that the Statechain >> Entity >> > (SE) can untraceably scam its users with the following attack: >> > >> > 1) Buy the utxo (have it transferred to a key it knows), this first >> step can be >> > skipped if the utxo was created by the SE. >> > 2) Transfer the UTXO to someone else, let it be for however long >> > 3) When it wishes to steal the UTXO, the SE now knows its own shard s_n >> and it >> > knows the full private key, x, from when it owned the UTXO (and had both >> > shards), and so it can compute x/s_n = the current users shard. It can >> then >> > sign for the current user, and forge a state transition to a key it >> owns before >> > spending the UTXO on chain. >> > >> > The main problem here is that the user who had their funds stolen >> cannot prove >> > to anyone that this has happened since the attack compromises their key. >> > That said, I think this problem is easily fixed by adding a new user >> key to the >> > protocol with which they must sign in order for the transfer to be >> considered >> > valid on the state chain. This way, if the SE wishes to steal the funds >> (which >> > they still can), at least it is traceable/provable that this SE is not >> > trustworthy as there is no evidence of a valid transfer for the funds >> that have >> > been stolen. >> > >> > Best, >> > Nadav >> > >> > On Thu, Apr 2, 2020 at 7:22 PM Tom Trevethan via bitcoin-dev < >> > bitcoin-dev@lists.linuxfoundation.org> wrote: >> > >> > Thanks for all of the input and comments - I do now think that the >> > decrementing nSequence relative locktime backup system with kick-off >> > transaction is the way to go, including a fee penalty via CPFP to >> > disincentivise DoS, as suggested. >> > I have started a more detailed document specifying the proposed >> protocol in >> > more detail: https://github.com/commerceblock/mercury/blob/master/ >> > statechains.md which includes improvements to the >> transfer mechanism (and >> > an explanation of how this can be used to transfer/novate positions >> in >> > DLCs). Always happy to get more feedback or PRs. >> > >> > Tom >> > >> > On Tue, Mar 31, 2020 at 12:41 PM Tom Trevethan < >> t...@commerceblock.com> >> > wrote: >> > >> > Hi David, >> > >> > Just for clarity, I left nChain over 2 years ago (having worked >> there >> > since 2016). While there, I (along with other researchers) were >> given >> > free rein to work on any ideas we wanted to. I had been >> interested in >> > the scaling of Bitcoin off-chain, and this was one of several >> things I >> > spent time on (including things like sidechains, pegs and >> threshold >> > signatures). This patent application came out of an idea I had >> to >> > transfer ownership of UTXOs off-chain that has some >> similarities to the >> > statechains proposal, which has shown there is interest and >> demand for >> > this type of system. >> > >> > Although I think the existence of this application is something >> to be >> > mindful of, there are several important things to note: >> > >> > 1. Although there are similarities, the current ideas are >> significantly >> > different to those in the application. >> > 2. The key transfer protocol as described in the application is >> not >> > secure (for several reasons, including as discussed above, by >> Albert >> > and Bob etc.) - and a different mechanism is required. >> > 3. Decrementing timelocks (as suggested in the application) are >> prior >> > art (Decker-Wattenhofer 2015), and in any case any >> implementation will >> > most likely use an 'invalidation t
Re: [bitcoin-dev] Statechain implementations
roblem here is that the user who had their funds stolen cannot > prove > > to anyone that this has happened since the attack compromises their key. > > That said, I think this problem is easily fixed by adding a new user key > to the > > protocol with which they must sign in order for the transfer to be > considered > > valid on the state chain. This way, if the SE wishes to steal the funds > (which > > they still can), at least it is traceable/provable that this SE is not > > trustworthy as there is no evidence of a valid transfer for the funds > that have > > been stolen. > > > > Best, > > Nadav > > > > On Thu, Apr 2, 2020 at 7:22 PM Tom Trevethan via bitcoin-dev < > > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > > Thanks for all of the input and comments - I do now think that the > > decrementing nSequence relative locktime backup system with kick-off > > transaction is the way to go, including a fee penalty via CPFP to > > disincentivise DoS, as suggested. > > I have started a more detailed document specifying the proposed > protocol in > > more detail: https://github.com/commerceblock/mercury/blob/master/ > > statechains.md which includes improvements to the transfer mechanism > (and > > an explanation of how this can be used to transfer/novate positions > in > > DLCs). Always happy to get more feedback or PRs. > > > > Tom > > > > On Tue, Mar 31, 2020 at 12:41 PM Tom Trevethan < > t...@commerceblock.com> > > wrote: > > > > Hi David, > > > > Just for clarity, I left nChain over 2 years ago (having worked > there > > since 2016). While there, I (along with other researchers) were > given > > free rein to work on any ideas we wanted to. I had been > interested in > > the scaling of Bitcoin off-chain, and this was one of several > things I > > spent time on (including things like sidechains, pegs and > threshold > > signatures). This patent application came out of an idea I had to > > transfer ownership of UTXOs off-chain that has some similarities > to the > > statechains proposal, which has shown there is interest and > demand for > > this type of system. > > > > Although I think the existence of this application is something > to be > > mindful of, there are several important things to note: > > > > 1. Although there are similarities, the current ideas are > significantly > > different to those in the application. > > 2. The key transfer protocol as described in the application is > not > > secure (for several reasons, including as discussed above, by > Albert > > and Bob etc.) - and a different mechanism is required. > > 3. Decrementing timelocks (as suggested in the application) are > prior > > art (Decker-Wattenhofer 2015), and in any case any > implementation will > > most likely use an 'invalidation tree' relative locktime backup > > mechanism for open-ended UTXOs. > > 4. The patent application has not been granted (it was made in > May > > 2017) and the international search report rejected it on the > grounds of > > prior art. > > > > Tom > > > > On Tue, Mar 31, 2020 at 11:36 AM David A. Harding > > > wrote: > > > > On Wed, Mar 25, 2020 at 01:52:10PM +, Tom Trevethan via > > bitcoin-dev wrote: > > > Hi all, > > > > > > We are starting to work on an implementation of the > statechains > > concept ( > > > https://medium.com/@RubenSomsen/ > > > statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39), > > > > > > [...] > > > There are two main modifications we are looking at: > > > [...] > > > > > > 2. Replacing the 2-of-2 multisig output (paying to > statechain > > entity SE key > > > and transitory key) with a single P2(W)PKH output where the > > public key > > > shared between the SE and the current owner. The SE and the > > current owner > > > can then sign with a 2-of-2 ECDSA MPC. > > > >
Re: [bitcoin-dev] Statechain implementations
Thanks for all of the input and comments - I do now think that the decrementing nSequence relative locktime backup system with kick-off transaction is the way to go, including a fee penalty via CPFP to disincentivise DoS, as suggested. I have started a more detailed document specifying the proposed protocol in more detail: https://github.com/commerceblock/mercury/blob/master/statechains.md which includes improvements to the transfer mechanism (and an explanation of how this can be used to transfer/novate positions in DLCs). Always happy to get more feedback or PRs. Tom On Tue, Mar 31, 2020 at 12:41 PM Tom Trevethan wrote: > Hi David, > > Just for clarity, I left nChain over 2 years ago (having worked there > since 2016). While there, I (along with other researchers) were given free > rein to work on any ideas we wanted to. I had been interested in the > scaling of Bitcoin off-chain, and this was one of several things I spent > time on (including things like sidechains, pegs and threshold signatures). > This patent application came out of an idea I had to transfer ownership of > UTXOs off-chain that has some similarities to the statechains proposal, > which has shown there is interest and demand for this type of system. > > Although I think the existence of this application is something to be > mindful of, there are several important things to note: > > 1. Although there are similarities, the current ideas are significantly > different to those in the application. > 2. The key transfer protocol as described in the application is not secure > (for several reasons, including as discussed above, by Albert and Bob etc.) > - and a different mechanism is required. > 3. Decrementing timelocks (as suggested in the application) are prior art > (Decker-Wattenhofer 2015), and in any case any implementation will most > likely use an 'invalidation tree' relative locktime backup mechanism for > open-ended UTXOs. > 4. The patent application has not been granted (it was made in May 2017) > and the international search report rejected it on the grounds of prior > art. > > Tom > > On Tue, Mar 31, 2020 at 11:36 AM David A. Harding wrote: > >> On Wed, Mar 25, 2020 at 01:52:10PM +, Tom Trevethan via bitcoin-dev >> wrote: >> > Hi all, >> > >> > We are starting to work on an implementation of the statechains concept >> ( >> > >> https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39 >> ), >> > >> > [...] >> > There are two main modifications we are looking at: >> > [...] >> > >> > 2. Replacing the 2-of-2 multisig output (paying to statechain entity SE >> key >> > and transitory key) with a single P2(W)PKH output where the public key >> > shared between the SE and the current owner. The SE and the current >> owner >> > can then sign with a 2-of-2 ECDSA MPC. >> >> Dr. Trevethan, >> >> Would you be able to explain how your proposal to use statechains with >> 2P-ECDSA relates to your patent assigned to nChain Holdings for "Secure >> off-chain blockchain transactions"?[1] >> >> [1] https://patents.google.com/patent/US20200074464A1 >> >> Here are some excerpts from the application that caught my attention in >> the context of statechains in general and your proposal to this list in >> particular: >> >> > an exchange platform that is trusted to implement and operate the >> > transaction protocol, without requiring an on-chain transaction. The >> > off-chain transactions enable one computer system to generate multiple >> > transactions that are recordable to a blockchain in different >> > circumstances >> > >> > [...] >> > >> > at least some of the off-chain transactions are valid for recording on >> > the blockchain even in the event of a catastrophic failure of the >> > exchange (e.g., exchange going permanently off-line or loosing key >> > shares). >> > >> > [...] >> > >> > there may be provided a computer readable storage medium including a >> > two-party elliptic curve digital signature algorithm (two-party ECDSA) >> > script comprising computer executable instructions which, when >> > executed, configure a processor to perform functions of a two-party >> > elliptic curve digital signature algorithm described herein. >> > >> > [...] >> > >> > In this instance the malicious actor would then also have to collude >> > with a previous owner of the funds to recreate the full key. Because >> > an attack requires either the simultaneous theft of both exchange and >> > depositor keys or collusion with previous legitimate owners of funds, >> > the opportunities for a malicious attacker to compromise the exchange >> > platform are limited. >> >> Thank you, >> >> -Dave >> > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Statechain implementations
Hi David, Just for clarity, I left nChain over 2 years ago (having worked there since 2016). While there, I (along with other researchers) were given free rein to work on any ideas we wanted to. I had been interested in the scaling of Bitcoin off-chain, and this was one of several things I spent time on (including things like sidechains, pegs and threshold signatures). This patent application came out of an idea I had to transfer ownership of UTXOs off-chain that has some similarities to the statechains proposal, which has shown there is interest and demand for this type of system. Although I think the existence of this application is something to be mindful of, there are several important things to note: 1. Although there are similarities, the current ideas are significantly different to those in the application. 2. The key transfer protocol as described in the application is not secure (for several reasons, including as discussed above, by Albert and Bob etc.) - and a different mechanism is required. 3. Decrementing timelocks (as suggested in the application) are prior art (Decker-Wattenhofer 2015), and in any case any implementation will most likely use an 'invalidation tree' relative locktime backup mechanism for open-ended UTXOs. 4. The patent application has not been granted (it was made in May 2017) and the international search report rejected it on the grounds of prior art. Tom On Tue, Mar 31, 2020 at 11:36 AM David A. Harding wrote: > On Wed, Mar 25, 2020 at 01:52:10PM +, Tom Trevethan via bitcoin-dev > wrote: > > Hi all, > > > > We are starting to work on an implementation of the statechains concept ( > > > https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39 > ), > > > > [...] > > There are two main modifications we are looking at: > > [...] > > > > 2. Replacing the 2-of-2 multisig output (paying to statechain entity SE > key > > and transitory key) with a single P2(W)PKH output where the public key > > shared between the SE and the current owner. The SE and the current owner > > can then sign with a 2-of-2 ECDSA MPC. > > Dr. Trevethan, > > Would you be able to explain how your proposal to use statechains with > 2P-ECDSA relates to your patent assigned to nChain Holdings for "Secure > off-chain blockchain transactions"?[1] > > [1] https://patents.google.com/patent/US20200074464A1 > > Here are some excerpts from the application that caught my attention in > the context of statechains in general and your proposal to this list in > particular: > > > an exchange platform that is trusted to implement and operate the > > transaction protocol, without requiring an on-chain transaction. The > > off-chain transactions enable one computer system to generate multiple > > transactions that are recordable to a blockchain in different > > circumstances > > > > [...] > > > > at least some of the off-chain transactions are valid for recording on > > the blockchain even in the event of a catastrophic failure of the > > exchange (e.g., exchange going permanently off-line or loosing key > > shares). > > > > [...] > > > > there may be provided a computer readable storage medium including a > > two-party elliptic curve digital signature algorithm (two-party ECDSA) > > script comprising computer executable instructions which, when > > executed, configure a processor to perform functions of a two-party > > elliptic curve digital signature algorithm described herein. > > > > [...] > > > > In this instance the malicious actor would then also have to collude > > with a previous owner of the funds to recreate the full key. Because > > an attack requires either the simultaneous theft of both exchange and > > depositor keys or collusion with previous legitimate owners of funds, > > the opportunities for a malicious attacker to compromise the exchange > > platform are limited. > > Thank you, > > -Dave > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Statechain implementations
Hi all, We are starting to work on an implementation of the statechains concept ( https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39), with particular interest in using the protocol enable the change of ownership (novation) of an individual position in an active discreet log contract (DLC) without an on-chain transaction, and without needing the cooperation of the counterparty. The protocol as outlined by Ruben requires features not currently available in Bitcoin (like SIGHASH_NOINPUT), and it is uncertain when (or even if) this will be added. So we are looking at variants that would work with current Bitcoin functionality, and it would be good to get some feedback on them. There are two main modifications we are looking at: 1. Instead of an eltoo-based backup/refund transaction (enabling the current owner to claim the UTXO in case the statechain entity disappears) we propose using a decrementing nLocktime for backup transactions as the output changes hands. Here, the first owner gets a backup transaction with an nLocktime at some future height (h0), then the next owner gets a backup transaction with nLocktime (h0-c) where c is a confirmation window. This approach has the downside of limiting the lifetime of the UTXO, but it also doesn't require the current owner to be always online. 2. Replacing the 2-of-2 multisig output (paying to statechain entity SE key and transitory key) with a single P2(W)PKH output where the public key shared between the SE and the current owner. The SE and the current owner can then sign with a 2-of-2 ECDSA MPC. This enables each owner to generate their own private key share, and the SE changes their key share at each change of ownership (with the shared public key remaining the same). This works as follows (.G is EC point multiplication, * is scalar multiplication): KeyGen: a. Owner 1 generates private key share o1 then calculates the corresponding public key of the share O1 and sends it to the SE: O1 = o1.G b. The SE then generates a private key: s1 (the SE private key share), calculates the corresponding public key and sends it to Owner 1: S1 = s1.G c. Both SE and Owner 1 then multiply the public keys they receive by their own private key shares to obtain the same shared public key P (which corresponds to a shared private key of p = o1*s1): P = o1.(s1.G) = s1.(o1.G) d. Owner 1 creates a funding transaction (Tx0) to pay an amount A to the address corresponding to P (but doesn't sign it). e. Once Owner 1 and SE cooperatively sign the first backup transaction, Owner 1 then signs and broadcasts the deposit transaction Tx0. Transfer from Owner 1 to Owner 2: a. Owner 2 generates two private keys: o2 (the new owner UTXO private key share) and b2 (the new owner refund private key). b. The SE generates a temporary blinding nonce x and calculates the value x*s1 and sends this securely to Owner 2. c. Owner 2 then multiplies this received value by the modular inverse of o2 (o2_inv) and then sends this value (x*s1*o2_inv), to Owner 1. d. Owner 1 then multiplies this received value by the key share o1 and sends the resulting value (x*s1*o2_inv*o1) to the SE. e. The SE then multiplies this received value by the modular inverse of the temporary nonce (x_inv) to obtain x*s1*o2_inv*o1*x_inv. This cancels the blinding nonce x to give s1*o2_inv*o1. This value, when multiplied by the new owner key share o2 equals the original shared private key s1*o1. f. The SE then sets this value equal to s2 = s1*o2_inv*o1 and deletes s1. s2 and o2 are now the key shares of `P` and can be used to colaboritively sign (with 2P ECDSA). So long as the SE delets s1, the old owner key share (o1) is of no use in deriving or co-signing with the full shared private key, and is invalidated. g. The shared public key P remains unchanged, but the corresponding private key (which no individual party ever has knowledge of or can derive) can only be determined from the key shares of the SE and Owner 2 (i.e. P = s2*o2.G). h. Owner 2 then calculates their backup public key (B2 = b2.G) and sends it to the SE. i. The SE creates a backup transaction (Tx2) that pays the output of Tx0 to the address corresponding to B2 , with `nLockTime` set to a block height h0 - c0, where c0, is a confirmation time sufficient to guarantee that Tx2 can be confirmed in the blockchain before Tx1 (therefore making Tx1 invalid). j. Owner 2 and the SE then cooperate to sign Tx2 with shared key (P) using the 2P ECDSA protocol, which Owner 2 then saves. The principle of the logic of the key transfer is that the two separate key shares are updated, but the full shared private key (which no-one knows) remains the same. The new owner chooses a new secret value for their private key share, and this (along with the private key share of the previous owner) is utilized by the SE to update their share. The use of the nonce (x) prevents any of the participants from determining any information about each others s
