Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup

> (1) It has been well documented again and again that there is desire to > remove OP_CODESEPARATOR, (2) it is well-documented OP_CODESEPARATOR in > non-segwit scripts represents a rather significant vulnerability in Bitcoin > today, and (3) lots of effort has gone into attempting to find prac

[bitcoin-dev] Signet

Hello, As some of you already know, I've been working on a network called "signet", which is bascially a complement to the already existing testnet, except it is completely centralized, and blocks are signed by a specific key rather than using proof of work. Benefits of this: 1. It is more predi

Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup

Replies inline. On 3/8/19 3:57 PM, Russell O'Connor wrote: On Thu, Mar 7, 2019 at 2:50 PM Matt Corallo > wrote: It's very easy to construct a practical script using OP_CODESEPARATOR. IF <2> <2> CHECKMULTISIGVERIFY ELSE CODESEPARATOR CHECKSIGVERFY ENDIF Now

Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup

On Thu, Mar 7, 2019 at 2:50 PM Matt Corallo wrote: > Replies inline. > > Matt > > On 3/7/19 3:03 PM, Russell O'Connor wrote: > > > > * OP_CODESEPARATOR in non-BIP 143 scripts fails the script > validation. > > This includes OP_CODESEPARATORs in unexecuted branches of if > > statements

Re: [bitcoin-dev] Sighash Type Byte; Re: BIP Proposal: The Great Consensus Cleanup

On Thu, Mar 7, 2019 at 2:57 PM Matt Corallo wrote: > I can't say I'm particularly married to this idea (hence the alternate > proposal in the original email), but at the same time the lack of > existing transactions using these bits (and the redundancy thereof - > they don't *do* anything special

Re: [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61)

On Thu, Mar 7, 2019 at 11:46 PM Andreas Schildbach via bitcoin-dev wrote: > First and foremost, reject messages are an indication that the > transaction isn't going to confirm. Without these messages, we'd need to > revert to pre-BIP61 behaviour of using a timeout for reception of > network confir