ell and Osuntokun. "eltoo: A Simple Layer2 Protocol for
> Bitcoin", https://blockstream.com/eltoo.pdf
> [4] Law, "Efficient Factories For Lightning Channels",
> https://github.com/JohnLaw2/ln-efficient-factories
> [5] Law, "Scaling Lightning With Simple Covenants&
consensus chain state, validation resources
>>> and reorg-safety are all the parameters that are self-contained in the
>>> spent FDT-encumbered transaction itself.
>>> If the per-block feerate fluctuates, the validity of the ulterior
>>> FDT-locked transactions chan
f miners
> collusion / coalition, as I think the introduction of a `claim_grace_period`
> is modifying the fundamentals).
>
> Best,
> Antoine
>
> [0]
> https://fc22.ifca.ai/preproceedings/119.pdf
> [1]
> https://github.com/ariard/bitcoin-contracting-primitives-wg/blob/main
imitives-wg/blob/main/meetings/meetings-18-04.md
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-November/022180.html
[3] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022093.html
[4] https://github.com/bitcoin-inquisition/bitcoin/pull/9[5] https://github.
Thanks!
> Here my understanding of the feerate-dependent timelock proposal.
> A transaction cannot be included in a block:
> - height-based or epoch-based absolute or relative timelocks are not
> satisfied according to current consensus rules (bip68 and bip 113 and
> implementation
