On Sat, Oct 21, 2023 at 01:08:03AM -0400, Ethan Heilman via bitcoin-dev wrote:
> 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
If you're interested in making this available via inquisition, here's
a
On Sat, Oct 21, 2023 at 01:08:03AM -0400, Ethan Heilman via bitcoin-dev wrote:
> OP_CAT fails if there are less than two values on the stack or if a
> concatenated value would have a combined size of greater than the
> maximum script element size of 520 Bytes.
Note that if OP_CAT immediately
I have to admit - I'm somewhat baffled at the enthusiasm for a "just CAT"
softfork, since I can't see that it would achieve much. It's indicative to
me that there isn't a compelling example to date that (i) actually has
working code and (ii) only relies upon CAT. I'm not averse to CAT, just
I support OP_CAT, along with reasonable resource-consumption limiters.
Implementation as a UASF would help build confidence in that method.
I also support moving forward on other opcodes as soon as they are
known to be safe and maintainable; whether for introspection, tx
unpinning, or vaults.
If there is sufficient interest in enabling OP_CAT on Bitcoin and
there is a strong desire in the community for using OP_SUCCESS126
rather than OP_SUCCESS80 then I'd be happy to switch to OP_SUCCESS126.
I don't have any particular affinity for OP_SUCCESS80.
Is there anyone who objects to using
I agree that there is no reason not to use OP_SUCCESS126, i.e. the
original OP_CAT opcode 0x7e. In many codebases, for example in Core,
there might be two OP_CAT constants than which might be confusing.
On 10/22/23 09:58, vjudeu via bitcoin-dev wrote:
> This opcode would be activated via a
On Tue, Oct 24, 2023 at 02:15:49PM +1030, Rusty Russell wrote:
> Andrew Poelstra writes:
> > I had a similar thought. But my feeling is that replacing the stack
> > interpreter data structure is still too invasive to justify the benefit.
> >
> > Also, one of my favorite things about this BIP is
Andrew Poelstra writes:
> I had a similar thought. But my feeling is that replacing the stack
> interpreter data structure is still too invasive to justify the benefit.
>
> Also, one of my favorite things about this BIP is the tiny diff.
To be fair, this diff is even smaller than the OP_CAT diff
On Tue, Oct 24, 2023 at 11:18:24AM +1030, Rusty Russell wrote:
> Andrew Poelstra writes:
> >> 3. Should we restrict elsewhere instead? After all, OP_CAT doesn't
> >>change total stack size, which is arguably the real limit?
> >>
> >
> > Interesting thought. Right now the stack size is
Andrew Poelstra writes:
> On Mon, Oct 23, 2023 at 12:43:10PM +1030, Rusty Russell via bitcoin-dev wrote:
>> Ethan Heilman via bitcoin-dev writes:
>> > Hi everyone,
>> >
>> > We've posted a draft BIP to propose enabling OP_CAT as Tapscript opcode.
>> >
On Mon, Oct 23, 2023 at 12:43:10PM +1030, Rusty Russell via bitcoin-dev wrote:
> 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
>
>
On Mon, Oct 23, 2023 at 12:43:10PM +1030, Rusty Russell via bitcoin-dev wrote:
> 2. Was there a concrete rationale for maintaining 520 bytes?
Without a limit of 520 bytes, then you can construct a script:
CHECKSIGVERIFY
{DUP CAT}x10
(we know have a string that is the second
> 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
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
> 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,
Hi Greg,
I didn't mean to imply this limit is a unique feature of tapescript, but
rather that:OP_CAT is a tapscript opcode and that tapscript enforces a 520
byte element size thus we don't have to worry about OP_CAT creating very
large stack elements.
Thanks for pointing this out, I didn't
> This is no
longer an issue in the current age as tapscript enforces a maximum
stack element size of 520 Bytes.
I don't think there's a new limit related to tapscript? In the very
beginning there was no limit, but a 5k limit was put into place, then 520
the same commit that OP_CAT was
disabled:
On Sat, Oct 21, 2023 at 01:08:03AM -0400, Ethan Heilman via bitcoin-dev wrote:
> 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
>
> OP_CAT was available in early versions of Bitcoin.
Hi Ethan,
> [2]: P. Wuille, "Multisig on steroids using tree signatures", 2015,
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019233.html
Correct link for "Multisig on steroids using tree signatures":
https://blog.blockstream.com/en-treesignatures/
/dev/fd0
floppy disk
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
OP_CAT was available in early versions of Bitcoin. It was disabled as
it allowed the construction of a script whose evaluation could create
20 matches
Mail list logo
