operands: OP_CAT, OP_ADD, OP_SHA256, OP_DUP, OP_DROP, OP_MIN, OP_MAX, OP_AND, OP_OR, OP_BOOLAND, OP_BOOLOR, OP_EQUAL. This is simpler than introducing general iteration into

I remember what i was talking about a few weeks back. I was envisioning that all the pubkeys would be merged together across all inputs, but this would

opcodes like OP_CAT, but then, they would open more use cases, which may have unknown side effects (like implementing BIP-300 or BIP-301 without any additional soft-fork). Also,

the vulnerability OP_CAT which had been closed in Bitcoin long time ago. It's pushed under the guise of secp256r1 which has nothing to do with the OP_CAT. Also, HSM and other technobabble

> Agreed. AFAICT, the only reason we'd use WOTS+ over stock > WOTS (w/o randomizers) would be if we wanted to use a less > collision-

>> OP_CAT (BIP-347) would provide useful data to inform a Bitcoin Script >>> replacement. >>> >>> In addition to allowing ZK people to experiment

ex: OP_CAT) to be committed to in an annex but not in a scriptPubKey. Such opcodes could then be safely used during delegation without enabling AMMs or state-carrying recursive covenants

-from-op_cat-to-covenants-hong-kong/ Delving Bitcoin post with more details: https://delvingbitcoin.org/t/collidervm-protocol-for-computation-and-l2-bridges/1662

and using OP_CAT only works if the exact position of the substring is known. How would a case be handled where the substring could be in any position > Whoever produces the signature

absolutely require OP_CAT to work? This does not require OP_CAT to work at all. It works today. > What is the rough size of such a transaction? SHA256 costs about 211kb of small script

Hi all, > After that, one can build a script: OP_CSFS> OR < SIGHASH_SINGLE> OP_CHECKSIG. Using SIGHASH_SINGLE the TxWithhold attacker can

> > OP_CAT is not proposed as an opcode to enable LN SYMMETRY. Whereas OP_PAIRCOMMIT is a part of LNHANCE. > > > > > > > > > > In this context, OP_PAIRCOMMIT

waiting on OP_CAT and the other more general script opcode additions for this, as those seem stuck in bikeshed hell, not to mention questions around MEVil and Bitcoin's future

> If I'm understanding correctly, the trick is about proving that y(y1 = y2) both in Big Script and Small Script. Yes, the trick is about

, without OP_CAT. These approaches both have downsides, Collider script costs millions of dollars in compute per spend, Functional Encryption requires fancy cryptography that

If `OP_CAT` was available, it could be used to combine multiple stack elements, that get verified with `OP_CHECKSIGFROMSTACK` as a valid state update. `OP_PAIRCOMMIT` solves this

Thanks for the response as always, Antoine, and I've made several substantial updates to the BIP in case you'd like to give it another once-

related to OP_CAT: > > Drivechain: https://sha-gate-demo.netlify.app/ > AOPP 2.0: > https://groups.google.com/g/bitcoindev/c/6SgD6_rmNAQ/m/Q3cTqaqEDQAJ

It seems like you could do this today, no new opcodes, if you made the pubkey identity check interactive rather than purely on-chain. I'd imagine

as `OP_CAT`. > 5. [BIP 118]-style Taproot internal key: Rather than introducing an > additional key type in this change, we suggest implementing > OP_INTERNALKEY or separately

347] OP_CAT ([PR#39]) This is based on [Bitcoin Core 25.2]. The first two of these have been active on the default signet since block 106704 (2022-09-06), and the third should become

see your OP_CAT design is now on the mailing list. > > Inside the BIP text, you mention that a sufficiently large OP_CAT script can "support tree signatures with a thousand