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