Antoine Riard

> Having some code that works in proof-of-concept mode is not proof that it works in the real world at all. A theoretical description of a use case that contemplates...

> I think it would be worth moving most conceptual discussion to the [Delving Bitcoin thread](https://delvingbitcoin.org/t/covenant-tools-softfork/98) to avoid blasting the already-burdened Github notifications of contributors here. Answering here as I’ll...

I still maintain than softforks reducing the amount of "systemic risk"-level technical debt of the Bitcoin ecosystem should be given priority over covenant-enabling softforks, especially when there is plausible or...

To the best of my comprehension, most of the use-cases brought as a justification for the consensus changes introduced in this PR are relying on UTXO-sharing / time-locks as part...

Open to manually test and review more the removal of mainnet checkpoints when there is momentum on moving forward to remove this logic from consensus. Reviewed last year the low-work-header...

> BIP text here: https://github.com/instagibbs/bips/blob/ephemeral_anchor/bip-ephemeralanchors.mediawiki "Be 0-fee” This is uncertain to me how this rule works with trimmed HTLCs on LN commitment transactions making their fees non-zero, even assuming anchor...

> @ariard I'd rather talk downstream details over here https://github.com/bitcoin/bips/pull/1524 Thanks good to me - Answered strong conceptual issues there.

> Removing adjusted time from consensus is a big win. Having time samples received from peers be involved in consensus checks is not great and not effective against NTP based...

> After a few attempts, I haven't found a way to trigger a consensus fork through adjusted time. Unclear what has been tested actually (e.g setting sampled time of peers...

> Yes, this is exactly what this pull request did. See also the description, which said: "while the warning to users if their clock is out of sync with the...