<oembed><type>rich</type><version>1.0</version><author_name>npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l</author_name><author_url>https://nostr.ae/npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2018-11-04&#xA;📝 Original message:&#xA;Good morninh list,&#xA;&#xA;&#xA;Sent with ProtonMail Secure Email.&#xA;&#xA;‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐&#xA;On Saturday, November 3, 2018 9:37 AM, ZmnSCPxj &lt;ZmnSCPxj at protonmail.com&gt; wrote:&#xA;&#xA;&gt; Good morning Rusty, aj, and list,&#xA;&gt;&#xA;&gt; &gt; &gt; -   channel announcements: do you support secp256k1 for hashes or just&#xA;&gt; &gt; &gt;     sha256?&#xA;&gt; &gt; &gt;&#xA;&gt; &gt;&#xA;&gt; &gt; Worse, it becomes &#34;I support secp256k1 with ECDSA&#34; then a new &#34;I support&#xA;&gt; &gt; secp256k1 with Schnorr&#34;. You need a continuous path of channels with&#xA;&gt; &gt; the same feature.&#xA;&gt;&#xA;&gt; I believe not? Both the 2p-ECDSA and Schnorr contingent payment schemes effectively encode &#34;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&#34;, 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.&#xA;&#xA;Thinking a little more....&#xA;&#xA;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) &amp;&amp; (h == sha256(k)).&#xA;&#xA;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.&#xA;&#xA;In the onion packet for Carol, Alice can put &#34;the secret preimage k is known by Delilah, with the secp256k1 public key P, here&#39;s the proof (P == k * G) &amp;&amp; (h == sha256(k))&#34;. This lets us make routes that are partially in secp256k1 and partially in sha256.&#xA;&#xA;However I am not enough of a mathematician to know how to generate such a proof.&#xA;&#xA;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.&#xA;&#xA;Regards,&#xA;ZmnSCPxj</html></oembed>