Tom Trevethan [ARCHIVE] on Nostr: 📅 Original date posted:2023-08-09 🗒️ Summary of this message: Coins in the ...
📅 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>;
🗒️ 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>;