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>
Subject: Re: [bitcoin-dev] Proposed BIP for OP_CAT
Date: Mon, 23 Oct 2023 07:13:48 +0200 [thread overview]
Message-ID: <194405691-79e11acd8b1dc1e2cdafc878b45b15c8@pmq3v.m5r2.onet> (raw)
[-- Attachment #1: Type: text/plain, Size: 2459 bytes --]
> 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.
[-- Attachment #2: Type: text/html, Size: 2707 bytes --]
next reply other threads:[~2023-10-23 5:14 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-23 5:13 vjudeu [this message]
2023-10-26 14:30 ` Ryan Grant
-- strict thread matches above, loose matches on Subject: below --
2023-10-21 5:08 Ethan Heilman
2023-10-21 5:49 ` alicexbt
2023-10-21 15:03 ` Andrew Poelstra
2023-10-26 16:04 ` James O'Beirne
2023-10-21 16:10 ` Greg Sanders
2023-10-21 20:24 ` Ethan Heilman
2023-10-22 8:58 ` vjudeu
2023-10-24 19:47 ` Steven Roose
2023-10-26 1:53 ` Ethan Heilman
2023-10-23 2:13 ` Rusty Russell
2023-10-23 12:26 ` Anthony Towns
2023-10-23 13:41 ` Andrew Poelstra
2023-10-24 0:48 ` Rusty Russell
2023-10-24 1:17 ` Andrew Poelstra
2023-10-24 3:45 ` Rusty Russell
2023-10-24 13:05 ` Andrew Poelstra
2023-10-26 21:55 ` Peter Todd
2023-10-27 18:32 ` Anthony Towns
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=194405691-79e11acd8b1dc1e2cdafc878b45b15c8@pmq3v.m5r2.onet \
--to=vjudeu@gazeta$(echo .)pl \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=eth3rs@gmail$(echo .)com \
--cc=rusty@rustcorp$(echo .)com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox