I think you may be confused. Mandatory signaling is not the same thing as
mandatory activation on timeout, aka Lock On Timeout aka LOT=true.
These are two related but separate things.
On Thu, May 12, 2022, 6:53 PM alicexbt via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi
Hi Russell,
> As far as I understand things, I believe the whole notion of a MUST_SIGNAL
> state is misguided today. Please correct me if I'm misunderstanding something
> here.
> Back when BIP8 was first proposed by Shaolin Fry, we were in a situation
> where many existing clients waiting for
@Antoine
> it's also hard to predict in advance the liquidity needs of the
sub-pools.
Definitely. Better than not being able to use the pool at all when
someone's offline tho.
> this fan-out transaction could interfere with the confirmation of the
simple withdraw transactions
> So there is an
@Jorge & Zmn
> A recursive covenant guarantees that the same thing will happen in the
future.
Just a clarification: a recursive covenant does not necessarily guarantee
any particular thing will happen in the future. Both recursives and a
non-recursive covenant opcodes *can* be used to guarantee
Great point in this specific case I unfortunately didn't consider! So
basically the design degenerates to the last option I gave, where the
counterparty
can send off N(25) weight-bound packages.
A couple thoughts:
0) Couldn't we relative-time lock update transactions's state input by 1
block as
Good morning Jorge,
> I fail to understand why non recursive covenants are called covenants at all.
> Probably I'm missing something, but I guess that's another topic.
A covenant simply promises that something will happen in the future.
A recursive covenant guarantees that the same thing will
I think something like visacoin could be kind of feasible without recursive
covenants. But as billy points out, I guess they could kind of do it with
multisig too.
I fail to understand why non recursive covenants are called covenants at
all. Probably I'm missing something, but I guess that's
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
Hi Rusty,
One of the common sentiments thats been expressed over the last few months
is that more people want to see experimentation with different applications
using covenants. I really like this proposal because in addition to
offering a cleaner upgrade/extension path than adding “CTV++” as a
On 2022-05-10 08:53, Greg Sanders via bitcoin-dev wrote:
We add OPTX_SELECT_WEIGHT(pushes tx weight to stack, my addition to
the proposal) to the "state" input's script.
This is used in the update transaction to set the upper bound on the
final transaction weight.
In this same input, for each
10 matches
Mail list logo
