Good morning shesek,
> On Sat, May 7, 2022 at 5:08 PM ZmnSCPxj via bitcoin-dev
> wrote:
> > * Even ***with*** `OP_CAT`, the following will enable non-recursive
> > covenants without enabling recursive covenants:
> > * `OP_CTV`, ...
> > * With `OP_CAT`, the following would enable recursive
Good morning Jorge,
> I think people may be scared of potential attacks based on covenants. For
> example, visacoin.
> But there was a thread with ideas of possible attacks based on covenants.
> To me the most scary one is visacoin, specially seeing what happened in
> canada and other places
Good morning Jorge,
> Thanks again.
> I won't ask anything else about bitcoin, I guess, since it seems my questions
> are too "misinforming" for the list.
> I also agreed with vjudeu, also too much misinformation on my part to agree
> with him, it seems.
> I mean, I say that because it doesn't
It is quite ironic that yeah, it is quite ironic that the people who are
constantly basing their arguments on personal attack are also the ones who
complain the most about personal attacks. That's exactly the irony I was
trying to convey.
Just like some people claim that the only people against
I think people may be scared of potential attacks based on covenants. For
example, visacoin.
But there was a thread with ideas of possible attacks based on covenants.
To me the most scary one is visacoin, specially seeing what happened in
canada and other places lately and the general censorship
Thanks a lot for the many clarifications.
Yeah, I forgot it wasn't OP_CAT alone, but in combination with other things.
I guess this wouldn't be a covenants proposal then.
But simplicity would enable covenants too indeed, no?
Or did I get that wrong too?
On Sat, May 7, 2022 at 5:06 AM ZmnSCPxj
On Sat, May 7, 2022 at 5:52 AM wrote:
> > Re-enabling OP_CAT with the exact same OP would be a hardfork, but
> creating a new OP_CAT2 that does the same would be a softfork.
>
> We have TapScript for that. OP_CAT is defined as OP_SUCCESS, it can be
> re-enabled in a soft-fork way. For now,
Good morning Jorge,
> Thanks a lot for the many clarifications.
> Yeah, I forgot it wasn't OP_CAT alone, but in combination with other things.
> I guess this wouldn't be a covenants proposal then.
> But simplicity would enable covenants too indeed, no?
> Or did I get that wrong too?
Yes, it
Have you seen the inherited ID proposal from John Law on this list?
It's a pretty thorough treatment of this type of proposal, curious if you
think it overlaps what you had in mind?
Honestly, I've yet to fully load in exactly how the applications of it
work, but I'd be interested to hear your
For now, we have txid:vout as a previous transaction output. This means that to
have a stable TXID, we are forced to use SIGHASH_ALL somewhere, just to prevent
any transaction modifications that can happen during adding some inputs and
outputs. But it seems that new sighashes could be far more
> Re-enabling OP_CAT with the exact same OP would be a hardfork, but creating a
> new OP_CAT2 that does the same would be a softfork.
We have TapScript for that. OP_CAT is defined as OP_SUCCESS, it can be
re-enabled in a soft-fork way. For now, OP_CAT in TapScript simply means
"anyone can move
Hi Bitcoin Developers,
Summary for the last CTV meeting:
Topics:
1)APO version of the simple vault
2)APO as alternative to CTV
3)fiatjaf's CTV spacechain demo
4)Compare CTV with other covenant proposals
5)Recursive covenants
6)Responding to FUD
12 matches
Mail list logo
