I'm not sure about the best way to approach soft-forking (I've opined on it
before, and still find the details mind-numbing) but the end goal seems
fairly clearly to be an all of the above: Have aggregatable public keys
which support simple signatures, taproot with BIP 114 style taproot, and
Graftr
Thanks for the summary,
It may be worth emphasizing the fungibility aspects of all this.
That summary contains ideas to possibly have separate address types,
opcodes and scriptSigs/witnesses for different feature, at least to
start with. To me this would seem bad because it may miss out on the
fu
Thanks for writing this up Anthony.
Do you think that a CHECKSIGFROMSTACK proposal should be included within
this discussion of signature soft-forks, or do you see it as an unrelated
issue?
CHECKSIGFROMSTACK enables some forms of (more) efficent MPC (See
http://people.csail.mit.edu/ranjit/papers/
Hello world,
After the core dev meetup in March I wrote up some notes of where I
think things stand for signing stuff post-Schnorr. It was mostly for my
own benefit but maybe it's helpful for others too, so...
They're just notes, so may assume a fair bit of background to be able to
understand the