moonsettler [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2023-06-11 to 2023-08-08
💬 Posted a total of 4 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-08-09 16:03:59

- reply

📅 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>

2023-07-27 00:26:35

- reply

📅 Original date posted:2023-07-26
🗒️ Summary of this message: The sender is discussing a protocol that incorporates 2FA authentication and blind signing, but there are concerns about potential attacks.
📝 Original message:
Yes, thank you!
There I assume if someone has your private key, and can satisfy the 2FA, he will just steal your coins, and not bother with extracting the co-signers key that is specific to you. I can see, how this assumption is not useful generally.
BR,
moonsettler
Sent with Proton Mail secure email.
------- Original Message -------
On Wednesday, July 26th, 2023 at 9:19 PM, AdamISZ <AdamISZ at protonmail.com> wrote:
> It's an interesting idea for a protocol. If I get it right, your basic idea here is to kind of "shoehorn" in a 2FA authentication, and that the blind-signing server has no other function than to check the 2FA?
>
> This makes it different from most uses of blind signing, where counting the number of signatures matters (hence 'one more forgery etc). Here, you are just saying "I'll sign whatever the heck you like, as long as you're authorized with this 2FA procedure".
>
> Going to ignore the details of practically what that means - though I'm sure that's where most of the discussion would end up - but just looking at your protocol in the gist:
>
> It seems you're not checking K values against attacks, so for example this would allow someone to extract the server's key from one signing:
>
> 1 Alice, after receiving K2, sets K1 = K1' - K2, where the secret key of K1' is k1'.
> 2 Chooses b as normal, sends e' as normal.
> 3 Receiving s2, calculate s = s1 + s2 as normal.
>
> So since s = k + ex = (k' + bx) + ex = k' + e'x, and you know s, k' and e', you can derive x. Then x2 = x - x1.
>
> (Gist I'm referring to: https://gist.github.com/moonsettler/05f5948291ba8dba63a3985b786233bb)
>
>
>
>
> Sent with Proton Mail secure email.
>
>
> ------- Original Message -------
> On Wednesday, July 26th, 2023 at 03:44, moonsettler via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:
>
>
>
> > Hi All,
> >
> > I believe it's fairly simple to solve the blinding (sorry for the bastard notation!):
> >
> > Signing:
> >
> > X = X1 + X2
> > K1 = k1G
> > K2 = k2G
> >
> > R = K1 + K2 + bX
> > e = hash(R||X||m)
> >
> > e' = e + b
> > s = (k1 + e'*x1) + (k2 + e'*x2)
> > s = (k1 + k2 + b(x1 + x2)) + e(x1 + x2)
> >
> > sG = (K1 + K2 + bX) + eX
> > sG = R + eX
> >
> > Verification:
> >
> > Rv = sG - eX
> > ev = hash(R||X||m)
> > e ?= ev
> >
> > https://gist.github.com/moonsettler/05f5948291ba8dba63a3985b786233bb
> >
> > Been trying to get a review on this for a while, please let me know if I got it wrong!
> >
> > BR,
> > moonsettler
> >
> > ------- Original Message -------
> > On Monday, July 24th, 2023 at 5:39 PM, Jonas Nick via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org 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.
> > > _______________________________________________
> > > 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

2023-07-27 00:26:35

- reply

2023-07-27 00:26:34

- reply

📅 Original date posted:2023-07-26
🗒️ Summary of this message: The author proposes a solution to the blinding issue in a signature protocol and seeks feedback on its correctness.
📝 Original message:
Hi All,
I believe it's fairly simple to solve the blinding (sorry for the bastard notation!):
Signing:
X = X1 + X2
K1 = k1G
K2 = k2G
R = K1 + K2 + bX
e = hash(R||X||m)
e' = e + b
s = (k1 + e'*x1) + (k2 + e'*x2)
s = (k1 + k2 + b(x1 + x2)) + e(x1 + x2)
sG = (K1 + K2 + bX) + eX
sG = R + eX
Verification:
Rv = sG - eX
ev = hash(R||X||m)
e ?= ev
https://gist.github.com/moonsettler/05f5948291ba8dba63a3985b786233bb
Been trying to get a review on this for a while, please let me know if I got it wrong!
BR,
moonsettler
------- Original Message -------
On Monday, July 24th, 2023 at 5:39 PM, Jonas Nick via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> 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.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-07-27 00:26:34

- reply

2023-06-15 00:54:55

- reply

📅 Original date posted:2023-06-11
🗒️ Summary of this message: The author questions the statement that "APO can emulate CTV" and discusses the consequences for Ark's ATLCs, suggesting that OP_CTV is more enforceable.
📝 Original message:
Hi All,
I have a question about the often touted statement that "APO can emulate CTV". From what I have found in the specs and the inquisition codebase:
> BIP-118 ANYPREVOUTANYSCRIPT can constrain outputs of a spending transaction by hardcoding a 65-byte signature and a 33-byte unknown public key type in a script. Alternatively, BIP-119 CTV can directly constrain transaction outputs to a template hash.
APO/AS SIGHASH does not commit to the number of inputs (nor obviously the other input outpoints themselves). This has some interesting consequences for Ark, which relies on TXID non-malleability for it's ATLCs.
Either one of these cases seem to be true depending on how the contracts are constructed:
- APO only: Users can double spend the ASP (USER CAN STEAL)
- APO + ASP single sig: ASP can stop users from unilateral exit and sweep funds after 4 weeks (ASP CAN STEAL)
- n-of-n musig on the vTXO tree: trustless, APO however is not needed, full interactivity, analogous to key deletion covenant (NOBODY CAN STEAL)
APO/AS can also not be used for the ATLC itself, as it has to commit to the TX outpoint of the connector transaction.
OP_CTV however commits to the number of inputs explicitly, thus committing to a single input prevents TXID malleability and ensures the ATLC is going to be enforceable.
I would like to ask what the devs who are deeper into covenant research think about this, and if I'm missing something?
- moonsettler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230611/a036b05f/attachment.html>