Hi aj,
I think there's another workaround for the x-only issue with
TAPLEAF_UPDATE_VERIFY.
So the opcode will need a function f that ensures that the new internal
key f(P'), where P' = P + X, has even y. You describe what happens for
the canonical choice of
f(P') = if has_even_y(P') then P' else
I very much like this idea. It seems pretty flexible and has a lot of
interesting properties and use cases without being very complex. I'll have
to read through this more deeply later. I'm curious to understand more how
it compares to OP_CTV. It seems that implementing OP_TLUV wouldn't make
OP_CTV
Hi AJ,
Happy to see that this proposal has finally seen the light of day! I've been
hearing about it in hinted background convos over the past few months, so
happy I can finally dig into the specifics of its operation.
> So the idea is to do just that via a new opcode "TAPLEAF_UPDATE_VERIFY"
>
> Hmm, I'm reading C5 as "If an oracle says X, and Alice and Carol agree,
> they can distribute all the remaining funds as they see fit".
Should be read as an OR:
IF 2 2 CHECKMULTISIG
ELSE 2 2 CHECKMULTISIG
ENDIF
<> 2 IN_OUT_AMOUNT
The empty vector is a
On Sat, Sep 18, 2021 at 10:11:10AM -0400, Antoine Riard wrote:
> I think one design advantage of combining scope-minimal opcodes like MERKLESUB
> with sighash malleability is the ability to update a subset of the off-chain
> contract transactions fields after the funding phase.
Note that it's not
> I think " MERKLESUB" is the same as " OP_0 2 TLUV", provided
> happens to be the same index as the current input. So it misses the
> ability to add branches (replacing OP_0 with a hash), the ability to
> preserve the current script (replacing 2 with 0), and the ability to
> remove some of the
On Sun, Sep 12, 2021 at 07:37:56PM -0400, Antoine Riard via bitcoin-dev wrote:
> While MERKLESUB is still WIP, here the semantic. [...]
> I believe this is matching your description and the main difference compared
> to
> your TLUV proposal is the lack of merkle tree extension, where a new merkle
Sorry for the lack of clarity, sometimes it sounds easier to explain ideas
with code.
While MERKLESUB is still WIP, here the semantic. If the input spent is a
SegWit v1 Taproot output, and the script path spending is used, the top
stack item is interpreted as an output position of the spending
On Fri, Sep 10, 2021 at 12:12:24AM -0400, Antoine Riard wrote:
> "Talk is cheap. Show me the code" :p
> case OP_MERKLESUB:
I'm not entirely clear on what your opcode there is trying to do. I
think it's taking
MERKLESUB
and checking that output N has the same scripts as the current
Hi AJ,
Thanks for finally putting the pieces together! [0]
We've been hacking with Gleb on a paper for the CoinPool protocol [1]
during the last weeks and it should be public soon, hopefully highlighting
what kind of scheme, TAPLEAF_UPDATE_VERIFY-style of covenant enable :)
Here few early
On Thu, Sep 09, 2021 at 12:26:37PM -0700, Jeremy wrote:
> I'm a bit skeptical of the safety of the control byte. Have you considered the
> following issues?
> If we used the script "0 F 0 TLUV" (H=F, C=0) then we keep the current
> script, keep all the steps in the merkle path (AB and
I'm a bit skeptical of the safety of the control byte. Have you considered
the following issues?
> The low bit of C indicates the parity of X; if it's 0, X has even y,
> if it's 1, X has odd y.
>
> The next bit of C indicates whether the current script is dropped from
> the merkle path, if it's
I like this proposal, I think it has interesting use cases! I'm quick to
charitably Matt's comment, "I’ve been saying we need more covenants
research and proposals before we move forward with one", as before we move
forward with *any.* I don't think that these efforts are rival -- different
Hi Anthony,
This post is a follow-up to your insight on Twitter [0], sent here for better
posterity, accessibility and readability than Twitter. And also to motivate this
idea by giving another concrete [1] usecase for it.
Revault [2] is a multi-party "vault" protocol. It involves 2 sets of
Thanks for taking the time to write this up!
To wax somewhat broadly here, I’m very excited about this as a direction for
bitcoin covenants. Other concrete proposals seem significantly more limited,
which worries me greatly. Further, this feels very “taproot-native” in a way
that encourages
On Thu, Sep 09, 2021 at 04:41:38PM +1000, Anthony Towns wrote:
> I'll split this into two emails, this one's the handwavy overview,
> the followup will go into some of the implementation complexities.
(This is informed by discussions with Greg, Matt Corallo, David Harding
and Jeremy Rubin;
16 matches
Mail list logo
