public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Tom Trevethan <tom@commerceblock.com>
To: Lloyd Fournier <lloyd.fourn@gmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Blinded 2-party Musig2
Date: Thu, 10 Aug 2023 12:59:52 +0100	[thread overview]
Message-ID: <CAJvkSsdCeOvKgh2B0rxZu1Hv92Ap8k_92v5ViKKigSOVAeH4hA@mail.gmail.com> (raw)
In-Reply-To: <CAH5Bsr1-zTrYNFcSKRf_nVX5LJ6goT8ccDjipWFb6KbSpSq7-A@mail.gmail.com>

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

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@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@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@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@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@commerceblock.com>
>>> wrote:
>>>
>>>>
>>>> On Thu, Jul 27, 2023 at 9:08 AM Jonas Nick <jonasdnick@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@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

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

  reply	other threads:[~2023-08-10 12:00 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-24  7:46 [bitcoin-dev] Blinded 2-party Musig2 Tom Trevethan
2023-07-24 10:50 ` ZmnSCPxj
2023-07-24 14:25   ` Erik Aronesty
2023-07-24 16:08     ` Tom Trevethan
2023-07-24 15:57   ` Tom Trevethan
2023-07-24 14:12 ` Jonas Nick
2023-07-24 14:40   ` Erik Aronesty
2023-07-24 15:40     ` Jonas Nick
2023-07-24 16:51   ` AdamISZ
2023-07-25 14:12     ` Erik Aronesty
2023-07-25 16:05       ` Tom Trevethan
2023-07-26  4:09         ` Erik Aronesty
2023-07-26 17:40           ` Andrew Poelstra
2023-07-26 19:59           ` Jonas Nick
2023-07-26 20:35             ` Tom Trevethan
2023-07-26 22:06               ` Erik Aronesty
2023-07-27  2:54                 ` Lloyd Fournier
2023-07-27  8:07               ` Jonas Nick
     [not found]                 ` <CAJvkSsfa8rzbwXiatZBpwQ6d4d94yLQifK8gyq3k-rq_1SH4OQ@mail.gmail.com>
2023-07-27 13:25                   ` [bitcoin-dev] Fwd: " Tom Trevethan
2023-08-07  0:55                     ` [bitcoin-dev] " Tom Trevethan
2023-08-08 17:44                       ` moonsettler
2023-08-09 15:14                         ` Tom Trevethan
2023-08-10  3:30                           ` Lloyd Fournier
2023-08-10 11:59                             ` Tom Trevethan [this message]
2023-08-14  6:31                               ` Lloyd Fournier
2023-08-30 10:52                       ` Tom Trevethan
2023-07-24 15:39 ` Jonas Nick
2023-07-24 16:22   ` Tom Trevethan
2023-07-26  9:44   ` moonsettler
2023-07-26 14:59     ` Jonas Nick
2023-07-26 19:19     ` AdamISZ
2023-07-26 19:28       ` moonsettler
2023-07-27  5:51         ` AdamISZ
     [not found] <mailman.125690.1690381971.956.bitcoin-dev@lists.linuxfoundation.org>
2023-07-26 16:32 ` Tom Trevethan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJvkSsdCeOvKgh2B0rxZu1Hv92Ap8k_92v5ViKKigSOVAeH4hA@mail.gmail.com \
    --to=tom@commerceblock.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=lloyd.fourn@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox