š
Original date posted:2015-11-27
š Original message:
I love how people come up with sneaky solutions to force the other
party to reveal the private key somehow. But given that we might have
dozens of HTLCs in a commit transactions or also payments that pay to
two (or more) payment keys (is this the new term for it now?) we
should maybe strive for a more clean solution.
I have summarized most of the information of this discussion and
'handed in' a BIP request to the bitcoin-dev mailing list. If the use
case is good enough (and I think it is) and there are little draw
backs (can't think of any security-relevant one), there should not be
too much resistance.
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011827.html
Cheers,
Mats
2015-11-27 5:42 GMT+01:00 Anthony Towns <aj at erisian.com.au>:
> 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
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Mats Jerratsch [ARCHIVE] /
npub1hzā¦q5x8w
2023-06-09 12:45:05
in reply to nevent1qā¦8d6f
Author Public Key
npub1hz386xq4qszumlx5fsxa3kuxpaf8qvfrqqjg8zdl2l892hrcg55q6q5x8wPublished at
2023-06-09 12:45:05Event JSON
{
"id": "8473899b65ff0d0a2b2a743d2fcecd5f2be2a4d14a414fb97d977a648caf9ee8",
"pubkey": "b8a27d18150405cdfcd44c0dd8db860f5270312300248389bf57ce555c784528",
"created_at": 1686314705,
"kind": 1,
"tags": [
[
"e",
"ebf410166f334c23aa8c4463788497d09c02fc7a472b5ea556de811c6970ae8b",
"",
"root"
],
[
"e",
"e2e016249ac95fa66026d2b2b431d1368ddfcfe7100ccbd5cc285f73dbae8513",
"",
"reply"
],
[
"p",
"f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab"
]
],
"content": "š
Original date posted:2015-11-27\nš Original message:\nI love how people come up with sneaky solutions to force the other\nparty to reveal the private key somehow. But given that we might have\ndozens of HTLCs in a commit transactions or also payments that pay to\ntwo (or more) payment keys (is this the new term for it now?) we\nshould maybe strive for a more clean solution.\n\nI have summarized most of the information of this discussion and\n'handed in' a BIP request to the bitcoin-dev mailing list. If the use\ncase is good enough (and I think it is) and there are little draw\nbacks (can't think of any security-relevant one), there should not be\ntoo much resistance.\n\nhttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011827.html\n\nCheers,\nMats\n\n2015-11-27 5:42 GMT+01:00 Anthony Towns \u003caj at erisian.com.au\u003e:\n\u003e On Fri, Nov 27, 2015 at 02:25:09PM +1030, Rusty Russell wrote:\n\u003e\u003e Anthony Towns \u003caj at erisian.com.au\u003e writes:\n\u003e\u003e \u003e The alternative approach, which andytoshi and I came up with\n\u003e\u003e \u003e independently is a lot more complicated:\n\u003e\u003e \u003e revealP( Q, R, sigA, sigB, sigC ) {\n\u003e\u003e \u003e check_multisig_verify(2, P, R, 2, sigA, sigB); code_separtor();\n\u003e\u003e \u003e check_multisig_verify(2, Q, R, 2, sigA, sigC); code_separtor();\n\u003e\u003e \u003e check_multisig_verify(2, P, Q, 2, sigC, sigB);\n\u003e\u003e \u003e }\n\u003e\u003e \u003e If sigA, sigB and sigC all share the same r and SIGHASH settings,\n\u003e\u003e I don't think this works? We can't provide the signatures in the\n\u003e\u003e scriptPubkey, since that requires them signing themselves.\n\u003e\n\u003e The scriptPubkey has the pubkey P, and a whole mess of stack operations\n\u003e to implement the function above; the scriptSig just has Q, R and the\n\u003e three signatures.\n\u003e\n\u003e\u003e We can't\n\u003e\u003e have them provide it in the scriptSig, since theres no \"do these have\n\u003e\u003e the same r value\" operator in script.\n\u003e\n\u003e There's six sig ops, but only three different signatures. Getting the\n\u003e various combinations to have the same signature forces the same r value\n\u003e between each of the signatures, without needing a separate op to check\n\u003e it explicitly.\n\u003e\n\u003e It's mathematically possible to come up with Q, R, sigA, sigB, sigC where\n\u003e sigA.r, sigB.r and sigC.r are all different; but it requires being able\n\u003e to come up with a transaction with a particular hash, or calculating the\n\u003e discrete log of a weird value to do so, so should be safely intractable.\n\u003e\n\u003e Cheers,\n\u003e aj\n\u003e\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev",
"sig": "d9260886acca90d6bb429a25b5bc104dc43c19228108fd1998e60e5fdf90747ce3c3a39e7fb193942cfaa2f189de1fab858c573e992a051deee8b800f9575bb0"
}