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 y
Good morning Erik,
> i may be ignorant here but i have a question:
>
> Given that schnorr signatures now allow signers to perform complex arithmetic
> signing operations out-of-band using their own communications techniques,
> couldn't you just perform the publishing and accumulation of these si
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 O'
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 Ele
It's a consideration, not a serious concern.
When I made the point around alphanumeric characters being similar to the
path numbers, I was actually thinking of the output descriptor appearing in
a fixed character width font, which I prefer as more appropriate for
displaying hexidecimal values. In
i may be ignorant here but i have a question:
Given that schnorr signatures now allow signers to perform complex
arithmetic signing operations out-of-band using their own communications
techniques, couldn't you just perform the publishing and accumulation of
these signature components without usin
There is a downside to using "h"/"H" from a UX perspective - taking up more
space and appearing as alphanumeric characters similar to the path numbers,
they make derivation paths and descriptors more difficult to read. Also,
although not as important, less efficient when making metal backups.
On S
On Sat, Jul 03, 2021 at 10:35:48AM +0200, Craig Raw wrote:
> There is a downside to using "h"/"H" from a UX perspective - taking up more
> space
Is this a serious concern of yours? An apostrophe is 1/2 en; an "h" is
1 en; the following descriptor contains three hardened derivations in 149
charac
Hi Billy,
> What if it was possible for the creditor to claw back the funds
As far as I know the “claw back” mechanism doesn’t exist in Bitcoin
system, and probably most Bitcoiners won’t be agree on it.
Even if we want to add claw back to Bitcoin in general, and Sabu in
particular, it would add t
Dear Bitcoin Devs,
I recently put a blog post up which is of interest for this list. Post
available here: https://rubin.io/blog/2021/07/02/covenants/ (text
reproduced below for archives).
The main technical points of interest for this list are:
1) There's a similar protocol to Eltoo built with C
12 matches
Mail list logo