{"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:2020-04-22\n📝 Original message:\nHello all,\n\nI'd like to give an update on the current state of thinking and coding\nsurrounding replacing Hash-TimeLock Contracts (HTLCs) with Point-TimeLock\nContracts (PTLCs) (aka Payment Hashes -\u003e Payment Points) in hopes of\nsparking interest, discussion, development, etc.\n\n\nWe Want Payment Points!\n-----------------------\n\nUsing point-locks (in PTLCs) instead of hash-locks (in HTLCs) for lightning\npayments is an all around improvement. HTLCs require the use of the same\nhash across payment routes (barring fancy ZKPs which are inferior to PTLCs)\nwhile PTLCs allow for payment de-correlation along routes. For an\nintroduction to the topic, see https://suredbits.com/payment-points-part-1/.\n\nIn addition to improving privacy in this way and protecting against\nwormhole attacks, PTLC-based lightning channels open the door to a large\nvariety of interesting applications that cannot be accomplished with HTLCs:\n\nStuckless (retry-able) Payments with proof of payment (\nhttps://suredbits.com/payment-points-part-2-stuckless-payments/)\n\nEscrow contracts over Lightning (\nhttps://suredbits.com/payment-points-part-3-escrow-contracts/)\n\nHigh/DLOG AMP (\nhttps://docs.google.com/presentation/d/15l4h2_zEY4zXC6n1NqsImcjgA0fovl_lkgkKu1O3QT0/edit#slide=id.g64c15419e7_0_40\n)\n\nStuckless + AMP (an improvement on Boomerang) (\nhttps://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002239.html\n)\n\nPay-for-signature (\nhttps://suredbits.com/payment-points-part-4-selling-signatures/)\n\nPay-for-commitment (\nhttps://lists.linuxfoundation.org/pipermail/lightning-dev/2019-September/002166.html\n)\n\nMonotonic access structures on payment completion (\nhttps://suredbits.com/payment-points-monotone-access-structures/)\n\nIdeal Barrier Escrow Implementation (\nhttps://suredbits.com/payment-points-implementing-barrier-escrows/)\n\nAnd allowing for Barrier Escrows, we can even have\n\nAtomic multi-payment setup (\nhttps://suredbits.com/payment-points-and-barrier-escrows/)\n\nLightning Discreet Log Contract (\nhttps://suredbits.com/discreet-log-contracts-on-lightning-network/)\n\nAtomic multi-payment update (\nhttps://suredbits.com/updating-and-transferring-lightning-payments/)\n\nLightning Discreet Log Contract Novation/Transfer (\nhttps://suredbits.com/transferring-lightning-dlcs/)\n\nThere are likely even more things that can be done with Payment Points so\nmake sure to respond if I've missed any known ones.\n\n\nHow Do We Get Payment Points?\n-----------------------------\n\nEventually, once we have Taproot, we can use 2p-Schnorr adaptor signatures\nin Lightning channels. For a detailed thread by ZmnSCPxj, see here\nhttps://lists.linuxfoundation.org/pipermail/lightning-dev/2019-December/002375.html\n\nIn the meantime, Lloyd has written about a way to do 1p-ECDSA adaptor sigs (\nhttps://github.com/LLFourn/one-time-VES) which can be paired with\nOP_CHECKMULTISIG to allows us to execute PTLCs on Bitcoin today!\n\nNickler has implemented this in a branch of secp256k1 (\nhttps://github.com/jonasnick/secp256k1/pull/14) and I have implemented it\nin Bouncy Castle in Bitcoin-S with some testing against this branch (\nhttps://github.com/nkohen/bitcoin-s-core/tree/bouncy-adaptor). Do note that\nas nickler states on his PR, \"IT IS EXTREMELY DANGEROUS AND RECKLESS TO USE\nTHIS MODULE IN PRODUCTION. DON'T!\"\n\nA demo of an on-chain PTLC I executed using nickler's implementation on the\nbackend + bitcoin-s can be seen here https://youtu.be/w9o4v7Idjno\n\nAnd waxwing did a lovely write-up about the crypto itself\nhttps://joinmarket.me/blog/blog/schnorrless-scriptless-scripts/\n\nI would be very interested in having a fork of (at least) one lightning\nimplementation (or Rust Lightning) to be a proof of concept ECDSA-PTLC node\nwith which we can test and play with the plethora of PTLC-based proposals\nabove.\n\nI believe this would only require a few changes to existing nodes:\n\n1) update_add_ptlc will have a 32 byte x-coordinate (of a point) rather\nthan a 32 byte hash. Additionally the onion's hop_data will contain a 32\nbyte scalar tweak for each hop. As per [link multi-hop locks]. The last\nhop_data will instead include a 32 byte scalar equal to the sum of all\ntweaks.\n\n2) commitment_signed will have 162 byte adaptor ptlc_signatures rather than\nvalid (71/72 byte) ECDSA signatures on PTLC-success transactions.\n\n3) The in-flight outputs on the commitment transaction itself become a\nlittle simpler as we no longer need to explicitly check the payment\npre-image against a hash. Instead, delete all instances of \"OP_HASH160\n\u003cRIPEMD160(payment_hash)\u003e OP_EQUALVERIFY\" in the scripts (leaving the rest\nthe same) and require no pre-image in the witness, only a valid signature.\nThe pre-image check is implicitly enforced by the \u003cremoteptlc_sig\u003e witness\nsince only an adaptor signature was provided by remote so that the payment\npre-image is required to create the valid signature (from which the\npre-image can be then deduced by comparing adaptor and valid signatures).\n\nIf I've missed any other changes that need to happen, do respond with them!\n\nI hope that as a community we can work towards having a PTLC-based\nLightning Network that is safe and stable as soon as possible, and so I\nencourage further thinking, development and expirementation with PTLCs now\nso that when Taproot is finally at our disposal we can cleanly start moving\ntowards a more ideal Lightning :)\n\nBest,\nNadav\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200422/a0197f12/attachment.html\u003e"}