+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
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
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
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
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
