>
>
>
> FWIW, I think the rmain reasons to do CAT+CSFS is to validate oracle
> messages and pubkey delegation. The ability to covenants would be
> secondary and would mostly serve to get us some real user data about what
> sort of covenants users find especially valuable.
>
I don't think this
On Fri, May 13, 2022 at 5:43 PM Anthony Towns wrote:
> For any specific opcode proposal, I think you still want to consider
>
> 1) how much you can do with it
> 2) how efficient it is to validate (and thus how cheap it is to use)
> 3) how easy it is to make it do what you want
> 4) how
On Thu, May 12, 2022 at 06:48:44AM -0400, Russell O'Connor via bitcoin-dev
wrote:
> On Wed, May 11, 2022 at 11:07 PM ZmnSCPxj wrote:
> > So really: are recursive covenants good or...?
> My view is that recursive covenants are inevitable. It is nearly
> impossible to have programmable money
On Wed, May 11, 2022 at 11:07 PM ZmnSCPxj wrote:
> Good morning Russell,
>
> > On Wed, May 11, 2022 at 7:42 AM ZmnSCPxj via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > > REMEMBER: `OP_CAT` BY ITSELF DOES NOT ENABLE COVENANTS, WHETHER
> RECURSIVE OR NOT.
> >
> >
> > I
Good morning Russell,
> On Wed, May 11, 2022 at 7:42 AM ZmnSCPxj via bitcoin-dev
> wrote:
>
> > REMEMBER: `OP_CAT` BY ITSELF DOES NOT ENABLE COVENANTS, WHETHER RECURSIVE
> > OR NOT.
>
>
> I think the state of the art has advanced to the point where we can say
> "OP_CAT in tapscript enables
On Wed, May 11, 2022 at 7:42 AM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> REMEMBER: `OP_CAT` BY ITSELF DOES NOT ENABLE COVENANTS, WHETHER RECURSIVE
> OR NOT.
>
I think the state of the art has advanced to the point where we can say
"OP_CAT in tapscript enables
> This transaction has 2 inputs: 0.00074 tBTC and 0.00073 tBTC (0.00074 +
> 0.00073 = 0.00147) which is more than output amount 0.001 tBTC
It was created without the second input, see:
https://bitcointalk.org/index.php?topic=5390103.msg59616324#msg59616324
I didn't touch that later, the
Hi vjudeu,
> It can be changed by using different sighashes, for example, it is possible
> to create a "negative fee transaction", where all transaction costs are paid
> by receiver. Using SIGHASH_SINGLE | SIGHASH_ANYONECANPAY with a higher amount
> in outputs than inputs is enough to do that,
Good morning vjudeu,
> > Looks like `OP_CAT` is not getting enabled until after we are reasonably
> > sure that recursive covenants are not really unsafe.
>
> Maybe we should use OP_SUBSTR instead of OP_CAT. Or even better: OP_SPLIT.
> Then, we could have OP_SPLIT... that would split a
>
> Looks like `OP_CAT` is not getting enabled until after we are reasonably sure
> that recursive covenants are not really unsafe.
Maybe we should use OP_SUBSTR instead of OP_CAT. Or even better: OP_SPLIT.
Then, we could have OP_SPLIT... that would split a
string N times (so there will be
On Sat, May 7, 2022 at 5:08 PM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> 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 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,
> 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
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
> 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
Good morning Jorge,
> OP_CAT was removed. If I remember correctly, some speculated that perhaps it
> was removed because it could allow covenants.I don't remember any technical
> concern about the OP besides enabling covenants.Before it was a common
> opinion that covenants shouldn't be
OP_CAT was removed. If I remember correctly, some speculated that perhaps
it was removed because it could allow covenants.
I don't remember any technical concern about the OP besides enabling
covenants.
Before it was a common opinion that covenants shouldn't be enabled in
bitcoin because, despite
19 matches
Mail list logo
