12015-11-20T00:17:07 *** davec has quit IRC
22015-11-20T00:20:12 *** tulip has quit IRC
32015-11-20T00:23:07 *** PRab has quit IRC
42015-11-20T00:23:13 *** davec has joined #bitcoin-core-dev
52015-11-20T00:31:21 *** tulip has joined #bitcoin-core-dev
62015-11-20T00:51:07 *** aburan28 has joined #bitcoin-core-dev
72015-11-20T01:05:51 *** aburan28 has quit IRC
82015-11-20T01:10:08 *** dcousens has joined #bitcoin-core-dev
92015-11-20T01:10:19 <dcousens> everytime I read IBLT, I think to myself "inverted bacon lettuce tomato"
102015-11-20T01:10:22 <dcousens> Sigh
112015-11-20T01:15:03 <sipa> LOL
122015-11-20T01:16:29 *** zooko has quit IRC
132015-11-20T01:25:42 *** PaulCapestany has quit IRC
142015-11-20T01:35:10 *** PaulCapestany has joined #bitcoin-core-dev
152015-11-20T01:38:13 *** zooko has joined #bitcoin-core-dev
162015-11-20T01:44:28 *** Ylbam has quit IRC
172015-11-20T01:57:07 <gmaxwell> likewise, fwiw
182015-11-20T02:08:45 *** guest234234 has joined #bitcoin-core-dev
192015-11-20T02:29:44 <GitHub122> [bitcoin] pstratem opened pull request #7064: Perform entire CWallet::TopUpKeyPool in a transaction. (master...2015-11-19-wallet-topupkeypool) https://github.com/bitcoin/bitcoin/pull/7064
202015-11-20T02:30:50 *** guest234234 has quit IRC
212015-11-20T02:34:00 <phantomcircuit> CDB::Close abort's any active transaction, it seems like any time we're calling CDB::Close and have an active transaction in play that's an exception
222015-11-20T02:35:51 *** belcher has quit IRC
232015-11-20T02:57:59 *** zooko has quit IRC
242015-11-20T03:07:16 *** teward has joined #bitcoin-core-dev
252015-11-20T03:33:28 *** guest234234 has joined #bitcoin-core-dev
262015-11-20T05:43:40 *** Guest23423 has joined #bitcoin-core-dev
272015-11-20T05:45:15 *** guest234234 has quit IRC
282015-11-20T06:02:23 *** Guest23423 has quit IRC
292015-11-20T07:21:54 *** paveljanik has quit IRC
302015-11-20T07:22:17 *** paveljanik has joined #bitcoin-core-dev
312015-11-20T07:25:51 *** MarcoFalke has joined #bitcoin-core-dev
322015-11-20T07:35:33 <GitHub13> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c983d6fcb47b...a1bfca80521e
332015-11-20T07:35:33 <GitHub13> bitcoin/master 2798e0b daniel: add powerpc build support for openssl lib
342015-11-20T07:35:34 <GitHub13> bitcoin/master a1bfca8 Wladimir J. van der Laan: Merge pull request #7059...
352015-11-20T07:35:43 <GitHub156> [bitcoin] laanwj closed pull request #7059: add powerpc build support for openssl lib (master...ppc) https://github.com/bitcoin/bitcoin/pull/7059
362015-11-20T07:38:42 <gmaxwell> I'm bummed that my ppc debian host stopped booting. I think something is wrong with the PSU.
372015-11-20T07:39:31 <midnightmagic> I still got mine running!
382015-11-20T07:40:28 <gmaxwell> midnightmagic: can you update to bitcoin core master and see that it still works there?
392015-11-20T07:40:35 <midnightmagic> sure!
402015-11-20T07:40:40 <gmaxwell> I'd wanted to use it to test the switch to libsecp256k1 validation.
412015-11-20T07:41:07 <midnightmagic> hrm. i think it's trying to do a kernel update.
422015-11-20T07:55:42 *** Ylbam has joined #bitcoin-core-dev
432015-11-20T07:58:35 *** MarcoFalke has quit IRC
442015-11-20T08:01:13 <GitHub118> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a1bfca80521e...07b770caf3f5
452015-11-20T08:01:13 <GitHub118> bitcoin/master 33b7f83 MarcoFalke: [qa] travis: cover *receivedby* rpcs
462015-11-20T08:01:14 <GitHub118> bitcoin/master 07b770c Wladimir J. van der Laan: Merge pull request #7019...
472015-11-20T08:01:18 <GitHub39> [bitcoin] laanwj closed pull request #7019: [qa] travis: cover more tests (master...MarcoFalke-2015-receivedby) https://github.com/bitcoin/bitcoin/pull/7019
482015-11-20T08:41:03 <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.
492015-11-20T08:41:39 <jonasschnelli> did you mean -1 confirmation = conflicted?
502015-11-20T08:44:50 <Luke-Jr> jonasschnelli: -1 is conflicted; that it shows -1 is a bug
512015-11-20T08:45:19 <Luke-Jr> I wonder if it's safe to use the same logic as walletconflicts for that
522015-11-20T08:46:26 <jonasschnelli> Luke-Jr: But looking at CMerkleTx::GetDepthInMainChain(), it seems like that -1 just means: "not in the chain, not in the mempool".
532015-11-20T08:46:57 <Luke-Jr> jonasschnelli: at the time that was written, it implied a conflict
542015-11-20T08:47:11 <Luke-Jr> there is an assumption that anything not conflicted, will be in the mempool or chain
552015-11-20T08:47:34 <jonasschnelli> Luke-Jr: right. This assumption fails as soon as mempool can evict txes.
562015-11-20T08:47:36 <Luke-Jr> it's possible doing a more through check could harm performance
572015-11-20T08:47:45 <Luke-Jr> so I'm not sure what the best way to fix it is
582015-11-20T08:48:14 <jonasschnelli> what about "removetransaction" call for -1 confirmations txes? GUI: right click -> remove tx?
592015-11-20T08:48:37 <Luke-Jr> so only allow removing conflicted ones?
602015-11-20T08:48:55 <jonasschnelli> right.
612015-11-20T08:49:15 <Luke-Jr> sounds fine, except s/remove/hide/ at least in the low-level
622015-11-20T08:49:25 <jonasschnelli> agreed.
632015-11-20T08:49:44 <gmaxwell> gah, sipa pointed earlier that we can just check for the actual reason.
642015-11-20T08:50:04 <gmaxwell> Luke-Jr: it won't harm performance any more than what we currently do.
652015-11-20T08:50:13 <jonasschnelli> gmaxwell: did you mean that point: http://bitcoinstats.com/irc/bitcoin-dev/logs/2015/11/19#l1447960611.0
662015-11-20T08:50:23 <Luke-Jr> gmaxwell: oh, good, so it should be easy
672015-11-20T08:50:55 <gmaxwell> jonasschnelli: yes.
682015-11-20T08:51:39 <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
692015-11-20T08:51:51 <jonasschnelli> And also, how should SPV wallet deal with mempool eviction.
702015-11-20T08:53:14 <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.
712015-11-20T08:54:24 <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?
722015-11-20T08:55:18 <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?
732015-11-20T08:55:24 <gmaxwell> It's more of a 'would be accepted in a block', but testing the mempool is a stronger version of that.
742015-11-20T08:56:09 <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.
752015-11-20T08:56:53 <Luke-Jr> jonasschnelli: I would prefer it behind-the-scenes/automatic, but that may be simpler.
762015-11-20T08:57:45 <jonasschnelli> gmaxwell: huh. Sounds after a nice solution, but probably relatively complex to implement. :)
772015-11-20T08:57:49 <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
782015-11-20T08:58:11 <Luke-Jr> hah, what I just suggested probably makes gmaxwell's look simple :D
792015-11-20T08:58:17 <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)
802015-11-20T08:58:56 <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.
812015-11-20T09:00:29 <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?
822015-11-20T09:00:44 <Luke-Jr> jonasschnelli: that's a bug because the wallet thinks it was conflicted
832015-11-20T09:01:04 <jonasschnelli> But also a feature? so "archivetransaction" is just a "visibility" thing?
842015-11-20T09:01:13 <Luke-Jr> not a feature..
852015-11-20T09:01:26 <Luke-Jr> unintended harmful behaviour <.<
862015-11-20T09:01:33 <gmaxwell> It's not a feature; it's a recently introducted bug that is very harmful.
872015-11-20T09:01:35 <sipa> jonasschnelli: hell no!
882015-11-20T09:01:36 <jonasschnelli> But if your transaction got evicted (to less fees), you can automatically create a new-one?
892015-11-20T09:02:07 <Luke-Jr> jonasschnelli: you can't deterministically respend it.. only accidentally
902015-11-20T09:02:23 <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.
912015-11-20T09:02:29 <Luke-Jr> so if you tried to RBF this way, you could quite easily end up sendign the payment twice
922015-11-20T09:02:38 <sipa> jonasschnelli: when the mempool evicts, you specifically do not want to make the coins available again
932015-11-20T09:03:03 <jonasschnelli> sipa: so the only way to re-use the inputs would be with RBF?
942015-11-20T09:03:28 <jonasschnelli> would be/should be
952015-11-20T09:03:31 <sipa> jonasschnelli: you only do that when the reason for not being in the mempool is conflict with the blockchain
962015-11-20T09:03:33 <gmaxwell> jonasschnelli: no, we need to fix that conflict check to work correctly now that eviction is possible.
972015-11-20T09:03:48 <sipa> jonasschnelli: read the meeting log
982015-11-20T09:04:18 <gmaxwell> They should only become available again once actually conflicted (or to a RBF respend which still pays the original destination)
992015-11-20T09:04:23 <sipa> jonasschnelli: RBF is a full node side thing, not a wallet thing
1002015-11-20T09:04:58 <gmaxwell> but we probably shouldn't be implementing wallet replacement behavior yet, not until after it's generally available in the network.
1012015-11-20T09:05:19 <gmaxwell> Though yes, archive would be just a visibility thing.
1022015-11-20T09:05:30 <gmaxwell> (and potentially memory usage and performance)
1032015-11-20T09:07:05 <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
1042015-11-20T09:07:46 <Luke-Jr> â¦no
1052015-11-20T09:08:04 <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.
1062015-11-20T09:08:23 <Luke-Jr> if the transaction isn't conflicted, then confirmations != -1
1072015-11-20T09:09:19 <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)
1082015-11-20T09:09:24 <sipa> the easiest, but ugly way, is to check the return validation state code from accepttomemorypool
1092015-11-20T09:10:43 <gmaxwell> (well perhaps not, since position is uncachable.; though a mempoolposition <txid> wouldn't be bad.)
1102015-11-20T09:12:52 <Luke-Jr> feels like something that we'd be likely to want to change after 0.12 IMO
1112015-11-20T09:13:15 <Luke-Jr> (although I wanted to give a good example reason, but I couldn't come up with one)
1122015-11-20T09:13:52 <gmaxwell> Luke-Jr: what would be?
1132015-11-20T09:14:11 <Luke-Jr> gmaxwell: mempool position of tx stuff
1142015-11-20T09:14:32 <Luke-Jr> the exposed interface seems not necessarily obvious
1152015-11-20T09:17:28 <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...
1162015-11-20T09:19:21 *** Guest23423 has joined #bitcoin-core-dev
1172015-11-20T09:21:03 <Luke-Jr> jonasschnelli: that's not the issue
1182015-11-20T09:21:12 <Luke-Jr> the UTXOs are confirmed, in this case
1192015-11-20T09:21:32 <Luke-Jr> but they are also spent already.
1202015-11-20T09:22:19 <Luke-Jr> that nDepth is the UTXO's transaction depth, not the spending transaction's depth
1212015-11-20T09:23:35 <jonasschnelli> Argh. Right...
1222015-11-20T09:24:32 <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
1232015-11-20T09:25:55 <gmaxwell> https://www.reddit.com/r/Bitcoin/comments/3tigrp/comcast_data_caps_will_make_nodes_running_with/
1242015-11-20T09:26:45 *** paveljanik has quit IRC
1252015-11-20T09:26:46 *** Guest23423 has quit IRC
1262015-11-20T09:29:26 <jonasschnelli> Luke-Jr: so that a relevant part?: https://github.com/bitcoin/bitcoin/blob/master/src/wallet/wallet.cpp#L459
1272015-11-20T09:30:20 <sipa> jonasschnelli: no
1282015-11-20T09:30:27 *** CodeShark has joined #bitcoin-core-dev
1292015-11-20T09:30:36 <sipa> jonasschnelli: the relevant part is the GetDepthInMainChain computation
1302015-11-20T09:30:40 <Luke-Jr> jonasschnelli: the only part that needs to be touched right now, is GetDepthInMainChain
1312015-11-20T09:30:46 <sipa> which looks at the mempool
1322015-11-20T09:31:05 <sipa> if it isn't in the mempool, it should just return 0
1332015-11-20T09:31:31 <sipa> upon first submit, and upon eviction, we should check the return value of accepttomemorypool
1342015-11-20T09:32:13 <sipa> and when that indicates it's due to missing input, set a boolean flag remember in the wallet
1352015-11-20T09:32:14 <Luke-Jr> sipa: well, it needs to return -1 when conflicted or we break other stuff
1362015-11-20T09:32:37 <Luke-Jr> or rather, <0
1372015-11-20T09:32:46 <sipa> and when GetDepthInMemoryPool would return 0 and that flag is said, only then return -1
1382015-11-20T09:32:53 <Luke-Jr> IIRC the original plan was -1 if the conflicting tx was 1 block deep; -2 and so on for more blocks
1392015-11-20T09:33:17 <sipa> right, that's an older idea that becomes viable again
1402015-11-20T09:33:18 <Luke-Jr> but no need to do that now
1412015-11-20T09:33:22 <sipa> indeed
1422015-11-20T09:34:43 <sipa> Luke-Jr: we also need to be informee on eviction, with the reason for that eviction (or alternatively, resubmit upon eviction)
1432015-11-20T09:35:22 <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
1442015-11-20T09:35:53 <sipa> Luke-Jr: the resubmit would fail
1452015-11-20T09:36:05 <sipa> Luke-Jr: the reason to do is to find out why it fails
1462015-11-20T09:36:24 <Luke-Jr> ah
1472015-11-20T09:40:55 *** guest234234 has joined #bitcoin-core-dev
1482015-11-20T09:45:13 <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?
1492015-11-20T09:47:02 <sipa> jonasschnelli: read 5 lines up
1502015-11-20T09:47:50 <gmaxwell> We shouldn't depend on submission or resubmission.
1512015-11-20T09:48:01 <sipa> gmaxwell: hmm?
1522015-11-20T09:48:11 <sipa> submission certainly
1532015-11-20T09:48:19 <gmaxwell> For example, if walletbroadcast=0 we should still learn when it goes conflicted.
1542015-11-20T09:48:22 <jonasschnelli> Saw that. But would that still require to evaluate the pfMissingInputs on first submitting?
1552015-11-20T09:48:27 <sipa> gmaxwell: ugh
1562015-11-20T09:48:52 <sipa> so we need an AcceptToMemoryPool dryrun mode?
1572015-11-20T09:48:57 <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.
1582015-11-20T09:49:24 <sipa> ok, i guess it's easier then to add a main function CheckForConflicgts
1592015-11-20T09:49:39 <sipa> and call then if submission fails or is skipped, or we are evicted
1602015-11-20T09:49:48 <sipa> and cache the result
1612015-11-20T09:49:59 <gmaxwell> I don't think we need to do anything with evicted?
1622015-11-20T09:50:17 <sipa> eviction also happens on block confirm, no?
1632015-11-20T09:50:22 <gmaxwell> just cache until blockchain tip changes,
1642015-11-20T09:50:47 <sipa> ok, that seems reasonable
1652015-11-20T09:51:21 <sipa> or even cache the blockindex itself, and as long as the active one descends from it, don't reevaluate if true
1662015-11-20T09:51:42 <gmaxwell> seperately it would be interesting to know if a txn was in-mempool or not, but I think thats not really cachable. :(
1672015-11-20T09:51:48 <sipa> right
1682015-11-20T09:52:14 <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.
1692015-11-20T09:54:36 <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.
1702015-11-20T10:04:32 <sipa> gmaxwell: yes, because such a conflict check will pull in dependent utxos from the chainstate
1712015-11-20T10:04:42 <sipa> so icthink we want to avoid that at all costs
1722015-11-20T10:08:19 <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.
1732015-11-20T10:20:51 <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
1742015-11-20T10:21:15 <jonasschnelli> There is no check right now when adding a wtx to the wallet.
1752015-11-20T10:28:38 <sipa> gmaxwell: well you need to check whether all inputs are available
1762015-11-20T10:28:53 <sipa> gmaxwell: which means looking at the utxo set, not just the wallet
1772015-11-20T10:30:58 <sipa> jonasschnelli: GetDepthInMainChain should return 0 if not conflicted
1782015-11-20T10:31:00 <gmaxwell> I don't think you do, you do that via the conflicted check, which is cached.
1792015-11-20T10:31:28 <sipa> gmaxwell: i'm confused; how could you detect a conflict with mempool that limited to zero?
1802015-11-20T10:31:46 <sipa> it's trivial if you see some inputs spent in the utxo set
1812015-11-20T10:31:58 <jonasschnelli> sipa: i think it should return 0 in that case (GetDepthInMainChainINTERNAL will result in 0), but will check
1822015-11-20T10:32:18 <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.
1832015-11-20T10:32:34 <sipa> gmaxwell: ok, i agree there
1842015-11-20T10:32:48 <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.
1852015-11-20T10:32:56 <gmaxwell> What I suggest wouldn't distinguish an in-mempool conflict with too-low-fee, but I think thats no big loss.
1862015-11-20T10:33:17 <sipa> gmaxwell: minimal viable solution firstz place
1872015-11-20T10:33:21 <sipa> grrr
1882015-11-20T10:33:27 <sipa> minimal viable solution first
1892015-11-20T10:33:49 <gmaxwell> ya ya. mostly its an observation that the direct test doesn't preclude also having a reasonable cheap mempoolness check.
1902015-11-20T10:34:35 <sipa> what difference does in-mempoolness make? how do we report the result?
1912015-11-20T10:35:24 <gmaxwell> sipa: listtransactions output, tells you if your unconfirmed tx is probably screwed. :)
1922015-11-20T10:36:26 <sipa> gmaxwell: all i was saying is that jonas' conflict check shouldn't (only) look at the mempool but at the utxo set
1932015-11-20T10:37: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...)
1942015-11-20T10:38:16 <gmaxwell> yes, I agree, -1 should mean blockchain conflict.
1952015-11-20T10:38:40 <gmaxwell> But if it does; it's useful to know that the transaction isn't in the mempool.
1962015-11-20T10:38:47 <sipa> sure
1972015-11-20T10:38:59 <gmaxwell> Ideally we'd give the depth of the earliest conflict, but sadly thats stupidly expensive to do. :(
1982015-11-20T10:39:23 <gmaxwell> at least with how things are structured now.
1992015-11-20T10:39:24 <sipa> not when there are other txouts of the txid still in the utxo set
2002015-11-20T10:39:35 <gmaxwell> yes, sure but thats not reliable.
2012015-11-20T10:39:38 <sipa> indeed
2022015-11-20T10:39:48 <CodeShark> txindex? :)
2032015-11-20T10:39:55 <gmaxwell> we could do it so long as we captured it as it flew by and recorded it in the wallet.
2042015-11-20T10:40:01 <sipa> CodeShark: die!
2052015-11-20T10:40:04 <CodeShark> lol
2062015-11-20T10:40:17 <sipa> CodeShark: it's german for "the"
2072015-11-20T10:41:07 <CodeShark> feminine nominative/accusative
2082015-11-20T10:41:14 <sipa> correct!
2092015-11-20T10:41:27 <gmaxwell> http://flyingscotsman.tumblr.com/post/3486957620/laywer-well-what-about-that-tattoo-on-your
2102015-11-20T10:41:56 <CodeShark> Ich weiss etwas Deutch Grammatik :)
2112015-11-20T10:42:22 <CodeShark> *Deutsch
2122015-11-20T10:42:31 <CodeShark> not dutch :p
2132015-11-20T10:42:51 <CodeShark> although dutch grammar is simpler
2142015-11-20T10:42:53 <CodeShark> but offtopic
2152015-11-20T10:43: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
2162015-11-20T10:43:46 <CodeShark> Bart is a girl? :)
2172015-11-20T10:45:21 <CodeShark> gmaxwell: you mean only flush txs from mempool once they're sufficiently buried?
2182015-11-20T10:45:51 <sipa> CodeShark: we're talking about the wallet
2192015-11-20T10:46:03 <CodeShark> right - so the wallet needs its own mempool :)
2202015-11-20T10:46:10 <CodeShark> I remember this topic a couple years ago
2212015-11-20T10:46:15 <gmaxwell> it's not really a mempool thing at all.
2222015-11-20T10:46:34 <CodeShark> well, it needs to keep track of its own transactions
2232015-11-20T10:46:39 <CodeShark> and dependencies
2242015-11-20T10:47:51 <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.
2252015-11-20T10:47:58 <sipa> gmaxwell: it's really quite complicated... the question for each input is whether the corresponding is available or would become available.
2262015-11-20T10:48:11 <sipa> . which means looking at the wallet, the mempool, and the utxo set
2272015-11-20T10:48:43 <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.
2282015-11-20T10:49:37 <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.
2292015-11-20T10:50:37 <sipa> how do you define "hit -1"
2302015-11-20T10:50:56 <sipa> all you can observe reliably is that there is an input missing
2312015-11-20T10:51:24 <gmaxwell> I know, as I said 'approximation'.
2322015-11-20T10:51:38 <sipa> ok
2332015-11-20T10:51:47 <CodeShark> 2 + 2 approximates 5 for sufficiently large values of 2
2342015-11-20T10:52:02 <sipa> but that check does not output a height
2352015-11-20T10:52:08 <sipa> and it depends on the mempool
2362015-11-20T10:52:44 <gmaxwell> why does it depend on the mempool?
2372015-11-20T10:52:57 <CodeShark> dependencies
2382015-11-20T10:53:09 <sipa> because unconfirmed inputs won't be in the utxo set
2392015-11-20T10:53:23 <gmaxwell> They'll be in the wallet.
2402015-11-20T10:53:26 <CodeShark> no
2412015-11-20T10:53:28 <CodeShark> not necessarily
2422015-11-20T10:53:36 <CodeShark> they don't necessarily belong to the wallet
2432015-11-20T10:53:37 <sipa> not for things that pay you
2442015-11-20T10:53:57 <CodeShark> someone could construct a chain of unconfirmed transactions, only the last one pays you
2452015-11-20T10:54:00 <gmaxwell> oh right, also recieved transactions can be conflicted. It's true.
2462015-11-20T10:54:17 <CodeShark> for intelligent conflict detection, the wallet must be alerted when any dependency is conflicted
2472015-11-20T10:54:28 <gmaxwell> sorry, had slipped into thinking only in terms of sent because I was thinking about the free to reuse question.
2482015-11-20T10:54:36 <sipa> received transactions matter even more, because they're the only ones that give spendable outputs
2492015-11-20T10:54:56 <gmaxwell> sipa: 0_o. change.
2502015-11-20T10:55:33 <sipa> oh, right
2512015-11-20T10:55:39 <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!)
2522015-11-20T10:55:41 <Luke-Jr> gmaxwell: just send all your change to sipa and that problem goes away
2532015-11-20T10:56:08 * sipa approves
2542015-11-20T10:56:17 <gmaxwell> new wallet feature: eliminates all malleability problems by sending your coins to sipa.
2552015-11-20T10:56:34 <Luke-Jr> :D
2562015-11-20T10:57:19 <sipa> gmaxwell: now.i wonder what googly eyes are...
2572015-11-20T10:57:54 <Luke-Jr> sipa: "0_o"
2582015-11-20T11:00:16 <CodeShark> basically, there currently is no safe way to spend an unconfirmed output ;)
2592015-11-20T11:00:31 <CodeShark> even your own
2602015-11-20T11:01:43 <CodeShark> for some malleability attacks about the best you can do is sign all likely cases
2612015-11-20T11:02:03 <CodeShark> and have the txs ready to broadcast
2622015-11-20T11:03:59 <wumpus> there's an option in bitcoin core's wallet to not spend any unconfirmed outputs
2632015-11-20T11:04:15 <CodeShark> but then your funds potentially get tied up for a while
2642015-11-20T11:04:44 <wumpus> it is only not the default because that was deemed too big a change from previous behavior
2652015-11-20T11:04:58 <CodeShark> and it's also impractical in many scenarios
2662015-11-20T11:05:06 <gmaxwell> CodeShark: well it'll be pratically pretty safe soon.
2672015-11-20T11:05:13 <sipa> gmaxwell: the wallet does get informed about all blockchain transactions, so i think we can just use that to detect conflicts
2682015-11-20T11:05:27 <CodeShark> yes, indeed - I'm very happy about that, gmaxwell
2692015-11-20T11:05:36 <gmaxwell> The don't spend unconfirmed change thing is pretty obnoxious unless you understand bitcoins operation very well and intentionally create extra outputs.
2702015-11-20T11:05:47 <wumpus> anything involving zero confirmation is risky
2712015-11-20T11:06:01 <sipa> we should be creating extra outputs anyway for amount privacy
2722015-11-20T11:06:09 <CodeShark> about the best way to mitigate having funds tied up for a while is to create denominated outputs up front
2732015-11-20T11:06:24 <CodeShark> which is ugly in terms of block chain bloat
2742015-11-20T11:06:26 <wumpus> absolutely, better output management could avoid having *all* your funds tied up
2752015-11-20T11:06:55 <wumpus> e.g. by having multiple change outputs
2762015-11-20T11:06:56 <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. :( )
2772015-11-20T11:07:00 <btcdrak> BIP68 bip text has been updated https://github.com/bitcoin/bips/issues/245
2782015-11-20T11:07:51 <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.
2792015-11-20T11:08:17 <sipa> gmaxwell: yup, that'd be useful
2802015-11-20T11:08:28 <sipa> gmaxwell: except when the payment is a nice round number
2812015-11-20T11:08:52 <sipa> gmaxwell: then you probably always want to make the change identical to it (or a round fraction/muktiple)
2822015-11-20T11:09:06 <CodeShark> denominating outputs in powers of 2 and limiting precision can help
2832015-11-20T11:09:23 <CodeShark> sometimes having the extra precision means adding dust outputs :)
2842015-11-20T11:09:37 <gmaxwell> sipa: well the decision could be biased, but the basic idea is reasonable.
2852015-11-20T11:09:43 <sipa> gmaxwell: agree
2862015-11-20T11:15:27 *** d_t has quit IRC
2872015-11-20T11:19:13 <sipa> gmaxwell: if conflicting wallet transactions with change
2882015-11-20T11:19:33 <sipa> can be accepted without conflicting
2892015-11-20T11:19:44 <sipa> then inthink our balance calc will be off
2902015-11-20T11:20:55 *** randy-waterhouse has quit IRC
2912015-11-20T11:24:26 <CodeShark> a scheme that avoids the need for change outputs without bloating the blockchain would fix a bunch of problems
2922015-11-20T11:24:38 <CodeShark> I've also had issues with asynchronous signing
2932015-11-20T11:25:06 <CodeShark> perhaps some transaction is rejected by the authorization layer and never gets signed...which ties up the outputs
2942015-11-20T11:26:01 <CodeShark> which means it ties up any attempts to sign dependencies
2952015-11-20T11:26:02 <sipa> oh! we should only count unconfirmed transactions (from ourselves) if they are in the mempool
2962015-11-20T11:26:26 <wumpus> sounds sensible sipa
2972015-11-20T11:26:47 <sipa> but only mark them conflicted/respendable when they have a conflict in the chain
2982015-11-20T11:26:58 <wumpus> right
2992015-11-20T11:29:58 *** jtimon_ has joined #bitcoin-core-dev
3002015-11-20T11:30:19 *** jtimon has quit IRC
3012015-11-20T11:33:02 <CodeShark> more sensible than what we currently do...but still has issues
3022015-11-20T11:33:59 <CodeShark> I guess the UI could indicate that certain transactions have failed
3032015-11-20T11:34:09 <CodeShark> and prompt the user to resend
3042015-11-20T11:34:59 <CodeShark> or automatically resign and resend if the keys are unencrypted
3052015-11-20T11:35:14 <CodeShark> although that might open up security holes
3062015-11-20T11:36:05 <sipa> CodeShark: the plan was to have a function to mark a tx as failed
3072015-11-20T11:36:07 <sipa> manually
3082015-11-20T11:36:33 <CodeShark> well, other than the usability complications, it technically is consistent behavior
3092015-11-20T11:38:11 <CodeShark> and arguably less problematic than having a zero fee transaction in limbo for a long time :)
3102015-11-20T11:38:23 <tulip> is there an opportunity in all this for a user to "remove" a transaction, make an alternative with different outputs, and both confirm?
3112015-11-20T11:39:55 <gmaxwell> I'm really not keen on requiring the manual intervention, I can see this resulting in lost funds.
3122015-11-20T11:40:53 <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.
3132015-11-20T11:41:37 <gmaxwell> tulip: you mean spending different outputs (different inputs)?
3142015-11-20T11:41:49 <tulip> yes.
3152015-11-20T11:42:32 <gmaxwell> That generally exists, even now. Though they don't have a remove button which they might misunderstand to abort the transaction.
3162015-11-20T11:43:47 <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)
3172015-11-20T11:45:29 <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
3182015-11-20T11:46:17 <gmaxwell> well we have zapwallettx to knock out any conflicted/unconfirmeds from the wallet, tech support via napalm.
3192015-11-20T11:46:28 <CodeShark> lol
3202015-11-20T11:46:37 <sipa> napalm is cool, when frozen
3212015-11-20T11:47:05 <gmaxwell> ^ man, I want a bot that produces comments like that.
3222015-11-20T11:48:04 <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)
3232015-11-20T11:48:18 <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.
3242015-11-20T11:48:42 <CodeShark> but I had to eventually allow deleting even propagated transactions for malleability attacks and transactions that just won't confirm (low fees)
3252015-11-20T11:49:08 <CodeShark> and for any sort of high volume operation it's a nightmare
3262015-11-20T11:49:53 <gmaxwell> CodeShark: have you yet had someone have something deleted make it through and be surprised?
3272015-11-20T11:50:36 <CodeShark> fortunately no terrible losses have occured...but it has required extra careful manual intervention
3282015-11-20T11:51:21 *** guest234234 has quit IRC
3292015-11-20T11:52:18 <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.
3302015-11-20T11:52:45 <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
3312015-11-20T11:54:14 <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
3322015-11-20T11:54:43 <CodeShark> gmaxwell: where did you find it? :)
3332015-11-20T11:55:52 <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.
3342015-11-20T11:56:31 <gmaxwell> (and also split up their wallet into new outputs, so they could reasonably run with spending unconfirmed change off)
3352015-11-20T11:59:51 *** Thireus has quit IRC
3362015-11-20T11:59:53 *** Thireus1 has joined #bitcoin-core-dev
3372015-11-20T12:00:53 *** Thireus has joined #bitcoin-core-dev
3382015-11-20T12:00:53 *** Thireus1 has quit IRC
3392015-11-20T12:04:55 *** Thireus has quit IRC
3402015-11-20T12:06:46 <kanzure> huh, what are the chances of an ancient mtgox transaction still being valid? i mean, that would require a lot of utxos..
3412015-11-20T12:07:44 <gmaxwell> mtgox intentional split their wallet into tiny utxo.
3422015-11-20T12:08:57 <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.
3432015-11-20T12:09:15 <gmaxwell> And noticed that one of the old ones had an unspent input.
3442015-11-20T12:09:29 <kanzure> smaller than dust?
3452015-11-20T12:09:56 *** MarcoFalke has joined #bitcoin-core-dev
3462015-11-20T12:10:12 <gmaxwell> no, not that small. The code that did that is public in that leaked php I think.
3472015-11-20T12:10:36 <tulip> the repo with all of the logged transactions is on github, somewhere.
3482015-11-20T12:11:27 <kanzure> tulip: ah didn't know, thanks
3492015-11-20T12:11:39 <kanzure> v. nice to have this historical data
3502015-11-20T12:12:58 <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)
3512015-11-20T12:13:16 <gmaxwell> s/ration/ratio/
3522015-11-20T12:13:57 <tulip> https://gist.github.com/alainmeier/9319451#file-mtgox-php-L120-L151
3532015-11-20T12:14:20 *** Thireus has joined #bitcoin-core-dev
3542015-11-20T12:15:14 *** Thireus1 has joined #bitcoin-core-dev
3552015-11-20T12:16:54 <midnightmagic> tulip: don't suppose you'd be willing to dig that github repo up would you?
3562015-11-20T12:19:01 *** Thireus has quit IRC
3572015-11-20T12:22:29 <midnightmagic> gmaxwell: corruption again on the ppc system. I'm doing a reindex..
3582015-11-20T12:23:12 <tulip> kanzure: midnightmagic: https://github.com/mtgoxtxfeed/json
3592015-11-20T12:23:20 <midnightmagic> tulip: thank you
3602015-11-20T12:27:41 <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
3612015-11-20T12:28:08 <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
3622015-11-20T12:31:56 <gmaxwell> midnightmagic: that its churning is good information!
3632015-11-20T12:32:12 *** PaulCape_ has joined #bitcoin-core-dev
3642015-11-20T12:32:14 <midnightmagic> gmaxwell: okie doke.
3652015-11-20T12:34:59 *** PaulCapestany has quit IRC
3662015-11-20T13:05:43 <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
3672015-11-20T13:09:52 <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.
3682015-11-20T13:21:31 *** tulip has quit IRC
3692015-11-20T13:27:51 <GitHub117> [bitcoin] MarcoFalke opened pull request #7069: [trivial] Fix -maxmempool InitError (master...MarcoFalke-2015-maxmempoolInitError) https://github.com/bitcoin/bitcoin/pull/7069
3702015-11-20T13:34:21 <GitHub192> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/07b770caf3f5...776848acefa8
3712015-11-20T13:34:22 <GitHub192> bitcoin/master c197798 Jonas Schnelli: [Qt] simple mempool info in debug window
3722015-11-20T13:34:22 <GitHub192> bitcoin/master 776848a Wladimir J. van der Laan: Merge pull request #6979...
3732015-11-20T13:34:31 <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
3742015-11-20T13:35:35 *** tulip has joined #bitcoin-core-dev
3752015-11-20T13:39:41 *** tulip has quit IRC
3762015-11-20T13:39:41 *** tulip has joined #bitcoin-core-dev
3772015-11-20T13:54:08 *** guest234234 has joined #bitcoin-core-dev
3782015-11-20T13:55:11 *** ParadoxSpiral has joined #bitcoin-core-dev
3792015-11-20T14:02:19 *** teward has quit IRC
3802015-11-20T14:03:19 *** gmaxwell has quit IRC
3812015-11-20T14:03:26 *** gmaxwell has joined #bitcoin-core-dev
3822015-11-20T14:03:49 *** gmaxwell is now known as Guest61914
3832015-11-20T14:04:09 *** Guest61914 has joined #bitcoin-core-dev
3842015-11-20T14:05:50 *** Guest61914 is now known as gmaxwell
3852015-11-20T14:06:18 *** teward has joined #bitcoin-core-dev
3862015-11-20T14:21:11 *** tulip has quit IRC
3872015-11-20T14:33:23 *** guest234234 has quit IRC
3882015-11-20T14:36:42 <jtimon_> morcos: ping https://github.com/jtimon/bitcoin/commit/6963b9ccb2c889564a2e0239aa73f03f6d406784
3892015-11-20T14:47:40 <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.
3902015-11-20T14:48:19 <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
3912015-11-20T14:49:02 <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?
3922015-11-20T14:49:54 <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.
3932015-11-20T14:50:54 <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...
3942015-11-20T14:53:39 <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
3952015-11-20T15:17:51 *** treehug88 has joined #bitcoin-core-dev
3962015-11-20T15:21:19 *** zooko has joined #bitcoin-core-dev
3972015-11-20T15:36:42 *** zooko is now known as zookolaptop
3982015-11-20T15:51:39 *** CodeShark has quit IRC
3992015-11-20T15:52:19 *** Guyver2 has joined #bitcoin-core-dev
4002015-11-20T15:58:41 <GitHub11> [bitcoin] MarcoFalke opened pull request #7070: Move hardcoded maxFeeRate out of mempool (master...MarcoFalke-2015-feeRateRefactor) https://github.com/bitcoin/bitcoin/pull/7070
4012015-11-20T16:12:44 *** zookolaptop has quit IRC
4022015-11-20T16:27:30 *** zooko` has joined #bitcoin-core-dev
4032015-11-20T16:37:15 *** zooko`` has joined #bitcoin-core-dev
4042015-11-20T16:38:43 *** zooko` has quit IRC
4052015-11-20T16:53:53 *** dcousens has quit IRC
4062015-11-20T17:04:55 *** zooko`` has quit IRC
4072015-11-20T17:27:43 *** skyraider has joined #bitcoin-core-dev
4082015-11-20T17:30:26 *** trippysalmon has joined #bitcoin-core-dev
4092015-11-20T17:35:35 *** d_t has joined #bitcoin-core-dev
4102015-11-20T17:41:07 *** JackH has quit IRC
4112015-11-20T18:39:14 <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
4122015-11-20T18:39:18 <phantomcircuit> any idea why that's there?
4132015-11-20T18:59:58 *** zooko` has joined #bitcoin-core-dev
4142015-11-20T19:14:40 *** zooko` is now known as zookolaptop
4152015-11-20T19:19:31 *** moli has quit IRC
4162015-11-20T19:20:27 <jgarzik> phantomcircuit, speed IIRC. We fiddled a lot with that during IBD tuning days. IBD was very sensitive to when things were flushed
4172015-11-20T19:20:37 <jgarzik> phantomcircuit, without special logic at close, shutdown would pause for a long time
4182015-11-20T19:23:41 <phantomcircuit> jgarzik, i can see that support for nested transactions was dropped but i dont see what this has to do with flush logic
4192015-11-20T19:24:29 <jgarzik> phantomcircuit, state mgmt -- during IBD you held the transaction open because you might get more blocks
4202015-11-20T20:52:39 *** zookolaptop has quit IRC
4212015-11-20T20:53:56 *** zookolaptop has joined #bitcoin-core-dev
4222015-11-20T20:58:58 *** d_t has quit IRC
4232015-11-20T20:59:48 *** d_t has joined #bitcoin-core-dev
4242015-11-20T21:06:51 *** zookolaptop has quit IRC
4252015-11-20T21:08:13 <phantomcircuit> jgarzik, hmm
4262015-11-20T21:08:51 <jgarzik> phantomcircuit, since you might be in the middle of IBD during shutdown, you might have a transaction open on purpose
4272015-11-20T21:09:09 <jgarzik> phantomcircuit, keeping the transaction open is poor man's write batching in the face of async "block" msgs
4282015-11-20T21:09:25 <phantomcircuit> jgarzik, the wallet keeps a transaction open?
4292015-11-20T21:09:35 <phantomcircuit> i can see leveldb doing that but why would the wallet need to do that
4302015-11-20T21:09:35 <jgarzik> phantomcircuit, BDB transaction
4312015-11-20T21:09:53 <phantomcircuit> ohhh it's from when we were using bdb for the chain state
4322015-11-20T21:10:07 <jgarzik> phantomcircuit, nod -- I'm talking about logic put in place during the days when we stored chain state in there
4332015-11-20T21:10:19 <phantomcircuit> ok so that can be safely changed to be an assert
4342015-11-20T21:10:41 <jgarzik> phantomcircuit, wallet should never do that
4352015-11-20T21:10:43 <jgarzik> indeed
4362015-11-20T21:11:38 <phantomcircuit> jgarzik, great that will make a bunch of stuff much easier for me
4372015-11-20T21:15:25 <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
4382015-11-20T21:19:01 *** trippysalmon has quit IRC
4392015-11-20T21:55:20 *** zookolaptop has joined #bitcoin-core-dev
4402015-11-20T21:58:49 <Luke-Jr> http://www.darlinghq.org/ maybe useful for running Mac test suite in Travis?
4412015-11-20T22:05:06 *** treehug88 has quit IRC
4422015-11-20T22:15:57 *** Guyver2 has quit IRC
4432015-11-20T22:29:56 *** d_t has quit IRC
4442015-11-20T22:30:06 *** d_t has joined #bitcoin-core-dev
4452015-11-20T22:35:46 *** davec has quit IRC
4462015-11-20T22:36:01 *** davec has joined #bitcoin-core-dev
4472015-11-20T22:36:01 *** JackH has joined #bitcoin-core-dev
4482015-11-20T22:48:49 *** PaulCape_ has quit IRC
4492015-11-20T22:49:14 *** PaulCapestany has joined #bitcoin-core-dev
4502015-11-20T22:49:35 *** zmanian_ has quit IRC
4512015-11-20T22:50:28 *** btcdrak has quit IRC
4522015-11-20T22:54:06 <midnightmagic> WOO 4.9% PROGRESS
4532015-11-20T22:54:16 * midnightmagic stabs old crappy ppc
4542015-11-20T22:54:31 <midnightmagic> I wonder if there's some assembly we could take advantage of on ppc..
4552015-11-20T22:56:12 *** molly has joined #bitcoin-core-dev
4562015-11-20T23:04:47 *** moli has joined #bitcoin-core-dev
4572015-11-20T23:08:05 *** molly has quit IRC
4582015-11-20T23:12:29 *** d_t_ has joined #bitcoin-core-dev
4592015-11-20T23:14:55 *** d_t has quit IRC
4602015-11-20T23:18:30 *** d_t_ has quit IRC
4612015-11-20T23:20:18 *** molly has joined #bitcoin-core-dev
4622015-11-20T23:24:04 *** zmanian_ has joined #bitcoin-core-dev
4632015-11-20T23:24:20 *** moli has quit IRC
4642015-11-20T23:26:35 *** btcdrak has joined #bitcoin-core-dev
4652015-11-20T23:29:28 *** moli has joined #bitcoin-core-dev
4662015-11-20T23:32:47 *** molly has quit IRC
4672015-11-20T23:36:57 *** d_t has joined #bitcoin-core-dev
4682015-11-20T23:38:04 *** guest234234 has joined #bitcoin-core-dev
4692015-11-20T23:38:37 *** d_t_ has joined #bitcoin-core-dev
4702015-11-20T23:41:53 *** d_t has quit IRC
4712015-11-20T23:42:50 *** JackH has quit IRC
4722015-11-20T23:48:37 <gmaxwell> anyone else notice the 2015-11-20 23:47:23 Invalid or missing banlist.dat; recreating
4732015-11-20T23:48:41 <gmaxwell> at every start?
4742015-11-20T23:48:51 <sipa> yup
4752015-11-20T23:49:17 *** d_t_ has quit IRC
4762015-11-20T23:50:01 *** d_t has joined #bitcoin-core-dev
4772015-11-20T23:50:03 <jcorgan> yes