--- Day changed Fri Nov 20 2015
00:01 < GitHub118> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a1bfca80521e...07b770caf3f5
00:01 < GitHub118> bitcoin/master 33b7f83 MarcoFalke: [qa] travis: cover *receivedby* rpcs
00:01 < GitHub118> bitcoin/master 07b770c Wladimir J. van der Laan: Merge pull request #7019...
00:01 < GitHub39> [bitcoin] laanwj closed pull request #7019: [qa] travis: cover more tests (master...MarcoFalke-2015-receivedby) https://github.com/bitcoin/bitcoin/pull/7019
00:41 < jonasschnelli> sipa: you said when the mempool evicts a tx, the wallet threats it as conflicted. I wrote a test and "gettransaction" on a mempool-evicted tx responses confirmations:-1 but no walletconflicts (=[]). The GUI will probably threats -1 confirmations as conflicted.
00:41 < jonasschnelli> did you mean -1 confirmation = conflicted?
00:44 < Luke-Jr> jonasschnelli: -1 is conflicted; that it shows -1 is a bug
00:45 < Luke-Jr> I wonder if it's safe to use the same logic as walletconflicts for that
00:46 < jonasschnelli> Luke-Jr: But looking at CMerkleTx::GetDepthInMainChain(), it seems like that -1 just means:  "not in the chain, not in the mempool".
00:46 < Luke-Jr> jonasschnelli: at the time that was written, it implied a conflict
00:47 < Luke-Jr> there is an assumption that anything not conflicted, will be in the mempool or chain
00:47 < jonasschnelli> Luke-Jr: right. This assumption fails as soon as mempool can evict txes.
00:47 < Luke-Jr> it's possible doing a more through check could harm performance
00:47 < Luke-Jr> so I'm not sure what the best way to fix it is
00:48 < jonasschnelli> what about "removetransaction" call for -1 confirmations txes? GUI: right click -> remove tx?
00:48 < Luke-Jr> so only allow removing conflicted ones?
00:48 < jonasschnelli> right.
00:49 < Luke-Jr> sounds fine, except s/remove/hide/ at least in the low-level
00:49 < jonasschnelli> agreed.
00:49 < gmaxwell> gah, sipa pointed earlier that we can just check for the actual reason.
00:50 < gmaxwell> Luke-Jr: it won't harm performance any more than what we currently do.
00:50 < jonasschnelli> gmaxwell: did you mean that point: http://bitcoinstats.com/irc/bitcoin-dev/logs/2015/11/19#l1447960611.0
00:50 < Luke-Jr> gmaxwell: oh, good, so it should be easy
00:50 < gmaxwell> jonasschnelli: yes.
00:51 < jonasschnelli> gmaxwell: my issue with that is, that i slowly like to reduce mempool/wallet coupling to have the possibility to detact the wallet over a SPV like connection
00:51 < jonasschnelli> And also, how should SPV wallet deal with mempool eviction.
00:53 < gmaxwell> This is largely unrelated to the actual mempool, it has to do more with the utxo set.  Please don't overdesign right now. A SPV wallet cannot detect a non-in-wallet conflict, but we can. 
00:54 < jonasschnelli> gmaxwell: Okay. I see the point. But sipas point would require a way to check if a tx *would* be accepted in the mempool IIRC?
00:55 < jonasschnelli> Luke-Jr : While working on this. How would RBF work in case of user interaction. Could a first feature be "altertransaction" where one could add inputs and or outputs while newfee > oldfee?
00:55 < gmaxwell> It's more of a 'would be accepted in a block', but testing the mempool is a stronger version of that.
00:56 < gmaxwell> For RBF fee revision the way that should work is to precalculate, with nlocktimes, transaction versions with higher fees. But do not broadcast them.  This avoids having to authorize signing multiple times.
00:56 < Luke-Jr> jonasschnelli: I would prefer it behind-the-scenes/automatic, but that may be simpler.
00:57 < jonasschnelli> gmaxwell: huh. Sounds after a nice solution, but probably relatively complex to implement. :)
00:57 < Luke-Jr> eg, sending another payment should probably by default be altering any outstanding unconfirmed one to add an output, but signing a normal one to broadcast in case the former confirms without it
00:58 < Luke-Jr> hah, what I just suggested probably makes gmaxwell's look simple :D
00:58 < gmaxwell> jonasschnelli: as far as remove, I think what would be better is 'archivetransaction' which can be done to any confirm/conflicted transaction or any unconfirmed non-conflicted at least (say) 72 hours old. (so people don't think they can cancel transactions this way)
00:58 < gmaxwell> I think thats fairly simple because it needs basically no interface. it could be litterally a couple line loop to produce the transactions. Storing them is a bit more work.
01:00 < jonasschnelli> Did i got this right; when the mempool evicts a wtx, the inputs automatically are release and can be used in a new transaction?
01:00 < Luke-Jr> jonasschnelli: that's a bug because the wallet thinks it was conflicted
01:01 < jonasschnelli> But also a feature? so "archivetransaction" is just a "visibility" thing?
01:01 < Luke-Jr> not a feature..
01:01 < Luke-Jr> unintended harmful behaviour <.<
01:01 < gmaxwell> It's not a feature; it's a recently introducted bug that is very harmful.
01:01 < sipa> jonasschnelli: hell no!
01:01 < jonasschnelli> But if your transaction got evicted (to less fees), you can automatically create a new-one?
01:02 < Luke-Jr> jonasschnelli: you can't deterministically respend it.. only accidentally
01:02 < gmaxwell> it could cause you to overdraft yourself and rip people off accidentally and be unable to make it right (at least not immediately) because you no longer have enough bitcoin.
01:02 < Luke-Jr> so if you tried to RBF this way, you could quite easily end up sendign the payment twice
01:02 < sipa> jonasschnelli: when the mempool evicts, you specifically do not want to make the coins available again
01:03 < jonasschnelli> sipa: so the only way to re-use the inputs would be with RBF?
01:03 < jonasschnelli> would be/should be
01:03 < sipa> jonasschnelli: you only do that when the reason for not being in the mempool is conflict with the blockchain
01:03 < gmaxwell> jonasschnelli: no, we need to fix that conflict check to work correctly now that eviction is possible.
01:03 < sipa> jonasschnelli: read the meeting log
01:04 < gmaxwell> They should only become available again once actually conflicted (or to a RBF respend which still pays the original destination)
01:04 < sipa> jonasschnelli: RBF is a full node side thing, not a wallet thing
01:04 < gmaxwell> but we probably shouldn't be implementing wallet replacement behavior yet, not until after it's generally available in the network.
01:05 < gmaxwell> Though yes, archive would be just a visibility thing. 
01:05 < gmaxwell> (and potentially memory usage and performance)
01:07 < jonasschnelli> so we need something like this: if confirmations = -1, check if tx would be accepted to the mempool, if rejected due to non-existing inputs = conflicted
01:07 < Luke-Jr> …no
01:08 < gmaxwell> jonasschnelli: the whole -1 comes from checking the mempool, the specific behavior of that check just needs to be changed a bit so that it's not confused by the new behavior.
01:08 < Luke-Jr> if the transaction isn't conflicted, then confirmations != -1
01:09 < gmaxwell> perhaps we should also add a field on the transaction that indicates if its in the local mempool or not. (or even what its position is, now that our mempool is usefully sorted)
01:09 < sipa> the easiest, but ugly way, is to check the return validation state code from accepttomemorypool
01:10 < gmaxwell> (well perhaps not, since position is uncachable.; though a mempoolposition <txid> wouldn't be bad.)
01:12 < Luke-Jr> feels like something that we'd be likely to want to change after 0.12 IMO
01:13 < Luke-Jr> (although I wanted to give a good example reason, but I couldn't come up with one)
01:13 < gmaxwell> Luke-Jr: what would be?
01:14 < Luke-Jr> gmaxwell: mempool position of tx stuff
01:14 < Luke-Jr> the exposed interface seems not necessarily obvious
01:17 < jonasschnelli> But while looking at https://github.com/bitcoin/bitcoin/blob/master/src/wallet/wallet.cpp#L1521, it looks like that the wallet does not spend evicted transaction (confirmations: -1)? Will test now...
01:19 -!- Guest23423 [~guest2342@223.207.239.241] has joined #bitcoin-core-dev
01:21 < Luke-Jr> jonasschnelli: that's not the issue
01:21 < Luke-Jr> the UTXOs are confirmed, in this case
01:21 < Luke-Jr> but they are also spent already.
01:22 < Luke-Jr> that nDepth is the UTXO's transaction depth, not the spending transaction's depth
01:23 < jonasschnelli> Argh. Right... 
01:24 < GitHub185> [bitcoin] laanwj opened pull request #7065: http: add Boost 1.49 compatibility (master...2015_11_httpserver_boost1_49) https://github.com/bitcoin/bitcoin/pull/7065
01:25 < gmaxwell> https://www.reddit.com/r/Bitcoin/comments/3tigrp/comcast_data_caps_will_make_nodes_running_with/
01:26 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]
01:26 -!- Guest23423 [~guest2342@223.207.239.241] has quit [Read error: Connection reset by peer]
01:29 < jonasschnelli> Luke-Jr: so that a relevant part?: https://github.com/bitcoin/bitcoin/blob/master/src/wallet/wallet.cpp#L459
01:30 < sipa> jonasschnelli: no
01:30 -!- CodeShark [uid126576@gateway/web/irccloud.com/x-bglnlpiloitkxvrk] has joined #bitcoin-core-dev
01:30 < sipa> jonasschnelli: the relevant part is the GetDepthInMainChain computation
01:30 < Luke-Jr> jonasschnelli: the only part that needs to be touched right now, is GetDepthInMainChain
01:30 < sipa> which looks at the mempool
01:31 < sipa> if it isn't in the mempool, it should just return 0
01:31 < sipa> upon first submit, and upon eviction, we should check the return value of accepttomemorypool
01:32 < sipa> and when that indicates it's due to missing input, set a boolean flag remember in the wallet 
01:32 < Luke-Jr> sipa: well, it needs to return -1 when conflicted or we break other stuff
01:32 < Luke-Jr> or rather, <0
01:32 < sipa> and when GetDepthInMemoryPool would return 0 and that flag is said, only then return -1
01:32 < Luke-Jr> IIRC the original plan was -1 if the conflicting tx was 1 block deep; -2 and so on for more blocks
01:33 < sipa> right, that's an older idea that becomes viable again
01:33 < Luke-Jr> but no need to do that now
01:33 < sipa> indeed
01:34 < sipa> Luke-Jr: we also need to be informee on eviction, with the reason for that eviction (or alternatively, resubmit upon eviction)
01:35 < Luke-Jr> sipa: well, if we're just going to resubmit as-is, we might as well just set a priority on our own transactions so they never get evicted
01:35 < sipa> Luke-Jr: the resubmit would fail
01:36 < sipa> Luke-Jr: the reason to do is to find out why it fails
01:36 < Luke-Jr> ah
01:40 -!- guest234234 [~guest2342@223.207.239.241] has joined #bitcoin-core-dev
01:45 < jonasschnelli> sipa: what about informing/signaling the wallet in case of mempool eviction and set the wtx flag then (=confirmation: 0 instead of -1)? Would that be wrong?
01:47 < sipa> jonasschnelli: read 5 lines up
01:47 < gmaxwell> We shouldn't depend on submission or resubmission.
01:48 < sipa> gmaxwell: hmm?
01:48 < sipa> submission certainly
01:48 < gmaxwell> For example, if walletbroadcast=0 we should still learn when it goes conflicted.
01:48 < jonasschnelli> Saw that. But would that still require to evaluate the pfMissingInputs on first submitting?
01:48 < sipa> gmaxwell: ugh
01:48 < sipa> so we need an AcceptToMemoryPool dryrun mode?
01:48 < gmaxwell> When the transaction is added to wallet we should check if it is conflicted. Then on every block tip change we should check all unconfirmed transactions if they are conflicted.
01:49 < sipa> ok, i guess it's easier then to add a main function CheckForConflicgts
01:49 < sipa> and call then if submission fails or is skipped, or we are evicted
01:49 < sipa> and cache the result
01:49 < gmaxwell> I don't think we need to do anything with evicted?
01:50 < sipa> eviction also happens on block confirm, no?
01:50 < gmaxwell> just cache until blockchain tip changes, 
01:50 < sipa> ok, that seems reasonable
01:51 < sipa> or even cache the blockindex itself, and as long as the active one descends from it, don't reevaluate if true
01:51 < gmaxwell> seperately it would be interesting to know if a txn was in-mempool or not, but I think thats not really cachable. :(
01:51 < sipa> right
01:52 < gmaxwell> sipa: yes, right once conflicted it would be nice if it were cheap, so a bunch of these don't become a performance sink in the wallet. Good call.
01:54 < gmaxwell> non-cachability of the mempool check is perhaps not that bad though, since it would only run on transactions which are not confirmed nor conflicted.
02:04 < sipa> gmaxwell: yes, because such a conflict check will pull in dependent utxos from the chainstate
02:04 < sipa> so icthink we want to avoid that at all costs
02:08 < gmaxwell> sipa: hm? To test if a transaction is in mempool we would just access the mempool by txid and check the transaction hash itself against it. Not try submitting it.
02:20 < jonasschnelli> gmaxwell, sipa: mind doing a quick concept-review if I'm going into the right direction (big !WIP!, just check the concept): https://github.com/jonasschnelli/bitcoin/commit/723b7c365ceaa1567c364e1ffc5602f5dfd1b7fb
02:21 < jonasschnelli> There is no check right now when adding a wtx to the wallet.
02:28 < sipa> gmaxwell: well you need to check whether all inputs are available
02:28 < sipa> gmaxwell: which means looking at the utxo set, not just the wallet
02:30 < sipa> jonasschnelli: GetDepthInMainChain should return 0 if not conflicted
02:31 < gmaxwell> I don't think you do, you do that via the conflicted check, which is cached.
02:31 < sipa> gmaxwell: i'm confused; how could you detect a conflict with mempool that limited to zero?
02:31 < sipa> it's trivial if you see some inputs spent in the utxo set
02:31 < jonasschnelli> sipa: i think it should return 0 in that case (GetDepthInMainChainINTERNAL will result in 0), but will check
02:32 < gmaxwell> I am saying there should be a Conflicted check that doesn't touch the viewcache, but checks the utxo set directly and is cached and keyed by blockindex.
02:32 < sipa> gmaxwell: ok, i agree there
02:32 < gmaxwell> If a transaction is unconfirmed and unconflicted (by the above), we could also check if the transaction is in the mempool, which is cheap.
02:32 < gmaxwell> What I suggest wouldn't distinguish an in-mempool conflict with too-low-fee, but I think thats no big loss.
02:33 < sipa> gmaxwell: minimal viable solution firstz place
02:33 < sipa> grrr
02:33 < sipa> minimal viable solution first
02:33 < gmaxwell> ya ya. mostly its an observation that the direct test doesn't preclude also having a reasonable cheap mempoolness check.
02:34 < sipa> what difference does in-mempoolness make? how do we report the result?
02:35 < gmaxwell> sipa: listtransactions output,  tells you if your unconfirmed tx is probably screwed. :)
02:36 < sipa> gmaxwell: all i was saying is that jonas' conflict check shouldn't (only) look at the mempool but at the utxo set
02:37 < sipa> in fact, i don't know if having a conflict in the mempool should matter at all for respendability... just because you accepted a different conflicting mempool tz does not mean the network will (though very likely...)
02:38 < gmaxwell> yes, I agree, -1 should mean blockchain conflict.
02:38 < gmaxwell> But if it does; it's useful to know that the transaction isn't in the mempool. 
02:38 < sipa> sure
02:38 < gmaxwell> Ideally we'd give the depth of the earliest conflict, but sadly thats stupidly expensive to do. :(
02:39 < gmaxwell> at least with how things are structured now.
02:39 < sipa> not when there are other txouts of the txid still in the utxo set
02:39 < gmaxwell> yes, sure but thats not reliable.
02:39 < sipa> indeed
02:39 < CodeShark> txindex? :)
02:39 < gmaxwell> we could do it so long as we captured it as it flew by and recorded it in the wallet.
02:40 < sipa> CodeShark: die!
02:40 < CodeShark> lol
02:40 < sipa> CodeShark: it's german for "the"
02:41 < CodeShark> feminine nominative/accusative
02:41 < sipa> correct!
02:41 < gmaxwell> http://flyingscotsman.tumblr.com/post/3486957620/laywer-well-what-about-that-tattoo-on-your
02:41 < CodeShark> Ich weiss etwas Deutch Grammatik :)
02:42 < CodeShark> *Deutsch
02:42 < CodeShark> not dutch :p
02:42 < CodeShark> although dutch grammar is simpler
02:42 < CodeShark> but offtopic
02:43 < gmaxwell> in any case, the conflict depth is pretty much only interesting for small values  e.g. it would be superior to not release conflicted txins for general respond until -3 (or -6) ... but no one cares about -500 vs -600
02:43 < CodeShark> Bart is a girl? :)
02:45 < CodeShark> gmaxwell:  you mean only flush txs from mempool once they're sufficiently buried?
02:45 < sipa> CodeShark: we're talking about the wallet
02:46 < CodeShark> right - so the wallet needs its own mempool :)
02:46 < CodeShark> I remember this topic a couple years ago
02:46 < gmaxwell> it's not really a mempool thing at all.
02:46 < CodeShark> well, it needs to keep track of its own transactions
02:46 < CodeShark> and dependencies
02:47 < gmaxwell> Right now the wallet will allow another transaction to reuse the non-conflicted txins from a conflicted transaction. This avoids the case when some malleated change vanishes on you, and a tx which has now been conflicted on account of it spent other coins as well, and now those coins are in limbo.
02:47 < sipa> gmaxwell: it's really quite complicated... the question for each input is whether the corresponding is available or would become available.
02:48 < sipa> . which means looking at the wallet, the mempool, and the utxo set
02:48 < gmaxwell> Thats fine and all, but -1 depth is not a guarentee that the conflict will stick, there might be a reorg that unconflicts it.. so it would probably be better to not free up the inputs quite so fast.
02:49 < gmaxwell> perhaps a cheaper approximation, is to record the height that it first hit -1 (side effect of the cache, in fact); and then make it available for respend N blocks later.
02:50 < sipa> how do you define "hit -1"
02:50 < sipa> all you can observe reliably is that there is an input missing
02:51 < gmaxwell> I know, as I said 'approximation'. 
02:51 < sipa> ok
02:51 < CodeShark> 2 + 2 approximates 5 for sufficiently large values of 2
02:52 < sipa> but that check does not output a height
02:52 < sipa> and it depends on the mempool
02:52 < gmaxwell> why does it depend on the mempool? 
02:52 < CodeShark> dependencies
02:53 < sipa> because unconfirmed inputs won't be in the utxo set
02:53 < gmaxwell> They'll be in the wallet.
02:53 < CodeShark> no
02:53 < CodeShark> not necessarily
02:53 < CodeShark> they don't necessarily belong to the wallet
02:53 < sipa> not for things that pay you
02:53 < CodeShark> someone could construct a chain of unconfirmed transactions, only the last one pays you
02:54 < gmaxwell> oh right, also recieved transactions can be conflicted. It's true.
02:54 < CodeShark> for intelligent conflict detection, the wallet must be alerted when any dependency is conflicted
02:54 < gmaxwell> sorry, had slipped into thinking only in terms of sent because I was thinking about the free to reuse question.
02:54 < sipa> received transactions matter even more, because they're the only ones that give spendable outputs
02:54 < gmaxwell> sipa: 0_o. change.
02:55 < sipa> oh, right
02:55 < gmaxwell> (googlyeyes simply because basically all conflict originated problems are related to change; since change is the only thing we'll spend with few/no confirms!)
02:55 < Luke-Jr> gmaxwell: just send all your change to sipa and that problem goes away
02:56  * sipa approves
02:56 < gmaxwell> new wallet feature: eliminates all malleability problems by sending your coins to sipa.
02:56 < Luke-Jr> :D
02:57 < sipa> gmaxwell: now.i wonder what googly eyes are...
02:57 < Luke-Jr> sipa: "0_o"
03:00 < CodeShark> basically, there currently is no safe way to spend an unconfirmed output ;)
03:00 < CodeShark> even your own
03:01 < CodeShark> for some malleability attacks about the best you can do is sign all likely cases
03:02 < CodeShark> and have the txs ready to broadcast
03:03 < wumpus> there's an option in bitcoin core's wallet to not spend any unconfirmed outputs
03:04 < CodeShark> but then your funds potentially get tied up for a while
03:04 < wumpus> it is only not the default because that was deemed too big a change from previous behavior
03:04 < CodeShark> and it's also impractical in many scenarios
03:05 < gmaxwell> CodeShark: well it'll be pratically pretty safe soon.
03:05 < sipa> gmaxwell: the wallet does get informed about all blockchain transactions, so i think we can just use that to detect conflicts
03:05 < CodeShark> yes, indeed - I'm very happy about that, gmaxwell 
03:05 < gmaxwell> The don't spend unconfirmed change thing is pretty obnoxious unless you understand bitcoins operation very well and intentionally create extra outputs.
03:05 < wumpus> anything involving zero confirmation is risky
03:06 < sipa> we should be creating extra outputs anyway for amount privacy
03:06 < CodeShark> about the best way to mitigate having funds tied up for a while is to create denominated outputs up front
03:06 < CodeShark> which is ugly in terms of block chain bloat
03:06 < wumpus> absolutely, better output management could avoid having *all* your funds tied up
03:06 < wumpus> e.g. by having multiple change outputs
03:06 < gmaxwell> During the last malleability attacks I walked a bitcoin ATM operator through doing that. Hard part was explaining the need, once they got it the actual implementation was easy. (well also the wallet they were using to fill their ATMs ..... had no sendmany support. :( )
03:07 < btcdrak> BIP68 bip text has been updated https://github.com/bitcoin/bips/issues/245
03:07 < gmaxwell> sipa: yea, did I ever tell you my thought?  if the change would be 'large'  flip a coin and either split the change 50/50, or make one change equal to the payment and the other the remainder.
03:08 < sipa> gmaxwell: yup, that'd be useful
03:08 < sipa> gmaxwell: except when the payment is a nice round number
03:08 < sipa> gmaxwell: then you probably always want to make the change identical to it (or a round fraction/muktiple)
03:09 < CodeShark> denominating outputs in powers of 2 and limiting precision can help
03:09 < CodeShark> sometimes having the extra precision means adding dust outputs :)
03:09 < gmaxwell> sipa: well the decision could be biased, but the basic idea is reasonable.
03:09 < sipa> gmaxwell: agree
03:15 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
03:19 < sipa> gmaxwell: if conflicting wallet transactions with change 
03:19 < sipa> can be accepted without conflicting
03:19 < sipa> then inthink our balance calc will be off
03:20 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.]
03:24 < CodeShark> a scheme that avoids the need for change outputs without bloating the blockchain would fix a bunch of problems
03:24 < CodeShark> I've also had issues with asynchronous signing
03:25 < CodeShark> perhaps some transaction is rejected by the authorization layer and never gets signed...which ties up the outputs
03:26 < CodeShark> which means it ties up any attempts to sign dependencies
03:26 < sipa> oh! we should only count unconfirmed transactions (from ourselves) if they are in the mempool
03:26 < wumpus> sounds sensible sipa
03:26 < sipa> but only mark them conflicted/respendable when they have a conflict in the chain
03:26 < wumpus> right
03:29 -!- jtimon_ [~quassel@74.29.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
03:30 -!- jtimon [~quassel@74.29.134.37.dynamic.jazztel.es] has quit [Read error: Connection reset by peer]
03:33 < CodeShark> more sensible than what we currently do...but still has issues
03:33 < CodeShark> I guess the UI could indicate that certain transactions have failed
03:34 < CodeShark> and prompt the user to resend
03:34 < CodeShark> or automatically resign and resend if the keys are unencrypted
03:35 < CodeShark> although that might open up security holes
03:36 < sipa> CodeShark: the plan was to have a function to mark a tx as failed
03:36 < sipa> manually
03:36 < CodeShark> well, other than the usability complications, it technically is consistent behavior
03:38 < CodeShark> and arguably less problematic than having a zero fee transaction in limbo for a long time :)
03:38 < tulip> is there an opportunity in all this for a user to "remove" a transaction, make an alternative with different outputs, and both confirm? 
03:39 < gmaxwell> I'm really not keen on requiring the manual intervention, I can see this resulting in lost funds.
03:40 < gmaxwell> Consider an automated user, ends up with some conflicted transactions.  Further spending gets rejected with insufficient funds, they think they're out of bitcoins and delete the wallet-- but they could have had a large amount remaining.
03:41 < gmaxwell> tulip: you mean spending different outputs (different inputs)? 
03:41 < tulip> yes. 
03:42 < gmaxwell> That generally exists, even now. Though they don't have a remove button which they might misunderstand to abort the transaction.
03:43 < gmaxwell> We can harden against that in the GUI by making the wallet warn you when you paid and address you've paid before. (something suggested before, because it can also avoid copied-the-wrong-line and double paid problems)
03:45 < CodeShark> I've had to directly deal with this issue in production before...and had to enable deleting transactions that have already propagated...and yes, it's a mess to keep track of stuff
03:46 < gmaxwell> well we have zapwallettx to knock out any conflicted/unconfirmeds from the wallet,  tech support via napalm.
03:46 < CodeShark> lol
03:46 < sipa> napalm is cool, when frozen
03:47 < gmaxwell> ^ man, I want a bot that produces comments like that.
03:48 < CodeShark> gmaxwell: I went ahead and added an API call to delete transactions - initially it would only allow deleting transactions that have not yet propagated (i.e. missing signatures)
03:48 < gmaxwell> in any case a dialog that says "You've paid X before, are you sure?" then shows the most recent payments to X. would likely help a lot there for gui users.
03:48 < CodeShark> but I had to eventually allow deleting even propagated transactions for malleability attacks and transactions that just won't confirm (low fees)
03:49 < CodeShark> and for any sort of high volume operation it's a nightmare
03:49 < gmaxwell> CodeShark: have you yet had someone have something deleted make it through and be surprised?
03:50 < CodeShark> fortunately no terrible losses have occured...but it has required extra careful manual intervention
03:51 -!- guest234234 [~guest2342@223.207.239.241] has quit [Ping timeout: 250 seconds]
03:52 < gmaxwell> I once found a mtgox transaction that was created almost a year before but managed to never make it into the chain (maybe wasn't relayed well), and was still valid.
03:52 < CodeShark> and ultimately, being extra careful also means creating a bottleneck and greatly reducing transaction processing volume (or grinding to a halt)...which some consider bad for business
03:54 < GitHub86> [bitcoin] paveljanik opened pull request #7066: [Trivial,Doc] Add missing "blocktime" description to listtransactions help, fix formatting. (master...listtransactions_blocktime) https://github.com/bitcoin/bitcoin/pull/7066
03:54 < CodeShark> gmaxwell: where did you find it? :)
03:55 < gmaxwell> For people I've helped with this, they did batch correction, where basically they shut down operations temporarily, waited for all outstanding to confirm, extracted all the transactions, checked all the conflicted outputs against the blockchain to figure out who hadn't been paid yet. zapped the wallet. Redid the missing payments with a transaction that spend all their coins.  
03:56 < gmaxwell> (and also split up their wallet into new outputs, so they could reasonably run with spending unconfirmed change off)
03:59 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Remote host closed the connection]
03:59 -!- Thireus1 [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
04:00 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
04:00 -!- Thireus1 [~Thireus@icy.thireus.fr] has quit [Remote host closed the connection]
04:04 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Ping timeout: 240 seconds]
04:06 < kanzure> huh, what are the chances of an ancient mtgox transaction still being valid? i mean, that would require a lot of utxos..
04:07 < gmaxwell> mtgox intentional split their wallet into tiny utxo.
04:08 < gmaxwell> My memory is a bit fuzzy, I think what the sequence of events was is that when mtgox was imploding I was trying to determine all the addresses that were theirs. And someone had been logging their api output that listed all their transactions.. and I was going through all that to find every address they every claimed to sign for.
04:09 < gmaxwell> And noticed that one of the old ones had an unspent input.
04:09 < kanzure> smaller than dust?
04:09 -!- MarcoFalke [50edb194@gateway/web/cgi-irc/kiwiirc.com/ip.80.237.177.148] has joined #bitcoin-core-dev
04:10 < gmaxwell> no, not that small. The code that did that is public in that leaked php I think.
04:10 < tulip> the repo with all of the logged transactions is on github, somewhere. 
04:11 < kanzure> tulip: ah didn't know, thanks
04:11 < kanzure> v. nice to have this historical data
04:12 < gmaxwell> I think the algorithim was something like if a txout is >threshold (10btc?) split, with a ration that is some exponential distribution, with 50/50 the most common, or something like that. (could be my imagination)
04:13 < gmaxwell> s/ration/ratio/
04:13 < tulip> https://gist.github.com/alainmeier/9319451#file-mtgox-php-L120-L151
04:14 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
04:15 -!- Thireus1 [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
04:16 < midnightmagic> tulip: don't suppose you'd be willing to dig that github repo up would you?
04:19 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Ping timeout: 265 seconds]
04:22 < midnightmagic> gmaxwell: corruption again on the ppc system. I'm doing a reindex..
04:23 < tulip> kanzure: midnightmagic: https://github.com/mtgoxtxfeed/json
04:23 < midnightmagic> tulip: thank you
04:27 < GitHub15> [bitcoin] jonasschnelli opened pull request #7067: [Wallet] improve detection of conflicted transactions (master...2015/11/mempool_wallet) https://github.com/bitcoin/bitcoin/pull/7067
04:28 < midnightmagic> gmaxwell: progress projects a 6-9 day reindex. do you want me to just let you know when it gets to head, or is that fact it's churning right now good enough for you? commitid: a1bfca80521ee99d70bc19a797484275d84e136f
04:31 < gmaxwell> midnightmagic: that its churning is good information!
04:32 -!- PaulCape_ [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
04:32 < midnightmagic> gmaxwell: okie doke.
04:34 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Ping timeout: 264 seconds]
05:05 < GitHub146> [bitcoin] jonasschnelli opened pull request #7068: [RPC-Tests] add simple way to run rpc test over QT clients (master...2015/11/rpc_tests_qt) https://github.com/bitcoin/bitcoin/pull/7068
05:09 < gmaxwell> [OT] Sad news, ITU announces that they've decided to not stop creating leapseconds for now, and spend 8 more years researching the impact.
05:21 -!- tulip [~tulip@128.199.135.43] has quit []
05:27 < GitHub117> [bitcoin] MarcoFalke opened pull request #7069: [trivial] Fix -maxmempool InitError (master...MarcoFalke-2015-maxmempoolInitError) https://github.com/bitcoin/bitcoin/pull/7069
05:34 < GitHub192> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/07b770caf3f5...776848acefa8
05:34 < GitHub192> bitcoin/master c197798 Jonas Schnelli: [Qt] simple mempool info in debug window
05:34 < GitHub192> bitcoin/master 776848a Wladimir J. van der Laan: Merge pull request #6979...
05:34 < GitHub105> [bitcoin] laanwj closed pull request #6979: [Qt] simple mempool info in debug window (master...2015/11/qt_mempool_easyinfo) https://github.com/bitcoin/bitcoin/pull/6979
05:35 -!- tulip [~tulip@128.199.135.43] has joined #bitcoin-core-dev
05:39 -!- tulip [~tulip@128.199.135.43] has quit [Changing host]
05:39 -!- tulip [~tulip@unaffiliated/tulip] has joined #bitcoin-core-dev
05:54 -!- guest234234 [~guest2342@223.207.239.241] has joined #bitcoin-core-dev
05:55 -!- ParadoxSpiral [~ParadoxSp@p508B85F4.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
06:02 -!- teward [teward@ubuntu/member/teward] has quit [Ping timeout: 240 seconds]
06:03 -!- gmaxwell [greg@wikimedia/KatWalsh/x-0001] has quit [Ping timeout: 240 seconds]
06:03 -!- gmaxwell [greg@mf4-xiph.osuosl.org] has joined #bitcoin-core-dev
06:03 -!- gmaxwell is now known as Guest61914
06:04 -!- Guest61914 [greg@mf4-xiph.osuosl.org] has quit [Changing host]
06:04 -!- Guest61914 [greg@wikimedia/KatWalsh/x-0001] has joined #bitcoin-core-dev
06:05 -!- Guest61914 is now known as gmaxwell
06:06 -!- teward [teward@ubuntu/member/teward] has joined #bitcoin-core-dev
06:21 -!- tulip [~tulip@unaffiliated/tulip] has quit []
06:33 -!- guest234234 [~guest2342@223.207.239.241] has quit [Ping timeout: 265 seconds]
06:36 < jtimon_> morcos: ping https://github.com/jtimon/bitcoin/commit/6963b9ccb2c889564a2e0239aa73f03f6d406784
06:47 < morcos> jtimon: i saw that.  i like the idea, but not exactly that.  I think it is usefull for TrimToSize still take an argument, and TrimToSize should then set the internal attribute of the mempool letting it know what size it has been set to.
06:48 < morcos> That way the policy logic on what size the mempool should be trimmed to is outside the mempool.  GetMinFee could access that internal attribute in the same way you have it
06:49 < morcos> I don't love calling that from txmempool.cpp, since I'd like that pass through function to go away, and the policy estimator to be called directly from the wallet I htink?
06:49 < morcos> My concern about that is someone needs to know to ask the mempool for its min fee if you want to estimate fees?  Where should that logic live.  IN my opinion not in the mempool.  
06:50 < morcos> So it doesn't seem unreasonable to me that the policyestimator is going to need to ask the mempool questions.  what questions it needs to ask and what it does with them, seem logic that could live in the estimator itself.  and therefore you have to pass in a pool, but i don't know... 
06:53 < morcos> In any case, I'm out of town for the next week+ so I'm not really going to have much time to modify it myself.  However if we end up with some changes that we think are good, I'm happy for you or sdaftuar to incorporate them
07:17 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
07:21 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has joined #bitcoin-core-dev
07:36 -!- zooko is now known as zookolaptop
07:51 -!- CodeShark [uid126576@gateway/web/irccloud.com/x-bglnlpiloitkxvrk] has quit [Quit: Connection closed for inactivity]
07:52 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
07:58 < GitHub11> [bitcoin] MarcoFalke opened pull request #7070: Move hardcoded maxFeeRate out of mempool (master...MarcoFalke-2015-feeRateRefactor) https://github.com/bitcoin/bitcoin/pull/7070
08:12 -!- zookolaptop [~user@c-73-217-16-2.hsd1.co.comcast.net] has quit [Ping timeout: 276 seconds]
08:27 -!- zooko` [~user@172.56.9.96] has joined #bitcoin-core-dev
08:37 -!- zooko`` [~user@2601:281:8001:26aa:7c2c:2601:b748:7d8a] has joined #bitcoin-core-dev
08:38 -!- zooko` [~user@172.56.9.96] has quit [Ping timeout: 260 seconds]
08:53 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has quit [Ping timeout: 272 seconds]
09:04 -!- zooko`` [~user@2601:281:8001:26aa:7c2c:2601:b748:7d8a] has quit [Ping timeout: 240 seconds]
09:27 -!- skyraider [uid41097@gateway/web/irccloud.com/x-eqjuuaqhsudjecwx] has joined #bitcoin-core-dev
09:30 -!- trippysalmon [rob@2001:984:6466:0:a0d3:d9b8:fab7:bab3] has joined #bitcoin-core-dev
09:35 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
09:41 -!- JackH [~Jack@host-80-43-142-236.as13285.net] has quit [Ping timeout: 244 seconds]
10:39 < phantomcircuit> jgarzik, in CDB::Close activeTxn is closed if it's open, this is legacy code from satoshi, but your'e the last to have touched it
10:39 < phantomcircuit> any idea why that's there?
10:59 -!- zooko` [~user@72.42.70.227] has joined #bitcoin-core-dev
11:14 -!- zooko` is now known as zookolaptop
11:19 -!- moli [~molly@unaffiliated/molly] has quit [Read error: Connection reset by peer]
11:20 < jgarzik> phantomcircuit, speed IIRC.  We fiddled a lot with that during IBD tuning days.  IBD was very sensitive to when things were flushed
11:20 < jgarzik> phantomcircuit, without special logic at close, shutdown would pause for a long time
11:23 < phantomcircuit> jgarzik, i can see that support for nested transactions was dropped but i dont see what this has to do with flush logic
11:24 < jgarzik> phantomcircuit, state mgmt -- during IBD you held the transaction open because you might get more blocks
12:52 -!- zookolaptop [~user@72.42.70.227] has quit [Remote host closed the connection]
12:53 -!- zookolaptop [~user@72.42.70.227] has joined #bitcoin-core-dev
12:58 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Read error: Connection reset by peer]
12:59 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
13:06 -!- zookolaptop [~user@72.42.70.227] has quit [Ping timeout: 255 seconds]
13:08 < phantomcircuit> jgarzik, hmm
13:08 < jgarzik> phantomcircuit, since you might be in the middle of IBD during shutdown, you might have a transaction open on purpose
13:09 < jgarzik> phantomcircuit, keeping the transaction open is poor man's write batching in the face of async "block" msgs
13:09 < phantomcircuit> jgarzik, the wallet keeps a transaction open?
13:09 < phantomcircuit> i can see leveldb doing that but why would the wallet need to do that
13:09 < jgarzik> phantomcircuit, BDB transaction
13:09 < phantomcircuit> ohhh it's from when we were using bdb for the chain state
13:10 < jgarzik> phantomcircuit, nod -- I'm talking about logic put in place during the days when we stored chain state in there
13:10 < phantomcircuit> ok so that can be safely changed to be an assert
13:10 < jgarzik> phantomcircuit, wallet should never do that
13:10 < jgarzik> indeed
13:11 < phantomcircuit> jgarzik, great that will make a bunch of stuff much easier for me
13:15 < GitHub82> [bitcoin] pstratem opened pull request #7071: Wallet: Replace TxnAbort with assert. (master...2015-11-20-wallet-activetxn) https://github.com/bitcoin/bitcoin/pull/7071
13:19 -!- trippysalmon [rob@2001:984:6466:0:a0d3:d9b8:fab7:bab3] has quit [Ping timeout: 250 seconds]
13:55 -!- zookolaptop [~user@2601:281:8001:26aa:7c2c:2601:b748:7d8a] has joined #bitcoin-core-dev
13:58 < Luke-Jr> http://www.darlinghq.org/ maybe useful for running Mac test suite in Travis?
14:05 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has quit [Quit: Textual IRC Client: www.textualapp.com]
14:15 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
14:29 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Read error: Connection reset by peer]
14:30 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
14:35 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: Connection reset by peer]
14:36 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev
14:36 -!- JackH [~Jack@host-80-43-142-236.as13285.net] has joined #bitcoin-core-dev
14:48 -!- PaulCape_ [~PaulCapes@204.28.124.82] has quit [Quit: .]
14:49 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
14:49 -!- zmanian_ [sid113594@gateway/web/irccloud.com/x-jcpcgdmbossuwhfs] has quit [Ping timeout: 250 seconds]
14:50 -!- btcdrak [uid115429@gateway/web/irccloud.com/x-oxmyfwfrtctnavdc] has quit [Ping timeout: 272 seconds]
14:54 < midnightmagic> WOO 4.9% PROGRESS
14:54  * midnightmagic stabs old crappy ppc
14:54 < midnightmagic> I wonder if there's some assembly we could take advantage of on ppc..
14:56 -!- molly [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
15:04 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
15:08 -!- molly [~molly@unaffiliated/molly] has quit [Ping timeout: 276 seconds]
15:12 -!- d_t_ [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
15:14 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Ping timeout: 252 seconds]
15:18 -!- d_t_ [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Ping timeout: 250 seconds]
15:20 -!- molly [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
15:24 -!- zmanian_ [sid113594@gateway/web/irccloud.com/x-trszzgfujeczpftq] has joined #bitcoin-core-dev
15:24 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 276 seconds]
15:26 -!- btcdrak [uid115429@gateway/web/irccloud.com/x-dtfjcmuakyyewnki] has joined #bitcoin-core-dev
15:29 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
15:32 -!- molly [~molly@unaffiliated/molly] has quit [Ping timeout: 276 seconds]
15:36 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
15:38 -!- guest234234 [~guest2342@223.207.239.241] has joined #bitcoin-core-dev
15:38 -!- d_t_ [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
15:41 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Ping timeout: 276 seconds]
15:42 -!- JackH [~Jack@host-80-43-142-236.as13285.net] has quit [Ping timeout: 240 seconds]
15:48 < gmaxwell> anyone else notice the 2015-11-20 23:47:23 Invalid or missing banlist.dat; recreating
15:48 < gmaxwell> at every start?
15:48 < sipa> yup
15:49 -!- d_t_ [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Read error: Connection reset by peer]
15:50 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
15:50 < jcorgan> yes
16:06 < gmaxwell> lol, luke's #6851 reduces the time to add 53k tx to the wallet from 843 seconds to 35 seconds.
16:32 -!- ParadoxSpiral [~ParadoxSp@p508B85F4.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
16:36 -!- tripleslash_x [~triplesla@unaffiliated/imsaguy] has quit [Remote host closed the connection]
16:37 < GitHub179> [bitcoin] pstratem closed pull request #6966: [WIP] Wallet: Cache CWalletDB pointer in CWallet to improve performance (master...wallet_speedup) https://github.com/bitcoin/bitcoin/pull/6966
16:38 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev
16:51 < gmaxwell> Luke-Jr: around?
16:51 < Luke-Jr> gmaxwell: ?
16:54 < phantomcircuit> gmaxwell, comment changed and merged petertodd's fRelayTxs rpc addition
16:55 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev
17:05 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
17:15 -!- jtimon_ [~quassel@74.29.134.37.dynamic.jazztel.es] has quit [Ping timeout: 276 seconds]
17:28 -!- CodeShark [uid126576@gateway/web/irccloud.com/x-tquvgkenoajvipxr] has joined #bitcoin-core-dev
18:18 -!- gavinandresen [~gavin@unaffiliated/gavinandresen] has joined #bitcoin-core-dev
18:18 -!- morcos_ [~morcos@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
18:18 -!- nanotube [~nanotube@unaffiliated/nanotube] has quit [Excess Flood]
18:19 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Remote host closed the connection]
18:19 -!- Anduck_ [~anduck@unaffiliated/anduck] has joined #bitcoin-core-dev
18:19 -!- morcos [~morcos@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Remote host closed the connection]
18:19 -!- gavinand1esen [~gavin@unaffiliated/gavinandresen] has quit [Remote host closed the connection]
18:19 -!- Anduck [~anduck@unaffiliated/anduck] has quit [Remote host closed the connection]
18:19 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev
18:22 -!- skyraider [uid41097@gateway/web/irccloud.com/x-eqjuuaqhsudjecwx] has quit [Quit: Connection closed for inactivity]
18:28 -!- nanotube [~nanotube@unaffiliated/nanotube] has joined #bitcoin-core-dev
18:34 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-sovgqgjhecqovgzf] has quit [Quit: Connection closed for inactivity]
18:35 -!- zookolaptop [~user@2601:281:8001:26aa:7c2c:2601:b748:7d8a] has quit [Ping timeout: 240 seconds]
18:38 < GitHub132> [bitcoin] Har01d opened pull request #7072: [RPC] Add transaction size to JSON output (master...master) https://github.com/bitcoin/bitcoin/pull/7072
18:53 < midnightmagic> gmaxwell: http://0bin.net/paste/vKUjDmnyTyWAkxP2#gkQ4nb+AGhl0QZKpjE1W0oaQqM0ElXzZMseXDp+fwmY  corruption..
18:53 < GitHub123> [bitcoin] gmaxwell pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/776848acefa8...616d61b20d56
18:53 < GitHub123> bitcoin/master 3e7c891 Luke Dashjr: Optimisation: Store transaction list order in memory rather than compute it every need...
18:53 < GitHub123> bitcoin/master 616d61b Gregory Maxwell: Merge pull request #6851...
18:53 < GitHub42> [bitcoin] gmaxwell closed pull request #6851: Optimisation: Store transaction list order in memory rather than compute it every need (master...opti_txorder) https://github.com/bitcoin/bitcoin/pull/6851
18:54 < gmaxwell> midnightmagic: interesting, so that had been running without interruption and just crashed while syncing?
18:55 < midnightmagic> gmaxwell: I did a -reindex and -connect to an internal node.
18:55 < midnightmagic> bitcoind -connect=x.y.z.a -listen -daemon -nodnsseed -nodns -reindex
18:56 < gmaxwell> I guess I need to fix the ppc host to see if I can repro.
18:56 < midnightmagic> Come to think of it.. I'm not sure this machine has ever reliably sync'd to head.
18:56 < gmaxwell> midnightmagic: I think before you might have been failing when it was fine for me.
18:57 < midnightmagic> gmaxwell: Yes. At one point it seemed to be coincident with a hard-disconnect of the network in the middle of a block transfer.
18:58 < midnightmagic> Perhaps this machine is just flakey.
19:09 < midnightmagic> no other evidence of a machine problem. everything else has been running for 300+ days
19:10 < midnightmagic> drat. another one.
19:10 < midnightmagic> http://0bin.net/paste/Jf7jsnULbX4jHJIU#TlLnA8uBw6uxDrYJicVgeOgtgfN37ouH51otjBRT2jC
19:17 < midnightmagic> ooo tor stream isolation
19:23 < gmaxwell> woot, dual G5 is back up.
19:29 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving]
19:35 -!- go1111111 [~go1111111@162.244.138.37] has quit [Ping timeout: 260 seconds]
19:49 -!- go1111111 [~go1111111@104.200.154.92] has joined #bitcoin-core-dev
19:54 < midnightmagic> ooo fascinating.
19:55 -!- challisto [~challisto@c-76-16-149-33.hsd1.il.comcast.net] has joined #bitcoin-core-dev
19:55 -!- challisto [~challisto@c-76-16-149-33.hsd1.il.comcast.net] has quit [Changing host]
19:55 -!- challisto [~challisto@unaffiliated/challisto] has joined #bitcoin-core-dev
19:55 < midnightmagic> http://0bin.net/paste/mK4mOOxCYGHmdN7a#6N5+i3ta5ZuVpyVBPX3Uk5NVna+MZUvDvCz5EGc7cTx
20:13 < btcdrak> that's weird
20:17  * midnightmagic shrugs and reindexes the main node.
20:21 -!- MarcoFalke [50edb194@gateway/web/cgi-irc/kiwiirc.com/ip.80.237.177.148] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
20:24 < gmaxwell> in any case, my 2xG5 host seems to be catching up fine with git master.. taking like 10 seconds for some blocks. :)
21:10 -!- arowser [~quassel@106.120.101.38] has quit [Ping timeout: 264 seconds]
21:56 -!- tulip [~tulip@unaffiliated/tulip] has joined #bitcoin-core-dev
22:16 -!- guest234234 [~guest2342@223.207.239.241] has quit [Ping timeout: 252 seconds]
23:39 < midnightmagic> what magic incantation do you do to make it go fast
23:46 -!- ParadoxSpiral [~ParadoxSp@p508B9D5F.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
23:50 -!- lecusemble [~lecusembl@f9beb4d9.violates.me] has quit [Ping timeout: 260 seconds]
23:53 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
23:56 -!- lecusemble [~lecusembl@f9beb4d9.violates.me] has joined #bitcoin-core-dev