{"type":"rich","version":"1.0","title":"Nadav Kohen [ARCHIVE] wrote","author_name":"Nadav Kohen [ARCHIVE] (npub1ge…rtua0)","author_url":"https://yabu.me/npub1geqdlge6ysz9qlq3w758422flnkgqklpu9veu80ehjprcd04ugyqkrtua0","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2019-10-09\n📝 Original message:\nHi list,\n\nI'm back again with another idea about Payment Points and fun things to do\nwith them! Hopefully this time I'm not entirely just hashing out old ideas\nin public like an out-of-the-loop person :)\n\n*TLDR: Adding and ECDH-ing points gives us AND and OR functionality which\nwe can compose to make cool lightning contracts like Multisig, Escrow, and\nDLCs*\n\nSo when looking at the following (likely incomplete) list of things you can\ndo with payment points:\n\n1) Payment De-correlation\n2) \"Stuckless\" Payments\n3) High AMP\n4) Selling Signatures\n5) Selling Pedersen De-commitment\n6) Escrow Contracts\n\nI started of trying to classify what kind of thing these new features are\nin hopes of coming across new ones. The first three I clumped into a group\nI called \"Payment point addition allows us to do cool things while\nmaintaining the Proof of Payment (PoP) property\". The next two (4 and 5) I\ncalled \"Commitment applications where point is public\". But ZmnSCPxj's\nproposal for lightning escrow contracts (\nhttps://lists.linuxfoundation.org/pipermail/lightning-dev/2019-June/002028.html)\nstruck me as something different that might somehow be made more general.\n\nEssentially the idea is to use the point S + ECDH(B, E) where S is the\nseller's point, B is the buyer's point and E is the escrow's point. This\nmeans that the scalar can be discovered by the seller in collaboration with\nthe buyer or the escrow, that is, S AND (B OR E). I propose that under\ncertain circumstances (such as the parties involved being able to\ninteract), this can be generalized to have payments conditioned on\narbitrary AND/OR circuits.\n\n I believe that AND is very straightforward as you simply take two\nconditions A and B and add them together to get a point that requires both\nof their scalars are discoverable (except maybe under certain bad\ncircumstances that can be avoided where like B = C - A, this must be\nguarded against).\n\nOR is harder but I think that it can be achieved in the two party case by\nECDH and in the n-party case by multi-party key exchanges (which I know\npretty much nothing about other than that they exist). Given some key\nexchange protocol (preferably non-interactive), KE, KE(A_1, ..., A_n)\nshould result in a number known only to those who know any scalar a_1, ...,\na_n and no one else. Assuming this exists and we can manage to trustlessly\n(in some possibly stretched sense of the word) compute shared keys\n(including such things as KE(A+B, C)), then KE(A, B) acts as A OR B in our\npayment condition contract.\n\nTo restate the escrow contract idea in this setting, the payment is\nconditioned on S + KE(B, E). Important to note is that not all parties must\nknow about the details of the payment itself: the Escrow in this example\nknows nothing about this payment (other than that some payment exists)\nunless there is a dispute.\n\nLastly, note that contracts following this scheme look indistinguishable to\nnormal payments on the network, and are fully compatible with High AMPs\nsince we can simply take the payment point specified by our contract and\nadd that point to each partial payment point.\n\nWell this is all nice in theory, but is there anything that will actually\ncome out of this thinking? I'll detail the two things I've thought of so\nfar for which I'd love critique! I'd also love to hear if anyone else\nthings of any cool application using this line of thought (or really\nanything cool with payment points :P).\n\nIdea 1: \"MultiSignature\" Lightning Contracts\nI mean \"MultiSignature\" here only in the sense that m-of-n parties must\nagree to the payment in order for it to happen, no actual signatures are\nused. A \"MultiSignature\" contract is simply a bunch of ANDs and ORs! For\nexample a 2-of-3 multisig between parties A, B, and C can be represented as\n(A AND B) OR (B AND C) OR (C AND A). As such, if some seller has a point S\nand three parties have points A, B, and C where a certain payment must go\nthrough if any two of them think it should, then the payment point used for\nthe payment should be S + KE(A + B, B + C, C + A). We add S to this point\nso that the scalar, s, can act as proof of payment. And that's it! I\nhaven't thought long enough to come up with any situation where this might\nbe useful but hoping someone who reads this will!\n\nIdea 2: DLCs Routed over Lightning\nSay that some DLC oracle will either broadcast s_A or s_B whose public\npoints are S_A and S_B (which can be computed from public information as\nper the DLC scheme). Then say that Alice and Bob enter into a contract\nunder which Alice wins some amount if s_A is broadcasted and Bob if s_B is\nbroadcasted. Say Alice has a point A and Bob has a point B. They each send\nthe other a payment with the amount that party must receive if they win\nwith the payment point A + S_A for Bob's payment to Alice and B + S_B for\nAlice's payment to Bob. And this is it! If s_A is broadcasted then Alice\ngets paid (and Bob gets proof of payment a, which is the scalar to A),\notherwise s_B is broadcasted and Bob gets paid (with Alice receiving b as\nPoP). An interesting note is that under this scheme neither party is forced\nto pay extra on-chain fees in the case of a counter-party who doesn't\ncooperate whilst in the wrong.\nOne wrinkle with this scheme is that setup isn't trustless. Although it is\ngenerally true that one party must sign the funding transaction for a DLC\nbefore the other party for on-chain DLCs, at least there is the mitigation\nthat when your counter-party goes silent, you can move your input funds\ninvalidating the funding transaction you signed (at a cost because fees).\nSo what can we do here to ensure that both payments are setup at the same\ntime in the case that Alice and Bob don't trust each other?\nSay that although they don't trust each other, they're both willing to\ntrust some escrow entity who generates some point E for their payment.\nAlice's payment point to Bob becomes B + S_B + E and Bob's to Alice becomes\nA + S_A + E. The escrow now waits to hear from Alice and Bob that they have\nincoming payments setup and only once both of them attest to this (using\nsignatures, for example) does the escrow release the scalar to E to them\nboth. The escrow can also have a timeout at which it will never reveal the\nscalar to E: forcing both parties to commit to the contract well before the\nDLC event. In this way, trust has been moved from counter-party to\ntrustworthy (hopefully) escrow in such a way that the Escrow learns nothing\nabout the contract itself (other than that there is one of some kind).\nI believe that this scheme can be extended to more events through the use\nof multiple payments being setup (usually in both directions) but this\nseems complicated and I've rambled for long enough. One last note is that\nDLC oracles can be composed in the usual way under this scheme (by\naddition) and potentially even threshold multi-oracles can be supported in\nthis way, although this would require the oracles to attest to some shared\nkey's points with other oracles which isn't necessarily optimal.\n\nBest,\nNadav\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191009/630cee2b/attachment.html\u003e"}