{"type":"rich","version":"1.0","title":"Olaoluwa Osuntokun [ARCHIVE] wrote","author_name":"Olaoluwa Osuntokun [ARCHIVE] (npub19h…zkvn4)","author_url":"https://yabu.me/npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2020-04-23\n📝 Original message:\n(this may be kind of off-topic, more about DLC deployment than PTLCs\nthemselves)\n\n\u003eFrom my PoV, new technologies aren't what has held back DLC deployment to\nthis date since the paper was originally released. Tadge has had working\ncode than can be deployed today for some time now, and other parties like\nDG-Lab have created full-fledge demos with the system working end to end.\nInstead, the real impediment has been the bootstrapping of the oracles\nwhich the scheme critically depends upon.\n\nWithout oracles, none of it really works. Although, it's also the case that\nthere're measures to prevent the oracles from equivocating (reporting two\nconflicting prices/events for a particular instance), bootstrapping a new\noracle still requires a very high degree of trust as they can lie or report\nincorrect data. As a result, actually deploying an oracle for a system like\nthis is tricky business, as it's a trusted centralized entity, so it will\nrun into all the normal meatspace/legal/operational risk that any trusted\ncentralized service would encounter.\n\nEarlier today, Coinbase announced that they were releasing a new price\noracle for the ETH ecosystem [1]. This caught my attention as one can\nimagine, that it would be even simpler for them to deploy a DLC oracle which\nexports an API to obtain signed prices/events. As an existing large company\nin the space (depending on who you talk to), they're a trusted entity, which\nhas earned a good reputation over the years (solving this\nbootstrapping/trust issue). If they do eventually grow the service to also\nencompass this use case, then it enables a number of possibilities, as\nthere's still a ton of value in just base DLC-specific channels (or one off\ncontracts), without all the fancy barrier escrow scriptless scipts swappy\nswap swap stuff.\n\n-- Laolu\n\n[1]:\nhttps://blog.coinbase.com/introducing-the-coinbase-price-oracle-6d1ee22c7068\n\n\nOn Thu, Apr 23, 2020 at 7:52 AM Nadav Kohen \u003cnadav at suredbits.com\u003e wrote:\n\n\u003e Hi Laolu,\n\u003e\n\u003e Thanks for the response :)\n\u003e\n\u003e I agree that some more framing probably would have been good to have in my\n\u003e update.\n\u003e\n\u003e First, I want to clarify that my intention is not to implement a\n\u003e PTLC-based lightning network on top of ECDSA adaptor signatures, as I do\n\u003e believe that using Schnorr will be superior, but rather I wish to get some\n\u003e PoC sandbox with which to start implementing and testing out the long list\n\u003e of currently theoretical proposals surrounding PTLCs, most of which are\n\u003e implementation agnostic (to a degree anyway). I think it would be super\n\u003e beneficial to have more fleshed out with respect to what some challenges of\n\u003e a Payment Point LN are going to be than we understand now, before Schnorr\n\u003e is implemented and it is time to commit to some PTLC scheme for real.\n\u003e\n\u003e Second, I agree that I've probably understated somewhat the changes that\n\u003e will be needed in most implementations as I was mostly thinking about what\n\u003e would need to change in the BOLTs, which does actually seem relatively\n\u003e minimal (although as you mention, these minimal changes to the BOLTs do\n\u003e trigger large changes in many implementations). Also, good point on how\n\u003e BOLT 11 (invoicing) will have to be altered as well, must've slipped my\n\u003e mind.\n\u003e\n\u003e Best,\n\u003e Nadav\n\u003e\n\u003e On Wed, Apr 22, 2020 at 8:17 PM Olaoluwa Osuntokun \u003claolu32 at gmail.com\u003e\n\u003e wrote:\n\u003e\n\u003e\u003e Hi Nadav,\n\u003e\u003e\n\u003e\u003e Thanks for the updates! Super cool to see this concept continue to evolve\n\u003e\u003e and integrate new technologies as they pop up.\n\u003e\u003e\n\u003e\u003e \u003e I believe this would only require a few changes to existing nodes:\n\u003e\u003e\n\u003e\u003e Rather than a \"few changes\", this would to date be the largest\n\u003e\u003e network-level\n\u003e\u003e update undertaken to the Lightning Network thus far. In the past, we\n\u003e\u003e rolled\n\u003e\u003e out the new onion blob format (which enables changes like this), but none\n\u003e\u003e of\n\u003e\u003e the intermediate nodes actually need to modify their behavior. New payment\n\u003e\u003e types like MPP+AMP only needed the _end points_ to update making this an\n\u003e\u003e end-to-end update that has been rolled out so far in a de-synchronized\n\u003e\u003e manner.\n\u003e\u003e\n\u003e\u003e Re-phrasing deploying this requires changes to: the core channel state\n\u003e\u003e machine (the protocol we use to make commitment updates), HTLC scripts,\n\u003e\u003e on-chain HTLC handling and resolution, path finding algorithms (to only\n\u003e\u003e see\n\u003e\u003e out the new PTLC-enabled nodes), invoice changes and onion blob\n\u003e\u003e processing.\n\u003e\u003e I'd caution against underestimating how long all of this will take in\n\u003e\u003e practice, and the degree of synchronization required to pull it all off\n\u003e\u003e properly.\n\u003e\u003e\n\u003e\u003e For a few years now the question we've all been pondering is: do we wait\n\u003e\u003e for\n\u003e\u003e scnhorr to roll out multi-hop locks, or just use the latest ECDSA based\n\u003e\u003e technique? As dual deployment is compatible (we can make the onion blobs\n\u003e\u003e for\n\u003e\u003e both types the same), a path has always existed to first roll out with the\n\u003e\u003e latest ECDSA based technique then follow up later to roll out the schnorr\n\u003e\u003e version as well. However there's also a risk here as depending on how\n\u003e\u003e quickly things can be rolled out, schnorr may become available\n\u003e\u003e mid-development, which would possibly cause us to reconsider the ECDSA\n\u003e\u003e path\n\u003e\u003e and have the network purely use scnhorr to make things nice and uniform.\n\u003e\u003e\n\u003e\u003e Zooming out for a bit, the solution space of \"how channels can look post\n\u003e\u003e scriptless-scripts + taproot\" is rather large [1], and the addition of\n\u003e\u003e this\n\u003e\u003e new technique allows for an even larger set of deployment possibilities.\n\u003e\u003e This latest ECDSA variant is much simpler than the prior ones (which had a\n\u003e\u003e few rounds of more involved ZKPs), but since it still uses OP_CMS, it\n\u003e\u003e can't\n\u003e\u003e be used to modify the funding output.\n\u003e\u003e\n\u003e\u003e [1]:\n\u003e\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-December/002375.html\n\u003e\u003e\n\u003e\u003e -- Laolu\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e On Wed, Apr 22, 2020 at 8:13 AM Nadav Kohen \u003cnadav at suredbits.com\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e Hello all,\n\u003e\u003e\u003e\n\u003e\u003e\u003e I'd like to give an update on the current state of thinking and coding\n\u003e\u003e\u003e surrounding replacing Hash-TimeLock Contracts (HTLCs) with Point-TimeLock\n\u003e\u003e\u003e Contracts (PTLCs) (aka Payment Hashes -\u003e Payment Points) in hopes of\n\u003e\u003e\u003e sparking interest, discussion, development, etc.\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e We Want Payment Points!\n\u003e\u003e\u003e -----------------------\n\u003e\u003e\u003e\n\u003e\u003e\u003e Using point-locks (in PTLCs) instead of hash-locks (in HTLCs) for\n\u003e\u003e\u003e lightning payments is an all around improvement. HTLCs require the use of\n\u003e\u003e\u003e the same hash across payment routes (barring fancy ZKPs which are inferior\n\u003e\u003e\u003e to PTLCs) while PTLCs allow for payment de-correlation along routes. For an\n\u003e\u003e\u003e introduction to the topic, see\n\u003e\u003e\u003e https://suredbits.com/payment-points-part-1/.\n\u003e\u003e\u003e\n\u003e\u003e\u003e In addition to improving privacy in this way and protecting against\n\u003e\u003e\u003e wormhole attacks, PTLC-based lightning channels open the door to a large\n\u003e\u003e\u003e variety of interesting applications that cannot be accomplished with HTLCs:\n\u003e\u003e\u003e\n\u003e\u003e\u003e Stuckless (retry-able) Payments with proof of payment (\n\u003e\u003e\u003e https://suredbits.com/payment-points-part-2-stuckless-payments/)\n\u003e\u003e\u003e\n\u003e\u003e\u003e Escrow contracts over Lightning (\n\u003e\u003e\u003e https://suredbits.com/payment-points-part-3-escrow-contracts/)\n\u003e\u003e\u003e\n\u003e\u003e\u003e High/DLOG AMP (\n\u003e\u003e\u003e https://docs.google.com/presentation/d/15l4h2_zEY4zXC6n1NqsImcjgA0fovl_lkgkKu1O3QT0/edit#slide=id.g64c15419e7_0_40\n\u003e\u003e\u003e )\n\u003e\u003e\u003e\n\u003e\u003e\u003e Stuckless + AMP (an improvement on Boomerang) (\n\u003e\u003e\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002239.html\n\u003e\u003e\u003e )\n\u003e\u003e\u003e\n\u003e\u003e\u003e Pay-for-signature (\n\u003e\u003e\u003e https://suredbits.com/payment-points-part-4-selling-signatures/)\n\u003e\u003e\u003e\n\u003e\u003e\u003e Pay-for-commitment (\n\u003e\u003e\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-September/002166.html\n\u003e\u003e\u003e )\n\u003e\u003e\u003e\n\u003e\u003e\u003e Monotonic access structures on payment completion (\n\u003e\u003e\u003e https://suredbits.com/payment-points-monotone-access-structures/)\n\u003e\u003e\u003e\n\u003e\u003e\u003e Ideal Barrier Escrow Implementation (\n\u003e\u003e\u003e https://suredbits.com/payment-points-implementing-barrier-escrows/)\n\u003e\u003e\u003e\n\u003e\u003e\u003e And allowing for Barrier Escrows, we can even have\n\u003e\u003e\u003e\n\u003e\u003e\u003e Atomic multi-payment setup (\n\u003e\u003e\u003e https://suredbits.com/payment-points-and-barrier-escrows/)\n\u003e\u003e\u003e\n\u003e\u003e\u003e Lightning Discreet Log Contract (\n\u003e\u003e\u003e https://suredbits.com/discreet-log-contracts-on-lightning-network/)\n\u003e\u003e\u003e\n\u003e\u003e\u003e Atomic multi-payment update (\n\u003e\u003e\u003e https://suredbits.com/updating-and-transferring-lightning-payments/)\n\u003e\u003e\u003e\n\u003e\u003e\u003e Lightning Discreet Log Contract Novation/Transfer (\n\u003e\u003e\u003e https://suredbits.com/transferring-lightning-dlcs/)\n\u003e\u003e\u003e\n\u003e\u003e\u003e There are likely even more things that can be done with Payment Points\n\u003e\u003e\u003e so make sure to respond if I've missed any known ones.\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e How Do We Get Payment Points?\n\u003e\u003e\u003e -----------------------------\n\u003e\u003e\u003e\n\u003e\u003e\u003e Eventually, once we have Taproot, we can use 2p-Schnorr adaptor\n\u003e\u003e\u003e signatures in Lightning channels. For a detailed thread by ZmnSCPxj, see\n\u003e\u003e\u003e here\n\u003e\u003e\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-December/002375.html\n\u003e\u003e\u003e\n\u003e\u003e\u003e In the meantime, Lloyd has written about a way to do 1p-ECDSA adaptor\n\u003e\u003e\u003e sigs (https://github.com/LLFourn/one-time-VES) which can be paired with\n\u003e\u003e\u003e OP_CHECKMULTISIG to allows us to execute PTLCs on Bitcoin today!\n\u003e\u003e\u003e\n\u003e\u003e\u003e Nickler has implemented this in a branch of secp256k1 (\n\u003e\u003e\u003e https://github.com/jonasnick/secp256k1/pull/14) and I have implemented\n\u003e\u003e\u003e it in Bouncy Castle in Bitcoin-S with some testing against this branch (\n\u003e\u003e\u003e https://github.com/nkohen/bitcoin-s-core/tree/bouncy-adaptor). Do note\n\u003e\u003e\u003e that as nickler states on his PR, \"IT IS EXTREMELY DANGEROUS AND RECKLESS\n\u003e\u003e\u003e TO USE THIS MODULE IN PRODUCTION. DON'T!\"\n\u003e\u003e\u003e\n\u003e\u003e\u003e A demo of an on-chain PTLC I executed using nickler's implementation on\n\u003e\u003e\u003e the backend + bitcoin-s can be seen here https://youtu.be/w9o4v7Idjno\n\u003e\u003e\u003e\n\u003e\u003e\u003e And waxwing did a lovely write-up about the crypto itself\n\u003e\u003e\u003e https://joinmarket.me/blog/blog/schnorrless-scriptless-scripts/\n\u003e\u003e\u003e\n\u003e\u003e\u003e I would be very interested in having a fork of (at least) one lightning\n\u003e\u003e\u003e implementation (or Rust Lightning) to be a proof of concept ECDSA-PTLC node\n\u003e\u003e\u003e with which we can test and play with the plethora of PTLC-based proposals\n\u003e\u003e\u003e above.\n\u003e\u003e\u003e\n\u003e\u003e\u003e I believe this would only require a few changes to existing nodes:\n\u003e\u003e\u003e\n\u003e\u003e\u003e 1) update_add_ptlc will have a 32 byte x-coordinate (of a point) rather\n\u003e\u003e\u003e than a 32 byte hash. Additionally the onion's hop_data will contain a 32\n\u003e\u003e\u003e byte scalar tweak for each hop. As per [link multi-hop locks]. The last\n\u003e\u003e\u003e hop_data will instead include a 32 byte scalar equal to the sum of all\n\u003e\u003e\u003e tweaks.\n\u003e\u003e\u003e\n\u003e\u003e\u003e 2) commitment_signed will have 162 byte adaptor ptlc_signatures rather\n\u003e\u003e\u003e than valid (71/72 byte) ECDSA signatures on PTLC-success transactions.\n\u003e\u003e\u003e\n\u003e\u003e\u003e 3) The in-flight outputs on the commitment transaction itself become a\n\u003e\u003e\u003e little simpler as we no longer need to explicitly check the payment\n\u003e\u003e\u003e pre-image against a hash. Instead, delete all instances of \"OP_HASH160\n\u003e\u003e\u003e \u003cRIPEMD160(payment_hash)\u003e OP_EQUALVERIFY\" in the scripts (leaving the rest\n\u003e\u003e\u003e the same) and require no pre-image in the witness, only a valid signature.\n\u003e\u003e\u003e The pre-image check is implicitly enforced by the \u003cremoteptlc_sig\u003e witness\n\u003e\u003e\u003e since only an adaptor signature was provided by remote so that the payment\n\u003e\u003e\u003e pre-image is required to create the valid signature (from which the\n\u003e\u003e\u003e pre-image can be then deduced by comparing adaptor and valid signatures).\n\u003e\u003e\u003e\n\u003e\u003e\u003e If I've missed any other changes that need to happen, do respond with\n\u003e\u003e\u003e them!\n\u003e\u003e\u003e\n\u003e\u003e\u003e I hope that as a community we can work towards having a PTLC-based\n\u003e\u003e\u003e Lightning Network that is safe and stable as soon as possible, and so I\n\u003e\u003e\u003e encourage further thinking, development and expirementation with PTLCs now\n\u003e\u003e\u003e so that when Taproot is finally at our disposal we can cleanly start moving\n\u003e\u003e\u003e towards a more ideal Lightning :)\n\u003e\u003e\u003e\n\u003e\u003e\u003e Best,\n\u003e\u003e\u003e Nadav\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/20200423/61661e72/attachment-0001.html\u003e"}