12017-12-14T00:05:31 *** bule has quit IRC
22017-12-14T00:05:56 *** PaulCapestany has joined #bitcoin-core-dev
32017-12-14T00:06:00 *** bule has joined #bitcoin-core-dev
42017-12-14T00:06:07 *** AaronvanW has quit IRC
52017-12-14T00:06:28 *** AaronvanW has joined #bitcoin-core-dev
62017-12-14T00:17:56 *** grondon has quit IRC
72017-12-14T00:26:48 *** tiagotrs has quit IRC
82017-12-14T00:28:41 *** Deacydal has quit IRC
92017-12-14T00:28:49 *** B_ has joined #bitcoin-core-dev
102017-12-14T00:34:39 *** Chris_Stewart_5 has joined #bitcoin-core-dev
112017-12-14T00:36:55 *** Randolf has joined #bitcoin-core-dev
122017-12-14T00:38:39 *** saint_ has joined #bitcoin-core-dev
132017-12-14T00:39:27 *** Aaronvan_ has joined #bitcoin-core-dev
142017-12-14T00:41:41 *** Randolf has quit IRC
152017-12-14T00:42:17 *** Randolf has joined #bitcoin-core-dev
162017-12-14T00:42:49 *** AaronvanW has quit IRC
172017-12-14T00:43:40 *** Cogito_Ergo_Sum has quit IRC
182017-12-14T00:56:25 *** PaulCapestany has quit IRC
192017-12-14T00:56:29 *** jb55 has quit IRC
202017-12-14T01:00:34 *** dermoth has quit IRC
212017-12-14T01:01:12 *** dermoth has joined #bitcoin-core-dev
222017-12-14T01:02:31 *** dabura667 has joined #bitcoin-core-dev
232017-12-14T01:06:03 *** PaulCapestany has joined #bitcoin-core-dev
242017-12-14T01:06:30 *** dermoth has quit IRC
252017-12-14T01:06:55 *** dermoth has joined #bitcoin-core-dev
262017-12-14T01:19:20 *** PaulCapestany has quit IRC
272017-12-14T01:19:51 *** PaulCapestany has joined #bitcoin-core-dev
282017-12-14T01:20:04 *** To7 has joined #bitcoin-core-dev
292017-12-14T01:24:23 *** ghost43 has quit IRC
302017-12-14T01:24:44 *** ghost43 has joined #bitcoin-core-dev
312017-12-14T01:25:46 *** Nobody_ has joined #bitcoin-core-dev
322017-12-14T01:26:23 <Nobody_> Please update Satoshi Nakamoto & The Bitcoin Core Developers that the Blockchain is complete and Copyright Free for this Holiday Season
332017-12-14T01:26:43 <Nobody_> I will not reveil my Identity but things work in wonderful ways
342017-12-14T01:27:13 <promag> nice, ty
352017-12-14T01:27:15 <Nobody_> Here is for those group(s) and anyone who made a Cryptocurrency, never having to worry about it not being protected
362017-12-14T01:27:23 <Nobody_> Blockchain ECDSA Public Key (Bitcoin Compatible): 15oZ3FrhQJsVnpT6Ho1ZrQFQRnaaZF9gdS exists since Wed Oct 11 2017 19:09:57 GMT-0700 (Pacific Summer Time) Hash (In HEX) SHA3-384 23b81d863e9607f3416d14cb5913ee4e83cc7bf32ae3a6fab12c53e741ac7dda028c3dcc1d25950bb2f1122cacba10ba SHA3-512 cc7240e11c025e2411630ba97e2e7cf59aa684823a147d1a3972d7b4eaf3019af7d8c25dcb25a6c25cd7b5b9b7f72c944b0fd6e7bda4aa365f036cc4a188fc65 HMAC (In
372017-12-14T01:27:34 <Nobody_> magnet:?xt=urn:btih:0539a6634c7f87f17788767b3a3c250ddaa4cde2&dn=Blockchain+updated.txt&tr=wss%3A%2F%2Ftracker.btorrent.xyz&tr=wss%3A%2F%2Ftracker.fastcast.nz&tr=wss%3A%2F%2Ftracker.openwebtorrent.com
382017-12-14T01:27:41 *** PaulCapestany has quit IRC
392017-12-14T01:27:49 <Nobody_> Hash: 0539a6634c7f87f17788767b3a3c250ddaa4cde2
402017-12-14T01:28:22 <Nobody_> HMAC (In HEX) Encrypted SHA3-384 00bed720e4ecd0897297c5b3f583d9567a19b2e9952c0a40fdd0bf24ae99093cfe27a3b433ca2b964a1a607c0dfb8b91 Encrypted SHA3-512 97013026b80c0a190e3591c42b3a75cce484a420d7f2305c28d6a1a7a937229d49aab88cb4d5aa90548df98eda2b699007bb5fae24e2485ec9fb0c0a1e685b41
412017-12-14T01:30:10 *** PaulCapestany has joined #bitcoin-core-dev
422017-12-14T01:30:20 <sipa> Nobody_: i have the impression you're trying to be nice, so i don't want to yell at you, but i have no clue what you're trying to say
432017-12-14T01:31:15 <Nobody_> I truely am Nobody in the system and as the Court of Japan ruled, Nobody own's the Cryptocurrency as Nobody own's the Blockchain so enjoy your holiday ok? make it the Perfect Greatest you ever could have! ;)
442017-12-14T01:31:24 <Nobody_> With even a bit of love from God
452017-12-14T01:31:28 <Nobody_> No Joke!
462017-12-14T01:31:33 *** Randolf has quit IRC
472017-12-14T01:31:34 <sipa> ok, thank you!
482017-12-14T01:31:35 <Nobody_> Hahaha
492017-12-14T01:31:56 <Nobody_> Time to leave, have a great one and that magnet link will download if you need it
502017-12-14T01:32:05 <Nobody_> https://btorrent.xyz/#0539a6634c7f87f17788767b3a3c250ddaa4cde2
512017-12-14T01:32:06 <gribble> https://github.com/bitcoin/bitcoin/issues/0539 | Qt GUI updates by laanwj · Pull Request #539 · bitcoin/bitcoin · GitHub
522017-12-14T01:32:10 <Nobody_> blob:https://btorrent.xyz/427f6751-7950-476d-84a3-693924bb02bc
532017-12-14T01:32:24 <sipa> please don't expect people to download things from random lins
542017-12-14T01:33:01 <Nobody_> Time to leave, please as we already added the Faucet in the Bitcoin Core make sure it is finalized
552017-12-14T01:33:14 <Nobody_> it is crutial for the Robot's to request from Nobody
562017-12-14T01:33:32 *** PaulCapestany has quit IRC
572017-12-14T01:33:48 *** Chris_Stewart_5 has quit IRC
582017-12-14T01:33:50 <Nobody_> it is a Free Faucet that you can deposit, withdraw or transact to a Nobody account in the Core that allow's for a Savings like Wallet
592017-12-14T01:33:52 <mryandao> quick question: does bitcoin 0.7.0rc3 also build a qt GUI interface?
602017-12-14T01:33:55 <Nobody_> for Everyone to use
612017-12-14T01:34:13 <sipa> mryandao: you certainly can
622017-12-14T01:34:18 <sipa> mryandao: Qt GUI was added in 0.5.0
632017-12-14T01:34:19 <Nobody_> Other than that, Ten Four, Over and Out!
642017-12-14T01:34:23 *** Nobody_ has quit IRC
652017-12-14T01:34:30 <mryandao> can we also ban the spammer.
662017-12-14T01:34:33 <mryandao> oh, he left.
672017-12-14T01:36:28 *** PaulCapestany has joined #bitcoin-core-dev
682017-12-14T01:37:51 <jimpo> Is there is a way to see debug logs generated during tests? And even better in tests running on Travis?
692017-12-14T01:39:13 <sipa> you can call the functional tests .py file with an argument to not clean up the testdir
702017-12-14T01:39:30 <sipa> --nocleanup
712017-12-14T01:39:58 <jimpo> For unit tests
722017-12-14T01:40:29 <jimpo> stdout seems to be suppressed
732017-12-14T01:41:45 *** jamesob has quit IRC
742017-12-14T01:45:15 *** xmsx has joined #bitcoin-core-dev
752017-12-14T01:46:07 <xmsx> Quick question -- can I import P2SH-P2WPKH address using importmulti?
762017-12-14T01:46:19 <sipa> no
772017-12-14T01:46:43 <xmsx> What RPC should I use for it?
782017-12-14T01:47:00 <sipa> import the private key however you want, and then call addwitnessaddress
792017-12-14T01:47:20 <sipa> the wallet just doesn't support segwit addresses natively yet
802017-12-14T01:47:21 <xmsx> addwitnessaddress doesn't rescan the blockchain :'(
812017-12-14T01:47:37 <sipa> you can call rescanblockchain manually
822017-12-14T01:48:03 <sipa> not saying all of this is ideal; none of it should be necessary (and soon won't)
832017-12-14T01:49:29 *** jb55 has joined #bitcoin-core-dev
842017-12-14T01:49:38 <xmsx> So we'll be able to use importmulti for segwit soon?
852017-12-14T01:49:50 *** Ylbam has quit IRC
862017-12-14T01:50:04 <xmsx> Atm it imports the address as watch only :(
872017-12-14T01:50:15 <sipa> yes
882017-12-14T01:50:19 <sipa> next release
892017-12-14T01:50:32 <sipa> (with high probability; unexpected events can always change release plans)
902017-12-14T01:50:46 <xmsx> Yay, any ETA by any chance?
912017-12-14T01:51:01 <sipa> no
922017-12-14T01:51:15 *** PaulCapestany has quit IRC
932017-12-14T01:51:48 <xmsx> Nvm, thanks a lot for your hard work anyway :)
942017-12-14T01:52:03 *** PaulCapestany has joined #bitcoin-core-dev
952017-12-14T01:52:26 <sipa> thanks!
962017-12-14T01:55:08 <xmsx> Another question from newb -- is there a way to find out the block height by timestamp?:)
972017-12-14T01:59:48 *** bule has quit IRC
982017-12-14T02:02:31 *** CubicEarth has quit IRC
992017-12-14T02:05:12 *** ederfdias has joined #bitcoin-core-dev
1002017-12-14T02:06:39 *** gaf_ has quit IRC
1012017-12-14T02:07:38 *** ederfdias has quit IRC
1022017-12-14T02:10:50 *** gaf_ has joined #bitcoin-core-dev
1032017-12-14T02:13:24 *** bule has joined #bitcoin-core-dev
1042017-12-14T02:18:28 <promag> xmsx: iirc no
1052017-12-14T02:20:03 *** bule has quit IRC
1062017-12-14T02:20:43 *** bule has joined #bitcoin-core-dev
1072017-12-14T02:29:43 *** PaulCapestany has quit IRC
1082017-12-14T02:31:59 *** dermoth has quit IRC
1092017-12-14T02:32:40 *** StopAndDecrypt has quit IRC
1102017-12-14T02:32:40 *** luke-jr has quit IRC
1112017-12-14T02:32:40 *** jtimon has quit IRC
1122017-12-14T02:32:40 *** bsm117532 has quit IRC
1132017-12-14T02:32:40 *** [b__b] has quit IRC
1142017-12-14T02:32:40 *** owowo has quit IRC
1152017-12-14T02:32:40 *** promag has quit IRC
1162017-12-14T02:32:40 *** nullptr| has quit IRC
1172017-12-14T02:32:40 *** d9b4bef9 has quit IRC
1182017-12-14T02:32:40 *** edman80 has quit IRC
1192017-12-14T02:32:40 *** shtirlic has quit IRC
1202017-12-14T02:36:25 *** StopAndDecrypt has joined #bitcoin-core-dev
1212017-12-14T02:36:25 *** luke-jr has joined #bitcoin-core-dev
1222017-12-14T02:36:25 *** jtimon has joined #bitcoin-core-dev
1232017-12-14T02:36:25 *** bsm117532 has joined #bitcoin-core-dev
1242017-12-14T02:36:25 *** [b__b] has joined #bitcoin-core-dev
1252017-12-14T02:36:25 *** owowo has joined #bitcoin-core-dev
1262017-12-14T02:36:25 *** promag has joined #bitcoin-core-dev
1272017-12-14T02:36:25 *** nullptr| has joined #bitcoin-core-dev
1282017-12-14T02:36:25 *** d9b4bef9 has joined #bitcoin-core-dev
1292017-12-14T02:36:25 *** edman80 has joined #bitcoin-core-dev
1302017-12-14T02:36:25 *** shtirlic has joined #bitcoin-core-dev
1312017-12-14T02:36:33 *** dermoth has joined #bitcoin-core-dev
1322017-12-14T02:36:58 *** luke-jr has quit IRC
1332017-12-14T02:37:07 *** luke-jr has joined #bitcoin-core-dev
1342017-12-14T02:37:17 *** PaulCapestany has joined #bitcoin-core-dev
1352017-12-14T02:37:47 *** Chris_Stewart_5 has joined #bitcoin-core-dev
1362017-12-14T02:40:28 *** Murch has quit IRC
1372017-12-14T02:41:50 *** Randolf has joined #bitcoin-core-dev
1382017-12-14T02:56:55 <promag> how long 'make -j5 check VERBOSE=1' usually takes on your machine? anyone?
1392017-12-14T02:59:11 <sipa> from scratch? with ccache?
1402017-12-14T02:59:16 *** lnostdal has quit IRC
1412017-12-14T02:59:51 <promag> from scratch? without ccache..
1422017-12-14T03:02:00 <xmsx> Do I have to use Bech32, or using P2SH-P2WPKH is ok for now?
1432017-12-14T03:03:26 *** freeark1 has joined #bitcoin-core-dev
1442017-12-14T03:03:59 <luke-jr> xmsx: you don't have to use anything. you can even use p2pk if you really want to.
1452017-12-14T03:04:43 *** PaulCapestany has quit IRC
1462017-12-14T03:04:57 *** bule2 has joined #bitcoin-core-dev
1472017-12-14T03:05:19 <xmsx> I really want to stay on bleeding edge :D
1482017-12-14T03:05:27 <sipa> xmsx: at this point, the bitcoin core wallet does not fully support segwit - you can use the addwitnessaddress approach at your own risk
1492017-12-14T03:05:48 <luke-jr> xmsx: well then you should just use Lightning :p
1502017-12-14T03:05:56 <sipa> if you want bleeding edge, try running with https://github.com/bitcoin/bitcoin/pull/11403
1512017-12-14T03:06:05 *** quantbot has joined #bitcoin-core-dev
1522017-12-14T03:06:37 <sipa> promag: benchmarking
1532017-12-14T03:06:48 <promag> sipa: ah thanks
1542017-12-14T03:07:24 *** bule has quit IRC
1552017-12-14T03:07:25 <promag> sipa: but it turns out I had a deadlock
1562017-12-14T03:07:37 <sipa> what do you want? a 4-core i7 system, an 8-core AMD Ryzen, or a 14-core Xeon v3?
1572017-12-14T03:08:04 <luke-jr> 16-core POWER9 system? <.<
1582017-12-14T03:08:08 <xmsx> What's the best software for LN? should I use eclair?
1592017-12-14T03:08:22 <promag> heh i5
1602017-12-14T03:08:23 <luke-jr> xmsx: if you're not *writing* software, you should really be asking in #bitcoin
1612017-12-14T03:08:38 <promag> luke-jr: sup?
1622017-12-14T03:08:43 <luke-jr> promag: ?
1632017-12-14T03:08:46 <promag> luke-jr: multiwallet gui :D
1642017-12-14T03:09:02 <luke-jr> sorry, tied up with high priority RL stuff lately :/
1652017-12-14T03:09:11 <xmsx> I'm a backend developer, so I am kinda writing stuff :)
1662017-12-14T03:09:12 <luke-jr> maybe I'll take a break and update multiwallet gui..
1672017-12-14T03:09:18 <promag> np +1
1682017-12-14T03:09:32 <sipa> xmsx: right, but this channel is about bitcoin core's development
1692017-12-14T03:09:47 <sipa> you're welcome to ask here how things work, or discuss related things
1702017-12-14T03:09:57 <sipa> but questions about usage really don't belong here
1712017-12-14T03:10:20 <xmsx> Kk, got it, thanks :)
1722017-12-14T03:12:01 <sipa> promag: on 8-core AMD Ryzen:
1732017-12-14T03:12:02 <sipa> real 3m28.787s
1742017-12-14T03:12:02 <sipa> user 43m10.276s
1752017-12-14T03:12:59 <promag> thanks
1762017-12-14T03:14:05 *** sanada has joined #bitcoin-core-dev
1772017-12-14T03:15:50 *** freeark1 has quit IRC
1782017-12-14T03:16:15 *** Chris_Stewart_5 has quit IRC
1792017-12-14T03:22:21 *** lnostdal has joined #bitcoin-core-dev
1802017-12-14T03:22:25 *** archaeal has quit IRC
1812017-12-14T03:24:35 *** bule2 has quit IRC
1822017-12-14T03:25:01 *** bule2 has joined #bitcoin-core-dev
1832017-12-14T03:35:10 <luke-jr> k, #11383 rebased & comments addressed
1842017-12-14T03:35:12 <gribble> https://github.com/bitcoin/bitcoin/issues/11383 | Basic Multiwallet GUI support by luke-jr · Pull Request #11383 · bitcoin/bitcoin · GitHub
1852017-12-14T03:35:27 *** quantbot has quit IRC
1862017-12-14T03:36:04 *** quantbot has joined #bitcoin-core-dev
1872017-12-14T03:36:26 *** archaeal has joined #bitcoin-core-dev
1882017-12-14T03:36:49 <promag> is fee estimation an activity? like it should show up in the activity window while it's not ready?
1892017-12-14T03:37:01 <promag> luke-jr: k
1902017-12-14T03:38:15 <sipa> promag: that's maybe a useful way to present it
1912017-12-14T03:38:37 <sipa> though it's not actually acitivity as in doing something - it just needs enough data
1922017-12-14T03:38:48 <sipa> so perhaps you can call it 'gather data for fee estimation'
1932017-12-14T03:38:51 <promag> waiting is an activity :D
1942017-12-14T03:39:02 *** DrFeelGood has joined #bitcoin-core-dev
1952017-12-14T03:39:04 <promag> or that
1962017-12-14T03:39:27 *** quantbot has quit IRC
1972017-12-14T03:39:35 *** fanquake has joined #bitcoin-core-dev
1982017-12-14T03:40:21 *** quantbot_ has joined #bitcoin-core-dev
1992017-12-14T03:40:27 <promag> I like that
2002017-12-14T03:41:43 <fanquake> I'm going to delete the "help me hard fork bitcoin for $500" comments and lock the threads they've been posted on. Seem to be kind of alt-coin related anyway.
2012017-12-14T03:42:06 <sipa> fanquake: thanks
2022017-12-14T03:46:01 *** meshcollider has quit IRC
2032017-12-14T03:50:35 *** furusato has joined #bitcoin-core-dev
2042017-12-14T03:54:21 *** DrFeelGood has quit IRC
2052017-12-14T03:55:11 *** bule2 has quit IRC
2062017-12-14T03:55:27 *** _parts_ is now known as _parts
2072017-12-14T03:55:36 *** bule2 has joined #bitcoin-core-dev
2082017-12-14T03:56:25 *** DrFeelGood has joined #bitcoin-core-dev
2092017-12-14T03:57:25 *** furusato has quit IRC
2102017-12-14T04:10:56 *** promag has quit IRC
2112017-12-14T04:11:30 *** quantbot_ has quit IRC
2122017-12-14T04:12:04 *** quantbot has joined #bitcoin-core-dev
2132017-12-14T04:15:21 *** jtimon has quit IRC
2142017-12-14T04:16:08 *** quantbot has quit IRC
2152017-12-14T04:21:29 *** meshcollider has joined #bitcoin-core-dev
2162017-12-14T04:26:08 *** meshcollider has quit IRC
2172017-12-14T04:36:58 *** mrfrasha_ has joined #bitcoin-core-dev
2182017-12-14T04:40:44 *** bule2 has quit IRC
2192017-12-14T04:40:53 *** derrekito has joined #bitcoin-core-dev
2202017-12-14T04:42:33 *** mrfrasha_ has quit IRC
2212017-12-14T04:42:45 *** mrfrasha_ has joined #bitcoin-core-dev
2222017-12-14T04:43:06 *** meshcollider has joined #bitcoin-core-dev
2232017-12-14T04:57:54 *** dermoth has quit IRC
2242017-12-14T04:58:33 *** dermoth has joined #bitcoin-core-dev
2252017-12-14T05:10:20 *** dermoth has quit IRC
2262017-12-14T05:10:49 *** dermoth has joined #bitcoin-core-dev
2272017-12-14T05:31:27 *** Squidicuz has quit IRC
2282017-12-14T05:31:30 *** Squidicc has joined #bitcoin-core-dev
2292017-12-14T05:36:07 *** saint_ has quit IRC
2302017-12-14T05:59:24 *** To7 has quit IRC
2312017-12-14T06:03:08 *** DrFeelGood has quit IRC
2322017-12-14T06:04:28 *** arubi has quit IRC
2332017-12-14T06:05:49 *** DrFeelGood has joined #bitcoin-core-dev
2342017-12-14T06:06:27 *** DrFeelGood has quit IRC
2352017-12-14T06:08:41 <jonasschnelli> [17:12:01] <sipa> promag: on 8-core AMD Ryzen:
2362017-12-14T06:08:47 <jonasschnelli> sipa: you are working on a desktop?
2372017-12-14T06:10:20 *** arubi has joined #bitcoin-core-dev
2382017-12-14T06:10:49 <sipa> jonasschnelli: via ssh
2392017-12-14T06:11:31 <jonasschnelli> sipa: heh... yes. I also use a ssh remote build script when I'm on low battery but high bandwidth.
2402017-12-14T06:15:13 <sipa> jonasschnelli: no, i don't generally don't build remotely
2412017-12-14T06:15:21 <sipa> i just ssh'ed into my desktop
2422017-12-14T06:15:26 <sipa> and compiled there
2432017-12-14T06:15:36 <jonasschnelli> Yeah.. makes sense...
2442017-12-14T06:15:41 <sipa> usually i build just on my laptop
2452017-12-14T06:16:19 <jonasschnelli> compiling is just a battery drainer...
2462017-12-14T06:18:21 <sipa> i have a power socket nearby :)
2472017-12-14T06:21:52 *** jb55 has quit IRC
2482017-12-14T06:29:14 *** DrFeelGood has joined #bitcoin-core-dev
2492017-12-14T06:29:21 <jonasschnelli> I think it's a travelers work from non-home location problem. :)
2502017-12-14T06:40:55 *** meshcollider has quit IRC
2512017-12-14T06:44:41 *** Ylbam has joined #bitcoin-core-dev
2522017-12-14T06:44:42 *** jadee_ has joined #bitcoin-core-dev
2532017-12-14T06:49:41 *** _jadeeUnix has joined #bitcoin-core-dev
2542017-12-14T06:49:49 <_jadeeUnix> .
2552017-12-14T06:50:56 *** _jadeeUnix has quit IRC
2562017-12-14T06:51:16 *** _jadeeUnix has joined #bitcoin-core-dev
2572017-12-14T06:51:28 *** Ylbam has quit IRC
2582017-12-14T06:59:29 *** _jadeeWeb has joined #bitcoin-core-dev
2592017-12-14T06:59:42 *** _jadeeWeb has left #bitcoin-core-dev
2602017-12-14T07:00:05 *** _jadeeUnix has quit IRC
2612017-12-14T07:08:04 *** Randolf has quit IRC
2622017-12-14T07:17:37 *** Randolf has joined #bitcoin-core-dev
2632017-12-14T07:22:29 *** go1111111 has joined #bitcoin-core-dev
2642017-12-14T07:31:08 *** DrFeelGood has quit IRC
2652017-12-14T07:32:52 *** Cogito_Ergo_Sum has joined #bitcoin-core-dev
2662017-12-14T07:32:52 *** Cogito_Ergo_Sum has joined #bitcoin-core-dev
2672017-12-14T07:42:07 *** DrFeelGood has joined #bitcoin-core-dev
2682017-12-14T07:47:28 *** SopaXorzTaker has joined #bitcoin-core-dev
2692017-12-14T07:48:10 *** SopaXorzTaker is now known as Xanukkah
2702017-12-14T07:50:07 <jonasschnelli> luke-jr: a complete UTXO scan with sweepprivkeys takes ~3mins on my machine (mainnet)... is there a nice way to show progress?
2712017-12-14T07:50:15 <jonasschnelli> (probably not with RPC)
2722017-12-14T07:56:09 *** jadee_ has quit IRC
2732017-12-14T07:56:48 *** jadee_ has joined #bitcoin-core-dev
2742017-12-14T07:56:51 *** meshcollider has joined #bitcoin-core-dev
2752017-12-14T07:56:55 *** jadee_ has quit IRC
2762017-12-14T07:57:12 *** jadee_ has joined #bitcoin-core-dev
2772017-12-14T07:57:57 *** jadee_ has joined #bitcoin-core-dev
2782017-12-14T07:58:28 *** jadee_ has quit IRC
2792017-12-14T08:02:52 *** Ylbam has joined #bitcoin-core-dev
2802017-12-14T08:04:52 *** chjj has quit IRC
2812017-12-14T08:26:28 *** Ylbam has quit IRC
2822017-12-14T08:27:59 *** chjj has joined #bitcoin-core-dev
2832017-12-14T08:55:26 *** zxzzt has quit IRC
2842017-12-14T08:55:48 *** zxzzt has joined #bitcoin-core-dev
2852017-12-14T08:56:01 *** ghost43 has quit IRC
2862017-12-14T08:56:19 *** ghost43 has joined #bitcoin-core-dev
2872017-12-14T08:58:00 *** laurentmt has joined #bitcoin-core-dev
2882017-12-14T08:59:08 *** tiagotrs has joined #bitcoin-core-dev
2892017-12-14T08:59:08 *** tiagotrs has joined #bitcoin-core-dev
2902017-12-14T09:02:03 *** fanquake has quit IRC
2912017-12-14T09:02:23 *** fanquake has joined #bitcoin-core-dev
2922017-12-14T09:04:42 *** tiagotrs has quit IRC
2932017-12-14T09:08:29 *** Xanukkah has quit IRC
2942017-12-14T09:08:49 *** SopaXorzTaker has joined #bitcoin-core-dev
2952017-12-14T09:10:31 *** cryptapus has quit IRC
2962017-12-14T09:11:16 *** cryptapus has joined #bitcoin-core-dev
2972017-12-14T09:13:06 *** SopaXorzTaker has quit IRC
2982017-12-14T09:13:48 *** JackH has quit IRC
2992017-12-14T09:16:23 *** tiagotrs has joined #bitcoin-core-dev
3002017-12-14T09:17:14 *** SopaXorzTaker has joined #bitcoin-core-dev
3012017-12-14T09:18:07 *** xmsx has quit IRC
3022017-12-14T09:27:25 *** JackH has joined #bitcoin-core-dev
3032017-12-14T09:28:57 *** timothy has joined #bitcoin-core-dev
3042017-12-14T09:29:26 *** promag has joined #bitcoin-core-dev
3052017-12-14T09:29:50 *** alreadylate has joined #bitcoin-core-dev
3062017-12-14T09:31:21 <promag> wumpus: I guess #11864 is ready
3072017-12-14T09:31:23 <gribble> https://github.com/bitcoin/bitcoin/issues/11864 | Make CWallet::FundTransaction atomic by promag · Pull Request #11864 · bitcoin/bitcoin · GitHub
3082017-12-14T09:34:55 <wumpus> thanks, will take a look
3092017-12-14T09:39:00 <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/d4991c0cbb8a...2ae58d5bfb76
3102017-12-14T09:39:01 <bitcoin-git> bitcoin/master 95d4450 João Barbosa: [wallet] Tidy up CWallet::FundTransaction
3112017-12-14T09:39:01 <bitcoin-git> bitcoin/master 03a5dc9 João Barbosa: [wallet] Make CWallet::FundTransaction atomic
3122017-12-14T09:39:02 <bitcoin-git> bitcoin/master 2ae58d5 Wladimir J. van der Laan: Merge #11864: Make CWallet::FundTransaction atomic...
3132017-12-14T09:39:36 <bitcoin-git> [bitcoin] laanwj closed pull request #11864: Make CWallet::FundTransaction atomic (master...2017-12-atomic-fundtransaction) https://github.com/bitcoin/bitcoin/pull/11864
3142017-12-14T09:42:28 *** mrfrasha_ has quit IRC
3152017-12-14T09:45:47 *** BGL has quit IRC
3162017-12-14T10:01:47 <bitcoin-git> [bitcoin] JavadSM closed pull request #11843: Use python not 'python2' (master...master) https://github.com/bitcoin/bitcoin/pull/11843
3172017-12-14T10:06:27 <bitcoin-git> [bitcoin] JavadSM opened pull request #11895: Moving to python3 (master...master) https://github.com/bitcoin/bitcoin/pull/11895
3182017-12-14T10:08:40 *** AaronvanW has joined #bitcoin-core-dev
3192017-12-14T10:09:22 *** Aaronvan_ has joined #bitcoin-core-dev
3202017-12-14T10:12:49 *** AaronvanW has quit IRC
3212017-12-14T10:13:57 *** Cory has quit IRC
3222017-12-14T10:16:55 *** quantbot has joined #bitcoin-core-dev
3232017-12-14T10:19:14 *** Guyver2 has joined #bitcoin-core-dev
3242017-12-14T10:20:20 <promag> can I get your attention to #11041 ?
3252017-12-14T10:20:22 <gribble> https://github.com/bitcoin/bitcoin/issues/11041 | Add LookupBlockIndex by promag · Pull Request #11041 · bitcoin/bitcoin · GitHub
3262017-12-14T10:21:17 *** Emcy has quit IRC
3272017-12-14T10:22:07 *** Emcy has joined #bitcoin-core-dev
3282017-12-14T10:26:38 *** dabura667 has quit IRC
3292017-12-14T10:28:06 <wumpus> sure
3302017-12-14T10:30:40 <promag> ty
3312017-12-14T10:34:25 *** quantbot has quit IRC
3322017-12-14T10:41:22 <wumpus> promag: you add some lock(cs_main), were these missing before?
3332017-12-14T10:41:39 <wumpus> you don't mention any lock bug fixes, which is why I ask
3342017-12-14T10:44:38 *** kiss- has joined #bitcoin-core-dev
3352017-12-14T10:45:52 *** xmsx has joined #bitcoin-core-dev
3362017-12-14T10:48:26 *** alfa has joined #bitcoin-core-dev
3372017-12-14T10:57:43 *** Kozuch has joined #bitcoin-core-dev
3382017-12-14T10:58:54 *** quantbot has joined #bitcoin-core-dev
3392017-12-14T11:02:47 *** BGL has joined #bitcoin-core-dev
3402017-12-14T11:08:06 *** whphhg has quit IRC
3412017-12-14T11:08:19 *** whphhg has joined #bitcoin-core-dev
3422017-12-14T11:10:57 *** BGL has quit IRC
3432017-12-14T11:11:01 *** Deadhand has quit IRC
3442017-12-14T11:11:55 *** Deadhand has joined #bitcoin-core-dev
3452017-12-14T11:12:53 *** Cory has joined #bitcoin-core-dev
3462017-12-14T11:13:13 *** quantbot has quit IRC
3472017-12-14T11:24:57 *** quantbot has joined #bitcoin-core-dev
3482017-12-14T11:25:45 <promag> wumpus: yes missing locks
3492017-12-14T11:26:35 <promag> not sure if all are bugs because some come from the init & load block index etc
3502017-12-14T11:26:51 <wumpus> ok, please mention that in the issue, we should mark it as bugfix and not only refactor
3512017-12-14T11:27:03 <wumpus> yes the ones in init are probably not so relevant, but there is one in wallet too
3522017-12-14T11:27:08 <promag> but FindForkInGlobalIndex I think it's a bug
3532017-12-14T11:28:42 <wumpus> good, thanks for finding and fixing
3542017-12-14T11:34:11 *** SopaXorzTaker has quit IRC
3552017-12-14T11:38:11 *** SopaXorzTaker has joined #bitcoin-core-dev
3562017-12-14T11:50:05 <JackH> is there a limitation to how many addresses Bitcoin Core can generate for a given wallet? We issue about 500 new addresses per day, some which are used, some which are not, but is there a limit per wallet?
3572017-12-14T11:51:25 <wumpus> the software has no limit
3582017-12-14T11:51:45 <xmsx> I tested a wallet with 300k addresses once
3592017-12-14T11:53:11 <wumpus> at some point you might run into resource issues, things going slower
3602017-12-14T11:55:21 <JackH> we thought about 300k actually being where we would see problems
3612017-12-14T11:55:34 <JackH> we are soon hitting that
3622017-12-14T11:55:51 <JackH> would there be any difference between HD wallets and non HD wallets in terms of speed?
3632017-12-14T11:56:02 <wumpus> I'd be more worried about the amount of transactions, not so much the number of keys, keys are small
3642017-12-14T11:56:32 <JackH> so about 40% are transactions
3652017-12-14T11:56:45 <JackH> meaning roughly 120k transactions are stored right now
3662017-12-14T11:57:01 <JackH> do we know the bottleneck?
3672017-12-14T11:57:09 *** shesek has quit IRC
3682017-12-14T11:58:03 <wumpus> bitcoin core's wallet is not optimized for handling huge numbers of transactions, for example it keeps them all in memory, and doesn't at the moment have an utxo index. There has been work in that direction but any help is welcome.
3692017-12-14T11:59:07 <wumpus> as for what the limits are for your cpu/amount of memory, try it out on a development machine
3702017-12-14T12:02:29 <xmsx> Also, I would suggest discussing these questions from throwaway account (No one really needs to know that you store all addresses in single wallet) :)
3712017-12-14T12:05:03 <wumpus> e.g. using regtest, you can generate tons of transactions and blocks in a relatively small time
3722017-12-14T12:05:05 *** ghost43 has quit IRC
3732017-12-14T12:05:17 *** ghost43 has joined #bitcoin-core-dev
3742017-12-14T12:08:42 <promag> wumpus: JackH: actually the number of addresses has a great impact on performance
3752017-12-14T12:09:11 <wumpus> it has an impact on performance, but what he asked is whether there's a limit
3762017-12-14T12:09:48 *** BGL has joined #bitcoin-core-dev
3772017-12-14T12:10:05 *** kiss- has quit IRC
3782017-12-14T12:12:08 *** Guyver2 has quit IRC
3792017-12-14T12:32:09 *** tiagotrs has quit IRC
3802017-12-14T12:46:15 *** promag has quit IRC
3812017-12-14T12:48:52 <JackH> we are looking to run multiple daemons as a solution
3822017-12-14T12:49:05 *** gmaxwell has quit IRC
3832017-12-14T12:49:06 <JackH> and retire daemons as they hit performance issues
3842017-12-14T12:49:12 <JackH> daemons//wallets
3852017-12-14T12:50:53 *** gmaxwell has joined #bitcoin-core-dev
3862017-12-14T12:51:17 *** gmaxwell is now known as Guest52242
3872017-12-14T12:51:42 *** guest123 has joined #bitcoin-core-dev
3882017-12-14T12:53:50 *** guest123 has left #bitcoin-core-dev
3892017-12-14T12:56:18 <kabaum_> Is it possible that there are other yet unknown ways to malleate a signature than the "-S" trick? Or maybe even known ones? I refer only to inherent ECDSA signature malleability.
3902017-12-14T13:07:27 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3912017-12-14T13:10:13 *** fanquake has quit IRC
3922017-12-14T13:13:23 *** Pavle has joined #bitcoin-core-dev
3932017-12-14T13:13:54 *** contrapumpkin has joined #bitcoin-core-dev
3942017-12-14T13:18:02 <xmsx> Could anyone review changes to segwitsupport.csv (bitcoincore.org repo) please? Using P2SH-P2WPKH addresses atm but will add bech32 soon too :)
3952017-12-14T13:18:31 <wumpus> kabaum_: yes that is possible (might be better to ask in #bitcoin-wizards)
3962017-12-14T13:19:52 *** PaulCapestany has joined #bitcoin-core-dev
3972017-12-14T13:24:48 *** Chris_Stewart_5 has quit IRC
3982017-12-14T13:37:07 *** To7 has joined #bitcoin-core-dev
3992017-12-14T13:37:11 *** kuldeeps48 has joined #bitcoin-core-dev
4002017-12-14T13:40:28 *** kuldeeps48 has quit IRC
4012017-12-14T13:43:25 *** tiagotrs has joined #bitcoin-core-dev
4022017-12-14T13:50:07 <kabaum_> wumpus: thanks
4032017-12-14T13:51:15 *** Chris_Stewart_5 has joined #bitcoin-core-dev
4042017-12-14T13:53:14 <Varunram> promag: http://www.kumobius.com/2013/08/c-string-to-int/ might help for #11897, comparing between various alternatives
4052017-12-14T13:53:15 <gribble> https://github.com/bitcoin/bitcoin/issues/11897 | Replace atoi64 with ParseInt64 · Issue #11897 · bitcoin/bitcoin · GitHub
4062017-12-14T13:53:28 *** alreadylate has quit IRC
4072017-12-14T13:54:06 <Varunram> oh wait, disregard that, my bad
4082017-12-14T13:56:38 *** meshcollider has quit IRC
4092017-12-14T13:57:01 *** xmsx has quit IRC
4102017-12-14T13:58:03 *** alfa has quit IRC
4112017-12-14T14:00:28 *** Chris_Stewart_5 has quit IRC
4122017-12-14T14:05:48 *** alreadylate has joined #bitcoin-core-dev
4132017-12-14T14:13:09 *** PaulCapestany has quit IRC
4142017-12-14T14:19:23 *** Mlkk has joined #bitcoin-core-dev
4152017-12-14T14:22:22 *** Mlkk is now known as Mlk
4162017-12-14T14:38:19 *** Chris_Stewart_5 has joined #bitcoin-core-dev
4172017-12-14T14:45:05 *** bgtc has joined #bitcoin-core-dev
4182017-12-14T14:47:02 *** PaulCapestany has joined #bitcoin-core-dev
4192017-12-14T14:51:39 *** JackH has quit IRC
4202017-12-14T14:52:13 *** bgtc has quit IRC
4212017-12-14T15:02:01 *** Pavle has quit IRC
4222017-12-14T15:09:32 *** Mlk has quit IRC
4232017-12-14T15:26:58 *** PaulCapestany has quit IRC
4242017-12-14T15:27:31 *** freeark1 has joined #bitcoin-core-dev
4252017-12-14T15:27:39 *** Pavle has joined #bitcoin-core-dev
4262017-12-14T15:28:44 *** jb55 has joined #bitcoin-core-dev
4272017-12-14T15:31:14 *** PaulCapestany has joined #bitcoin-core-dev
4282017-12-14T15:32:21 *** whphhg has quit IRC
4292017-12-14T15:33:32 *** whphhg has joined #bitcoin-core-dev
4302017-12-14T15:35:14 *** PaulCapestany has quit IRC
4312017-12-14T15:37:42 *** Matt__ has joined #bitcoin-core-dev
4322017-12-14T15:42:25 *** PaulCapestany has joined #bitcoin-core-dev
4332017-12-14T15:42:52 *** satoshi_1iv3s has joined #bitcoin-core-dev
4342017-12-14T15:45:03 *** Giszmo has quit IRC
4352017-12-14T15:47:05 *** mrfrasha_ has joined #bitcoin-core-dev
4362017-12-14T15:48:06 *** CubicEarth has joined #bitcoin-core-dev
4372017-12-14T15:49:37 *** CASEgezadthfr has joined #bitcoin-core-dev
4382017-12-14T15:51:34 *** CubicEarth has quit IRC
4392017-12-14T15:53:30 *** jb55 has quit IRC
4402017-12-14T15:54:53 *** edman80 has quit IRC
4412017-12-14T15:55:02 *** pkx2 has joined #bitcoin-core-dev
4422017-12-14T15:55:30 *** freeark1 has quit IRC
4432017-12-14T15:55:54 <BlueMatt> #11884 looks merge-able
4442017-12-14T15:55:55 <gribble> https://github.com/bitcoin/bitcoin/issues/11884 | Remove unused include in hash.cpp by kallewoof · Pull Request #11884 · bitcoin/bitcoin · GitHub
4452017-12-14T15:57:36 *** Szadek has joined #bitcoin-core-dev
4462017-12-14T16:01:41 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/2ae58d5bfb76...66479c0e611a
4472017-12-14T16:01:41 <bitcoin-git> bitcoin/master 3f09e03 Karl-Johan Alm: Remove unused include in hash.cpp
4482017-12-14T16:01:42 <bitcoin-git> bitcoin/master 66479c0 Wladimir J. van der Laan: Merge #11884: Remove unused include in hash.cpp...
4492017-12-14T16:01:45 *** macumba has joined #bitcoin-core-dev
4502017-12-14T16:02:13 <bitcoin-git> [bitcoin] laanwj closed pull request #11884: Remove unused include in hash.cpp (master...20171213-unneeded-include-hash-cpp) https://github.com/bitcoin/bitcoin/pull/11884
4512017-12-14T16:02:43 <wumpus> yep
4522017-12-14T16:03:22 *** Giszmo has joined #bitcoin-core-dev
4532017-12-14T16:09:38 *** macumba has quit IRC
4542017-12-14T16:21:23 *** jb55 has joined #bitcoin-core-dev
4552017-12-14T16:24:27 *** rfdavid_ has quit IRC
4562017-12-14T16:33:51 <BlueMatt> if someone wants to kill uselessly-trivial prs: #10839 could be merged
4572017-12-14T16:33:53 <gribble> https://github.com/bitcoin/bitcoin/issues/10839 | Dont use pass by reference to const for cheaply-copied types (bool, char, etc.) by practicalswift · Pull Request #10839 · bitcoin/bitcoin · GitHub
4582017-12-14T16:39:25 <cfields> #11842 is trivial and merge-ready too
4592017-12-14T16:39:27 <gribble> https://github.com/bitcoin/bitcoin/issues/11842 | [build] Add missing stuff to clean-local by kallewoof · Pull Request #11842 · bitcoin/bitcoin · GitHub
4602017-12-14T16:39:56 *** promag has joined #bitcoin-core-dev
4612017-12-14T16:43:00 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/66479c0e611a...3c8f0a3b8e67
4622017-12-14T16:43:01 <bitcoin-git> bitcoin/master b341143 Karl-Johan Alm: [build] Add missing stuff to clean-local...
4632017-12-14T16:43:02 <bitcoin-git> bitcoin/master 3c8f0a3 Wladimir J. van der Laan: Merge #11842: [build] Add missing stuff to clean-local...
4642017-12-14T16:43:32 <bitcoin-git> [bitcoin] laanwj closed pull request #11842: [build] Add missing stuff to clean-local (master...buildsys-cleanup) https://github.com/bitcoin/bitcoin/pull/11842
4652017-12-14T16:50:36 *** promag has quit IRC
4662017-12-14T17:14:34 *** Pavle has quit IRC
4672017-12-14T17:21:18 *** goatpig has joined #bitcoin-core-dev
4682017-12-14T17:28:34 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3c8f0a3b8e67...c66adb286a89
4692017-12-14T17:28:34 <bitcoin-git> bitcoin/master 99ba0c3 practicalswift: Don't use pass by reference to const for cheaply-copied types (bool, char, etc.).
4702017-12-14T17:28:35 <bitcoin-git> bitcoin/master c66adb2 Wladimir J. van der Laan: Merge #10839: Don't use pass by reference to const for cheaply-copied types (bool, char, etc.)...
4712017-12-14T17:28:53 <bitcoin-git> [bitcoin] laanwj closed pull request #10839: Don't use pass by reference to const for cheaply-copied types (bool, char, etc.) (master...dont-pass-by-reference-for-cheaply-copied-types) https://github.com/bitcoin/bitcoin/pull/10839
4722017-12-14T17:29:18 *** Matt__ has quit IRC
4732017-12-14T17:35:10 *** xmsx has joined #bitcoin-core-dev
4742017-12-14T17:35:48 *** timothy has quit IRC
4752017-12-14T17:42:09 *** justanotheruser has quit IRC
4762017-12-14T17:50:45 *** Giszmo has quit IRC
4772017-12-14T17:51:40 *** Guest52242 has quit IRC
4782017-12-14T17:51:40 *** Guest52242 has joined #bitcoin-core-dev
4792017-12-14T17:51:50 *** Guest52242 is now known as gmaxwell
4802017-12-14T17:55:08 *** jtimon has joined #bitcoin-core-dev
4812017-12-14T17:58:15 *** maaku has joined #bitcoin-core-dev
4822017-12-14T17:59:38 <maaku> the implementation of BIPs 98, 116, 117 could use some review:
4832017-12-14T17:59:48 <maaku> https://github.com/maaku/bitcoin/tree/merkle-branch-verify
4842017-12-14T17:59:56 <maaku> https://github.com/maaku/bitcoin/tree/tail-call-semantics
4852017-12-14T18:00:03 *** jadee_ has joined #bitcoin-core-dev
4862017-12-14T18:00:24 <maaku> (together they implement the features needed for MAST, currently policy-only)
4872017-12-14T18:00:32 <wumpus> would be good to bring up in the meeting
4882017-12-14T18:02:24 <maaku> I believe kallewoof is going to make a PR when he's done reviewing it himself, but no harm in others taking a peek too
4892017-12-14T18:02:56 <Chris_Stewart_5> maaku: What's up with the goto in the tail-call-semantics? Isn't that pretty ill advised?
4902017-12-14T18:04:15 <maaku> Chris_Stewart_5: goto is a funny thing. this is actually the one application goto is the best solution for, where the semantics are well-defined and is the easiest way to accomplish what is desired
4912017-12-14T18:04:49 <maaku> it's not possible to do tail-call recursion otherwise, and to my knowledge that's basically the reason goto still exists all these iterations of the C++ standard later
4922017-12-14T18:05:50 <Chris_Stewart_5> maaku: So I might be getting my 'tail-calls' mixed up, but does this goto keep a stack frames allocated during the recursive step?
4932017-12-14T18:06:06 <Chris_Stewart_5> like tail recursion in a functional lang
4942017-12-14T18:07:33 <maaku> A new stack frame is not created for the call itself. Any changes to the stack are properly unwound, with destructors called for things that fall out of scope, or stack allocations made and constructors called for things you skip over in other applications of goto (not here)
4952017-12-14T18:07:50 *** jamesob has joined #bitcoin-core-dev
4962017-12-14T18:08:44 *** laurentmt has quit IRC
4972017-12-14T18:08:49 <maaku> for example, if the `if {}` statement that had the goto had its own variable that was an instance of the class, the goto would have called the destructor and deallocated it before jumping up to the start of the function
4982017-12-14T18:09:35 <maaku> or as an actual example, vfExec is destroyed as part of the goto
4992017-12-14T18:09:47 <maaku> (and then recreated when execution reaches it again)
5002017-12-14T18:09:58 *** Ylbam has joined #bitcoin-core-dev
5012017-12-14T18:11:25 *** alreadylate has quit IRC
5022017-12-14T18:11:44 *** meshcollider has joined #bitcoin-core-dev
5032017-12-14T18:12:55 <maaku> from cppreference:
5042017-12-14T18:12:58 <maaku> > If transfer of control exits the scope of any automatic variables (e.g. by jumping backwards to a point before the declarations of such variables or by jumping forward out of a compound statement where the variables are scoped), the destructors are called for all variables whose scope was exited, in the order opposite to the order of their construction.
5052017-12-14T18:16:03 <Chris_Stewart_5> maaku: so why can't we just recursively call `EvalScript` inside of VerifyScript?
5062017-12-14T18:16:21 <Chris_Stewart_5> and have a counter or whatever of how many recursive calls we have made
5072017-12-14T18:16:48 <Chris_Stewart_5> now that I re-read that i'm not sure if that made sense.
5082017-12-14T18:16:57 *** Giszmo has joined #bitcoin-core-dev
5092017-12-14T18:17:14 <maaku> (1) that would require refactoring the EvalScript API to carry extra parameters (like the alt stack) as arguments; (2) that would not be safe if/when the limitation of single-recursion is dropped
5102017-12-14T18:18:11 <maaku> this is an easier, more targetted change that enables just the functionality required without large code changes, with well defined semantics (even if the use of goto is unusal)
5112017-12-14T18:18:15 *** wxss has joined #bitcoin-core-dev
5122017-12-14T18:18:35 <sipa> why not wrap the part you're jumping over in a loop?
5132017-12-14T18:18:54 <Chris_Stewart_5> ^
5142017-12-14T18:19:02 <Chris_Stewart_5> or just recursively call EvalScript here? https://github.com/maaku/bitcoin/blob/tail-call-semantics/src/script/interpreter.cpp#L1050
5152017-12-14T18:19:44 <Chris_Stewart_5> maybe I am missing some goto functionality here, but it seems like it would be almost identical to just call EvalScritp() instead of using goto
5162017-12-14T18:20:07 <sipa> i admit there are use cases for goto, and dismissing it unconditionally is very much a cargo cult thing to do
5172017-12-14T18:20:16 <sipa> but i don't think you need it here
5182017-12-14T18:20:37 *** jadee_ has quit IRC
5192017-12-14T18:20:38 *** xmsx has quit IRC
5202017-12-14T18:20:55 <maaku> Chris_Stewart_5: look at the altstack and nOpCount variables
5212017-12-14T18:22:18 <maaku> sipa: a do-while would be equivalent, if slightly more verbose, at the additional review cost of indenting 1000 lines of code
5222017-12-14T18:22:44 <maaku> that's up to kallewoof
5232017-12-14T18:23:15 <Chris_Stewart_5> maaku: Ah ok I think i see what you are saying. C++ allows for default args right? But I guess that is still pretty unfortunate
5242017-12-14T18:23:36 <sipa> review with ?w=1 (in github) or -w (in git) makes indentation changes trivial to review
5252017-12-14T18:27:32 <maaku> sipa: I'm sure it would be a stumbling block for many still, unfortunately.
5262017-12-14T18:28:05 <sipa> maaku: i expect that a goto would be even more so
5272017-12-14T18:28:49 <sipa> the altstack trick is neat; it allows doing this without any new script versioning at all
5282017-12-14T18:28:51 <maaku> re: goto I guess it comes down to encoding semantic intent. a do {} while(!done) construct where done is a boolean variable set inside the loop under complex conditions is not a clearer encoding of the semantic intent, which is to restart execution of the function from the beginning
5292017-12-14T18:29:15 <maaku> this is why I am handing it over to kallewoof though, who will make the call on making such changes
5302017-12-14T18:29:21 <sipa> ok
5312017-12-14T18:30:34 <maaku> yes, and I have another simple soft-fork that recovers script versioning inside the witness itself, which would allow us to later remove the altstack trick without needing a new "script version" as presently defined
5322017-12-14T18:32:42 <sipa> i'm still very unconfortable with needing code execution before knowing what code is executable, though
5332017-12-14T18:33:33 <maaku> ?
5342017-12-14T18:34:34 <sipa> you don't distinguish code and data
5352017-12-14T18:35:02 <sipa> anything can be either, up to the end of the (top level) program
5362017-12-14T18:35:04 <maaku> I mean what are your concerns?
5372017-12-14T18:35:12 <sipa> static analysis
5382017-12-14T18:35:32 <maaku> (as a lisper I have no sympathy for that general concern ;) )
5392017-12-14T18:35:43 <sipa> haha
5402017-12-14T18:35:46 <maaku> static analysis of what, limits? those are gone in this iteration
5412017-12-14T18:36:51 <sipa> can you enumerate all possible code paths ahead of time?
5422017-12-14T18:36:56 *** jadee_ has joined #bitcoin-core-dev
5432017-12-14T18:39:29 *** tiagotrs has quit IRC
5442017-12-14T18:42:16 <maaku> yes
5452017-12-14T18:43:00 <maaku> I'm not sure if that's generally provable in the sense that you can show non-decidable scripts aren't possible to write
5462017-12-14T18:43:43 <maaku> but the way this is anticipated to be used, and especially with only single recursion, it is straightforward to show all possible code paths
5472017-12-14T18:43:54 <sipa> well there are certainly trivial counterexamples, like just "OP_0 OP_TOALTSTACK"
5482017-12-14T18:44:07 <sipa> which permits executing anything?
5492017-12-14T18:45:29 <maaku> I expect actual deployment to be of the form [root 1 MERKLEBRANCHVERIFY 2DROP 2DROP N*TOALTSTACK] with [argN ... arg1 script proof] as the witness
5502017-12-14T18:45:44 <maaku> it's trivial to show all code paths there -- expand the merkle tree
5512017-12-14T18:45:58 <sipa> fair enough
5522017-12-14T18:46:13 <sipa> i would just be more confortable with having that property guaranteed
5532017-12-14T18:46:32 <maaku> (actually [root 2 MERKLEBRANCHVERIFY] for anyone paying close attention)
5542017-12-14T18:47:06 <maaku> it's guaranteed in that construct, or related constructs
5552017-12-14T18:48:07 *** jadee_ has quit IRC
5562017-12-14T18:48:29 <maaku> I guess I'm not understanding why this is a concern -- is there something you are worried about? witness malleability?
5572017-12-14T18:49:03 <sipa> i'm not worried, i'm uneasy
5582017-12-14T18:49:49 <sipa> just the thought of having code be subject to other code seems so hard to reason about
5592017-12-14T18:50:27 <maaku> well keep in mind that tail recursion can only add spend conditions
5602017-12-14T18:50:52 <sipa> but counts towards sigops
5612017-12-14T18:51:34 *** jadee_ has joined #bitcoin-core-dev
5622017-12-14T18:51:41 <maaku> nope
5632017-12-14T18:51:48 <sipa> nope?
5642017-12-14T18:52:29 <maaku> tail recursion policy scripts do not add to any aggregate limits, including sigops. see bip 117
5652017-12-14T18:52:53 <sipa> ouch
5662017-12-14T18:53:34 <maaku> not really. the worst you could possibly do with a 4MB block is 30s of signature verification, which could be dropped to 1-2s with a reasonable fix
5672017-12-14T18:53:45 <maaku> so why do we maintain these limits going forward?
5682017-12-14T18:53:52 <sipa> that's utterly unacceptable
5692017-12-14T18:54:38 <maaku> it's less than other attack vectos we can't do much about, with the fix in place at least, and it costs 1 block's worth of fee income to perform
5702017-12-14T18:54:44 <jonasschnelli> sipa: when I'm scanning the UTXO set with the CCoinsViewCursor (while, cursor.Next()) is there a way to calculate the progress? Similar to your https://github.com/bitcoin/bitcoin/blob/master/src/txdb.cpp#L387?
5712017-12-14T18:55:01 <maaku> sipa: I suggest actually running the numbers and seeing how much of an issue it is for yourself
5722017-12-14T18:55:14 <sipa> maaku: *seconds* of CPU time?
5732017-12-14T18:55:20 <sipa> for a block?
5742017-12-14T18:55:49 <sipa> what other attack vectors
5752017-12-14T18:56:06 <maaku> conservative (high) estimates for a worst-case adversarially constructed block that is nothing but signature verifications
5762017-12-14T18:56:21 <maaku> I'm not sure why this is surprising You can fit 64k signatures in a 4MB block
5772017-12-14T18:57:28 <maaku> it would take a few seconds to verify 64k signatures
5782017-12-14T18:57:48 <sipa> well the concern is that you may construct signatures in less than 70ish byte per check
5792017-12-14T18:58:04 <sipa> but i guess your fix is relying on caching to avoid that
5802017-12-14T18:58:12 <sipa> which probably works
5812017-12-14T18:58:30 <maaku> or the trivial fix I alluded to above -- a per-script sigop limit of size(script+witness)/72
5822017-12-14T18:58:49 <sipa> ah, i missed that
5832017-12-14T18:59:19 <maaku> I didn't say it, but that's what I was alluding to. Might not be easy to be per-input with sigagg, but could still be a per-tx limit
5842017-12-14T18:59:40 <sipa> still, if i'm reading things correctly, it's the outer script's sigop limit that is discarded; the inner sceipt still counts?
5852017-12-14T19:00:30 <wumpus> #startmeeting
5862017-12-14T19:00:30 <lightningbot> Meeting started Thu Dec 14 19:00:30 2017 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
5872017-12-14T19:00:30 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
5882017-12-14T19:00:31 <maaku> opposite. the sigops are picked up by static analysis of the outer script, which if it only contains a NOP4 (MBV) and stack oeprations is 0
5892017-12-14T19:00:37 <jtimon> hi
5902017-12-14T19:00:48 *** jadee_ has quit IRC
5912017-12-14T19:00:54 <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag
5922017-12-14T19:00:54 <jonasschnelli> hi
5932017-12-14T19:00:56 <achow101> hi
5942017-12-14T19:01:02 <kanzure> hi.
5952017-12-14T19:01:06 <cfields> hi
5962017-12-14T19:01:19 <wumpus> #topic high priority for review
5972017-12-14T19:01:23 <wumpus> #link https://github.com/bitcoin/bitcoin/projects/8
5982017-12-14T19:01:25 <Provoostenator> hi
5992017-12-14T19:01:37 <sipa> hi
6002017-12-14T19:01:41 <luke-jr> multiwallet gui can be added back in
6012017-12-14T19:01:56 <BlueMatt> #11639
6022017-12-14T19:01:58 <gribble> https://github.com/bitcoin/bitcoin/issues/11639 | Rewrite the interface between validation and net_processing wrt DoS by TheBlueMatt · Pull Request #11639 · bitcoin/bitcoin · GitHub
6032017-12-14T19:02:04 <wumpus> I think we managed to merge two high-priority PRs this week, woohoo
6042017-12-14T19:02:15 <sipa> woohoo
6052017-12-14T19:02:32 <wumpus> now all we really want is #11403 :)
6062017-12-14T19:02:39 <gribble> https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub
6072017-12-14T19:02:40 <jnewbery> hi
6082017-12-14T19:02:48 <jonasschnelli> Added #11383 to the high prio project
6092017-12-14T19:02:50 <gribble> https://github.com/bitcoin/bitcoin/issues/11383 | Basic Multiwallet GUI support by luke-jr · Pull Request #11383 · bitcoin/bitcoin · GitHub
6102017-12-14T19:03:04 <cfields> should've named it "trivial SegWit wallet support". Those get merged quicker :)
6112017-12-14T19:03:06 *** promag has joined #bitcoin-core-dev
6122017-12-14T19:03:13 <jonasschnelli> hah
6132017-12-14T19:03:14 <wumpus> segwit wallet before multiwallet please :)
6142017-12-14T19:03:20 <promag> hi
6152017-12-14T19:03:40 <jonasschnelli> Yes. 11383 needs more reviews first
6162017-12-14T19:03:59 <achow101> I'll actually start working on #10367 again after finals this week
6172017-12-14T19:04:01 <gribble> https://github.com/bitcoin/bitcoin/issues/10367 | [test] Test abortrescan command. by kallewoof · Pull Request #10367 · bitcoin/bitcoin · GitHub
6182017-12-14T19:04:09 <achow101> *#10637
6192017-12-14T19:04:13 <gribble> https://github.com/bitcoin/bitcoin/issues/10637 | Coin Selection with Murchs algorithm by achow101 · Pull Request #10637 · bitcoin/bitcoin · GitHub
6202017-12-14T19:04:33 <BlueMatt> we're getting really close on #11281 which is also high-prio and I think also #10387
6212017-12-14T19:04:36 <BlueMatt> so thats nice
6222017-12-14T19:04:36 <wumpus> added BlueMatt #11639
6232017-12-14T19:04:36 <gribble> https://github.com/bitcoin/bitcoin/issues/11281 | Avoid permanent cs_main/cs_wallet lock during RescanFromTime by jonasschnelli · Pull Request #11281 · bitcoin/bitcoin · GitHub
6242017-12-14T19:04:38 <gribble> https://github.com/bitcoin/bitcoin/issues/10387 | Eventually connect to NODE_NETWORK_LIMITED peers by jonasschnelli · Pull Request #10387 · bitcoin/bitcoin · GitHub
6252017-12-14T19:04:40 <gribble> https://github.com/bitcoin/bitcoin/issues/11639 | Rewrite the interface between validation and net_processing wrt DoS by TheBlueMatt · Pull Request #11639 · bitcoin/bitcoin · GitHub
6262017-12-14T19:05:21 <wumpus> yep, getting there
6272017-12-14T19:05:24 <BlueMatt> ryanofsky: asked for #11687
6282017-12-14T19:05:26 <gribble> https://github.com/bitcoin/bitcoin/issues/11687 | External wallet files by ryanofsky · Pull Request #11687 · bitcoin/bitcoin · GitHub
6292017-12-14T19:06:13 <wumpus> added
6302017-12-14T19:06:21 <wumpus> but let's focus on segwit wallet please
6312017-12-14T19:06:41 <BlueMatt> yea, I mean there's also like 3 or 4 bugs on master that need fixing for 0.16...
6322017-12-14T19:06:53 <wumpus> all the other things are nice but what people really want at this point is segwit wallet
6332017-12-14T19:07:28 <wumpus> I get bothered a lot about it so I'm happy to pass it on :p
6342017-12-14T19:07:45 <wumpus> other topics?
6352017-12-14T19:08:01 *** Dizzle has joined #bitcoin-core-dev
6362017-12-14T19:08:23 * BlueMatt notes that things needed for 0.16 are at least #11888 (does not yet have pr), #11822 (pr 11824) and #11512
6372017-12-14T19:08:24 <gribble> https://github.com/bitcoin/bitcoin/issues/11888 | Prevent Opening Wallets Simultaneously in Two Instances · Issue #11888 · bitcoin/bitcoin · GitHub
6382017-12-14T19:08:24 <gribble> https://github.com/bitcoin/bitcoin/issues/11822 | Severe memory leak on current master · Issue #11822 · bitcoin/bitcoin · GitHub
6392017-12-14T19:08:26 <promag> will sipa include Qt changes in #11403?
6402017-12-14T19:08:26 <gribble> https://github.com/bitcoin/bitcoin/issues/11512 | Use GetDesireableServiceFlags in seeds, dnsseeds, fixing static seed adding by TheBlueMatt · Pull Request #11512 · bitcoin/bitcoin · GitHub
6412017-12-14T19:08:31 <wumpus> #action merge segwit wallet
6422017-12-14T19:08:32 <gribble> https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub
6432017-12-14T19:08:54 <jnewbery> Quick topic: can I shill for the Coredev tech days in New York, March 5th-7th?
6442017-12-14T19:09:07 <wumpus> #topic coredev tech announcement
6452017-12-14T19:09:09 <BlueMatt> jnewbery: I think you just did
6462017-12-14T19:09:15 <cfields> woohoo!
6472017-12-14T19:09:50 <jnewbery> I've sent invites to everyone I think contributes regularly to Bitcoin Core or lightning implementations. If you think you should have got an invite and haven't, plese message me
6482017-12-14T19:09:52 <BlueMatt> put it on your calendar! week after fc so book your flights back via ny!
6492017-12-14T19:09:59 <jonasschnelli> I think I should merge https://github.com/coredev-tech/coredev-dot-tech/pull/1
6502017-12-14T19:10:05 <achow101> is it up on coredev.tech yet?
6512017-12-14T19:10:13 <jnewbery> jonasschnelli: yes please!
6522017-12-14T19:10:13 <jonasschnelli> jnewbery: have you invited promag?
6532017-12-14T19:10:32 <jnewbery> jonasschnelli: yes
6542017-12-14T19:10:36 *** alreadylate has joined #bitcoin-core-dev
6552017-12-14T19:11:19 <promag> yes he did
6562017-12-14T19:11:20 <jnewbery> that's all my shilling :)
6572017-12-14T19:11:35 <luke-jr> proposed topic: status of meeting summaries on the website
6582017-12-14T19:11:45 <jonasschnelli> Thanks for organising jnewbery! To bad I can't attend....
6592017-12-14T19:12:20 <maaku> jnewbery: New York is a big place. Where is it?
6602017-12-14T19:12:20 <wumpus> BlueMatt: seems they were already tagged for 0.16 except #11824
6612017-12-14T19:12:22 <gribble> https://github.com/bitcoin/bitcoin/issues/11824 | Block ActivateBestChain to empty validationinterface queue by TheBlueMatt · Pull Request #11824 · bitcoin/bitcoin · GitHub
6622017-12-14T19:12:32 <sipa> that needs tagging
6632017-12-14T19:12:32 <jnewbery> sorry jonas :(
6642017-12-14T19:12:34 <jonasschnelli> jnewbery: keep the location discolued
6652017-12-14T19:12:38 <luke-jr> maaku: "We're still working on final confirmation for the location, but it's almost certain to be in Lower Manhattan, close to The Battery."
6662017-12-14T19:12:39 <jonasschnelli> *disclosed
6672017-12-14T19:12:42 <luke-jr> oops
6682017-12-14T19:12:43 <wumpus> better to send the address in private
6692017-12-14T19:12:53 <BlueMatt> wumpus: yes, I'm aware, I was pointing out that those three are issues which fix current master bugs ie are blocking 0.16, unlike much of the 0.16 tagged things
6702017-12-14T19:12:58 <maaku> "Lower Manhatten, close to The Battery" was all I was looking for
6712017-12-14T19:12:58 <luke-jr> hopefully that wasn't too much detail
6722017-12-14T19:13:16 <wumpus> BlueMatt: yeah if there's things tagged 0.16 that shouldn't be, let me know
6732017-12-14T19:13:22 <wumpus> BlueMatt: I'll bump them to 0.17
6742017-12-14T19:13:34 <BlueMatt> "whatever makes it in", right? :p
6752017-12-14T19:14:03 <instagibbs> oh meeting, hi
6762017-12-14T19:14:09 <wumpus> yes, but if it shouldn't hold up the release it shouldn't really be tagged w/ specific release
6772017-12-14T19:14:21 <jtimon> so after #11403 gets merged, what's the timeline for "whatever makes it in" ?
6782017-12-14T19:14:27 <gribble> https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub
6792017-12-14T19:14:28 *** TheSadFace has joined #bitcoin-core-dev
6802017-12-14T19:14:30 <luke-jr> wumpus: then why tag anything? :p
6812017-12-14T19:14:59 <BlueMatt> wumpus: heh, ok, so lets see, untag 7664, 7729, 7949, 7955, 8501, 9502, 9728....yea, pretty much everything there
6822017-12-14T19:14:59 *** bule has joined #bitcoin-core-dev
6832017-12-14T19:15:00 <wumpus> after 11403 makes it in we should go to bugfixing only
6842017-12-14T19:15:14 <luke-jr> even Segwit wallet is a "early release trigger", not a blocker ;)
6852017-12-14T19:15:19 <jtimon> wumpus: I see
6862017-12-14T19:15:31 <BlueMatt> most 0.16-tagged things really dont need a tag
6872017-12-14T19:15:35 <sipa> wumpus: i guess that means we shouldn't have tags for future releases
6882017-12-14T19:15:42 <sipa> only for backport branches
6892017-12-14T19:15:54 <BlueMatt> we should just have a "fixes current master bug" tag which has to be cleared for each release
6902017-12-14T19:15:54 <wumpus> sipa: unless they're bugfixes that really need to get in
6912017-12-14T19:16:05 <BlueMatt> or i guess stop tagging things that dont fit into that category
6922017-12-14T19:16:08 <jonasschnelli> Mabe a tag for "aims for next release"?
6932017-12-14T19:16:13 <wumpus> well, github has milestones, not 'current master'
6942017-12-14T19:16:23 <BlueMatt> jonasschnelli: doesnt everything aim for next release?
6952017-12-14T19:16:25 <wumpus> at least now they will stick which is useful for historical reference
6962017-12-14T19:16:29 <BlueMatt> i mean occasionally not, but its rare
6972017-12-14T19:16:38 <jonasschnelli> BlueMatt: that is a good questions... or "candidate for next release"?
6982017-12-14T19:17:02 <wumpus> the 'future' milestone is for unlikely things that need a lot more work
6992017-12-14T19:17:18 <wumpus> so probably not next release
7002017-12-14T19:18:03 <gmaxwell> release candidate on tuesday then?
7012017-12-14T19:18:05 <sipa> wumpus: perhaps a tag "release blocker" rather than a spdcific version milestone is better for those?
7022017-12-14T19:18:05 <jonasschnelli> Usually agile development works with "priorities"..
7032017-12-14T19:18:05 <luke-jr> jonasschnelli: everything is a candidate if it gets enough review ;p
7042017-12-14T19:18:10 *** jadee_ has joined #bitcoin-core-dev
7052017-12-14T19:18:17 <wumpus> sipa: I prefer a milestone, we have too many tags already
7062017-12-14T19:18:20 <sipa> ok
7072017-12-14T19:18:21 *** owowo has quit IRC
7082017-12-14T19:18:23 <wumpus> sipa: at least this is displayed in a different place
7092017-12-14T19:18:39 <luke-jr> jonasschnelli: that assumes someone gets to decide priorities for other people
7102017-12-14T19:18:40 <sipa> right
7112017-12-14T19:18:42 <wumpus> ok, any real topics?
7122017-12-14T19:18:56 <jonasschnelli> luke-jr: Yes. Agree. It's kinda impossible
7132017-12-14T19:19:04 <wumpus> luke-jr: we have 'high priority' which we already discuss every week
7142017-12-14T19:19:11 <wumpus> there's no point in other priorities really
7152017-12-14T19:19:12 <luke-jr> [19:11:35] <luke-jr> proposed topic: status of meeting summaries on the website
7162017-12-14T19:19:25 <luke-jr> wumpus: sure, just pointing out it has its limits
7172017-12-14T19:19:28 <wumpus> #topic meeting summaries
7182017-12-14T19:19:32 <gmaxwell> I've been seeing highish connection counts, appears to be organic. Non-listening nodes appear to have grown a lot in the last three months.
7192017-12-14T19:19:51 <achow101> luke-jr: what about the meeting summaries
7202017-12-14T19:19:58 <gmaxwell> Who called this meeting?
7212017-12-14T19:20:40 <sipa> ?
7222017-12-14T19:20:45 <luke-jr> I don't actually know what's up with meeting summaries, but the last one was 2 months ago (with a huge gap before that), and people are wondering
7232017-12-14T19:20:55 <achow101> TheSadFace is the person I got to write them
7242017-12-14T19:21:03 <achow101> he's been doing them slowly
7252017-12-14T19:21:06 <BlueMatt> https://github.com/bitcoin-core/bitcoincore.org/pulls
7262017-12-14T19:21:14 <BlueMatt> I mean there are ones sitting there ready to merge
7272017-12-14T19:21:18 <BlueMatt> so...that sounds like a first step
7282017-12-14T19:21:37 <TheSadFace> Hello everyone, yeah sorry about how slow it's going... After finals I plan to catch up to the present time
7292017-12-14T19:21:44 <achow101> the last few weeks have been slightly busy because of exams, so meeting notes haven't really gotten written. but hopefully a bunch will be written in the next few weeks
7302017-12-14T19:21:45 <wumpus> oh right I'm allowed to merge things on the bitcoincore.org site now
7312017-12-14T19:21:48 <wumpus> :D
7322017-12-14T19:22:01 <BlueMatt> lol after you broke the site!
7332017-12-14T19:22:10 <luke-jr> ok, so basically it's taken care of, just a matter of time
7342017-12-14T19:22:14 <achow101> luke-jr: yes
7352017-12-14T19:22:30 <TheSadFace> luke-jr: Yeah just had a crazy last bit of the semester
7362017-12-14T19:22:31 <wumpus> well the site was still working :)
7372017-12-14T19:22:36 <Provoostenator> I think just posting the chat log quickly after the meeting is better than nothing.
7382017-12-14T19:22:47 <sipa> TheSadFace: very happy that someone's doing that
7392017-12-14T19:22:49 <wumpus> Provoostenator: the bot uploads the chat log
7402017-12-14T19:22:53 <sipa> even if it takes a while
7412017-12-14T19:23:14 <wumpus> e.g. http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-12-07-19.00.log.html for last meeting
7422017-12-14T19:23:16 <Provoostenator> But those don't show up here: https://bitcoincore.org/en/meetings/
7432017-12-14T19:23:25 <TheSadFace> sipa: Thanks!
7442017-12-14T19:23:32 *** owowo has joined #bitcoin-core-dev
7452017-12-14T19:23:34 <Provoostenator> For the RSS folks out there...
7462017-12-14T19:23:42 <wumpus> TheSadFace: yes, thanks a lot
7472017-12-14T19:23:55 <luke-jr> Provoostenator: wouldn't that make RSS more complex? if it shows up with the log, but then the summary added later.,.
7482017-12-14T19:23:56 <achow101> Provoostenator: "To view more recent logs, all meeting logs and raw minutes can be found here."
7492017-12-14T19:24:00 <bitcoin-git> [bitcoin] instagibbs opened pull request #11900: [policy] simplify CheckMinimalPush checks, add safety assert (master...checkminimal) https://github.com/bitcoin/bitcoin/pull/11900
7502017-12-14T19:24:02 <achow101> here links to http://www.erisian.com.au/meetbot/bitcoin-core-dev/
7512017-12-14T19:24:04 *** jadee_ has quit IRC
7522017-12-14T19:24:05 <Provoostenator> It might be better to just always generate a post on /meetings, edit the post later.
7532017-12-14T19:24:26 <luke-jr> I don't personally use RSS, but I would imagine it would be better if the post only showed when the summary is done
7542017-12-14T19:24:40 <luke-jr> otherwise people will try to read, see no summary, and forget to go back later
7552017-12-14T19:25:00 <Provoostenator> True, maybe have a second RSS feed with just the logs?
7562017-12-14T19:25:07 <Provoostenator> For people who want them fast.
7572017-12-14T19:25:20 <achow101> also, who owns the meetbot and the site where all of the meeting logs and stuff go?
7582017-12-14T19:25:26 <wumpus> aj does
7592017-12-14T19:25:29 <luke-jr> why not they just connect to the webchat? :P
7602017-12-14T19:25:33 * aj waves
7612017-12-14T19:25:40 <MarcoFalke> Provoostenator: Scroll back on botbot?
7622017-12-14T19:25:48 *** pkx2 has quit IRC
7632017-12-14T19:26:19 *** pkx2 has joined #bitcoin-core-dev
7642017-12-14T19:26:38 <cfields> very quick topic suggestion: toolchain builder progress
7652017-12-14T19:26:42 *** jadee_ has joined #bitcoin-core-dev
7662017-12-14T19:26:50 <wumpus> #topic toolchain builder progress
7672017-12-14T19:26:50 <luke-jr> actually, maybe we should link the webchat on the page?
7682017-12-14T19:27:04 <wumpus> is a read-only link to the webchat possible?
7692017-12-14T19:27:06 <cfields> i'm knee-deep in compiler builds. slowly taking shape. that is all :)
7702017-12-14T19:27:09 <BlueMatt> pr in time for 0.16 to replace gitian for 0.16, right?
7712017-12-14T19:27:09 <wumpus> if not, please don't do it
7722017-12-14T19:27:22 <cfields> heh
7732017-12-14T19:27:25 <achow101> wumpus: could link to botbot which is read only
7742017-12-14T19:27:27 *** StopAndDecrypt_ has joined #bitcoin-core-dev
7752017-12-14T19:27:29 <wumpus> achow101: +1
7762017-12-14T19:27:43 <luke-jr> wait, replacing gitian? :/
7772017-12-14T19:27:52 *** Murch has joined #bitcoin-core-dev
7782017-12-14T19:28:17 <cfields> first step will just be a toolchain that we use in gitian rather than whatever ubuntu ships
7792017-12-14T19:28:33 *** StopAndDecrypt has quit IRC
7802017-12-14T19:28:40 <cfields> that will mean that we can very easily use whatever compilers/versions we want for gitian/travis
7812017-12-14T19:28:45 <wumpus> that would help in cases like we have with ubuntu 16.04, where the mingw64 compiler is completely broken
7822017-12-14T19:28:55 *** intcat has quit IRC
7832017-12-14T19:28:57 <cfields> right
7842017-12-14T19:29:09 <sipa> wow, even in travis?
7852017-12-14T19:29:13 *** jadee_ has quit IRC
7862017-12-14T19:29:19 <Chris_Stewart_5> cfields: nice!
7872017-12-14T19:29:42 <cfields> after that, I'd like to discuss something more long-term. But replacing Gitian would still be a long way away
7882017-12-14T19:29:53 <luke-jr> within gitian sgtm, although hopefully only as-needed for Travis since it's already slow
7892017-12-14T19:29:55 <BlueMatt> #link http://vxer.org/lib/pdf/Reflections%20on%20Trusting%20Trust.pdf
7902017-12-14T19:30:16 <gmaxwell> luke-jr: the would it be slow in travis? it would get cached.
7912017-12-14T19:30:34 <cfields> luke-jr: the idea would be to host our toolchains somewhere, so that travis just pulls them like anything else
7922017-12-14T19:30:40 <cfields> right
7932017-12-14T19:30:49 *** intcat has joined #bitcoin-core-dev
7942017-12-14T19:30:57 <BlueMatt> will this make bitcoin core the first open source project to do releases using the 1984-suggested toolchain system? =D
7952017-12-14T19:31:18 <sipa> BlueMatt: we don't ship with our own CPU microcode yet :(
7962017-12-14T19:31:22 <cfields> gmaxwell: also, the clang/gcc thing is kinda moot. We'll want to build them with each-other anyway, so going clang-only wouldn't make things any easier
7972017-12-14T19:31:28 <wumpus> 1984 toolchain system doesn't have a good ring to it
7982017-12-14T19:31:29 <luke-jr> sipa: yet.
7992017-12-14T19:31:29 <BlueMatt> sipa: lol, ok, fair
8002017-12-14T19:31:45 <BlueMatt> wumpus: all the better to spy on you with
8012017-12-14T19:31:52 <wumpus> BlueMatt: :D
8022017-12-14T19:32:39 <achow101> is the goal to eventually get rid of gitian?
8032017-12-14T19:32:44 <gmaxwell> BlueMatt: IIRC diverse double compilation was not suggested by KT.
8042017-12-14T19:32:53 <cfields> BlueMatt: heh yes. The initial toolchain will likely take ages and ages to build. But after it's done once, updates are quick and easy
8052017-12-14T19:33:02 <luke-jr> achow101: I would hope not. Gitian is handy.
8062017-12-14T19:33:03 <wumpus> good to hear you're making progress cfields
8072017-12-14T19:33:07 <BlueMatt> gmaxwell: oh? how did I get that confused...who suggested it?
8082017-12-14T19:33:24 <luke-jr> achow101: at least not unless there's an alternative that isn't Bitcoin/Core-specific
8092017-12-14T19:33:28 <achow101> luke-jr: same, although it does need a bit of fixing I think
8102017-12-14T19:33:35 <gmaxwell> KT made the problem statement, I don't think DDC was suggested until david wheeler's thesis in the mid-oughts.
8112017-12-14T19:33:43 <BlueMatt> ah, ok
8122017-12-14T19:34:07 <wumpus> I think abstractly gitian as a launcher for deterministic containers that build is a good concept
8132017-12-14T19:34:24 <luke-jr> (and also not distro-specific ;)
8142017-12-14T19:35:14 <jtimon> what would be the advantageof getting rid of gitian?
8152017-12-14T19:35:16 <wumpus> it does have too much overhead (runnig a full ubuntu VM inside, which upgrades everyt ime), and is pretty hard to initially set up
8162017-12-14T19:35:52 <cfields> wumpus: agreed that the concept is good. It's just got lots of rough edges
8172017-12-14T19:36:00 <wumpus> the advantage is not in getting rid in it, but building something better
8182017-12-14T19:36:08 <luke-jr> wumpus: even making the updates persistent might be an improvement there
8192017-12-14T19:36:10 <achow101> I think that setting up a new gitian environment has been slowly getting harder
8202017-12-14T19:36:12 *** intcat has quit IRC
8212017-12-14T19:36:29 <cfields> luke-jr: with the toolchain stuff done, we won't need to do the updates anymore
8222017-12-14T19:36:40 <cfields> it'll be distro-agnostic
8232017-12-14T19:36:47 <wumpus> cfields: what about the windows installer stuff
8242017-12-14T19:37:04 <luke-jr> building NSIS should be trivial I'd think
8252017-12-14T19:37:06 <wumpus> cfields: I mean NSIS - we should probably build that too, then
8262017-12-14T19:37:12 <wumpus> oh no building NSIS is not trivial :(
8272017-12-14T19:37:13 <luke-jr> Gentoo has an ebuild, so just port that
8282017-12-14T19:37:29 <cfields> wumpus: right, i haven't gotten that far yet. But I suspect we'll just need to suck it up and build it
8292017-12-14T19:37:33 <wumpus> the problem is that it's a mix of cross compield windows code and native code, and has a sucky build system
8302017-12-14T19:38:13 <wumpus> yes
8312017-12-14T19:38:18 <luke-jr> correction: Gentoo *used* to have an ebuild :x
8322017-12-14T19:38:19 <cfields> have no alternatives cropped up in the last ~10 years?
8332017-12-14T19:38:27 <wumpus> using the one in 12.04 isn't acceptable anymore at least
8342017-12-14T19:38:33 <wumpus> eh, 14.04
8352017-12-14T19:38:52 <luke-jr> I have a copy of the last ebuild in my overlay, it's only 111 lines
8362017-12-14T19:39:17 <cfields> luke-jr: that assumes you already have scons built and working
8372017-12-14T19:39:22 <wumpus> windows has a native installer db system that would be preferable to use
8382017-12-14T19:39:33 <wumpus> but porting the installer over to that would be... work
8392017-12-14T19:39:40 <luke-jr> yes :p
8402017-12-14T19:40:43 <cfields> well we can always take the toolchain stuff but still rely on a few bits and pieces from ubuntu until we get it all worked out
8412017-12-14T19:40:49 <wumpus> sure
8422017-12-14T19:41:05 <luke-jr> doesn't the toolchain stuff depend on a native autotools/make anyway?
8432017-12-14T19:41:10 <luke-jr> what harm in using native scons?
8442017-12-14T19:41:20 <wumpus> ah yes window's own system is msi
8452017-12-14T19:41:31 <cfields> luke-jr: depends how deep we want to go
8462017-12-14T19:41:51 <wumpus> thinking of it, might not be that easy to make those in cross-build
8472017-12-14T19:41:55 <maaku> wumpus: building a gitian vm can be easily scriptable. I had vagrant scripts for doing this since 2013, but weren't upstreamed out of lack of interest
8482017-12-14T19:42:17 *** intcat has joined #bitcoin-core-dev
8492017-12-14T19:42:20 <wumpus> maaku: there is a script for that now
8502017-12-14T19:42:21 <maaku> maintaining a script to construct a gitian vm solves the accessibilty problem (and gets more people using gitian)
8512017-12-14T19:42:40 <cfields> wumpus: msi's? IIRC gnu ld can target them, at least
8522017-12-14T19:43:02 <sipa> i also have brief libsecp256k1 update
8532017-12-14T19:43:07 <wumpus> contrib/gitian-build.sh
8542017-12-14T19:43:22 <wumpus> cfields: ok, so if we can get someone to make a msi installer for us, we could use that instead
8552017-12-14T19:43:22 <achow101> maaku: unfortunately sometimes gitian doesn't get setup even with a script
8562017-12-14T19:43:33 <achow101> it might fail at some random point in the process for some unknown reason
8572017-12-14T19:43:39 <cfields> wumpus: sure, something to look into
8582017-12-14T19:43:42 <wumpus> the problem is that it has a lot to accomodate, because setting up the kvm/lxc is slightly different on differnt systems
8592017-12-14T19:44:01 *** alx has joined #bitcoin-core-dev
8602017-12-14T19:44:04 <wumpus> anyhow we'll figure it out, time for next topic
8612017-12-14T19:44:04 <wumpus> #topic libsecp256k1 update (sipa)
8622017-12-14T19:44:11 <luke-jr> doesn't KVM just work on all modern systems?
8632017-12-14T19:44:24 <wumpus> luke-jr: not inside VMs
8642017-12-14T19:44:27 <cfields> luke-jr: nested is a pain
8652017-12-14T19:44:29 <sipa> in the past week we've finally merged multi-multiplication support in libsecp256k1: https://github.com/bitcoin-core/secp256k1/pull/486
8662017-12-14T19:44:38 <maaku> wumpus: which is why you outsource the vm maintenance to an existing cross-platform vm management tool, like vagrant, and then do lxc-gitian within that vm
8672017-12-14T19:44:56 <jonasschnelli> sipa; what are the benefits?
8682017-12-14T19:45:04 <achow101> sipa: that's the pippenger thing?
8692017-12-14T19:45:05 <sipa> this is the low-level functionality for efficiently computing a*A + b*B + c*C + ..., with a,b,c scalars and A,B,C points
8702017-12-14T19:45:20 <sipa> it is not exposed currently (except for tests and benchmarks)
8712017-12-14T19:45:22 <cfields> ah, nice :)
8722017-12-14T19:45:34 <sipa> but it's the basis for efficiently building signature aggregation, batch validation, bulletproofs, ...
8732017-12-14T19:45:47 <jonasschnelli> nice
8742017-12-14T19:46:14 <wumpus> maaku: ok, maybe discuss with cfields
8752017-12-14T19:46:37 <wumpus> sipa: congrats!
8762017-12-14T19:46:50 <sipa> it doesn't currently affect anything in bitcoin, but i thought about mentioning it here as it's under the bitcoin-core repo and all that
8772017-12-14T19:47:20 <cfields> sipa: how do you picture that working with threading?
8782017-12-14T19:47:36 <cfields> batches of batches?
8792017-12-14T19:47:50 <sipa> cfields: split up the problem in N parts, run each part on one thread, and add the results together
8802017-12-14T19:47:59 <cfields> (I realize that's still a ways out)
8812017-12-14T19:48:03 <cfields> roger
8822017-12-14T19:48:19 <sipa> there are algorithms to actually be more efficient than that, but they need high communication across threads
8832017-12-14T19:48:24 <sipa> which may or may not be worth it
8842017-12-14T19:48:35 <sipa> (and be much harder to do API-wise)
8852017-12-14T19:48:48 *** Randolf has quit IRC
8862017-12-14T19:48:56 <wumpus> one step at a time
8872017-12-14T19:49:04 <sipa> anyway, thanks to andytoshi and nickler, and peterdettman who all contributed optimizations
8882017-12-14T19:49:31 *** alx has quit IRC
8892017-12-14T19:49:46 <michagogo> Sorry I'm late. IIRC a while back I made a gitian-building appliance with video instructions for recreating it from scratch
8902017-12-14T19:49:47 <cfields> nice work
8912017-12-14T19:50:00 <sipa> and of course gmaxwell for all imput and discussions :)
8922017-12-14T19:50:05 <sipa> *input
8932017-12-14T19:50:27 <achow101> sipa: so what do we need to be able to use this in Bitcoin?
8942017-12-14T19:50:49 <sipa> achow101: ECDSA can't really take advantage of it in its current form
8952017-12-14T19:50:51 <michagogo> (Wow, apparently that was over a year ago: https://1drv.ms/f/s!AvCguGMVwWzLgxJPeXdvaQVJ2WJq )
8962017-12-14T19:50:52 <cfields> a use-case
8972017-12-14T19:51:17 <BlueMatt> ok, any last-minute topics/
8982017-12-14T19:51:18 <BlueMatt> ?
8992017-12-14T19:51:33 <gmaxwell> well I tried to talk about connection slot saturation earlier.
9002017-12-14T19:51:34 <sipa> achow101: slightly modified ECDSA would permit batch validation, but there's no reason to choose that over some form of Schnorr-based signatures
9012017-12-14T19:51:37 <maaku> achow101: bitcoin doesn't do multi-generator arithmetic
9022017-12-14T19:51:57 <maaku> but it's useful for CT/CA
9032017-12-14T19:52:16 <achow101> oh, ok. cool.
9042017-12-14T19:52:19 <BlueMatt> gmaxwell: was there much to discuss? thanks for the notice, encourage people to run nodes/increase -maxconnections if possible?
9052017-12-14T19:52:36 <sipa> </endtopic>
9062017-12-14T19:52:37 <gmaxwell> We need to start looking into reenabling some kind of port forwarding I think.
9072017-12-14T19:52:42 <wumpus> so does anyone really get a lot of connections?
9082017-12-14T19:52:51 <gmaxwell> the number of non-listning nodes as increased by 50% in the last six months.
9092017-12-14T19:53:03 <wumpus> I have maxconnections at 500 on one node and have never got more than 100
9102017-12-14T19:53:15 <achow101> wumpus: I have 120 right now
9112017-12-14T19:53:16 <sipa> i'm at 124 connections
9122017-12-14T19:53:18 <gmaxwell> wumpus: when I was commenting a day ago I had confirmations of >110 on 6 nodes.
9132017-12-14T19:53:19 <Provoostenator> Are we sure UDNP works?
9142017-12-14T19:53:20 <wumpus> on the other node I'm happy to get more than 10
9152017-12-14T19:53:31 *** Murch has quit IRC
9162017-12-14T19:53:32 <achow101> Provoostenator: it's currently disabled by default
9172017-12-14T19:53:45 <sipa> Provoostenator: UPNP?
9182017-12-14T19:53:47 <gmaxwell> you'll see less if you're in a /16 with many other nodes in it.
9192017-12-14T19:53:51 <jonasschnelli> does NODE_NETWORK_LIMITED helps in this case?
9202017-12-14T19:53:58 <sipa> jonasschnelli: perhaps!
9212017-12-14T19:54:05 <wumpus> well the netherlands has lots of nodes so I've heard :-)
9222017-12-14T19:54:08 <gmaxwell> probably not much.
9232017-12-14T19:54:14 <Provoostenator> sipa: that one
9242017-12-14T19:54:18 *** Murch has joined #bitcoin-core-dev
9252017-12-14T19:54:19 <wumpus> they're not *all* mine :p
9262017-12-14T19:54:55 <gmaxwell> Running short on inbounds is the reasonable and expected outcome from not having automatic port forwarding... it's obviously not critical currently, but I think it's becoming more important.
9272017-12-14T19:55:12 <achow101> gmaxwell: do you think it would be safe to re-enable UPnP?
9282017-12-14T19:55:14 <Provoostenator> Maybe BitcoinQT can encourage users to use UPnP with a little nag?
9292017-12-14T19:55:21 <achow101> IIRC it was disabled because of vulnerabilities
9302017-12-14T19:55:27 <luke-jr> Provoostenator: better to just make it default then..
9312017-12-14T19:55:27 <wumpus> any plans for bitcoin over udp? much easier to port fw there
9322017-12-14T19:55:31 <gmaxwell> achow101: bleh. I dunno. that codebase sucks.
9332017-12-14T19:55:49 <wumpus> yes, UPNP is not going to be enabled by default again as long as I have a say, I have no confidence in that codebase
9342017-12-14T19:55:53 <gmaxwell> achow101: but there are other portforwarding protocols that we could support that are simple.
9352017-12-14T19:56:05 <BlueMatt> I believe wumpus has investigated it the most, sadly :(
9362017-12-14T19:56:06 <luke-jr> wumpus: what if someone ports it to another UPnP lib? (are there any good ones?)
9372017-12-14T19:56:16 *** Kozuch has quit IRC
9382017-12-14T19:56:35 *** clarkmoody has joined #bitcoin-core-dev
9392017-12-14T19:56:42 <Provoostenator> Without UPnP, we could at least show some instructions that they need to perform the port forwarding ritual.
9402017-12-14T19:56:50 <wumpus> wasn't there a better replacement for upnp gmaxwell?
9412017-12-14T19:57:07 <luke-jr> other protocols won't help with routers being UPnP..
9422017-12-14T19:57:11 <gmaxwell> Yes, there are several.
9432017-12-14T19:57:12 <wumpus> something that didn't rely on variable buffers and xml parsing
9442017-12-14T19:57:21 *** TheSadFace has quit IRC
9452017-12-14T19:57:28 <jonasschnelli> Provoostenator: a "connectable" green/read flag and some instruction is probably simple
9462017-12-14T19:57:32 <gmaxwell> not as widely supported as UPNP but e.g. all apple networking appliances support the one whos name I can't remember.
9472017-12-14T19:57:43 <cfields> Bonjour?
9482017-12-14T19:57:45 <gmaxwell> where the protocol is just a trivial struct sent over usp.
9492017-12-14T19:57:54 <jonasschnelli> Bonjour is mDNS (that is different)
9502017-12-14T19:57:56 <sipa> DLNA?
9512017-12-14T19:58:22 <gmaxwell> I'm thinking of NAT-PMP
9522017-12-14T19:58:23 <Provoostenator> As well as a P2P message like "please try to connect to me", so it's easier to see if the port is open?
9532017-12-14T19:58:26 <luke-jr> does anyone actually use Apple networking appliances? :/
9542017-12-14T19:58:28 <sipa> ah yes, that
9552017-12-14T19:58:36 *** pkx2 has quit IRC
9562017-12-14T19:58:53 <wumpus> NAT-PMP is quite common these days, not only in apple
9572017-12-14T19:58:56 <gmaxwell> luke-jr: yes, though I'm sure they're not the most popular... NAT-PMP has support beyond apple of course.
9582017-12-14T19:59:05 <Provoostenator> The current instruction says "go to 21 and enter your IP there"
9592017-12-14T19:59:10 *** alreadylate has quit IRC
9602017-12-14T19:59:12 <gmaxwell> I just mentioned apple as a concrete example that it is widely supported.
9612017-12-14T19:59:13 <luke-jr> would be nice to find a quality library that can do both
9622017-12-14T19:59:18 <sipa> Provoostenator: ?
9632017-12-14T19:59:23 <gmaxwell> Provoostenator: wtf? what "the current instructions" say that?
9642017-12-14T19:59:49 <gmaxwell> luke-jr: there is not really a reason for a library for nat-pmp. You send a dozen byte packet over UDP.
9652017-12-14T19:59:50 <wumpus> I'd be ok with NAT-PMP on by default
9662017-12-14T20:00:01 <gmaxwell> And if you want to know your IP you listen for a similarly structured dozen by UDP reply.
9672017-12-14T20:00:09 <achow101> gmaxwell: I think Provoostenator is talking about https://bitcoin.org/en/full-node#port-forwarding
9682017-12-14T20:00:23 <wumpus> but no C/C++ xml parser crap again please
9692017-12-14T20:00:33 <wumpus> we've pretty much dodged a bullet last time
9702017-12-14T20:00:37 <BlueMatt> achow101: oh ffs, can we get that fixed?
9712017-12-14T20:00:41 <Provoostenator> (trying to find where I saw that)
9722017-12-14T20:00:44 <BlueMatt> <dong>
9732017-12-14T20:00:49 <wumpus> #endmeeting
9742017-12-14T20:00:49 <lightningbot> Meeting ended Thu Dec 14 20:00:49 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
9752017-12-14T20:00:49 <lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-12-14-19.00.html
9762017-12-14T20:00:49 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-12-14-19.00.txt
9772017-12-14T20:00:49 <lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-12-14-19.00.log.html
9782017-12-14T20:00:52 <gmaxwell> So in any case, we should look into it more. I don't think we need something as widespread (and poorly implemented) as UPNP.
9792017-12-14T20:00:55 <luke-jr> gmaxwell: that explains why I didn't see any libs :P
9802017-12-14T20:00:56 <luke-jr> maaku: VM maintenance is exactly what gitian is handy for.. vagrant on the other hand has a ton of deps, one of which is non-free :/
9812017-12-14T20:01:17 <jonasschnelli> sipa: when I'm scanning the UTXO set with the CCoinsViewCursor (while, cursor.Next()) is there a way to calculate the progress? Similar to your https://github.com/bitcoin/bitcoin/blob/master/src/txdb.cpp#L387?
9822017-12-14T20:01:18 <gmaxwell> I think NAT-PMP would probably help a lot and wouldn't be a risk.
9832017-12-14T20:01:32 <sipa> jonasschnelli: you can assume the txids and uniformly distributed
9842017-12-14T20:01:36 <wumpus> not sure if I ever made it public, but I could own every bitcoin node starting up in a LAN
9852017-12-14T20:01:37 <achow101> Provoostenator: this: https://bitcoin.org/en/full-node#testing-connections
9862017-12-14T20:01:42 <achow101> I think that's what you were looking for
9872017-12-14T20:01:50 <cfields> wumpus: yikes!
9882017-12-14T20:01:54 <sipa> maaku: multi-multiplication is useful even for cryptographic systems that don't use multiple generators
9892017-12-14T20:01:55 <Provoostenator> achow101 yes
9902017-12-14T20:02:10 <Provoostenator> So now they just need some browser fingerprinting et voila.
9912017-12-14T20:02:22 <sipa> maaku: e.g. Schnorr batch validation
9922017-12-14T20:02:28 <Provoostenator> Next time you go to a shop, they'll offer you a bitcoin payment option. Super convenient!
9932017-12-14T20:02:31 <jonasschnelli> sipa: thanks...
9942017-12-14T20:02:37 <jonasschnelli> wumpus: oh.. due to UPnP?
9952017-12-14T20:02:40 <achow101> wumpus: how so?
9962017-12-14T20:02:50 <wumpus> cfields: was a combination of a heartbleed-like leak (to get the ASLR addresses) and the known vulnerability, both are patched now in any case
9972017-12-14T20:02:51 <gmaxwell> sipa: in fact it would be perfectly useful in bitcoin for batch validation if but for the ecda reduction of R.x mod P and the lack of R's sign.
9982017-12-14T20:03:19 <sipa> jonasschnelli: so take the top 64 bits of the txid, and convert it to a double... that should increase at a constant rate
9992017-12-14T20:03:35 <maaku> luke-jr: there are alternatives to vagrant, but I think you missed the point. use a vagrant-like tool to make a linux vm (centos, ubuntu, I don't care). on THAT system make the gitian VM using the usual scripts
10002017-12-14T20:03:54 <gmaxwell> do not just cast the bits to a double, as that could constract signaling nans and other baddness.
10012017-12-14T20:04:04 <wumpus> achow101: there was a buffer overflow bug in the miniupnp library at some point, don't have the CVE at hand
10022017-12-14T20:04:21 *** intcat has quit IRC
10032017-12-14T20:04:24 <sipa> gmaxwell: it also wouldn't work
10042017-12-14T20:04:28 <gmaxwell> There was more than one. We'd previously noted that the code smelled.
10052017-12-14T20:04:29 <jonasschnelli> sipa: int percentageDone = (int)(high * 100.0 / 65536.0 + 0.5) (can you explain why 65536.0 + 0.5?)
10062017-12-14T20:04:52 <cfields> maaku: that's pretty much Gitian's utility though. I'd argue that if you need a vm builder to run the vm builder, one of them needs some love :)
10072017-12-14T20:04:56 <sipa> jonasschnelli: i assume that's just looking at the top 16 bits?
10082017-12-14T20:05:05 <sipa> jonasschnelli: 16 bits have 65536 possibilities
10092017-12-14T20:05:07 <luke-jr> Gentoo let the CVE sit until just a few weeks ago. My workaround was to depend on the fixed version explicitly. :/
10102017-12-14T20:05:10 <sipa> 0.5 is for rounding
10112017-12-14T20:05:14 <jonasschnelli> sipa: okay. I see
10122017-12-14T20:05:15 <luke-jr> anyhow, bbl
10132017-12-14T20:05:39 *** intcat has joined #bitcoin-core-dev
10142017-12-14T20:05:48 <maaku> cfields: how is that gitian's utility? I'm not sure why it should be our business to maintain the gitian setup procedure on every development environment out there
10152017-12-14T20:06:18 <wumpus> the vuln was: TALOS-2015-0035 (CVE-2015-6031)
10162017-12-14T20:06:37 <wumpus> had to badger ubuntu day in day out to put up an updated libupnpc library
10172017-12-14T20:06:56 <sipa> badger badger badger
10182017-12-14T20:07:13 <wumpus> bitcoin wasn't the only affected program, but one of the worst, because it had the upnp structures on the stack
10192017-12-14T20:07:59 *** Kozuch has joined #bitcoin-core-dev
10202017-12-14T20:08:01 *** tiagotrs has joined #bitcoin-core-dev
10212017-12-14T20:08:27 <achow101> what if we just removed UPnP entirely? It's not like people actually seem to be using it.
10222017-12-14T20:08:47 <cfields> maaku: right, Gitian's tasked with abstracting that away. But in reality it only behaves on Linux environments that look as it expects. If something like vagrant/docker/etc. does it better, it may make sense to outsource some of it.
10232017-12-14T20:08:48 <wumpus> sure, but please implement an alternative first
10242017-12-14T20:09:05 <wumpus> NAT-PMP is great but someone has to do it :)
10252017-12-14T20:09:17 <gmaxwell> achow101: I think we need at least some kind of internal traversal, perhaps NAT-PMP is enough.
10262017-12-14T20:12:12 *** LeMiner2 has joined #bitcoin-core-dev
10272017-12-14T20:12:31 <wumpus> I'll create an issue for it
10282017-12-14T20:13:20 *** LeMiner has quit IRC
10292017-12-14T20:13:34 <maaku> cfields: gitian is not designed to work on windows or mac os x or bsd or even non-mainstream linux environments. it expects a standard linux environment. so give it one: use gitian-lxc inside of a vm or container made with more traditional cross-platform support
10302017-12-14T20:13:52 <maaku> i'm not saying replace any aspect of gitian. these are totally different problems, and gitian only tackles one of them
10312017-12-14T20:14:36 <cfields> maaku: it is intended to work on osx
10322017-12-14T20:15:22 <sipa> looking at RFC 6886, NAT-PNP looks absolutely trivial
10332017-12-14T20:17:03 <gmaxwell> I think if we didn't care about learning our external IP (we do) it would be a dozen lines of code to support.
10342017-12-14T20:17:28 <sipa> oh, you need to know your gateway address
10352017-12-14T20:17:36 <sipa> that looks slightly nontrivial, especially across platforms
10362017-12-14T20:17:40 <aj> supa: http://miniupnp.free.fr/nat-pmp.html laims it's superceded by rfc6887 "port control protocol"
10372017-12-14T20:17:45 <aj> sipa even
10382017-12-14T20:17:54 <gmaxwell> aj: yes, though PCP is fully backwards compatible with PMP I believe.
10392017-12-14T20:18:02 <cfields> maaku: its primary task is to kick off a vm, run a script, and gather the results. imo the creation of that vm is out of its scope.
10402017-12-14T20:18:16 <gmaxwell> and just supports additional features we don't really need (well, IPv6 is among them I think)
10412017-12-14T20:18:29 <maaku> cfields: i seem to be failing at comunication with you. i give up, sorry.
10422017-12-14T20:18:48 <cfields> sipa: multicast to 0.0.0.0 :p
10432017-12-14T20:19:42 <Provoostenator> gmaxwell what do you mean by "care about learning our external ip"?
10442017-12-14T20:20:12 <sipa> Provoostenator: NAT-PMP has a way to know what your external IP is
10452017-12-14T20:20:18 <sipa> we need that for announcements in addr messages
10462017-12-14T20:20:29 <gmaxwell> Provoostenator: we use UPNP for two things: to open the port, and to learn our IP so we can announce it.
10472017-12-14T20:20:47 <gmaxwell> there are workarounds we have for the latter, but they're kinda lame, it's much better to learn it from the router.
10482017-12-14T20:21:10 <Provoostenator> I see. One (lame) workaround could be to ask another peer I assume?
10492017-12-14T20:21:28 <gmaxwell> we do that but the result isn't something we can trust.
10502017-12-14T20:21:53 <sipa> very early versions of bitcoin used whatismyip.com, no joke :)
10512017-12-14T20:22:04 <sipa> or some site like that
10522017-12-14T20:22:47 <Provoostenator> Can't you verify this untrusted IP by pinging it?
10532017-12-14T20:22:54 <cfields> maaku: sorry for steamrolling. I'd like to understand the role you see for something like Vagrant.
10542017-12-14T20:23:21 <wumpus> #11902
10552017-12-14T20:23:22 <gribble> https://github.com/bitcoin/bitcoin/issues/11902 | NAT-PMP port forwarding support · Issue #11902 · bitcoin/bitcoin · GitHub
10562017-12-14T20:23:44 <sipa> Provoostenator: so a peer would tell you, "hey, your IP is 192.168.1.1!" and you'd try to ping it, and indeed, it works!
10572017-12-14T20:23:56 *** To7 has quit IRC
10582017-12-14T20:23:59 <Provoostenator> You can't send a payload along with that ping?
10592017-12-14T20:24:06 <sipa> Provoostenator: you miss my point
10602017-12-14T20:24:10 <gmaxwell> Provoostenator: actually usually from inside nat you can't reach the external IP.
10612017-12-14T20:24:35 <Provoostenator> sipa: oh wait, I think I see your point
10622017-12-14T20:24:38 <gmaxwell> but what you're thinking of doesn't work either because the peer can mitm anything you do.
10632017-12-14T20:24:52 <Provoostenator> Exactly
10642017-12-14T20:25:18 <gmaxwell> besides, supporting the discovery part of PMP isn't that much harder.
10652017-12-14T20:25:49 <Provoostenator> Sure, just trying to understand why. But that makes sense.
10662017-12-14T20:26:19 <Provoostenator> IPv6 is still scheduled for 2008, right?
10672017-12-14T20:26:59 <maaku> cfields: setup a standard linux environment in which gitian is run
10682017-12-14T20:27:02 <BlueMatt> Provoostenator: yep, we're all preparing to deploy on schedule!
10692017-12-14T20:27:07 <sipa> Provoostenator: i had an IPv6 address in 2005 ;)
10702017-12-14T20:27:17 <maaku> on any platform, with ~no maintenence burden to bitcoin core
10712017-12-14T20:28:00 <maaku> cfields: like this did, although I'd change the approach if I re-did it in 2017 : https://github.com/bitcoin/bitcoin/pull/1597
10722017-12-14T20:28:08 <wumpus> lol yes I also had an IPv6 address in the past, but no longer, seems IPv6 support by the big providers in the Netherlands has been postponed indefinitely, they announce and postpone every time
10732017-12-14T20:28:20 *** alreadylate has joined #bitcoin-core-dev
10742017-12-14T20:28:34 *** intcat has quit IRC
10752017-12-14T20:29:07 <wumpus> one provider acquired another provider, cancelling their ongoing ipv6 rollout
10762017-12-14T20:29:21 <gmaxwell> lol
10772017-12-14T20:29:41 <BlueMatt> lol, monopolistic practices to prevent ipv6 rollout?
10782017-12-14T20:29:44 *** intcat has joined #bitcoin-core-dev
10792017-12-14T20:29:52 <sipa> apparently my home desktop, behind a NAT, has a global IPv6 address that works :o
10802017-12-14T20:30:02 <BlueMatt> my home internet does as well
10812017-12-14T20:30:04 <gmaxwell> SURPRISE.
10822017-12-14T20:30:33 <gmaxwell> just when you thought you didn't have to worry much about security on random hosts in your home...
10832017-12-14T20:30:43 <sipa> it's firewalled of course
10842017-12-14T20:30:49 <BlueMatt> InternetOfShitTakesRevenge
10852017-12-14T20:31:01 <BlueMatt> heh, my default garbage isnt
10862017-12-14T20:31:06 <cfields> maaku: I see
10872017-12-14T20:31:20 *** alreadylate has quit IRC
10882017-12-14T20:32:28 <sipa> gmaxwell: my machine is reachable in other ways too - i'm just surpised that ISP, router, OS, ... all support IPv6 without any configuration
10892017-12-14T20:32:48 *** Kozuch has quit IRC
10902017-12-14T20:33:02 <wumpus> yes, hardware and software support for ipv6 support is very good these days
10912017-12-14T20:33:12 <wumpus> that's no longer the bottleneck
10922017-12-14T20:33:19 *** games has joined #bitcoin-core-dev
10932017-12-14T20:33:19 <Provoostenator> Wumpus: seems Ziggo is experimenting with IPv6 again though.
10942017-12-14T20:33:41 *** games is now known as Guest66654
10952017-12-14T20:33:50 <Provoostenator> Top hit on Google is people trying to downgrade to IPv4 because [something bad].
10962017-12-14T20:34:30 *** alreadylate has joined #bitcoin-core-dev
10972017-12-14T20:34:39 *** maaku has left #bitcoin-core-dev
10982017-12-14T20:38:52 <wumpus> Provoostenator: you mean, to IPv6 only?
10992017-12-14T20:39:17 <Provoostenator> Yes, I'll just email them to see if that's possible. Then I'll find out how it works and what breaks.
11002017-12-14T20:39:44 <wumpus> I'd not be happy with that either, would just like the choice to use IPv6 as well
11012017-12-14T20:41:28 <BlueMatt> wumpus: I mean, hey, from a network-management perspective I do get why one might want to drag their feet on ipv6 rollout...the possibility that your users end up joining a DDoS attack because you host garbage IoT devices all over the place that get pop'ed via IPv6 is....much too high. ofc its something they need to deal with *either way*, but...ehh
11022017-12-14T20:43:47 <wumpus> BlueMatt: yes, having all devices reachable for incoming connections from outside by default is one of the things I like less about IPv6, although that's not the fault of the protocol but of router's default firewall configuration
11032017-12-14T20:43:58 <BlueMatt> indeed
11042017-12-14T20:43:59 *** SopaXorzTaker has quit IRC
11052017-12-14T20:44:22 <Provoostenator> Can't a standard cable modem just block all ports by default?
11062017-12-14T20:44:41 <BlueMatt> should, probably, but wont in my experience
11072017-12-14T20:44:52 <Provoostenator> So the user just needs to open them, but not forward. Although that's probably still too much of a barrier.
11082017-12-14T20:44:56 <wumpus> blocking incoming TCP SYN packets to the entire range would be a start
11092017-12-14T20:45:17 <wumpus> but I don't think any routers do that by default
11102017-12-14T20:45:23 <gmaxwell> internet of terror
11112017-12-14T20:45:40 *** alreadylate has quit IRC
11122017-12-14T20:47:16 *** Giszmo has quit IRC
11132017-12-14T20:47:17 <wumpus> then again, that would defeat its entire purpose for things like bitcoin and P2P programs, again requiring the users to manually change a setting
11142017-12-14T20:47:25 *** PaulCapestany has quit IRC
11152017-12-14T20:47:53 <BlueMatt> gmaxwell: internet of shit!
11162017-12-14T20:47:57 *** PaulCapestany has joined #bitcoin-core-dev
11172017-12-14T20:48:12 <BlueMatt> wumpus: yea, but upnp and auto-forwarding is easy to get right and implement!
11182017-12-14T20:49:05 *** alreadylate has joined #bitcoin-core-dev
11192017-12-14T20:50:25 *** promag has quit IRC
11202017-12-14T20:50:39 *** Giszmo has joined #bitcoin-core-dev
11212017-12-14T20:50:41 <wumpus> BlueMatt: not quite, though well at least for ipv4 there are protocols for that, I'm not sure what a ipv6 'please allow this port' request would look like
11222017-12-14T20:51:19 <BlueMatt> wumpus: I was joking......
11232017-12-14T20:51:23 <sipa> wumpus: PCP supports IPv6 IIRC
11242017-12-14T20:51:28 <wumpus> in principle it would be the application requesting global scope for a port instead of LAN scope, of course, it's dangerous to allow applications to make those decisions in general
11252017-12-14T20:54:06 <sipa> well UPnP/NAT-PMP aren't designed to bypass firewalls, they're to inform the router of port mappings
11262017-12-14T20:54:16 <sipa> in IPv6 those should just not be needed anymore
11272017-12-14T20:54:46 *** Guest16 has joined #bitcoin-core-dev
11282017-12-14T20:54:54 <wumpus> yeah, 'should'
11292017-12-14T20:55:05 <sipa> unfortunately, many people treat the lack of a mapping as a substitute for a firewall, where of course those protocols effectively become a way for application to bypass security
11302017-12-14T20:55:24 <wumpus> right
11312017-12-14T20:56:38 <wumpus> another problem is that applications and operating systems open all kinds of ports, expecting them to be only open to a LAN instead of to the whole world, whereas most users don't really configure a firewall
11322017-12-14T20:56:38 *** meshcollider has quit IRC
11332017-12-14T20:56:41 *** Guest16 is now known as xames
11342017-12-14T20:57:24 <xames> not possible to use port 80 like skype...
11352017-12-14T20:57:33 <wumpus> NAT made developers and users lazy in that way
11362017-12-14T20:57:50 <xames> like teamviewer
11372017-12-14T20:59:01 *** Guest66654 has quit IRC
11382017-12-14T20:59:48 *** intcat has quit IRC
11392017-12-14T21:01:10 *** intcat has joined #bitcoin-core-dev
11402017-12-14T21:06:10 <bitcoin-git> [bitcoin] jonasschnelli opened pull request #11903: [trivial] Add required package dependencies for depends cross compilation (master...2017/12/depends_pkg) https://github.com/bitcoin/bitcoin/pull/11903
11412017-12-14T21:08:32 *** alreadylate has quit IRC
11422017-12-14T21:09:56 *** intcat has quit IRC
11432017-12-14T21:11:00 *** propumpkin has joined #bitcoin-core-dev
11442017-12-14T21:12:12 *** contrapumpkin has quit IRC
11452017-12-14T21:14:39 *** meshcollider has joined #bitcoin-core-dev
11462017-12-14T21:15:27 *** intcat has joined #bitcoin-core-dev
11472017-12-14T21:29:21 *** Randolf has joined #bitcoin-core-dev
11482017-12-14T21:30:13 *** TheSadFace has joined #bitcoin-core-dev
11492017-12-14T21:31:25 <meshcollider> Ah I missed the meeting oops
11502017-12-14T21:32:06 *** xames has quit IRC
11512017-12-14T21:32:47 *** jb55 has quit IRC
11522017-12-14T21:32:48 *** bule has quit IRC
11532017-12-14T21:33:45 *** alreadylate has joined #bitcoin-core-dev
11542017-12-14T21:35:45 <BlueMatt> meshcollider: tsk tsk, no more getting your prs reviewed this week, then :p
11552017-12-14T21:36:39 *** timothy has joined #bitcoin-core-dev
11562017-12-14T21:36:51 *** alreadylate has quit IRC
11572017-12-14T21:37:15 *** timothy has quit IRC
11582017-12-14T21:37:31 <meshcollider> BlueMatt: how is that different from every other week though ;)
11592017-12-14T21:37:57 <BlueMatt> meshcollider: heh, try the high priority review queue, it at least usually gets you one or two reviews in a week :p
11602017-12-14T21:40:57 *** AaronvanW has joined #bitcoin-core-dev
11612017-12-14T21:42:28 *** Aaronvan_ has quit IRC
11622017-12-14T21:44:19 *** Aaronvan_ has joined #bitcoin-core-dev
11632017-12-14T21:45:07 *** shesek has joined #bitcoin-core-dev
11642017-12-14T21:45:07 *** shesek has joined #bitcoin-core-dev
11652017-12-14T21:47:45 *** AaronvanW has quit IRC
11662017-12-14T21:49:33 *** jb55 has joined #bitcoin-core-dev
11672017-12-14T21:49:54 *** Guest16 has joined #bitcoin-core-dev
11682017-12-14T21:50:38 *** jadee_ has joined #bitcoin-core-dev
11692017-12-14T22:00:40 *** alreadylate has joined #bitcoin-core-dev
11702017-12-14T22:04:15 <MarcoFalke> re: jonasschnelli: [OT] what is the fastest way to amend commit the current changes into a non HEAD commit?
11712017-12-14T22:04:17 <MarcoFalke> git commit --fixup=${that_non_head_commit} && git rebase --interactive --autosquash ${that_non_head_commit}~
11722017-12-14T22:07:03 <wumpus> huh autosquash is nice, so it will automatically mark commits whose message start with squash! as squash and same with fixup!, didn't know about that one
11732017-12-14T22:07:31 <BlueMatt> heh, cool
11742017-12-14T22:08:08 <meshcollider> You can also turn on autosquash by default with git config --global rebase.autosquash true
11752017-12-14T22:08:21 <meshcollider> so you don't have to use --autosquash every time
11762017-12-14T22:10:17 <BlueMatt> I really want a fixup! "Title of Commit to Squash Into"
11772017-12-14T22:10:33 <meshcollider> that is what it does?
11782017-12-14T22:11:16 <BlueMatt> oh, heh, nice
11792017-12-14T22:11:27 <meshcollider> ;)
11802017-12-14T22:11:57 *** jb55 has quit IRC
11812017-12-14T22:14:16 *** CASEgezadthfr has quit IRC
11822017-12-14T22:15:04 <MarcoFalke> promag: re ParseInt64
11832017-12-14T22:15:17 <MarcoFalke> Imo it should be done at init and then throw an error
11842017-12-14T22:15:32 *** jb55 has joined #bitcoin-core-dev
11852017-12-14T22:16:29 <meshcollider> MarcoFalke: I'm going to work on some stronger argument checking as soon as I can
11862017-12-14T22:16:35 <MarcoFalke> When your node is running for a day and you sendtoaddress, it is too late to crash on "Wrong tx fee set on command line"
11872017-12-14T22:16:42 <MarcoFalke> meshcollider: Cool
11882017-12-14T22:16:46 <wumpus> that's what I also said, we should have some options mechanism that parses all options at init time,
11892017-12-14T22:17:00 <MarcoFalke> wumpus: Jup, like python :)
11902017-12-14T22:17:01 <wumpus> it's crazy to parse options every time in a loop anyway
11912017-12-14T22:17:48 <wumpus> or every time a RPC command is called
11922017-12-14T22:18:21 <MarcoFalke> It is still good to have the GetArg in place, but internally they might use some sort of caching
11932017-12-14T22:18:35 <wumpus> just call the getarg in init
11942017-12-14T22:18:36 <meshcollider> GetArg just looks up in mapArgs
11952017-12-14T22:18:42 <wumpus> then assign to a global
11962017-12-14T22:18:47 <wumpus> or have some automatic system to do that
11972017-12-14T22:19:02 <wumpus> caching is also unnecessary, it can just be a variable
11982017-12-14T22:19:14 <wumpus> no need for any lookup at all
11992017-12-14T22:19:15 <meshcollider> wumpus all args are parsed in ArgsManager::ParseParameters
12002017-12-14T22:19:26 <MarcoFalke> wumpus: You'd have to sprikle the code with locks in case we allow args to change at run time, no?
12012017-12-14T22:19:33 <wumpus> we don't allow that
12022017-12-14T22:19:42 <MarcoFalke> There is a pull to do that, though
12032017-12-14T22:19:48 <meshcollider> which one?
12042017-12-14T22:19:52 <wumpus> well yes in that case you'd have to protect the values with a lock
12052017-12-14T22:20:02 <wumpus> it's tsill better than parsing every time
12062017-12-14T22:20:18 <MarcoFalke> wumpus: My style preferense would be to put the lock in the GetArg
12072017-12-14T22:20:20 <wumpus> but most settings don't really make sense to change at run time
12082017-12-14T22:20:26 <MarcoFalke> The getarg can return the variable
12092017-12-14T22:20:34 <wumpus> using strings to refer to variables just doesn't make sense when you know what you're accessing
12102017-12-14T22:20:41 <MarcoFalke> jup
12112017-12-14T22:20:48 <wumpus> there's this whole hash lookup every time that makes no sense
12122017-12-14T22:20:52 <jnewbery> wumpus: Perhaps #11415 is ready for merge?
12132017-12-14T22:20:55 <gribble> https://github.com/bitcoin/bitcoin/issues/11415 | [RPC] Disallow using addresses in createmultisig by achow101 · Pull Request #11415 · bitcoin/bitcoin · GitHub
12142017-12-14T22:22:17 <wumpus> jnewbery: thanks
12152017-12-14T22:22:29 <meshcollider> wumpus: so you suggest adding a private variable inside ArgsManager for each argument?
12162017-12-14T22:22:37 <meshcollider> I can probably work on this today
12172017-12-14T22:23:00 <wumpus> meshcollider: I'm not sure that's a good idea, because that makes argmanager have to know about all options in the entire program
12182017-12-14T22:23:16 <wumpus> meshcollider: ideally there would be some way to register arguments with the argument manager
12192017-12-14T22:23:22 <wumpus> meshcollider: same as we do with RPC methods
12202017-12-14T22:23:37 <meshcollider> wumpus: ah yes that's a cool idea
12212017-12-14T22:23:38 *** alreadylate has quit IRC
12222017-12-14T22:23:47 <wumpus> meshcollider: this information could include the name, documentaion, type, as well as a pointer to the variable to update
12232017-12-14T22:24:06 <MarcoFalke> and valid ranges for integers, e.g.
12242017-12-14T22:24:09 <wumpus> meshcollider: well it's pretty much what quake already did in 1995 or so :)
12252017-12-14T22:24:11 <wumpus> yep
12262017-12-14T22:24:13 <meshcollider> MarcoFalke: do you know what PR is the one which allows changing them at runtime? I'd like to take a quick look at it
12272017-12-14T22:24:16 *** YellowSphere has joined #bitcoin-core-dev
12282017-12-14T22:24:30 <MarcoFalke> it could be one of luke's
12292017-12-14T22:24:34 <aj> meshcollider: having a table of argument name -> reference to global that gets populated with value by parseargs+config?
12302017-12-14T22:24:36 <MarcoFalke> might be closed
12312017-12-14T22:25:15 <wumpus> MarcoFalke: yep a range or if that's not enough, a functor that does checking
12322017-12-14T22:25:25 <meshcollider> do we want to add a whole lot more global variables though
12332017-12-14T22:25:43 <wumpus> you could put them in a structure per module
12342017-12-14T22:25:44 <aj> wumpus, meshcollider, *: happy with the overall approach of #11862 at this point, btw?
12352017-12-14T22:25:46 <gribble> https://github.com/bitcoin/bitcoin/issues/11862 | [concept] Network specific conf sections by ajtowns · Pull Request #11862 · bitcoin/bitcoin · GitHub
12362017-12-14T22:26:14 <YellowSphere> Hi there.
12372017-12-14T22:26:26 <wumpus> e.g. a module could register its own globals, so they're only global static in that compilation unit
12382017-12-14T22:26:31 *** promag has joined #bitcoin-core-dev
12392017-12-14T22:26:32 <wumpus> same as the RPC registration
12402017-12-14T22:27:01 <wumpus> aj: ACK on the conept, haven't reviewed the code
12412017-12-14T22:27:07 <meshcollider> aj: so far yep it looks sensible
12422017-12-14T22:27:07 <MarcoFalke> meshcollider: Maybe this one https://github.com/bitcoin/bitcoin/pull/7510/files ?
12432017-12-14T22:27:19 *** intcat has quit IRC
12442017-12-14T22:27:46 <aj> wumpus: cool, i'll review the code, add some tests and maybe even docs then
12452017-12-14T22:27:56 *** danklasson has joined #bitcoin-core-dev
12462017-12-14T22:28:10 <aj> wumpus: modules registering their own options/globals would fit well with declaring some options as needing to be specified per network
12472017-12-14T22:28:26 <wumpus> aj: yes, that could be one of the registration parameters
12482017-12-14T22:28:46 *** intcat has joined #bitcoin-core-dev
12492017-12-14T22:28:59 <aj> wumpus: maybe help text could be one of the params too?
12502017-12-14T22:29:09 *** Guest16 has quit IRC
12512017-12-14T22:29:12 <wumpus> aj: absolutely, yes
12522017-12-14T22:29:19 <meshcollider> aj: he already mentioned that ;)
12532017-12-14T22:29:28 <MarcoFalke> falls under "documentation"
12542017-12-14T22:29:43 <meshcollider> Ok I'll get started then
12552017-12-14T22:30:18 <meshcollider> aj's PR should be merged first but I won't base mine on top of it until its been more thoroughly reviewed / less likely to drastically change
12562017-12-14T22:30:27 <wumpus> meshcollider: the idea would be that everything about the option is specified at registration, so that it's in one place and that's the module where it gets used
12572017-12-14T22:30:58 <danklasson> I don't know if you guys know. But supposedly this guy set up this fund where you can apply for 1 million dollars donation. Would you guys say that could be used to hire a bunch of devs working on several projects related to Bitcoin, such as segwit supported wallets and LN. What's your thoughts regarding this? https://pineapplefund.org/
12582017-12-14T22:32:51 <meshcollider> danklasson: I don't think bitcoin core counts as a charity ;)
12592017-12-14T22:33:12 *** Deacyde has joined #bitcoin-core-dev
12602017-12-14T22:34:11 <danklasson> meshcollider: I know but I'm guessing they would be willing to make an exception
12612017-12-14T22:34:23 <wumpus> yeah, I've had the question before 'how can I pay to help lightning development', I had no idea
12622017-12-14T22:36:15 *** scoooobydooo has quit IRC
12632017-12-14T22:36:18 <danklasson> wumpus: I read that few people are working on LN. If we had a bunch of money we could hire a bunch of devs to work on it. I bet I can get a bunch of guys on board to get the ball rolling
12642017-12-14T22:36:39 <wumpus> in open source it's individual developers working on things, there's no one dealing out work items, and allocating resources
12652017-12-14T22:36:51 <ryanofsky> imo, gflags has a good model for registering options. lets you declare options where used, creates variables to avoid lookups, and combines with documentation: https://gflags.github.io/gflags/#define
12662017-12-14T22:37:17 <danklasson> wumpus: not necessarily. a lot of companies contribute to open source too
12672017-12-14T22:37:22 <wumpus> sure you could ask individual developers for donation address
12682017-12-14T22:38:03 <danklasson> i was thinking something more like setting up a foundation that hires people and allocates them to different projects
12692017-12-14T22:38:47 <wumpus> heh that didn't go too well with the bitcoin foundation... anyhow off topic here
12702017-12-14T22:39:19 <danklasson> is there a better channel to discuss this?
12712017-12-14T22:39:25 <wumpus> #bitcoin
12722017-12-14T22:39:42 <Deacyde> /join #bitcoin
12732017-12-14T22:39:48 <Deacyde> :) \
12742017-12-14T22:40:51 <danklasson> ok, thanks
12752017-12-14T22:41:10 <wumpus> ryanofsky: agree, looks decent
12762017-12-14T22:41:23 *** jadee_ has quit IRC
12772017-12-14T22:42:12 *** jadee_ has joined #bitcoin-core-dev
12782017-12-14T22:43:18 *** Cogito_Ergo_Sum has quit IRC
12792017-12-14T22:52:06 *** jb55 has quit IRC
12802017-12-14T22:54:31 *** belcher has joined #bitcoin-core-dev
12812017-12-14T22:54:35 *** Dizzle has quit IRC
12822017-12-14T22:55:34 *** Guyver2 has joined #bitcoin-core-dev
12832017-12-14T22:57:17 *** jb55 has joined #bitcoin-core-dev
12842017-12-14T22:59:51 <phantomcircuit> i've got a node in blocks only mode with a peer that claims to be 0.15.1 sending transactions in violation of the protocol
12852017-12-14T23:00:24 <phantomcircuit> lol i also have a peer claiming to be 0.15.0.1
12862017-12-14T23:00:57 *** Chris_Stewart_5 has quit IRC
12872017-12-14T23:01:08 *** quantbot has quit IRC
12882017-12-14T23:02:11 <BlueMatt> yea, thats been a common complaint, dont know that anyone has reproduced it with their own nodes, but people seem to pop up claiming that every now and again
12892017-12-14T23:02:36 <BlueMatt> I'm betting its random garbage nodes hacked to relay lots of shit, cause several people have gone looking for a bug there and failed to find one, afair
12902017-12-14T23:03:00 <BlueMatt> err...not *common*, but it gets mentioned once or twice every now and again
12912017-12-14T23:03:05 <BlueMatt> we should probably just ban peers for that
12922017-12-14T23:03:43 <phantomcircuit> possibly nodes that have whitelisted 0.0.0.0/0
12932017-12-14T23:07:21 *** jb55 has quit IRC
12942017-12-14T23:11:38 *** photonclock_ has joined #bitcoin-core-dev
12952017-12-14T23:15:14 *** intcat has quit IRC
12962017-12-14T23:16:35 *** intcat has joined #bitcoin-core-dev
12972017-12-14T23:20:49 *** Pavle has joined #bitcoin-core-dev
12982017-12-14T23:21:48 *** tiagotrs has quit IRC
12992017-12-14T23:22:58 *** Kozuch has joined #bitcoin-core-dev
13002017-12-14T23:25:18 *** roadcrap has quit IRC
13012017-12-14T23:26:06 <bitcoin-git> [bitcoin] MeshCollider opened pull request #11904: Add a lock to the wallet directory (master...201712_walletdir_lock) https://github.com/bitcoin/bitcoin/pull/11904
13022017-12-14T23:26:10 <meshcollider> BlueMatt: ^
13032017-12-14T23:26:40 <meshcollider> wumpus: that needs a 0.16 milestone
13042017-12-14T23:31:01 *** quantbot has joined #bitcoin-core-dev
13052017-12-14T23:32:17 *** quantbot has quit IRC
13062017-12-14T23:32:51 *** quantbot has joined #bitcoin-core-dev
13072017-12-14T23:36:37 *** quantbot has quit IRC
13082017-12-14T23:36:51 *** quantbot has joined #bitcoin-core-dev
13092017-12-14T23:37:27 *** jb55 has joined #bitcoin-core-dev
13102017-12-14T23:41:10 *** roadcrap has joined #bitcoin-core-dev
13112017-12-14T23:53:49 *** mrfrasha_ has quit IRC
13122017-12-14T23:54:42 *** Pavle has quit IRC
13132017-12-14T23:56:09 *** Murch has quit IRC
13142017-12-14T23:57:19 *** dermoth has quit IRC
13152017-12-14T23:58:38 *** vicenteH has quit IRC
13162017-12-14T23:59:24 *** dermoth has joined #bitcoin-core-dev