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

2019-06-13 Thread Rusty Russell via bitcoin-dev
"David A. Harding" writes: > On Thu, Jun 06, 2019 at 02:46:54PM +0930, Rusty Russell via bitcoin-dev wrote: >> If that's true, I don't think this proposal makes it worse. > > Here's a scenario that I think shows it being at least 20x worse. [ Snip ] Indeed :( To be fair, if I have a transaction

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

2019-06-12 Thread Ryan Havar via bitcoin-dev
What about this? We store a RBU ("relay bandwidth used") with each transaction in the mempool. Where RBU is defined as the size of the transaction + RBU of all transactions it has evicted. For a replacement to be valid: The feerate must be higher than what it's evicting, and the fee must be gre

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

2019-06-09 Thread David A. Harding via bitcoin-dev
On Thu, Jun 06, 2019 at 02:46:54PM +0930, Rusty Russell via bitcoin-dev wrote: > Matt Corallo writes: > > 2) wrt rule 4, I'd like to see a calculation of worst-case free > > relay. I think we're already not in a great place, but maybe it's > > worth it or maybe there is some other way to reduce th

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

2019-06-09 Thread Russell O'Connor via bitcoin-dev
On Sat, Jun 8, 2019 at 11:59 PM Rusty Russell wrote: > "Russell O'Connor" writes: > > 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 transactio

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

2019-06-09 Thread Rusty Russell via bitcoin-dev
Matt Corallo writes: > 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 bl

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

2019-06-09 Thread Rusty Russell via bitcoin-dev
"Russell O'Connor" writes: > 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 m

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 t

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 i

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 r

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

2019-06-02 Thread Rusty Russell via bitcoin-dev
Hi all, I want to propose a modification to rules 3, 4 and 5 of BIP 125: To remind you of BIP 125: 3. The replacement transaction pays an absolute fee of at least the sum paid by the original transactions. 4. The replacement transaction must also pay for its own bandwidth at or