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
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
> 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,
> 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
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
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
