I'm not particularly persuaded, but also not wedded to either idea.
Fixed up tests for the OP_TRUE case here:
https://github.com/instagibbs/bitcoin/tree/ephemeral-anchors-true
On Fri, Feb 3, 2023 at 5:10 PM Peter Todd wrote:
> On Thu, Feb 02, 2023 at 03:47:28PM -0500, Greg Sanders wrote:
> > >
On Thu, Feb 02, 2023 at 03:47:28PM -0500, Greg Sanders wrote:
> > OP_TRUE is the obvious way to do this, and it results with a 1 on the
> stack,
> which plays better with other standardness rules.
>
> What other standardness rules? MINAMALIF? How does that interact with the
> proposal?
It makes
pá 27. 1. 2023 v 13:47 odesílatel Robert Dickinson via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> napsal:
> I'm curious what opinions exist and what actions might be taken by core
> developers regarding storing unlimited amounts of NFT (or other?) content
> as witness data
On Fri, Feb 3, 2023 at 3:52 AM Aymeric Vitte via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I think the right way so people don't invent deviant things is to
> increase the size of OP_RETURN, I don't get this number of 80B, you can
> hardly store a signature (of what?) in there
Indeed the witness envelope is more costly and less easy to use (or
read/track)
But let's take a standard P2PKH or P2WPKH output, what prevents me from
adding in the beginning of scriptSig or witness while spending it:
OP_PUSH OP_DROP ? Non standard ? This one makes one transaction only
There
Good evening list,
Apologies for posting! I've tried to keep discussion of ordinals and
inscriptions off-list, because I consider it to be of little relevance to
general Bitcoin development. Also, apologies for the HTML mail, but I don't
have my email client configured correctly. And finally,
