Re: [bitcoin-dev] MAST/Schnorr related soft-forks

2018-05-10 Thread Bram Cohen via bitcoin-dev
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

Re: [bitcoin-dev] MAST/Schnorr related soft-forks

2018-05-10 Thread Chris Belcher via bitcoin-dev
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

Re: [bitcoin-dev] MAST/Schnorr related soft-forks

2018-05-10 Thread Russell O'Connor via bitcoin-dev
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/

[bitcoin-dev] MAST/Schnorr related soft-forks

2018-05-10 Thread Anthony Towns via bitcoin-dev
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