< GitHub144> [bitcoin] pstratem opened pull request #8061: [Wallet] Improve Wallet encapsulation (master...2016-05-14-wallet-api-cleanup) https://github.com/bitcoin/bitcoin/pull/8061
< gmaxwell> In the past 4 days, these 10 blocks were the only blocks to have very low mempool hitrates (less than 50% in mempool; and over 100 missed txn) with the compact block implementation against nodes that have been running the code for about a month (so mature mempools). I wonder if there is any obvious systemic factor, http://0bin.net/paste/wS81yPcdhPGVDFh-#DW3wgBF6x4YauJqOMBU4c+EdZFSrcnLDYlhgVnJ0e
< gmaxwell> zw
< phantomcircuit> gmaxwell, 6 of those are antpool
< GitHub87> [bitcoin] pstratem closed pull request #7955: [WIP] sync mempool after new block (master...2016-04-26-mempoolsync) https://github.com/bitcoin/bitcoin/pull/7955
< GitHub91> [bitcoin] pstratem opened pull request #8063: Acquire lock to check for genesis block. (master...2015-05-16-lockfix) https://github.com/bitcoin/bitcoin/pull/8063
< spudowiarslave> test
< GitHub172> [bitcoin] sipa closed pull request #7167: Move TestBlockValidity into a background thread (master...TBVBackground) https://github.com/bitcoin/bitcoin/pull/7167
< warren> Hmm, why is -debug=proxy separate from -debug=net? They should probably be merged?
< GitHub137> [bitcoin] gmaxwell opened pull request #8065: Addrman offline attempts (master...addrman_offline_attempts) https://github.com/bitcoin/bitcoin/pull/8065
< GitHub54> [bitcoin] MarcoFalke pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/1f01443567b0...e2bf830bb6c1
< GitHub54> bitcoin/master ac40ed7 error10: Increase timeout waiting for pruned blk00000.dat...
< GitHub54> bitcoin/master fa72f7d MarcoFalke: [doc] Remove outdated line from listunspent RPC help, fix typo
< GitHub54> bitcoin/master fadd048 MarcoFalke: [doc] Link to clang-format in the developer notes
< GitHub58> [bitcoin] MarcoFalke closed pull request #8038: [qa, doc] Various minor fixes (master...Mf1605-trivial12) https://github.com/bitcoin/bitcoin/pull/8038
< GitHub14> [bitcoin] sipa closed pull request #7884: Optimize CScript.FindAndDelete (master...optimize_FindAndDelete) https://github.com/bitcoin/bitcoin/pull/7884
< GitHub130> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e2bf830bb6c1...5c3f8ddcaa11
< GitHub130> bitcoin/master 1475ecf EthanHeilman: Fix de-serialization bug where AddrMan is corrupted after exception...
< GitHub130> bitcoin/master 5c3f8dd Pieter Wuille: Merge #7696: Fix de-serialization bug where AddrMan is left corrupted...
< GitHub129> [bitcoin] sipa closed pull request #7696: Fix de-serialization bug where AddrMan is left corrupted (master...bug) https://github.com/bitcoin/bitcoin/pull/7696
< petertodd> anyone know of some up-to-date UTXO age distribution graphs? (or better yet, UTXO priority distribution graphs)
< GitHub50> [bitcoin] MarcoFalke opened pull request #8066: [qa] test_framework: Use different rpc_auth_pair for each node (master...Mf1605-qaAuthPairDiff) https://github.com/bitcoin/bitcoin/pull/8066
< BlueMatt> sipa: re: std::unordered_map hasher creation: funny, I cant find any references to it online :(
< sipa> BlueMatt: it follows from type generality :)
< sipa> BlueMatt: you can pass in a hasher type that has no no-arg constructor
< sipa> so unordered_map cannot construct it on its own
< sipa> so you need to pass it in
< BlueMatt> wait, how does that work? when passing it in as a class reference unordered_map has to be able to create it somehow?
< sipa> explicit unordered_map( size_type bucket_count, const Hash& hash = Hash(), const KeyEqual& equal = KeyEqual(), const Allocator& alloc = Allocator() );
< sipa> is the constructor
< BlueMatt> ohhhh, oops, yea, missed that
< Chris_Stewart_5> Question about BIP113, if I have a locktime transaction I need the locktime on that tx to be < the median block timestamp for the last 11 blocks correct?
< gmaxwell> Jeff Garzik is attacking the project's work again, https://twitter.com/jgarzik/status/732648223823695874
< gmaxwell> I think it's doubtful that he's ever thought about the deployment implications of SW as a hardfork, having actually done it in elements alpha and found it barely workable there-- because doing it the HF way so throughly destroys all software compatiblity-- I continue to be surprised at the level of ignorance displayed here.
< gmaxwell> I'm also disappointed to see yet another transparently political move-- which is all I could characterize someone clammering to halt segwit when it's relatively uncontroversial (except emong those trying to use the lack of it as a wedge to force other rule changes onto the network, like Jeff.)-- while at the same time he supported (and continues to support) trying to force a hardfork onto the sy
< gmaxwell> stem using a much lower criteria of 75% hashpower.
< gmaxwell> I've been contacting Jeff for months in private raising my concerns about his unproductive tyrades-- seemingly motivated by creating drama to bring attention to his business-- while he continues to contribute no ongoing technical work the the bitcoin ecosystem. Most of my emails have gone unresponded or not meaningfully responded.
< gmaxwell> https://twitter.com/jgarzik/status/729511340008611840 last week Jeff was offering his Bloq company as a provider for "segwit roadmap with dates"; at the time I thought it was inexplicable considering AFAIK no one with Bloq has been contributing to segwit development/testing at all. With today's comment it seems like it was an request for proposal for payment to attack and delay segwit.
< gmaxwell> and saw the "Editors note: Shortly before publication, Bitcoin Core developers pointed out that an RBF-notification might be added soon, after all." and was confused by that.
< gmaxwell> Whats the context? I think based on petertodd's measurements saying that a subset of transactions are replacable would be misleading. All unconfirmed transactions a fairly reliably replacable.
< btcdrak> gmaxwell: AaronvanW (the author) is in here.
< AaronvanW> that's what jonasschnelli told me
< AaronvanW> unless I misunderstood
< AaronvanW> also in this channel iirx
< AaronvanW> iirc
< AaronvanW> yesterday
< AaronvanW> (I don't think I misunderstood)
< instagibbs> s/RBF-notification/bip-125 replaceable notification/
< instagibbs> it's a bit of a mouthful though
< instagibbs> RBF-signaling, perhaps
< btcdrak> aaronvanw: gmaxwell: There is a PR open for it https://github.com/bitcoin/bitcoin/pull/7817
< TD-Linux> it's kind of hard to convey "you shouldn't accept this yet" vs "you REALLY shouldn't accept this yet"
< luke-jr> petertodd: your NACK there is IMO incomplete. in theory, if you + others sign an outgoing tx (eg, CoinJoin), it can still be double-spent by those others
< luke-jr> AaronvanW: probably should stress the "might" there. I don't think such notification will get sufficient agreement to merge.
< gmaxwell> AaronvanW: oh, I'm not suggesting that you had anything wrong.
< gmaxwell> AaronvanW: only perhaps that someone responded to you without having discussed it or thought it through.
< gmaxwell> aaronvanw: at least the form shown in the example of another wallet with a red warning I'd oppose as materially misleading and likely to result in funds loss.