< 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
< 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?
< 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>
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.
< 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.