02:49 < Lightsword> luke-jr, think you can rebase #7533?

02:49 < gribble> https://github.com/bitcoin/bitcoin/issues/7533 | RPC: sendrawtransaction: Allow the user to ignore/override specific rejections by luke-jr · Pull Request #7533 · bitcoin/bitcoin · GitHub

02:58 < luke-jr> Lightsword: I can, if there's reason to.

02:58 < Lightsword> luke-jr, would be nice to have for 0.14 if possible

02:59 < luke-jr> yes

03:00 < gmaxwell> luke-jr: it would be more useful if it interacted with mempool saving in a productive way.

03:00 < luke-jr> gmaxwell: ?

03:01 < gmaxwell> well IIRC the only real justification for that change is to bypass policy (though probably not non-mandatory script verify flags) to poke things into your mempool.

03:01 < gmaxwell> But those things wouldn't be restored after restart.

03:02 < luke-jr> so basically just have mempool loading ignore all policy somehow?

03:03 < gmaxwell> Or save the fact that particular transaction bypassed it.

03:06 < Lightsword> yeah, you would probably only want to bypass mempool loading for those that bypassed with sendrawtransaction since that feature is mostly useful for miners wanting to bypass policy without having to patch core

03:06 < luke-jr> mempool.dat format doesn't look very extensible :x

03:07 < gmaxwell> luke-jr: it's versioned.

03:09 < gmaxwell> https://github.com/bitcoin/bitcoin/issues/9103 < already have one requested extension with an issue

03:12 < Lightsword> gmaxwell, wouldn’t it make more sense rather than saving minfee to just load all then evict those that don’t match policy? is the priority for manual prioritizations set currently there?

03:13 < Lightsword> then maybe extend that to have policy bypass flags

03:14 < Lightsword> my thoughts are that configs that affect mempoolminfee are often changed across restarts

03:22 < gmaxwell> Lightsword: minfee is additional state. imagine your mempool is full. Then a block arives that clears out 1MB of it. Your minfee doesn't instantly drop to zero (or the configured relay minfee)-- that would be dumb, because if it doesn't change at all it's likely newly arriving transactions will fill up the mempool again in short order.

03:22 < gmaxwell> so instead it decays back to the minimum at a rate that depends on how empty the mempool is.

03:23 < gmaxwell> part of the point of the mempool saving is so that your node isn't in a highly irregular state right after start.

05:09 < jcorgan> /cl

06:07 < bitcoin-git> [bitcoin] luke-jr opened pull request #9422: Refactor mempool.dat to be extensible, and store missing info (master...mempool_dat_extensible) https://github.com/bitcoin/bitcoin/pull/9422

17:20 < bitcoin-git> [bitcoin] rebroad closed pull request #9030: Don't process blocktxns when we have the block already. (master...BlocktxnExits) https://github.com/bitcoin/bitcoin/pull/9030

20:09 < achow101> any plans for an rc2?

20:12 < gmaxwell> hasn't been a deed for one. only thing missed was the version bump, but I think wladimir said that if that was all, we wouldn't do another rc.

20:33 < bitcoin-git> [bitcoin] gmaxwell opened pull request #9424: Change LogAcceptCategory to use uint32_t rather than sets of strings. (master...log_category_simplify) https://github.com/bitcoin/bitcoin/pull/9424

20:33 < luke-jr> probably makes sense to put off rc2/final until after Christmas, since testing is likely reduced in the meantime?