{"type":"rich","version":"1.0","author_name":"npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4","author_url":"https://nostr.ae/npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2018-05-07\n📝 Original message:\nActually, just thought about this a bit more and I think it's possible to\ndeploy this in unison with (or after) any sort of SS based on schnorr\nbecomes\npossible in Bitcoin. My observation is that since both techniques are based\non\nthe same underlying technique (revealing a secret value in a signature) and\nthey center around leveraging the onion payload to drop off a payment point\n(G*a, or G*a_1*a_2*a_3, etc), then the disclosure within the _links_ can be\nheterogeneous, as the same secret is still revealed in an end-to-end matter.\n\nAs an illustration, consider: A \u003c-\u003e B \u003c-\u003e C. The A \u003c-\u003e B link could use the\n2pc\npailier technique, while the B \u003c-\u003e C link could use the OG SS technique\nbased\non schnorr. If i'm correct, then this would mean that we can deploy both\ntechniques, without worrying about fragmenting the network due to the\nexistence\nof two similar but incompatible e2e payment routing schemes!\n\n-- Laolu\n\n\nOn Mon, May 7, 2018 at 4:57 PM Olaoluwa Osuntokun \u003claolu32 at gmail.com\u003e wrote:\n\n\u003e Hi Pedro,\n\u003e\n\u003e Very cool stuff! When I originally discovered the Lindell's technique, my\n\u003e immediate thought was the we could phase this in as a way to _immediately_\n\u003e (no\n\u003e additional Script upgrades required), replace the regular 2-of-2 mulit-sig\n\u003e with\n\u003e a single p2wkh. The immediate advantages of this would: be lower fees for\n\u003e opening/closing channels (as the public key script, and witness are\n\u003e smaller),\n\u003e openings and cooperative close transactions would blend in with the\n\u003e anonymity\n\u003e set of regular p2wkh transactions, and finally the htlc timeout+success\n\u003e transactions can be made smaller as we can remove the multi-sig. The second\n\u003e benefit is nerfed a bit if the channel are advertised, but non-advertised\n\u003e channels would be able to take advantage of this \"stealth\" feature.\n\u003e\n\u003e The upside of the original application I hand in mind is that it wouldn't\n\u003e require any end-to-end changes, as it would only be a link level change\n\u003e (diff\n\u003e output for the funding transaction). If we wanted to allow these styles of\n\u003e channels to be used outside of non-advertised channels, then we would need\n\u003e to\n\u003e update the way channels are verified in the gossip layer.\n\u003e\n\u003e Applying this to the realm of allowing us to use randomized payment\n\u003e identifiers\n\u003e across the route is obviously much, much doper. So then the question would\n\u003e be\n\u003e what the process of integrating the scheme into the existing protocol would\n\u003e look like. The primary thing we'd need to account for is the additional\n\u003e cryptographic overhead this scheme would add if integrated. Re-reviewing\n\u003e the\n\u003e paper, there's an initial setup and verification phase (which was omitted\n\u003e from\n\u003e y'alls note for brevity) where both parties need to complete before the\n\u003e actually signing process can take place. Ideally, we can piggy-back this\n\u003e setup\n\u003e on top of the existing accept_channel/open_channel dance both sides need\n\u003e to go\n\u003e through in order to advance the channel negotiation process today.\n\u003e\n\u003e Conner actually started to implement this when we first discovered the\n\u003e scheme,\n\u003e so we have a pretty good feel w.r.t the implementation of the initial set\n\u003e of\n\u003e proofs. The three proofs required for the set up phase are:\n\u003e\n\u003e   1. A proof that that the Paillier public key is well formed. In the paper\n\u003e   they only execute this step for the party that wishes to _obtain_ the\n\u003e   signature. In our case, since we'll need to sign for HTLCs in both\n\u003e   directions, but parties will need to execute this step.\n\u003e\n\u003e   2. A dlog proof for the signing keys themselves. We already do this more\n\u003e or\n\u003e   less, as if the remote party isn't able to sign with their target key,\n\u003e then\n\u003e   we won't be able to update the channel, or even create a valid\n\u003e commitment in\n\u003e   the first place.\n\u003e\n\u003e   3. A proof that value encrypted (the Paillier ciphertext) is actually the\n\u003e   dlog of the public key to be used for signing. (as an aside this is the\n\u003e part\n\u003e   of the protocol that made me do a double take when first reading it:\n\u003e using one\n\u003e   cryptosystem to encrypt the private key of another cryptosystem in order\n\u003e to\n\u003e   construct a 2pc to allow signing in the latter cryptosystem! soo clever!)\n\u003e\n\u003e First, we'll examine the initial proof. This only needs to be done once by\n\u003e both\n\u003e parties AFAICT. As a result, we may be able to piggyback this onto the\n\u003e initial\n\u003e channel funding steps. Reviewing the paper cited on the Lindell paper [1],\n\u003e it\n\u003e appears this would take 1 RTT, so this shouldn't result in any additional\n\u003e round\n\u003e trips during the funding process. We should be able to use a Paillier\n\u003e modulos\n\u003e of 2048 bits, so nothing too crazy. This would just result in a slightly\n\u003e bigger\n\u003e opening message.\n\u003e\n\u003e Skipping the second proofs as it's pretty standard.\n\u003e\n\u003e The third proof as described (Section 6 of the Lindell paper) is\n\u003e interactive.\n\u003e It also contains a ZK range proof as a sub-protocol which as described in\n\u003e Appendix A is also interactive. However, it was pointed out to us by Omer\n\u003e Shlomovits on the lnd slack, that we can actually replace their custom\n\u003e range\n\u003e proofs with Bulletproofs. This would make this section non-interactive,\n\u003e allowing the proof itself to take 1.5 RTT AFAICT. Additionally, this would\n\u003e only\n\u003e need to be done once at the start, as AFIACT, we can re-use the encryption\n\u003e of\n\u003e the secp256k1 private key of both parties.\n\u003e\n\u003e The current channel opening process requires 2 RTT, so it seems that we'd\n\u003e be\n\u003e able to easily piggy back all the opening proofs on top of the existing\n\u003e funding\n\u003e protocol. The main cost would be the increased size of these opening\n\u003e messages,\n\u003e and also the additional computational cost of operations within the\n\u003e Paillier\n\u003e modulus and the new range proof.\n\u003e\n\u003e The additional components that would need to be modified are the process of\n\u003e adding+settling an HTLC, and also the onion payload that drops off the\n\u003e point\n\u003e whose dlog is r_1*alpha. Within the current protocol, adding and settling\n\u003e an\n\u003e HTLC are more or less non-interactive, we have a single message for each,\n\u003e which\n\u003e is then staged to be committed in new commitments for both parties. With\n\u003e this\n\u003e new scheme (if I follow it correctly), adding an HTLC now requires N RTT:\n\u003e   1. Alice sends A = G*alpha to Bob. Here alpha is the payment secret.\n\u003e   2. Bob sends R_3 = (G*alpha)*r_2 (along w/ a proof of knowledge of r_2\n\u003e and\n\u003e   relation to A)\n\u003e   3. Alice sends R_3' = (G*alpha)*r_3 (along with a similar proof as\n\u003e above) 4.\n\u003e   Bob then computes c3 (the encrypted partial sig which when completed will\n\u003e   reveal a) to Alice.\n\u003e   5. Alice decrypts c3 to get the plaintext partial sig (s'), then\n\u003e finalizes\n\u003e   the set up by sending s'' to Bob.\n\u003e\n\u003e This process takes 2.5 RTT, and would require re-working the state machine\n\u003e slightly to only actually commit an HTLC after step 5 has been completed.\n\u003e When\n\u003e Bob obtains a from the next party in the path, we Alice can then then over\n\u003e the\n\u003e signature, from which Alice can extract alpha. So adding HTLCs is now a bit\n\u003e more interactive, but settling them is the same a before.\n\u003e\n\u003e Finally, the onion payload would need to be re-interpreted in order to\n\u003e encode\n\u003e G*alpha which takes 33 bytes. We can shave this down to 32 by selecting\n\u003e the x\n\u003e coordinate (at the sender) to always be either even or odd. Currently, we\n\u003e have\n\u003e 12 unused bytes in the onion payload. The HMAC is currently 32 bytes. One\n\u003e path\n\u003e would be to allocate a portion of HMAC space to encoding this point. A\n\u003e 16-byte\n\u003e HMAC would probably have been enough in the beginning, so we can drop down\n\u003e to\n\u003e that. However, that still leaves 4 bytes somewhere that has to give...one\n\u003e could\n\u003e either obtain these extra bytes from the CLTV and Amount fields, or just\n\u003e have\n\u003e each hop consume an extra payload. The latter path would mean that the new\n\u003e upper hop limit is actually 10.\n\u003e\n\u003e However, given that we would need need a new global feature bit in order to\n\u003e roll this out, it may make sense to re-work the onion format all together\n\u003e which\n\u003e would mean that we wouldn't need to hack the old format a bit to\n\u003e accommodate\n\u003e this additional data. One aspect of introducing a new end-to-end contract\n\u003e type\n\u003e which I hadn't considered before is that each new type effectively\n\u003e partitions\n\u003e the network. This is due to the fact that these HTLCs will now only be\n\u003e able to\n\u003e be carried along paths that understand this new feature. As a result,\n\u003e plausible\n\u003e path diversity takes as we can no longer utilize all channels on the\n\u003e network\n\u003e for routing. This would suggest that introducing new end to end contract\n\u003e types\n\u003e (if one wishes to use them widely across arbitrary channels and not for\n\u003e specific contract protocols) may be a strong point of synchronization w.r.t\n\u003e updates across the network. As a result, we may need to be a bit more\n\u003e discerning w.r.t new candidates for e2e contracts given the coordination\n\u003e costs.\n\u003e\n\u003e So the takeaways are:\n\u003e   * we can probably piggy back the extra proofs onto the channel opening\n\u003e     process\n\u003e       * one of the subproofs can use bulletproofs to make the proof\n\u003e shorter and\n\u003e         also non-interactive\n\u003e   * adding an HTLC would take 2.5 RTT's, but settling is just as quick as\n\u003e     before\n\u003e   * the onion payload would either need to be hacked, or extended to\n\u003e support\n\u003e     packaging the point.\n\u003e   * the utility of the scheme won't shine until all/most of the network\n\u003e uses it\n\u003e   * we could start w/ just the introduction of the OG 2PC scheme as a\n\u003e multi-sig\n\u003e     replacement\n\u003e\n\u003e\n\u003e [1]: https://eprint.iacr.org/2011/494.pdf (section 3.3)\n\u003e\n\u003e -- Laolu\n\u003e\n\u003e\n\u003e On Fri, Apr 27, 2018 at 11:42 AM Pedro Moreno Sanchez \u003cpmorenos at purdue.edu\u003e\n\u003e wrote:\n\u003e\n\u003e\u003e Hello guys,\n\u003e\u003e\n\u003e\u003e as some of you already know, I am working on some cryptographic\n\u003e\u003e constructions that might be of interest and useful for the Lightning\n\u003e\u003e Network.\n\u003e\u003e\n\u003e\u003e Recently, I have come up with a scriptless version of the adaptor\n\u003e\u003e signatures and the contract required in the Lighting Network using only\n\u003e\u003e 2-party ECDSA signatures. The main advantage is that, instead of waiting\n\u003e\u003e for Schnorr signatures to be deployed in Bitcoin so that Poelstra's\n\u003e\u003e scriptless scripts can be used, I believe that this ECDSA-version of the\n\u003e\u003e scriptless scripts can be directly applied today.\n\u003e\u003e\n\u003e\u003e Details are in the attached PDF. I am looking forward to hearing your\n\u003e\u003e comments and suggestions.\n\u003e\u003e\n\u003e\u003e Cheers,\n\u003e\u003e Pedro.\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e Lightning-dev mailing list\n\u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180508/04e449be/attachment-0001.html\u003e"}