Hi,
I think if Gleb Naumenko and myself allocate our research time on this
issue, we should (hopefully) be able to come with a strong sustainable fix
to the lightning network, both systematically solving pinnings and
replacement cycling attacks (and maybe other mempools issues or things
related li
Could this be addressed with an OP_CSV_ALLINPUTS, a covenant opcode that
requires *all* inputs to have a matching nSequence, and using `1
OP_CSV_ALLINPUTS` in the HTLC preimage branch?
This would prevent using unconfirmed outputs in the HTLC-preimage-spending
transaction entirely, which IIUC shoul
> By redefining a bit of the nVersion field, eg the most significant bit, we
> can apply coinbase-like txout handling to arbitrary transactions.
We already have that in OP_CHECKSEQUENCEVERIFY. You can have a system with no
coinbase transactions at all, and use only OP_CHECKSEQUENCEVERIFY on the
> This opcode would be activated via a soft fork by redefining the opcode
> OP_SUCCESS80.
Why OP_SUCCESS80, and not OP_SUCCESS126? When there is some existing opcode, it
should be reused. And if OP_RESERVED will ever be re-enabled, I think it should
behave in the same way, as in pre-Taproot, s
Brandon Black writes:
> On 2023-10-20 (Fri) at 14:10:37 +1030, Rusty Russell via bitcoin-dev wrote:
>> I've done an exploration of what would be required (given
>> OP_TX/OP_TXHASH or equivalent way of pushing a scriptPubkey on the
>> stack) to usefully validate Taproot outputs in Bitcoin S
Ethan Heilman via bitcoin-dev writes:
> Hi everyone,
>
> We've posted a draft BIP to propose enabling OP_CAT as Tapscript opcode.
> https://github.com/EthanHeilman/op_cat_draft/blob/main/cat.mediawiki
This is really nice to see!
AFAICT you don't define the order of concatenation, except in the
i
