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
Hi Luke,
> Maybe we need a 3rd BIP editor. Both Kalle and myself haven't had time
> to keep up. There are several PRs far more important than Ordinals
> nonsense that need to be triaged and probably merged.
I don't think adding another editor solves the problem discussed in this
thread.
Last
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.
>> >
Everything standardized between Bitcoin software is eligible to be and
should be a BIP. I completely disagree with the claim that it's used for
too many things.
SLIPs exist for altcoin stuff. They shouldn't be used for things related
to Bitcoin.
BOLTs also shouldn't have ever been a
On Mon, Oct 23, 2023 at 03:35:30PM +, Peter Todd via bitcoin-dev wrote:
>
> I have _not_ requested a BIP for OpenTimestamps, even though it is of much
> wider relevance to Bitcoin users than Ordinals by virtue of the fact that much
> of the commonly used software, including Bitcoin Core, is
On Mon, 2023-10-23 at 15:35 +, Peter Todd via bitcoin-dev wrote:
> Thus
> we should limit BIP assignment to the minimum possible: _extremely_
> widespread
> standards used by the _entire_ Bitcoin community, for the core
> mission of
> Bitcoin.
BIPs are Bitcoin Improvement *Proposals*. What
BIPs such as the increase in block size, drives-chains, colored coins, etc...
were proposals for Bitcoin improvements. On the other hand, your BIP brings
absolutely no improvement, on the contrary it is a regression, but you already
know that.
I strongly invite you to retract or if the
On 10/20/23 7:43 PM, Peter Todd wrote:
On Fri, Oct 20, 2023 at 09:55:12PM -0400, Matt Corallo wrote:
Quite the contrary. Schnorr signatures are 64 bytes, so in situations like
lightning where the transaction form is deterministically derived, signing 100
extra transactions requires just 6400
On Mon, Oct 23, 2023 at 11:10:56AM +, ZmnSCPxj wrote:
> Hi all,
>
> This was discussed partially on the platform formerly known as twitter, but
> an alternate design goes like this:
>
> * Add an `nExpiryTime` field in taproot annex.
I would strongly suggest making it nExpiryHeight, and
On Fri, Oct 20, 2023 at 10:38:01PM -0700, Casey Rodarmor via bitcoin-dev wrote:
> Dear List,
>
> The Ordinals BIP PR has been sitting open for nine months now[0]. I've
> commented a few times asking the BIP editors to let me know what is needed
> for the BIP to either be merged or rejected. I've
On Fri, Oct 20, 2023 at 10:38:01PM -0700, Casey Rodarmor via bitcoin-dev wrote:
>
>
>
> There has been much misunderstanding of the nature of the BIP process.
> BIPS, in particular informational BIPs, are a form of technical
> documentation, and their acceptance does not indicate that they will
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
Hi all,
This was discussed partially on the platform formerly known as twitter, but an
alternate design goes like this:
* Add an `nExpiryTime` field in taproot annex.
* This indicates that the transaction MUST NOT exist in a block at or above
the height specified.
* Mempool should put txes
On 2023-10-21 18:49, Nadav Ivgi via bitcoin-dev wrote:
Could this be addressed with an OP_CSV_ALLINPUTS, a covenant opcode
that requires _all_ inputs to have a matching nSequence, and using `1
OP_CSV_ALLINPUTS` in the HTLC preimage branch?
This would prevent using unconfirmed outputs in the
> 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
Dear List,
The Ordinals BIP PR has been sitting open for nine months now[0]. I've
commented a few times asking the BIP editors to let me know what is needed
for the BIP to either be merged or rejected. I've also reached out to the
BIP editors via DM and email, but haven't received a response.
18 matches
Mail list logo
