Nadav Kohen [ARCHIVE] on Nostr: 📅 Original date posted:2020-04-22 📝 Original message: Hello all, I'd like to ...
📅 Original date posted:2020-04-22
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200422/a0197f12/attachment.html>;
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200422/a0197f12/attachment.html>;