Nostr notes by Tom Trevethan [ARCHIVE]

📅 Original date posted:2023-08-10 🗒️ Summary of this ...

2023-08-11T01:09:38+02:00

In reply to nevent1q…tmxg
_________________________

📅 Original date posted:2023-08-10
🗒️ Summary of this message: Blind signatures are used in the statechain protocol for bitcoin transactions to ensure security and prevent malicious signatures. The server generates partial signatures, but does not have access to the full key, message, or final signature. The receiver must verify all previous backup transactions and the total number of signatures before accepting the coin.
📝 Original message:
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 <lloyd.fourn at gmail.com>
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 at 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 <moonsettler at protonmail.com>
>> 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 at 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 <tom at commerceblock.com>
>>> wrote:
>>>
>>>>
>>>> On Thu, Jul 27, 2023 at 9:08 AM Jonas Nick <jonasdnick at gmail.com>
>>>> 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230810/e3f1fcb8/attachment.html>;

📅 Original date posted:2023-08-09 🗒️ Summary of this ...

2023-08-09T18:04:00+02:00

In reply to nevent1q…xk3w
_________________________

📅 Original date posted:2023-08-09
🗒️ Summary of this message: Coins in the statechain protocol require verification of previous signatures and backup transactions. Transfer data is encrypted with the new owner's public key, and a non-identifying key can be used for authentication with the server.
📝 Original message:
@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 <moonsettler at protonmail.com>
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 at 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 <tom at commerceblock.com>
> wrote:
>
>>
>> On Thu, Jul 27, 2023 at 9:08 AM Jonas Nick <jonasdnick at gmail.com> 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.
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230809/94da0e46/attachment.html>;

📅 Original date posted:2023-08-06 🗒️ Summary of this ...

2023-08-08T16:20:52+02:00

In reply to nevent1q…xc9q
_________________________

📅 Original date posted:2023-08-06
🗒️ Summary of this message: The blinded statechain protocol has been updated to include mitigation against the Wagner attack by requiring verification of previous computed values by new statecoin owners.
📝 Original message:
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 <tom at commerceblock.com> wrote:

>
> On Thu, Jul 27, 2023 at 9:08 AM Jonas Nick <jonasdnick at gmail.com> 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.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230807/f1841d99/attachment.html>;

📅 Original date posted:2023-07-24 🗒️ Summary of this ...

2023-07-27T02:26:33+02:00

In reply to nevent1q…wek4
_________________________

📅 Original date posted:2023-07-24
🗒️ Summary of this message: The sender is discussing with Jonas the need for a method to blind the value of c in order to prevent the server from learning the value of m.
📝 Original message:
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 <jonasdnick at gmail.com> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230724/2bc0b366/attachment.html>;

📅 Original date posted:2023-07-26 🗒️ Summary of this ...

2023-07-27T02:26:33+02:00

In reply to nevent1q…kka0
_________________________

📅 Original date posted:2023-07-26
🗒️ Summary of this message: Proving knowledge of the r values used in generating each R can prevent the Wagner attack, not signing or secret keys.
📝 Original message:
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 <jonasdnick at gmail.com> 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).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230726/05286983/attachment-0001.html>;

📅 Original date posted:2023-07-25 🗒️ Summary of this ...

2023-07-27T02:26:33+02:00

In reply to nevent1q…3aw8
_________________________

📅 Original date posted:2023-07-25
🗒️ Summary of this message: The v=2 nonces signing protocol of musig2 prevents the Wagner attack. The challenge value c must be blinded from the server to prevent signature determination.
📝 Original message:
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 <erik at q32.com> 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 at 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 with Jonas that this is just the start, i.e. the fundamental
>> requirement of a blind signing scheme is there has to be some guarantee of
>> no 'one more forgery' possibility, so presumably there has to be some proof
>> that the signing request is 'well formed' (Jonas expresses it below as a
>> ZKP of a SHA2 preimage .. it does not seem pretty but I agree that on the
>> face of it, that is what's needed).
>>
>> @Jonas, Erik:
>> 'posk' is probably meant as 'proof of secret key' which may(?) be a mixup
>> with what is sometimes referred to in the literature as "KOSK" (iirc they
>> used it in FROST for example). It isn't clear to me yet how that factors
>> into this scenario, although ofc it is for sure a potential building block
>> of these constructions.
>>
>> Sent with Proton Mail secure email.
>>
>> ------- Original Message -------
>> On Monday, July 24th, 2023 at 08:12, Jonas Nick via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>
>> > Hi Tom,
>> >
>> > I'm not convinced that this works. As far as I know blind musig is
>> still an open
>> > research problem. What the scheme you propose appears to try to prevent
>> is that
>> > the server signs K times, but the client ends up with K+1 Schnorr
>> signatures for
>> > the aggregate of the server's and the clients key. I think it's
>> possible to
>> > apply a variant of the attack that makes MuSig1 insecure if the nonce
>> commitment
>> > round was skipped or if the message isn't determined before sending the
>> nonce.
>> > Here's how a malicious client would do that:
>> >
>> > - Obtain K R-values R1[0], ..., R1[K-1] from the server
>> > - Let
>> > R[i] := R1[i] + R2[i] for all i <= K-1
>> > R[K] := R1[0] + ... + R1[K-1]
>> > c[i] := H(X, R[i], m[i]) for all i <= K.
>> > Using Wagner's algorithm, choose R2[0], ..., R2[K-1] such that
>> > c[0] + ... + c[K-1] = c[K].
>> > - Send c[0], ..., c[K-1] to the server to obtain s[0], ..., s[K-1].
>> > - Let
>> > s[K] = s[0] + ... + s[K-1].
>> > Then (s[K], R[K]) is a valid signature from the server, since
>> > s[K]G = R[K] + c[K]a1X1,
>> > which the client can complete to a signature for public key X.
>> >
>> > What may work in your case is the following scheme:
>> > - Client sends commitment to the public key X2, nonce R2 and message m
>> to the
>> > server.
>> > - Server replies with nonce R1 = k1G
>> > - Client sends c to the server and proves in zero knowledge that c =
>> > SHA256(X1 + X2, R1 + R2, m).
>> > - Server replies with s1 = k1 + c*x1
>> >
>> > However, this is just some quick intuition and I'm not sure if this
>> actually
>> > works, but maybe worth exploring.
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230725/f5e995d9/attachment-0001.html>;

📅 Original date posted:2023-07-24 🗒️ Summary of this ...

2023-07-24T13:36:00+02:00

In reply to nevent1q…670e
_________________________

📅 Original date posted:2023-07-24
🗒️ Summary of this message: A version of 2-of-2 Schnorr Musig2 is being implemented for statechains, where the server is fully blinded and does not learn certain information. The security relies on the server reporting the number of partial signatures generated and verifying the signatures client-side. The protocol operates by generating private and public keys, aggregating the public keys, generating nonces, computing challenges, and creating the final signature. In the case of blinding for party 1, key aggregation and nonce aggregation are performed by party 2, and party 1 does not learn the final signature or the message being signed.
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230724/9454c8c8/attachment.html>;

📅 Original date posted:2020-09-13 📝 Original message:We are ...

2023-06-07T20:26:48+02:00

In reply to nevent1q…3q5m
_________________________

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

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

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

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

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

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

Cheers,

Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200913/22a2f536/attachment.html>;

📅 Original date posted:2020-03-25 📝 Original message:Hi ...

2023-06-07T20:23:34+02:00

In reply to nevent1q…qhtr
_________________________

📅 Original date posted:2020-03-25
📝 Original message: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 secret keys. In this way Owner 2 cannot determine s1 from
x*s1, Owner 1 cannot determine s1 or o2 from x*s1*o2_inv and the SE cannot
determine o1 or o2 from x*s1*o2_inv*o1.

This transfer protocol can be repeated to transfer the ownership to new
owners. Each time the SE key share sX is updated, the previous key shares
become invalid and are of no use even if the current key share is
subsequently revealed. The SE still needs to be trusted to delete the old
key share, but this protocol removes the risk the the SE can be hacked by a
previous owner to steal the funds.

Any comments on the above would be greatly appreciated.

Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200325/d83a4cfd/attachment-0001.html>;