Re: [bitcoin-dev] Version 1 witness programs (first draft)

On Monday 02 October 2017 12:35:38 AM Mark Friedenbach wrote: > > b. OP_RETURNTRUE (Luke). I proposed this in an earlier version of BIP114 > > but now I think it doesn’t interact well with signature aggregation, and > > I worry that it would have some other unexpected effects. c. Generalised > >

Re: [bitcoin-dev] Version 1 witness programs (first draft)

On Sunday 01 October 2017 9:32:56 PM Johnson Lau wrote: > 1. How do we allow further upgrade within v1 witness? Here are some > options: a. Minor version in witness. (Johnson / Luke) I prefer this way, > but we may end up with many minor versions. b. OP_RETURNTRUE (Luke). I > proposed this in an

Re: [bitcoin-dev] Version 1 witness programs (first draft)

> On Oct 1, 2017, at 2:32 PM, Johnson Lau wrote: > > So there are 3 proposals with similar goal but different designs. I try to > summarise some questions below: > > 1. How do we allow further upgrade within v1 witness? Here are some options: > a. Minor version in witness.

Re: [bitcoin-dev] Version 1 witness programs (first draft)

On Sunday 01 October 2017 8:39:11 PM Mark Friedenbach wrote: > What about an optional commitment to witness size in bytes? The value zero > meaning ??I don??t care.?? I would argue that it should be a maximum however, > and therefor serialized as part of the witness. The serialization of this >

Re: [bitcoin-dev] Version 1 witness programs (first draft)

> On Oct 1, 2017, at 12:41 PM, Russell O'Connor wrote: > > Creating a Bitcoin script that does not allow malleability is difficult and > requires wasting a lot of bytes to do so, typically when handling issues > around non-0-or-1 witness values being used with OP_IF,

Re: [bitcoin-dev] Version 1 witness programs (first draft)

On Sun, Oct 1, 2017 at 3:27 PM, Mark Friedenbach wrote: > > On Oct 1, 2017, at 12:05 PM, Russell O'Connor > wrote: > > > > Given the proposed fixed signature size, It seems better to me that we > create a SIGHASH_WITNESS_WEIGHT flag as opposed to

Re: [bitcoin-dev] Version 1 witness programs (first draft)

> On Oct 1, 2017, at 12:05 PM, Russell O'Connor wrote: > > Given the proposed fixed signature size, It seems better to me that we create > a SIGHASH_WITNESS_WEIGHT flag as opposed to SIGHASH_WITNESS_DEPTH. For what benefit? If your script actually uses all the items on

Re: [bitcoin-dev] Version 1 witness programs (first draft)

Given the proposed fixed signature size, It seems better to me that we create a SIGHASH_WITNESS_WEIGHT flag as opposed to SIGHASH_WITNESS_DEPTH. Mark, you seem to be arguing that in general we still want weight malleability even with witness depth fixed, but I don't understand in what scenario we

Re: [bitcoin-dev] Version 1 witness programs (first draft)

I would also suggest that the 520 byte push limitation be removed for v1 scripts as well. MERKLEBRANCHVERIFY in particular could benefit from larger proof sizes. To do so safely would require reworking script internals to use indirect pointers and reference counting for items on stack, but this

Re: [bitcoin-dev] Version 1 witness programs (first draft)

BIP 115 provides fork-independent opt-in replay protection, which can be used in combination with the new signature condition scripts in this proposal. Perhaps the code can have a flag for new altcoins to easily make it mandatory (and we can use it on testnet?). Luke On Sunday 01 October

Re: [bitcoin-dev] Version 1 witness programs (first draft)

Just a simple suggestion since the signature format is changed. Can this be designed so that possible future hard forks can simply change 1 constant in the code and turn on cross chain replay protection? On Sun, Oct 1, 2017 at 1:05 PM Mark Friedenbach via bitcoin-dev <