12017-01-06T00:00:01 *** Squidicc has quit IRC
22017-01-06T00:02:53 *** Evel-Knievel has quit IRC
32017-01-06T00:11:15 *** brg444 has quit IRC
42017-01-06T00:31:05 *** TomMc has quit IRC
52017-01-06T00:36:22 *** PRab has quit IRC
62017-01-06T00:39:02 *** brg444 has joined #bitcoin-core-dev
72017-01-06T00:42:15 *** dcousens has joined #bitcoin-core-dev
82017-01-06T00:57:26 *** Ylbam has quit IRC
92017-01-06T00:57:37 <luke-jr> sipa: I see your point. paveljanik: are you already working on a PR, or shall I?
102017-01-06T00:57:42 <gmaxwell> 16:53 < Michail1> gmaxwell - Mental note: bitcoin-0.13.2-win64-setup.exe is detected by Norton (File Insight) as not safe and automatically removes it. (Not that you can do anything about it, just letting you know.) I am confirming the prior versions are not auto deleted.
112017-01-06T00:58:06 *** abpa has quit IRC
122017-01-06T00:58:40 *** wasi has joined #bitcoin-core-dev
132017-01-06T01:07:47 *** Chris_Stewart_5 has quit IRC
142017-01-06T01:13:51 *** belcher has quit IRC
152017-01-06T01:13:51 *** rubensayshi has quit IRC
162017-01-06T01:13:52 *** owowo has quit IRC
172017-01-06T01:13:52 *** paracyst has quit IRC
182017-01-06T01:13:52 *** PatBoy has quit IRC
192017-01-06T01:13:52 *** Eliel has quit IRC
202017-01-06T01:13:52 *** michagogo has quit IRC
212017-01-06T01:13:52 *** sipa has quit IRC
222017-01-06T01:13:52 *** Lightsword has quit IRC
232017-01-06T01:13:52 *** ill has quit IRC
242017-01-06T01:13:52 *** nanotube has quit IRC
252017-01-06T01:13:53 *** aspect_ has quit IRC
262017-01-06T01:13:53 *** midnightmagic has quit IRC
272017-01-06T01:13:53 *** jonasschnelli has quit IRC
282017-01-06T01:13:53 *** ryan-c has quit IRC
292017-01-06T01:17:53 *** lightningbot has joined #bitcoin-core-dev
302017-01-06T01:18:48 *** rubensayshi has joined #bitcoin-core-dev
312017-01-06T01:21:10 *** michagogo has joined #bitcoin-core-dev
322017-01-06T01:21:57 *** Chris_Stewart_5 has joined #bitcoin-core-dev
332017-01-06T01:22:03 *** nanotube has joined #bitcoin-core-dev
342017-01-06T01:22:19 *** gwollon is now known as gwillen
352017-01-06T01:24:44 *** wallet42 has joined #bitcoin-core-dev
362017-01-06T01:24:59 *** limpkin has joined #bitcoin-core-dev
372017-01-06T01:25:41 <bitcoin-git> [bitcoin] kallewoof closed pull request #9478: Trivial refactor: BOOST_FOREACH(a, b) -> for (a : b) (master...replace-boostforeach) https://github.com/bitcoin/bitcoin/pull/9478
382017-01-06T01:26:16 *** CodeShark has joined #bitcoin-core-dev
392017-01-06T01:33:54 *** aspect_ has joined #bitcoin-core-dev
402017-01-06T01:40:03 *** eragmus has joined #bitcoin-core-dev
412017-01-06T01:41:05 *** mappum has joined #bitcoin-core-dev
422017-01-06T01:49:55 *** abpa has joined #bitcoin-core-dev
432017-01-06T02:20:15 <kallewoof> sipa: i have 4 nodes (n1-n4) partitioned into two nets (n12 n34). n2 and n3 both spend the same UTXO, then 6 blocks are generated on each side after which the nets are merged and an additional block is generated on n4 causing the n3 transaction to take precedence, knocking the n1 transaction out. this is sometimes listed in listsinceblock and sometimes not.
442017-01-06T02:21:08 <kallewoof> sipa: I tried putting a 1 sec delay after the generate to see if there was some wallet fiddling that did not finish in time but this did not change the outcome.
452017-01-06T02:31:03 <gmaxwell> listed in listsinceblock on which side?
462017-01-06T02:31:18 <gmaxwell> and which block are you listing since?
472017-01-06T02:34:29 <kallewoof> I am calling listsinceblock from n1
482017-01-06T02:36:32 <kallewoof> What's fascinating is that, for the MISSING case (i.e. when it doesn't list the now-orphaned transaction originating from n2), n1 has this in the debug.log file, and for the present case it does not have this:
492017-01-06T02:36:34 <kallewoof> 2017-01-05 11:04:46 Transaction efd9e5d4daf8d47a2cc07db0e153513b2d02da2e031d3f2398f804b2a3d7ba03 (in block 2fd09b11259689722ec38873aeedc7e27753a587f66a542bb2ae64546b17943f) conflicts with wallet transaction 5c717b80ee4e4909e9f4a15bfacd728c3be8c1e75d6eed83a3e9324f6b9ea38c (both spend f72d9d38468c40777640e5b7731dab76cd961ee60cc93198b2ec706c21fb1801:0)
502017-01-06T02:40:54 <kallewoof> I guess since the transaction was overridden by another one, 'orphaned' is probably not the right term. 'Invalidated'? 'Betrayed'? Anyway, the tx that lost the UTXO race.
512017-01-06T02:42:04 <kallewoof> A bit verbose but you can compare the two cases here: http://pastebin.com/EqupZuFM (missing) and here: http://pastebin.com/Phy6mN3G (present)
522017-01-06T02:45:39 *** Chris_Stewart_5 has quit IRC
532017-01-06T02:46:27 *** Giszmo has quit IRC
542017-01-06T03:01:25 *** Chris_Stewart_5 has joined #bitcoin-core-dev
552017-01-06T03:14:51 *** abpa has quit IRC
562017-01-06T03:17:52 *** Chris_Stewart_5 has quit IRC
572017-01-06T03:43:30 *** tunafizz has joined #bitcoin-core-dev
582017-01-06T04:02:40 <phantomcircuit> kallewoof, conflicted
592017-01-06T05:01:52 *** roidster has quit IRC
602017-01-06T05:06:36 *** CubicEarth has quit IRC
612017-01-06T05:10:32 *** CubicEarth has joined #bitcoin-core-dev
622017-01-06T05:15:48 *** CubicEarth has quit IRC
632017-01-06T05:35:13 <paveljanik> luke-jr, I'm not (I was sleeping ;-)
642017-01-06T06:32:40 <gmaxwell> morcos: par=4 synctime of 24453.715550 (all signatures checked), and par=max (24 actual core host) 12182.296543... so yea, I suppose it's scaling better than it used to.
652017-01-06T06:33:10 <gmaxwell> (these figures with dbcache=2000)
662017-01-06T06:52:07 *** Ylbam has joined #bitcoin-core-dev
672017-01-06T06:54:12 *** Alopex has quit IRC
682017-01-06T06:55:17 *** Alopex has joined #bitcoin-core-dev
692017-01-06T07:00:07 *** dermoth has quit IRC
702017-01-06T07:01:06 *** dermoth has joined #bitcoin-core-dev
712017-01-06T07:09:55 *** brg444 has quit IRC
722017-01-06T07:59:06 *** Alopex has quit IRC
732017-01-06T08:00:12 *** Alopex has joined #bitcoin-core-dev
742017-01-06T08:08:17 *** kadoban has quit IRC
752017-01-06T08:21:28 *** Victor_sueca has quit IRC
762017-01-06T08:22:26 *** paveljanik has quit IRC
772017-01-06T08:23:31 *** Guest26441 has quit IRC
782017-01-06T08:23:48 *** instagibbs has quit IRC
792017-01-06T08:24:40 *** paveljanik has joined #bitcoin-core-dev
802017-01-06T08:25:25 *** sdaftuar has quit IRC
812017-01-06T08:25:57 *** zxzzt has quit IRC
822017-01-06T08:26:28 *** roasbeef has quit IRC
832017-01-06T08:26:32 *** sdaftuar has joined #bitcoin-core-dev
842017-01-06T08:26:41 *** zxzzt has joined #bitcoin-core-dev
852017-01-06T08:27:04 *** thib_ has joined #bitcoin-core-dev
862017-01-06T08:28:28 *** jyap has joined #bitcoin-core-dev
872017-01-06T08:28:37 *** windsok has quit IRC
882017-01-06T08:28:46 *** instagibbs has joined #bitcoin-core-dev
892017-01-06T08:29:35 <jonasschnelli> I'm not very familiar with bloom filters,... for the concept of a block filter committment, I get the point of creating a CBloomFilter for a block containing al inputs and outputs of the containing txs.
902017-01-06T08:29:43 <jonasschnelli> What I don't see how this would be possible is...
912017-01-06T08:30:16 <jonasschnelli> how you then could compare a CBloomFilter created with ones wallet pubkeys against the block committment CBloomFilter.
922017-01-06T08:30:35 <jonasschnelli> I though you have to compare each key from your local wallet against the block-wide committment filter?
932017-01-06T08:31:30 *** morcos has quit IRC
942017-01-06T08:31:31 *** amiller has quit IRC
952017-01-06T08:31:31 *** mr_burdell has quit IRC
962017-01-06T08:31:32 *** Guest98817 has quit IRC
972017-01-06T08:31:32 *** so has quit IRC
982017-01-06T08:31:32 *** AaronvanW has quit IRC
992017-01-06T08:31:33 *** wumpus has quit IRC
1002017-01-06T08:31:33 *** cjamthagen has quit IRC
1012017-01-06T08:31:33 *** afk11 has quit IRC
1022017-01-06T08:31:33 *** molz has quit IRC
1032017-01-06T08:31:34 *** eenoch has quit IRC
1042017-01-06T08:31:34 *** GAit has quit IRC
1052017-01-06T08:31:34 *** kallewoof has quit IRC
1062017-01-06T08:31:34 *** warren has quit IRC
1072017-01-06T08:31:34 *** lesderid has quit IRC
1082017-01-06T08:31:34 *** thestringpuller has quit IRC
1092017-01-06T08:31:35 *** jeremias has quit IRC
1102017-01-06T08:31:35 *** NicolasDorier has quit IRC
1112017-01-06T08:31:35 *** pindarhk has quit IRC
1122017-01-06T08:31:35 *** btcdrak has quit IRC
1132017-01-06T08:31:35 *** jcorgan has quit IRC
1142017-01-06T08:31:35 *** shinobimonkey has quit IRC
1152017-01-06T08:31:35 *** gmaxwell has quit IRC
1162017-01-06T08:31:35 *** adiabat has quit IRC
1172017-01-06T08:31:35 *** Cory has quit IRC
1182017-01-06T08:31:36 *** atroxes has quit IRC
1192017-01-06T08:31:36 *** xHire has quit IRC
1202017-01-06T08:31:36 *** emzy has quit IRC
1212017-01-06T08:31:36 *** wbnns has quit IRC
1222017-01-06T08:31:36 *** thrasher` has quit IRC
1232017-01-06T08:31:36 *** isis has quit IRC
1242017-01-06T08:31:36 *** petertodd has quit IRC
1252017-01-06T08:31:36 *** fengling has quit IRC
1262017-01-06T08:31:36 *** Magma has quit IRC
1272017-01-06T08:31:36 *** [Author] has quit IRC
1282017-01-06T08:31:36 *** LeMiner has quit IRC
1292017-01-06T08:31:37 *** achow101 has quit IRC
1302017-01-06T08:31:37 *** cryptapus_afk has quit IRC
1312017-01-06T08:31:37 *** murchandamus has quit IRC
1322017-01-06T08:31:38 *** Jouke has quit IRC
1332017-01-06T08:31:38 *** crudel has quit IRC
1342017-01-06T08:31:38 *** Madars has quit IRC
1352017-01-06T08:31:38 *** face has quit IRC
1362017-01-06T08:31:38 *** mturquette has quit IRC
1372017-01-06T08:31:38 *** Anduck has quit IRC
1382017-01-06T08:31:38 *** rabidus_ has quit IRC
1392017-01-06T08:31:38 *** ensign has quit IRC
1402017-01-06T08:31:38 *** cfields has quit IRC
1412017-01-06T08:31:38 *** kanzure has quit IRC
1422017-01-06T08:31:38 *** cysm has quit IRC
1432017-01-06T08:31:38 *** thib has quit IRC
1442017-01-06T08:31:38 *** e4xit has quit IRC
1452017-01-06T08:31:39 *** echonaut has quit IRC
1462017-01-06T08:31:39 *** dgenr8 has quit IRC
1472017-01-06T08:31:39 *** thermoman has quit IRC
1482017-01-06T08:31:39 *** jeremyrubin has quit IRC
1492017-01-06T08:31:39 *** niska` has quit IRC
1502017-01-06T08:33:49 *** profall has quit IRC
1512017-01-06T08:33:59 *** limpkin has quit IRC
1522017-01-06T08:37:45 *** LeMiner has joined #bitcoin-core-dev
1532017-01-06T08:37:45 *** AaronvanW has joined #bitcoin-core-dev
1542017-01-06T08:37:45 *** fengling has joined #bitcoin-core-dev
1552017-01-06T08:37:45 *** jeremias has joined #bitcoin-core-dev
1562017-01-06T08:37:45 *** NicolasDorier has joined #bitcoin-core-dev
1572017-01-06T08:37:45 *** pindarhk has joined #bitcoin-core-dev
1582017-01-06T08:37:45 *** jcorgan has joined #bitcoin-core-dev
1592017-01-06T08:37:45 *** molz has joined #bitcoin-core-dev
1602017-01-06T08:37:45 *** e4xit has joined #bitcoin-core-dev
1612017-01-06T08:37:45 *** achow101 has joined #bitcoin-core-dev
1622017-01-06T08:37:45 *** wumpus has joined #bitcoin-core-dev
1632017-01-06T08:37:45 *** shinobimonkey has joined #bitcoin-core-dev
1642017-01-06T08:37:45 *** cryptapus_afk has joined #bitcoin-core-dev
1652017-01-06T08:37:45 *** cjamthagen has joined #bitcoin-core-dev
1662017-01-06T08:37:45 *** afk11 has joined #bitcoin-core-dev
1672017-01-06T08:37:45 *** gmaxwell has joined #bitcoin-core-dev
1682017-01-06T08:37:45 *** eenoch has joined #bitcoin-core-dev
1692017-01-06T08:37:45 *** echonaut has joined #bitcoin-core-dev
1702017-01-06T08:37:45 *** adiabat has joined #bitcoin-core-dev
1712017-01-06T08:37:45 *** dgenr8 has joined #bitcoin-core-dev
1722017-01-06T08:37:45 *** morcos has joined #bitcoin-core-dev
1732017-01-06T08:37:45 *** Magma has joined #bitcoin-core-dev
1742017-01-06T08:37:45 *** Guest98817 has joined #bitcoin-core-dev
1752017-01-06T08:37:45 *** GAit has joined #bitcoin-core-dev
1762017-01-06T08:37:45 *** murchandamus has joined #bitcoin-core-dev
1772017-01-06T08:37:45 *** thermoman has joined #bitcoin-core-dev
1782017-01-06T08:37:45 *** kallewoof has joined #bitcoin-core-dev
1792017-01-06T08:37:45 *** jeremyrubin has joined #bitcoin-core-dev
1802017-01-06T08:37:45 *** Jouke has joined #bitcoin-core-dev
1812017-01-06T08:37:45 *** petertodd has joined #bitcoin-core-dev
1822017-01-06T08:37:45 *** Cory has joined #bitcoin-core-dev
1832017-01-06T08:37:45 *** xHire has joined #bitcoin-core-dev
1842017-01-06T08:37:45 *** [Author] has joined #bitcoin-core-dev
1852017-01-06T08:37:45 *** crudel has joined #bitcoin-core-dev
1862017-01-06T08:37:45 *** Madars has joined #bitcoin-core-dev
1872017-01-06T08:37:45 *** face has joined #bitcoin-core-dev
1882017-01-06T08:37:45 *** amiller has joined #bitcoin-core-dev
1892017-01-06T08:37:45 *** mturquette has joined #bitcoin-core-dev
1902017-01-06T08:37:45 *** atroxes has joined #bitcoin-core-dev
1912017-01-06T08:37:45 *** mr_burdell has joined #bitcoin-core-dev
1922017-01-06T08:37:45 *** warren has joined #bitcoin-core-dev
1932017-01-06T08:37:45 *** Anduck has joined #bitcoin-core-dev
1942017-01-06T08:37:45 *** rabidus_ has joined #bitcoin-core-dev
1952017-01-06T08:37:45 *** emzy has joined #bitcoin-core-dev
1962017-01-06T08:37:45 *** ensign has joined #bitcoin-core-dev
1972017-01-06T08:37:45 *** lesderid has joined #bitcoin-core-dev
1982017-01-06T08:37:45 *** cfields has joined #bitcoin-core-dev
1992017-01-06T08:37:45 *** kanzure has joined #bitcoin-core-dev
2002017-01-06T08:37:45 *** cysm has joined #bitcoin-core-dev
2012017-01-06T08:37:45 *** thestringpuller has joined #bitcoin-core-dev
2022017-01-06T08:37:45 *** thrasher` has joined #bitcoin-core-dev
2032017-01-06T08:37:45 *** niska` has joined #bitcoin-core-dev
2042017-01-06T08:37:45 *** wbnns has joined #bitcoin-core-dev
2052017-01-06T08:37:45 *** isis has joined #bitcoin-core-dev
2062017-01-06T08:39:15 *** jyap has quit IRC
2072017-01-06T08:39:15 *** jyap has joined #bitcoin-core-dev
2082017-01-06T08:39:32 *** Victorsueca has joined #bitcoin-core-dev
2092017-01-06T08:40:03 *** thib_ has quit IRC
2102017-01-06T08:40:04 *** michagogo has quit IRC
2112017-01-06T08:40:31 *** wallet42 has quit IRC
2122017-01-06T08:41:21 *** roasbeef has joined #bitcoin-core-dev
2132017-01-06T08:41:47 *** profall has joined #bitcoin-core-dev
2142017-01-06T08:42:20 *** btcdrak has joined #bitcoin-core-dev
2152017-01-06T08:45:21 *** jonasschnelli has quit IRC
2162017-01-06T08:46:27 *** jonasschnelli has joined #bitcoin-core-dev
2172017-01-06T08:47:49 *** jonasschnelli has quit IRC
2182017-01-06T08:47:49 *** jonasschnelli has joined #bitcoin-core-dev
2192017-01-06T08:47:59 *** limpkin has joined #bitcoin-core-dev
2202017-01-06T08:51:21 *** wallet42 has joined #bitcoin-core-dev
2212017-01-06T08:55:17 *** michagogo has joined #bitcoin-core-dev
2222017-01-06T09:14:00 *** chjj has joined #bitcoin-core-dev
2232017-01-06T09:17:02 *** windsok has joined #bitcoin-core-dev
2242017-01-06T09:24:33 *** jannes has joined #bitcoin-core-dev
2252017-01-06T09:31:08 *** goregrin1 is now known as goregrind
2262017-01-06T09:31:57 *** so has joined #bitcoin-core-dev
2272017-01-06T09:41:21 *** laurentmt has joined #bitcoin-core-dev
2282017-01-06T09:48:53 <bitcoin-git> [bitcoin] jonasschnelli closed pull request #7826: [Qt] show conflicts of unconfirmed transactions in the UI (master...2016/04/ui_mem_cflct) https://github.com/bitcoin/bitcoin/pull/7826
2292017-01-06T09:49:14 <bitcoin-git> [bitcoin] jonasschnelli closed pull request #7817: [Qt] attribute replaceable (RBF) transactions (master...2016/04/qt_rbf) https://github.com/bitcoin/bitcoin/pull/7817
2302017-01-06T09:56:09 *** laurentmt has quit IRC
2312017-01-06T10:03:11 <bitcoin-git> [bitcoin] jonasschnelli opened pull request #9481: [Qt] Show more significant warning if we fall back to the default fee (master...2017/01/fee_warning) https://github.com/bitcoin/bitcoin/pull/9481
2322017-01-06T10:13:52 <btcdrak> jonasschnelli: I'm willing to test those this weekend...
2332017-01-06T10:14:27 <jonasschnelli> btcdrak: They need overhaul from my side, don't bother
2342017-01-06T10:14:33 <btcdrak> ok
2352017-01-06T10:14:50 <jonasschnelli> I'll re-base overhaul them as soon as they rise on my pile-of-work
2362017-01-06T10:27:49 *** Giszmo has joined #bitcoin-core-dev
2372017-01-06T10:46:31 *** windsok has quit IRC
2382017-01-06T10:56:36 *** MarcoFalke has joined #bitcoin-core-dev
2392017-01-06T11:25:44 *** paveljanik has quit IRC
2402017-01-06T11:35:57 *** windsok has joined #bitcoin-core-dev
2412017-01-06T12:37:47 *** MarcoFalke has left #bitcoin-core-dev
2422017-01-06T13:01:22 *** laurentmt has joined #bitcoin-core-dev
2432017-01-06T13:02:12 *** laurentmt has quit IRC
2442017-01-06T13:25:59 *** berndj has joined #bitcoin-core-dev
2452017-01-06T13:38:26 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2462017-01-06T13:43:42 *** Chris_Stewart_5 has quit IRC
2472017-01-06T13:49:19 <jonasschnelli> Request for review: #9294
2482017-01-06T13:49:21 <gribble> https://github.com/bitcoin/bitcoin/issues/9294 | Use internal HD chain for change outputs (hd split) by jonasschnelli · Pull Request #9294 · bitcoin/bitcoin · GitHub
2492017-01-06T13:53:24 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2502017-01-06T13:55:58 <morcos> gmaxwell: re: CreateTransaction logging, I think thats a great idea. If needed we could even make fee estimation take a bool to output more debugging information for the times its called via CreateTransaction. but even without that, just having the basic info would be nice.
2512017-01-06T14:04:22 *** BashCo has quit IRC
2522017-01-06T14:06:38 *** laurentmt has joined #bitcoin-core-dev
2532017-01-06T14:15:39 *** Chris_Stewart_5 has quit IRC
2542017-01-06T14:23:24 <jonasschnelli> Idea: would it be stupid to use the first 16 addrs of the dns-seeder DNS response as a "hidden" secp256k1 compact sig for the next 16 addrs of a complete response of 32 addrs?
2552017-01-06T14:23:41 *** BashCo has joined #bitcoin-core-dev
2562017-01-06T14:23:58 <jonasschnelli> Then ship apps with an ec pubkey per seeder (that supports signed dns responses)
2572017-01-06T14:24:23 <jonasschnelli> I think this approach would be a simple hack and much less work then switching to DNSSEC
2582017-01-06T14:26:34 <sipa> jonasschnelli: i believw intermediate resolvers can reorder/filter responses
2592017-01-06T14:29:13 <gmaxwell> s/can/constantly/
2602017-01-06T14:30:03 <gmaxwell> a lot of intermediate resolvers trim the results to just a few, and many (most?) reorder them (e.g. under the assumption that the final device will use the first, then yielding a cached response they reorder to avoid overloading the source).
2612017-01-06T14:31:39 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2622017-01-06T14:39:20 *** Guyver2 has joined #bitcoin-core-dev
2632017-01-06T14:40:02 *** BCBot_ has quit IRC
2642017-01-06T14:49:10 *** laurentmt has quit IRC
2652017-01-06T14:51:45 <jonasschnelli> hmm... that unfortunate.
2662017-01-06T14:55:33 *** BCBot has joined #bitcoin-core-dev
2672017-01-06T14:58:18 *** BCBot has quit IRC
2682017-01-06T14:58:33 *** BCBot has joined #bitcoin-core-dev
2692017-01-06T15:04:21 *** TomMc has joined #bitcoin-core-dev
2702017-01-06T15:05:52 *** MarcoFalke has joined #bitcoin-core-dev
2712017-01-06T15:19:18 *** Evel-Knievel has joined #bitcoin-core-dev
2722017-01-06T15:20:08 *** Alina-malina has quit IRC
2732017-01-06T15:20:30 *** Alina-malina has joined #bitcoin-core-dev
2742017-01-06T15:22:23 *** Alina-malina has quit IRC
2752017-01-06T15:22:23 *** Alina-malina has joined #bitcoin-core-dev
2762017-01-06T16:05:05 *** whphhg has joined #bitcoin-core-dev
2772017-01-06T16:05:06 *** Chris_Stewart_5 has quit IRC
2782017-01-06T16:06:07 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2792017-01-06T16:12:10 <jonasschnelli> We do we try to connect to the dnsseeder on 8333? One-shot getaddr?
2802017-01-06T16:14:04 <sipa> ?
2812017-01-06T16:14:46 <sipa> you mean why does the oneshot concept exist?
2822017-01-06T16:15:14 <sipa> if you're connecting over Tor you shouldn't do DNS lookups, as they'd leak your traffic
2832017-01-06T16:15:37 <jonasschnelli> sipa: That was the problem! Dam Qt settings...
2842017-01-06T16:16:03 <jonasschnelli> Now I also know why my SPV block downloads where slower then expected. :)
2852017-01-06T16:16:19 <sipa> so instead we "connect" to the seeder, which in practice means we're connecting to a Tor exit router, and make the router resoove the seeder, and connect tovit
2862017-01-06T16:16:37 <sipa> we don't actually learn what IP we're connecting to in that case
2872017-01-06T16:26:26 *** Chris_Stewart_5 has quit IRC
2882017-01-06T16:32:17 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2892017-01-06T16:38:09 <bitcoin-git> [bitcoin] sipa pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/f646275b90b1...a55716abe566
2902017-01-06T16:38:10 <bitcoin-git> bitcoin/master 50bd12c Gregory Maxwell: Break addnode out from the outbound connection limits....
2912017-01-06T16:38:11 <bitcoin-git> bitcoin/master 90f13e1 Gregory Maxwell: Add release notes for addnode changes.
2922017-01-06T16:38:11 <bitcoin-git> bitcoin/master 032ba3f Gregory Maxwell: RPC help documentation for addnode peerinfo....
2932017-01-06T16:38:24 <bitcoin-git> [bitcoin] sipa closed pull request #9319: Break addnode out from the outbound connection limits. (master...addnode_own_count) https://github.com/bitcoin/bitcoin/pull/9319
2942017-01-06T16:44:57 <bitcoin-git> [bitcoin] jonasschnelli opened pull request #9483: Complete hybrid full block SPV mode (master...2017/01/spv) https://github.com/bitcoin/bitcoin/pull/9483
2952017-01-06T16:45:10 <midnightmagic> \o/ YAYYY
2962017-01-06T16:45:45 *** brg444 has joined #bitcoin-core-dev
2972017-01-06T16:47:07 *** abpa has joined #bitcoin-core-dev
2982017-01-06T16:50:03 *** brg444 has quit IRC
2992017-01-06T16:50:15 *** brg444 has joined #bitcoin-core-dev
3002017-01-06T16:53:42 *** TomMc has quit IRC
3012017-01-06T16:57:40 *** kadoban has joined #bitcoin-core-dev
3022017-01-06T17:03:36 *** Chris_Stewart_5 has quit IRC
3032017-01-06T17:08:47 <morcos> cfields: just finished reading through 9441, didn't understand your last comment on the PR, you are going to change it back to what?
3042017-01-06T17:08:59 *** TomMc has joined #bitcoin-core-dev
3052017-01-06T17:09:27 <sipa> morcos: the current PR makes ProcessMessages only process one message at a timre
3062017-01-06T17:09:39 <morcos> i don't think you need to change it (now) i think its fairly clear any edge case change from current behavior is a net benefit
3072017-01-06T17:09:44 <morcos> sipa: but thats what it did before
3082017-01-06T17:10:01 <sipa> yes
3092017-01-06T17:10:40 <morcos> so you think he should change it to process more than one?
3102017-01-06T17:10:52 <sipa> i'd be more confortable with that
3112017-01-06T17:11:11 <BlueMatt> you'd be more comfortable with a change in behavior?
3122017-01-06T17:11:15 <morcos> that seems like the change to me, possibly a good one, but the PR seems more clearly correct without doing that b/c it doesn't require thinking about that
3132017-01-06T17:11:20 <BlueMatt> I mean I agree we should probably do that in the furture, but why change it now?
3142017-01-06T17:11:25 <morcos> BlueMatt: +!
3152017-01-06T17:11:26 <morcos> 1
3162017-01-06T17:11:34 <sipa> i'm confused
3172017-01-06T17:11:41 <sipa> the current code processes multiple messages at once
3182017-01-06T17:11:48 <BlueMatt> the pr does not change the behavior except for some stupid weird edge cases
3192017-01-06T17:11:55 <sipa> his current PR changes that to only process one at a time
3202017-01-06T17:11:59 <BlueMatt> specifically, currently, if you have a message with a bad hash, it will process more than once
3212017-01-06T17:12:07 <morcos> morcos> sipa: but thats what it did before (meaning master does not process more than one)
3222017-01-06T17:12:09 <BlueMatt> but the current code does NOT process more than one message if it calls ProcessMessage
3232017-01-06T17:12:22 <sipa> morcos: heh?
3242017-01-06T17:12:26 <BlueMatt> (also the pr just disconnects on a bad hash, which I think is a change, but a good one imo)
3252017-01-06T17:12:33 <sipa> master does process more than one, unless it's a block
3262017-01-06T17:12:36 <BlueMatt> no
3272017-01-06T17:12:36 <sipa> or the send buffer is full
3282017-01-06T17:12:37 <BlueMatt> it does not
3292017-01-06T17:13:28 <BlueMatt> I had the same misunderstanding initially
3302017-01-06T17:14:10 <morcos> line 2566 in net_processing.cpp on master i think
3312017-01-06T17:14:53 <sipa> ok, i was not aware of that
3322017-01-06T17:15:00 <sipa> but that seems to be a bug
3332017-01-06T17:15:11 <morcos> :) i think cfields tried to explain it multiple times
3342017-01-06T17:15:36 <morcos> i think we all agree it may be better to process multiple messages, but it seems to me to make more sense to do that as a follow on PR
3352017-01-06T17:16:08 <BlueMatt> (and the overhead of not doing so is (likely) not too terrible)
3362017-01-06T17:16:30 <BlueMatt> (except for the bug fixed by #9315)
3372017-01-06T17:16:32 <gribble> https://github.com/bitcoin/bitcoin/issues/9315 | Request announcement by cmpctblock AFTER requesting cmpctblock/blocktxn by rebroad · Pull Request #9315 · bitcoin/bitcoin · GitHub
3382017-01-06T17:18:46 <morcos> we need to think carefully if there could be negative situations in the other direction.. you're about to announce blocks to all your peers or respond to their getblocktxns messages and some other peer manages to tie you up with a slew of expensive to process received msgs
3392017-01-06T17:18:57 <BlueMatt> heh, fun github bug - if you "start a review" and then "add single comment", it will publish all pending comments
3402017-01-06T17:19:12 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3412017-01-06T17:19:20 <sipa> on a different page?
3422017-01-06T17:20:11 <sipa> ok, so it seems i had completely forgotten about #3180 (> 3 years old)
3432017-01-06T17:20:13 <gribble> https://github.com/bitcoin/bitcoin/issues/3180 | Reduce latency in network processing by pstratem · Pull Request #3180 · bitcoin/bitcoin · GitHub
3442017-01-06T17:20:36 <BlueMatt> you dont /usually/ forget prs from 3 years ago???!
3452017-01-06T17:20:46 <BlueMatt> man, I cant remember prs from 6 months ago
3462017-01-06T17:20:52 <cfields> sipa: heh, i commented on it in about ~5 places :)
3472017-01-06T17:20:52 <morcos> i think clearly we should do SOMETHING smarter, i mean if a block has been announced to you and is sitting in yoru receive queue, seems silly to announce it back just b/c you haven't read it...
3482017-01-06T17:21:01 <cfields> sipa: i thought you just wanted to minimize the diff here
3492017-01-06T17:21:45 <sipa> cfields: you said "in nearly all cases, only one message is processed" - i thought that referred to cases where the buffer was full or we're processing blocks - the pre-3180 behaviour
3502017-01-06T17:21:54 <sipa> and i didn't understand why you'd be changing it
3512017-01-06T17:22:24 <morcos> so do we all agree that cfields should leave 9441 alone, and any further change should be in a separate PR?
3522017-01-06T17:22:46 <sipa> yes.
3532017-01-06T17:22:52 <cfields> sipa: ah, sorry. the only cases for processing multiple are for bad hash, or bad header
3542017-01-06T17:22:58 *** brg444 has quit IRC
3552017-01-06T17:23:16 <sipa> i was trying to ask "why are you changing behaviour" - it would have been clearer if you just had said "it doesn't"
3562017-01-06T17:23:16 <sipa> :)
3572017-01-06T17:23:31 <morcos> s/only cases/only preexisting cases were/
3582017-01-06T17:23:34 <jonasschnelli> luke-jr: I first was using the term "non-validation mode". But than â after reading satoshis whitepaper again â considered to use the name "Simple Payment Verification".
3592017-01-06T17:23:38 <BlueMatt> fucking engineers - always precise.....
3602017-01-06T17:23:44 <sipa> sorry, i was probably misreading what you said
3612017-01-06T17:24:01 <morcos> or something.. nm
3622017-01-06T17:24:16 <cfields> sipa: it's mentioned in a bunch of places and at one point you said "I certainly noticed it only processed one message at a time", so i thought we were on the same page
3632017-01-06T17:24:26 <cfields> no worries though, sounds like we're all good now
3642017-01-06T17:24:44 <morcos> cfields: i'll review again after you fix outstanding comments
3652017-01-06T17:24:53 <sipa> cfields: i noticed that your PR changed it to only processing one message at a time
3662017-01-06T17:25:06 <sipa> i didn't realize that that was not a change
3672017-01-06T17:25:17 <cfields> sipa: ah, heh. i misread you too then :)
3682017-01-06T17:25:45 <morcos> i'm not sure i 100% understand the wait_until condition, is the idea that you don't want spurious wakeups to cause another loop?
3692017-01-06T17:25:56 <cfields> ok. I rebased this morning to address all nits and keep the loop in. Will back that out and push.
3702017-01-06T17:26:01 <sipa> anyway - misunderstandings in both directions. i should have read the code, instead of making (apparently 3-year old) assumptions about the code
3712017-01-06T17:26:31 <cfields> sipa: sure, no worries. It's not obvious behavior _at all_.
3722017-01-06T17:27:03 <cfields> morcos: the condition lets us wake the processor from the message handler thread when a new message comes in
3732017-01-06T17:27:11 <cfields> and yea, avoids spurious wakes too
3742017-01-06T17:31:35 *** brg444 has joined #bitcoin-core-dev
3752017-01-06T17:38:07 <bitcoin-git> [bitcoin] sipa pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/a55716abe566...46b249e578e8
3762017-01-06T17:38:08 <bitcoin-git> bitcoin/master 9479f8d Jonas Schnelli: Allow shutdown during LoadMempool, dump only when necessary
3772017-01-06T17:38:09 <bitcoin-git> bitcoin/master 325e400 Jonas Schnelli: [Qt] Do proper shutdown
3782017-01-06T17:38:09 <bitcoin-git> bitcoin/master 46b249e Pieter Wuille: Merge #9408: Allow shutdown during LoadMempool, dump only when necessary...
3792017-01-06T17:38:18 <bitcoin-git> [bitcoin] sipa closed pull request #9408: Allow shutdown during LoadMempool, dump only when necessary (master...2016/12/memp_dump) https://github.com/bitcoin/bitcoin/pull/9408
3802017-01-06T17:38:57 *** wrkrcoop has joined #bitcoin-core-dev
3812017-01-06T17:45:15 *** wrkrcoop has quit IRC
3822017-01-06T17:45:37 *** wrkrcoop has joined #bitcoin-core-dev
3832017-01-06T17:47:42 <morcos> cfields: ah yes, ok good.. cool. i like the new design...
3842017-01-06T17:48:59 <cfields> morcos: great, thanks.
3852017-01-06T17:50:55 *** brg444 has quit IRC
3862017-01-06T17:51:28 *** brg444 has joined #bitcoin-core-dev
3872017-01-06T17:53:38 <luke-jr> BlueMatt: how's this look now?
3882017-01-06T17:56:20 *** paveljanik has joined #bitcoin-core-dev
3892017-01-06T17:56:20 *** paveljanik has joined #bitcoin-core-dev
3902017-01-06T17:57:24 <cfields> morcos: updated. Very little changed from before, mostly just fixed some things in the interim commits to be more correct for easier review
3912017-01-06T18:00:55 *** wasi has quit IRC
3922017-01-06T18:05:14 *** jannes has quit IRC
3932017-01-06T18:25:46 *** sipa has quit IRC
3942017-01-06T18:25:46 *** sipa has joined #bitcoin-core-dev
3952017-01-06T18:37:38 *** laurentmt has joined #bitcoin-core-dev
3962017-01-06T18:38:12 *** laurentmt has quit IRC
3972017-01-06T18:40:28 <brg444> can someone confirm how many iterations of segwit testnet there were?
3982017-01-06T18:41:21 <sipa> 4, i believe
3992017-01-06T18:42:54 <brg444> thanks
4002017-01-06T19:18:58 <morcos> cfields: one more question on that wait_until.. lets say a block message comes in, takes you a while to process.. if any peers sent you a new message in the interim, you won't wait b/c of fMsgProcWake correct?
4012017-01-06T19:19:56 <morcos> But if no peers sent you a message, you will announce quickly to peers N+1 -> MAX_CONNECTIONS, but then sleep up to 100ms before announcing to peers 1 -> N-1 ?
4022017-01-06T19:20:51 <gmaxwell> sipa: Processmessage _currently_ processes one at a time, there is a break stuck in the bottom of the loop.
4032017-01-06T19:21:38 *** Guest98817 has quit IRC
4042017-01-06T19:21:50 <morcos> I thought I had seen somewhere talk about making the wait_until time be 100ms from start of loop and not end, or perhaps we should add a WakeMessageHandler for new tips in particular?
4052017-01-06T19:22:08 *** cjamthagen_ has joined #bitcoin-core-dev
4062017-01-06T19:22:12 *** wump has joined #bitcoin-core-dev
4072017-01-06T19:22:27 *** so has quit IRC
4082017-01-06T19:22:27 *** AaronvanW has quit IRC
4092017-01-06T19:22:27 *** wumpus has quit IRC
4102017-01-06T19:22:28 *** cjamthagen has quit IRC
4112017-01-06T19:22:28 *** afk11 has quit IRC
4122017-01-06T19:22:44 *** afk11 has joined #bitcoin-core-dev
4132017-01-06T19:22:44 *** afk11 has quit IRC
4142017-01-06T19:22:44 *** afk11 has joined #bitcoin-core-dev
4152017-01-06T19:23:03 <gmaxwell> morcos: I opened a PR that did those things, and also explicitly asked about the fact that it changed the message handling back to process multiple messages. After no one replied for a bit I just changed it back to one message at a time.
4162017-01-06T19:23:13 <gmaxwell> Then after cfields said he preferred his net refactors I closed it.
4172017-01-06T19:23:13 <cfields> morcos: yes, that would probably make sense. I think gmaxwell's change included that
4182017-01-06T19:23:46 <gmaxwell> it didn't really make that much of a difference when the other problems were fixed.
4192017-01-06T19:24:32 <morcos> gmaxwell: I like the changes in 9441 and i think its good to be making progress as part of a larger roadmap.. i think it captures most of the improtant improvements..
4202017-01-06T19:25:18 <morcos> perhaps we can add quick relay of new tips, and processing multiple messages requires a bit more thought in my view.. as we can see by the fact that it was ever taken out in the first place
4212017-01-06T19:25:38 <morcos> that said, i admit i did not look at your PRs
4222017-01-06T19:25:53 <morcos> hard to keep up!
4232017-01-06T19:26:18 <cfields> It's certainly reasonable to tweak it now that the dependencies are untangled, I just tried to keep the scope narrow at first
4242017-01-06T19:26:29 <gmaxwell> I know, that why I closed them rather than have more things to look at!
4252017-01-06T19:26:57 <gmaxwell> not gonna stop me from going 'I already pointed this out, if you only listened!' :P
4262017-01-06T19:27:22 <morcos> insufficient emoticons
4272017-01-06T19:27:35 <sipa> gmaxwell: i finally understand your comment on the PR
4282017-01-06T19:27:53 <sipa> gmaxwell: i thought you were trying to say that that PR changed it to only process one at a time (which i noticed)... and i was very confused by what you said afterwards about fixing it
4292017-01-06T19:30:02 <gmaxwell> sipa: it changed it to process multiple at a time initially, and I immediately added a line comment on that change asking for review of that (which github seems to have lost when I force pushed a change that reverted back to the old behavior)
4302017-01-06T19:30:03 <cfields> morcos: hmm, wait. Are you talking about the new quick-relay from 9375 in particular?
4312017-01-06T19:30:15 <morcos> cfields: no i'm talking about exactly not that
4322017-01-06T19:30:20 <sipa> seems i was just assuming i knew what master did, and i misinterpreted everything that people tried to explain it to me
4332017-01-06T19:30:39 <cfields> morcos: ok, good
4342017-01-06T19:31:18 *** AaronvanW has joined #bitcoin-core-dev
4352017-01-06T19:31:19 *** AaronvanW has quit IRC
4362017-01-06T19:31:19 *** AaronvanW has joined #bitcoin-core-dev
4372017-01-06T19:31:36 <gmaxwell> sipa: I think it should probably handle multiple at a time subject to some time limit. ::shrugs::
4382017-01-06T19:31:43 <morcos> cfields: its very easy to see the behavior with 9375 now though b/c of the cached blocks making the annoucements so fast. you watch annoucements in quick succession up to some high numbered peer and then a pause before announcements start to low numbered peers
4392017-01-06T19:32:40 <sipa> gmaxwell: absolutely agree
4402017-01-06T19:33:06 <sipa> but if we've done it this way since 0.10, i really don't care whether that happens in 0.14 or not
4412017-01-06T19:33:42 <morcos> sipa: gmaxwell: i think ideally we might do something even smarter, such as queue received transactions to be ATMP'ed after we'd gotten through block relay.. however its a bit tricky in that you dont' want to reorder those after any potential other cmpctblock messages for reconstruction purposes
4422017-01-06T19:33:51 <cfields> morcos: ah, i think that'd be a different culprit then
4432017-01-06T19:34:08 <gmaxwell> sipa: in other things people probably didn't notice, I've been complaining that our socket recieve buffer (5 MB) is _way_ too small given how long executions of the message handler take; and it is adversely impacting performance; even with cfields' PR.
4442017-01-06T19:34:25 <morcos> cfields: wait, why a different culprit? didn't the old code have the same problem in a different way?
4452017-01-06T19:35:25 <cfields> morcos: to be clear, you're saying that you observe that behavior with the cached blocks?
4462017-01-06T19:36:04 <morcos> cfields: :) yes, but not the pre-announced cached blocks. we use the cached blocks for regular announcment too.
4472017-01-06T19:36:10 <gmaxwell> sipa: e.g. right now we can, during a single handler run, connect 999 blocks which will take 2000 seconds even on a moderately fast computer... all the rx buffers just fill. (and on a really slow computer, we'll ping timeout our peers while connecting a wad of blocks)
4482017-01-06T19:36:53 <cfields> gmaxwell: https://github.com/bitcoin/bitcoin/pull/9441#issuecomment-270397280 . I think we should consider changing this for 0.14 as well.
4492017-01-06T19:39:21 <cfields> morcos: aha, i see. I'm with you now.
4502017-01-06T19:39:47 <morcos> they just make the rest of the loop so fast that the pause is more visible
4512017-01-06T19:43:53 <gmaxwell> morcos: my strategy was basically to make the loop run immediately again after anything interestin happened. I think it's harmless to always execute the loop an extra time.
4522017-01-06T19:47:06 <morcos> gmaxwell: how would you define interesting? any message processed?
4532017-01-06T19:48:28 <gmaxwell> morcos: yes, though my PR didn't bother catching any message processed, it did catch any message sent or any block recieved, I believe.
4542017-01-06T19:49:27 <gmaxwell> I think it would be fine to make it do any message sent or recieved.
4552017-01-06T19:51:25 <gmaxwell> I also made it run through the loop an extra time in any case it skipped something due to lock contention.
4562017-01-06T19:51:36 <sipa> gmaxwell: i'm aware... but i think it's just fundamentally broken that we're pegging the message handler thread for 2000s
4572017-01-06T19:51:56 <sipa> gmaxwell: it's not too hard to not always connect everything we have
4582017-01-06T19:52:27 <gmaxwell> sipa: That would be good, the change to accomplish that wasn't obvious to me or I would have PRed it already; though that is necessary it's not sufficient.
4592017-01-06T19:53:19 <gmaxwell> sipa: since even a _1_ second delay coupled with a 5MB buffer is enough to limit our IBD sync speed to far below what we can reindex-chainstate at on reasonable hardware.
4602017-01-06T19:54:02 *** wrkrcoop has quit IRC
4612017-01-06T19:56:19 <gmaxwell> morcos: the wake on lock contention seemed important to me, otherwise we could get a message from a peer, bounce off cs_main before getting to handle it, then sleep for 100ms before trying again.
4622017-01-06T19:57:40 <gmaxwell> (e.g. if we're competing with rpc for cs_main)
4632017-01-06T19:59:12 *** wrkrcoop has joined #bitcoin-core-dev
4642017-01-06T19:59:27 <morcos> gmaxwell: hmm.. that makes sense. where are you referring to where we skip handling the message if we can't get cs_main?
4652017-01-06T20:00:38 *** wrkrcoop has quit IRC
4662017-01-06T20:02:06 <gmaxwell> morcos: ah, I think one of the just merged networking changes just removed where we did that.
4672017-01-06T20:02:07 <morcos> oh in SendMessages
4682017-01-06T20:02:20 <gmaxwell> oh no, there it is.
4692017-01-06T20:05:03 <morcos> gmaxwell: on another note, i guess our ability to make use of >4 cores isn't as good as I thought... I had a whole series of PR's that removed successive bottlenecks, but i'd misremembered how much progress we could make wiht only the cuckoocache
4702017-01-06T20:05:43 <morcos> And then I got sidetracked by the near conesnsus bug with CCoinsViewCache.. but when I get a chance I'll go back and see if there are other parts of that that are still worth doing now
4712017-01-06T20:05:47 <gmaxwell> yea...
4722017-01-06T20:07:25 <BlueMatt> ugh, ffs, fibre cuts in india means fibre rtt between eu and asia is up 90ms on one path :(
4732017-01-06T20:07:58 <BlueMatt> luke-jr: did you fix https://github.com/bitcoin/bitcoin/pull/8775#discussion_r94985339 ?
4742017-01-06T20:07:59 <sipa> that try_lock cs_main can go away after #9419 (+ follow ups), i think, as it will be replaced by the nodestate locks
4752017-01-06T20:08:03 <gribble> https://github.com/bitcoin/bitcoin/issues/9419 | Stop Using cs_main for CNodeState/State() by TheBlueMatt · Pull Request #9419 · bitcoin/bitcoin · GitHub
4762017-01-06T20:10:08 <luke-jr> BlueMatt: no, where is it assumed to return non-NULL?
4772017-01-06T20:10:27 <gmaxwell> there is some advantage in skipping processing peers that need a lock, when other peers can be processed without it.
4782017-01-06T20:10:48 <BlueMatt> luke-jr: ok, please add documentation to note that it is assumed it can return null
4792017-01-06T20:12:17 <gmaxwell> though on the other hand, I think that that construction could leave us sending pings even if cs_main is deadlocked which would be undesirable. (not an actual issue because our message handler will get stuck elsewhere in the case, but still)
4802017-01-06T20:12:30 <luke-jr> I would think that's implied in returning a pointer type, but ok
4812017-01-06T20:15:22 <BlueMatt> luke-jr: could you not rebase when people are in the middle of review?
4822017-01-06T20:18:21 <luke-jr> haven't rebased that PR in a week, but ok
4832017-01-06T20:18:48 <BlueMatt> did you just rebase again?
4842017-01-06T20:18:55 <luke-jr> no, just added the comment
4852017-01-06T20:19:05 <BlueMatt> no? the previous head is now gone?
4862017-01-06T20:19:35 <luke-jr> indeed, I amended it
4872017-01-06T20:19:46 <BlueMatt> please do not do that
4882017-01-06T20:19:56 *** wrkrcoop has joined #bitcoin-core-dev
4892017-01-06T20:21:36 * luke-jr starts a list of the contradicting development processes preferred by various people.
4902017-01-06T20:25:37 * BlueMatt restarts review from the start :(
4912017-01-06T20:25:40 <BlueMatt> does anyone ask for regular squash/rebase mid-review?
4922017-01-06T20:28:36 <luke-jr> I don't usually distinguish (or have a way to) when others are actively reviewing. (note there was already amended commits before I became aware you were)
4932017-01-06T20:29:10 <gmaxwell> at what point is someone not reviewing?
4942017-01-06T20:30:18 <luke-jr> gmaxwell: exactly, hence why some desiring squashing vs others not liking squashing [at particular times] is confusing to resolve
4952017-01-06T20:30:22 <BlueMatt> when it is time to merge and/or there are limited comments showing up?
4962017-01-06T20:30:50 <BlueMatt> no one desires squashing unless its been a while since things have been commented on, though to be fair, you should, at a minimum, comment when you squash and note changes
4972017-01-06T20:31:07 <BlueMatt> eg respond to the previous comments and note where you did/didnt make changes, instead of letting them sit
4982017-01-06T20:32:02 <sipa> i usually prefer squashing trivial fixes immediately, unless it's a very complicated PR
4992017-01-06T20:32:22 <sipa> most of the time is understanding what the PR is trying to achieve and how... reading the code is easy
5002017-01-06T20:32:48 *** wrkrcoop has quit IRC
5012017-01-06T20:33:06 <gmaxwell> matt's style can be helpful on more complicated ones, but as someone who has often come to a PR to review later, I've found the style to really suck in that case. I waste my time finding bugs that are already fixed in later updates.
5022017-01-06T20:33:08 <BlueMatt> not for a major refactor pr where most of the pr is just code movement
5032017-01-06T20:33:12 *** wrkrcoop has joined #bitcoin-core-dev
5042017-01-06T20:33:18 <sipa> gmaxwell: likewise
5052017-01-06T20:33:20 *** wrkrcoop has quit IRC
5062017-01-06T20:33:40 <sipa> (but i don't mind following either style... just my personal preference is usually fixing things immediately)
5072017-01-06T20:33:42 <BlueMatt> gmaxwell: I try to title such commits f "Commit title this should be squashed into" fix XYZ
5082017-01-06T20:33:48 <BlueMatt> which should at least make it easy to glance at such changes
5092017-01-06T20:34:06 <sipa> i guess things have improved with the "review" thing
5102017-01-06T20:34:19 <gmaxwell> also it leaves me having to re-review the squash since sometimes a pair of reasonable looking changes my reveal their brokenness once merged. (also we have no tools to tell if a squash was faithful in any case, so someone malicious could slip something in if people didn't review the squash just as carefully)
5112017-01-06T20:34:38 <sipa> so you can comment on an issue, and then later delete if you see it's already fixed ahead of time
5122017-01-06T20:35:13 <BlueMatt> yes, my bigger annoyance is having to re-review after squash was shit
5132017-01-06T20:35:30 <BlueMatt> its easy if its clear and the commits are just being cleanly squashed (can compare treeish)
5142017-01-06T20:35:40 <luke-jr> I have an alias that compares diffs that I've gotten used to using to see what changed in an amend
5152017-01-06T20:41:10 *** wrkrcoop has joined #bitcoin-core-dev
5162017-01-06T20:50:10 *** Giszmo has quit IRC
5172017-01-06T21:04:12 *** wrkrcoop has quit IRC
5182017-01-06T21:10:46 <owowo> is there a time when core drops a tx if unconfirmed for a long time? Or will it just keep on rebroadcasting it until the return of the Messiah?
5192017-01-06T21:11:11 <BlueMatt> the wallet will keep rebroadcasting, but you can "abandon" a transaction both in the gui and the rpc
5202017-01-06T21:11:32 <BlueMatt> the mempool will eventually drop them, but there are "helpful" nodes which like to rebroadcast lots of shit to their peers all the time
5212017-01-06T21:12:18 <owowo> ok, thx
5222017-01-06T21:23:06 *** wrkrcoop has joined #bitcoin-core-dev
5232017-01-06T21:35:40 *** brg444 has quit IRC
5242017-01-06T21:39:34 *** brg444 has joined #bitcoin-core-dev
5252017-01-06T21:43:48 *** Chris_Stewart_5 has quit IRC
5262017-01-06T21:45:50 *** Guyver2 has quit IRC
5272017-01-06T21:49:04 *** btcdrak has quit IRC
5282017-01-06T21:49:17 *** Chris_Stewart_5 has joined #bitcoin-core-dev
5292017-01-06T22:30:45 *** juscamarena_ has quit IRC
5302017-01-06T22:38:04 *** fengling has quit IRC
5312017-01-06T22:46:56 *** Chris_Stewart_5 has quit IRC
5322017-01-06T23:00:10 *** Chris_Stewart_5 has joined #bitcoin-core-dev
5332017-01-06T23:06:44 *** fengling has joined #bitcoin-core-dev
5342017-01-06T23:14:28 *** afk11 has quit IRC
5352017-01-06T23:16:55 *** fengling has quit IRC
5362017-01-06T23:18:48 *** afk11 has joined #bitcoin-core-dev
5372017-01-06T23:18:48 *** afk11 has quit IRC
5382017-01-06T23:18:48 *** afk11 has joined #bitcoin-core-dev
5392017-01-06T23:18:55 <bitcoin-git> [bitcoin] gmaxwell opened pull request #9484: Introduce assumevalid setting to skip validation presumed valid scripts. (master...script_elide_verified) https://github.com/bitcoin/bitcoin/pull/9484
5402017-01-06T23:29:08 <bitcoin-git> [bitcoin] mcelrath opened pull request #9485: ZMQ example using python3 and asyncio (master...python3zmq) https://github.com/bitcoin/bitcoin/pull/9485
5412017-01-06T23:43:45 *** MarcoFalke has quit IRC
5422017-01-06T23:44:13 *** fengling has joined #bitcoin-core-dev
5432017-01-06T23:44:54 *** laurentmt has joined #bitcoin-core-dev
5442017-01-06T23:54:04 *** wrkrcoop has quit IRC
5452017-01-06T23:58:40 *** TomMc has quit IRC
5462017-01-06T23:59:48 *** wrkrcoop has joined #bitcoin-core-dev