< razor948> ┬┬─┐┌─┐ ┌─┐┬ ┬┌─┐┌─┐┬─┐┌┐┌┌─┐┌┬┐┌─┐ ┌─┐┬─┐┌─┐
< razor948> ┬┬─┐┌─┐ ┌─┐┬ ┬┌─┐┌─┐┬─┐┌┐┌┌─┐┌┬┐┌─┐ ┌─┐┬─┐┌─┐
< razor948> ┬┬─┐┌─┐ ┌─┐┬ ┬┌─┐┌─┐┬─┐┌┐┌┌─┐┌┬┐┌─┐ ┌─┐┬─┐┌─┐
< razor948> ┬┬─┐┌─┐ ┌─┐┬ ┬┌─┐┌─┐┬─┐┌┐┌┌─┐┌┬┐┌─┐ ┌─┐┬─┐┌─┐
< razor948> │├┬┘│ └─┐│ │├─┘├┤ ├┬┘│││├┤ │ └─┐ │ │├┬┘│ ┬
< razor948> │├┬┘│ └─┐│ │├─┘├┤ ├┬┘│││├┤ │ └─┐ │ │├┬┘│ ┬
< razor948> │├┬┘│ └─┐│ │├─┘├┤ ├┬┘│││├┤ │ └─┐ │ │├┬┘│ ┬
< razor948> │├┬┘│ └─┐│ │├─┘├┤ ├┬┘│││├┤ │ └─┐ │ │├┬┘│ ┬
< razor948> ┴┴└─└─┘o└─┘└─┘┴ └─┘┴└─┘└┘└─┘ ┴ └─┘o└─┘┴└─└─┘
< razor948> ┴┴└─└─┘o└─┘└─┘┴ └─┘┴└─┘└┘└─┘ ┴ └─┘o└─┘┴└─└─┘
< razor948> ┴┴└─└─┘o└─┘└─┘┴ └─┘┴└─┘└┘└─┘ ┴ └─┘o└─┘┴└─└─┘
< razor948> ┴┴└─└─┘o└─┘└─┘┴ └─┘┴└─┘└┘└─┘ ┴ └─┘o└─┘┴└─└─┘
< razor948> rex_4539 eklitzke mmgen dlb76 ohnx Victorsueca intcat goatpig Sinclair6 arubi grafcaps DarylSharp dgy_ tryphe Randolf shesek Emcy meshcollider dcousens Arise2 mirese Evel-Knievel ghost43 Cory mandric DrFeelGood justanotheruser gmaxwell droark spinza unholymachine lnostdal boblee ludens[m] Masaomi[m] ajtowns[m] kewde[m] herzmeister[m] cncr04s Scrat Apocalyptic NielsvG bordeaux_facile_ Varunram Muis dagurval mariorz jnewbery mlz punch rockhouse Bas
< meshcollider> not this again -_-
< wumpus> yeah...
< aj> at least it's not in colour?
< wumpus> can anyone, that uses bitcoin-tx, comment on https://github.com/bitcoin/bitcoin/pull/10694?
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/fe53d5f3636a...79313d2e2040
< bitcoin-git> bitcoin/master a8b5d20 Sjors Provoost: Reset pblocktree before deleting LevelDB file
< bitcoin-git> bitcoin/master 79313d2 Wladimir J. van der Laan: Merge #12401: Reset pblocktree before deleting LevelDB file...
< bitcoin-git> [bitcoin] laanwj closed pull request #12401: Reset pblocktree before deleting LevelDB file (master...2018/02/reset-pblocktree) https://github.com/bitcoin/bitcoin/pull/12401
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/79313d2e2040...a8cbbdb07a59
< bitcoin-git> bitcoin/master c4af738 Matt Corallo: Fix ignoring tx data requests when fPauseSend is set on a peer...
< bitcoin-git> bitcoin/master a8cbbdb Wladimir J. van der Laan: Merge #12392: Fix ignoring tx data requests when fPauseSend is set on a peer...
< bitcoin-git> [bitcoin] laanwj closed pull request #12392: Fix ignoring tx data requests when fPauseSend is set on a peer (master...2018-02-fix-fpausesend-getdata-resp) https://github.com/bitcoin/bitcoin/pull/12392
< jonasschnelli> rc4?
< wumpus> maybe...
< wumpus> might be too soon
< jonasschnelli> maybe wait for other report, right.
< jonasschnelli> *reports
< wumpus> if you release too many rcs in short succession the number of testers will likely drop; I've already seen the first "I'll test next weekend when rc n+1 is out"
< wumpus> so let's keep it to 1 per week
< wumpus> going to do the backports already so people on the 0.16 branch can test
< jonasschnelli> Makes sense.
< gmaxwell> wumpus: though perhaps the things that would be in rc3 should ... nevermind you got it. :P
< * gmaxwell> will test as soon as the backports are merged.
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to 0.16: https://github.com/bitcoin/bitcoin/compare/a5e3d44cc8f6...0f616517e1f2
< bitcoin-git> bitcoin/0.16 d44cd7e Sjors Provoost: Reset pblocktree before deleting LevelDB file...
< bitcoin-git> bitcoin/0.16 0f61651 Matt Corallo: Fix ignoring tx data requests when fPauseSend is set on a peer...
< wumpus> gmaxwell: ^^
< gmaxwell> oh lol I was already running with those two patches.
< bitcoin-git> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/a8cbbdb07a59...0dfc25f82a01
< bitcoin-git> bitcoin/master f26866b Cory Fields: boost: drop boost threads for upnp
< bitcoin-git> bitcoin/master ba91724 Cory Fields: boost: remove useless threadGroup parameter from Discover
< bitcoin-git> bitcoin/master 0827267 Cory Fields: boost: drop boost threads from torcontrol
< wumpus> heh
< bitcoin-git> [bitcoin] laanwj closed pull request #12381: Remove more boost threads (master...boost-threads-again) https://github.com/bitcoin/bitcoin/pull/12381
< Randolf> Maybe #12393 is an easy one to close?
< gribble> https://github.com/bitcoin/bitcoin/issues/12393 | Fix a-vs-an typos by practicalswift · Pull Request #12393 · bitcoin/bitcoin · GitHub
< Randolf> Merge?
< Randolf> Simple documentation fixes.
< Randolf> Not a high priority.
< gmaxwell> Randolf: it has pending requested changes by reviewers.
< wumpus> documentation is high priority unless. yeah, this is only typos
< Randolf> gmaxwell: Okay. Is there a place where one can see what's in the "pending requested changes by reviewers" list? Or is the fact that they're open already implying that?
< gmaxwell> Randolf: look at the last comments on it.
< gmaxwell> oh I misread, sorry!
< Randolf> I see "utACK" from luke-jr.
< gmaxwell> (I thought the last comment was asking to remove that change, and I saw no commits after it)
< Randolf> My curiosity on this is motivated by my desire to gain a better understanding of how this all works.
< Randolf> (So far, the process overall seems to be well organized and efficient.)
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/0dfc25f82a01...108af52ef75a
< bitcoin-git> bitcoin/master 11376b5 practicalswift: Fix a-vs-an typos
< bitcoin-git> bitcoin/master 108af52 Wladimir J. van der Laan: Merge #12393: Fix a-vs-an typos...
< bitcoin-git> [bitcoin] laanwj closed pull request #12393: Fix a-vs-an typos (master...a-vs-an-typos) https://github.com/bitcoin/bitcoin/pull/12393
< Randolf> wumpus: I agree.
< wumpus> Randolf: cool, someone finally agrees with me for once, mind if I save the quote? :)
< Sentineo> :D
< Randolf> wumpus: Yes, I have no objections to being quoted. (My full name is Randolf Richardson.)
< wumpus> Randolf: woohoo!
< Randolf> wumpus: I'm a big fan of writing documentation before coding. I do this with all the software that I write.
< Randolf> wumpus: It sure makes maintenance easier later on.
< wumpus> Randolf: yup; it's good to have a background idea why something was done; and the most important thing is correct documentation, comments that are deceiving and don't match the code are worse than having no comments at all
< Randolf> I like comments in code too. Sometimes they are overdone though, so I prefer to have a mixture of per-line comments (for specific things that need it) and an introductory set prior to a number of instructions / lines of code.
< wumpus> I think what is important about code comments is that they explain reasoning, not directly what the code does which is obvious to everyone with knowledge of the programming language
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/108af52ef75a...b4d85490f09e
< bitcoin-git> bitcoin/master faefd29 MarcoFalke: qa: Prepare functional tests for Windows...
< bitcoin-git> bitcoin/master b4d8549 Wladimir J. van der Laan: Merge #11858: qa: Prepare tests for Windows...
< bitcoin-git> [bitcoin] laanwj closed pull request #11858: qa: Prepare tests for Windows (master...Mf1712-qaWinForRealNow) https://github.com/bitcoin/bitcoin/pull/11858
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b4d85490f09e...c8b54b2044db
< bitcoin-git> bitcoin/master a25cb0f murrayn: Use ptrdiff_t type to more precisely indicate usage and avoid compiler warnings.
< bitcoin-git> bitcoin/master c8b54b2 Wladimir J. van der Laan: Merge #12351: Libraries: Use correct type ; avoid compiler warnings....
< bitcoin-git> [bitcoin] laanwj closed pull request #12351: Libraries: Use correct type ; avoid compiler warnings. (master...ptrdiff_t) https://github.com/bitcoin/bitcoin/pull/12351
< bitcoin-git> [bitcoin] jonasschnelli pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/c8b54b2044db...8e6f9f4ebc74
< bitcoin-git> bitcoin/master 718f05c Gregory Sanders: move more bumpfee prechecks to feebumper::PreconditionChecks
< bitcoin-git> bitcoin/master faca18d MarcoFalke: feebumper: Use PreconditionChecks to determine bump eligibility
< bitcoin-git> bitcoin/master 8e6f9f4 Jonas Schnelli: Merge #12296: wallet: Only fee-bump non-conflicted/non-confirmed txes...
< bitcoin-git> [bitcoin] jonasschnelli closed pull request #12296: wallet: Only fee-bump non-conflicted/non-confirmed txes (master...Mf1801-walletFeeBumpNoConf) https://github.com/bitcoin/bitcoin/pull/12296
< provoostenator> In at least some cases the reference code is more clear than the BIP it implements, thanks to an abundance of comments.
< bitcoin-git> [bitcoin] laanwj closed pull request #12023: update the OpenBSD build guide (master...openbsd) https://github.com/bitcoin/bitcoin/pull/12023
< promag> is it valid or not to have the on scriptpubkey duplicated?
< wumpus> provoostenator: that's a good thing, yes :)
< promag> *the same
< gmaxwell> the same scriptpubkey duplicated where?
< gmaxwell> promag: are you asking if a transaction can have multiple outputs using the same scriptpubkey?
< promag> yes, sorry if it was't clear
< gmaxwell> If so, thats valid in the consensus rules, though bitcoin core's wallet (and I assume most other wallets) won't produce it.
< gmaxwell> (e.g. if you do a sendmany with repeated outputs it just merges them)
< murrayn> sipa, I get that. But where's the bottleneck? I could see if one cpu was pegged. Or disk IO. But nothing seems to be happening. It's just slow.
< bitcoin-git> [bitcoin] laanwj closed pull request #11790: Add pixmaps for testnet and regtest (master...pixmaps) https://github.com/bitcoin/bitcoin/pull/11790
< promag> gmaxwell: well fundrawtransaction allows a change address to be one of the outputs
< promag> gmaxwell: should probably check that?
< wumpus> sounds like an edge case that might be checked, yes. Not because it would be invalid, but because it 100% sure means someone made amistake.
< promag> maybe 99%
< promag> :P
< wumpus> I can't think of any reason why it wouldn't be
< promag> like a stupid coin split to same address
< wumpus> I see no point to doing that
< promag> anyway, should we bother to check that on these raw rpc?
< wumpus> esp. after #12257, when the coin selection is changed so that all coins sent to a certain destination will always be spent at once
< 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
< promag> wumpus: should the check be in fundrawtransaction or CWallet::CreateTransaction?
< wumpus> probably in CreateTransaction if you want to catch all cases where this is a possibility
< wumpus> e.g. otherwise you could still do the same trick from the GUI with coincontrol?
< sipa> murrayn: usually it's RAM and disk access that's the bottleneck
< murrayn> sipa I can confirm that it's neither for me. I am running dbcache 2048 and disk IO is not a factor.
< sipa> what are you observing?
< murrayn> what do you mean?
< sipa> what do you see, what do you expect to see
< murrayn> like i said i could understand if one cpu was pegged. i have a quad core processor
< murrayn> there is no heavy disk i/o
< sipa> well is it making progress?
< murrayn> it moves forward, like time itself
< sipa> is it validating blocks?
< murrayn> yes!
< sipa> what's in debug.log?
< murrayn> but if i have the hardware, why not do it quicker? i'm waiting dammit!
< gmaxwell> murrayn: bitcoin it takes hours to sync even on the fastest hardware available, its doing a tremendous amount of work.
< gmaxwell> when you say 'disk IO is not a factor' -- this isn't particularly convincing. IOwait often doesn't look like high usage.
< phantomcircuit> gmaxwell, i do experience stang performance things doing IBD over the network where there isn't any obvious bottleneck
< phantomcircuit> (vm with fsync off)
< sipa> with dbcache 2048 i would expect 100% cpu usage on one core though
< sipa> for extended periods of time between flushes
< echeveria> it comes across to me as sort of bursty for no real reason.
< wumpus> I'm missing the context, but if it doesn't max out your CPUs, don't you happen to have bad peers so it's waiting for blocks?
< phantomcircuit> wumpus, yes
< echeveria> wumpus: even when directly connected to a single peer on a 200Mbit line, I've seen that.
< wumpus> in the latter stages of synchronization it will generally use all cores at 100% where it can, in my experience
< murrayn> that's the tail of debug.log
< phantomcircuit> iirc there is supposed to be logic to handle that but it doesn't seem to work great
< phantomcircuit> but it works well enough that i haven't looked carefully
< sipa> murrayn: can you show a bit more?
< murrayn> sure, how much?
< sipa> a page
< gmaxwell> stalling peers is certantly a thing, the functionality to deal with that is "simplest thing necessary to avoid totally failing" grade.
< gmaxwell> murrayn: are you doing this sync on a computer you physically have or AWS or what?
< wumpus> gmaxwell: indeed
< murrayn> gmaxwell, my desktop
< echeveria> 2018-02-12 11:06:21 version handshake timeout from 476
< echeveria> 2018-02-12 11:06:24 version handshake timeout from 477
< echeveria> that's fun.
< echeveria> it's in my log a bunch too but I've never been able to work out a pattern in it.
< sipa> murrayn: you may want to run with -debug=bench of you want to figure out what it's spending time on
< sipa> but it may just be shitty peers
< sipa> that don't give you blocks fast enough for you to process
< murrayn> well i'm afraid to start over!
< sipa> it won't
< murrayn> "only" 1 year 16 weeks behind
< sipa> if you shutdown cleanly it will continue where it left off
< murrayn> ok sipa i will try
< gmaxwell> These logs look pretty normal.
< gmaxwell> other than it being a bit slow.
< murrayn> just to add some background this is running with -reindex-chainstate because i already had all the blocks downloaded
< sipa> oh
< gmaxwell> see now all these peer theories go out the window.
< sipa> well, then it's not due to slow peers
< murrayn> no
< sipa> but in any case, don't run with -reindex-chainstate the second time or it will start over again
< murrayn> my initial sync took 10 days which i thought was crazy
< sipa> but you can shutdown and it will continue the reindex
< gmaxwell> murrayn: what OS and what version of the software is this?
< murrayn> win7, 0.15.1
< gmaxwell> some anti-virus can absurdly slow down sync.
< murrayn> n/a
< gmaxwell> wumpus: why are you running -reindex-chainstate?
< murrayn> gmaxwell, do you mean me?
< gmaxwell> lol yes
< murrayn> ok
< murrayn> i moved the datadir to a new disk
< gmaxwell> would it happen to be a USB hard drive?
< murrayn> and when i restarted bitcoin-qt it did it's thing
< murrayn> gmaxwell, no
< phantomcircuit> murrayn, that looks like io issues
< phantomcircuit> there's 2-3 seconds between blocks
< phantomcircuit> it's not bursty
< murrayn> i would be glad to see 2-3s/block
< murrayn> phantomcircuit, it's just not IO. these aren't slow drives
< murrayn> i would hear them!
< bitcoin-git> [bitcoin] promag opened pull request #12415: Interrupt loading thread after shutdown request (master...2018-02-shutdown) https://github.com/bitcoin/bitcoin/pull/12415
< gmaxwell> hear them?
< murrayn> i do see memory use climb up to 2G+, but then it drops down and starts the cycle again
< * gmaxwell> waits to hear that he's using a shingled spinning disk...
< murrayn> it's under 1G now
< gmaxwell> murrayn: yes when the cache fills it flushes.
< murrayn> yeah, makes sense
< gmaxwell> The name cache is largely a misnomer, the main useful thing the cache does during sync is act as a buffer to prevent spent outputs from ever hitting the database.
< gmaxwell> it caches too, but that function doesn't do much for performance.
< gmaxwell> (during sync)
< murrayn> ok, well i'm using -dbcache=2048
< murrayn> just out of curiosity, when is the last time any of you guys in this conversation started a new datadir
< murrayn> i'm willing to believe it's some issue with the windows build, and willing to try to track it down.
< gmaxwell> murrayn: several times a month.
< murrayn> ok, thought so
< gmaxwell> murrayn: it's not an issue with the 'windows build' people have reported couple hour syncs in windows with 0.15.x
< murrayn> gmaxwell, from the network?
< gmaxwell> murrayn: yes, and reindexes.
< murrayn> well in any case i would like to help track it down. from what I read I'm not alone.
< gmaxwell> in your case either you finished syncing from blocks on disk and started pulling from the network and your slower due to peers/network.. or your IO is just super high latency on your system.
< gmaxwell> murrayn: sipa asked you earlier to turn up bench debugging.
< gmaxwell> murrayn: you can turn them on without restarting dunno why he didn't suggest that.
< murrayn> gmaxwell, yeah but i don't want to restart and lose over two days of "progress"
< murrayn> oh ok
< gmaxwell> you won't lose progress.
< gmaxwell> regardless, it'll continue from where it is.
< gmaxwell> use the logging rpc/cli command to enable bench and net
< murrayn> can you give me a tldr?
< murrayn> the command
< wumpus> I think it's time to move this to #bitcoin
< gmaxwell> murrayn: you're using the gui interface? bring up the debug console and run logging '["bench","net"]'
< murrayn> or console. ok will try
< murrayn> done will report back in a few
< dcousens> wumpus - hope https://github.com/bitcoin/bitcoin/pull/12169#issuecomment-364903510 didn't de-rail, I was genuinely curious and figured it might be useful to others to see a code example
< bitcoin-git> [bitcoin] MarcoFalke pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/8e6f9f4ebc74...5dc00f68c49c
< bitcoin-git> bitcoin/master a570098 MarcoFalke: Squashed 'src/univalue/' changes from 07947ff2da..51d3ab34ba...
< bitcoin-git> bitcoin/master fa1388e MarcoFalke: univalue: Bump subtree
< bitcoin-git> bitcoin/master 91986ed Karel Bilek: scripted-diff: Use UniValue.pushKV instead of push_back(Pair())...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #12193: RPC: Consistently use UniValue.pushKV instead of push_back(Pair()) (karel-3d) (master...Mf1801-univalueDeprecatedPair) https://github.com/bitcoin/bitcoin/pull/12193
< bitcoin-git> [bitcoin] practicalswift opened pull request #12416: Fix Windows build errors introduced in #10498 (master...fix-windows-build) https://github.com/bitcoin/bitcoin/pull/12416
< instagibbs> is someone generating hashes of issues/prs somewhere?
< instagibbs> wumpus, oh i see you linked, nevermind
< wumpus> yes not so much hashes as a full mirror of information available through the API, though of course you can use it to compute hashes: https://github.com/zw/bitcoin-gh-meta
< qttmyth88> Hello, Is there a precaution to sending a request through bitcoin core. What happens if a malware classified me as a fraud because my name doesn't show as the name on the internet provider. Is there away to remove me off that alert?
< provoostenator> How is change_type in coincontrol used? There's no UI for it afaik, but maybe an RPC command?
< provoostenator> Or is coincontrol.h alwasys used even if the user turns off "Enable coin control features"?
< sipa> yes, it's just the interface to pass information to the coin selection algorithm
< polpol> i heard that after 0.16.0 segwit will be used "by default" is that correct?
< sipa> yes
< polpol> that means that segwit usage will be 100% or not necessarily?
< sipa> no, people may be using wallet software other than bitcoin core
< sipa> or may choose to turn it off
< sipa> or may continue to use addresses they created before
< polpol> got it, thank you sipa
< sipa> or may keep spending coins sent to earlier addresses
< michagogo> Does anyone here have any experience in working with Ubuntu packages (backports etc.)?
< instagibbs> provoostenator, yeah coin control is an overloaded term imo. consumers see it as that qt window, Core contributors see it as what sipa said
< provoostenator> Is there a good reason not to just remove that checbox and turn it on by default?
< sipa> which checkbox?
< provoostenator> There's a "Enable Coin Control Features" checkbox in the QT settings.Maybe move Coin Control Features to the bottom of the Send screen, below fees. As long as the basic stuff is at the top, it shouldn't be too intimiating.
< provoostenator> And some sort of Show / Hide toggle in the send screen itself make more sense to me in general.
< sipa> define basic stuff
< provoostenator> Basic stuff: how much, to which address
< sipa> the idea is that most users don't know and shouldn't care about things like coins, inputs, outputs, groupings, ...
< provoostenator> (and label / note)
< provoostenator> The Coin Control Feature at the moment are only Input selection and a custom change address. They can be hidden by default, but I don't need you need a setting to reveal them.
< provoostenator> E.g. there could be Coin Control button next to Add Recipient at the bottom of the screen to toggle that section.
< provoostenator> ryanofsky or someone else: re #11625, I have no idea how to use gdb other than "gdb src/qt/test/test_bitcoin-qt"
< gribble> https://github.com/bitcoin/bitcoin/issues/11625 | Add BitcoinApplication & RPCConsole tests by ryanofsky · Pull Request #11625 · bitcoin/bitcoin · GitHub
< provoostenator> And do I need to use any special configure flags?
< michagogo> Hm
< michagogo> I tried to see if mingw-w64 was easily backportable
< michagogo> And it's not really working, something about dependencies
< michagogo> For all I know it's easy to fix, but I don't actually know ~anything about Ubuntu packaging, so I have no idea how to do more than run the `backportpackage` command :-/
< cfields> sipa: 1day-ago pong.
< instagibbs> fAllowOtherInputs comment seems to be off. "//! If false, allows unselected inputs, but requires all selected inputs be used". But AvailableCoins immediately filters things not on the selected list when list is non-zero
< instagibbs> am I understanding it right
< instagibbs> SelectCoins allows you to use other inputs, but those inputs will never be fed in the normal Available->Select flow
< provoostenator> Gotta love Stack Overflow... "Here's one million ways to fix gdb on OSX...." "Oh by the way, you can use lldb"
< bitcoin-git> [bitcoin] droark opened pull request #12417: [WIP] Delete mac_alias patch (master...master_del_mac_alias) https://github.com/bitcoin/bitcoin/pull/12417
< n1bor> @murrayn how much RAM do you have? I have seen this sort of performance with 4Gig or less of RAM. Put in 8-12 Gig and same machine was 10x faster.
< n1bor> ibd hate to be short of RAM. I think the filesystem cache needs it for leveldb reads?
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5dc00f68c49c...c997f8808256
< bitcoin-git> bitcoin/master f40df29 practicalswift: Fix Windows build errors introduced in #10498...
< bitcoin-git> bitcoin/master c997f88 MarcoFalke: Merge #12416: Fix Windows build errors introduced in #10498...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #12416: Fix Windows build errors introduced in #10498 (master...fix-windows-build) https://github.com/bitcoin/bitcoin/pull/12416
< BlueMatt> ugh, duh
< BlueMatt> #12367 only fixed the issue for non-reindex cases (ie where LoadChainTip gets called)...any other cases will simply happily initialize pcoinsTip on top of an empty chainstate and then expect to have genesis loaded in the ThreadImport
< gribble> https://github.com/bitcoin/bitcoin/issues/12367 | Fix two fast-shutdown bugs by TheBlueMatt · Pull Request #12367 · bitcoin/bitcoin · GitHub
< cfields> grr
< BlueMatt> we could revert to the initial suggestion of #12349 and just short-circuit flushing, but I really hate that
< gribble> https://github.com/bitcoin/bitcoin/issues/12349 | shutdown: fix crash on shutdown with reindex-chainstate by theuni · Pull Request #12349 · bitcoin/bitcoin · GitHub
< BlueMatt> would rather be smarter and not call FlushStateToDisk somehow
< cfields> BlueMatt: yes, I don't like that either. It was really only intended to jump of discussion about where to fix it for real.
< cfields> *jump off
< BlueMatt> I mean looking at the issue I dont really see a way to fix it that I like to begin with :(
< cfields> same, hence the punt :p
< BlueMatt> but should slip it into the next rc :(
< BlueMatt> well I liked my earlier fix...that didnt actually fix it :/
< BlueMatt> I mean the other obvious option is to make it explicit - have some static in validation.cpp/CChainState that just means "ive gotten as far as loading the genesis block, I can flush now"
< cfields> right
< cfields> and don't we already have that, in some form?
< BlueMatt> not afaik.....I mean we just explicitly refuse to finish loading until we've gotten that far
< BlueMatt> Ive gotta run, but I'd say just do something in CChainState that gets set to true the first time we do a DisconnectBlock or ConnectBlock, and refuse to flush until then?
< BlueMatt> should fix the bug without hiding a hack in utxo flushing
< cfields> fHaveGenesis... ?
< BlueMatt> fHaveLoadedGenesis
< BlueMatt> sure
< BlueMatt> set either in LoadChainTip
< BlueMatt> or ConnectBlock
< BlueMatt> I think
< cfields> no i mean, look in init.cpp
< BlueMatt> yea, I know
< BlueMatt> it feels cleaner to duplicate it inside CChainState
< BlueMatt> so that its clearly a validation thing
< BlueMatt> instead of yet more global pollution
< BlueMatt> fHaveGenesis can continue to sit in init as a block-on-me-before-continuing
< BlueMatt> @eklitzke gets the credit for discovery, btw
< * BlueMatt> -> out
< cfields> looking, cya