š
Original date posted:2018-11-04
š Original message:
Good morninh list,
Sent with ProtonMail Secure Email.
āāāāāāā Original Message āāāāāāā
On Saturday, November 3, 2018 9:37 AM, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Rusty, aj, and list,
>
> > > - channel announcements: do you support secp256k1 for hashes or just
> > > sha256?
> > >
> >
> > Worse, it becomes "I support secp256k1 with ECDSA" then a new "I support
> > secp256k1 with Schnorr". You need a continuous path of channels with
> > the same feature.
>
> I believe not? Both the 2p-ECDSA and Schnorr contingent payment schemes effectively encode "I will pay you N satoshi if you give me the private key of the public key P on the secp256k1 curve, before time B", which can be composed with another contingent payment of either 2p-ECDSA or Schnorr. So it would be possible to have a route with channels alternating between the two schemes.
Thinking a little more....
Suppose we are in possession of a zero knowledge proof, with public parameters P (a point on secp256k1) and h (a 256-bit scalar), and private parameter k (a 256-bit scalar). The proof shows (P == k * G) && (h == sha256(k)).
Then suppose Alice wishes to pay Delilah some satoshis in exchange for k. However there is no channel between them. There *is* a route from Alice to Bob to Carol to Delilah. The problem is that Bob is using old software and all channels Bob has use only sha256.
In the onion packet for Carol, Alice can put "the secret preimage k is known by Delilah, with the secp256k1 public key P, here's the proof (P == k * G) && (h == sha256(k))". This lets us make routes that are partially in secp256k1 and partially in sha256.
However I am not enough of a mathematician to know how to generate such a proof.
And as aj points out, whether to use sha256 or secp256k1 can be done on a per-HTLC basis instead of requiring a channel start out with one or both. As long as all nodes on all viable routes understand some secp256k1 protocol,it would be possible to do AMP and decorrelation.
Regards,
ZmnSCPxj
ZmnSCPxj [ARCHIVE] /
npub1g5ā¦3ms3l
2023-06-09 12:52:02
in reply to nevent1qā¦46p0
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lPublished at
2023-06-09 12:52:02Event JSON
{
"id": "0ab6c48d88f82cc0a0f271744908e2dcfe01c0b1a2b4e57dc20ce7aa31cc6668",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686315122,
"kind": 1,
"tags": [
[
"e",
"e7c4f764fcc0b51f5e943dfe8efd409779c7c6f87908c1f1f9f5d90c707fd321",
"",
"root"
],
[
"e",
"d909c8f1b82c412cbb44cefc62dd3579d57770a3a3521c2172e779100f9a82bf",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "š
Original date posted:2018-11-04\nš Original message:\nGood morninh list,\n\n\nSent with ProtonMail Secure Email.\n\nāāāāāāā Original Message āāāāāāā\nOn Saturday, November 3, 2018 9:37 AM, ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e wrote:\n\n\u003e Good morning Rusty, aj, and list,\n\u003e\n\u003e \u003e \u003e - channel announcements: do you support secp256k1 for hashes or just\n\u003e \u003e \u003e sha256?\n\u003e \u003e \u003e\n\u003e \u003e\n\u003e \u003e Worse, it becomes \"I support secp256k1 with ECDSA\" then a new \"I support\n\u003e \u003e secp256k1 with Schnorr\". You need a continuous path of channels with\n\u003e \u003e the same feature.\n\u003e\n\u003e I believe not? Both the 2p-ECDSA and Schnorr contingent payment schemes effectively encode \"I will pay you N satoshi if you give me the private key of the public key P on the secp256k1 curve, before time B\", which can be composed with another contingent payment of either 2p-ECDSA or Schnorr. So it would be possible to have a route with channels alternating between the two schemes.\n\nThinking a little more....\n\nSuppose we are in possession of a zero knowledge proof, with public parameters P (a point on secp256k1) and h (a 256-bit scalar), and private parameter k (a 256-bit scalar). The proof shows (P == k * G) \u0026\u0026 (h == sha256(k)).\n\nThen suppose Alice wishes to pay Delilah some satoshis in exchange for k. However there is no channel between them. There *is* a route from Alice to Bob to Carol to Delilah. The problem is that Bob is using old software and all channels Bob has use only sha256.\n\nIn the onion packet for Carol, Alice can put \"the secret preimage k is known by Delilah, with the secp256k1 public key P, here's the proof (P == k * G) \u0026\u0026 (h == sha256(k))\". This lets us make routes that are partially in secp256k1 and partially in sha256.\n\nHowever I am not enough of a mathematician to know how to generate such a proof.\n\nAnd as aj points out, whether to use sha256 or secp256k1 can be done on a per-HTLC basis instead of requiring a channel start out with one or both. As long as all nodes on all viable routes understand some secp256k1 protocol,it would be possible to do AMP and decorrelation.\n\nRegards,\nZmnSCPxj",
"sig": "8e2de907eb3004b8a8d76054596cc5b058b3830c107a467f8ef1a6198fbc52b73f6aaeafdadf5b39c0165d2674d9f2a1afab50edbdc46ec0073b050de474e8c5"
}