Content-Type: multipart/alternative;
 boundary="===============8910380127139815667=="
MIME-Version: 1.0
From: vjudeu@gazeta.pl
To: Rusty Russell <rusty@rustcorp.com.au>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Ethan Heilman <eth3rs@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Date: Mon, 23 Oct 2023 07:13:48 +0200
Message-Id: <194405691-79e11acd8b1dc1e2cdafc878b45b15c8@pmq3v.m5r2.onet>
Subject: Re: [bitcoin-dev] Proposed BIP for OP_CAT
Precedence: list

This is a multi-part message in MIME format.
--===============8910380127139815667==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

> I think if A is top of stack, we get BA, not AB?
=C2=A0
Good question. I always thought "0x01234567 0x89abcdef OP_CAT 0x0123456789a=
bcdef 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 imple=
mentation of OP_CAT, before it was disabled. But anyway, any of those two c=
hoices will lead to similar consequences. Because you can always turn the f=
ormer into the latter by using "OP_SWAP OP_CAT", instead of "OP_CAT".
=C2=A0
> 520 feels quite small for script templates
=C2=A0
It will be easier to start with that, when it comes to reaching consensus f=
or 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 perma=
nently 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 succe=
ed.
=C2=A0
> 10k is the current script limit, can we get closer to that?
=C2=A0
We will get there anyway. Even if OP_CAT would allow concatenating up to 52=
0-bit Schnorr signature (not to confuse 520-bit with 520-byte), people woul=
d chain it, to reach arbitrary size. If you can concatenate secp256k1 publi=
c 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 som=
ething around 4 MB/10 min, and that is your only limit in this case.
=C2=A0
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 52=
0-byte proposal into 520-bit proposal, then still, people will do exactly t=
he 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.
=C2=A0
> Of course, we can increase this limit in future tapscript versions, too, =
so it's not completely set in stone.
=C2=A0
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.
--===============8910380127139815667==
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<div>
<div>&gt; I think if A is top of stack, we get BA, not AB?</div>
<div>&nbsp;</div>
<div>Good question. I always thought "0x01234567 0x89abcdef OP_CAT 0x012345=
6789abcdef OP_EQUAL" is correct, but it could be reversed as well. If we wa=
nt 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".<=
/div>
<div>&nbsp;</div>
<div>&gt; 520 feels quite small for script templates</div>
<div>&nbsp;</div>
<div>It will be easier to start with that, when it comes to reaching consen=
sus 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.</div>
<div>&nbsp;</div>
<div>&gt; 10k is the current script limit, can we get closer to that?</div>
<div>&nbsp;</div>
<div>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 h=
andle arbitrary size. The only limitation is then blockchain speed, which i=
s something around 4 MB/10 min, and that is your only limit in this case.</=
div>
<div>&nbsp;</div>
<div>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 fr=
om 520-byte proposal into 520-bit proposal, then still, people will do exac=
tly 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.=
</div>
<div>&nbsp;</div>
<div>&gt; Of course, we can increase this limit in future tapscript version=
s, too, so it's not completely set in stone.</div>
<div>&nbsp;</div>
<div>Judging by the last misuse of Ordinals, I think it may happen before a=
nyone will propose some official future version. Which means, nothing is re=
ally set in stone anymore, because now people know, how to activate new fea=
tures, without any soft-fork, and some no-forks will probably be done by ne=
wbies, without careful designing and testing, as it is done here.</div>
</div>

--===============8910380127139815667==--