12016-06-08T00:00:28 <gmaxwell> Funny that.
22016-06-08T00:00:58 * gmaxwell checks to see if he created that article. no, surprising!
32016-06-08T00:03:12 * luke-jr assigns it to sipa's next proposal. jk
42016-06-08T00:45:52 *** hoihut has joined #bitcoin-core-dev
52016-06-08T00:51:16 *** Ylbam has quit IRC
62016-06-08T01:12:04 <adiabat> Hey, wondering if anyone is working on the idea of the "Bloom Filter Digest", like if there's a BIP in the works or anything
72016-06-08T01:12:15 <adiabat> there was a post in the mailing list about a month ago
82016-06-08T01:14:09 *** molly has joined #bitcoin-core-dev
92016-06-08T01:17:09 *** molz has quit IRC
102016-06-08T01:23:01 *** Alopex has quit IRC
112016-06-08T01:24:07 *** Alopex has joined #bitcoin-core-dev
122016-06-08T01:28:40 *** Chris_Stewart_5 has quit IRC
132016-06-08T01:35:04 *** dermoth has quit IRC
142016-06-08T01:35:50 *** dermoth has joined #bitcoin-core-dev
152016-06-08T01:51:26 *** Chris_Stewart_5 has joined #bitcoin-core-dev
162016-06-08T01:58:18 <Chris_Stewart_5> If I specify a -datadir when launching an instnce of bitcoind, does my bitcoind instance look for a bitcoin.conf inside of my datadir, or ~/.bitcoin/bitcoin.conf?
172016-06-08T02:01:17 *** molz has joined #bitcoin-core-dev
182016-06-08T02:02:57 *** skyraider has joined #bitcoin-core-dev
192016-06-08T02:03:44 <achow101> Chris_Stewart_5: it looks for it in your specified datadir
202016-06-08T02:04:45 *** molly has quit IRC
212016-06-08T02:07:53 <Chris_Stewart_5> achow101: Thanks
222016-06-08T02:12:32 *** hoihut has quit IRC
232016-06-08T02:36:47 *** justanot1eruser has joined #bitcoin-core-dev
242016-06-08T02:36:58 *** justanotheruser has quit IRC
252016-06-08T02:42:17 *** adiabat has quit IRC
262016-06-08T02:46:47 <phantomcircuit> cfields_, travis appears to be borked
272016-06-08T02:47:20 <cfields_> phantomcircuit: https://github.com/bitcoin/bitcoin/pull/8164 ?
282016-06-08T02:47:22 <cfields_> or something else?
292016-06-08T02:48:12 <cfields_> yea, same problem
302016-06-08T02:48:24 <phantomcircuit> https://github.com/bitcoin/bitcoin/pull/8152
312016-06-08T02:48:36 *** assgrass has joined #bitcoin-core-dev
322016-06-08T02:48:50 <phantomcircuit> the no-wallet test fails and that pr is only touching wallet code
332016-06-08T02:48:55 <phantomcircuit> so it's definitely a travis failure
342016-06-08T02:49:33 <cfields_> phantomcircuit: see 8164. master's currently borked, so that will need to be fixed first
352016-06-08T02:49:34 *** assgrass has quit IRC
362016-06-08T02:49:43 <phantomcircuit> jonasschnelli, also i can swap the order of the commits in 8152 such that there's never a performance regression even within the pr
372016-06-08T02:49:44 *** assgrass has joined #bitcoin-core-dev
382016-06-08T02:50:04 <phantomcircuit> ah ok
392016-06-08T02:50:35 *** assgrass has quit IRC
402016-06-08T02:51:24 *** grassass has quit IRC
412016-06-08T02:51:44 *** xiangfu has joined #bitcoin-core-dev
422016-06-08T02:58:36 <cfields_> wumpus: for backlog, ^^ please check out 8164 when you're around if jonasschnelli doesn't beat you to it :)
432016-06-08T02:58:52 *** Kexkey has joined #bitcoin-core-dev
442016-06-08T03:08:45 *** Cory has quit IRC
452016-06-08T03:11:17 *** Kexkey has quit IRC
462016-06-08T03:13:18 *** Chris_Stewart_5 has quit IRC
472016-06-08T03:16:52 *** supasonic has joined #bitcoin-core-dev
482016-06-08T03:28:55 *** Chris_Stewart_5 has joined #bitcoin-core-dev
492016-06-08T03:32:47 *** achow101 has quit IRC
502016-06-08T03:37:53 *** molly has joined #bitcoin-core-dev
512016-06-08T03:41:00 *** molz has quit IRC
522016-06-08T03:41:58 *** Cory has joined #bitcoin-core-dev
532016-06-08T03:42:47 <GitHub141> [bitcoin] theuni opened pull request #8167: gitian: Ship debug tarballs/zips with debug symbols (master...split-debug) https://github.com/bitcoin/bitcoin/pull/8167
542016-06-08T03:43:03 *** Chris_Stewart_5 has quit IRC
552016-06-08T03:43:47 *** raedah has quit IRC
562016-06-08T03:43:48 *** xiangfu has quit IRC
572016-06-08T03:47:23 *** jiggalator has joined #bitcoin-core-dev
582016-06-08T03:51:17 *** fengling has joined #bitcoin-core-dev
592016-06-08T03:54:38 *** fengling has quit IRC
602016-06-08T04:01:35 *** jiggalator has joined #bitcoin-core-dev
612016-06-08T04:05:14 *** jiggalator has quit IRC
622016-06-08T04:06:02 *** jiggalator has joined #bitcoin-core-dev
632016-06-08T04:11:42 *** justanot1eruser is now known as justanotheruser
642016-06-08T04:13:33 *** jiggalator has quit IRC
652016-06-08T04:39:02 *** Alopex has quit IRC
662016-06-08T04:40:07 *** Alopex has joined #bitcoin-core-dev
672016-06-08T04:51:23 *** moli has joined #bitcoin-core-dev
682016-06-08T04:53:21 *** molly has quit IRC
692016-06-08T04:55:59 *** frankenmint has joined #bitcoin-core-dev
702016-06-08T05:00:01 *** Alopex has quit IRC
712016-06-08T05:01:06 *** Alopex has joined #bitcoin-core-dev
722016-06-08T05:01:33 *** skyraider has quit IRC
732016-06-08T05:04:40 *** jtimon has quit IRC
742016-06-08T05:07:43 *** ghtdak has quit IRC
752016-06-08T05:08:12 *** ghtdak has joined #bitcoin-core-dev
762016-06-08T05:17:47 *** paveljanik has quit IRC
772016-06-08T05:28:29 *** Giszmo has quit IRC
782016-06-08T05:41:14 *** Squidicc has quit IRC
792016-06-08T05:48:04 *** ozanyurt has quit IRC
802016-06-08T05:57:13 *** ghtdak has quit IRC
812016-06-08T06:00:07 *** ghtdak has joined #bitcoin-core-dev
822016-06-08T06:04:48 *** Ylbam has joined #bitcoin-core-dev
832016-06-08T06:26:50 *** blur3d has quit IRC
842016-06-08T06:37:56 *** supasonic has quit IRC
852016-06-08T07:17:33 *** xiangfu has joined #bitcoin-core-dev
862016-06-08T07:18:43 *** ozanyurt has joined #bitcoin-core-dev
872016-06-08T07:19:17 *** trippysa1mon has quit IRC
882016-06-08T07:25:18 *** adiabat has joined #bitcoin-core-dev
892016-06-08T07:46:14 *** adiabat has quit IRC
902016-06-08T07:55:01 <jonasschnelli> wumpus: ParseInt does use int32_t and not uint32_t... isn't that a problem?
912016-06-08T07:55:18 <wumpus> do you need the full range of uint32_t?
922016-06-08T07:55:35 <jonasschnelli> nSequence is uint32_t i guess.
932016-06-08T07:55:45 <wumpus> if so, we need a ParseUint32
942016-06-08T07:56:11 <wumpus> I'll make one.
952016-06-08T07:56:28 <jonasschnelli> Yes. I just saw that there are atoi in bitcoin-tx (before my change) and I just was "continue" that way. But I agree, re-using the ParseInt* stuff is better
962016-06-08T07:56:36 <wumpus> do you need that atoi change in #8164 to 'unstuck' travis?
972016-06-08T07:56:49 <jonasschnelli> yes.
982016-06-08T07:57:00 <wumpus> ok
992016-06-08T07:57:07 <wumpus> I'll just merge #8164 then
1002016-06-08T07:57:10 <jonasschnelli> yes.
1012016-06-08T07:57:17 <jonasschnelli> We can change it bitcoin-tx wide later
1022016-06-08T07:57:32 <wumpus> but we should move away from using low-level number parsing functions and use the ones in util where available
1032016-06-08T07:57:34 <wumpus> right
1042016-06-08T07:57:47 <jonasschnelli> There are servals atoi
1052016-06-08T07:57:54 <jonasschnelli> and even atoi64
1062016-06-08T07:58:21 <wumpus> the problem is that those functions don't have any error reporting, or range checking, etc
1072016-06-08T07:58:42 <wumpus> or if they do it's annoying to use
1082016-06-08T07:58:47 <wumpus> or even OS dependent
1092016-06-08T07:59:27 <GitHub30> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/79004d4ae671...0f24eaf253ab
1102016-06-08T07:59:28 <GitHub30> bitcoin/master 86efa30 Jonas Schnelli: [Bitcoin-Tx] fix missing test fixtures, fix 32bit atoi issue
1112016-06-08T07:59:28 <GitHub30> bitcoin/master 0f24eaf Wladimir J. van der Laan: Merge #8164: [Bitcoin-Tx] fix missing test fixtures, fix 32bit atoi issue...
1122016-06-08T07:59:37 <GitHub188> [bitcoin] laanwj closed pull request #8164: [Bitcoin-Tx] fix missing test fixtures, fix 32bit atoi issue (master...2016/04/rbf_base) https://github.com/bitcoin/bitcoin/pull/8164
1132016-06-08T08:01:03 <jonasschnelli> Yes. And sorry for the travis breaker...
1142016-06-08T08:01:36 <wumpus> I should have waited for travis before merging, I ran the test locally and assumed it'd be ok
1152016-06-08T08:03:12 <jonasschnelli> Yes. Did the same. Haven't though about 32bit issues. But great that we have Travis!
1162016-06-08T08:03:26 *** blur3d has joined #bitcoin-core-dev
1172016-06-08T08:03:26 <jonasschnelli> A failing travis is always a success. :)
1182016-06-08T08:03:48 <jonasschnelli> going to re-kick failed pulls
1192016-06-08T08:19:25 *** kadoban has quit IRC
1202016-06-08T08:27:02 <GitHub98> [bitcoin] laanwj opened pull request #8168: util: Add ParseUInt32 and ParseUInt64 (master...2016_06_parseuint) https://github.com/bitcoin/bitcoin/pull/8168
1212016-06-08T08:27:13 <wumpus> let's see if this one passes travis, what surprises windows has in store for us...
1222016-06-08T08:28:43 <gmaxwell> Great mysteries of the window--- who know what lies beyond it's curtain rimmed borders.
1232016-06-08T08:30:13 <sipa> the Window kingdom has been in decline for years
1242016-06-08T08:30:17 <wumpus> a perilous landscape full of traps and mines
1252016-06-08T08:33:21 <wumpus> "In locales other than the 'C' locale, other strings may be accepted. (For example, the thousands separator of the current locale may be supported.)" ... oh crap, I thought strto* avoided the locale madness, I was wrong
1262016-06-08T08:34:18 <wumpus> why is it so difficult to have a number parsing function that does strict parsing and the set of inputs that it accepts is independent of geographical conditions
1272016-06-08T08:35:53 <wumpus> it's almost easier to just write one from scratch than use the C-provided functions
1282016-06-08T08:37:09 <wumpus> in any case using our own utility function makes it easier to swap it out later...
1292016-06-08T08:37:16 <gmaxwell> yea, there are actually a bunch of file formats that are befuxored by this... internationalization was bolted onto the standard library... so there aren't even normal locale independant functions, and you can't change the locale without potentially screwing up other threads.. (well there is the locale_t stuff, but not really portable yet AFAIK)
1302016-06-08T08:37:56 <wumpus> I can imagine - you need to be such a language lawyer to get these things rihgt
1312016-06-08T08:38:32 <wumpus> and yes it was bolted on in retrospect
1322016-06-08T08:39:59 <wumpus> I'm entirely for handling locales where it makes sense, but there's a place for simple deterministic parsing functions (network protocols, file formats) and a place for internationalized handling (such as GUIs), those don't really overlap
1332016-06-08T08:41:09 <gmaxwell> My general principle is to avoid strings in network protocols and file formats. :) but really, textual file formats are often fairly handy.
1342016-06-08T08:42:01 <wumpus> sure, but that's a completely orthogonal discussion, usually you don't get to choose
1352016-06-08T08:43:52 <wumpus> though passing binary numbers on the command line would be interesting :-)
1362016-06-08T08:45:21 <gmaxwell> just don't type anything with any zero bytes...
1372016-06-08T08:45:50 <wumpus> well wouldn't be the first time, passing addresses and code is very popular when trying to get setuid'ed executables to do eh non-standard things
1382016-06-08T08:46:23 <wumpus> yes, those are pesky
1392016-06-08T08:47:40 <gmaxwell> you mean, to do especially awesome things. :)
1402016-06-08T08:51:47 *** MarcoFalke has joined #bitcoin-core-dev
1412016-06-08T08:52:02 <wumpus> exactly
1422016-06-08T08:52:07 <sipa> wumpus: binary numbers... as in head -n 10011101 file
1432016-06-08T08:56:20 *** ozanyurt has quit IRC
1442016-06-08T08:56:32 <wumpus> binary, at the speed of one byte per bit!
1452016-06-08T08:56:36 *** ozanyurt has joined #bitcoin-core-dev
1462016-06-08T09:04:08 *** Guyver2 has joined #bitcoin-core-dev
1472016-06-08T09:05:15 *** ozanyurt has quit IRC
1482016-06-08T09:05:34 *** ozanyurt has joined #bitcoin-core-dev
1492016-06-08T09:19:03 *** ghtdak has quit IRC
1502016-06-08T09:23:19 *** ghtdak has joined #bitcoin-core-dev
1512016-06-08T09:29:42 *** jannes has joined #bitcoin-core-dev
1522016-06-08T09:45:03 *** Ginnarr has joined #bitcoin-core-dev
1532016-06-08T09:47:40 *** laurentmt has joined #bitcoin-core-dev
1542016-06-08T09:49:30 *** laurentmt has quit IRC
1552016-06-08T10:01:21 *** xiangfu has quit IRC
1562016-06-08T10:09:39 *** JackH has joined #bitcoin-core-dev
1572016-06-08T10:14:23 *** xiangfu has joined #bitcoin-core-dev
1582016-06-08T10:25:55 *** jl2012 has quit IRC
1592016-06-08T10:26:20 *** xiangfu has quit IRC
1602016-06-08T10:40:26 *** Ginnarr has quit IRC
1612016-06-08T10:45:37 *** jl2012 has joined #bitcoin-core-dev
1622016-06-08T10:57:13 <GitHub32> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/0f24eaf253ab...2156fa23b8ac
1632016-06-08T10:57:14 <GitHub32> bitcoin/master beceac9 Peter Todd: Disable the mempool P2P command when bloom filters disabled...
1642016-06-08T10:57:14 <GitHub32> bitcoin/master 3d3602f Jonas Schnelli: Add RPC test for the p2p mempool command in conjunction with disabled bloomfilters
1652016-06-08T10:57:15 <GitHub32> bitcoin/master 2156fa2 Wladimir J. van der Laan: Merge #8078: Disable the mempool P2P command when bloom filters disabled...
1662016-06-08T10:57:23 <GitHub78> [bitcoin] laanwj closed pull request #8078: Disable the mempool P2P command when bloom filters disabled (master...2016-05-mempool-p2p-and-bloom) https://github.com/bitcoin/bitcoin/pull/8078
1672016-06-08T11:02:12 <GitHub130> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/2156fa23b8ac...67c91f8c4cf7
1682016-06-08T11:02:13 <GitHub130> bitcoin/master c769c4a Gregory Maxwell: Avoid counting failed connect attempts when probably offline....
1692016-06-08T11:02:13 <GitHub130> bitcoin/master 6182d10 Gregory Maxwell: Do not increment nAttempts by more than one for every Good connection....
1702016-06-08T11:02:14 <GitHub130> bitcoin/master 67c91f8 Wladimir J. van der Laan: Merge #8065: Addrman offline attempts...
1712016-06-08T11:02:22 <GitHub45> [bitcoin] laanwj closed pull request #8065: Addrman offline attempts (master...addrman_offline_attempts) https://github.com/bitcoin/bitcoin/pull/8065
1722016-06-08T11:07:53 *** edward has joined #bitcoin-core-dev
1732016-06-08T11:08:34 *** STAFFSCOINS_ has joined #bitcoin-core-dev
1742016-06-08T11:09:58 <GitHub196> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/67c91f8c4cf7...761cddb69029
1752016-06-08T11:09:58 <GitHub196> bitcoin/master 2e49448 Wladimir J. van der Laan: tor: Change auth order to only use HASHEDPASSWORD if -torpassword...
1762016-06-08T11:09:59 <GitHub196> bitcoin/master 761cddb Wladimir J. van der Laan: Merge #7703: tor: Change auth order to only use password auth if -torpassword...
1772016-06-08T11:10:05 <GitHub18> [bitcoin] laanwj closed pull request #7703: tor: Change auth order to only use password auth if -torpassword (master...2016_03_auth_order) https://github.com/bitcoin/bitcoin/pull/7703
1782016-06-08T11:13:40 *** ozanyurt has quit IRC
1792016-06-08T11:17:16 <MarcoFalke> wumpus: I have cherry picked the backports for .12 back in April: https://github.com/bitcoin/bitcoin/pull/7938 Hope this is helpful
1802016-06-08T11:17:30 <MarcoFalke> Also, I was wondering if we need any test framework backports
1812016-06-08T11:17:41 <sipa> i would say yes
1822016-06-08T11:17:47 <wumpus> MarcoFalke: thanks!
1832016-06-08T11:17:57 <MarcoFalke> i.e. segwit backport will be different due to missing py3 in .12
1842016-06-08T11:18:03 <sipa> i think 0
1852016-06-08T11:18:13 <sipa> i think 0.12 should be uograded to py3 as well
1862016-06-08T11:18:16 <wumpus> philosophy for the test framework should be: everything that can run against 0.12 should run against 0.12
1872016-06-08T11:18:20 <wumpus> agree with sipa
1882016-06-08T11:18:49 <sipa> of course, if a test requires an rpc that didn't exist in 0.12 yet
1892016-06-08T11:18:55 <wumpus> there is no reason to be exceedingly careful for regressions with backports of test changes
1902016-06-08T11:18:55 <sipa> then probably not
1912016-06-08T11:18:56 <MarcoFalke> Ok, will have a look tonight. Will be quite a huge diff.
1922016-06-08T11:19:06 <wumpus> yeah, no problem
1932016-06-08T11:19:10 <sipa> backporting tests never risks breakjng anything :)
1942016-06-08T11:19:20 <MarcoFalke> Will open a separate pull, just in case
1952016-06-08T11:19:23 <sipa> ... on the contrary, it may catch bugs in backports
1962016-06-08T11:20:31 <wumpus> agreed, better to do so in a separate PR, due to the difference in review density
1972016-06-08T11:21:24 <MarcoFalke> sipa: The python 3 switch for the segwit test was a single commit: https://github.com/sipa/bitcoin/commit/a7eeee1c07b5283c0984fcdaac04faac2d93b2e3. So in case I choke at backporting, you may as well not include those in the backport.
1982016-06-08T11:21:25 *** ozanyurt has joined #bitcoin-core-dev
1992016-06-08T11:28:28 *** molz has joined #bitcoin-core-dev
2002016-06-08T11:30:34 <GitHub9> [bitcoin] jonasschnelli opened pull request #8169: OSX diskimages need 0775 folder permissions (master...2016/06/fix_gitian_osx) https://github.com/bitcoin/bitcoin/pull/8169
2012016-06-08T11:31:23 *** moli has quit IRC
2022016-06-08T11:31:37 *** cryptapus has joined #bitcoin-core-dev
2032016-06-08T12:01:38 <GitHub172> [bitcoin] laanwj pushed 7 new commits to master: https://github.com/bitcoin/bitcoin/compare/761cddb69029...a7c41f2de03c
2042016-06-08T12:01:39 <GitHub172> bitcoin/master 1b9e6d3 Pieter Wuille: Add support for unique_ptr and shared_ptr to memusage
2052016-06-08T12:01:39 <GitHub172> bitcoin/master 8d39d7a Pieter Wuille: Switch CTransaction storage in mempool to std::shared_ptr
2062016-06-08T12:01:40 <GitHub172> bitcoin/master dbfb426 Pieter Wuille: Optimize the relay map to use shared_ptr's...
2072016-06-08T12:01:48 <GitHub0> [bitcoin] laanwj closed pull request #8126: std::shared_ptr based CTransaction storage in mempool (master...sharedmempool) https://github.com/bitcoin/bitcoin/pull/8126
2082016-06-08T12:02:33 <GitHub153> [bitcoin] laanwj closed pull request #7530: autogen.sh: check for libtool before automake fails to find it (master...libtool-check) https://github.com/bitcoin/bitcoin/pull/7530
2092016-06-08T12:14:09 *** paveljanik has joined #bitcoin-core-dev
2102016-06-08T12:15:17 <GitHub56> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/a7c41f2de03c...75ec320a0d53
2112016-06-08T12:15:18 <GitHub56> bitcoin/master faf82e8 MarcoFalke: [rpc] fundrawtransaction: Fix help text and interface
2122016-06-08T12:15:19 <GitHub56> bitcoin/master fa7f4f5 MarcoFalke: [rpc] fundrawtransaction feeRate: Use BTC/kB...
2132016-06-08T12:15:19 <GitHub56> bitcoin/master 75ec320 Wladimir J. van der Laan: Merge #8153: [rpc] fundrawtransaction feeRate: Use BTC/kB...
2142016-06-08T12:15:22 <GitHub172> [bitcoin] laanwj closed pull request #8144: [rpc] fundrawtransaction: Fix help text (master...Mf1606-rpcDoc) https://github.com/bitcoin/bitcoin/pull/8144
2152016-06-08T12:15:27 <GitHub0> [bitcoin] laanwj closed pull request #8153: [rpc] fundrawtransaction feeRate: Use BTC/kB (master...Mf1606-univalAny) https://github.com/bitcoin/bitcoin/pull/8153
2162016-06-08T12:21:58 *** moli has joined #bitcoin-core-dev
2172016-06-08T12:24:15 *** molz has quit IRC
2182016-06-08T12:25:59 <GitHub43> [bitcoin] laanwj pushed 7 new commits to master: https://github.com/bitcoin/bitcoin/compare/75ec320a0d53...6a034ed89891
2192016-06-08T12:26:00 <GitHub43> bitcoin/master 2b2d52e fanquake: [depends] Freetype 2.6.3...
2202016-06-08T12:26:01 <GitHub43> bitcoin/master 0385202 fanquake: [depends] ccache 3.2.5
2212016-06-08T12:26:01 <GitHub43> bitcoin/master bd3cbd5 fanquake: [depends] ZeroMQ 4.1.4
2222016-06-08T12:26:04 <GitHub64> [bitcoin] laanwj closed pull request #7993: [depends] Bump Freetype, ccache, ZeroMQ, miniupnpc, expat (master...depends-no-sourceforge) https://github.com/bitcoin/bitcoin/pull/7993
2232016-06-08T12:28:57 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2242016-06-08T12:34:24 *** murch has joined #bitcoin-core-dev
2252016-06-08T12:38:57 *** da2ce7_mobile has quit IRC
2262016-06-08T12:40:07 *** dermoth_ has joined #bitcoin-core-dev
2272016-06-08T12:40:35 *** dermoth has quit IRC
2282016-06-08T12:40:37 *** dermoth_ is now known as dermoth
2292016-06-08T12:44:11 *** da2ce7_mobile has joined #bitcoin-core-dev
2302016-06-08T12:53:32 *** fengling has joined #bitcoin-core-dev
2312016-06-08T12:55:07 <GitHub34> [bitcoin] sipa opened pull request #8170: Remove lookup-tx-by-utxo functionality (master...betternotxindex) https://github.com/bitcoin/bitcoin/pull/8170
2322016-06-08T13:13:15 *** jarret has quit IRC
2332016-06-08T13:14:45 <jonasschnelli> Hmm....
2342016-06-08T13:15:19 <jonasschnelli> another cleanup required for one of my pulls..
2352016-06-08T13:15:22 <jonasschnelli> *sight*
2362016-06-08T13:16:07 <sipa> sight is good
2372016-06-08T13:16:52 <jonasschnelli> *sigh* :-)
2382016-06-08T13:17:09 <jonasschnelli> wumpus: can you extend your ParseUInt32 to univalue?
2392016-06-08T13:17:38 <wumpus> why would univalue need to parse unsigned 32 bit integers?
2402016-06-08T13:18:00 <jonasschnelli> createrawtransactions new sequence number input per vin does not support unsigned
2412016-06-08T13:18:10 <wumpus> we treat all integers as 64 bit signed
2422016-06-08T13:18:15 <jonasschnelli> So > 0x7FFFFFFF will be rejected.. :(
2432016-06-08T13:18:26 <wumpus> which should be enough to support the full 32 bit unsigned range
2442016-06-08T13:18:31 <jonasschnelli> It calls int UniValue::get_int() const
2452016-06-08T13:18:40 <jonasschnelli> which does a `if (!ParseInt32(getValStr(), &retval))`
2462016-06-08T13:18:52 <jonasschnelli> and throws > 0x7FFFFFFF
2472016-06-08T13:18:52 <wumpus> oh, just use the 64-bit one then
2482016-06-08T13:19:04 *** Chris_Stewart_5 has quit IRC
2492016-06-08T13:19:14 <sipa> use get_int64(), and rangecheck the result
2502016-06-08T13:19:16 <wumpus> I don't think we should be adding more types of integers to JSON, that just complicates things
2512016-06-08T13:19:26 <jonasschnelli> Right... let me try
2522016-06-08T13:19:39 <wumpus> our previous JSON parsing library didn't even have a 32-bit signed integer get
2532016-06-08T13:25:26 *** jtimon has joined #bitcoin-core-dev
2542016-06-08T13:25:49 <jonasschnelli> should we allow -1 as sequence numbers? Pretty convenient.
2552016-06-08T13:28:17 <wumpus> wouldn't be very consistent if we do strict 32-bit unsigned int parsing for the -tx
2562016-06-08T13:29:44 <jonasschnelli> yes. Let me do a <0 check
2572016-06-08T13:30:32 <wumpus> I'd say sequence number is a positive value, and that should be enforced in the API; though -1 is convenient, negative numbers are slightly ambigious
2582016-06-08T13:31:18 <wumpus> we also print sequence numbers as unsigned int I hope?
2592016-06-08T13:32:31 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2602016-06-08T13:37:52 *** jcorgan has joined #bitcoin-core-dev
2612016-06-08T13:38:56 <jonasschnelli> wumpus: at least decoderawtransaction does this correct.
2622016-06-08T13:39:07 <wumpus> good, thanks for checking
2632016-06-08T13:39:15 <jonasschnelli> heh: entry.push_back(Pair("sequence", (uint64_t)txin.nSequence));
2642016-06-08T13:39:40 <jonasschnelli> I guess UniValues has no uint32 pair?
2652016-06-08T13:40:10 <jonasschnelli> but (uint64_t)txin.nSequence is fine IMO
2662016-06-08T13:40:17 <wumpus> yea, please just use 64 bit signed integeres with JSON
2672016-06-08T13:41:41 <wumpus> there's no need to support other integer types - certainly not for output, for input a specific range checked get function could be mildly useful, but that probably belongs at the application (argument checking) side, not in univalue itself
2682016-06-08T13:44:04 <GitHub34> [bitcoin] jonasschnelli opened pull request #8171: [RPC] Fix createrawtx sequence number unsigned int parsing (master...2016/06/fix_crt) https://github.com/bitcoin/bitcoin/pull/8171
2692016-06-08T13:44:34 <GitHub123> [bitcoin] sipa pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/6a034ed89891...66ed450d771a
2702016-06-08T13:44:35 <GitHub123> bitcoin/master d3df40e Luke Dashjr: Implement BIP 9 GBT changes...
2712016-06-08T13:44:35 <GitHub123> bitcoin/master 72cd6b2 Luke Dashjr: qa/rpc-tests: bip9-softforks: Add tests for getblocktemplate versionbits updates
2722016-06-08T13:44:36 <GitHub123> bitcoin/master 9879060 Luke Dashjr: getblocktemplate: Explicitly handle the distinction between GBT-affecting softforks vs not
2732016-06-08T13:44:39 <GitHub100> [bitcoin] sipa closed pull request #7935: Versionbits: GBT support (master...gbt_bip9) https://github.com/bitcoin/bitcoin/pull/7935
2742016-06-08T13:45:06 *** Chris_Stewart_5 has quit IRC
2752016-06-08T13:45:54 <GitHub68> [bitcoin] sipa opened pull request #8172: Fix two warnings for comparison between signed and unsigned (master...fixunsigned) https://github.com/bitcoin/bitcoin/pull/8172
2762016-06-08T13:47:52 *** Giszmo has joined #bitcoin-core-dev
2772016-06-08T13:48:49 *** jannes has quit IRC
2782016-06-08T13:52:51 <GitHub73> [bitcoin] laanwj opened pull request #8173: test: Add more test vectors for siphash (master...2016_06_siphash_testing) https://github.com/bitcoin/bitcoin/pull/8173
2792016-06-08T13:54:41 *** achow101 has joined #bitcoin-core-dev
2802016-06-08T13:55:20 <GitHub7> [bitcoin] sipa closed pull request #8086: Use SipHash for node eviction (master...moresiphash) https://github.com/bitcoin/bitcoin/pull/8086
2812016-06-08T14:02:08 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2822016-06-08T14:04:58 *** kadoban has joined #bitcoin-core-dev
2832016-06-08T14:18:42 *** Chris_Stewart_5 has quit IRC
2842016-06-08T14:25:38 *** _anthony_ has joined #bitcoin-core-dev
2852016-06-08T14:26:20 <_anthony_> woohoo it's like I've built a time machine
2862016-06-08T14:26:25 <_anthony_> hello all
2872016-06-08T14:28:19 <_anthony_> BtcDrak said that I can be a core dev
2882016-06-08T14:28:21 <sipa> hello
2892016-06-08T14:28:26 <_anthony_> hi sipa
2902016-06-08T14:33:55 <achow101> _anthony_: anyone can be a "core dev". You just need to submit PRs to Bitcoin Core
2912016-06-08T14:34:17 <instagibbs> please don't forget review of PRs
2922016-06-08T14:34:20 <_anthony_> OK. What PRs do you want me to work on?
2932016-06-08T14:34:45 <_anthony_> Is there any internals documentation that needs to be worked on?
2942016-06-08T14:36:43 <wumpus> generally all PRs and issues that are open are fair game, of course reviewing segwit or compact blocks etc may be the most urgent
2952016-06-08T14:37:20 <instagibbs> when is freeze for 0.13
2962016-06-08T14:37:53 <wumpus> segwit: https://github.com/bitcoin/bitcoin/pull/8149 compact blocks: https://github.com/bitcoin/bitcoin/pull/8068
2972016-06-08T14:38:04 <wumpus> instagibbs: feature freeze is june 16
2982016-06-08T14:38:27 <wumpus> release schedule for 0.13.0: https://github.com/bitcoin/bitcoin/issues/7679
2992016-06-08T14:38:40 <instagibbs> I'll try and make time to review CB soon
3002016-06-08T14:39:19 *** fengling has quit IRC
3012016-06-08T14:39:21 <_anthony_> hmm I definitely need to get more familiar with the way the code is layed out...maybe while reviewing segwit I can do that
3022016-06-08T14:39:45 <btcdrak> welcome _anthony_
3032016-06-08T14:40:06 <instagibbs> _anthony_, that's a bear of a first PR to review :)
3042016-06-08T14:40:10 <_anthony_> thanks btcdrak
3052016-06-08T14:40:17 <sipa> _anthony_: usually the best way to learn a codebase is by contributing yourself... find relatively simple improvements, and try to fix them
3062016-06-08T14:40:41 <sipa> _anthony_: reviewing changes to a codebase that you're not familiar with is not so effective i think
3072016-06-08T14:40:48 <_anthony_> I went through some of the open issues yesterday...it looks like some of them should be closed
3082016-06-08T14:41:08 <instagibbs> Writing tests can be good practice too.
3092016-06-08T14:41:10 <wumpus> _anthony_: that can certainly happen, feel free to let us know if that is the case
3102016-06-08T14:41:31 <_anthony_> k I'll keep a list next time I come across one
3112016-06-08T14:41:41 <wumpus> sometimes an issue is fixed but forgotten about, I tend to go over the full list at least monthly but some things slip through
3122016-06-08T14:54:38 *** ozanyurt_ has joined #bitcoin-core-dev
3132016-06-08T14:57:54 *** ozanyurt has quit IRC
3142016-06-08T15:02:34 *** blur3d has quit IRC
3152016-06-08T15:39:27 *** laurentmt has joined #bitcoin-core-dev
3162016-06-08T15:40:03 *** laurentmt has quit IRC
3172016-06-08T15:42:36 <GitHub12> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/66ed450d771a...cd0c5135ab22
3182016-06-08T15:42:36 <GitHub12> bitcoin/master 2d83013 Jonas Schnelli: Add support for dnsseeds with option to filter by servicebits
3192016-06-08T15:42:37 <GitHub12> bitcoin/master cd0c513 Pieter Wuille: Merge #8083: Add support for dnsseeds with option to filter by servicebits...
3202016-06-08T15:42:46 <GitHub53> [bitcoin] sipa closed pull request #8083: Add support for dnsseeds with option to filter by servicebits (master...2016/05/dnsfilter) https://github.com/bitcoin/bitcoin/pull/8083
3212016-06-08T15:44:22 <cfields_> jonasschnelli: great work on ^^
3222016-06-08T15:44:35 <sipa> petertodd, luke-jr: subtle ping to update your dns seeds to support service bits filtering
3232016-06-08T15:46:23 <jonasschnelli> cfields_: the bitcoin part was easy, the part on the bitcoin-seeder was more complex. :)
3242016-06-08T15:46:33 <jonasschnelli> Also code i'm not use to play around with.
3252016-06-08T15:47:11 <jonasschnelli> But as always, sipa made the important last changes/fixes. :)
3262016-06-08T15:47:16 <cfields_> jonasschnelli: yea, i took a quick look. steep learning curve there
3272016-06-08T15:50:26 <sipa> i wrote it in a week while i was ill
3282016-06-08T15:50:43 <sipa> certainly not the best code i've written :)
3292016-06-08T15:53:34 <cfields_> heh, well it's apparently pretty bullet-proof. can't argue with that :)
3302016-06-08T16:08:24 <cfields_> ok, I was trying to avoid this because i know everyone's busy with a dozen other things, but I'll be away for a while after Friday, and I'm hoping to get as much net refactor stuff as possible knocked out first...
3312016-06-08T16:08:34 <cfields_> so... review begs for #8128 and #8085
3322016-06-08T16:09:34 *** aj has quit IRC
3332016-06-08T16:09:43 <cfields_> (and taking requests for anything I should prioritize before leaving)
3342016-06-08T16:10:25 *** aj has joined #bitcoin-core-dev
3352016-06-08T16:25:35 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3362016-06-08T16:33:00 <GitHub88> [bitcoin] sipa pushed 6 new commits to master: https://github.com/bitcoin/bitcoin/compare/cd0c5135ab22...4286f4302514
3372016-06-08T16:33:01 <GitHub88> bitcoin/master 053930f Patrick Strateman: Avoid recalculating vchKeyedNetGroup in eviction logic....
3382016-06-08T16:33:02 <GitHub88> bitcoin/master 9bf156b Pieter Wuille: Support SipHash with arbitrary byte writes
3392016-06-08T16:33:03 <GitHub88> bitcoin/master c31b24f Pieter Wuille: Use 64-bit SipHash of netgroups in eviction
3402016-06-08T16:33:07 <GitHub140> [bitcoin] sipa closed pull request #8173: Use SipHash for node eviction (cont'd) (master...2016_06_siphash_testing) https://github.com/bitcoin/bitcoin/pull/8173
3412016-06-08T16:54:48 <jonasschnelli> Is there a way within CWallet / CWalletTx to detect which of the tx.vout's is the change output if the wtx is a spend-to-myself?
3422016-06-08T16:55:01 <jonasschnelli> AddressBook lookup?
3432016-06-08T16:55:33 *** Chris_Stewart_5 has quit IRC
3442016-06-08T16:57:02 <luke-jr> yes
3452016-06-08T16:57:33 <jonasschnelli> So I need to solve the pubkey and check if its P2PKH (or different), get the CKeyID and do an addressbook lookup...
3462016-06-08T16:57:40 <jonasschnelli> hmm... not good. :)
3472016-06-08T16:58:20 <jonasschnelli> s/solve the pubkey/use the solver on the scriptPubKey to retrieve the address
3482016-06-08T16:58:52 <sipa> jonasschnelli: no, you convert to a CTxDestination and then check whether that's in the address book
3492016-06-08T16:59:18 <jonasschnelli> sipa: with ExtractDestination()?
3502016-06-08T16:59:26 <sipa> yes
3512016-06-08T16:59:46 <jonasschnelli> Okay.. that sounds feasible.
3522016-06-08T17:02:40 <cfields_> sipa: wrt #7749, do we want to maybe filter the addresses we send in response to getaddr based on the current connection's common services? or maybe prioritize those somehow?
3532016-06-08T17:07:15 *** jarret has joined #bitcoin-core-dev
3542016-06-08T17:08:13 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3552016-06-08T17:10:40 *** ozanyurt_ has quit IRC
3562016-06-08T17:13:49 <jl2012> is it possible to use signrawtransaction to sign a multisig tx with flags other than SIGHASH_ALL?
3572016-06-08T17:15:07 <gmaxwell> Yes.
3582016-06-08T17:15:18 <gmaxwell> it takes an argument to set the flags it will sign with.
3592016-06-08T17:20:22 *** Squidicuz has joined #bitcoin-core-dev
3602016-06-08T17:22:22 <NicolasDorier> sipa: long story short bytespersigop enforced in AcceptToMempool broke some use case on upper layer (https://github.com/bitcoin/bitcoin/issues/8079) we have a simple way to fix it, but it would require to count signatures for a transaction a second time accuratly. Do you think it would be a problem performance wise ? I don't think so but maybe I am missing
3612016-06-08T17:22:22 <NicolasDorier> something.
3622016-06-08T17:24:31 <jl2012> gmaxwell: the sighash flag is the 4th argument. 1st argument is the unsigned tx. However, when I use [] [] as the 2nd and 3rd arguments, it fails to sign
3632016-06-08T17:25:23 <jl2012> without any optional arguments, it signs normally
3642016-06-08T17:25:58 <jl2012> btw i'm signing a P2SH-P2WSH
3652016-06-08T17:45:48 <NicolasDorier> oh whatever, I'm pretty sure it can't be a perf problem, as the second count is done only on a very specific case. nevermind
3662016-06-08T17:46:42 <sipa> NicolasDorier: i don't understand the solution you suggest
3672016-06-08T17:47:49 <NicolasDorier> sipa: Well basically bytespersig use GetLegacySigCount which overshoot multisig real signature count. Because of that, it broke an upper layer protocol (counteryparty)
3682016-06-08T17:47:52 <NicolasDorier> the solution
3692016-06-08T17:48:37 <NicolasDorier> would be "if(nSigOps > MAX_STANDARD_TX_SIGOPS)", then you count signature again accurately, and use such count for calculating if bytespersigop is reached or not
3702016-06-08T17:48:44 <sipa> heh, does counterparty still e ist
3712016-06-08T17:48:53 <sipa> i see
3722016-06-08T17:48:56 <sipa> that would work
3732016-06-08T17:49:00 <NicolasDorier> well, I'm not using it, but yeah it seems very much alive
3742016-06-08T17:49:08 <sipa> :(
3752016-06-08T17:49:14 <sipa> anyway, sounds like a good solution
3762016-06-08T17:49:20 <NicolasDorier> ok cool
3772016-06-08T17:53:07 <rubensayshi> counterparty uses it as fallback when > 80 bytes, which is 0.0x% or something
3782016-06-08T17:56:15 <gmaxwell> People involved with counterparty have told me they intend for counterparty to replace the bitcoin currency because the distribution of bitcoins is "unfair" and counterparty is "more equitable"-- I don't think it's accurate to describe it as an "upper layer" system, it's a system that explicitly is in competition with the bitcoin currency.
3792016-06-08T18:02:12 <sipa> NicolasDorier: your solution does not work, because it reintroduces the problem that the original PR was intended to fix
3802016-06-08T18:02:53 <sipa> NicolasDorier: the consensus rules count those as 20 sigops; if for mining purposes do not count it as 20, the attack reappears
3812016-06-08T18:04:07 <sdaftuar> sipa: doesn't the code as merged still allow for an attack, as you could fill up 400kb of block space with 20k sigops?
3822016-06-08T18:04:51 <sipa> sdaftuar: hmm?
3832016-06-08T18:05:18 <sipa> 20k sigops should be counted as 1 MB, no?
3842016-06-08T18:05:37 <sdaftuar> sorry i think i phrased poorly. at 20bytes/sigop, you could hit the 20k sigops limit with only 400kb of transactions
3852016-06-08T18:05:51 <sipa> it should be 50 bytes/sigop
3862016-06-08T18:05:53 <sdaftuar> yes
3872016-06-08T18:06:03 <sdaftuar> unless there are valid use cases which we'd preclude, that is?
3882016-06-08T18:06:17 <sdaftuar> but regardless we should have had this discussion when that PR was merged. i have no idea where 20 comes from
3892016-06-08T18:06:34 <sdaftuar> or what the valid use cases are...
3902016-06-08T18:06:43 <sipa> i think i assumed that number was the correct translation factor when it was merged
3912016-06-08T18:07:29 <sipa> but dropping transactions that go over the limit is wrong, i think
3922016-06-08T18:07:30 *** Squidicuz has quit IRC
3932016-06-08T18:07:44 *** Squidicuz has joined #bitcoin-core-dev
3942016-06-08T18:07:54 <sipa> we should just count them as if they were the correspondig size
3952016-06-08T18:07:58 *** Squidicc has joined #bitcoin-core-dev
3962016-06-08T18:08:08 <sdaftuar> you mean for feerate purposes?
3972016-06-08T18:10:35 <gmaxwell> thats what I argued for forever but there was some reason people didn't like it... convert each limit to a feerate, and take the worst... under the approximation that whatever is worst will be the limiting factor.
3982016-06-08T18:10:58 <sdaftuar> that approximation doesn't hold in CreateNewBlock, most of the time, i'd think
3992016-06-08T18:11:14 <sdaftuar> most of the time you're nowhere near the sigops limit
4002016-06-08T18:11:24 <gmaxwell> it doesn't, but the size is the worst most of the time, so it doesn't matter except for excpetional transactions.
4012016-06-08T18:11:30 <sipa> yes, this is the nonlinear optimization problem again
4022016-06-08T18:11:44 <paveljanik> sipa, thanks for fixing the warnings!
4032016-06-08T18:11:54 <sipa> but if you use the same count for mining and for relay/priority, there is no problem i think
4042016-06-08T18:12:37 <sipa> at least you wouldn't lose money over it as a miner
4052016-06-08T18:12:48 <sdaftuar> well miners woulnd't be doing the optimal thing?
4062016-06-08T18:13:39 <helo> they'll intend to do the optimal thing, at least
4072016-06-08T18:13:54 *** bsm1175321 has quit IRC
4082016-06-08T18:15:12 <sipa> sdaftuar: right, suboptimal, but not susceptible to losing a majority of yiur available block space
4092016-06-08T18:16:37 <gmaxwell> Suboptimal though only in the presence of transactions whos sigops cost would dominate their size cost.
4102016-06-08T18:16:42 <sdaftuar> yeah maybe that's good enough, and better than the status quo
4112016-06-08T18:19:06 <gmaxwell> It's my belief (and hope) that the other limits are set so high that they should never come into effect in practice.
4122016-06-08T18:19:25 <gmaxwell> (though this isn't true if people use bare multisig, but they mostly don't)
4132016-06-08T18:20:56 <sipa> the fact that this problem only got detected so many months after 0.12 shows that probably not many people use bare multisig...
4142016-06-08T18:23:10 <GitHub47> [bitcoin] laanwj opened pull request #8175: gitian: Add --disable-bench to config flags for windows (master...2016_06_disable_bench_windows) https://github.com/bitcoin/bitcoin/pull/8175
4152016-06-08T18:31:35 <rubensayshi> offtopic; gmaxwell, I've never heard any1 say counterparty competes with bitcoin, it's focus is tokens (and soon EVM), it would be insane to think it could compete with bitcoin (considering the reduced efficiency)
4162016-06-08T18:32:21 <rubensayshi> sipa, I wouldn't find it odd if you guys would decide to block bare multisig from isstandard, but this check wasn't intended that way and the result did
4172016-06-08T18:32:53 <rubensayshi> though there might be people still using it, and I don't see it being isstandard as such a big problem
4182016-06-08T18:33:29 <sipa> rubensayshi: agree, i think there are good reasons to make it nonstandard, but it should happen intentionally and after communication, not as an unintended side effect
4192016-06-08T18:34:24 <rubensayshi> the consensus rules count bare multisig as 20 sigops, and considering it's part of consensus should continue to do so
4202016-06-08T18:34:44 <rubensayshi> I guess the reason why we don't properly count the sigops to begin with is because it's been part of consensus since day 1
4212016-06-08T18:35:17 <gmaxwell> it wasn't a part of consensus since day 1, </pedantic>
4222016-06-08T18:35:27 <rubensayshi> oh?
4232016-06-08T18:36:50 <sipa> i assume it was introeuced somewhere in 2010
4242016-06-08T18:37:34 <sipa> whether they were part of the consensus rules on day 1 is also irrelevant; what matters if they are part of consensus now :)
4252016-06-08T18:39:53 <rubensayshi> ok, but changing the `bytespersigop` check in AcceptToMempool to use `fAccurate=True` shouldn't be a problem right?
4262016-06-08T18:40:24 <gmaxwell> that would defeat the fix against the bloat attack.
4272016-06-08T18:40:33 <gmaxwell> The counting has to work exactly as the consensus rule does.
4282016-06-08T18:42:57 *** MarcoFalke has left #bitcoin-core-dev
4292016-06-08T18:45:30 <rubensayshi> hmm, the consensus prevents a block being larger than 1mb or 20k sigops, so you don't want to accept any txs that would tip over the balance to reaching the 20k sigops before you'd reach 1mb?
4302016-06-08T18:46:03 <rubensayshi> as in; to optimize fees?
4312016-06-08T18:46:38 <gmaxwell> rubensayshi: thats right.. there was some attacker a while back flooding the network with transactions that used huge amounts of sigops, which would cause miners to needlessly produce small blocks.
4322016-06-08T18:47:05 <gmaxwell> there are multiple ways to address that.
4332016-06-08T18:47:11 <rubensayshi> ok so I guess I get sipa's point, because we rely on fee/size and not on sigops/size when that's higher
4342016-06-08T18:48:53 *** adiabat has joined #bitcoin-core-dev
4352016-06-08T18:57:18 <rubensayshi> so there's no way to bring back bare multisig other than miners choosing to run with a lower `bytespersigop` (but you just said the default should be 50, not the current 20 to begin with) or changing the consensus rule where bare multisig is counted as 20 sigops?
4362016-06-08T18:57:29 *** Chris_Stewart_5 has quit IRC
4372016-06-08T18:58:23 <gmaxwell> the broken counting was a softfork added in sept 2010, in ~0.3.12.
4382016-06-08T18:59:54 <rubensayshi> so the only valid option would be to improve selecting TXs for blocks in a way that it won't use TXs with high sigops/bytes if it would result in not having a full block so that the check doesn't have to be in the mempool policy
4392016-06-08T19:00:04 <rubensayshi> which is ...
4402016-06-08T19:00:16 <rubensayshi> way to much complexity and too big of a task
4412016-06-08T19:02:29 *** molz has joined #bitcoin-core-dev
4422016-06-08T19:04:22 <gmaxwell> 20 is more permissive than 50, fwiw.
4432016-06-08T19:04:28 *** moli has quit IRC
4442016-06-08T19:04:51 <gmaxwell> there was a discussion on IRC about setting it, and 20 seemsed to be the lowest that it could be set without outright enabling that attack.
4452016-06-08T19:05:46 <sdaftuar> gmaxwell: pointer to the IRC conversation? i looked and never found any discussion
4462016-06-08T19:05:57 <gmaxwell> rubensayshi: right, and generally we consider bare multisig undesirable for unrelated reasons too, and there is longstanding discussion toward moving to make it non-standard... so doesn't really justify a bunch of complexity to try to work around it.
4472016-06-08T19:06:15 <rubensayshi> I guess it should just be made non standard then
4482016-06-08T19:06:28 <rubensayshi> which it essentially is now
4492016-06-08T19:07:28 <rubensayshi> how about some extra bytes for opreturn then :P ?
4502016-06-08T19:09:32 *** moli has joined #bitcoin-core-dev
4512016-06-08T19:10:19 <gmaxwell> sdaftuar: turns out searching for the number 20 is really hard.
4522016-06-08T19:10:39 <btcdrak> maybe sigop?
4532016-06-08T19:11:32 <btcdrak> gmaxwell: how about this? https://botbot.me/freenode/bitcoin-core-dev/2015-10-22/?msg=52464204&page=1
4542016-06-08T19:12:00 *** molz has quit IRC
4552016-06-08T19:12:26 *** TomMc has joined #bitcoin-core-dev
4562016-06-08T19:13:15 <btcdrak> another conversation starts here https://botbot.me/freenode/bitcoin-core-dev/2015-11-04/?msg=53446658&page=2
4572016-06-08T19:13:44 *** Chris_Stewart_5 has joined #bitcoin-core-dev
4582016-06-08T19:14:08 <luke-jr> regardless of what we do to fix bytespersigop, I think we should disable bare multisig by default; with that in mind, *which* solution we go with seems less important
4592016-06-08T19:15:23 <luke-jr> (but IMO the better fix is to simply count CHECKMULTISIG correctly for this purpose, since the goal is spam prevention, and higher fees don't matter in that case)
4602016-06-08T19:15:57 <GitHub83> [bitcoin] luke-jr opened pull request #8176: [0.12.x]: Versionbits: GBT support (0.12...gbt_bip9-0.12.x) https://github.com/bitcoin/bitcoin/pull/8176
4612016-06-08T19:17:06 <luke-jr> rubensayshi: what happened to OP_RETURN counterparty?
4622016-06-08T19:17:14 <gmaxwell> it isn't about charging more fees, the whole attack was causing miners to produce needlessly small blocks because they thought sigopbloat txn were more attractive to produce than they were.
4632016-06-08T19:17:39 <gmaxwell> if an attacker had to pay as much to 'fill' a block that way as they would with ordinary transactions, then it's no longer an interesting attack vector.
4642016-06-08T19:17:43 <rubensayshi> luke-jr, literally 99.988% of CP txs are opreturn
4652016-06-08T19:18:07 <btcdrak> luke-jr: they use OP_RETURN for messages < 80 bytes which is most of them.
4662016-06-08T19:18:11 <luke-jr> rubensayshi: why not 100%?
4672016-06-08T19:18:47 <luke-jr> rubensayshi: is there a good way we could teach Core to identify CP OP_RETURN separate from spam OP_RETURN, so we can allow longer lengths for CP only?
4682016-06-08T19:19:12 <rubensayshi> is there a reason not to change isstandard to allow opreturn with more data?
4692016-06-08T19:19:17 *** ozanyurt has joined #bitcoin-core-dev
4702016-06-08T19:19:27 <rubensayshi> they dont polute utxo set and are prunable
4712016-06-08T19:19:31 <rubensayshi> and fee is paid for them
4722016-06-08T19:19:47 <gmaxwell> rubensayshi: Bitcoin is a currency not a public shared database.
4732016-06-08T19:19:55 <sipa> you're storing data on my disk, without benefitting me or the bitcoin ecosystem
4742016-06-08T19:20:19 *** grubles_ has joined #bitcoin-core-dev
4752016-06-08T19:20:27 <btcdrak> gmaxwell: what concerns me is if systems resort to bloating the UTXO with unspendable transactions as a way to encode >80 bytes.
4762016-06-08T19:20:44 <gmaxwell> btcdrak: they're not unspendable AFAIK.
4772016-06-08T19:20:47 <luke-jr> btcdrak: it seems they currently use spendable CHECKMULTISIGs
4782016-06-08T19:20:50 *** ozanyurt_ has joined #bitcoin-core-dev
4792016-06-08T19:20:55 <rubensayshi> the bare multisig are spendable btw
4802016-06-08T19:20:58 <luke-jr> 1-of-2 with the 2nd key up to 500 or so bytes
4812016-06-08T19:21:07 <gmaxwell> though if they were we should simply filter them out generally.
4822016-06-08T19:21:07 <rubensayshi> that's the reason to use bare multisig, they're 1-of-3 and the 3rd key is a real key
4832016-06-08T19:21:34 <rubensayshi> the last resort is pubkeyhash encoding ...
4842016-06-08T19:21:47 <luke-jr> we could probably enforce a pubkey format for bare multisig even when they're enabled, but nobody afaik is legitimately using it, so might as well just disable it by default
4852016-06-08T19:22:05 <btcdrak> gmaxwell: pubkeyhash encoding is unspendable afaik
4862016-06-08T19:22:22 <luke-jr> pubkeyhash encoding can't do >80 bytes anyway?
4872016-06-08T19:22:27 <rubensayshi> yea
4882016-06-08T19:22:31 <rubensayshi> 100s of outputs ...
4892016-06-08T19:22:33 <luke-jr> -.-
4902016-06-08T19:22:35 <rubensayshi> all unspendable
4912016-06-08T19:22:55 <luke-jr> sigh, maybe we really do need p2sh^2 sooner rather than later
4922016-06-08T19:23:05 <rubensayshi> the bare multisig was perfect tbh, because we could clean the outputs
4932016-06-08T19:23:17 <btcdrak> it really is about the lesser of the evils. I would say a slightly larger OP_RETURN is preferable than unspendable junk
4942016-06-08T19:23:24 <rubensayshi> as a fallback to opreturn that is
4952016-06-08T19:23:29 <luke-jr> [19:18:46] <luke-jr> rubensayshi: is there a good way we could teach Core to identify CP OP_RETURN separate from spam OP_RETURN, so we can allow longer lengths for CP only?
4962016-06-08T19:23:30 <gmaxwell> rubensayshi: you should have your own network, and stop storing data unrelated to bitcoin in the bitcoin network.
4972016-06-08T19:23:47 *** ozanyurt has quit IRC
4982016-06-08T19:23:48 <gmaxwell> The OP_RETURN as standard facility was intended to store _commitments_ not data.
4992016-06-08T19:23:58 <rubensayshi> luke-jr, is there a way you won't change that to drop all of them the next release xD?
5002016-06-08T19:24:23 <rubensayshi> gmaxwell, I'm just a script kiddie who dropped by a project that needed some work and sounded fun to do
5012016-06-08T19:24:37 <rubensayshi> I didn't come up with this stuff xD
5022016-06-08T19:24:39 <gmaxwell> rubensayshi: :)
5032016-06-08T19:24:43 <btcdrak> :D
5042016-06-08T19:24:43 <rubensayshi> I just get the bug reports
5052016-06-08T19:24:46 <gmaxwell> rubensayshi: but you could help rescue it. :)
5062016-06-08T19:24:53 <gmaxwell> Dare to dream.
5072016-06-08T19:25:01 <btcdrak> sidechains...
5082016-06-08T19:25:21 <rubensayshi> hehe
5092016-06-08T19:25:40 <gmaxwell> it's not even a 'sidechain'-- it's a seperate currency/asset tracking network. :)
5102016-06-08T19:25:45 *** mkarrer has joined #bitcoin-core-dev
5112016-06-08T19:25:53 <luke-jr> rubensayshi: believe it or not, the 0.12 thing was an accident in affecting CP
5122016-06-08T19:26:21 <gmaxwell> indeed, that wasn't intended. if we had intended to block CP then it would be blocked completely.
5132016-06-08T19:26:25 <rubensayshi> I gave you the benefit of doubt luke-jr, but not having any tests for it makes it look funky (I'll write some tests 2morrow for it!)
5142016-06-08T19:26:41 <adiabat> is there a recommended / reliable way to put this data in the witness stack?
5152016-06-08T19:26:56 <adiabat> it'd be nicer to have it there instead of in an OP_RETURN
5162016-06-08T19:26:57 <rubensayshi> would that be better?
5172016-06-08T19:27:17 <luke-jr> adiabat: it's probably better in OP_RETURN tbh
5182016-06-08T19:27:21 <gmaxwell> adiabat: it's not under a signature there, so it can be stripped in relay, unfortunately.
5192016-06-08T19:27:28 <adiabat> yeah...
5202016-06-08T19:27:36 <gmaxwell> There is no good place to store arbritary data, unfortunately.
5212016-06-08T19:27:48 <adiabat> you'd have to put like a hash of it in the output script, then put your 520 byte preimage in the witness
5222016-06-08T19:27:50 <rubensayshi> op_drop?
5232016-06-08T19:27:55 <luke-jr> gmaxwell: Factom! :P
5242016-06-08T19:27:58 *** Chris_Stewart_5 has quit IRC
5252016-06-08T19:27:58 <adiabat> heh
5262016-06-08T19:28:05 <gmaxwell> except via a _commitment_ in op_return and the data elsewhere, which was already whas op_return as standard was supposted to be.
5272016-06-08T19:28:08 <adiabat> op_2drop is even more efficient :)
5282016-06-08T19:28:41 <rubensayshi> if all my addresses would be P2SH I could put it in the scriptSig with an op_drop no?
5292016-06-08T19:28:43 *** grubles_ is now known as grubles
5302016-06-08T19:28:53 <gmaxwell> The problem with op_return is that the data still ends up in prued-nowit-sync and in SPV scans. The problem with putting it in the witness is that it's not signed.
5312016-06-08T19:29:08 <gmaxwell> rubensayshi: sure you can, but any joker can strip it out of the transactions as they go past.
5322016-06-08T19:29:09 <adiabat> at some point someone should make like a p2pool backed merkle-branch-service
5332016-06-08T19:29:23 <rubensayshi> ah right
5342016-06-08T19:30:05 <adiabat> ~most of the data on the segnet4 blockchain is op_2drop witness items
5352016-06-08T19:30:12 <adiabat> nobody modified any of them :)
5362016-06-08T19:30:58 <gmaxwell> I think we should add some 'notes' facility, where people can publish data into a DHT(spit) with access rate limited by ownership of stationary txouts. Then if they want commitments in op-returns great. We'd hoped people would build this for themselves, but building complex infrastructure isn't something many people do when there is a speculative asset they could be pumping instead.
5372016-06-08T19:31:15 <gmaxwell> adiabat: thats been done, it was called chronobit.
5382016-06-08T19:31:37 <gmaxwell> adiabat: yea, sure lots of things work for a while. :)
5392016-06-08T19:31:43 <adiabat> huh! look at that. and people use op_return instead...
5402016-06-08T19:31:48 <luke-jr> gmaxwell: the hard part there is proving ownership
5412016-06-08T19:32:13 <gmaxwell> luke-jr: you just write a non-minable transaction to perform your insert.
5422016-06-08T19:32:28 <luke-jr> gmaxwell: that involves key reuse :<
5432016-06-08T19:32:41 <gmaxwell> adiabat: utter refusal to use anything except the simplest possible thing. "This is why we can't have nice things".
5442016-06-08T19:32:47 <gmaxwell> luke-jr: so? not in a way that matters.
5452016-06-08T19:33:05 <gmaxwell> Key reuse isn't inherently bad. Reusing in dumb ways is.
5462016-06-08T19:33:34 <gmaxwell> If your alternative was to transact; then signmessaging is stricly superior.
5472016-06-08T19:33:35 *** ozanyurt_ has quit IRC
5482016-06-08T19:33:40 <adiabat> oh, semi-unrelated but, gmaxwell: remember the "bloom filter digest" post about a month ago on the mailing list
5492016-06-08T19:33:42 <luke-jr> there is zero risk of QC ever?
5502016-06-08T19:33:53 <adiabat> and you said, since you're not updating, there's better structures than bloom filters
5512016-06-08T19:34:03 <gmaxwell> luke-jr: it doesn't change anything wrt QC when your alternative was just transacting!
5522016-06-08T19:34:25 <luke-jr> transacting doesn't leave coins on the key ;)
5532016-06-08T19:34:28 <gmaxwell> adiabat: yes.
5542016-06-08T19:34:53 <adiabat> gmaxwell: Do you know if anyone's working on that, or a BIP or anything? It looked like it was from a troll account...
5552016-06-08T19:35:09 <gmaxwell> I don't think anyone is working on it right now.
5562016-06-08T19:35:12 <adiabat> I don't really want to commit to like "I'll work on that" because I might not have time but...
5572016-06-08T19:35:27 <adiabat> it seems so much nicer than the current merkle block stuff
5582016-06-08T19:35:37 <gmaxwell> adiabat: well would be good for you to, and if other people show up I can point them at you.
5592016-06-08T19:35:47 *** ozanyurt has joined #bitcoin-core-dev
5602016-06-08T19:35:49 <luke-jr> a better way IMO would be to use sign-to-contract to commit to another key, and use that key to sign the DHT publication
5612016-06-08T19:35:59 <gmaxwell> TBH, I'm a bit afraid to work on technology that I really like right now, because it'll just get attacked because I like it. :(
5622016-06-08T19:36:27 <AaronvanW> "Do you guys know what the the latest up to date spec for stealth addresses is?" (asking for someone... who is asking for me.)
5632016-06-08T19:36:31 <gmaxwell> luke-jr: but then access to publish is people who don't have bitcoins anymore which would be kinda odd. :)
5642016-06-08T19:36:41 <adiabat> gmaxwell: heh yeah... do you have any links to the more efficient filters, like the binomial codec you linked to?
5652016-06-08T19:37:04 <luke-jr> gmaxwell: contracthash then? :P
5662016-06-08T19:37:53 *** grubles is now known as dingus
5672016-06-08T19:38:06 <gmaxwell> adiabat: well the more efficient filter is just like a bloom but with a single hash function and large number of candidate positions, and then you compress the result, using your choice of optimal compressor for cases where the probablity of a 1 is very low
5682016-06-08T19:38:18 <gmaxwell> luke-jr: doesn't achieve your goal.
5692016-06-08T19:38:34 <luke-jr> hm
5702016-06-08T19:39:17 <gmaxwell> I wish I never pointed out that the use of hashed keys might harden a little against QC, it's vastly overestimated in performance. If we think that is at all a threat we need to be urgently migrating to secure schemes.
5712016-06-08T19:39:21 <luke-jr> MAST with a branch for payment vs message vs DHT-message :P
5722016-06-08T19:40:13 <gmaxwell> adiabat: So, for example, a simple range coder would work. rice coding might be reasonably efficient, or things like the binomial codec I linked to.
5732016-06-08T19:40:29 <gmaxwell> luke-jr: cute.
5742016-06-08T19:40:33 <adiabat> gmaxwell: so maybe start with the current murmur hash, and look at different compression encodings?
5752016-06-08T19:40:35 <luke-jr> gmaxwell: I consider it a useful property in that it doesn't cause QCs to take all old coins not being spent immediately. It does that, at least, no?
5762016-06-08T19:40:58 <gmaxwell> adiabat: or siphash 1-3. Yes, thats possible.
5772016-06-08T19:41:46 <gmaxwell> adiabat: another newly trendy kind of data structure for this is a cuckoo filter, though for ideal use here you'd also need to compress it, though the compression could be simpler.
5782016-06-08T19:42:05 <gmaxwell> it might work better simply because it will be smaller in memory when matching.
5792016-06-08T19:42:10 *** Chris_Stewart_5 has joined #bitcoin-core-dev
5802016-06-08T19:42:18 <adiabat> gmaxwell: OK thanks, will look into it. Probably can't work on it much, but it doesn't *feel* that hard... in fact feels simpler than the current merkle-blocks and then send txs stuff
5812016-06-08T19:42:45 <gmaxwell> Yes, it's simpler. I think fully elaborated out you could go very deep down a rabbit hole, but the basic idea is simple.
5822016-06-08T19:43:32 <adiabat> gmaxwell: the main design tradeoff seems to be the size of the block digest. Too small and lots of false positives and people have to download lots of blocks. Too big and you're spending a lot of space on the digest.
5832016-06-08T19:43:36 <gmaxwell> A cool thing about it is that it could be used before being commited, so people could try many different designs and explore the solution space pretty far.
5842016-06-08T19:44:05 <adiabat> yeah, could implement it on the p2p layer without any consensus changes
5852016-06-08T19:44:22 <gmaxwell> well you can also do things like multiple tiers, like a digest covering groups of 8 blocks, and a digest covering single blocks.. even digests covering parts of blocks.
5862016-06-08T19:44:23 <adiabat> and the node could lie to you, but they can do that right now with bloom filters anyway
5872016-06-08T19:45:18 <adiabat> also feels like maybe a perverse incentive would be that you'd not want to make as many new addresses, as your false positive rate would go up and you'd have to download more...
5882016-06-08T19:45:50 <gmaxwell> the current system has that issue, these commited schemes have less of it.
5892016-06-08T19:46:18 <adiabat> yeah, basically nothing about it seems any *worse* than the current filter system
5902016-06-08T19:47:05 <gmaxwell> There are other totally different alternatives though, like PIR scan services, which I think we almost have enough in bitcoin core to support as a purely external add on.
5912016-06-08T19:48:01 <adiabat> PIR scans would be better but also seems more complex...
5922016-06-08T19:48:39 <gmaxwell> much more complex, though a lot of the heavy lifting has been done by other people (percy++)
5932016-06-08T19:48:46 <adiabat> not that people shouldn't do it, but I feel like I could reasonably get a block digest to work, but getting a PIR system seems more .. innovative :)
5942016-06-08T19:49:06 <gmaxwell> hah
5952016-06-08T19:49:19 <gmaxwell> I only bring it up in the hope that someone will be foolish enough to think it easy.
5962016-06-08T19:49:48 <gmaxwell> Though actually I think they're more similar in difficulty than you think... in both cases the details are what get you.
5972016-06-08T19:50:20 <adiabat> yeah, I guess with the digest, you can get something working even if the details are wrong and it works sub-optimally
5982016-06-08T19:50:43 <adiabat> with PIR, well... I guess you wouldn't really know if it was horribly broken and revealed everything that you were requesting
5992016-06-08T19:51:51 <gmaxwell> PIR is straight forward: there is existing software that lets you have a {key, value} database and query it privately. Take the existing utxo set, order by address, for every txout for each address, generate a txout proof (gettxoutproof rpc), for it. ... now thats your database. People query it with each of there addresses, and import the results into the wallet after verifying the proofs. Tad
6002016-06-08T19:51:57 <gmaxwell> a.
6012016-06-08T19:52:19 <gmaxwell> The reality is less simple, because different addresses have (vastly) different numbers of txouts connected with them.. so you have to have some way of handling it.
6022016-06-08T19:53:09 <gmaxwell> Probably the thing to do is take all the txouts for each address and make the keys key, key_2, key_3, key_4... for each of them. and have the first key tell you how many txouts there are in total.
6032016-06-08T19:53:44 <gmaxwell> Though that still will have some inefficiency since the txoutproof has the whole transaction paying you in it, so they'd all need to be padded up to a constant (large size).
6042016-06-08T19:54:03 <gmaxwell> and maybe the inefficiency of all that makes it unreasonable to use.
6052016-06-08T19:55:06 <adiabat> yeah... also percy++ looks a little scary to work with in that I don't think there's a lot of real world implementations using it right now
6062016-06-08T19:56:25 <adiabat> wheras the block digest idea just jumps out as like "Oh yeah that'll work!"
6072016-06-08T19:56:27 <gmaxwell> Right. Well most people have no desire, "keep user data private? but then how will we sell it?" :) a positive point is that the academics working on it are actually competent programmers too (not always the case)... so I think it's likely to not be a software engineering disaster (and it's always worked right when I've messed around with it)
6082016-06-08T19:56:38 *** cryptapus has quit IRC
6092016-06-08T19:57:10 <adiabat> yeah I looked at percy++ a year or two ago and it does seem to be well made
6102016-06-08T19:57:18 <gmaxwell> adiabat: indeed, it will, though less private! it's also not exclusive with using PIR.. a simpler way to use PIR would be to use it to fetch the whole blocks you're going to fetch.
6112016-06-08T19:58:27 <adiabat> I guess I'm also not just looking at it from a privacy perspective, though that's a big part of it
6122016-06-08T19:58:41 <gmaxwell> ::nods::
6132016-06-08T19:58:46 <adiabat> with LN channels, a false negative can be a big problem
6142016-06-08T19:58:51 <gmaxwell> the existing bloom stuff is just broken on a bunch of levels.
6152016-06-08T19:59:29 <adiabat> yeah, if the node you're asking to filter for you omits the tx where someone closes a channel incorrectly, you might not know and lose coins
6162016-06-08T19:59:41 <gmaxwell> it's vulnerable to attack both from data hiding and from denial of service, its resource intensive, .. strongly discourages single use addresses.. quite non-private...
6172016-06-08T19:59:58 <adiabat> oh and the merkle-block data structure is... weird...
6182016-06-08T20:00:07 <adiabat> and then it sends the txs, unrequested
6192016-06-08T20:00:57 <_anthony_> bitcoin satellites are definitely the way to go
6202016-06-08T20:01:08 <gmaxwell> yea, a side effect of the bitcoin protocol having no mechensim to just fetch txn already in blocks, which has a good reason for it (among other things, it helps keep the network from being abused as a file trading DHT)
6212016-06-08T20:01:39 <gmaxwell> BIP152 actually adds a sutiable mechenism-- getblocktxn that fetches txn in a block by index, that only works for recent blocks.
6222016-06-08T20:05:11 *** molz has joined #bitcoin-core-dev
6232016-06-08T20:07:18 *** moli has quit IRC
6242016-06-08T20:08:12 *** Squidicc has quit IRC
6252016-06-08T20:11:32 <sipa> my train internet connection is too weak to actually visit github.com, but can someone see if https://github.com/sipa/bitcoin/commits/dogcgit renerders nicely?
6262016-06-08T20:15:23 <gmaxwell> sipa: 404.
6272016-06-08T20:15:41 <paveljanik> sipa, yes, looks nice - https://github.com/bitcoin/bitcoin/compare/master...sipa:docgit
6282016-06-08T20:15:58 <gmaxwell> https://github.com/sipa/bitcoin/commits/docgit maybe
6292016-06-08T20:20:29 <sipa> yes indeed; thanks!
6302016-06-08T20:21:46 <GitHub146> [bitcoin] kazcw opened pull request #8177: developer notes: deprecate C-style casts (master...no-c-casts) https://github.com/bitcoin/bitcoin/pull/8177
6312016-06-08T20:35:42 *** moli has joined #bitcoin-core-dev
6322016-06-08T20:38:20 *** molz has quit IRC
6332016-06-08T21:02:45 *** adiabat has quit IRC
6342016-06-08T21:16:25 *** cryptapus has joined #bitcoin-core-dev
6352016-06-08T21:23:15 *** cryptapus has quit IRC
6362016-06-08T21:26:49 *** JackH has quit IRC
6372016-06-08T21:40:38 *** supasonic has joined #bitcoin-core-dev
6382016-06-08T21:42:03 <luke-jr> can someone reopen https://github.com/bitcoin/bitcoin/pull/5872 so I can push to it (addressing unreviewability concerns)?
6392016-06-08T22:31:29 *** xiangfu has joined #bitcoin-core-dev
6402016-06-08T22:32:01 <frankenmint> heh, rusty russel also invented modprobe
6412016-06-08T22:32:20 *** Guyver2 has quit IRC
6422016-06-08T22:32:35 <gmaxwell> Someday we'll forgive him.
6432016-06-08T22:41:28 <luke-jr> XD
6442016-06-08T22:41:31 <sipa> and if not, we'll xkcd538 him with a 5 AUD rusty wrench
6452016-06-08T22:41:45 <luke-jr> sipa: ^ 1 hr ago
6462016-06-08T22:42:34 <GitHub126> [bitcoin] sipa reopened pull request #5872: configure: BITCOIN_SUBDIR_TO_INCLUDE: Improve compatibility with paths including space and multiline cpp output (master...subdir_incl_compat) https://github.com/bitcoin/bitcoin/pull/5872
6472016-06-08T22:42:37 <luke-jr> thx
6482016-06-08T22:44:58 <luke-jr> hopefully that's finally reviewable
6492016-06-08T22:48:30 *** mkarrer has quit IRC
6502016-06-08T22:50:06 *** mkarrer has joined #bitcoin-core-dev
6512016-06-08T22:51:55 <sipa> luke-jr: i'm not sure i understand the problem it os trying to address
6522016-06-08T22:51:59 <sipa> you say it is biggy
6532016-06-08T22:52:04 *** supasonic has quit IRC
6542016-06-08T22:52:08 <sipa> how does that manifest?
6552016-06-08T22:53:57 <luke-jr> sipa: I think mostly paths with spaces failing
6562016-06-08T22:54:24 <sipa> ah
6572016-06-08T23:06:49 <GitHub106> [bitcoin] sipa opened pull request #8178: Add git and github tips and tricks to developer notes (master...docgit) https://github.com/bitcoin/bitcoin/pull/8178
6582016-06-08T23:09:33 *** xiangfu has quit IRC
6592016-06-08T23:16:41 <btcdrak> sipa: more gitfu please
6602016-06-08T23:17:55 *** xiangfu has joined #bitcoin-core-dev