IRC meeting summary for 2016-02-18

Overview

Logs

Main topics

  • feefilter P2P message
  • Reorg performance of SequenceLocks checks

Short topics/notes

Note: The meeting was a short one as some developers were participating in the Bitcoin Roundtable.

Btcdrak suggested arranging open source licenses of the Jetbrains IDEs for C++ and Python. The maintainer (wumpus) needs to apply.

feefilter P2P message

background

The concept of a limited mempool was introduced in Bitcoin Core 0.12 to provide protection against attacks or spam transactions of low fees that are not being mined. Currently there is a reject message which allows informing peers about insufficient fees, but only on per transaction basis. The feefilter message allows a node to inform its peers about the minimum transaction fee rate it is willing to accept so that its peers can skip relaying nonconforming transactions.

meeting comments

Wumpus hasn’t looked at the the fee filter so it will be discussed on the next meeting.

meeting conclusion

Review Implement “feefilter” P2P message #7542

Reorg performance of SequenceLocks checks

background

BIP 68 Consensus-enforced transaction replacement signaled via sequence numbers.

BIP 68 changes the meaning of the previously unused sequence number field to a relative locktime.

SequenceLocks functions are used to evaluate sequence lock times or heights per BIP 68.

Checking sequence locks to determine whether the transaction is valid requires looking up the heights of all its inputs. In a reorg, as it stands now, this will require reevaluating the inputs of every single transaction in the mempool. PR #7187 attempts to cache for each transaction the block hash of the latest block containing an input which had a sequence lock. In the event of a reorg, if that hash is still on the chain, you know the previously calculated height and time (also cached) are still valid. This means that ideally most inputs won’t need to be reevaluated.

meeting comments

There was discussion whether to backport this to 0.12 and 0.11. Due to all the changes to the mempool in 0.12 it will probably be non-trivial to backport that optimization to 0.11, which already is way slower.

meeting conclusion

Review/test Keep reorgs fast for SequenceLocks checks #7187

Participants

wumpus            Wladimir J. van der Laan
morcos            Alex Morcos
btcdrak           btcdrak
paveljanik        Pavel Janik
sdaftuar          Suhas Daftuar
shea256           Ryan Shea

Comic relief

19:08:51 <morcos> is the topic 7187 now?
19:09:22 <wumpus> we dont' have a topic yet :)
19:09:32 * btcdrak makes wumpus a coffee