Hi Tom, Thanks for the explanation. There's one remaining thing that isn't clear: do you actually require parallel signing requests under the same key. It seems to me that the protocol is very sequential in that you are passing a utxo from one point to another in sequence. If so then the Schnorr blind sigs problem doesn't apply. LL On Thu, 10 Aug 2023 at 20:00, Tom Trevethan wrote: > 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/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 >>> >>