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 helpfu
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 witho
Hi all,
Since there's recently been a lot more interest in discussing covenants and
alternative covenant proposals because of CTV, I figured I'd bring up my
own proposed covenant opcode again while the urge is still fresh.
To be clear upfront, this opcode has a spec, but nothing else. No tests. N
Good morning Chris,
> Hello waxwing,
>
> > A user sacrifices X amount of time-value-of-money (henceforth TVOM)
>
> by committing in Joinmarket with FB1. He then uses the same FB1 in
> Teleport, let's say. If he gets benefit Y from using FB1 in Joinmarket,
> and benefit Z in Teleport, then presumab
@alicexbt
> I think 'support' and 'opposition' can be replaced with readiness.
Miners should not consider signaling as voting.
I agree that it isn't voting, its signaling. But whether or not you call it
'readiness' or 'support', some miners will use it to signal 'support' and
will refuse to becom
Hello waxwing,
> A user sacrifices X amount of time-value-of-money (henceforth TVOM)
by committing in Joinmarket with FB1. He then uses the same FB1 in
Teleport, let's say. If he gets benefit Y from using FB1 in Joinmarket,
and benefit Z in Teleport, then presumably he'll only do it if
(proba