I don't think Elements engineering decisions or management timelines should
have any bearing on what Bitcoin adopts, beyond learning what
works/doesn't. Same as litecoin, dogecoin, or bitcoin cash :)
With my understanding of elements it makes sense that you wouldn't want to
break compatibility
If the main outstanding issue is whether to split R or S, I think as far as
Elements goes, I am inclined to go with the CAT option regardless of
whether Bitcoin chooses to split R/S or not (not that I'm necessarily a
decision maker here).
The issue here is that (a) Elements already has CAT, and
Re-threading Sanket's comment on split R value:
I also am in general support of the `OP_CHECKSIGFROMSTACK` opcode. We would
> need to update the suggestion to BIP340, and add it to sigops budget. I
> have no strong preference for splitting R and s values or variable-length
> messages.
>
Back to
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.
>
> 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
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
On Sat, Jul 03, 2021 at 09:31:57AM -0700, Jeremy via bitcoin-dev wrote:
> Note that with *just* CheckSigFromStack, while you can do some very
> valuable use cases, but without OP_CAT it does not enable sophisticated
> covenants
Do you have concerns about sophisticated covenants, and if so, would
There is one line written at
https://github.com/ElementsProject/elements/pull/949/files#r660130155. I
suppose we need to decide on which variants of *VERIFY and *ADD we want to
include (presumably all of them) and choose which opcodes they will be
assigned to. And I guess for CHECKSIGFROMSTACKADD
Awesome to hear that!
Actually I don't think I did know (or I forgot/didn't catch it) that there
was an updated spec for elements, I searched around for what I could find
and came up empty handed. Do you have any links for that? That sounds
perfect to me.
On Sat, Jul 3, 2021, 10:50 AM Russell
Hi Jermy,
As you are aware, we, and by we I mean mostly Sanket, are developing an
updated OP_CHECKSIGFROMSTACK implementation for tapscript on elements. The
plan here would be to effectively support the an interface to the
variable-length extension of BIP-0340 schnorr signatures.
BIP-0340 would
Reproduced below is the BIP text from Bitcoin Cash's (MIT-Licensed)
specification for "CheckDataSig", more or less the same thing as
CHECKSIGFROMSTACK
https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/op_checkdatasig.md.
In contrast to Element's implementation, it does not have
11 matches
Mail list logo
