Re: [bitcoin-dev] Soft-forks and schnorr signature aggregation

2018-03-27 Thread Bram Cohen via bitcoin-dev
On Mon, Mar 26, 2018 at 11:34 PM, Anthony Towns wrote: > On Wed, Mar 21, 2018 at 05:47:01PM -0700, Bram Cohen via bitcoin-dev wrote: > > [...] Most unused opcodes should be reclaimed as RETURN_VALID, > > but there should still be one OP_NOP and there should be a 'real' >

[bitcoin-dev] Optimized Header Sync

2018-03-27 Thread Jim Posen via bitcoin-dev
Based on some ideas that were thrown around in this thread ( https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-December/015385.html), I have been working on a P2P extension that will allow faster header sync mechanisms. The one-sentence summary is that by encoding headers more

Re: [bitcoin-dev] {sign|verify}message replacement

2018-03-27 Thread Karl Johan Alm via bitcoin-dev
Pieter, Thanks for the feedback. Comments below: On Mon, Mar 26, 2018 at 5:53 PM, Pieter Wuille wrote: > One solution is to include a version number in the signature, which > explicitly corresponds to a set of validation flags. When the version number > is something a

Re: [bitcoin-dev] Soft-forks and schnorr signature aggregation

2018-03-27 Thread Anthony Towns via bitcoin-dev
On Wed, Mar 21, 2018 at 05:47:01PM -0700, Bram Cohen via bitcoin-dev wrote: > [...] Most unused opcodes should be reclaimed as RETURN_VALID, > but there should still be one OP_NOP and there should be a 'real' > RETURN_VALID, > which (a) is guaranteed to not be soft forked into something else in