{"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:\nHi Pedro,\n\nVery cool stuff! When I originally discovered the Lindell's technique, my\nimmediate thought was the we could phase this in as a way to _immediately_\n(no\nadditional Script upgrades required), replace the regular 2-of-2 mulit-sig\nwith\na single p2wkh. The immediate advantages of this would: be lower fees for\nopening/closing channels (as the public key script, and witness are\nsmaller),\nopenings and cooperative close transactions would blend in with the\nanonymity\nset of regular p2wkh transactions, and finally the htlc timeout+success\ntransactions can be made smaller as we can remove the multi-sig. The second\nbenefit is nerfed a bit if the channel are advertised, but non-advertised\nchannels would be able to take advantage of this \"stealth\" feature.\n\nThe upside of the original application I hand in mind is that it wouldn't\nrequire any end-to-end changes, as it would only be a link level change\n(diff\noutput for the funding transaction). If we wanted to allow these styles of\nchannels to be used outside of non-advertised channels, then we would need\nto\nupdate the way channels are verified in the gossip layer.\n\nApplying this to the realm of allowing us to use randomized payment\nidentifiers\nacross the route is obviously much, much doper. So then the question would\nbe\nwhat the process of integrating the scheme into the existing protocol would\nlook like. The primary thing we'd need to account for is the additional\ncryptographic overhead this scheme would add if integrated. Re-reviewing the\npaper, there's an initial setup and verification phase (which was omitted\nfrom\ny'alls note for brevity) where both parties need to complete before the\nactually signing process can take place. Ideally, we can piggy-back this\nsetup\non top of the existing accept_channel/open_channel dance both sides need to\ngo\nthrough in order to advance the channel negotiation process today.\n\nConner actually started to implement this when we first discovered the\nscheme,\nso we have a pretty good feel w.r.t the implementation of the initial set of\nproofs. The three proofs required for the set up phase are:\n\n  1. A proof that that the Paillier public key is well formed. In the paper\n  they only execute this step for the party that wishes to _obtain_ the\n  signature. In our case, since we'll need to sign for HTLCs in both\n  directions, but parties will need to execute this step.\n\n  2. A dlog proof for the signing keys themselves. We already do this more\nor\n  less, as if the remote party isn't able to sign with their target key,\nthen\n  we won't be able to update the channel, or even create a valid commitment\nin\n  the first place.\n\n  3. A proof that value encrypted (the Paillier ciphertext) is actually the\n  dlog of the public key to be used for signing. (as an aside this is the\npart\n  of the protocol that made me do a double take when first reading it:\nusing one\n  cryptosystem to encrypt the private key of another cryptosystem in order\nto\n  construct a 2pc to allow signing in the latter cryptosystem! soo clever!)\n\nFirst, we'll examine the initial proof. This only needs to be done once by\nboth\nparties AFAICT. As a result, we may be able to piggyback this onto the\ninitial\nchannel funding steps. Reviewing the paper cited on the Lindell paper [1],\nit\nappears this would take 1 RTT, so this shouldn't result in any additional\nround\ntrips during the funding process. We should be able to use a Paillier\nmodulos\nof 2048 bits, so nothing too crazy. This would just result in a slightly\nbigger\nopening message.\n\nSkipping the second proofs as it's pretty standard.\n\nThe third proof as described (Section 6 of the Lindell paper) is\ninteractive.\nIt also contains a ZK range proof as a sub-protocol which as described in\nAppendix A is also interactive. However, it was pointed out to us by Omer\nShlomovits on the lnd slack, that we can actually replace their custom range\nproofs with Bulletproofs. This would make this section non-interactive,\nallowing the proof itself to take 1.5 RTT AFAICT. Additionally, this would\nonly\nneed to be done once at the start, as AFIACT, we can re-use the encryption\nof\nthe secp256k1 private key of both parties.\n\nThe current channel opening process requires 2 RTT, so it seems that we'd be\nable to easily piggy back all the opening proofs on top of the existing\nfunding\nprotocol. The main cost would be the increased size of these opening\nmessages,\nand also the additional computational cost of operations within the Paillier\nmodulus and the new range proof.\n\nThe additional components that would need to be modified are the process of\nadding+settling an HTLC, and also the onion payload that drops off the point\nwhose dlog is r_1*alpha. Within the current protocol, adding and settling an\nHTLC are more or less non-interactive, we have a single message for each,\nwhich\nis then staged to be committed in new commitments for both parties. With\nthis\nnew scheme (if I follow it correctly), adding an HTLC now requires N RTT:\n  1. Alice sends A = G*alpha to Bob. Here alpha is the payment secret.\n  2. Bob sends R_3 = (G*alpha)*r_2 (along w/ a proof of knowledge of r_2 and\n  relation to A)\n  3. Alice sends R_3' = (G*alpha)*r_3 (along with a similar proof as above)\n4.\n  Bob then computes c3 (the encrypted partial sig which when completed will\n  reveal a) to Alice.\n  5. Alice decrypts c3 to get the plaintext partial sig (s'), then finalizes\n  the set up by sending s'' to Bob.\n\nThis process takes 2.5 RTT, and would require re-working the state machine\nslightly to only actually commit an HTLC after step 5 has been completed.\nWhen\nBob obtains a from the next party in the path, we Alice can then then over\nthe\nsignature, from which Alice can extract alpha. So adding HTLCs is now a bit\nmore interactive, but settling them is the same a before.\n\nFinally, the onion payload would need to be re-interpreted in order to\nencode\nG*alpha which takes 33 bytes. We can shave this down to 32 by selecting the\nx\ncoordinate (at the sender) to always be either even or odd. Currently, we\nhave\n12 unused bytes in the onion payload. The HMAC is currently 32 bytes. One\npath\nwould be to allocate a portion of HMAC space to encoding this point. A\n16-byte\nHMAC would probably have been enough in the beginning, so we can drop down\nto\nthat. However, that still leaves 4 bytes somewhere that has to give...one\ncould\neither obtain these extra bytes from the CLTV and Amount fields, or just\nhave\neach hop consume an extra payload. The latter path would mean that the new\nupper hop limit is actually 10.\n\nHowever, given that we would need need a new global feature bit in order to\nroll this out, it may make sense to re-work the onion format all together\nwhich\nwould mean that we wouldn't need to hack the old format a bit to accommodate\nthis additional data. One aspect of introducing a new end-to-end contract\ntype\nwhich I hadn't considered before is that each new type effectively\npartitions\nthe network. This is due to the fact that these HTLCs will now only be able\nto\nbe carried along paths that understand this new feature. As a result,\nplausible\npath diversity takes as we can no longer utilize all channels on the network\nfor routing. This would suggest that introducing new end to end contract\ntypes\n(if one wishes to use them widely across arbitrary channels and not for\nspecific contract protocols) may be a strong point of synchronization w.r.t\nupdates across the network. As a result, we may need to be a bit more\ndiscerning w.r.t new candidates for e2e contracts given the coordination\ncosts.\n\nSo the takeaways are:\n  * we can probably piggy back the extra proofs onto the channel opening\n    process\n      * one of the subproofs can use bulletproofs to make the proof shorter\nand\n        also non-interactive\n  * adding an HTLC would take 2.5 RTT's, but settling is just as quick as\n    before\n  * the onion payload would either need to be hacked, or extended to support\n    packaging the point.\n  * the utility of the scheme won't shine until all/most of the network\nuses it\n  * we could start w/ just the introduction of the OG 2PC scheme as a\nmulti-sig\n    replacement\n\n\n[1]: https://eprint.iacr.org/2011/494.pdf (section 3.3)\n\n-- Laolu\n\n\nOn Fri, Apr 27, 2018 at 11:42 AM Pedro Moreno Sanchez \u003cpmorenos at purdue.edu\u003e\nwrote:\n\n\u003e Hello guys,\n\u003e\n\u003e as some of you already know, I am working on some cryptographic\n\u003e constructions that might be of interest and useful for the Lightning\n\u003e Network.\n\u003e\n\u003e Recently, I have come up with a scriptless version of the adaptor\n\u003e signatures and the contract required in the Lighting Network using only\n\u003e 2-party ECDSA signatures. The main advantage is that, instead of waiting\n\u003e for Schnorr signatures to be deployed in Bitcoin so that Poelstra's\n\u003e scriptless scripts can be used, I believe that this ECDSA-version of the\n\u003e scriptless scripts can be directly applied today.\n\u003e\n\u003e Details are in the attached PDF. I am looking forward to hearing your\n\u003e comments and suggestions.\n\u003e\n\u003e Cheers,\n\u003e Pedro.\n\u003e\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180507/32b51086/attachment-0001.html\u003e"}