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