12016-02-12T00:00:16 *** frankenmint has joined #bitcoin-core-dev
22016-02-12T00:01:10 *** frankenmint has joined #bitcoin-core-dev
32016-02-12T00:05:22 *** frankenmint has quit IRC
42016-02-12T00:13:00 *** adnn has joined #bitcoin-core-dev
52016-02-12T00:23:34 *** jujumax has quit IRC
62016-02-12T00:24:44 *** randy-waterhouse has joined #bitcoin-core-dev
72016-02-12T00:42:43 *** zooko has joined #bitcoin-core-dev
82016-02-12T00:43:15 *** laurentmt has joined #bitcoin-core-dev
92016-02-12T00:43:38 *** laurentmt has quit IRC
102016-02-12T00:45:18 *** PRab has quit IRC
112016-02-12T00:46:11 *** laurentmt has joined #bitcoin-core-dev
122016-02-12T00:52:02 *** bsm117532 has quit IRC
132016-02-12T00:53:00 *** bsm1175321 has joined #bitcoin-core-dev
142016-02-12T00:53:24 *** frankenmint has joined #bitcoin-core-dev
152016-02-12T00:54:29 *** jujumax has joined #bitcoin-core-dev
162016-02-12T00:56:49 *** Sparyx has joined #bitcoin-core-dev
172016-02-12T00:57:33 *** mm_1 has quit IRC
182016-02-12T00:58:06 *** mm_1 has joined #bitcoin-core-dev
192016-02-12T00:59:50 *** ghtdak has quit IRC
202016-02-12T01:03:50 *** frankenmint has quit IRC
212016-02-12T01:05:23 *** ghtdak has joined #bitcoin-core-dev
222016-02-12T01:06:06 *** laurentmt has quit IRC
232016-02-12T01:09:44 *** adnn has quit IRC
242016-02-12T01:11:38 *** adnn has joined #bitcoin-core-dev
252016-02-12T01:14:26 *** frankenmint has joined #bitcoin-core-dev
262016-02-12T01:16:18 *** adnn has quit IRC
272016-02-12T01:18:17 *** frankenmint has quit IRC
282016-02-12T01:28:10 *** jujumax has quit IRC
292016-02-12T01:33:54 *** fkhan has quit IRC
302016-02-12T01:48:16 *** fkhan has joined #bitcoin-core-dev
312016-02-12T01:58:25 *** Ylbam has quit IRC
322016-02-12T02:00:10 *** dermoth has quit IRC
332016-02-12T02:00:53 *** dermoth has joined #bitcoin-core-dev
342016-02-12T02:01:07 *** jujumax has joined #bitcoin-core-dev
352016-02-12T02:02:30 *** Sparyx has quit IRC
362016-02-12T02:15:40 *** Thireus has quit IRC
372016-02-12T02:16:00 *** Thireus has joined #bitcoin-core-dev
382016-02-12T02:18:12 *** justanotheruser has quit IRC
392016-02-12T02:20:55 *** justanotheruser has joined #bitcoin-core-dev
402016-02-12T02:30:15 *** brg444 has quit IRC
412016-02-12T02:41:26 *** bityogi has quit IRC
422016-02-12T02:47:09 *** jtimon has quit IRC
432016-02-12T02:47:14 *** frankenmint has joined #bitcoin-core-dev
442016-02-12T02:56:04 <Luke-Jr> maybe it'd be easier to try to figure out 7521 here? [ gmaxwell morcos ]
452016-02-12T02:56:19 *** Sparyx has joined #bitcoin-core-dev
462016-02-12T02:57:00 <morcos> i'm here
472016-02-12T02:57:18 <sipa> Luke-Jr: with or without 7521, an evicted transaction is not accepted back into the mempool
482016-02-12T02:57:27 <sipa> without it, however, it does get rebroadcast
492016-02-12T02:57:46 <Luke-Jr> ok, but I think that's the expected/desired behaviour
502016-02-12T02:58:10 <Luke-Jr> how is it ever going to get mined if the sender/receiver don't rebroadcast it?
512016-02-12T02:58:31 <morcos> If it got evicted, its not likely to ever get mined
522016-02-12T02:58:31 <sipa> yes, that should be fixed
532016-02-12T02:58:47 <sipa> we should retry to get it into the mempool, and when it does, rebroadcast
542016-02-12T02:58:57 <sipa> but not rebroadcast despite violating your own rules
552016-02-12T02:59:25 <morcos> sipa: so you don't like the fix in 7521? or you just think we should eventually make a better one?
562016-02-12T02:59:35 <sipa> morcos: i don't think it's enough, but it's an improvement
572016-02-12T02:59:40 <morcos> i think its really unlikely to make it back into your own mempool
582016-02-12T02:59:57 <sipa> morcos: i think mempool pressure goes up and down
592016-02-12T02:59:59 <Luke-Jr> morcos: stuck transactions are never good behaviour
602016-02-12T02:59:59 <morcos> it would be much better to just abandon it and try again with a higher fee
612016-02-12T03:00:12 <Luke-Jr> we don't have wallet RBF support in 0.12..
622016-02-12T03:00:13 *** dermoth has quit IRC
632016-02-12T03:00:19 <morcos> you don't need wallet support
642016-02-12T03:00:31 <Luke-Jr> â¦
652016-02-12T03:00:45 *** jl2012 has quit IRC
662016-02-12T03:00:51 <Luke-Jr> morcos: what you're proposing there results in transactions that are literally stuck forever and unrecoverable
672016-02-12T03:00:58 *** dermoth has joined #bitcoin-core-dev
682016-02-12T03:01:04 *** jl2012 has joined #bitcoin-core-dev
692016-02-12T03:01:06 <morcos> that is what abandontransaction is for
702016-02-12T03:01:26 <Luke-Jr> abandontransaction is not usable to users
712016-02-12T03:01:39 <Luke-Jr> it shouldn't be encouraged, much less requied
722016-02-12T03:02:06 <morcos> what about the attack i and gmaxwell described above
732016-02-12T03:02:09 * Luke-Jr gets a sense we had that discussion before
742016-02-12T03:02:31 <morcos> you send small very low fee txs to random addresses
752016-02-12T03:03:01 <morcos> for instance if you send 1000 sat/kB txs repeatedly they'll eventually be accepted and then evicted/expired with high probability
762016-02-12T03:03:16 <morcos> then the nodes you sent them to will continually rebroadcast them frequently
772016-02-12T03:03:30 <Luke-Jr> 0.11 would do this too
782016-02-12T03:03:35 <morcos> both contributing to a bandwidth DoS attack and compromising their privacy
792016-02-12T03:03:44 <sipa> Luke-Jr: but with 0.11 you can't be certain
802016-02-12T03:03:53 <Luke-Jr> sipa: ?
812016-02-12T03:04:07 <Luke-Jr> 0.11 never prunes its mempool, so it will always be there
822016-02-12T03:04:12 <sipa> Luke-Jr: with current 0.12, you can send a mempool command, and if the result doesn't contain the transaction, you know it's theirs
832016-02-12T03:04:21 <Luke-Jr> ah
842016-02-12T03:04:56 <Luke-Jr> so what sipa suggested, add to our own before rebroadcasting
852016-02-12T03:05:03 <morcos> i tried that first
862016-02-12T03:05:05 <Luke-Jr> if it fails, don't rebroadcast until it doesn't fail anymore
872016-02-12T03:05:12 <morcos> as i mentioned on the PR
882016-02-12T03:05:18 <Luke-Jr> also, how frequent is wallet rebroadcast? I thought it was some hours
892016-02-12T03:05:38 <Luke-Jr> morcos: the lock shouldn't be a problem, why do you think it is?
902016-02-12T03:05:38 *** jujumax has quit IRC
912016-02-12T03:06:03 <morcos> some time in the next 30 mins
922016-02-12T03:06:07 <morcos> it looks like
932016-02-12T03:06:21 <Luke-Jr> still rare enough to be okay locking I think?
942016-02-12T03:06:42 <Luke-Jr> (on that note, we should probably never rebroadcast to the same connection twice?)
952016-02-12T03:06:45 <sipa> morcos: i wonder if rebroadcast could just call "ProcessMessage" and send a tx message to the node...
962016-02-12T03:06:48 <morcos> well, my first attempt at figuring out how it would lock makes it seem like you would have to lock cs_main while you iterate through every tx in your wallet and then send the ones that need sending
972016-02-12T03:07:20 <morcos> i think you guys are trying to solve for a non-existant problem
982016-02-12T03:07:33 <Luke-Jr> sipa: my local hacks includes abstracting the "tx" message to a function so I can basically simulate that. maybe worth upstreaming for this
992016-02-12T03:07:49 <sipa> morcos: nah, lock cs_wallet, copy the matching ones to a stack-allocated vector, unlock cs_wallet, accepttomemorypool
1002016-02-12T03:08:14 <morcos> if you have a very small mempool, then maybe you are right.. but at the size peoples mempools are now... if you get evicted/exprired... you really have no business being rebroadcast
1012016-02-12T03:08:29 <Luke-Jr> morcos: it's not a problem because we don't have the bug you'd be introducing yet! :P
1022016-02-12T03:08:38 <morcos> i'd be introducting?
1032016-02-12T03:08:59 <Luke-Jr> morcos: right now, transactions never get stuck due to failure to rebroadcast
1042016-02-12T03:09:07 *** PRab has joined #bitcoin-core-dev
1052016-02-12T03:09:38 <morcos> sipa: yeah ok, i mean i agree its solvable. but i just think its silly to solve
1062016-02-12T03:09:58 <morcos> i think you're trying to reaccept and rebroadcast garbage basically
1072016-02-12T03:10:04 <Luke-Jr> morcos: as soon as the fee rate goes up, you'd have a permanently stuck transaction
1082016-02-12T03:10:17 <Luke-Jr> and nothing the user could do to fix it
1092016-02-12T03:10:30 <sipa> morcos: there will always be transactions that are close to acceptable, and random variations push them below and above
1102016-02-12T03:11:09 <morcos> sipa: i think we made mempools big enough that the bottom of the mempool basically never gets confirmed
1112016-02-12T03:12:40 <morcos> i mean if we changed the rebroadcast interval to be once a week instead of once every 30 mins, then maybe it would make sense? but do people really want txs that might get confirmed in a week or two
1122016-02-12T03:12:51 <Luke-Jr> morcos: if the mempool is filled with spam, it could be that ONLY the bottom gets confirmed ;)
1132016-02-12T03:12:56 <morcos> it seems like its just a cleaner UI to be be like, sorry, that tx probably didnt make it
1142016-02-12T03:13:17 <morcos> anywya, i certainly don't object to attempting to stick it in the mempool first
1152016-02-12T03:13:21 <Luke-Jr> morcos: it's only an attempt every 30 mins. if it fails for a week, it will take a week..
1162016-02-12T03:13:24 <morcos> i just think its a bigger change for no good reason
1172016-02-12T03:13:33 <morcos> so i'll let someone else make that change
1182016-02-12T03:13:39 <Luke-Jr> sorry, that tx probably didnt make it <-- we cannot say this until there is a recourse
1192016-02-12T03:13:43 <aj> Luke-Jr: how would that work? bottom of the mempool = high priority, so the middle (low fee, low pri) is never confirmed? or?
1202016-02-12T03:14:05 <morcos> personally i think we should turn off all wallet rebroadcast by default
1212016-02-12T03:14:07 <Luke-Jr> aj: middle/top gets ignored by miners with better spam filters
1222016-02-12T03:14:09 <morcos> i doubt it does any good
1232016-02-12T03:14:21 <Luke-Jr> morcos: â¦
1242016-02-12T03:14:25 <aj> Luke-Jr: how do you filter spam by anything other than fee/priority?
1252016-02-12T03:14:37 <morcos> once you have propagated your tx, its either going to get mined or not
1262016-02-12T03:14:40 <Luke-Jr> aj: some spammers use repeated patterns, for example
1272016-02-12T03:14:56 <morcos> trying again (especially frequently) is not a worthwhile effort
1282016-02-12T03:14:57 <aj> Luke-Jr: is there a blog post or something about that anywhere?
1292016-02-12T03:15:02 <Luke-Jr> aj: no
1302016-02-12T03:15:11 <aj> Luke-Jr: *arrgghhh*
1312016-02-12T03:15:11 <Luke-Jr> or maybe there is, but I wouldn't know because I don't spend time on blogs
1322016-02-12T03:15:48 <aj> Luke-Jr: s/or something/or an email thread, or a reddit post, or a paper, or.../
1332016-02-12T03:15:50 <Luke-Jr> morcos: right now, it is an assumption that wallets must rebroadcast if they want transactions to get mined
1342016-02-12T03:16:00 <Luke-Jr> morcos: any wallet that fails to do so is considered broken
1352016-02-12T03:16:25 <sipa> morcos: due to non-uniform policies across nodes on the network, i think rebroadcasting actually helps confirmation
1362016-02-12T03:16:38 <sipa> though that isn't relevant here; we still rebroadcast, just not after eviction
1372016-02-12T03:16:49 <aj> Luke-Jr: or a github repo with code that discriminates between spam txes?
1382016-02-12T03:17:01 <Luke-Jr> aj: I have a spamfilter branch that isn't entirely up to date.
1392016-02-12T03:17:08 <sipa> Luke-Jr: do you use it?
1402016-02-12T03:17:19 <Luke-Jr> sipa: spamfilter? of course
1412016-02-12T03:17:31 <Luke-Jr> (merged into a current branch)
1422016-02-12T03:17:50 <aj> Luke-Jr: !!!
1432016-02-12T03:18:29 <Luke-Jr> obsolete is better than nothing at all still ;)
1442016-02-12T03:21:33 <morcos> well like i said, i'm not opposed to trying to reaccept first and then relaying. i just didn't personally think it was worth it.
1452016-02-12T03:24:30 <Luke-Jr> ok, so is someone working on this, or should I be?
1462016-02-12T03:25:36 <sipa> i'm having a look
1472016-02-12T04:12:59 *** adnn has joined #bitcoin-core-dev
1482016-02-12T04:14:17 *** Sparyx has quit IRC
1492016-02-12T04:17:06 *** adnn has quit IRC
1502016-02-12T04:29:17 <Luke-Jr> wumpus: I collected a bunch of bugfixes in master missing in 0.12 - I assume I should let them all wait for 0.12.1?
1512016-02-12T04:30:16 <Luke-Jr> mostly typos, the only ones I'd really consider are:
1522016-02-12T04:30:21 <Luke-Jr> * e54f412 peers.dat, banlist.dat recreated when missing
1532016-02-12T04:30:22 <Luke-Jr> * 54608c1 GUI: Disable tab navigation for peers tables.
1542016-02-12T04:38:30 *** zooko has quit IRC
1552016-02-12T05:05:25 *** Sparyx has joined #bitcoin-core-dev
1562016-02-12T05:06:43 *** adnn has joined #bitcoin-core-dev
1572016-02-12T05:09:42 *** lightningbot has joined #bitcoin-core-dev
1582016-02-12T05:09:44 *** jl2012 has quit IRC
1592016-02-12T05:10:11 *** Arnavion has quit IRC
1602016-02-12T05:10:16 *** Arnavion3 has joined #bitcoin-core-dev
1612016-02-12T05:10:20 *** Arnavion3 is now known as Arnavion
1622016-02-12T05:11:27 *** Cory has quit IRC
1632016-02-12T05:12:54 *** Pasha has joined #bitcoin-core-dev
1642016-02-12T05:19:47 *** Pasha is now known as Cory
1652016-02-12T05:25:09 *** jl2012 has joined #bitcoin-core-dev
1662016-02-12T05:42:01 <GitHub22> [bitcoin] luke-jr opened pull request #7522: Bugfix: Only use git for build info if the repository is actually the right one (master...bugfix_gitdir) https://github.com/bitcoin/bitcoin/pull/7522
1672016-02-12T05:42:44 <paveljanik> Luke-Jr, I understand your attitude to it - the same applies to me :-) But during years I've got some decent knowledge of it and your notation - i.e. ]AC_...[ - with reversed parens got me 8)
1682016-02-12T05:43:27 <Luke-Jr> paveljanik: it's de-quoting so it's substituted
1692016-02-12T05:43:37 <paveljanik> I was even analysing our bitcoin_qt.m4 yesterday for missing quotes etc...
1702016-02-12T05:44:12 <Luke-Jr> [] are usually called brackets in English FWIW; () are parens ;)
1712016-02-12T05:45:36 <paveljanik> in Czech, they are round (kulaté) vs. rectangle [hranaté] parens (závorky) ;-)
1722016-02-12T05:46:29 <Luke-Jr> interesting
1732016-02-12T05:46:39 <Luke-Jr> {} are sometimes "curly brackets", but usually just "braces"
1742016-02-12T05:48:53 <Luke-Jr> paveljanik: can I convince you to in 20160211_LibreSSL_compile_fix do: git rebase HEAD^ --onto 3cd836c1d
1752016-02-12T05:49:11 <paveljanik> {sloené} závorky
1762016-02-12T05:49:19 <paveljanik> Luke-Jr, sure
1772016-02-12T05:49:33 <Luke-Jr> what does sloÂené mean?
1782016-02-12T05:50:28 <paveljanik> {} are slozene zavorky, where slozene means composed
1792016-02-12T05:50:33 <Luke-Jr> i c
1802016-02-12T05:52:00 <paveljanik> Luke-Jr, done
1812016-02-12T05:52:20 <Luke-Jr> paveljanik: thanks. that will merge cleanly to 0.12 and master both
1822016-02-12T05:52:51 <Luke-Jr> someone with repo push access: care to copy tags from my fork? branch-0.{9..12}
1832016-02-12T05:55:58 <Luke-Jr> (these are the last-common-commit for the branch and master)
1842016-02-12T05:59:21 <Luke-Jr> paveljanik: oh, your new LogPrintf is missing a space
1852016-02-12T05:59:40 <Luke-Jr> quick, before anyone else notices! :P
1862016-02-12T06:02:02 <paveljanik> :-))
1872016-02-12T06:04:13 <paveljanik> force pushed
1882016-02-12T06:10:57 <Luke-Jr> thanks, utACK'd
1892016-02-12T06:16:29 *** Sparyx has quit IRC
1902016-02-12T06:22:27 <paveljanik> m4/autoconf is almost the same nightmare as sendmail's cf was.
1912016-02-12T06:40:36 <Luke-Jr> paveljanik: and somehow every attempt to replace it has been a disaster
1922016-02-12T06:56:25 <paveljanik> so called vendor-lock in ;-)
1932016-02-12T07:09:29 *** Sparyx has joined #bitcoin-core-dev
1942016-02-12T07:11:37 *** frankenmint has quit IRC
1952016-02-12T07:30:25 *** frankenmint has joined #bitcoin-core-dev
1962016-02-12T07:48:09 *** BashCo has quit IRC
1972016-02-12T07:57:26 *** Sparyx has quit IRC
1982016-02-12T08:00:44 *** paveljanik has quit IRC
1992016-02-12T08:04:57 *** Ylbam has joined #bitcoin-core-dev
2002016-02-12T08:09:03 *** BashCo has joined #bitcoin-core-dev
2012016-02-12T08:14:53 *** Sparyx has joined #bitcoin-core-dev
2022016-02-12T08:22:17 *** frankenmint has quit IRC
2032016-02-12T08:24:33 *** davec has quit IRC
2042016-02-12T08:30:03 *** zesi has joined #bitcoin-core-dev
2052016-02-12T08:30:08 *** davec has joined #bitcoin-core-dev
2062016-02-12T08:40:27 *** JackH has joined #bitcoin-core-dev
2072016-02-12T08:42:54 *** Evel-Knievel has quit IRC
2082016-02-12T08:45:06 *** Evel-Knievel has joined #bitcoin-core-dev
2092016-02-12T08:49:37 *** frankenmint has joined #bitcoin-core-dev
2102016-02-12T08:52:26 <GitHub170> [bitcoin] wodry opened pull request #7523: Fix of semantic failure "meet pay" (0.12...patch-1) https://github.com/bitcoin/bitcoin/pull/7523
2112016-02-12T08:56:46 *** Sparyx has quit IRC
2122016-02-12T09:09:19 *** zesi has quit IRC
2132016-02-12T09:12:06 <GitHub88> [bitcoin] laanwj closed pull request #7523: Fix of semantic failure "meet pay" (0.12...patch-1) https://github.com/bitcoin/bitcoin/pull/7523
2142016-02-12T09:12:06 <GitHub26> [bitcoin] laanwj pushed 2 new commits to 0.12: https://github.com/bitcoin/bitcoin/compare/04503f78c750...02d707ff37a1
2152016-02-12T09:12:06 <GitHub26> bitcoin/0.12 e473c2d wodry: Fix of semantic failure "meet pay"...
2162016-02-12T09:12:07 <GitHub26> bitcoin/0.12 02d707f Wladimir J. van der Laan: Merge #7523: Fix of semantic failure "meet pay"...
2172016-02-12T09:15:55 *** AaronvanW has joined #bitcoin-core-dev
2182016-02-12T09:16:12 *** Guyver2 has joined #bitcoin-core-dev
2192016-02-12T09:16:32 *** paveljanik has joined #bitcoin-core-dev
2202016-02-12T09:16:32 *** paveljanik has joined #bitcoin-core-dev
2212016-02-12T09:22:29 *** Sparyx has joined #bitcoin-core-dev
2222016-02-12T10:02:06 *** randy-waterhouse has quit IRC
2232016-02-12T10:13:16 *** Sparyx has quit IRC
2242016-02-12T10:16:12 <wumpus> hm RPC/univalue seems to generate invalid json on special floating point values like NaN, -inf, +inf, not sure what should be generated in that case though (and luckily there is no place in the API where those are normally returned)
2252016-02-12T10:19:51 <gmaxwell> The hashrate estimate thing left me wondering if it could return a nan in some case.
2262016-02-12T10:19:59 <gmaxwell> but it didn't look like it.
2272016-02-12T10:20:09 <gmaxwell> The ping time might be another place.
2282016-02-12T10:20:19 <gmaxwell> hm guess we don't divide there at least.
2292016-02-12T10:20:37 *** Sparyx has joined #bitcoin-core-dev
2302016-02-12T10:20:41 *** Guyver2 has quit IRC
2312016-02-12T10:20:44 <wumpus> difficulty for an all-zeros target ;)
2322016-02-12T10:21:36 <wumpus> in any case it should be fixed at some point, I'll report an issue, but doesn't look urgent.
2332016-02-12T10:23:00 *** dgenr8 has quit IRC
2342016-02-12T10:23:20 *** dgenr8 has joined #bitcoin-core-dev
2352016-02-12T10:24:50 *** dgenr8 has joined #bitcoin-core-dev
2362016-02-12T10:29:21 <wumpus> https://github.com/jgarzik/univalue/issues/19
2372016-02-12T10:37:12 <wumpus> cfields: did you find a clue why your gitian output doesn't match?
2382016-02-12T10:40:19 <gmaxwell> wumpus: have you followed the discussion about wallet transaction rebroadcast?
2392016-02-12T10:41:01 <wumpus> yes
2402016-02-12T10:41:53 <wumpus> not going to hold up 0.12.0 for another wallet issue though
2412016-02-12T10:43:36 <wumpus> at some point we just need to make the cut
2422016-02-12T10:43:51 <wumpus> I hate having to say this every release
2432016-02-12T10:46:09 <wumpus> leave something to be fixed in 0.12.1
2442016-02-12T10:46:21 <wumpus> I'm sure more issues will come up
2452016-02-12T10:47:27 <gmaxwell> OK
2462016-02-12T10:47:41 <wumpus> this last-minute-based development is unduely stressful
2472016-02-12T10:48:21 <gmaxwell> well that was why I did hope that the fix for that could be made very small. but indeed.
2482016-02-12T10:49:13 <gmaxwell> but yes, I don't disagree at all.
2492016-02-12T10:51:38 <wumpus> a 'small' change still needs testing, especially if made in a hurry
2502016-02-12T10:52:04 <wumpus> in any case if it turn out we really do need another rc because cfields cannot build this one deterministically, then we can include it
2512016-02-12T11:07:53 *** Sparyx has quit IRC
2522016-02-12T11:20:20 *** laurentmt has joined #bitcoin-core-dev
2532016-02-12T12:01:30 *** frankenmint has quit IRC
2542016-02-12T12:07:23 <GitHub105> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/2f3f4af4cc2b...621940e04090
2552016-02-12T12:07:23 <GitHub105> bitcoin/master a0a17b3 Pavel JanÃk: LibreSSL doesn't define OPENSSL_VERSION, use LIBRESSL_VERSION_TEXT instead
2562016-02-12T12:07:24 <GitHub105> bitcoin/master 621940e Wladimir J. van der Laan: Merge #7520: LibreSSL doesn't define OPENSSL_VERSION, use LIBRESSL_VERSION_TEXT instead...
2572016-02-12T12:07:27 <GitHub160> [bitcoin] laanwj closed pull request #7520: LibreSSL doesn't define OPENSSL_VERSION, use LIBRESSL_VERSION_TEXT instead (master...20160211_LibreSSL_compile_fix) https://github.com/bitcoin/bitcoin/pull/7520
2582016-02-12T12:09:50 *** frankenmint has joined #bitcoin-core-dev
2592016-02-12T12:17:00 *** amiller has quit IRC
2602016-02-12T12:23:17 *** Guest58194 has joined #bitcoin-core-dev
2612016-02-12T13:04:25 <cfields> wumpus: finally gave up on poking at it and created a clean setup on my macbook, building now. i'll figure out my issue later
2622016-02-12T13:06:59 <wumpus> okay- there was no trivial difference, the executables were completely out of whack?
2632016-02-12T13:10:24 <cfields> yea
2642016-02-12T13:11:07 <cfields> i'll keep my build objects on the fresh builder for comparison. i'd still like to hunt it down, just to be aware of the variable
2652016-02-12T13:12:19 *** drnet has joined #bitcoin-core-dev
2662016-02-12T13:20:18 *** Kexkey has joined #bitcoin-core-dev
2672016-02-12T13:26:01 *** drnet has quit IRC
2682016-02-12T13:26:57 *** Kexkey has quit IRC
2692016-02-12T13:44:30 *** Thireus has quit IRC
2702016-02-12T13:48:01 *** zooko has joined #bitcoin-core-dev
2712016-02-12T14:10:33 *** Thireus has joined #bitcoin-core-dev
2722016-02-12T15:09:00 *** paveljanik has quit IRC
2732016-02-12T15:26:40 *** bityogi has joined #bitcoin-core-dev
2742016-02-12T15:33:15 *** Thireus1 has joined #bitcoin-core-dev
2752016-02-12T15:34:13 *** BashCo has quit IRC
2762016-02-12T15:36:30 *** Thireus has quit IRC
2772016-02-12T15:43:27 *** Thireus1 has quit IRC
2782016-02-12T15:43:44 *** Thireus has joined #bitcoin-core-dev
2792016-02-12T15:47:37 <wumpus> the only thing I can think of that can cause such large differences would be a gcc upgrade on the base image
2802016-02-12T15:47:52 <wumpus> if it's just some compiled-in variable it's usually just a few bytes difference
2812016-02-12T15:57:28 *** BashCo has joined #bitcoin-core-dev
2822016-02-12T15:59:00 *** zooko has quit IRC
2832016-02-12T16:01:30 *** Guest58194 has quit IRC
2842016-02-12T16:01:30 *** Guest58194 has joined #bitcoin-core-dev
2852016-02-12T16:01:30 *** Guest58194 is now known as amiller
2862016-02-12T16:02:30 *** skyraider_ has joined #bitcoin-core-dev
2872016-02-12T16:04:21 <GitHub174> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/621940e04090...80d1f2e48364
2882016-02-12T16:04:22 <GitHub174> bitcoin/master c6c2f0f Alex Morcos: Implement SequenceLocks functions...
2892016-02-12T16:04:22 <GitHub174> bitcoin/master da6ad5f Suhas Daftuar: Add RPC test exercising BIP68 (mempool only)
2902016-02-12T16:04:23 <GitHub174> bitcoin/master a51c79b Alex Morcos: Bug fix to RPC test
2912016-02-12T16:04:26 <GitHub95> [bitcoin] laanwj closed pull request #7184: Implement SequenceLocks functions for BIP 68 (master...alternate68) https://github.com/bitcoin/bitcoin/pull/7184
2922016-02-12T16:16:26 <btcdrak> OMG!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1
2932016-02-12T16:16:29 <btcdrak> \o/
2942016-02-12T16:23:02 <wumpus> more gitian problems, this time building macosx. What is happening? https://github.com/bitcoin/gitian.sigs/pull/304
2952016-02-12T16:29:35 <JackH> this is huge, huge huge huge
2962016-02-12T16:30:56 <Ylbam> \o/
2972016-02-12T16:40:16 *** ryitpm has joined #bitcoin-core-dev
2982016-02-12T16:44:18 *** treehug88 has joined #bitcoin-core-dev
2992016-02-12T16:45:06 <cfields> wumpus: sigh, another mismatch for me
3002016-02-12T16:46:57 <wumpus> cfields: strange
3012016-02-12T16:47:09 <wumpus> so this is with a new base image?
3022016-02-12T16:49:46 <wumpus> going to have a look at it
3032016-02-12T16:49:48 <cfields> newish, but i'll try again
3042016-02-12T16:50:10 <cfields> i think the deps are all equal, so should be much quicker
3052016-02-12T16:50:24 *** treehug88 has quit IRC
3062016-02-12T16:52:18 <wumpus> all the mingw .deb packages are equal between us
3072016-02-12T16:52:38 <wumpus> so that rules out the compiler or binutils
3082016-02-12T16:53:42 <wumpus> can you upload your win64 result please?
3092016-02-12T16:55:52 <cfields> yep, sec
3102016-02-12T17:01:45 *** frankenmint has quit IRC
3112016-02-12T17:02:22 <cfields> wumpus: https://www.dropbox.com/s/nv27zxuit0202l9/bitcoin-0.12.0-win64.zip
3122016-02-12T17:04:08 <wumpus> got it
3132016-02-12T17:05:48 <cfields> actually, some deps don't match on this new build
3142016-02-12T17:05:55 <wumpus> cfields: so bench_bitcoin, bitcoin-cli, bitcoin-tx match - bitcoind, bitcoin-qt, test-bitcoin and test-bitcoin-qt differ
3152016-02-12T17:06:04 <wumpus> wild guess: openssl?
3162016-02-12T17:06:41 <cfields> wumpus: openssl dep matched yours, no?
3172016-02-12T17:06:50 <wumpus> I didn't check yet
3182016-02-12T17:07:05 <wumpus> but yes that kind of rules it out
3192016-02-12T17:07:18 *** paveljanik has joined #bitcoin-core-dev
3202016-02-12T17:08:46 <wumpus> non-matching executables are the same size - this rules out serious code/version differences
3212016-02-12T17:10:04 <wumpus> what the hell.
3222016-02-12T17:10:27 <wumpus> no, I can't make sense of this either, looks like scattered random differences
3232016-02-12T17:10:31 <cfields> yea, it seems things are just rearranged
3242016-02-12T17:10:47 <cfields> the random differences are mostly 1/2 bytes, which are just jump offsets
3252016-02-12T17:11:05 <cfields> s/offsets/addresses/
3262016-02-12T17:11:31 <wumpus> some gcc random seed issue again?
3272016-02-12T17:11:38 <cfields> so my guess was that functions got rearranged
3282016-02-12T17:11:52 <wumpus> or maybe file ordering within .a
3292016-02-12T17:11:55 <cfields> wumpus: well the weird part is that everyone else matched
3302016-02-12T17:12:27 <wumpus> my bet would be file ordering, and you using another file system than us
3312016-02-12T17:12:41 <cfields> otherwise i'd agree. it still points to pebkac, i just can't figure out what's different
3322016-02-12T17:12:49 <cfields> hmm, could be
3332016-02-12T17:12:58 <wumpus> or a locale leaking in issue, but you're not in a strange part of the world :-)
3342016-02-12T17:13:37 <cfields> well i think i did build the day after you guys
3352016-02-12T17:13:54 <cfields> (and building a 3rd day today)
3362016-02-12T17:14:01 <wumpus> last time I had an issue like this I compared the linker maps
3372016-02-12T17:14:14 <wumpus> good point, I'll build mine again to see if it changed.
3382016-02-12T17:14:55 <cfields> great, thanks. i'll rebuild with a fresh image
3392016-02-12T17:15:17 <wumpus> are you using LXC or KVM?
3402016-02-12T17:15:29 <wumpus> (no, I don't think that's what makes the difference)
3412016-02-12T17:15:31 <cfields> kvm
3422016-02-12T17:15:35 <wumpus> me too.
3432016-02-12T17:15:52 <wumpus> but kvm has less chance of external things leaking in
3442016-02-12T17:16:30 <cfields> right. and i built before on my desktop as usual, today with debian->trusty on my macbook
3452016-02-12T17:16:37 <cfields> that one should be about as "pure" as it gets
3462016-02-12T17:29:58 <GitHub164> [bitcoin] btcdrak opened pull request #7524: BIP-112: Mempool-only CHECKSEQUENCEVERIFY (master...checksequenceverify) https://github.com/bitcoin/bitcoin/pull/7524
3472016-02-12T18:02:35 *** frankenmint has joined #bitcoin-core-dev
3482016-02-12T18:07:35 *** frankenmint has quit IRC
3492016-02-12T18:22:38 *** degriff has joined #bitcoin-core-dev
3502016-02-12T18:42:18 <GitHub81> [bitcoin] jloughry opened pull request #7526: fix spelling of advertise (shows up in the debug log) (master...advertize-advertise) https://github.com/bitcoin/bitcoin/pull/7526
3512016-02-12T18:42:31 <cfields> wumpus: got a match
3522016-02-12T18:44:41 *** treehug88 has joined #bitcoin-core-dev
3532016-02-12T18:46:49 <wumpus> cfields: awesome! so upgrading the base image did it?
3542016-02-12T18:47:25 <cfields> wumpus: i just made a completely fresh one from debian and moved it over
3552016-02-12T18:47:59 <wumpus> holy shit I built from scratch (without cache) get a different output now
3562016-02-12T18:48:12 <cfields> maybe it has something to do with the fact that mine was a much older trusty image, so packages got held back or something
3572016-02-12T18:48:13 <cfields> ...
3582016-02-12T18:48:43 <wumpus> - b13f362e4efbcdcc539398010ef3b287209dc497a057f1f86805cc610c1e6796 bitcoin-0.12.0-win64.zip
3592016-02-12T18:48:43 <wumpus> + b785149cc0cc56dfb1c28626300f85ff8ea1b9658f8016bd9b202e32180a2bd9 bitcoin-0.12.0-win64.zip
3602016-02-12T18:49:14 <wumpus> that's not your output either, it's a third different one?
3612016-02-12T18:49:25 <cfields> wait, i wonder if that matches my unmatched macbook build
3622016-02-12T18:49:31 <cfields> sec, let me see if i still have it
3632016-02-12T18:50:23 <cfields> b785149cc0cc56dfb1c28626300f85ff8ea1b9658f8016bd9b202e32180a2bd9
3642016-02-12T18:50:33 <cfields> 4098c47e08a882892b2a2b88761cf688ae11d6a5a1d02270a154d60c0393e7fb bitcoin-0.12.0-win-unsigned.tar.gz
3652016-02-12T18:50:34 <cfields> ?
3662016-02-12T18:50:56 <wumpus> wrong file
3672016-02-12T18:51:26 <cfields> yes, my first file matched yours. was asking if the final result matched too :)
3682016-02-12T18:52:45 <wumpus> this looks like a different issue: bench, cli, bitcoind, -tx matches, -qt, test_* does not
3692016-02-12T18:53:02 <wumpus> 4098c47e08a882892b2a2b88761cf688ae11d6a5a1d02270a154d60c0393e7fb yes that's it
3702016-02-12T18:54:12 <cfields> ok, so there was definitely some recent update that broke us
3712016-02-12T18:55:04 <wumpus> a small segment of code looks different, no string changes
3722016-02-12T18:55:14 <wumpus> no jump table scatter either though
3732016-02-12T18:55:27 <wumpus> yep
3742016-02-12T18:56:13 <wumpus> - 3a23c66f383d6f26482333a963189f6aed948fc59b651daed3a7a57944d9ac44 i686-w64-mingw32/boost/boost-1_59_0-00e14fdbc48.tar.gz
3752016-02-12T18:56:14 <wumpus> + 92058863d4944dfb2d5fae3b46014e6121870cb9fc5a016b093afe3f0671fd81 i686-w64-mingw32/boost/boost-1_59_0-00e14fdbc48.tar.gz
3762016-02-12T18:56:37 <wumpus> - 158452df335b82928c16f70efd3753482c4a737ba0a1c13bb1fa444e1f32738a x86_64-w64-mingw32/qt/qt-5.5.0-70c250502c5.tar.gz
3772016-02-12T18:56:37 <wumpus> + 98b13ab377646e3aaebfee54555233b876ecbcc56ac60df88529adfca072bfbb x86_64-w64-mingw32/qt/qt-5.5.0-70c250502c5.tar.gz
3782016-02-12T18:56:47 <wumpus> ok ok almost every dependency is different
3792016-02-12T18:57:08 <wumpus> may be the dependencies were built with older .deb packages, I cannot verify that
3802016-02-12T18:57:10 <GitHub167> [bitcoin] instagibbs opened pull request #7527: [RPC] Fix and listreceivedbyX documentation (master...listfix) https://github.com/bitcoin/bitcoin/pull/7527
3812016-02-12T18:57:20 <wumpus> I don't have them anymore I deleted them instead of moving them :(
3822016-02-12T18:57:59 <cfields> i think i still have copies of everything
3832016-02-12T18:58:11 <wumpus> but it certainly looks like there are more toolchain versions in play, that's the only explanation I can think of
3842016-02-12T18:58:48 <cfields> yea. i've been poking for the last few hours on/off, while building. i don't see anything obvious that's updated since november
3852016-02-12T18:59:14 <Luke-Jr> bisect?
3862016-02-12T18:59:25 <wumpus> bisect ubuntu?
3872016-02-12T19:00:02 <Luke-Jr> oh, recent OS update
3882016-02-12T19:00:34 <cfields> wumpus: well, i'll fixup depends to make sure it detects any kind of system change
3892016-02-12T19:00:59 <cfields> wumpus: for now, want to just take that last result, since it's the result of a fresh/clean build?
3902016-02-12T19:01:12 <Luke-Jr> depends should work without determinism, right?
3912016-02-12T19:01:33 <wumpus> cfields: indeed, having some toolchain version info part of the cache hash would make sense
3922016-02-12T19:02:23 <wumpus> cfields: yes, I think so. We'll have to recommend everyone to update their base image and rebuild
3932016-02-12T19:03:09 <cfields> wumpus: yea, i was planning to add `$cc -v | sha256` to the hash, but now i'm thinking it might make sense to take an additional optional seed as well. in gitian's case, it'll be the result of `dpkg -l` or so
3942016-02-12T19:03:35 *** frankenmint has joined #bitcoin-core-dev
3952016-02-12T19:03:47 <wumpus> I'm not sure any change in dpkg should cause a rebuild
3962016-02-12T19:03:57 <cfields> (without trying to add each tool by hand)
3972016-02-12T19:04:04 <wumpus> right...
3982016-02-12T19:04:09 <wumpus> we should at least log the tool versions though
3992016-02-12T19:04:22 <wumpus> (somewhere in the cache directory)
4002016-02-12T19:04:39 <cfields> well it should only be the toolchain, but i'm not sure we want to enumerate each binary that could change build output
4012016-02-12T19:04:48 <cfields> yes
4022016-02-12T19:05:20 <wumpus> I understand. Well maybe detection of every single tool change is too much work, but would be nice to have them somewhere to compare if something like this happens
4032016-02-12T19:05:24 <cfields> wumpus: did you have to update your base to change the result, or simply nuke the cache?
4042016-02-12T19:05:52 <wumpus> just the cache
4052016-02-12T19:06:01 <cfields> ok
4062016-02-12T19:06:17 <wumpus> the updates should happen automatically
4072016-02-12T19:06:40 <wumpus> (which can take a long time, especially with LXC, as it starts off with an image with ancient packages)
4082016-02-12T19:07:01 <wumpus> (but upgrades it before build every time)
4092016-02-12T19:08:40 *** frankenmint has quit IRC
4102016-02-12T19:10:11 <cfields> right
4112016-02-12T19:11:20 <wumpus> so probably a *mingw* .deb upgrade happened in last week
4122016-02-12T19:12:57 <wumpus> probably yesterday
4132016-02-12T19:13:39 <wumpus> hm no we can't actually know for sure - I don't know when my last cache was built. But it can't be too long ago.
4142016-02-12T19:14:41 <wumpus> in any case: everyone should nuke cache and rebuild rc5
4152016-02-12T19:15:28 *** Arnavion has quit IRC
4162016-02-12T19:15:57 <cfields> right
4172016-02-12T19:16:31 <cfields> i'll make the toolchain detection top priority. will try to pr something today, once i/we track down what actually changed
4182016-02-12T19:18:01 <wumpus> well top priority is getting rc5 out :) but yes would certainly be useful to have, even if it's just a dpkg -l >> $CACHEDIR so that if something like this happens we can compare the package state under which the old and new cache was built
4192016-02-12T19:18:05 *** Arnavion has joined #bitcoin-core-dev
4202016-02-12T19:19:03 <wumpus> because the caching right now makes the list in the .assert only partially useful
4212016-02-12T19:20:18 <cfields> yes
4222016-02-12T19:20:22 <cfields> well
4232016-02-12T19:20:35 <cfields> i suppose we should rebuild everything, then. might not be mingw related
4242016-02-12T19:20:46 <cfields> doing osx now
4252016-02-12T19:21:32 <wumpus> ideally it would list the state under which the cache is built in the assert as well in a separate section, but that would require changes to gitian. In any case having these kind of things tracable would be great.
4262016-02-12T19:22:00 <wumpus> I don't see how it could be non mingw related
4272016-02-12T19:22:20 <wumpus> but sure, I'll try rebuilding linux and osx as well
4282016-02-12T19:24:34 <wumpus> if those differ it would make me even more interested in what changed
4292016-02-12T19:27:25 <cfields> wumpus: native_protobuf differs already for me. looks like it's system-wide
4302016-02-12T19:27:49 * wumpus gets his tinfoil hat
4312016-02-12T19:28:55 <cfields> haha
4322016-02-12T19:28:56 <wumpus> osx uses a compiler that isn't even part of an ubuntu package right?
4332016-02-12T19:29:16 <cfields> i had considered that, but dismissed it so far :)
4342016-02-12T19:29:23 <wumpus> I don't see how this is possible, I want to put 0.12.0 on hold until it is clear what causes this
4352016-02-12T19:29:40 <cfields> wumpus: yes, but it builds some native packages with the system toolchain first
4362016-02-12T19:30:04 <cfields> for ex: gcc builds protoc, which preprocesses, and apple-clang builds
4372016-02-12T19:30:29 <wumpus> but it build *our* protoc, it would be weird if the output of protoc changes based on what compiles it
4382016-02-12T19:30:41 <cfields> right
4392016-02-12T19:30:51 <wumpus> suspicious, even
4402016-02-12T19:30:55 <cfields> i only pointed out that native_protoc changed, not sure if it affects the end result
4412016-02-12T19:31:14 <cfields> (presumably that one wouldn't, as you said)
4422016-02-12T19:31:20 <wumpus> sure, let's hope for the best, I don't have build output either yet
4432016-02-12T19:31:58 * wumpus looking at asm difference
4442016-02-12T19:32:59 <cfields> i can't really think of anything that would change the osx result, beyond a gcc change that would really be cause for alarm, enough to affect the behavior of the osx-binutils
4452016-02-12T19:33:10 <cfields> (cctools)
4462016-02-12T19:33:28 <cfields> brb
4472016-02-12T19:33:45 <wumpus> agreed. linux build difference could be explained by *both* a linux and mingw toolchain chainge, but macosx difference would be nearly impossible
4482016-02-12T19:34:10 <gmaxwell> lets hope the protobuff wasn't backdoored. :)
4492016-02-12T19:34:41 <wumpus> gmaxwell: in this case it would be the compiler that inserts a backdoor into protobuf </tinfoil hat mode> ;)
4502016-02-12T19:36:36 <wumpus> well the compiler would insert a backdoor into protoc, which generates C++ code with a backdoor, which gets compiled in. And it's sneaky enough to result in an executable of the same size with some bytes different. Nahh... ;)
4512016-02-12T19:44:21 <cfields> wumpus: the osx dmg result is the same, but the unsigned .tar.gz is different
4522016-02-12T19:44:47 <cfields> wumpus: notice also that the comparisontool is different, which is just one file stuffed into a tarball
4532016-02-12T19:45:10 <cfields> so i'm guessing it's either something related to file-ordering (no clue how), or something low-level like zlib
4542016-02-12T19:45:34 <wumpus> linux result stays the same for me *happy*
4552016-02-12T19:46:26 <wumpus> now building mac too, let's see if we at least get the same
4562016-02-12T19:46:52 <paveljanik> BTW - this week I have read something about ls changes - quoting of filenames with space, different ordering etc...
4572016-02-12T19:48:30 <wumpus> right, it wouldn't be impossible for a system tool like that to actually make a difference somewhere paveljanik
4582016-02-12T19:48:40 <cfields> crap, i've gtg. back in an hour or so
4592016-02-12T19:48:50 <cfields> wumpus: c427d4076e1827d5fd3d645d26f3e1504ffe8b53c33c559c5dc49605d0b10cbd bitcoin-0.12.0-osx-unsigned.tar.gz
4602016-02-12T19:49:13 <wumpus> ok thanks, later
4612016-02-12T19:51:58 <paveljanik> wumpus, http://lists.gnu.org/archive/html/coreutils/2016-02/msg00000.html
4622016-02-12T19:54:47 <paveljanik> ie. ls from coreutils 8.25. But I think this new version was not in your builds...
4632016-02-12T19:57:33 <wumpus> I doubt ubuntu stable will upgrade coreutils that soon, and AFAIK we don't use ls anywhere (at least directly), it's likely not that exact issue (but it could be a similar one)
4642016-02-12T20:01:08 *** laurentmt has quit IRC
4652016-02-12T20:01:11 <wumpus> f153f1555b60edd61fa57a9b2f6b43d8d6449fd5c0e6a4ef0f4ba745c6376566 bitcoin-0.12.0-osx-unsigned.tar.gz didn't change for me cfields, osx output is the same
4662016-02-12T20:06:11 <wumpus> so that points at a mingw toolchain change, and only a mingw toolchain change only. Not sure what causes your .tar.gz difference, but if the dmg is the same at least the executable is the same.
4672016-02-12T20:13:38 <wumpus> from what I can see from the assembler difference it's exactly the same code, just using slightly different instructions to accomplish the same (e.g. mov shr and instead of testb setne). Typical of a compiler update.
4682016-02-12T20:14:00 * wumpus takes off his tinfoil hat and goes to bed
4692016-02-12T20:15:55 * Luke-Jr steals wumpus's tinfoil hat and runs away
4702016-02-12T20:16:18 <wumpus> hehe
4712016-02-12T20:27:27 <midnightmagic> yay other people having gitian problems besides me
4722016-02-12T20:27:58 <midnightmagic> I bet it's just because I do late gitian builds after you guys are all asleep
4732016-02-12T20:28:31 <midnightmagic> wumpus: but this sort of change makes it hard to reconstruct gitian sigs for earlier 0.12.0rc*
4742016-02-12T20:29:23 *** treehug88 has quit IRC
4752016-02-12T20:45:37 *** Guyver2 has joined #bitcoin-core-dev
4762016-02-12T20:47:30 <GitHub136> [bitcoin] knocte opened pull request #7528: autogen.sh: warn about needing autoconf if autoreconf is not found (master...warn-autoconf) https://github.com/bitcoin/bitcoin/pull/7528
4772016-02-12T20:51:04 <Luke-Jr> since when is ~/.bitcoin/testnet3/bitcoin.conf ignored and why?
4782016-02-12T20:52:19 <wumpus> midnightmagic: yes, the caching complicates that, as the package list in the assert is no longer that package state with which everything was built, that's why isuggested above to also log that
4792016-02-12T20:52:37 <wumpus> Luke-Jr: that's always been the case, there has never been support for per-chain config files
4802016-02-12T20:52:44 <Luke-Jr> also, is there any reason *not* to have regtest use non-testnet QSettings?
4812016-02-12T20:53:09 <Luke-Jr> (this means QApplication appname change)
4822016-02-12T20:53:11 <wumpus> I don't think regtest in the GUI is very well supported
4832016-02-12T20:53:28 <wumpus> it works, but probably there's some flukes here and there
4842016-02-12T20:53:40 <Luke-Jr> any complaint if I make it use its own appname/qsettings? :P
4852016-02-12T20:53:50 <wumpus> I don't really care, no
4862016-02-12T20:54:03 <wumpus> it's not something that affects end users
4872016-02-12T20:54:15 <wumpus> so if that makes testing easier why not
4882016-02-12T20:54:31 <Luke-Jr> well, IMO it's necessary for saving the network port number in QSettings
4892016-02-12T20:54:45 <Luke-Jr> (#7107)
4902016-02-12T20:54:49 *** treehug88 has joined #bitcoin-core-dev
4912016-02-12T20:54:51 <wumpus> just make sure it doesn't cause any other reversions, as we have hardly/none automatic tests for that stuff
4922016-02-12T20:55:10 *** xabbix has quit IRC
4932016-02-12T20:55:21 *** treehug88 has quit IRC
4942016-02-12T20:55:33 <Luke-Jr> does anything use appname besides qsettings?
4952016-02-12T20:55:56 *** treehug88 has joined #bitcoin-core-dev
4962016-02-12T20:56:11 <wumpus> I don't know by heart, I suppose qt docs can help you
4972016-02-12T20:56:54 * Luke-Jr shocked wumpus doesn't have the entire codebase memorised. :P jk
4982016-02-12T20:57:41 <wumpus> hey that's unfair it was a aquestion about upstream :P
4992016-02-12T20:58:13 *** xabbix has joined #bitcoin-core-dev
5002016-02-12T20:58:14 *** xabbix has joined #bitcoin-core-dev
5012016-02-12T20:58:19 <midnightmagic> wumpus: apparently there is an effort in debianland to build an archival package-state database which can be used to sync to specific sets of packages.
5022016-02-12T20:58:21 <Luke-Jr> docs say it's just QSettings
5032016-02-12T20:58:21 <wumpus> I know most of the bitcoin core codebase in detail, though I sometimes get confused by the wallet and some of the mempool workings
5042016-02-12T20:58:31 <Luke-Jr> also, apparently it's read-only on Blackberry, but I don't know that we care
5052016-02-12T20:58:46 <wumpus> I doubt anyone cares about blackberry no :)
5062016-02-12T20:59:39 <wumpus> there's not even an android bitcoin core release, let alone blackberry
5072016-02-12T21:00:06 <Luke-Jr> wumpus: GreenBits apparently runs Bitcoin Core Daemon on Android these days
5082016-02-12T21:00:38 <Luke-Jr> (optionally)
5092016-02-12T21:00:45 <wumpus> nice. yeah it's certainly possible, I've heard people have done it before, though I don't think it's documented anywhere
5102016-02-12T21:01:19 <wumpus> probably overheats most phone CPUs, as well as wears out the flash tho :-)
5112016-02-12T21:24:55 *** Nuief has quit IRC
5122016-02-12T21:28:37 *** Noice has joined #bitcoin-core-dev
5132016-02-12T21:31:11 *** Guyver2 has quit IRC
5142016-02-12T21:37:57 *** Guyver2 has joined #bitcoin-core-dev
5152016-02-12T21:38:12 <warren> Luke-Jr: what? full validation with pruning I'm guessig?
5162016-02-12T21:41:27 *** paveljanik has quit IRC
5172016-02-12T21:44:46 <morcos> So I've got a first pass at the feefilter idea coded up. I was thinking I'd also write a BIP for it. But seems like there might be some discussion of the best way to implement the idea.
5182016-02-12T21:45:03 <morcos> Any suggestions as to whether I should just write the BIP and then have discussion, or show the code first or what?
5192016-02-12T21:45:05 *** larsk has joined #bitcoin-core-dev
5202016-02-12T21:46:16 <Luke-Jr> warren: I assume
5212016-02-12T21:46:28 <Luke-Jr> morcos: ?
5222016-02-12T21:47:00 *** Chris_Stewart_5 has quit IRC
5232016-02-12T21:47:21 <morcos> Luke-Jr: The idea is that nodes can optionally broadcast a feefilter p2p message to let their peers know that their mempool is currently limited and they are not accepting txs below a certain feerate
5242016-02-12T21:48:11 <Luke-Jr> morcos: this idea that fees are the only relevant metric is troubling.
5252016-02-12T21:48:14 <morcos> This would save considerable network traffic in both invs that are never requested b/c they were previously rejected or requesting of txs that would fail due to insufficient fee
5262016-02-12T21:48:33 <Luke-Jr> "feerate" is not a well-defined term btw
5272016-02-12T21:48:34 <morcos> Well the idea I came up with is to make it optional
5282016-02-12T21:48:55 <Luke-Jr> Core uses a very subjective feerate that discounts part of the transaction, for example
5292016-02-12T21:49:20 <Luke-Jr> (ModSize)
5302016-02-12T21:49:23 <morcos> So that if you are a node that is implementing tx prioritization, then even if you have a limited mempool, you have to at least see the hash first b/c the feerate might get modified
5312016-02-12T21:49:35 <morcos> Luke-Jr: No, thats only for priority. FeeRate uses actual tx size
5322016-02-12T21:49:43 <Luke-Jr> hm, it does?
5332016-02-12T21:49:49 <Luke-Jr> I wonder if it should
5342016-02-12T21:49:55 <morcos> It's a valid question
5352016-02-12T21:50:07 <morcos> Partialy answered by segwit
5362016-02-12T21:51:00 <Luke-Jr> anyway, it's something to consider in your idea
5372016-02-12T21:51:17 <morcos> The way I was looking at the feature is that if you are just a relay node and you're not doing anything special with regards to priority (which is probably a significant % of the nodes) then this will help cut down on bandwidth significantly
5382016-02-12T21:51:41 <morcos> If you are running different policy or are a miner and doing prioritization, then you just don't use it
5392016-02-12T21:52:06 <Luke-Jr> it may bias the network toward a specific policy, which would be bad
5402016-02-12T21:52:06 <morcos> If used properly it should basically have no effect other than cutting down on useless network traffic
5412016-02-12T21:53:10 <morcos> I don't see why it would bias the network more than already is the case.
5422016-02-12T21:53:19 <Luke-Jr> hm, that's a point
5432016-02-12T21:53:25 <Luke-Jr> already there is lower bw use if you filter
5442016-02-12T21:54:16 <Luke-Jr> anyway, might make sense to abstract it a little at least
5452016-02-12T21:54:37 <Luke-Jr> eg, 1 byte for "feerate version" or smth
5462016-02-12T21:54:44 <Luke-Jr> (maybe varint)
5472016-02-12T21:55:17 <morcos> You mean have the p2p message be a bit more generic for future extension?
5482016-02-12T21:55:20 <Luke-Jr> perhaps some way to say "trickle non-matching transactions"?
5492016-02-12T21:55:21 <Luke-Jr> yes
5502016-02-12T21:55:27 <morcos> Sure seems reasonable
5512016-02-12T21:56:00 <morcos> Instead of FeeFilter 8byteFeeRate It could be InvFilter 1byteType 8byteFeeRAte
5522016-02-12T21:56:37 <Luke-Jr> varints might be nicer for both fields.
5532016-02-12T21:57:01 <Luke-Jr> perhaps some way to say "trickle non-matching transactions"? <-- this would nicely fit in with rate-limited priority relaying
5542016-02-12T21:58:04 <Luke-Jr> (but perhaps not worth the implementation effort)
5552016-02-12T22:00:06 *** gevs has quit IRC
5562016-02-12T22:01:39 <morcos> I'm not super familiar with the networking code, but seems like second data field type can depend on the content of the first data field. But also its not clear that its worth the effort as opposed to just defining different message types for future filters
5572016-02-12T22:02:03 <morcos> Anyway, sounds like from you comments that perhaps a BIP would be a good next step
5582016-02-12T22:06:08 <Luke-Jr> morcos: well, I mean I expect the feerate to be small ;)
5592016-02-12T22:06:36 <Luke-Jr> no need to waste 8 bytes for 100000 when 2 is sufficient
5602016-02-12T22:06:47 <Luke-Jr> (or is it 3? not relevant)
5612016-02-12T22:08:39 *** treehug88 has quit IRC
5622016-02-12T22:13:10 *** gevs has joined #bitcoin-core-dev
5632016-02-12T22:16:31 <cfields> wumpus: https://lists.ubuntu.com/archives/trusty-changes/2016-February/021179.html
5642016-02-12T22:16:33 <cfields> got to be that
5652016-02-12T22:40:12 *** skyraider_ has quit IRC
5662016-02-12T23:01:16 *** Guyver2 has quit IRC
5672016-02-12T23:03:17 *** frankenmint has joined #bitcoin-core-dev
5682016-02-12T23:09:11 *** frankenmint has quit IRC
5692016-02-12T23:24:08 <degriff> QUIT
5702016-02-12T23:24:43 *** degriff has quit IRC
5712016-02-12T23:33:42 *** adnn has quit IRC