📅 Original date posted:2015-10-19
📝 Original message:
Mats Jerratsch <matsjj at gmail.com> writes:
>> This makes some sense (though the anchor transactions don't need to be
>> P2SH, it's nicer for bitcoin's UTXO if they are).
>
> Well, currently there is no one working on a malleability fix, so we
> should probably work forwards the next available goal. ;)
Oh, I'm pushing BIP 62, as well, in parallel with everything else :)
>>> For the current form it would be enough to have
>>> SecretAHash || KeyB' || KeyB || KeyA || TxID || SignatureB (L=231B)
>>> with KeyB being the node pubkey (lots of key reusage...)
>>> or
>>> SecretAHash || KeyB' || KeyB || KeyA || TxID || nodePubKey ||
>>> SignatureB (L=264B) with KeyB as a channel key that does not need to
>>> be equal with the nodePubKey.
>>
>> Yes, I think avoiding key reuse is good. So, to be clear, the anchor TX
>> output looks like:
>>
>> P2SH (2 KEYA KEYB 2 OP_CHECKMULTISIG)
>
> Having to deal with malleability, the only viable solution for anchor
> transactions are with escape and fast-escape?
>
>> I think we can do slightly better with Schnorr signatures (which you can
>> simply do multisig by addition, if I understand correctly) where both
>> parties cooperate to form:
>>
>> KEYA KEYB NODE-PUBKEYA NODE-PUBKEYB TXID DUAL-SIGNATURE
>>
>> That's 33+33+33+33+32+64 = 228 bytes per channel.
>
> Interesting, I kinda feel uncomfortable with Schnorr though. It feels
> like some experimental method, and at least for Java, there are very
> few implementations around (and I don't feel comfortable implementing
> it on my own either..)
>
> I like the idea of adding together one object for the channel to be
> sent by both nodes. Even without Schnorr it saves some bytes and the
> overhead of gossipping.. We can always switch the signature to Schnorr
> too..
Yes, we've not as bound to consensus, which is nice. Schnorr is
something we can decide on later, for sure.
Cheers,
Rusty.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 12:44:48
in reply to nevent1q…tmzu
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 12:44:48Event JSON
{
"id": "4468ca3af17059c85330e9db86b0a9753b0fd9fac406f968f9e5c21eb5249b71",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686314688,
"kind": 1,
"tags": [
[
"e",
"a852f7164f575698e067e8fc679f5003dd9087247fc7ef7f6067ab966288eef1",
"",
"root"
],
[
"e",
"c119778f3a4448521bf460e6d47617fcea2b8e8604d37d818cd8854b4f0e68df",
"",
"reply"
],
[
"p",
"b8a27d18150405cdfcd44c0dd8db860f5270312300248389bf57ce555c784528"
]
],
"content": "📅 Original date posted:2015-10-19\n📝 Original message:\nMats Jerratsch \u003cmatsjj at gmail.com\u003e writes:\n\u003e\u003e This makes some sense (though the anchor transactions don't need to be\n\u003e\u003e P2SH, it's nicer for bitcoin's UTXO if they are).\n\u003e\n\u003e Well, currently there is no one working on a malleability fix, so we\n\u003e should probably work forwards the next available goal. ;)\n\nOh, I'm pushing BIP 62, as well, in parallel with everything else :)\n\n\u003e\u003e\u003e For the current form it would be enough to have\n\u003e\u003e\u003e SecretAHash || KeyB' || KeyB || KeyA || TxID || SignatureB (L=231B)\n\u003e\u003e\u003e with KeyB being the node pubkey (lots of key reusage...)\n\u003e\u003e\u003e or\n\u003e\u003e\u003e SecretAHash || KeyB' || KeyB || KeyA || TxID || nodePubKey ||\n\u003e\u003e\u003e SignatureB (L=264B) with KeyB as a channel key that does not need to\n\u003e\u003e\u003e be equal with the nodePubKey.\n\u003e\u003e\n\u003e\u003e Yes, I think avoiding key reuse is good. So, to be clear, the anchor TX\n\u003e\u003e output looks like:\n\u003e\u003e\n\u003e\u003e P2SH (2 KEYA KEYB 2 OP_CHECKMULTISIG)\n\u003e\n\u003e Having to deal with malleability, the only viable solution for anchor\n\u003e transactions are with escape and fast-escape?\n\u003e\n\u003e\u003e I think we can do slightly better with Schnorr signatures (which you can\n\u003e\u003e simply do multisig by addition, if I understand correctly) where both\n\u003e\u003e parties cooperate to form:\n\u003e\u003e\n\u003e\u003e KEYA KEYB NODE-PUBKEYA NODE-PUBKEYB TXID DUAL-SIGNATURE\n\u003e\u003e\n\u003e\u003e That's 33+33+33+33+32+64 = 228 bytes per channel.\n\u003e\n\u003e Interesting, I kinda feel uncomfortable with Schnorr though. It feels\n\u003e like some experimental method, and at least for Java, there are very\n\u003e few implementations around (and I don't feel comfortable implementing\n\u003e it on my own either..)\n\u003e\n\u003e I like the idea of adding together one object for the channel to be\n\u003e sent by both nodes. Even without Schnorr it saves some bytes and the\n\u003e overhead of gossipping.. We can always switch the signature to Schnorr\n\u003e too..\n\nYes, we've not as bound to consensus, which is nice. Schnorr is\nsomething we can decide on later, for sure.\n\nCheers,\nRusty.",
"sig": "c1a96908c6fc2d7f446854227e308517fa6b6df4dacfec9e6a581c57ee60fe41e74931a475570951fa5d9d497dcc4907eac2dd06170330436427683e16518a17"
}