Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2015-11-27 📝 Original message: On Fri, Nov 27, 2015 at ...
📅 Original date posted:2015-11-27
📝 Original message:
On Fri, Nov 27, 2015 at 02:25:09PM +1030, Rusty Russell wrote:
> Anthony Towns <aj at erisian.com.au> writes:
> > The alternative approach, which andytoshi and I came up with
> > independently is a lot more complicated:
> > revealP( Q, R, sigA, sigB, sigC ) {
> > check_multisig_verify(2, P, R, 2, sigA, sigB); code_separtor();
> > check_multisig_verify(2, Q, R, 2, sigA, sigC); code_separtor();
> > check_multisig_verify(2, P, Q, 2, sigC, sigB);
> > }
> > If sigA, sigB and sigC all share the same r and SIGHASH settings,
> I don't think this works? We can't provide the signatures in the
> scriptPubkey, since that requires them signing themselves.
The scriptPubkey has the pubkey P, and a whole mess of stack operations
to implement the function above; the scriptSig just has Q, R and the
three signatures.
> We can't
> have them provide it in the scriptSig, since theres no "do these have
> the same r value" operator in script.
There's six sig ops, but only three different signatures. Getting the
various combinations to have the same signature forces the same r value
between each of the signatures, without needing a separate op to check
it explicitly.
It's mathematically possible to come up with Q, R, sigA, sigB, sigC where
sigA.r, sigB.r and sigC.r are all different; but it requires being able
to come up with a transaction with a particular hash, or calculating the
discrete log of a weird value to do so, so should be safely intractable.
Cheers,
aj
Published at
2023-06-09 12:45:05Event JSON
{
"id": "e2e016249ac95fa66026d2b2b431d1368ddfcfe7100ccbd5cc285f73dbae8513",
"pubkey": "f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab",
"created_at": 1686314705,
"kind": 1,
"tags": [
[
"e",
"ebf410166f334c23aa8c4463788497d09c02fc7a472b5ea556de811c6970ae8b",
"",
"root"
],
[
"e",
"d692e42c9cbaa0a0925ecf5bdbdc30b02a1e4667e9b32b6c9f23a4d3cbde1b93",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2015-11-27\n📝 Original message:\nOn Fri, Nov 27, 2015 at 02:25:09PM +1030, Rusty Russell wrote:\n\u003e Anthony Towns \u003caj at erisian.com.au\u003e writes:\n\u003e \u003e The alternative approach, which andytoshi and I came up with\n\u003e \u003e independently is a lot more complicated:\n\u003e \u003e revealP( Q, R, sigA, sigB, sigC ) {\n\u003e \u003e check_multisig_verify(2, P, R, 2, sigA, sigB); code_separtor();\n\u003e \u003e check_multisig_verify(2, Q, R, 2, sigA, sigC); code_separtor();\n\u003e \u003e check_multisig_verify(2, P, Q, 2, sigC, sigB);\n\u003e \u003e }\n\u003e \u003e If sigA, sigB and sigC all share the same r and SIGHASH settings,\n\u003e I don't think this works? We can't provide the signatures in the\n\u003e scriptPubkey, since that requires them signing themselves. \n\nThe scriptPubkey has the pubkey P, and a whole mess of stack operations\nto implement the function above; the scriptSig just has Q, R and the\nthree signatures.\n\n\u003e We can't\n\u003e have them provide it in the scriptSig, since theres no \"do these have\n\u003e the same r value\" operator in script.\n\nThere's six sig ops, but only three different signatures. Getting the\nvarious combinations to have the same signature forces the same r value\nbetween each of the signatures, without needing a separate op to check\nit explicitly.\n\nIt's mathematically possible to come up with Q, R, sigA, sigB, sigC where\nsigA.r, sigB.r and sigC.r are all different; but it requires being able\nto come up with a transaction with a particular hash, or calculating the\ndiscrete log of a weird value to do so, so should be safely intractable.\n\nCheers,\naj",
"sig": "94225f189afe5925e9a383b30e1b51ed35f912e766885ff26af37cd02877ec615b876a24dc11885c1197a27fb42c321e45e69a246d602a9d25e11357ec34d503"
}