--- Day changed Fri Sep 09 2016
00:02 < jonasschnelli> jl2012: I guess this is kind a strange. It let you define your return value.
00:02 < jonasschnelli> looking at validation.h L45-L48 is looks wrongish
00:03 < jonasschnelli> Meh.. maybe it makes sense like that.
00:04 < jonasschnelli> Calling the DoS function basically allows you to set the return value of that function.
00:04 < luke-jr> it's to avoid 2 lines
00:05 < jl2012> jonasschnelli: it seems it is always set as false. I can't find any example of true
00:07 < jonasschnelli> jl2012: Indeed. I guess the error() function also resolves to false.
00:07 < jonasschnelli> Maybe remove it to increase code readability?
00:07 < jl2012> so it's just some kind of dead code?
00:08 < jonasschnelli> Looks like... though, haven't analyzed it in detail
00:11 < luke-jr> used to have state.DoS(0, error( some places IIRC
00:12 < luke-jr> still do I think
00:16 < luke-jr> wee, reduced pwalletMain references to 42 lines, half in tests
00:17 < luke-jr> why is nWalletUnlockTime not on CWallet?
00:18 < da2ce7> I was thinking that the RPC wallet-calls should include an monochromic increasing nounce:  the only one that I can reliably think of is the 'total blockchain work' statistic.
00:18 < da2ce7> block hash and block hight are both not reliable.
00:19 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
00:21 < da2ce7> then the RPC call should guarantee the return values are correct for at least the total work specified; or respond with the error 'not enough total work'.
00:30 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-ievylziaftuzsbzr] has joined #bitcoin-core-dev
00:31 < luke-jr> da2ce7: eh, block hash is always a specific known amount of work
00:31 < luke-jr> using total work would fail to solve issues for reorgs
00:32 < da2ce7> luke-jr I thought you reorg to the chain that has the 'most total work'.
00:32 < luke-jr> da2ce7: competing chains often have the same work
00:32 < da2ce7> this is important to at times of difficulty adjustment. 
00:33 < luke-jr> two blocks at height X are almost always going to have the same total work
00:37 < da2ce7> except at the case of the edge of a difficulty adjustment?
00:38 < luke-jr> yes
00:38 < luke-jr> or an attack
00:38 < luke-jr> (but not all attacks)
00:40 < da2ce7> well it seems like a thing that we should take account of; then the wallet can give out a stronger consistency guarantee
00:43 < luke-jr> da2ce7: the problem then is that in some cases, you want the RPC call to execute regardless of what block you're at - including the "in between blocks" state
00:45 < da2ce7> luke-jr: then if without specifying the nounce the RPC call should return a statement: "this response is accurate for at least X total work"
00:50 < jonasschnelli> I having a hard time to analyze our main.cpp code how Core is detecting if a peer is not responding to a getheader message... there must be a timeout or something I guess.
01:00 -!- laurentmt [~Thunderbi@80.215.234.210] has joined #bitcoin-core-dev
01:01 < sipa> yes
01:01 -!- laurentmt [~Thunderbi@80.215.234.210] has quit [Client Quit]
01:01 < sipa> search for 'stall'
01:02 < luke-jr> instagibbs: why does removeprunedfunds call ThreadFlushWalletDB? :/
01:02 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye]
01:02 < jonasschnelli> sipa: i searched, but can only link it to block downloads (not to headers)
01:02 < luke-jr> I can't imagine that's right. It will rename the RPC thread!
01:09 < sipa> jonasschnelli: i don't think we have timeouts for headers
01:10 < sipa> but we do ask for headers from multiple peers
01:10 < sipa> so it's less risky
01:10 < gmaxwell> it will continue with a new source once someone else offers it a block.
01:10 < gmaxwell> I was explaining this in #bitcoin two days ago in fact.
01:11 < jonasschnelli> Okay...
01:11 < gmaxwell> as it interacts poorly with the large number of fake nodes out there that just monitor transaction advertisements and don't do anything else.
01:12 < jonasschnelli> we not increase the missbehave score if a node does not response to a getheaders request in an adequate amount of time?
01:13 < jonasschnelli> seems to be the cheapest method to detect fake nodes... though, keeping a headers-chain is probably simple, but I guess most fake nodes are not willing to implement that
01:13 < gmaxwell> that can cause network partioning. just dos attack nodes and peers will ban them.
01:14 < gmaxwell> misbehavior score can't be just handed out like that
01:14 < sipa> i think we should get rid of misbehaviour score
01:14 < gmaxwell> Agreed.
01:14 < sipa> and just have a boolean: bannable offence or not
01:14 < gmaxwell> Right.
01:15 < sipa> i guess there are cases where you disconnect but not ban
01:15 < sipa> but that's more for not wanting to deal with a request, and a courtesy to the peer, so he can find someone else
01:16 < sipa> not for misbehaviour
01:16 < gmaxwell> jonasschnelli: headers should come from all network peers, the only real complication with that is the initial headers sync, which you don't want to do redundantly as its some 40MB of data or so.
01:23 < sipa> yes, there is some logic that does not overeagerly send out headers requests during ibd
01:24 < gmaxwell> thats the only element of headers handling that I've ever seen cause stalls.
01:24 < gmaxwell> and they recover on new blocks, but it does sometimes causes new users to footgun themselves.
01:24 < gmaxwell> e.g. they are syncing and they decide it's slow, so they restart... and the first peer they get is a black hole... and so they sit there not syncing for a bit.. then decide to reindex.
01:26 < GitHub33> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7f8b677aeb79...4daf02a03f9e
01:26 < GitHub33> bitcoin/master 125b946 Pavel Janík: Do not shadow upper local variable 'send', prevent -Wshadow compiler warning.
01:26 < GitHub33> bitcoin/master 4daf02a Wladimir J. van der Laan: Merge #8677: Do not shadow upper local variable 'send', prevent -Wshadow compiler warning....
01:26 < GitHub48> [bitcoin] laanwj closed pull request #8677: Do not shadow upper local variable 'send', prevent -Wshadow compiler warning. (master...20160907_Wshadow_8606) https://github.com/bitcoin/bitcoin/pull/8677
01:26 < Lauda> https://bitcoincore.org/en/lifecycle/
01:26 < Lauda> Needs updating
01:26 < gmaxwell> [20 minutes later] and as they strap their head to a table and start pushing the drill bit into their temple, some don't think that perhaps lobotomizing themselves is too far to go to complete a software install... :P
01:26 < Lauda> Still has "TBA*" on 0.13.0
01:27 < gmaxwell> Lauda: thanks.
01:29 < Lauda> Np.
01:30 < sipa> gmaxwell: also, i believe we still have the bug that after a reindex finishes, we do not actively start asking pers for headers
01:30 < sipa> wait a minute
01:31 < sipa> since the reindex change in 0.13 we already know all headers beforehand
01:31 < sipa> so we could in fact start asking peers for headers after the first stage
01:31 < sipa> and learn about new headers while still reindexing blocms from disk
01:32 < gmaxwell> I don't recall what governs the decision between asking only a single peer vs everyone.
01:34 < sipa> IBD or not, i guess
01:35 < sipa> but this is something else
01:35 < sipa> at startup we pick one peer to actively start asking for headwrs, to bootstrap the sync process
01:35 < sipa> we don't do that during reindex, and not after reindex finishes either
01:43 < gmaxwell> jonasschnelli: re 'detect fake'-- not reasonable to do, they'll just continue to do the bare minimum to not get detected whatever that is. We should focus on being robust (and increasingly so) in the face of abusive peers.
01:45 < jonasschnelli> gmaxwell: Yes. Agree. I haven't tested it,... but somehow I had the assumption a peer that signals NODE_NETWORK not does not respond to getheaders messages will result in stalling IBD (if we have chosen that peer for headers sync during IBD).
01:45 < jonasschnelli> But I guess I'm wrong with that assumption.
01:45 < jonasschnelli> Just couldn't find the corresponding code part that breaks my assumption
01:46 < gmaxwell> it will, until the next block on the network, and then it will select another peer.
01:49 < jonasschnelli> Wouldn't a timeout of lets say 30 secs make sense in this case? If timeout fired, select next node for header-sync
01:49 < sipa> 30s is extremely short
01:49 < jonasschnelli> for a headers message after a getheaders? Why short?
01:49 < sipa> it's trivial to dos a peer to make them unresponsive for 30s
01:50 < jonasschnelli> Would you care switching to the next header sync peer in case your DOSed?
01:50 < gmaxwell> and it also means you couldn't use bitcoin anymore on a connection of less than about 50kbit/sec which, otherwise, could keep up with the chain.
01:50 < sipa> during IBD that's fine
01:51 < gmaxwell> (as the first header response will be 160kb of data, 30 second timeout means the minimum usable bandwidth around 50kbit/sec.
01:51 < jonasschnelli> Yes. The bandwith / timeout problems still appears...
01:52 < gmaxwell> even just switching that fast would mean that a host with borderline bandwith you would livelock requesting the same data over again and changing peers.
01:52 < luke-jr> I have a peer right now ping wait over 300s
01:52 < gmaxwell> luke-jr: that one is probably not actually working.
01:52 < gmaxwell> though I do frequently have working peers with rather high pingtimes.
01:52 < luke-jr> gmaxwell: it's responded to pings before?
01:52 < luke-jr> connected 3 hours, last ping time 227s
01:52 < gmaxwell> luke-jr: I mean it's probably fallen off the network.
01:52 < luke-jr> hm
01:53 < luke-jr> debug window claims it's got the best block
01:55 < gmaxwell>     "minping": 21.978129,
01:55 < GitHub91> [bitcoin] luke-jr opened pull request #8687: Bugfix: RPC/Wallet: removeprunedfunds should flush the wallet db (master...bugfix_removeprunedfunds) https://github.com/bitcoin/bitcoin/pull/8687
02:00 < jl2012> https://github.com/bitcoin/bitcoin/blob/a6a860796a44a2805a58391a009ba22752f64e32/src/secp256k1/src/eckey_impl.h#L17
02:00 < gmaxwell> I wish we could control the number of headers retured by getheaders in that initial case... as the obvious thing to do is request a tiny amount from every peer. Then pick among the responses, and keep doubling the request size, requesting from a single peer, so long as the replies are sufficiently fast. Then a short timeout would be fine.
02:00 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev
02:01 < gmaxwell> jl2012: yes, thats an internal function in libsecp256k1. 
02:01 < jl2012> ^ sipa: if the pubkey does not pass this test, the verify must return 0?
02:03 < gmaxwell> jl2012: a pubkey that fails that test will never result in a passing signature validation.
02:07 < sipa> jl2012: if that functioms returns 1 there always exists some valid signature/message pairs
02:08 < sipa> jl2iif it returns 0, no signature can verify
02:30 < jl2012> so P2WPKH has an implicit requirement for key size 
02:31 < jl2012> pub[0] == 0x06 || pub[0] == 0x07 are so called "hybrid key"?
02:32 < sipa> yup
02:32 < sipa> afaik, never used on mainnet
02:33 < jl2012> should we make keys not 33 bytes non standard in segwit?
02:34 < sipa> i don't think there is any reason not to
02:34 < sipa> but that should be communicated
02:35 < jl2012> i'll post it the ML with all other segwit standard limits
02:35 < sipa> great
02:36 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 244 seconds]
02:36 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
02:50 -!- vega4 [~JBouncer@static.88-198-5-245.clients.your-server.de] has joined #bitcoin-core-dev
02:52 < GitHub123> [bitcoin] laanwj pushed 34 new commits to master: https://github.com/bitcoin/bitcoin/compare/4daf02a03f9e...6423116741de
02:52 < GitHub123> bitcoin/master 531214f Cory Fields: gui: add NodeID to the peer table
02:52 < GitHub123> bitcoin/master d93b14d Cory Fields: net: move CBanDB and CAddrDB out of net.h/cpp...
02:52 < GitHub123> bitcoin/master cd16f48 Cory Fields: net: Create CConnman to encapsulate p2p connections
02:52 < GitHub100> [bitcoin] laanwj closed pull request #8085: p2p: Begin encapsulation (master...net-refactor13) https://github.com/bitcoin/bitcoin/pull/8085
02:53 < sipa> \o/
02:53 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev
03:01 < GitHub198> [bitcoin] laanwj closed pull request #8679: [0.13] Various backports (0.13...backports_0.13) https://github.com/bitcoin/bitcoin/pull/8679
03:01 < GitHub48> [bitcoin] laanwj pushed 13 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/122fdfdae915...32269449185d
03:01 < GitHub48> bitcoin/0.13 75f2065 Wladimir J. van der Laan: build: Remove check for `openssl/ec.h`...
03:01 < GitHub48> bitcoin/0.13 1db3352 Wladimir J. van der Laan: qt: Fix random segfault when closing "Choose data directory" dialog...
03:01 < GitHub48> bitcoin/0.13 2611ad7 Ethan Heilman: Added feeler connections increasing good addrs in the tried table....
03:05 < GitHub90> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/a9429ca26dd8f4555def2dc8bd8ea7fc4e32fce6
03:05 < GitHub90> bitcoin/0.13 a9429ca Pieter Wuille: Reduce default number of blocks to check at startup...
03:05 < MarcoFalke> wumpus: I always wondered if you need the "Rebased-From:" comment in backports
03:05 < wumpus> MarcoFalke: it helps a lot
03:06 < sipa> it would be nice to have some script to do that
03:06 < wumpus> if not I have to expand the pulls manually
03:06 < GitHub149> [bitcoin] laanwj closed pull request #8646: [0.13 backport] Reduce default number of blocks to check at startup (0.13...reduceblocks_backport) https://github.com/bitcoin/bitcoin/pull/8646
03:06 < wumpus> (or not, and leave it as 'backport' in the release notes)
03:06 < wumpus> but that doesn't make reading it any easier
03:07 < wumpus> yes, it would be useful to have a script for that
03:08 < wumpus> I never bothered, top-level commits have to be signed anyhow, so I can just as well add in the metadata
03:09 < wumpus> but if the idea is to have more 'nested' PRs which backport other PRs, then a script would sure be handy
03:10 < wumpus> (which makes sense if the code is substantially different)
03:10 < luke-jr> I have a script that does it. Sortof.
03:10 < wumpus> if it applies cleanly, please just cherry-pick to the tip of the branch w/ added Github-Pull: #8611 header
03:10 < luke-jr> http://codepad.org/DRsESBYb
03:11 < wumpus> and Rebased-From if appropriate
03:11 < wumpus> cool luke-jr
03:11 < luke-jr> the github pull # isn't actually optional
03:13 < wumpus> yes the pull # is the most important part, the Rebased-From commit ids are optional / nice to know for cross-referencing, I don't use it for the release notes
03:21 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev
03:24 < GitHub33> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/6423116741de...2abfe5956eef
03:24 < GitHub33> bitcoin/master c40b034 Suhas Daftuar: Clear witness with vin/vout in CWallet::CreateTransaction()
03:24 < GitHub33> bitcoin/master 2abfe59 Wladimir J. van der Laan: Merge #8664: Fix segwit-related wallet bug...
03:25 < GitHub43> [bitcoin] laanwj closed pull request #8664: Fix segwit-related wallet bug (master...segwit-wallet-bug) https://github.com/bitcoin/bitcoin/pull/8664
03:48 < MarcoFalke> would be nice to have a test case for this ^
03:51 < GitHub126> [bitcoin] sipa opened pull request #8688: Move static global randomizer seeds into CConnman (master...detrandconnman) https://github.com/bitcoin/bitcoin/pull/8688
04:41 < GitHub163> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/2abfe5956eef...689821340981
04:41 < GitHub163> bitcoin/master ec81881 Jeremy Rubin: Performance Regression Fix: Pre-Allocate txChanged vector
04:41 < GitHub163> bitcoin/master 6898213 Pieter Wuille: Merge #8681: Performance Regression Fix: Pre-Allocate txChanged vector...
04:41 < GitHub34> [bitcoin] sipa closed pull request #8681: Performance Regression Fix: Pre-Allocate txChanged vector (master...fix-perf-regressed-txChanged) https://github.com/bitcoin/bitcoin/pull/8681
04:43 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
05:09 -!- cryptapus_afk is now known as cryptapus
05:16 < GitHub103> [bitcoin] sipa opened pull request #8690: Use a heap to not fully sort all nodes for addr relay (master...heapaddrsort) https://github.com/bitcoin/bitcoin/pull/8690
05:34 < GitHub155> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/689821340981...702e6e059b3d
05:34 < GitHub155> bitcoin/master 0480293 Jonas Schnelli: [Qt][CoinControl] fix UI bug that could result in paying unexpected fee
05:34 < GitHub155> bitcoin/master 702e6e0 Jonas Schnelli: Merge #8678: [Qt][CoinControl] fix UI bug that could result in paying unexpected fee...
05:34 < GitHub17> [bitcoin] jonasschnelli closed pull request #8678: [Qt][CoinControl] fix UI bug that could result in paying unexpected fee (master...2016/09/qt_cc_ui_radrio_fix) https://github.com/bitcoin/bitcoin/pull/8678
05:41 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
05:53 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 265 seconds]
05:56 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
06:01 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 255 seconds]
06:03 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
06:18 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has left #bitcoin-core-dev []
06:18 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]
06:20 -!- TomMc [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev
06:26 < morcos> sipa: i may be thoroughly confusing myself, but once you made the change to track explicit conflicts.  was it any longer necessary to have the SyncWithWallets loop run on txConflicted?
06:27 < morcos> it seems like that code actively does the wrong thing now, but its ok since its corrected by the loop immediately following which calls SyncWithWallets on the in block txs which will then call your MarkConflicted code
06:28 < morcos> of course if we could see mid block state, then that would be bad.  But if it is true that we can just remove the txConflicted updates, then maybe that problem goes away?
06:33 < sipa> morcos: txConflicted... that's the thing used for malleability detection?
06:33 < sipa> or you mean the txConflicted in the block connection logic
06:34 < morcos> block connection logic
06:38 < morcos> it appears to me that both removeForBlock and AddToWalletIfInvolvingMe try to do the same thing, which is find conflicting txs.  In removeForBlock (at least in the block connection logic) this is used to build a vector txConflicted, which we then call SyncWithWallets with (essentially with a null hashBlock).
06:38 < morcos> Thats actually the wrong way to mark something conflicted now
06:38 < morcos> but maybe i'm getting confused
06:39 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds]
06:40 < sipa> txConflicted (iirc, not looking at the code) is just transactions that used to be confirmed which go back to being unconfirmed after the reorg
06:41 < sipa> ah, no, which were in the mempool and are removed due to being in conflict with the new change
06:41 < sipa> i believe you are right
06:43 < sipa> trying to think whether one of the approaches can subsume the other
06:44 < morcos> i'm having trouble figuring out why we ever needed the SyncWithWallets(txConflicted)
06:45 < sipa> ah, there may be conflicts that are only obvious once you take dependencies through the mempool into account
06:45 < sipa> the wallet's internal conflict detection code can only work when the disconnected chain is entirely inside the wallet
06:45 < morcos> yes, makes sense
06:46 < sipa> but it may make sense to keep the wallet's internal code as well, as i think it's more robust (it can also track things that are temporarily removed from the mempool), and it would keep working in a hypothetical spv mode
06:47 < sipa> but i guess we do need to mark the things from txConflicted as actually conflicted
06:47 < sipa> not just as unconfirmed
06:48 < morcos> sipa: i'm not sure that's very doable
06:49 < sipa> how so?
06:49 < morcos> well, i don't think we've really ever tracked that
06:49 < morcos> prior to your conflict change
06:49 < sipa> i think we can?
06:49 < sipa> we know what block caused the conflict
06:50 < morcos> it was txs that were no longer in the mempool that were viewed as conflicted, it didn't really matter that you'd called SyncWithWallets(txConflicted)
06:50 < sipa> yes, but i think we can make it work
06:51 < morcos> but how would you ever know if it became unconflicted
06:51 < sipa> when the block it conflicts with is no longer in the active chain
06:52 < sipa> i believe that's what the negative confirmation logic already does
06:52 < morcos> perhaps you are right...
06:55 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
06:55 < sipa> we remember either the block which contains the transaction, or the first block that directly or indirectly conflicts with it
06:56 < sipa> then we count the number of confirmations on that block, and negate the number if it's a conflict
06:58 < morcos> when we disconnect a block, where do we go back and reevaluate things that might have conflicted with the now disconnected txs?
06:59 < sipa> we don't
06:59 < sipa> there is no need, i think
06:59 < sipa> the confirmations are always calculated based on the current best chain
07:00 < morcos> ah, i guess what there is a need for is to mark the cached credits/debits as dirty though right?
07:00 < sipa> so if that disconnected block was the one that conflicted with a transaction, the confirmations for that tx will go from -n to 0 afterwarfs
07:00 < sipa> yes, we may need dirtymarking
07:01 < morcos> ok, all very confusing...  we probably need to comment this way better
07:02 < sipa> agree.
07:02 < sipa> it was a relatively short notice change after the mempool eviction had been implemented
07:02 < sipa> we haven't really revisited it since
07:03 < morcos> hmm, so to summarize, even in 0.13, there is a problem right?
07:03 < morcos> if you have a mempool tx which is conflicted only via a chain of mempool txs...  then the wallet code won't catch it to mark it properly conflicted, so it'll just get marked with a null hash block which in the 0.13 code does not make the balance available again
07:04 < sipa> if that is true, it is probably 1) infrequent and 2) also wrong in 0.12
07:04 < morcos> agreed and agreed, but damn annoying when it happens.  :)
07:05 < sipa> it also seems easy to fix, but probably hard to test
07:05 -!- timothy [~quassel@archlinux/trusteduser/DrizztBSD] has quit [Disconnected by services]
07:05 -!- drizztbsd [~quassel@archlinux/trusteduser/DrizztBSD] has joined #bitcoin-core-dev
07:05 < sipa> i will probably not have much time next week to look at things
07:06 -!- drizztbsd is now known as timothy
07:07 < morcos> yeah, i'm not sure i will either, but i'll make an issue for it at least...   
07:08 < morcos> sdaftuar thinks we may have already known about this, i remember we knew that it was hard to correctly identify chains of txs that should be marked conflicted, but didn't remember it cause a (re)spendability problem
07:08 < sipa> it was known to me there were potential issues with chains outside of the wallet... but i think i considered it a best effort thing
07:09 -!- aalex_ [~aalex@64.187.177.58] has quit [Max SendQ exceeded]
07:09 < sipa> and it is... if the chain gets broken due to eviction, it stops working too
07:10 -!- aalex_ [~aalex@64.187.177.58] has joined #bitcoin-core-dev
07:11 < sipa> i guess the novel thing is that the current code is mostly a no-op (ignoring those edge cases)
07:11 < sipa> so either we do not care about through-mempool conflicts, and we should just remove the code
07:11 < sipa> or we do, and then we should make it mark dependent txn as actually conflicted
07:14 < morcos> yes, i think i agree with all that.  i also think that the mid-block state is a bigger concern here, b/c then the existing code might be worse than a no-op.  also aside from the mid-block state, the existing code might be worse than a no-op in the event that you've abandoned a tx, and then it's marked unabandoned if it gets conflicted via a mempool only chain.
07:15 < sipa> right
07:24 < morcos> sipa: ok last comment i think and then i'll shut up.  the value of that SyncWithWallets(txConflicted) was essentially that it was marking things as dirty, that wouldn't have been caught by the wallets own conflict detection code.  B/c it doesn't seem like it was ever changing any of the state of the wtx anyway.  Is that right?  that makes it easier to reason about. 
07:28 < sipa> my head hurts :)
07:28 < sipa> i'll check the code later
07:29 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev
07:35 -!- rubensayshi [~ruben@82.201.93.169] has quit [Ping timeout: 240 seconds]
07:40 < jl2012> sipa: I think we could not make uncompressed key non-std in segwit, because addwitnessaddress may create adddresses with existing or imported uncompressed keys
07:41 < sipa> jl2012: good point, but addwitnessaddress could test for that?
07:43 < jl2012> it also needs to test pubkeys inside multisig addresses. Would it be too much?
07:44 < BlueMatt> sipa: ok, take a look at https://github.com/TheBlueMatt/bitcoin/tree/segwitcb - removed the boolean and I think simplified some of the logic
07:44 < BlueMatt> the total diff against master is simpler to me
07:48 < bsm117532> BlueMatt: you're going to be in NYC from Monday, no?  What do you have planned for your "hacker residency" and time here?  I'd definitely like to swing by since I'm here and all...
07:50 < BlueMatt> bsm117532: I'm already here, but, yea, we start on monday...if you want to swing by for a day or two the week after next that'd be cool
07:51 < BlueMatt> next week might be tricky since we'll be doing a bunch of spin-up and such
07:52 < bsm117532> We also have a BitDevs meetup next week, I hope you can attend: https://www.meetup.com/BitDevsNYC/events/233599964/
07:52 < BlueMatt> yea, I had it on my mental list to figure out when bitdevs things are and show up for some of them
07:53 < bsm117532> The following week (Sep 21) a fellow has asked to present the Rootstock whitepaper.  Hopefully I'll announce that event today.
07:54 < sipa> jl2012: i dislike that a local wallet implementation detail would stand in the way of clearly useful network rule
08:09 < BlueMatt> jl2012: I would have no problem if addwitnessaddress failed for uncompressed pubkeys
08:09 < BlueMatt> altneratively, we could just compress the pubkey for them, at that point, but thats probably not ideal
08:15 < jl2012> is mutlisig the only allowed P2SH address type in wallet?
08:16 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
08:24 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
08:41 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
08:42 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Quit: conversation terminated!]
08:46 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
08:47 < jl2012> is addwitnessaddress the only possible way to create and add a witness address to the wallet?
08:55 < sipa> i believe so
08:55 < sipa> there is createwitnessaddress as well, however
08:56 < sipa> which allows computing the address, but does not actually allow soending
08:56 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
08:57 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Read error: Connection reset by peer]
09:03 < jl2012> so createwitnessaddress will return an address, even if the script is clearly invalid? (e.g. OP_RETURN)?
09:04 -!- murch [~murch@p4FE3B485.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
09:04 < sipa> yes
09:04 < jl2012> so that's another problem
09:05 < sipa> i don't think so - createwitnessaddress takes a raw script
09:05 < sipa> it's a raw tool; we could warn that it does not guarantee it results in a spendable script
09:05 < sipa> or just delete it
09:05 < jl2012> yes, either way
09:07 -!- instagibbs_ [602c943a@gateway/web/freenode/ip.96.44.148.58] has joined #bitcoin-core-dev
09:08 < instagibbs_> sipa: is there a reason addwitnessaddress doesn't add the address to the address book? Any funds sent to those addresses gets counted as change, which is a bit off
09:08 < instagibbs_> odd*
09:09 < sipa> instagibbs_: we should fix that too.
09:10 < instagibbs_> ok ill PR.
09:17 < GitHub77> [bitcoin] instagibbs opened pull request #8693: add witness address to address book (master...addwitbook) https://github.com/bitcoin/bitcoin/pull/8693
09:20 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Quit: gtg]
09:25 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer]
09:26 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
09:26 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]
09:45 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
09:47 -!- Samdney [~Samdney@dyn-ant666999.hawo.ipv6.uni-erlangen.de] has joined #bitcoin-core-dev
09:54 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
10:28 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
11:03 -!- Samdney [~Samdney@dyn-ant666999.hawo.ipv6.uni-erlangen.de] has quit [Quit: Verlassend]
11:08 -!- Samdney [~Samdney@dyn-ant666999.hawo.ipv6.uni-erlangen.de] has joined #bitcoin-core-dev
11:31 -!- instagibbs_ [602c943a@gateway/web/freenode/ip.96.44.148.58] has quit [Quit: Page closed]
11:47 -!- jannes [~jannes@178.132.211.90] has quit [Remote host closed the connection]
11:48 < morcos> cfields: sdaftuar: MarcoFalke: re: #8680, i actually think we need to improve the design a bit.  the problem is latestblock can be accessed when it hasn't been updated by even the reference node yet?  in practice this doesn't happen very often because the python control flow blocks on the reference node completing chain operations, but might happen in a p2p test.
11:49 < morcos> In addition invalidateblock (and reconsiderblock?) don't even notify latestblock after chain operations are complete, but this i think is fixable separately
11:50 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Quit: gtg]
11:52 < morcos> It seems like a better overall testing design might be to say sync_blocks(reference_node) where then you call reference_node.getbestblockhash() and then wait for all latest blocks to be at that hash (including at this point waiting for the reference_node to have finished wallet ops)
11:53 < morcos> but this requires changing all the rpc tests.   it's probably the case that reference_node is node0 a very high percentage of the time, but thats a bit of an unintuitive thing to have as a default
12:11 < morcos> cfields: on an unrelated note, maxuploadtarget.py is failing now.  i'm guessing its due to your network refactor?  did you try that test?
12:18 < morcos> cfields: yeah, i just checked, the merge of #8085 broke that test. 
12:26 < cfields> morcos: hmm, I was getting that spuriously, but I thought i was seeing it in master as well
12:27 < cfields> probably crossed wires, though. checking now, thanks for letting me know
12:28 < cfields> morcos: re rpc stuff, yea, there's lots to fix, i'm not sure where is the best place to start.
12:30 < cfields> i think we need to nail down an approach to attack these async issues in general though, rather than reacting to changes
12:30 < morcos> cfields: ha, that was sufficient for me to erase what i just typed. :)
12:31 < cfields> heh
12:32 < cfields> morcos: i started working on more async calls/features, but it all feels so ad-hoc that i'm having a hard time moving forward
12:32 < cfields> i think a design doc is necessary :\
12:35 < morcos> i think one question we should answer in that design doc is how important it is to fully support invalidateblock and reconsiderblock
12:35 < sipa> i consider them unsupported raw emergency tools
12:35 < morcos> originally i thought these were just kind of developer tools, and it wasn't maybe necessary that production code worked 100% seamlessly with them
12:36 < sipa> they were introduced because of experience with the march 2013 attack
12:36 < morcos> but seems like over time i've heard them being talked of as yeah, tools that we would use in an emergency
12:36 < sdaftuar> i seem to find myself using them in tests a lot
12:36 < morcos> which to me means they also need to make sure behavior is correct after you use them...  such as if you're asking for a balance and you expect it to be after wallet is updated, then that ought to also work for invalidate block
12:38 < cfields> morcos: they're interesting to me because they break all notions of fencing. And I assume there are other cases, or will be in the future. But it really makes me crave atomicity as a feature.
12:40 < kanzure> which things feel adhoc about the async stuff?
12:41 < gmaxwell> I also think of invalidate/revalidate as emergency tools / developer tools, I expected that they'd cause some misbehavior. OTOH,  I don't think there is any fundimental reason why they need to: we already _must_ handle reorgs in the system. 
12:41 < cfields> kanzure: thinking in terms of individual calls rather than a general approach
12:41 < morcos> gmaxwell: but a reorg that lowers height is basically impossible
12:42 < BlueMatt> i mean if those rpcs break wallet, does anyone give a fuck?
12:42 < kanzure> 3 blocks replaced by 2 blocks at the tip?
12:42 < morcos> gmaxwell: and reorgs don't return control while height is less than prev height
12:42 < BlueMatt> they're primarily considered there for mining, no?
12:46 < BlueMatt> anyone who's running a wallet and is aware of issues like this enough to want to run invalidateblock shouldnt run invalidateblock - they should stop using their damn wallet until the problem is fixed
12:46 < gmaxwell> morcos: reorgs can reduce height, in fact.
12:46 < gmaxwell> They commonly do on testnet, but they can on mainnet too.
12:46 < morcos> gmaxwell: yeah i know, thats why i said basically
12:47 < gmaxwell> oh sorry.
12:47 < morcos> if we forget about where we are and just think about where we want to be
12:47 < morcos> what we really might want is a blocking version of a wallet call that takes some hash
12:48 < morcos> and then blocks until the work on the wallet chain is >= work on that hash?
12:48 < morcos> which should then work for all reorgs, but not invalidateblock?
12:48 < morcos> but maybe matt is right, maybe thats good enough
12:49 < cfields> morcos: yes, that's basically what i've arrived at as well
12:49 < morcos> then we could modify the tests to use a simple get bestblockhash on our reference node, and then call the blocking balance calls with that hash
12:49 < morcos> then we'd have to do something somewhat smart to make tests that use invalidateblock work properly
12:50 < cfields> <cfields> I think the reason today's discussion devolved so quickly is because "getblockcount" is impossible to define, because there's no global height. So the only fix is to ensure that we're asking a specific interface a specific question. Then there's no way of being out of sync because you've specified your constraints
12:50 < morcos> at least thats what we want to do if we want to compare balances, if we're syncing chains for other reasons, thats fine, we just since the getbestblockhashes
12:51 < morcos> yep, i think we agree'ish
12:51 < cfields> morcos: close, but i think that's falling into the same trap. What you really want in that case is "tell the wallet to wait for balance x at height y and hash z"
12:51 < morcos> which part
12:51 < BlueMatt> morcos: would we need to do something smarter for tests? I mean if we get to control what it blocks until isnt that fine?
12:52 < cfields> (the missing constraint in yours was the balance itself)
12:52 < morcos> well i was trying to imagine what might be a useful rpc call in general (and then how would we use that to accomplish the tests goals)
12:52 < morcos> in general you might say, oh i know this many blocks have happened
12:52 < morcos> i want the wallet to give me the balance as soon as its caught up that far
12:53 < morcos> but you have no control if it accidentally proceeds beyond that before you get a chance to ask it
12:53 < morcos> which is already the case
12:54 < sipa> gmaxwell: invalidate and reconsider do need to do pretty invasive things to the internal data structures (they pretty much iterate over all block index objects and modify values here and there to keep things consistent)
12:54  * BlueMatt missed a bunch of discussion, but what happened to "wallet rpc calls, by default, block until the wallet is up-to-date with the state of the chain at the start of the call, or, if the state of the chain changes and we never reach that point, until the wallet is caught up to the state of the chain"
12:55 < sipa> BlueMatt: i am not convinced that is necessary
12:56 < BlueMatt> not neccessary in what regard?
12:56 < BlueMatt> not neccessary for tests or not a good idea to target for?
12:56 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-umqvfhiestmlvalq] has quit [Quit: Connection closed for inactivity]
12:57 < sipa> BlueMatt: it's a promise that's hard to keep if the wallet becomes more independent
12:57 < sipa> maybe it is necessary, but i am not convinced yet
12:58 < BlueMatt> I dont think its hard to keep?
12:58 < BlueMatt> I mean you start wallet calls with "get current chain state" and then wait until the wallet thinks its up to date with that or better before returning
12:59 < sipa> well, yes, a huge cost
12:59 < sipa> of course it is easy to implement
12:59 < sipa> but it may reduce performance a lot
13:00 < sipa> so i'd rather not
13:01 < sipa> anyway, off to have beer
13:02 < BlueMatt> i mean, yes, there should be an option to say "actually, only wait until point X", but it should default to X being the current chainstate when entering the wallet call
13:03 < sipa> i don't know about that
13:03 < sipa> that seems like an over-conservative approach that we may regret
13:03 < morcos> i think that what BlueMatt and I are saying is the same thing.  Although I'd expose the argument as to what hash you want the wallet to require it is synced up to at least (workwise) and possibly add a default that does what matt suggests
13:04 < morcos> but certainly i suppose there should be a just give me what you got version as well
13:04 < BlueMatt> sipa: I mean I think the api change has a lot of cost to users, so would prefer we default to what it does now, though I suppose I donnt care as long as there is a way to easily switch to the original behavior
13:05 < sipa> fair enough
13:06 < sipa> the reason i think it may not be needed os that right now, between any two calls the height can already cjange
13:06 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev
13:07 < sipa> so i don't think that the wallet should report a state that is necessarily at the beginning of the call
13:07 < sipa> it just needs to be internally consistent and well-ordered with the results of other calls
13:25 -!- e4xit [~e4xit@cpc92302-cmbg19-2-0-cust1369.5-4.cable.virginm.net] has quit [Ping timeout: 264 seconds]
13:25 -!- e4xit [~e4xit@cpc92302-cmbg19-2-0-cust1369.5-4.cable.virginm.net] has joined #bitcoin-core-dev
13:28 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-xuwhhhyacrrigxot] has joined #bitcoin-core-dev
13:29 -!- arubi_ [~ese168@unaffiliated/arubi] has joined #bitcoin-core-dev
13:30 -!- arubi [~ese168@unaffiliated/arubi] has quit [Ping timeout: 260 seconds]
13:55 < cfields> morcos: pretty sure i found the maxupload problem, working on a patch now. thanks again for the ping.
13:57 < BlueMatt> heh, fun, if memory allocation fails in script (which it def could), bitcoind will reject the block as an invalid block
13:57 < BlueMatt> yay overcommit
13:59 -!- moli [~molly@unaffiliated/molly] has quit [Quit: Leaving]
13:59 < gmaxwell> actual overcommit will not cause an allocation failure.
14:00 < gmaxwell> it will cause a crash, which would actually be preferable here. :)
14:00 < BlueMatt> indeed, overcommit is required to run bitcoin core in consensus
14:01 < gmaxwell> required is a bit too strong, in practice that divergence may be untriggerable.
14:01 < BlueMatt> true
14:02 < gmaxwell> This can probably be handled with a limited wrapper that catches any unexpected exception inside block validation and asserts.
14:02 < gmaxwell> Which I think would be a really good idea, especailly in the short term.
14:03 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
14:04 < BlueMatt> i think in block validation its fine, it will throw out to caller and either give you an exception in rpc or in ProcessMessage
14:05 < BlueMatt> but in script we have a general catch
14:05 < BlueMatt> indeed, should probably have a catch for bad_alloc there that does an assert(false)
14:05 < GitHub57> [bitcoin] luke-jr opened pull request #8694: Basic multiwallet support (master...multiwallet) https://github.com/bitcoin/bitcoin/pull/8694
14:15 < gmaxwell> I looked before to see if it was possible to catch bad_alloc process wide, but found nothing. (Also, I don't think that would work, because while stepping through with GDB I've seen boost code try to alloc TBs of memory then fail and continue on with life)
14:21 < GitHub64> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/702e6e059b3d...2a0836f6d5e7
14:21 < GitHub64> bitcoin/master 2f2548d Johnson Lau: Fix SIGHASH_SINGLE bug in test_framework SignatureHash...
14:21 < GitHub64> bitcoin/master 2a0836f MarcoFalke: Merge #8667: Fix SIGHASH_SINGLE bug in test_framework SignatureHash...
14:21 < GitHub25> [bitcoin] MarcoFalke closed pull request #8667: Fix SIGHASH_SINGLE bug in test_framework SignatureHash (master...patch-16) https://github.com/bitcoin/bitcoin/pull/8667
14:24 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 252 seconds]
14:29 < BlueMatt> gmaxwell: lulwut
14:29 < BlueMatt> in any case should probably put a second catch in script interpreter above the catch-all and assert(false) on bad_alloc
14:30 -!- instagibbs_ [640fdb5c@gateway/web/freenode/ip.100.15.219.92] has joined #bitcoin-core-dev
14:56 -!- timothy [~quassel@archlinux/trusteduser/DrizztBSD] has quit [Disconnected by services]
14:56 -!- drizztbsd [~quassel@archlinux/trusteduser/DrizztBSD] has joined #bitcoin-core-dev
14:56 -!- drizztbsd is now known as timothy
15:05 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]
15:14 -!- instagibbs_ [640fdb5c@gateway/web/freenode/ip.100.15.219.92] has quit [Quit: Page closed]
15:16 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
15:19 -!- droark [~droark@c-24-22-36-12.hsd1.or.comcast.net] has quit [Ping timeout: 244 seconds]
15:22 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev
15:23 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]
15:31 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Quit: zzZZZzzzZZzZzZzzzzzZz]
15:35 -!- Yogh [~Yogh@f36186.upc-f.chello.nl] has quit [Ping timeout: 265 seconds]
15:35 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
15:38 -!- Yogh [~Yogh@f36186.upc-f.chello.nl] has joined #bitcoin-core-dev
16:07 -!- Samdney [~Samdney@dyn-ant666999.hawo.ipv6.uni-erlangen.de] has quit [Remote host closed the connection]
16:11 -!- Samdney [~Samdney@dyn-ant666999.hawo.ipv6.uni-erlangen.de] has joined #bitcoin-core-dev
16:17 -!- FNinTak [~jonhbit@tsarviajado.media.mit.edu] has joined #bitcoin-core-dev
16:18 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 265 seconds]
16:19 < gmaxwell> hm. I don't understand why my node is attempting feeler connections on IPv when the only v6 ifs I have are ::1 and a link local.
16:21 -!- FNinTak [~jonhbit@tsarviajado.media.mit.edu] has quit [Client Quit]
16:24 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
16:30 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has left #bitcoin-core-dev []
16:42 < phantomcircuit> gmaxwell: the reachable stuff was largely disabled because it didn't work
16:42 < phantomcircuit> so right now unless something is marked explicitly as unreachable everything is reachable
16:42 < phantomcircuit> (ie you're using tor)
16:44 < gmaxwell> this is suboptimal. :) at least it probably shouldn't think it can connect to IPv6 if I litterally have no IPv6 addresses but local and linklocal.
16:49 -!- cryptapus is now known as cryptapus_afk
16:54 -!- murch [~murch@p4FE3B485.dip0.t-ipconnect.de] has quit [Quit: Leaving.]
17:14 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has quit [Disconnected by services]
17:27 < phantomcircuit> gmaxwell: except you might be able to ipv6 with only a link local thanks to ipv6nat
17:27 < phantomcircuit> (yeah i know nobody deploys this, but it is a thing)
17:35 < phantomcircuit> really the only way to know for sure is to check the local routing table
17:35 < phantomcircuit> but i dont see us doing that anytime soon
17:35 < phantomcircuit> also it should basically instantly fail anyways
17:38 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
17:48 < GitHub117> [bitcoin] pstratem opened pull request #8695: Retry feeler connection if OpenNetworkConnection fails in under 1ms. (master...2016-09-09-net-feeler-timeout) https://github.com/bitcoin/bitcoin/pull/8695
17:51 -!- TomMc [~tom@unaffiliated/tommc] has quit [Ping timeout: 244 seconds]
18:00 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Quit: WeeChat 0.4.2]
18:12 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
18:13 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
18:13 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
18:24 < luke-jr> "If checked, users with write access to bitcoin/bitcoin can add new commits to your multiwallet branch. You can always change this setting later." … on by default O.o
18:24 < luke-jr> that's slightly scary
18:26 < gmaxwell> thats...
18:26 < gmaxwell> not really desirable.
18:26 < luke-jr> when I first saw it I figured it meant the PR description, but apparently it extends to code :/
18:28 < gmaxwell> is there any way to even tell who made a change, assuming they mucked with the repository in the right way?
18:29 < luke-jr> doubtful.
18:29 < luke-jr> I suppose GitHub shows what user pushed commits, maybe?
18:29 < luke-jr> hard to know without trying
18:49 -!- instagibbs [~instagibb@pool-100-15-114-3.washdc.fios.verizon.net] has quit [Ping timeout: 250 seconds]
18:58 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Quit: .]
19:00 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
19:28 < GitHub126> [bitcoin] pstratem opened pull request #8696: [Wallet] Remove last external reference to CWalletDB (master...2016-09-09-cwallet-listaccountcreditdebit) https://github.com/bitcoin/bitcoin/pull/8696
19:36 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-xuwhhhyacrrigxot] has quit [Quit: Connection closed for inactivity]
19:46 -!- TomMc [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev
20:12 < phantomcircuit> luke-jr: yeah im not concerned about the flushing thread since it will just wait for whatever has the db locked to release the lock
20:18 < luke-jr> phantomcircuit: I was mainly just commenting on the title of your PR :p
20:22 < phantomcircuit> it's technically true
20:22 < phantomcircuit> the best kind of true
20:27 -!- ryan-c [~ryan@znc.rya.nc] has quit [Ping timeout: 255 seconds]
20:46 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
20:47 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
20:49 -!- TomMc [~tom@unaffiliated/tommc] has quit [Ping timeout: 276 seconds]
21:00 -!- dermoth [~thomas@dsl-66-36-143-95.mtl.aei.ca] has quit [Read error: Connection reset by peer]
21:00 -!- dermoth [~thomas@dsl-66-36-143-95.mtl.aei.ca] has joined #bitcoin-core-dev
21:01 -!- ryan-c [~ryan@znc.rya.nc] has joined #bitcoin-core-dev
21:12 -!- ryan-c [~ryan@znc.rya.nc] has quit [Excess Flood]
21:12 -!- ryan-c [~ryan@znc.rya.nc] has joined #bitcoin-core-dev
21:13 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 250 seconds]
21:16 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
21:31 -!- Samdney [~Samdney@dyn-ant666999.hawo.ipv6.uni-erlangen.de] has quit [Quit: Verlassend]
21:40 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev
21:49 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
21:50 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
22:07 -!- Netsplit *.net <-> *.split quits: waxwing, aalex_, moli, wolfspraul, [b__b], Chris_Stewart_5, binns, mr_burdell, PatBoy, windsok,  (+3 more, use /NETSPLIT to show all of them)
22:07 -!- Netsplit *.net <-> *.split quits: jeremyrubin, owowo, isis, PaulCapestany, neha, helo, bad_duck, go1111111, lightningbot, petertodd,  (+17 more, use /NETSPLIT to show all of them)
22:10 -!- michagogo [uid14316@wikia/Michagogo] has quit [Ping timeout: 258 seconds]
22:14 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
22:17 -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev
22:25 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
22:25 -!- aalex_ [~aalex@64.187.177.58] has joined #bitcoin-core-dev
22:25 -!- binns [sid105317@21/bitcoin/binns] has joined #bitcoin-core-dev
22:25 -!- PatBoy [xyz@192.99.249.194] has joined #bitcoin-core-dev
22:25 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has joined #bitcoin-core-dev
22:25 -!- waxwing [~waxwing@62.205.214.125] has joined #bitcoin-core-dev
22:25 -!- wolfspraul [~wolfsprau@bobbin.q-ag.de] has joined #bitcoin-core-dev
22:25 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
22:25 -!- michagogo [uid14316@gateway/web/irccloud.com/x-tnhwjqyfhlgvzzcj] has joined #bitcoin-core-dev
22:40 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.]
22:44 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
22:54 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
22:55 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
23:05 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
23:17 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
23:27 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
23:28 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
23:37 -!- mrkent [~textual@unaffiliated/mrkent] has quit []
23:38 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
23:50 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev