< bitcoin-git> [bitcoin] ken2812221 opened pull request #13465: Avoid concurrency issue when make multiple target (master...no_parallel) https://github.com/bitcoin/bitcoin/pull/13465
< bitcoin-git> [bitcoin] jnewbery opened pull request #13467: [Tests] Make p2p_segwit easier to debug (master...tidy_up_p2p_segwit) https://github.com/bitcoin/bitcoin/pull/13467
< christos88> im so happy, the client finished the checkup, now its downloading blocks again :)
< bitcoin-git> [bitcoin] kaloudis opened pull request #13468: Trivial: Fix locale typos (master...locale-typos) https://github.com/bitcoin/bitcoin/pull/13468
< bitcoin-git> [bitcoin] fanquake closed pull request #13468: Trivial: Fix locale typos (master...locale-typos) https://github.com/bitcoin/bitcoin/pull/13468
< GitHub85> [bitcoin-detached-sigs] jonasschnelli opened pull request #8: 0.16.1: osx signatures for 0.16.1 (0.16...0.16) https://github.com/bitcoin-core/bitcoin-detached-sigs/pull/8
< bitcoin-git> [bitcoin] Empact closed pull request #13239: [moveonly] Fix CConnman template methods to be fully-defined in net.h (master...net-template-methods) https://github.com/bitcoin/bitcoin/pull/13239
< jonasschnelli> sipa: you may want to review the Bech32X python ref impl. https://github.com/jonasschnelli/Bech32X/blob/master/ref/python/bech32x.py
< jonasschnelli> It's still WIP, I added the HRP handling
< jonasschnelli> Not sure if it should have decode and correct or only correct
< promag> jonasschnelli: can you explain how is the progress calculated in FindScriptPubKey*
< promag> I don't understand lines 42-43
< jonasschnelli> promag: let me check...
< jonasschnelli> promag: hases are stored ordered, ... so we calculate the progress from the hash in relation to 0xFFFF IIRC
< jonasschnelli> Not to 0xFFFF but similar
< promag> jonasschnelli: I think I get it, still it's an approximation right?
< promag> I mean, it's not linear
< jonasschnelli> yes. its approx
< ken2812221> wumpus: Can I add #13426 to High priority for review? The meeting time is 3 am for me.
< gribble> https://github.com/bitcoin/bitcoin/issues/13426 | [bugfix] Add u8path and u8string to fix #13103 by ken2812221 · Pull Request #13426 · bitcoin/bitcoin · GitHub
< instagibbs> was there ever any resolution to the release notes conflict-a-thon
< ken2812221> instagibbs: You can create release-notes-prXXXXX.md to avoid it. Also see #12819
< gribble> https://github.com/bitcoin/bitcoin/issues/12819 | Avoid release-notes.md conflicts · Issue #12819 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] Sjors opened pull request #13470: WIP [bench] CCoinsView(Cache): measure various scenarios (master...2018/06/bench_db_cache) https://github.com/bitcoin/bitcoin/pull/13470
< bitcoin-git> [bitcoin] Sjors closed pull request #12404: Prune more aggressively during IBD (master...2018/02/ibd_prune_extra) https://github.com/bitcoin/bitcoin/pull/12404
< promag> do we lock files?
< sipa> we lock a lockfile
< sipa> perhaps
< jnewbery> promag: what is https://github.com/bitcoin/bitcoin/pull/13111/files#diff-2e3836af182cfb375329c3463ffd91f8R370 suppposed to be doing? It's invoking a method called "unload" which I can't find
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/4a7e64fc8546...cc7cbd756acd
< bitcoin-git> bitcoin/master 86edf4a Gregory Sanders: expose CBlockIndex::nTx in getblock(header)
< bitcoin-git> bitcoin/master cc7cbd7 Wladimir J. van der Laan: Merge #13451: rpc: expose CBlockIndex::nTx in getblock(header)...
< bitcoin-git> [bitcoin] laanwj closed pull request #13451: rpc: expose CBlockIndex::nTx in getblock(header) (master...expose_nTx) https://github.com/bitcoin/bitcoin/pull/13451
< bitcoin-git> [bitcoin] sipa opened pull request #13471: For AVX2 code, also check for AVX, XSAVE, and OS support (master...201806_avxossupport) https://github.com/bitcoin/bitcoin/pull/13471
< kanzure> wom 3
< kanzure> error. hm.
< jonasschnelli> sipa: The polynominal operation in Bech32X requires 256bit bitwise AND operation, right?
< sipa> jonasschnelli: 135 bit XOR
< jonasschnelli> okay.. I see
< sipa> on languages that don't support big integers, split it up in 3 64-bit integers
< jonasschnelli> Yes. Will do
< sipa> what language?
< jonasschnelli> sipa: the python impl. is "done" (draft) https://github.com/jonasschnelli/Bech32X/blob/master/ref/python/bech32x.py ... now working on C
< jonasschnelli> sipa: I guess it makes sense to have a straight decode() _and_ a correct() in case decode fails?
< sipa> jonasschnelli: the correction code is less efficient in realizing there are no errors
< jonasschnelli> okay
< sipa> it could have a short circuit check if all syndromes are 0, and in that case just straight decode
< sipa> (the syn variable, after the "for v" loop)
< jonasschnelli> Okay. That makes sense...
< bitcoin-git> [bitcoin] kristapsk closed pull request #13464: RPC: Allow to specify rescan start timestamp for importaddress, importprivkey and importpubkey (master...rescan-from) https://github.com/bitcoin/bitcoin/pull/13464
< sipa> no need to invoke solver etc in that case
< jonasschnelli> Also, what made me think a bit: dropping a char will not be detected which seems like a likely (error) case
< jonasschnelli> s/detected/corrected
< sipa> huh
< sipa> that should be detected
< gmaxwell> sipa: he means a frameshift, and correction, not detection.
< gmaxwell> i think for these things its useful if the length is explicit and known, so then you can trigger dropped character repair more usefully.
< jonasschnelli> Yes. Length is known,.. but the correction would need to be different
< gmaxwell> yes, there isn't a simple algebraic correction for that, but you can insert a dummy at each position and run the normal correction. I think it's sufficient to know it's possible to do that.
< jonasschnelli> agree
< sipa> i wonder if ability to detect such errors is something we can optimize the code for
< gmaxwell> even placing two characters in a 64 character string is only about 2k possibilities.
< gmaxwell> sipa: I started to write a fancy bech32 hinter with the idea of list decoding out to 3 errors, including searching for patterns of up to a couple drop and inserts, then using that recent data base of password entry error probablities (which include probabilities for dropped, transposed, and inserted characters) and ranking a probablity for each option.
< jonasschnelli> I'm manly worried about that people will think with "it can correct up to X characters", it does include missing chars
< sipa> it's hamming distance, not levenshtein distance :)
< gmaxwell> well it does correct up to missing characters with unknown positions, assuming a sutiable decoder.
< sipa> jonasschnelli: oh, something that i haven't mentioned - that bech32x code can correct up to 14 errors if you know their positions
< sipa> jonasschnelli: which means that if you have explicitly unreadable characters (as opposed to characters that may be wrong), its error correction ability is much stronger
< sipa> this is called erasure, not correction
< gmaxwell> by 'correct up to' sipa means "with no more remaining error detection power"
< sipa> or in general, you can correct with M known erasures and N addition errors in unknown places as long as M+2*N <= 14
< sipa> that's not implemented in that demo
< jonasschnelli> I see...
< sipa> but it's not very hard to do
< sipa> M+2*N < 15 is why this is called a distance 15 code
< gmaxwell> sipa: are those figures really all that useful for this application? e.g. if you can't externally tell that the key is correct (by checking against the blockchain) you can't go safely to that bound, and if you can tell via external information, you can go further.
< sipa> why can't you safely go to that bound?
< gmaxwell> because you can't tell if the result is right or not.
< gmaxwell> if you corrupt 15 characters, but think you have corrupted 14, you'll "recover" something but it'll be the wrong one.
< gmaxwell> Of course, if you can check against the blockchain you're good to go, but in that case in we could go beyond 15 errors.
< sipa> right
< sipa> in practice you always have both, i guess
< sipa> but the without-the-blockchain inner "loop" is much more efficient
< wumpus> meeting time?
< jonasschnelli> jup
< wumpus> #startmeeting
< lightningbot> Meeting started Thu Jun 14 19:00:32 2018 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
< jonasschnelli> hi
< sipa> aye
< wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator
< meshcollider> hi
< cfields> hi
< kanzure> hi.
< meshcollider> Sorry I haven't been around for the last few weeks, swamped with assignments and exams
< achow101> hi
< promag> hi
< wumpus> meshcollider: np!
< wumpus> topic proposals?
< wumpus> #topic high priority for review
< promag> jnewbery: after qt4 is dropped, I'll replace qt connections with the new sintax
< wumpus> currently on the list: #13425 #13111 #13062 #12196 #12136
< achow101> topic proposal: srd fallback coin selection
< gribble> https://github.com/bitcoin/bitcoin/issues/13425 | Moving final scriptSig construction from CombineSignatures to ProduceSignature (PSBT signer logic) by achow101 · Pull Request #13425 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/13111 | Add unloadwallet RPC by promag · Pull Request #13111 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/13062 | Make script interpreter independent from storage type CScript by sipa · Pull Request #13062 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/12196 | Add scantxoutset RPC method by jonasschnelli · Pull Request #12196 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] HashUnlimited opened pull request #13472: [devtools translations] catch invalid specifiers (master...HashUnlimited-translate-1) https://github.com/bitcoin/bitcoin/pull/13472
< gribble> https://github.com/bitcoin/bitcoin/issues/12136 | Implement BIP 174 Partially Signed Bitcoin Transactions serialization and RPCs by achow101 · Pull Request #12136 · bitcoin/bitcoin · GitHub
< wumpus> unloadwallet from promag seems almost ready for merge
< achow101> 12136 can be removed for now
< wumpus> achow101: ok
< achow101> it depends on 13425
< wumpus> dropped
< promag> wumpus: I think so, I have to fix last jnewbery points
< sipa> #13425 is pretty much all of the PSBT internal changes that are needed, excluding serialization and RPCs
< wumpus> it was unfair for you to have two entires on the list, anyway
< gribble> https://github.com/bitcoin/bitcoin/issues/13425 | Moving final scriptSig construction from CombineSignatures to ProduceSignature (PSBT signer logic) by achow101 · Pull Request #13425 · bitcoin/bitcoin · GitHub
< jnewbery> I think since the last change, unloadwallet no longer removes the unloaded wallet from the dropdown menu
< wumpus> (just kidding, no idea how it came that way)
< promag> jnewbery: you are right
< promag> needs signal unload
< wumpus> right
< jnewbery> yep. Seems to work with that method declaration readded
< wumpus> should we add anything to the list this week?
< promag> #13160
< gribble> https://github.com/bitcoin/bitcoin/issues/13160 | wallet: Unlock spent outputs by promag · Pull Request #13160 · bitcoin/bitcoin · GitHub
< wumpus> you already have one
< meshcollider> Lol
< promag> there was a behaviour change since 0,15 iirc, that fixes it
< wumpus> promag: but I agree it needs more attention, FWIW
< promag> it's one line change
< sipa> the high-priority list is for things that block other work
< wumpus> yes
< sipa> not just "this needs attention"
< wumpus> that's what the meeting is for
< wumpus> #action look at #13160
< gribble> https://github.com/bitcoin/bitcoin/issues/13160 | wallet: Unlock spent outputs by promag · Pull Request #13160 · bitcoin/bitcoin · GitHub
< wumpus> other topics?
< meshcollider> I just reviewed it fwiw promag
< wumpus> meshcollider: thanks!
< achow101> <achow101> topic proposal: srd fallback coin selection
< wumpus> #topic srd fallback coin selection (achow101)
< wumpus> srd = Single Random Draw?
< achow101> yes
< wumpus> #13307
< gribble> https://github.com/bitcoin/bitcoin/issues/13307 | Replace coin selection fallback strategy with Single Random Draw by achow101 · Pull Request #13307 · bitcoin/bitcoin · GitHub
< achow101> I think we should discuss instagibbs's point here: https://github.com/bitcoin/bitcoin/pull/13307#discussion_r192899180
< instagibbs> oh, I said something eh
< achow101> the basic point is that in the current coin selection, we prefer exact matches over confirmations. However the current implementation of srd fallback is that we prefer confirmations over exact matches
< instagibbs> altnernating between BnB(Exact match) and then fallback, rather than Bnb of all sorts then fallback
< sipa> so this is a bit of a question on what our coin selection algorithm should prioritize
< achow101> yes
< sipa> confirmed coins, or (immediate) fee
< instagibbs> and privacy
< instagibbs> imo privacy puts it over the top and we should try really hard to do it
< instagibbs> but obviously it's not a slam dunk
< sipa> hmm, unclear how privacy is affect here?
< instagibbs> change-less outputs mess with coin analysis
< instagibbs> to a large degree
< sipa> that's a good point
< sipa> sdaftuar, morcos: present, opinions?
< sipa> gmaxwell: ?
< instagibbs> IIRC we converged on being ok with current behavior, because it breaks the long chains if it works
< achow101> I also did a simulation (so take it with a grain of salt) that showed that the number of utxos with exact match over confirmations was higher than not
< instagibbs> was an intentional design decision
< sipa> what do you mean by "current behaviour"?
< instagibbs> in master
< sipa> master or the SRD PR?
< sipa> ok
< sipa> there is another question here on what the criteria for SRD merge should be
< sipa> because it seems it results in somewhat higher average UTXOs per wallet in simulations
< instagibbs> merge as in code? or?
< achow101> merge as in merge the pr
< instagibbs> ah
< sipa> yes, i'm wondering what our bar for deciding to change tbe logic should be
< achow101> it doesn't seem to perform as well as the current coin selection in master w.r.t mean number of utxos in the wallet in my simulations
< meshcollider> Significantly higher?
< instagibbs> did you try filtering for using only coins lower than target value? using coins with negative effective value?
< achow101> from ~20 utxos to ~90 utxos
< instagibbs> allowing a single negative effective value?
< instagibbs> Core is an extreme UTXO cop currently. I don't think we're going to be able to match it.
< achow101> I have tried filtering for inputs smaller than the target value and doing srd on that. if that fails, srd on all inputs
< achow101> I have also done that but instead of srd on all inputs on failure, choosing the input that is immediately larger than the target value
< sipa> also, these numbers are just for a single simulation, right?
< achow101> yes, those are all for the same scenario
< sipa> on different workloads differents effects may be preswnt
< achow101> I'm running simulations for the other scenarios right now, but that will take a while to finish
< sipa> i guess more to discuss in the PR
< instagibbs> achow101, you can also test not filtering for -EV
< instagibbs> to see how big an effect that is
< achow101> so we could be spending dust?
< instagibbs> Like we do now yes
< achow101> hmm.. ok, I can try that too
< instagibbs> And "allow 1 negative EV output" type logic
< instagibbs> anyways, more to discuss on PR
< sipa> EV filtering is probably the biggest reason for increased UTXO
< MarcoFalke> Sorry for being late, but I'd like to propose #13439 for high priority for review
< instagibbs> "allow 1" might be nice in that you won't blow up way past what is actually sane, while containing the bloat
< gribble> https://github.com/bitcoin/bitcoin/issues/13439 | rpc: Avoid "duplicate" return value for invalid submitblock by TheBlueMatt · Pull Request #13439 · bitcoin/bitcoin · GitHub
< wumpus> MarcoFalke: sure
< MarcoFalke> thx
< wumpus> MarcoFalke: done
< wumpus> any other topics?
< sipa> i have 4 PRs open relating to optimized hardware SHA256... should I combine them into 1, or leave like this?
< wumpus> let me see
< sipa> #13471 #13386 #13442 #13438
< gribble> https://github.com/bitcoin/bitcoin/issues/13471 | For AVX2 code, also check for AVX, XSAVE, and OS support by sipa · Pull Request #13471 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/13386 | SHA256 implementations based on Intel SHA Extensions by sipa · Pull Request #13386 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/13442 | Convert the 1-way SSE4 SHA256 code from asm to intrinsics by sipa · Pull Request #13442 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/13438 | Improve coverage of SHA256 SelfTest code by sipa · Pull Request #13438 · bitcoin/bitcoin · GitHub
< wumpus> it's good for the selftest one to be seperate, I think that one can be merged
< wumpus> I haven't really looked at the other ones yet in detail yet
< cfields> sipa: I have a follow-up PR as well to build a lib-for-each-arch
< sipa> cfields: ah yes
< sipa> i'll leave things like this
< cfields> I figured I'd just wait until everything settled for that one, but let me know if you'd prefer something else
< wumpus> re: 13442, didn't you first say that made things a few % *slower* on 64 bit?
< sipa> wumpus: i made more changes, it's faster now
< wumpus> great, no problems with it anymore then
< sipa> but it's very heavily compiler dependent... rearranging two lines can have 5% effect on speed
< wumpus> seems preferable in every way then
< sipa> or making a constant static
< sipa> how so?
< wumpus> both more readable and faster
< sipa> ah yes, but probably less reliably faster
< sipa> perhaps on clang it's slower
< cfields> sipa: also worth considering (I read this just yesterday), apparently gcc switched the way that 256bit loads are done, somewhere around gcc6, I believe.
< sipa> or with particular gcc versions
< cfields> so, worth considering compiler age as well.
< wumpus> right
< wumpus> if it becomes faster with new compilers it's good
< wumpus> if slower, not :)
< cfields> (see gcc's "mavx256-split-unaligned-load" option, which had its default value changed)
< ryanofsky> cd
< sipa> wumpus: another benefit is that this lets us compile the exact same code with -mavx, and get a slightly faster version for AVX capable machines
< cfields> ~$
< wumpus> sipa: that's really nice
< wumpus> sipa: so we compile it twice, the same code?
< sipa> wumpus: yup
< sipa> cfields is working on build system changes for that
< wumpus> almost for free
< sipa> i wonder what percentage of our binary will be SHA256 implementations...
< wumpus> a very small part
< cfields> heh
< wumpus> though I understand the sentiment :)
< wumpus> as for the source code, a larger part, which reminds me I still need to add ARM
< wumpus> POWER8 one needs review #13203
< gribble> https://github.com/bitcoin/bitcoin/issues/13203 | Add POWER8 ASM for 4-way SHA256 by TheBlueMatt · Pull Request #13203 · bitcoin/bitcoin · GitHub
< sipa> cfields: we should also try with things like -mmovbe, -mbmi1, -mbmi2, ...
< wumpus> that's really an instruction set I have no clue about
< sipa> cfields: i think these may not be implied by -mavx / -mavx2
< sipa> but generally available on the same systems
< cfields> sipa: yes. IIRC bmi provides some useful things.
< cfields> yea, rorx
< cfields> sorry, that's bmi2
< wumpus> I'm lost
< sipa> don't worry :)
< wumpus> :)
< wumpus> any quick topic?
< achow101> when 0.16.1 detached sigs?
< cfields> achow101: soon, building now
< cfields> jonasschnelli: ^^ ping for other half
< jonasschnelli> already made
< wumpus> cfields: jonasschnelli: thanks
< cfields> jonasschnelli: ah, I missed the pr! You beat me to it :)
< jonasschnelli> :-)
< GitHub133> [bitcoin-detached-sigs] laanwj closed pull request #8: 0.16.1: osx signatures for 0.16.1 (0.16...0.16) https://github.com/bitcoin-core/bitcoin-detached-sigs/pull/8
< luke-jr> hi
< wumpus> jonasschnelli: you should probably be able to merge your own stuff there
< jonasschnelli> wumpus: Yes. I did create the PR because I wasn't sure if we did hit the threshold or required non code-signed signatures
< wumpus> right, good point
< luke-jr> well, as soon as the signatures exist, someone could potentially use them
< luke-jr> so if the threshold isn't met, even a PR could be problematic
< wumpus> 5 signers for every platform so that seems ok
< cfields> yea, it'd only be an issue if there were 2 competing "correct" gitian outputs
< wumpus> agree that for a -final relaese it's better to wait for a few more
< cfields> I think that's happened in the past due to timezones
< luke-jr> 5 is fine
< wumpus> cfields: yes, that's worrying
< luke-jr> IIRC threshold was 3 anyway
< wumpus> meeting ending in 1 minute
< wumpus> oh no, now
< wumpus> #endmeeting
< lightningbot> Meeting ended Thu Jun 14 20:00:09 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< jamesob> maybe not meeting-worthy, but something I've been curious about is whether there are other indexes people'd like to see (now that we have this nice framework for building them)
< jamesob> I was thinking address-to-related-txns might be nice
< luke-jr> AFAIK the goal was to move indexes out of Core
< jamesob> I think in some cases there can be a compelling argument for additional opt-in indexes
< jonasschnelli> jamesob: I also started an experimental external indexing daemon: https://github.com/jonasschnelli/bitcoincore-indexd
< wumpus> at least the indexing functionality has been factored to a generic class now
< jamesob> jonasschnelli: cool, I'll take a look
< jonasschnelli> jamesob: I tried to build an address-to-related-txns,... but figured out its a source for general evil things like "central validation". :)
< jamesob> hah
< jonasschnelli> I think using the wallet more for "selective indexing" makes more sense.
< jonasschnelli> But IMO an address-to-related-txns is probably better kept external...
< jamesob> it'd be nice to, e.g., back trezor's web interface with your own bitcoind node instead of a bitcore instance and afaik part of that is because bitcore maintains indexes that bitcoind doesn't
< jonasschnelli> I understand this use case... but indexing everything for this is just silly..
< jonasschnelli> You only want to index a certain xpub or range of keys
< jamesob> yeah, makes sense
< jonasschnelli> The only use case is probably if you want to recover a backup...
< jonasschnelli> But even for that, my new scantxoutset PR makes more sense and works also with pruned peers...
< jonasschnelli> it just can't reproduce the transaction history,... just recover the funds.
< jonasschnelli> For bitcore / Trezor,... I'm pretty sure one can do the same thing belcher did with stratum (his personal electrum server)
< jonasschnelli> Create a bitcoin interface where only a defined set of keys (or xpubs) are indexed.
< jonasschnelli> In the background, you could use a watch-only core wallet for this...
< jonasschnelli> If you don't need backup-recovery, it would work with pruned peers as well
< gmaxwell> instagibbs: I don't think it would be hard to beat bitcoin core in terms of tx out cleanup.
< gmaxwell> For example, if it agressively spent all outputs to a scriptpubkey when it spent from any, it would likely sweep more txouts than the current code, AND improve privacy.
< jamesob> jonasschnelli: interesting, thanks
< instagibbs> gmaxwell, yeah yeah i meant within the constraints of the discussion, but agreed!
< gmaxwell> instagibbs: my thought on it was that we'd offset more txout prolific behavior with explicit txo consuming behavior.
< instagibbs> gotcha
< gmaxwell> the two kinds of extra consuming behavior I know of are (1) grouping by scriptpubkey (which helps privacy), (2) spending more small inputs when fees are low.
< sipa> gmaxwell: #12257
< gribble> https://github.com/bitcoin/bitcoin/issues/12257 | [wallet] Use destination groups instead of coins in coin select by kallewoof · Pull Request #12257 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] TheBlueMatt closed pull request #11604: [net] Remove ForNode/ForEachNode (master...2017-11-no-foreachnode) https://github.com/bitcoin/bitcoin/pull/11604
< bitcoin-git> [bitcoin] TheBlueMatt closed pull request #12138: Track best-possible-headers (master...2017-10-best-header-tracking) https://github.com/bitcoin/bitcoin/pull/12138
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/cc7cbd756acd...1939536eea7a
< bitcoin-git> bitcoin/master fa3d39e MarcoFalke: doc: Remove note to install all boost dev packages
< bitcoin-git> bitcoin/master 1939536 MarcoFalke: Merge #13460: doc: Remove note to install all boost dev packages...
< bitcoin-git> [bitcoin] TheBlueMatt closed pull request #13233: Skip PrecomputedTransactionData hashing for cache hits. (master...2018-05-no-needless-precompute) https://github.com/bitcoin/bitcoin/pull/13233
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #13460: doc: Remove note to install all boost dev packages (master...Mf1806-docBuildUbuntu) https://github.com/bitcoin/bitcoin/pull/13460
< bitcoin-git> [bitcoin] TheBlueMatt closed pull request #11775: Move fee estimator into validationinterface/cscheduler thread (master...2017-09-background-feeest) https://github.com/bitcoin/bitcoin/pull/11775
< bitcoin-git> [bitcoin] TheBlueMatt closed pull request #11856: [RFC] I Have a Hammer! (Replace parts of ui_interface with validationinterface) (master...2017-12-remove-cvblockchange) https://github.com/bitcoin/bitcoin/pull/11856
< bitcoin-git> [bitcoin] TheBlueMatt closed pull request #10984: Allow 2 simultaneous (compact-)block downloads (master...2017-08-paralell-block-downloads) https://github.com/bitcoin/bitcoin/pull/10984
< BlueMatt> phew, now I dont have so many prs to rebase, and none that conflict with each other
< bitcoin-git> [bitcoin] TheBlueMatt closed pull request #11913: Avoid cs_main during ReadBlockFromDisk Calls (master...2017-12-no-readblockfromdisk-csmain) https://github.com/bitcoin/bitcoin/pull/11913
< wumpus> whoa
< BlueMatt> heh, havent had time to rebase anything in a while :(
< BlueMatt> maybe I'll get back to them in a few weeks or so
< promag> \o/ < 270 prs!
< sipa> MarcoFalke: feature request: in the conflict checker, if one PR is just a prefix of another one's commits, don't call it a conflict
< sipa> BlueMatt: :(
< sipa> BlueMatt: oh, some are still open
< BlueMatt> lol ffs, I was just closing stale crap I'm not gonna have a chance to rebase for a month
< BlueMatt> or, more likely, longer
< sipa> okay!
< bitcoin-git> [bitcoin] Empact closed pull request #13462: scripted-diff: Simplify common case of CHashWriter and drop SER_GETHASH & SerializeHash (master...serialize-hash-type) https://github.com/bitcoin/bitcoin/pull/13462
< bitcoin-git> [bitcoin] TheBlueMatt closed pull request #11639: Rewrite the interface between validation and net_processing wrt DoS (master...2017-10-dos-rewrite) https://github.com/bitcoin/bitcoin/pull/11639
< cfields> gitian builders: v0.16.1 detached sigs are pushed
< cfields> achow101: ^^
< wumpus> thanks
< bitcoin-git> [bitcoin] Empact reopened pull request #13462: scripted-diff: Simplify common case of CHashWriter and drop SER_GETHASH & SerializeHash (master...serialize-hash-type) https://github.com/bitcoin/bitcoin/pull/13462
< bitcoin-git> [bitcoin] Empact closed pull request #13462: scripted-diff: Simplify common case of CHashWriter and drop SER_GETHASH & SerializeHash (master...serialize-hash-type) https://github.com/bitcoin/bitcoin/pull/13462