Re: [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY)

2019-06-03 Thread Russell O'Connor via bitcoin-dev
On Sat, Jun 1, 2019 at 12:47 PM Jeremy via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi All, > > OP_CHECKOUTPUTSHASHVERIFY is retracted in favor of OP_SECURETHEBAG*. > OP_SECURETHEBAG does more or less the same thing, but fixes malleability > issues and lifts the single output

Re: [bitcoin-dev] [PROPOSAL] Emergency RBF (BIP 125)

2019-06-03 Thread Russell O'Connor via bitcoin-dev
Hi Rusty, On Sun, Jun 2, 2019 at 9:21 AM Rusty Russell via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > The new "emergency RBF" rule: > > 6. If the original transaction was not in the first 4,000,000 weight > units of the fee-ordered mempool and the replacement transaction

Re: [bitcoin-dev] [PROPOSAL] Emergency RBF (BIP 125)

2019-06-03 Thread Ryan Havar via bitcoin-dev
+1 From an incentive-compatible point of view, miners should be accepting transactions that increase the amount of fees that can achieved with 4M weight of transactions, so it seems like a pretty sane plan. One common problem I've run into with RBF is since you're using RBF you probably want

Re: [bitcoin-dev] [PROPOSAL] Emergency RBF (BIP 125)

2019-06-03 Thread Matt Corallo via bitcoin-dev
I think this needs significantly improved motivation/description. A few areas I'd like to see calculated out: 1) wrt rule 3, for this to be obviously-incentive-compatible-for-the-next-miner, I'd think no evicted transactions would be allowed to be in the next block range. This would probably

Re: [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY)

2019-06-03 Thread Jeremy via bitcoin-dev
Hi Russell, Thanks for the response. I double checked my work in drafting my response and realized I didn't address all the malleability concerns, I believe I have now (fingers crossed) addressed all points of malleability. *The malleability concerns are as follows:* A TXID is computed as: def