📅 Original date posted:2018-04-30
📝 Original message:This construction is pretty neat and seems to solve a lot of problems. I
find the use of CLTV with past timestamps to provide ordering in particular
to be quite clever.
If my understanding is correct though, this construction would
significantly increase the safe CLTV delta requirements because HTLCs
cannot be timed out immediately on the settlement transaction. Consider a
case where node B receives an HTLC from A and forwards to C. If the HTLC
offered to C times out and C does not fail the HTLC off-chain, Lightning
currently guarantees that the CLTV delta is sufficient that I may close the
channel to C on-chain and claim the timed-out HTLC before my upstream HTLC
to A times out. If the CLTV delta is too small, I may fail the upstream
HTLC as soon as it times out, and then C may still claim the downstream
HTLC with the preimage on-chain. With eltoo, when B closes the downstream
channel on-chain, it must wait the CSV timeout on the update transaction
before locking in the timed-out HTLC. This effectively means the CLTV delta
has to be greater than the CSV timeout, plus some extra (whereas it is
currently safe to make it significantly shorter). Is that true or am I
missing something?
On Mon, Apr 30, 2018 at 8:41 AM, Christian Decker via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> (cross-posting to bitcoin-dev since this serves as motivation behind the
> sighash_noinput proposal)
>
> > TL;DR: we announce a new, simple, update mechanism for off-chain
> protocols,
> > see the announcement [1] and the paper [2] :-)
>
> A little over a year ago, the three Lightning Network implementation
> teams joined forces to work on a common specification for the protocol
> stack. Now that both that specification and our three implementations
> are becoming stable and usable, it is time to look forward: to further
> improve the protocol, to add new features, to simplify, and to fix
> downsides.
>
> One of the core innovations that enabled Lightning in the first place was
> an
> off-chain update mechanism to renegotiate a new state and ensure that the
> old
> state can not be settled on-chain. Today, we're excited to release our
> latest
> research paper on a new, simplified, update mechanism for layer 2
> protocols,
> called eltoo.
>
> eltoo is a drop-in replacement for the penalty based invalidation
> mechanism that is used today in the Lightning specification. It is
> similar in many ways to the sequence number mechanism that was already
> present in the original Bitcoin implementation. But, while sequence
> numbers were unenforceable on the blockchain, eltoo is enforceable by
> overriding subsequent states on-chain.
>
> Unlike the current mechanism used in Lightning so far, it is not penalty
> based, i.e., publishing an old state does not result in the faulty node
> to automatically lose funds, and is most similar to the duplex
> micropayment channels construction. It is a symmetric scheme, i.e., all
> participants share an identical set of transactions, and it ensures that
> the
> last agreed upon state is settled on-chain, with similar tradeoffs as
> today's Lightning (timelock vs. online requirement).
>
> eltoo addresses some of the issues we encountered while speficying and
> implementing the Lightning Network. For example outsourcing becomes very
> simple since old states becoming public can't hurt us anymore. We
> completely remove the need to estimate fees ahead of time. The
> construction allows us to attach fees when settling, and even allows for
> fees to be bumped using CPFP or RBF.
>
> Beyond Lightning, eltoo can be used as a generic update mechanism for an
> off-chain contract, for a larger number of participants. This was not
> possible in the current update mechanism since reactions to a
> misbehaving participant needed to be tailore to that participant. This
> enables other protocols such as the channel factories, and in
> combination with Schnorr signatures allows for very large off-chain
> contracts with minimal on-chain footprint.
>
> Before we can implement eltoo, we need a minor change to Bitcoin: the
> introduction of the SIGHASH_NOINPUT flag for signatures. This was first
> discussed a few months ago in the context of watchtowers to help secure
> Lightning channels, but was not formally proposed. A formal proposal may
> now be found in the eltoo paper.
>
> We invite the community to consider our proposal and to participate in
> its discussion. We hope to arrive at a consensus for the usage of
> SIGHASH_NOINPUT, so that it can be accepted and included in a future
> soft fork of Bitcoin Script. Doing so will put us on the road to a more
> reliable and simpler Lightning Network, incorporating a new update
> mechanism that can also be used for many other applications.
>
> The full official announcement can be found at [1] and the paper with the
> full
> details can be found at [2].
>
> Looking forward to the communities feedback,
> Christian
>
> [1] https://blockstream.com/2018/04/30/eltoo-next-lightning.html
> [2] https://blockstream.com/eltoo.pdf
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180430/b6a46771/attachment-0001.html>;
Jim Posen [ARCHIVE] /
npub1nc…lqt2n
2023-06-07 18:11:43
in reply to nevent1q…68fe
Author Public Key
npub1ncnj8arudstdxzfhxk7k4nwgkrw3hyw8sgt0wqqmm5hh2c4knmgs2lqt2nPublished at
2023-06-07 18:11:43Event JSON
{
"id": "b45ed974d1e335d9f42a2f556395616c957a4c8923687e2a0807e0826d5694c4",
"pubkey": "9e2723f47c6c16d3093735bd6acdc8b0dd1b91c78216f7001bdd2f7562b69ed1",
"created_at": 1686161503,
"kind": 1,
"tags": [
[
"e",
"1f5cc16548ec8a809c4075d425cab923fec71f0c7be06c89b241aa480be02df2",
"",
"root"
],
[
"e",
"5c75be3592cef4115d12db2ffc2f7993f96a3b940b213899db919d4688b92c08",
"",
"reply"
],
[
"p",
"72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057"
]
],
"content": "📅 Original date posted:2018-04-30\n📝 Original message:This construction is pretty neat and seems to solve a lot of problems. I\nfind the use of CLTV with past timestamps to provide ordering in particular\nto be quite clever.\n\nIf my understanding is correct though, this construction would\nsignificantly increase the safe CLTV delta requirements because HTLCs\ncannot be timed out immediately on the settlement transaction. Consider a\ncase where node B receives an HTLC from A and forwards to C. If the HTLC\noffered to C times out and C does not fail the HTLC off-chain, Lightning\ncurrently guarantees that the CLTV delta is sufficient that I may close the\nchannel to C on-chain and claim the timed-out HTLC before my upstream HTLC\nto A times out. If the CLTV delta is too small, I may fail the upstream\nHTLC as soon as it times out, and then C may still claim the downstream\nHTLC with the preimage on-chain. With eltoo, when B closes the downstream\nchannel on-chain, it must wait the CSV timeout on the update transaction\nbefore locking in the timed-out HTLC. This effectively means the CLTV delta\nhas to be greater than the CSV timeout, plus some extra (whereas it is\ncurrently safe to make it significantly shorter). Is that true or am I\nmissing something?\n\nOn Mon, Apr 30, 2018 at 8:41 AM, Christian Decker via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e (cross-posting to bitcoin-dev since this serves as motivation behind the\n\u003e sighash_noinput proposal)\n\u003e\n\u003e \u003e TL;DR: we announce a new, simple, update mechanism for off-chain\n\u003e protocols,\n\u003e \u003e see the announcement [1] and the paper [2] :-)\n\u003e\n\u003e A little over a year ago, the three Lightning Network implementation\n\u003e teams joined forces to work on a common specification for the protocol\n\u003e stack. Now that both that specification and our three implementations\n\u003e are becoming stable and usable, it is time to look forward: to further\n\u003e improve the protocol, to add new features, to simplify, and to fix\n\u003e downsides.\n\u003e\n\u003e One of the core innovations that enabled Lightning in the first place was\n\u003e an\n\u003e off-chain update mechanism to renegotiate a new state and ensure that the\n\u003e old\n\u003e state can not be settled on-chain. Today, we're excited to release our\n\u003e latest\n\u003e research paper on a new, simplified, update mechanism for layer 2\n\u003e protocols,\n\u003e called eltoo.\n\u003e\n\u003e eltoo is a drop-in replacement for the penalty based invalidation\n\u003e mechanism that is used today in the Lightning specification. It is\n\u003e similar in many ways to the sequence number mechanism that was already\n\u003e present in the original Bitcoin implementation. But, while sequence\n\u003e numbers were unenforceable on the blockchain, eltoo is enforceable by\n\u003e overriding subsequent states on-chain.\n\u003e\n\u003e Unlike the current mechanism used in Lightning so far, it is not penalty\n\u003e based, i.e., publishing an old state does not result in the faulty node\n\u003e to automatically lose funds, and is most similar to the duplex\n\u003e micropayment channels construction. It is a symmetric scheme, i.e., all\n\u003e participants share an identical set of transactions, and it ensures that\n\u003e the\n\u003e last agreed upon state is settled on-chain, with similar tradeoffs as\n\u003e today's Lightning (timelock vs. online requirement).\n\u003e\n\u003e eltoo addresses some of the issues we encountered while speficying and\n\u003e implementing the Lightning Network. For example outsourcing becomes very\n\u003e simple since old states becoming public can't hurt us anymore. We\n\u003e completely remove the need to estimate fees ahead of time. The\n\u003e construction allows us to attach fees when settling, and even allows for\n\u003e fees to be bumped using CPFP or RBF.\n\u003e\n\u003e Beyond Lightning, eltoo can be used as a generic update mechanism for an\n\u003e off-chain contract, for a larger number of participants. This was not\n\u003e possible in the current update mechanism since reactions to a\n\u003e misbehaving participant needed to be tailore to that participant. This\n\u003e enables other protocols such as the channel factories, and in\n\u003e combination with Schnorr signatures allows for very large off-chain\n\u003e contracts with minimal on-chain footprint.\n\u003e\n\u003e Before we can implement eltoo, we need a minor change to Bitcoin: the\n\u003e introduction of the SIGHASH_NOINPUT flag for signatures. This was first\n\u003e discussed a few months ago in the context of watchtowers to help secure\n\u003e Lightning channels, but was not formally proposed. A formal proposal may\n\u003e now be found in the eltoo paper.\n\u003e\n\u003e We invite the community to consider our proposal and to participate in\n\u003e its discussion. We hope to arrive at a consensus for the usage of\n\u003e SIGHASH_NOINPUT, so that it can be accepted and included in a future\n\u003e soft fork of Bitcoin Script. Doing so will put us on the road to a more\n\u003e reliable and simpler Lightning Network, incorporating a new update\n\u003e mechanism that can also be used for many other applications.\n\u003e\n\u003e The full official announcement can be found at [1] and the paper with the\n\u003e full\n\u003e details can be found at [2].\n\u003e\n\u003e Looking forward to the communities feedback,\n\u003e Christian\n\u003e\n\u003e [1] https://blockstream.com/2018/04/30/eltoo-next-lightning.html\n\u003e [2] https://blockstream.com/eltoo.pdf\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180430/b6a46771/attachment-0001.html\u003e",
"sig": "7f9591f968ddefeee7773eb45bec901ae9dc2d60a814aff880059b08e756de4769ca64f5d08876975ac84141b1901ec21049d18c9d8f278866de99e1d0c49356"
}