> I think if A is top of stack, we get BA, not AB?
Good question. I always thought "0x01234567 0x89abcdef OP_CAT
0x0123456789abcdef OP_EQUAL" is correct, but it could be reversed as well. If
we want to stay backward-compatible, we can dig into the past, and test the old
implementation of OP_CAT, before it was disabled. But anyway, any of those two
choices will lead to similar consequences. Because you can always turn the
former into the latter by using "OP_SWAP OP_CAT", instead of "OP_CAT".
> 520 feels quite small for script templates
It will be easier to start with that, when it comes to reaching consensus for a
new soft-fork. But yes, I am very surprised, because I thought we will never
see things like that, and I assumed the path to OP_CAT is just permanently
closed. So, I am surprised this BIP reached a positive reaction, but well, that
kind of proposal was not battle-tested, so maybe it could succeed.
> 10k is the current script limit, can we get closer to that?
We will get there anyway. Even if OP_CAT would allow concatenating up to
520-bit Schnorr signature (not to confuse 520-bit with 520-byte), people would
chain it, to reach arbitrary size. If you can concatenate secp256k1 public keys
with signatures, you can create a chain of OP_CATs, that will handle arbitrary
size. The only limitation is then blockchain speed, which is something around 4
MB/10 min, and that is your only limit in this case.
And yes, if I can see that some people try to build logical gates like NAND
with Bitcoin Script, then I guess all paths will be explored anyway. Which
means, even if we will take more conservative approach, and switch from
520-byte proposal into 520-bit proposal, then still, people will do exactly the
same things. Now, it is all about the cost of pushing data, because some people
noticed, that everything can be executed on Script. I knew we will get there,
but I expected it would just happen later than it happened.
> Of course, we can increase this limit in future tapscript versions, too, so
> it's not completely set in stone.
Judging by the last misuse of Ordinals, I think it may happen before anyone
will propose some official future version. Which means, nothing is really set
in stone anymore, because now people know, how to activate new features,
without any soft-fork, and some no-forks will probably be done by newbies,
without careful designing and testing, as it is done here.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
