On Sun, Jul 04, 2021 at 09:02:25PM -0400, Russell O'Connor via bitcoin-dev
wrote:
> Bear in mind that when people are talking about enabling covenants, we are
> talking about whether OP_CAT should be allowed or not.
In some sense multisig *alone* enables recursive covenants: a government
that wan
Good morning Russell,
> On Sun, Jul 4, 2021 at 9:02 PM Russell O'Connor
> wrote:
>
> > Bear in mind that when people are talking about enabling covenants, we are
> > talking about whether OP_CAT should be allowed or not.
> >
> > That said, recursive covenants, the type that are most worrying,
On Sun, Jul 4, 2021 at 9:02 PM Russell O'Connor
wrote:
> Bear in mind that when people are talking about enabling covenants, we are
> talking about whether OP_CAT should be allowed or not.
>
> That said, recursive covenants, the type that are most worrying, seems to
> require some kind of OP_TWEA
Bear in mind that when people are talking about enabling covenants, we are
talking about whether OP_CAT should be allowed or not.
That said, recursive covenants, the type that are most worrying, seems to
require some kind of OP_TWEAK operation, and I haven't yet seen any
evidence that this can be
Good morning Dave,
> On Sun, Jul 04, 2021 at 11:39:44AM -0700, Jeremy wrote:
>
> > However, I think the broader community is unconvinced by the cost benefit
> > of arbitrary covenants. See
> > https://medium.com/block-digest-mempool/my-worries-about-too-generalized-covenants-5eff33affbb6
> > as a
I agree with you David. I think rather unconstrained covenants are
incredibly useful and important. Yes you can burn coins with them, you can
also permanently limit the usability of certain coins (which is less
destructive than burning them). But as Jeremy said, people are free to burn
their coins.
On Sun, Jul 04, 2021 at 11:39:44AM -0700, Jeremy wrote:
> However, I think the broader community is unconvinced by the cost benefit
> of arbitrary covenants. See
> https://medium.com/block-digest-mempool/my-worries-about-too-generalized-covenants-5eff33affbb6
> as a recent example. Therefore as a c
On Sun, Jul 4, 2021 at 1:30 PM Jeremy wrote:
> I don't really see the point of CHECKSIGFROMSTACKADD since it's not bound
> to the txdata? When might you use this?
>
I don't feel strongly about *ADD. I just figured it might be useful to do
a 2-of-3 between Alice, Bob and an Oracle signed value.
Hello,
I just wanted to put my two cents in, on the metal backup aspect. We make the
Bitcoin Recovery Tag for a similar purpose. We use a fixed font, so using '
(apostrophe) or H/h are both acceptable. Most metal stamping tools are fixed
width fonts.
You can see a picture here...
[ https://
>
> Do you have concerns about sophisticated covenants, and if so, would you
> mind describing them?
Personally, not in particular worried about arbitrary covenants as I think
that: 1 validation costs can be kept in check; 2 you're free to burn your
coins it you want to.
I *do* care that when we
I don't really see the point of CHECKSIGFROMSTACKADD since it's not bound
to the txdata? When might you use this?
And yes -- "Add OP_CHECKSIGFROMSTACK and OP_CHECKSIGFROMSTACKVERIFY to
follow the semantics from bip340-342 when witness program is v1." is a bit
light on detail for what the BIP would
Good morning Erik and Jeremy,
> The "for" arithmetic here is largely to mean that this cleverness allows an
> implementation of `OP_CHECKSIGFROMSTACK`, using arithmetic operation `OP_ADD`.
>
> To my mind this cleverness is more of an argument against ever enabling
> `OP_ADD` and friends, LOL.
>
12 matches
Mail list logo
