ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-04 📝 Original message: Good morninh list, Sent ...
📅 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
📝 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