moonsettler [ARCHIVE] on Nostr: 📅 Original date posted:2023-08-08 🗒️ Summary of this message: The author ...
📅 Original date posted:2023-08-08
🗒️ Summary of this message: The author discusses an update to the blinded statechain protocol to mitigate the Wagner attack and ensure the honesty of computed values.
📝 Original message:
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/20230808/41a344ee/attachment.html>;
🗒️ Summary of this message: The author discusses an update to the blinded statechain protocol to mitigate the Wagner attack and ensure the honesty of computed values.
📝 Original message:
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/20230808/41a344ee/attachment.html>;