12018-06-01T00:03:56 *** niska has quit IRC
22018-06-01T00:09:45 *** lxer has quit IRC
32018-06-01T00:17:18 *** niska has joined #bitcoin-core-dev
42018-06-01T00:18:20 *** goatpig has quit IRC
52018-06-01T00:53:38 *** Randolf has joined #bitcoin-core-dev
62018-06-01T00:58:49 *** Krellan has joined #bitcoin-core-dev
72018-06-01T01:07:35 *** jtimon has quit IRC
82018-06-01T01:26:57 *** Randolf has quit IRC
92018-06-01T01:29:02 *** Randolf has joined #bitcoin-core-dev
102018-06-01T01:37:59 *** jhfrontz has quit IRC
112018-06-01T01:50:29 *** meshcollider has quit IRC
122018-06-01T02:06:03 *** Krellan has quit IRC
132018-06-01T02:06:31 *** Krellan has joined #bitcoin-core-dev
142018-06-01T02:10:36 *** Krellan has quit IRC
152018-06-01T02:34:42 *** Aaronvan_ has joined #bitcoin-core-dev
162018-06-01T02:34:52 *** Aaronvan_ has quit IRC
172018-06-01T02:37:57 *** AaronvanW has quit IRC
182018-06-01T02:42:27 *** TheV01d has quit IRC
192018-06-01T02:47:08 *** TheV01d has joined #bitcoin-core-dev
202018-06-01T02:51:16 *** jhfrontz has joined #bitcoin-core-dev
212018-06-01T03:09:56 *** fanquake has joined #bitcoin-core-dev
222018-06-01T03:12:15 *** fanquake has quit IRC
232018-06-01T03:44:45 *** luke-jr has quit IRC
242018-06-01T03:44:45 *** vicenteH has quit IRC
252018-06-01T03:44:46 *** kinlo has quit IRC
262018-06-01T03:44:46 *** wallet42 has quit IRC
272018-06-01T03:44:46 *** gaf_ has quit IRC
282018-06-01T03:44:46 *** exit70 has quit IRC
292018-06-01T03:44:46 *** rubensayshi_ has quit IRC
302018-06-01T03:44:46 *** CryptAxe has quit IRC
312018-06-01T03:44:46 *** pindarhk_ has quit IRC
322018-06-01T03:44:46 *** bosma has quit IRC
332018-06-01T03:44:46 *** rockhouse has quit IRC
342018-06-01T03:44:46 *** Eliel has quit IRC
352018-06-01T03:44:46 *** delpa^ has quit IRC
362018-06-01T03:44:46 *** cncr04s has quit IRC
372018-06-01T04:36:20 *** Jackpot1136 has joined #bitcoin-core-dev
382018-06-01T04:43:10 *** Jackpot1136 has quit IRC
392018-06-01T04:51:57 *** bitconner has quit IRC
402018-06-01T04:53:40 *** luke-jr has joined #bitcoin-core-dev
412018-06-01T05:12:23 <kallewoof> I'm a bit surprised at the concerns with people running distros from 2007 not being able to run the latest & greatest version of bitcoin core. Does such a person actually exist?
422018-06-01T05:13:55 <kallewoof> Also amazed at how long RHEL support lasts. :O
432018-06-01T05:20:21 <mryandao> enterprise would be running the oldest version of bitcoin possible
442018-06-01T05:21:31 *** tryphe has joined #bitcoin-core-dev
452018-06-01T05:24:17 *** tryphe_ has quit IRC
462018-06-01T05:40:32 *** SopaXorzTaker has joined #bitcoin-core-dev
472018-06-01T05:42:05 *** bitconner has joined #bitcoin-core-dev
482018-06-01T05:53:32 <kallewoof> mryandao: Yeah, so even if RHEL 8 was released with C++14 support it wouldn't really matter cause its users would be running bitcoin core 0.3 or something, anyway...
492018-06-01T05:55:05 *** harrymm has quit IRC
502018-06-01T06:08:56 *** harrymm has joined #bitcoin-core-dev
512018-06-01T06:24:08 <jonasschnelli> sipa: Yes. Possible,... but seems like we re-inventing a description language like JSON. :)
522018-06-01T06:24:41 <jonasschnelli> I like such compact forms though,.. but they tend to fail once extended to the max
532018-06-01T06:25:39 <jonasschnelli> Maybe it makes more sense to use JSON as the container/desciption format rather then inventing a custom CSV
542018-06-01T06:26:14 <jonasschnelli> not sure though,.. the compact string format would be used at various places,.. like importmulti, etc.
552018-06-01T06:26:25 <jonasschnelli> We just need to make sure it works for all possible extensions
562018-06-01T06:41:20 <sipa> jonasschnelli: i'm worrier about introducing too many formats
572018-06-01T06:48:21 <sipa> jonasschnelli: my idea is that the "records" that eventually will constitute a wallet will consist of a) a descriptor of script(s) and (b) birthdate (c) watchonly or not (d) private key optionally
582018-06-01T06:48:47 <jonasschnelli> Yes. I think that is a very good idea..
592018-06-01T06:48:51 <sipa> the (a) part is something that should be shared with scanutxo and perhaps some other things
602018-06-01T06:48:54 <jonasschnelli> My concerns are more about the format
612018-06-01T06:49:25 <sipa> so it would be nice of it's a nice and self contained thing
622018-06-01T06:49:31 <sipa> it could be json
632018-06-01T06:49:45 <sipa> that was what i was thinking too... but it's kind of unwieldy too
642018-06-01T06:49:52 <jonasschnelli> Not sure what would make more sense...
652018-06-01T06:49:54 <sipa> so i'm considering a single string thing
662018-06-01T06:50:07 <jonasschnelli> If the use cases are beyond JSON RPC, then I think a "new" format may make sense
672018-06-01T06:50:38 <jonasschnelli> JSON is very extensible...
682018-06-01T06:51:00 <sipa> dump files
692018-06-01T06:51:21 <jonasschnelli> Yes...
702018-06-01T06:51:26 * jonasschnelli thinking...
712018-06-01T06:52:13 <jonasschnelli> The whole dump file is another things... I'm currently not sure what the purpose of a dump file is, and if it is "a backup", if it is the right format
722018-06-01T06:52:26 *** SopaXorzTaker has quit IRC
732018-06-01T06:52:50 <jonasschnelli> But I kinda like a string based descriptor,... lets do that
742018-06-01T06:53:29 <jonasschnelli> sipa: have you done a short spec on it already?
752018-06-01T06:53:45 *** SopaXorzTaker has joined #bitcoin-core-dev
762018-06-01T06:54:28 <jonasschnelli> Would it be k/v or fix order/index? Would the xpub ckd range also be possible to describe?
772018-06-01T06:54:50 <sipa> yes, it needs to be
782018-06-01T06:55:02 <jonasschnelli> What is "(c) watchonly or not"?
792018-06-01T06:55:08 <sipa> jonasschnelli: read my.gist
802018-06-01T06:55:17 <sipa> i've linked to it many times :)
812018-06-01T06:55:31 <jonasschnelli> heh.. okay. I shoud re-read you wallet gist, yes.
822018-06-01T06:56:08 <sipa> jonasschnelli: the idea is that watchonly should not be tied to whether or not you happen to ha e the private key
832018-06-01T06:56:08 <jonasschnelli> We should that probably stick to the channel topic. :)
842018-06-01T06:56:30 <jonasschnelli> hmm...
852018-06-01T06:56:53 <jonasschnelli> But I guess senseless for primitive scripts like P2WPKH?
862018-06-01T06:56:59 <sipa> no
872018-06-01T06:57:10 <sipa> for example if your private key is in a hardware wallet
882018-06-01T06:57:17 <sipa> that shouldn't be treated as watchonly
892018-06-01T06:57:19 <sipa> it is yours
902018-06-01T06:57:41 <jonasschnelli> Aha... you look at it from an overall perspective... I was looking from a pure "wallet" perspective
912018-06-01T06:57:42 <sipa> watchonly is for multisig things that you participate in, but don't want counted towards your balance
922018-06-01T06:58:19 <sipa> so my view is that private key or not should be independent from "counted towards balance" ("watch only") or not
932018-06-01T06:58:33 <jonasschnelli> So then there would be 3 categories, hot keys (default), non-private-key-keys (HWW) and watch only?
942018-06-01T06:59:27 <sipa> no, there are "yours" records and "non-yours records" ("watch only")
952018-06-01T06:59:50 <jonasschnelli> When I did a primitive PoC with Core and the Bitbox, I came to the conclusion that three categories may make sense...
962018-06-01T06:59:50 <sipa> in addition, you have private keys... in various places; some can be in your wallet, some are not
972018-06-01T07:00:04 <sipa> the wallet should not care about whether it has the private key or not
982018-06-01T07:00:08 <jonasschnelli> But since multiwallet, this is no longer necesarry I gues
992018-06-01T07:00:11 <jonasschnelli> *s
1002018-06-01T07:00:19 <sipa> please, read my gist :)
1012018-06-01T07:00:33 <jonasschnelli> Yes. I see. Makes sense to me...
1022018-06-01T07:00:44 <jonasschnelli> Yes. I should read your gist every morning...
1032018-06-01T07:00:49 <jonasschnelli> amen. :)
1042018-06-01T07:04:42 *** lxer has joined #bitcoin-core-dev
1052018-06-01T07:27:51 *** bitconner has quit IRC
1062018-06-01T07:31:35 *** bitconner has joined #bitcoin-core-dev
1072018-06-01T07:33:34 *** fanquake has joined #bitcoin-core-dev
1082018-06-01T07:34:03 <fanquake> wumpus got a 6.3 vm setup, will get through those bsd PRs
1092018-06-01T07:45:15 *** ghost43 has quit IRC
1102018-06-01T07:47:26 *** vicenteH has joined #bitcoin-core-dev
1112018-06-01T07:47:26 *** kinlo has joined #bitcoin-core-dev
1122018-06-01T07:47:26 *** wallet42 has joined #bitcoin-core-dev
1132018-06-01T07:47:26 *** gaf_ has joined #bitcoin-core-dev
1142018-06-01T07:47:26 *** exit70 has joined #bitcoin-core-dev
1152018-06-01T07:47:26 *** rubensayshi_ has joined #bitcoin-core-dev
1162018-06-01T07:47:26 *** CryptAxe has joined #bitcoin-core-dev
1172018-06-01T07:47:26 *** pindarhk_ has joined #bitcoin-core-dev
1182018-06-01T07:47:26 *** bosma has joined #bitcoin-core-dev
1192018-06-01T07:47:26 *** rockhouse has joined #bitcoin-core-dev
1202018-06-01T07:47:26 *** Eliel has joined #bitcoin-core-dev
1212018-06-01T07:47:26 *** delpa^ has joined #bitcoin-core-dev
1222018-06-01T07:47:26 *** cncr04s has joined #bitcoin-core-dev
1232018-06-01T07:47:41 *** exit70 has quit IRC
1242018-06-01T07:49:43 *** exit70 has joined #bitcoin-core-dev
1252018-06-01T08:00:41 <wumpus> fanquake: great!
1262018-06-01T08:03:25 *** Cory has quit IRC
1272018-06-01T08:05:26 <fanquake> #13355 fixes running gmake check
1282018-06-01T08:05:28 <gribble> https://github.com/bitcoin/bitcoin/issues/13355 | Fix "gmake check" under OpenBSD 6.3 (probably *BSD): Avoid using GNU grep specific regexp handling by practicalswift · Pull Request #13355 · bitcoin/bitcoin · GitHub
1292018-06-01T08:06:32 <wumpus> thanks for checking, it seems about time to merge it
1302018-06-01T08:09:38 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/87a9d03c0c1e...0b1c0c462eda
1312018-06-01T08:09:38 <bitcoin-git> bitcoin/master db56755 practicalswift: Fix "gmake check" under OpenBSD 6.3 (probably *BSD): Avoid using GNU grep specific regexp handling
1322018-06-01T08:09:39 <bitcoin-git> bitcoin/master 0b1c0c4 Wladimir J. van der Laan: Merge #13355: Fix "gmake check" under OpenBSD 6.3 (probably *BSD): Avoid using GNU grep specific regexp handling...
1332018-06-01T08:09:44 *** Pasha has joined #bitcoin-core-dev
1342018-06-01T08:10:31 <bitcoin-git> [bitcoin] laanwj closed pull request #13355: Fix "gmake check" under OpenBSD 6.3 (probably *BSD): Avoid using GNU grep specific regexp handling (master...openbsd-gmake-check) https://github.com/bitcoin/bitcoin/pull/13355
1352018-06-01T08:10:32 <fanquake> Obviously 13294 was submitted without running any tests, seeing as they would have been broken at the time.. ? Bit scary given the changes
1362018-06-01T08:11:26 *** setpill has joined #bitcoin-core-dev
1372018-06-01T08:11:54 *** aaa_ has joined #bitcoin-core-dev
1382018-06-01T08:12:08 <aaa_> join
1392018-06-01T08:12:11 <aaa_> ??
1402018-06-01T08:12:17 *** aaa_ is now known as Guest15263
1412018-06-01T08:12:34 <Guest15263> 11111
1422018-06-01T08:12:34 *** timothy has joined #bitcoin-core-dev
1432018-06-01T08:12:56 *** Pasha is now known as Cory
1442018-06-01T08:13:06 <Guest15263> 31232321
1452018-06-01T08:13:08 <Guest15263> adad
1462018-06-01T08:13:08 <Guest15263> ad
1472018-06-01T08:13:08 <Guest15263> d
1482018-06-01T08:13:08 <Guest15263> d
1492018-06-01T08:13:09 <Guest15263> d
1502018-06-01T08:13:09 <Guest15263> d
1512018-06-01T08:13:09 <Guest15263> d
1522018-06-01T08:13:09 <Guest15263> d
1532018-06-01T08:13:10 <Guest15263> d
1542018-06-01T08:13:10 <Guest15263> d
1552018-06-01T08:13:11 <Guest15263> d
1562018-06-01T08:13:11 <Guest15263> d
1572018-06-01T08:13:12 <Guest15263> d
1582018-06-01T08:13:14 <fanquake> Please stop.
1592018-06-01T08:14:35 <Guest15263> Why no one speaks?Is this a bitcore channel?
1602018-06-01T08:15:25 <fanquake> This channel is for Core Development discussion. Generally there are always hundreds of people idling/watching. Actually discussion happens sporadically.
1612018-06-01T08:15:53 <fanquake> *actual
1622018-06-01T08:16:43 <Guest15263> soga
1632018-06-01T08:17:05 *** drizztbsd has joined #bitcoin-core-dev
1642018-06-01T08:17:23 *** timothy has quit IRC
1652018-06-01T08:26:08 <wumpus> fanquake: #13294 duplicates too much of the ifdef forest for my taste, Maybe empact's idea of just pre-declaring the function instead would result in less mess.
1662018-06-01T08:26:11 <gribble> https://github.com/bitcoin/bitcoin/issues/13294 | Fix compiler warnings emitted when compiling under stock OpenBSD 6.3 by practicalswift · Pull Request #13294 · bitcoin/bitcoin · GitHub
1672018-06-01T08:28:14 *** ghost43 has joined #bitcoin-core-dev
1682018-06-01T08:29:04 <wumpus> I think there should be a limit to how much logic to add just to avoid a compiler warning, we're at the point again where the avoidance of warnings becomes a goal in itself instead of an indication of potential problems.
1692018-06-01T08:30:48 <wumpus> I mean at least in #13349 I also solved an issue, while removing the warning.
1702018-06-01T08:30:51 <gribble> https://github.com/bitcoin/bitcoin/issues/13349 | bench: Dont return a bool from main by laanwj · Pull Request #13349 · bitcoin/bitcoin · GitHub
1712018-06-01T08:32:31 <fanquake> wumpus I agree. Should find out what the test plan was to ensure that no behaviour changed for any of the platforms affected by that forrest, just to silence a warning.
1722018-06-01T08:32:41 <fanquake> That feels like exactly the kind of place you'd subtly break something.
1732018-06-01T08:33:37 <wumpus> woule be a very bad place to break something too, and hard todetect
1742018-06-01T08:47:13 <bitcoin-git> [bitcoin] jonasschnelli pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/0b1c0c462eda...343d4e44ef4d
1752018-06-01T08:47:14 <bitcoin-git> bitcoin/master 9421317 John Newbery: [wallet] [rpc] Add `createwallet` RPC...
1762018-06-01T08:47:14 <bitcoin-git> bitcoin/master 32167e8 John Newbery: [wallet] [tests] Add tests for `createwallet` RPC.
1772018-06-01T08:47:15 <bitcoin-git> bitcoin/master f7e153e John Newbery: [wallets] [docs] Add release notes for createwallet RPC.
1782018-06-01T08:47:46 <bitcoin-git> [bitcoin] jonasschnelli closed pull request #13058: [wallet] `createwallet` RPC - create new wallet at runtime (master...create_wallet) https://github.com/bitcoin/bitcoin/pull/13058
1792018-06-01T08:52:04 *** Guest15263 has quit IRC
1802018-06-01T08:52:47 <fanquake> wumpus #13353 looks ok
1812018-06-01T08:52:49 <gribble> https://github.com/bitcoin/bitcoin/issues/13353 | qa: Fixup setting of PATH env var by MarcoFalke · Pull Request #13353 · bitcoin/bitcoin · GitHub
1822018-06-01T09:05:00 <wumpus> yes
1832018-06-01T09:05:11 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/343d4e44ef4d...d4f6dac9abf8
1842018-06-01T09:05:12 <bitcoin-git> bitcoin/master fa26cf0 MarcoFalke: qa: Fixup setting of PATH env var
1852018-06-01T09:05:12 <bitcoin-git> bitcoin/master d4f6dac Wladimir J. van der Laan: Merge #13353: qa: Fixup setting of PATH env var...
1862018-06-01T09:06:06 <bitcoin-git> [bitcoin] laanwj closed pull request #13353: qa: Fixup setting of PATH env var (master...Mf1806-qaPathBitcoind) https://github.com/bitcoin/bitcoin/pull/13353
1872018-06-01T09:16:11 <kewde[m]> https://github.com/bitcoin/bitcoin/blob/0.16/src/qt/locale/bitcoin_ru.ts#L65
1882018-06-01T09:16:41 <kewde[m]> What a weird translation - seems like the Russian language is adopting bitcoin addresses as new vocabulary.
1892018-06-01T09:17:13 <wumpus> kewde[m]: yuck
1902018-06-01T09:17:30 <fanquake> kewde[m] heh. Could you report it upstream? https://www.transifex.com/bitcoin/bitcoin/
1912018-06-01T09:17:31 <wumpus> kewde[m]: thanks for noticing
1922018-06-01T09:17:44 <wumpus> fanquake: I'm just going to nuke the message
1932018-06-01T09:17:51 <wumpus> (on transfex)
1942018-06-01T09:17:57 <fanquake> wumpus np
1952018-06-01T09:18:04 <kewde[m]> I can't take credit for noticing it - just passing along the message.
1962018-06-01T09:18:28 <wumpus> good that it was caught in a rc at least
1972018-06-01T09:19:27 <wumpus> fanquake: maybe delete the entire Russian translation to teach them a lesson :p
1982018-06-01T09:19:34 <kewde[m]> https://insight.bitpay.com/address/12Ny5wkrQ5d5bVk2LANAx5R3wcMT9HLFz9
1992018-06-01T09:20:09 <fanquake> wumpus heh, poor translators
2002018-06-01T09:20:42 <wumpus> I think this is the first time this was ever tried, or at least reported. I'll change the import translations script to check for this.
2012018-06-01T09:21:11 <kewde[m]> It hasn't received any funds recently - but there is a tx from 2017 O_o
2022018-06-01T09:22:01 <wumpus> kewde[m]: bizarre
2032018-06-01T09:23:43 *** ken2812221 has quit IRC
2042018-06-01T09:24:50 <wumpus> I reverted the message on transifex (they keep a history, thankfully). https://www.transifex.com/user/profile/IVAN6015/ is the person that added the address.
2052018-06-01T09:24:59 *** ken2812221 has joined #bitcoin-core-dev
2062018-06-01T09:25:39 <wumpus> looks like they did no other damage at least in RU
2072018-06-01T09:28:06 <fanquake> wumpus good to know
2082018-06-01T09:28:17 <fanquake> I'm heading out, will get some more review done tomorrow.
2092018-06-01T09:28:54 *** fanquake has quit IRC
2102018-06-01T09:29:46 *** ken2812221 has quit IRC
2112018-06-01T09:38:16 <bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.16: https://github.com/bitcoin/bitcoin/commit/4ea3e8ef070417ccc22007407d78fa0a41949bee
2122018-06-01T09:38:16 <bitcoin-git> bitcoin/0.16 4ea3e8e Wladimir J. van der Laan: qt: Periodic translations update...
2132018-06-01T09:39:26 <wumpus> the address will be gone in next rc
2142018-06-01T09:42:47 <wumpus> created issue #13363
2152018-06-01T09:42:48 <gribble> https://github.com/bitcoin/bitcoin/issues/13363 | Make update-translations.py script check for (valid) bitcoin addresses · Issue #13363 · bitcoin/bitcoin · GitHub
2162018-06-01T09:43:58 <wumpus> (might have a stab at this myself later, but if someone else wants to, you're very welcome)
2172018-06-01T09:47:47 *** Guyver2 has joined #bitcoin-core-dev
2182018-06-01T09:52:17 *** ghost43 has quit IRC
2192018-06-01T09:52:18 *** intcat has quit IRC
2202018-06-01T09:54:33 *** intcat has joined #bitcoin-core-dev
2212018-06-01T10:07:35 *** ghost43 has joined #bitcoin-core-dev
2222018-06-01T10:24:24 *** AaronvanW has joined #bitcoin-core-dev
2232018-06-01T10:30:23 <bitcoin-git> [bitcoin] mess110 opened pull request #13364: update transifex doc links (master...fix_transifex_client_config_link) https://github.com/bitcoin/bitcoin/pull/13364
2242018-06-01T10:40:24 *** drizztbsd is now known as timothy
2252018-06-01T10:42:02 *** Aaronvan_ has joined #bitcoin-core-dev
2262018-06-01T10:44:41 *** AaronvanW has quit IRC
2272018-06-01T10:46:44 *** AaronvanW has joined #bitcoin-core-dev
2282018-06-01T10:50:22 *** Aaronvan_ has quit IRC
2292018-06-01T11:04:12 *** mess110 has joined #bitcoin-core-dev
2302018-06-01T11:05:05 *** bitconner has quit IRC
2312018-06-01T11:05:25 <mess110> hi
2322018-06-01T11:05:57 <mess110> can I please get a rebuild for https://github.com/bitcoin/bitcoin/pull/13364 ? I updated some doc links but some test failed
2332018-06-01T11:09:16 *** timothy has quit IRC
2342018-06-01T11:10:48 *** timothy has joined #bitcoin-core-dev
2352018-06-01T11:15:05 *** timothy has quit IRC
2362018-06-01T11:15:27 *** timothy has joined #bitcoin-core-dev
2372018-06-01T11:18:16 *** timothy has quit IRC
2382018-06-01T11:25:34 *** timothy has joined #bitcoin-core-dev
2392018-06-01T11:30:02 *** drizztbsd has joined #bitcoin-core-dev
2402018-06-01T11:30:59 *** timothy has quit IRC
2412018-06-01T11:34:49 *** bitconner has joined #bitcoin-core-dev
2422018-06-01T11:39:27 *** bitconner has quit IRC
2432018-06-01T11:46:44 *** bitconner has joined #bitcoin-core-dev
2442018-06-01T11:53:42 *** bitconner has quit IRC
2452018-06-01T12:01:06 <wumpus> mess110: I've triggered the failed build
2462018-06-01T12:01:48 <wumpus> going to merge #13352 as it's anoying that travis fails all the time
2472018-06-01T12:01:50 *** bitconner has joined #bitcoin-core-dev
2482018-06-01T12:01:51 <gribble> https://github.com/bitcoin/bitcoin/issues/13352 | qa: Avoid checking reject code for now by MarcoFalke · Pull Request #13352 · bitcoin/bitcoin · GitHub
2492018-06-01T12:03:33 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d4f6dac9abf8...e24bf1ce184b
2502018-06-01T12:03:33 <bitcoin-git> bitcoin/master faac7a2 MarcoFalke: qa: Avoid checking reject code for now...
2512018-06-01T12:03:34 <bitcoin-git> bitcoin/master e24bf1c Wladimir J. van der Laan: Merge #13352: qa: Avoid checking reject code for now...
2522018-06-01T12:04:16 <bitcoin-git> [bitcoin] laanwj closed pull request #13352: qa: Avoid checking reject code for now (master...Mf1806-qaRejectCode) https://github.com/bitcoin/bitcoin/pull/13352
2532018-06-01T12:06:19 *** bitconner has quit IRC
2542018-06-01T12:07:27 <bitcoin-git> [bitcoin] yuntai opened pull request #13365: RPC/REST/ZMQ: Set label with importprivkey only requested. #13087 (master...master) https://github.com/bitcoin/bitcoin/pull/13365
2552018-06-01T12:17:32 *** bitconner has joined #bitcoin-core-dev
2562018-06-01T12:18:12 *** niu has joined #bitcoin-core-dev
2572018-06-01T12:18:17 *** AaronvanW has quit IRC
2582018-06-01T12:21:17 *** niu has quit IRC
2592018-06-01T12:22:05 *** bitconner has quit IRC
2602018-06-01T12:23:36 *** jtimon has joined #bitcoin-core-dev
2612018-06-01T12:23:49 *** AaronvanW has joined #bitcoin-core-dev
2622018-06-01T12:26:22 *** bitconner has joined #bitcoin-core-dev
2632018-06-01T12:28:45 *** goatpig has joined #bitcoin-core-dev
2642018-06-01T12:31:30 *** laurentmt has joined #bitcoin-core-dev
2652018-06-01T12:33:31 *** bitconner has quit IRC
2662018-06-01T12:33:35 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2672018-06-01T12:40:49 *** bitconner has joined #bitcoin-core-dev
2682018-06-01T12:41:25 *** qu4ku has joined #bitcoin-core-dev
2692018-06-01T12:42:43 *** Krellan has joined #bitcoin-core-dev
2702018-06-01T12:44:06 *** AaronvanW has quit IRC
2712018-06-01T12:44:16 *** fanquake has joined #bitcoin-core-dev
2722018-06-01T12:44:42 *** AaronvanW has joined #bitcoin-core-dev
2732018-06-01T12:45:35 *** bitconner has quit IRC
2742018-06-01T12:47:26 *** Krellan has quit IRC
2752018-06-01T12:49:08 *** AaronvanW has quit IRC
2762018-06-01T12:49:43 *** qu4ku has joined #bitcoin-core-dev
2772018-06-01T12:50:04 *** bitconner has joined #bitcoin-core-dev
2782018-06-01T12:51:20 *** AaronvanW has joined #bitcoin-core-dev
2792018-06-01T12:54:48 *** bitconner has quit IRC
2802018-06-01T12:55:29 <bitcoin-git> [bitcoin] giulio92 opened pull request #13366: Docs: Rename âOS Xâ to the newer âmacOSâ convention (master...osx-renaming) https://github.com/bitcoin/bitcoin/pull/13366
2812018-06-01T13:02:21 *** bitconner has joined #bitcoin-core-dev
2822018-06-01T13:02:57 *** Chris_Stewart_5 has quit IRC
2832018-06-01T13:07:13 *** bitconner has quit IRC
2842018-06-01T13:07:35 *** setpill has quit IRC
2852018-06-01T13:13:55 *** bitconner has joined #bitcoin-core-dev
2862018-06-01T13:14:06 <jonasschnelli> sipa: what do you think about "address:<addr>/b<timestamp_uint64>/w|p<pkey_wif>" or "script:<script_hex>" or "p2wpkh:<pub|xpub>/r0-2000/..."?
2872018-06-01T13:15:26 <jonasschnelli> pub/xpub is autodetect, first char r |Â b | w | p is for (r)ange, (b)irthday, (w)atchonly, (p)rivatekey
2882018-06-01T13:16:55 <jonasschnelli> we could avoid the first "key-char" and detect the type an the length and characteristics (8byte int == birthday, <num>â<num> == range, etc.)
2892018-06-01T13:17:10 <jonasschnelli> But it smells after voodoo... so unsure
2902018-06-01T13:19:26 *** bitconner has quit IRC
2912018-06-01T13:21:08 *** bitconner has joined #bitcoin-core-dev
2922018-06-01T13:25:57 *** bitconner has quit IRC
2932018-06-01T13:28:59 *** bitconner has joined #bitcoin-core-dev
2942018-06-01T13:30:04 *** gojo has joined #bitcoin-core-dev
2952018-06-01T13:31:17 <gojo> Hi, I'm experienced developer Blockchain, C/C++, reverse engineering, compilers, drivers, GPU/OpenCL, Cryptography, Python, NodeJS, Linux, Windows, Web, mobile, embedded and more. Urgent! I'm looking for important job!
2962018-06-01T13:33:38 *** bitconner has quit IRC
2972018-06-01T13:36:21 *** qu4ku has quit IRC
2982018-06-01T13:36:59 <jonasschnelli> gojo: no jobs here...
2992018-06-01T13:37:16 *** bitconner has joined #bitcoin-core-dev
3002018-06-01T13:41:51 *** bitconner has quit IRC
3012018-06-01T13:42:46 *** cryptapus has quit IRC
3022018-06-01T13:43:11 *** cryptapus has joined #bitcoin-core-dev
3032018-06-01T13:43:29 *** drizztbsd is now known as timothy
3042018-06-01T13:47:13 *** bitconner has joined #bitcoin-core-dev
3052018-06-01T13:49:01 <TheCharlatan> Picking up from yesterday's back compat question, I'm having the same problems with gcc-7 as ken2812221 in #12511 using same configure and environment flags as in the gitian linux descriptor. I'm not sure if there is a simple fix available for this, like currently with aliasing memcpy.
3062018-06-01T13:49:03 <gribble> https://github.com/bitcoin/bitcoin/issues/12511 | Switch to Ubuntu 18.04 for gitian building · Issue #12511 · bitcoin/bitcoin · GitHub
3072018-06-01T13:51:26 *** laurentmt has quit IRC
3082018-06-01T13:52:07 *** bitconner has quit IRC
3092018-06-01T13:59:11 *** bitconner has joined #bitcoin-core-dev
3102018-06-01T14:04:38 *** bitconner has quit IRC
3112018-06-01T14:05:33 *** bitconner has joined #bitcoin-core-dev
3122018-06-01T14:06:33 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3132018-06-01T14:10:25 *** bitconner has quit IRC
3142018-06-01T14:15:55 *** bitconner has joined #bitcoin-core-dev
3152018-06-01T14:20:27 *** bitconner has quit IRC
3162018-06-01T14:25:32 <wumpus> I've made a start with the addrv2 BIP spec: https://gist.github.com/laanwj/4fe8470881d7b9499eedc48dc9ef1ad1
3172018-06-01T14:29:52 *** bitconner has joined #bitcoin-core-dev
3182018-06-01T14:34:36 *** bitconner has quit IRC
3192018-06-01T14:37:45 *** bitconner has joined #bitcoin-core-dev
3202018-06-01T14:39:52 * jonasschnelli reading addrv2 BIP
3212018-06-01T14:41:40 <jonasschnelli> wumpus: nice.
3222018-06-01T14:41:50 <jonasschnelli> I like the backward compatible way (only >128bit use v2)
3232018-06-01T14:42:16 <jonasschnelli> Not sure about the name addrv2 (versioning of protocol commands)
3242018-06-01T14:42:32 <jonasschnelli> or it should be something like addr32
3252018-06-01T14:42:43 *** bitconner has quit IRC
3262018-06-01T14:44:20 <wumpus> yes the name is completely contingent, I don't care
3272018-06-01T14:44:54 <wumpus> as for the backwards compatibility, I think I prefer a new network version that simply uses addrv2 only, this will allow moving away from legacy addr messages at some point completely
3282018-06-01T14:45:30 <wumpus> I think the only advantage of the backward compatible approach is that it doesn't require a new network version, but I'm not sure how important that is
3292018-06-01T14:45:37 <jonasschnelli> Yes. It is a cleaner cut
3302018-06-01T14:46:28 <wumpus> we could even *not* rename the message, with the new protocol version, but that introduces some fragility I'm not happy with
3312018-06-01T14:47:11 *** vicenteH has quit IRC
3322018-06-01T14:47:45 *** vicenteH has joined #bitcoin-core-dev
3332018-06-01T14:47:53 <jonasschnelli> I guess using a varint for services is probably an unnecessary optimization? It would save 33% for a IPv4 addr
3342018-06-01T14:48:04 <jonasschnelli> (with the current used service bits)
3352018-06-01T14:48:09 <jonasschnelli> AFAIK
3362018-06-01T14:48:57 <jonasschnelli> wumpus: I guess not using a new command would probably make a lot of stupid light clients crash. :)
3372018-06-01T14:49:30 *** bitconner has joined #bitcoin-core-dev
3382018-06-01T14:49:32 <wumpus> jonasschnelli: that's an interesting proposal
3392018-06-01T14:49:57 <wumpus> jonasschnelli: I like it, don't see a reason why not
3402018-06-01T14:50:27 <jonasschnelli> Yes. I think its worth it.
3412018-06-01T14:50:35 <wumpus> jonasschnelli: even beter, it's future-proof
3422018-06-01T14:50:40 <jonasschnelli> Especially since the addrv2 is already varlen
3432018-06-01T14:50:44 <wumpus> (I guess, in a way)
3442018-06-01T14:51:03 <jonasschnelli> >8byte service bits?!... not sure if we ever reach that limit :)
3452018-06-01T14:51:10 <wumpus> yes, decided on varlen because padding everything to 32 bytes would be crazy, and I like not wasting space for v4 addresses
3462018-06-01T14:51:23 <jonasschnelli> Yes. Good point.
3472018-06-01T14:52:01 <jonasschnelli> Another redundant byte is the std::vector<uint8_t> varlen byte
3482018-06-01T14:52:17 <jonasschnelli> But I guess that serialization property we can't change
3492018-06-01T14:52:55 <jonasschnelli> (since the length is indirectly defined by the networkID)
3502018-06-01T14:53:11 *** brianhoffman has left #bitcoin-core-dev
3512018-06-01T14:54:14 *** bitconner has quit IRC
3522018-06-01T15:01:55 *** m8tion has joined #bitcoin-core-dev
3532018-06-01T15:02:08 *** bitconner has joined #bitcoin-core-dev
3542018-06-01T15:05:24 <luke-jr> wumpus: it might be a good idea to include port in addr
3552018-06-01T15:05:44 <luke-jr> hidden services don't have ports IIRC, and non-TCP protocols might not either - or might have 64-bit ports or smth
3562018-06-01T15:06:40 <luke-jr> 32-bit times seem to be dying, but we probably will end up with a new addr message before 2038 I guess
3572018-06-01T15:06:54 <luke-jr> especially if services isn't revised now
3582018-06-01T15:07:20 *** bitconner has quit IRC
3592018-06-01T15:07:21 <jonasschnelli> makes sense to me: putting port into the addr part
3602018-06-01T15:08:52 *** bitconner has joined #bitcoin-core-dev
3612018-06-01T15:13:35 <wumpus> hidden services have ports
3622018-06-01T15:13:50 <wumpus> luke-jr: we could use a VARINT for the time too
3632018-06-01T15:14:07 *** bitconner has quit IRC
3642018-06-01T15:15:26 *** fanquake has quit IRC
3652018-06-01T15:15:34 *** bitconner has joined #bitcoin-core-dev
3662018-06-01T15:15:50 <wumpus> luke-jr: another option would be to lower precision
3672018-06-01T15:16:03 <luke-jr> hmm
3682018-06-01T15:16:05 <luke-jr> or both
3692018-06-01T15:16:31 <luke-jr> epoch 2009 with 1 hour resolution seems plenty
3702018-06-01T15:17:16 <luke-jr> or 90 minutes to be tonal-correct :D
3712018-06-01T15:18:16 *** jhfrontz has quit IRC
3722018-06-01T15:19:06 <wumpus> luke-jr: jonasschnelli: changed them both to VARINT, thanks for the comments
3732018-06-01T15:20:33 *** bitconner has quit IRC
3742018-06-01T15:23:06 *** ken2812221 has joined #bitcoin-core-dev
3752018-06-01T15:24:29 <wumpus> I've added the concern about lowering time precision as well as rolling the port into address into a "considerations" section, I'm not sure about those
3762018-06-01T15:24:56 *** bitconner has joined #bitcoin-core-dev
3772018-06-01T15:29:37 *** bitconner has quit IRC
3782018-06-01T15:29:40 <luke-jr> well, like I said, it's unlikely we'll still be using this BIP in 2038 if it doesn't improve the services field, so 32-bit time probably is fine
3792018-06-01T15:30:08 <luke-jr> and unsigned 32-bit time is actually even 2106, not 2038
3802018-06-01T15:31:58 <wumpus> having always been angry at the people that decided to use two-digit years and gave us the Y2K nonsense, I'm very happy to make it 2038-proof
3812018-06-01T15:33:35 *** bitconner has joined #bitcoin-core-dev
3822018-06-01T15:38:21 *** bitconner has quit IRC
3832018-06-01T15:44:24 *** bitconner has joined #bitcoin-core-dev
3842018-06-01T15:45:23 *** Randolf has quit IRC
3852018-06-01T15:50:27 <gmaxwell> wumpus: cool!
3862018-06-01T15:50:55 *** AaronvanW has quit IRC
3872018-06-01T15:52:09 <gmaxwell> So would this also accomidate I2P? I don't really recall what I2P needed, but I vaguely recall its addresses were 512 bits-ish... though it isn't unlikely that I'm mistaken.
3882018-06-01T15:52:50 *** bitconner has quit IRC
3892018-06-01T15:53:21 <luke-jr> I think that's the goal
3902018-06-01T15:54:04 <gmaxwell> oh nevermind I see there is a section, don't see how I missed it on the first pass.
3912018-06-01T15:54:47 *** cncr04s has quit IRC
3922018-06-01T15:55:55 <wumpus> gmaxwell: yep - I2P is 256 bits
3932018-06-01T15:56:07 *** cncr04s has joined #bitcoin-core-dev
3942018-06-01T15:57:13 <wumpus> (could trivially extend the max length to 512 bits if that turns out to be needed for something, but I like the strict length requirement as it bounds the maximum size of addr messages)
3952018-06-01T15:57:21 <gmaxwell> wumpus: some ideas circulating for nodes that store some fraction of the blockchain (e.g. some FEC slice, as in taek's post, or some range of blocks) need a bit of signaling to encode what is there. With 64 bits of 'services' it could be stuffed there, but I'm not sure if thats what you'd want?
3962018-06-01T15:57:35 <gmaxwell> yes, I like strict length checking too.
3972018-06-01T15:58:18 *** bitconner has joined #bitcoin-core-dev
3982018-06-01T15:58:20 <gmaxwell> wumpus: so would we want to addrv3 for those things, user service bits, or add some opional field mechenism(s)?
3992018-06-01T15:58:37 <luke-jr> gmaxwell: services currently apply an | to the bits, so not useful for multi-bit stuff sadly
4002018-06-01T15:58:39 <wumpus> gmaxwell: that was brought up in the meeting yesterday as well, by sdaftuar , but I'm not sure what that would imply in practice
4012018-06-01T15:59:02 <wumpus> e.g. gossiping block ranges directly would not be useful as the information is outdated by time someone gets it
4022018-06-01T15:59:24 <luke-jr> wumpus: just a seed that nodes can deterministically calculate block numbers from
4032018-06-01T15:59:28 <gmaxwell> wumpus: these wouldn't be outdated by construction.
4042018-06-01T15:59:32 <gmaxwell> as luke-jr says.
4052018-06-01T15:59:37 <wumpus> but if it's some other kind of descriptor, sure, it could be added
4062018-06-01T15:59:41 <gmaxwell> (also, FEC slice proposals don't have that issue)
4072018-06-01T15:59:45 <wumpus> how many bits per address?
4082018-06-01T16:00:24 <gmaxwell> I haven't seen any ideas that need more than 32 bits, most probably need 8-16 bits. Perhaps just stick in a 32 bit field which has a "service flag specific interpertation" ?
4092018-06-01T16:00:28 <luke-jr> there might be a fingerprinting risk here with too many bits, but too few might be an issue for storage too
4102018-06-01T16:00:34 <wumpus> an optional field mechanism could work, but otoh, I'm a bit afraid of overdesign (also: it still has to be bounded)
4112018-06-01T16:00:50 <gmaxwell> luke-jr: yes but leave that problem to the other proposals.
4122018-06-01T16:01:17 <luke-jr> ah, true
4132018-06-01T16:01:45 <wumpus> ah, an optional 32-bit field per service bit?
4142018-06-01T16:02:29 <luke-jr> then I can make a 2k addr message.. :/
4152018-06-01T16:02:33 <gmaxwell> If you care about space time field could be reduced to 16 bits easily. Turn it into a "time ago seen" quantized to 1 hour precision. (IIRC we quantize times to 2hrs regardless).
4162018-06-01T16:03:03 <gmaxwell> wumpus: oh I wasn't thinking of that, I was just thinking of 32 bits whos meaning is defined as "depends on the service bits".
4172018-06-01T16:03:22 <gmaxwell> (e.g. just to take specifying its content out of scope for this BIP)
4182018-06-01T16:03:27 *** bitconner has quit IRC
4192018-06-01T16:04:43 <gmaxwell> having a field per service bit would be nice but unfortunately would allow huge messages.
4202018-06-01T16:06:53 <luke-jr> I suppose nodes could policy-drop the extra data if they don't comprehend it?
4212018-06-01T16:07:05 <gmaxwell> wumpus: is there any particular reason why you have a potentially irrelevant port field, rather than encoding the port in the low bytes of the address as relevant for the service type?
4222018-06-01T16:07:40 <gmaxwell> luke-jr: then you need a mechenism to encode which extra data is there.
4232018-06-01T16:07:53 <luke-jr> gmaxwell: you need that anyway if it's optional?
4242018-06-01T16:08:22 <luke-jr> and it wouldn't make sense to have extra data for most of the current service bits
4252018-06-01T16:08:36 <gmaxwell> luke-jr: right well if we didn't care about size we could just define that every service bit set gets 32 bits of flags. :)
4262018-06-01T16:10:48 <gmaxwell> if we want optional flags. I guess the best thing would just be a byte to include the count of them, then a byte "type" for each one where the type also encodes if the payload is 0/8/16/32 bits. (using the two MSB of the type to encode the length). And then bound the count of them so that the total is still reasonably sized.
4272018-06-01T16:11:13 <gmaxwell> And then define nodes should strip ones they don't understand.
4282018-06-01T16:11:24 <gmaxwell> or something along those lines.
4292018-06-01T16:11:39 *** bitconner has joined #bitcoin-core-dev
4302018-06-01T16:12:23 <wumpus> gmaxwell: yes, making the port optinal or rolling it into addr was mentioned by luke-jr, it's under "considerations", I'm not sure
4312018-06-01T16:12:26 <gmaxwell> If that kind of mechenism existed there might be less argument to make service flags anything but 32 bits?
4322018-06-01T16:13:04 <gmaxwell> wumpus: I don't care one way or another, it would save two bytes when not used, and perhaps eliminate some stupidity of what happens when it's non-zero for I2P or whatever doesn't use it.
4332018-06-01T16:13:06 <wumpus> gmaxwell: at least currently all the mechanisms have a concept of port
4342018-06-01T16:14:04 *** Randolf has joined #bitcoin-core-dev
4352018-06-01T16:14:12 <gmaxwell> My memory of I2P is really bad then.
4362018-06-01T16:14:18 <wumpus> 32 bits "depending on the service bits" would be ok, although it leaves some difficulty if multiple service bits want to use it
4372018-06-01T16:15:25 <wumpus> same here, I intend to run this by one of the I2P devs before publishing it anyhow
4382018-06-01T16:15:30 *** brianhoffman has joined #bitcoin-core-dev
4392018-06-01T16:16:26 <gmaxwell> Beyond node-flavors for striping, another thing we might want more payload for is alternative ports for other transports. E.g. if later we define a bitcoin-over-udp we might want to signal the ports for that instead of sending two addr messages for the two endpoints. I'm not currently remembering any other service flag things where we've wanted other payload.
4402018-06-01T16:16:40 <gmaxwell> but I'm sure we could come up with other ones.
4412018-06-01T16:16:47 *** bitconner has quit IRC
4422018-06-01T16:17:40 <gmaxwell> I don't feel that strongly about any of this of course, if we're too limited it's not like it's a big deal to define an addr3.
4432018-06-01T16:18:12 <wumpus> we already send multiple addr messages when listening to multiple interfaces
4442018-06-01T16:18:36 *** bitconner has joined #bitcoin-core-dev
4452018-06-01T16:19:35 <wumpus> but indeed there's a lot of reasons adding service-specfic information to gossiping would potentiall be useful, even though we have none at the moment
4462018-06-01T16:19:39 <gmaxwell> yes though it would be really inefficient if almost every node were doing it.
4472018-06-01T16:19:54 <gmaxwell> (sending a whole seperate addr just to give another 16 bit port number)
4482018-06-01T16:20:05 <wumpus> yes
4492018-06-01T16:23:13 <wumpus> there's risk of combinatorial blowup there
4502018-06-01T16:23:32 <wumpus> that's a good argument for encoding the port separately though
4512018-06-01T16:23:51 <wumpus> that extends better to having multiple ports
4522018-06-01T16:24:02 *** bitconner has quit IRC
4532018-06-01T16:24:03 <gmaxwell> one could use the above mechenism of a <type/length> byte followed by payload to do the port.
4542018-06-01T16:24:37 <wumpus> yes
4552018-06-01T16:26:40 <wumpus> that's a good idea, I think
4562018-06-01T16:27:24 <wumpus> though it increases the average size, port is only 2 bytes, making it a 'data item' will by definition be larger
4572018-06-01T16:28:20 <gmaxwell> Yes, though it's two bytes overhead assuming you used my above suggestion and had no other data items.
4582018-06-01T16:28:21 *** bitconner has joined #bitcoin-core-dev
4592018-06-01T16:28:42 <gmaxwell> One byte overhead if you had other data items.
4602018-06-01T16:29:00 <wumpus> true, I just mean in practice, everything will be sending a port
4612018-06-01T16:29:08 <gmaxwell> And I think if the data item mechenism existed service bits could stay 32 bits, saving a byte.
4622018-06-01T16:30:06 <gmaxwell> or you keep the port field (or merge into the variable length addresses) for the primary port to get that savings.
4632018-06-01T16:30:32 <wumpus> aren't service bits 64 bits right now?
4642018-06-01T16:30:49 <gmaxwell> oh. hm! I thought they were 32bits!
4652018-06-01T16:31:02 <gmaxwell> nope, 64.
4662018-06-01T16:31:06 <wumpus> I thought so too yesterday
4672018-06-01T16:31:28 <wumpus> that's why Jonas proposed turning it into a VARINT, which I did
4682018-06-01T16:32:42 <sipa> they're 64 bits now
4692018-06-01T16:33:47 *** bitconner has quit IRC
4702018-06-01T16:36:21 <wumpus> I wonder if CJDNS should get its own network id, the reason I'm not sure is because they're explicitly IPv6 addresses
4712018-06-01T16:37:38 *** arubi has quit IRC
4722018-06-01T16:38:43 *** Victorsueca has quit IRC
4732018-06-01T16:38:44 <gmaxwell> I suspect it should, since you can't reach them unless you use CJDNS? so it's like onion embedded tor?
4742018-06-01T16:39:08 *** arubi has joined #bitcoin-core-dev
4752018-06-01T16:39:54 *** Victorsueca has joined #bitcoin-core-dev
4762018-06-01T16:40:44 <sipa> yeah, i good criterion for separate networks would be whether they need separate routing
4772018-06-01T16:41:29 <wumpus> gmaxwell: that's true; the differece is that cjdns runs as a network interface, so from the viewpoint of the application it's simply IPv6 networking. OTOH it's possible to set up the firewall to do the same with TOr, so I'm not sure it's a useful distinction for this.
4782018-06-01T16:41:52 *** bitconner has joined #bitcoin-core-dev
4792018-06-01T16:41:58 <wumpus> so yes, better to just add a n ID, they're cheap
4802018-06-01T16:46:40 *** bitconner has quit IRC
4812018-06-01T16:47:44 *** bitconner has joined #bitcoin-core-dev
4822018-06-01T16:47:59 *** Dizzle has joined #bitcoin-core-dev
4832018-06-01T16:52:35 *** bitconner has quit IRC
4842018-06-01T16:55:03 *** bitconner has joined #bitcoin-core-dev
4852018-06-01T16:59:50 *** bitconner has quit IRC
4862018-06-01T17:03:12 *** jhfrontz has joined #bitcoin-core-dev
4872018-06-01T17:09:27 *** bitconner has joined #bitcoin-core-dev
4882018-06-01T17:13:57 *** bitconner has quit IRC
4892018-06-01T17:15:58 *** justan0theruser has quit IRC
4902018-06-01T17:22:22 *** justan0theruser has joined #bitcoin-core-dev
4912018-06-01T17:24:26 *** bitconner has joined #bitcoin-core-dev
4922018-06-01T17:26:51 <wumpus> I guess we could save 6 bytes per Tor v2 address by not doing the onioncat thing (otoh, who's going to care about that going forward)
4932018-06-01T17:28:56 <gmaxwell> ah, just don't onioncat embed them. that would be nice. though who cares much about tor v2.
4942018-06-01T17:29:47 *** bitconner has quit IRC
4952018-06-01T17:31:03 <bitcoin-git> [bitcoin] MarcoFalke opened pull request #13367: qa: Increase includeconf test coverage (master...Mf1806-qaIncludeconf) https://github.com/bitcoin/bitcoin/pull/13367
4962018-06-01T17:31:51 <gmaxwell> I assume that within a couple years we'll stop forwarding torv2 completely.
4972018-06-01T17:32:49 *** vicenteH has quit IRC
4982018-06-01T17:36:13 <sipa> wumpus: for simplicity, i think it makes sense to put tor v2 in a separate class
4992018-06-01T17:36:18 <sipa> it needs separate routing after all
5002018-06-01T17:36:52 <wumpus> sipa: that's what I've done, I just kept the onioncat wrapping (so addresses are 16 bytes not 10)
5012018-06-01T17:37:02 *** bitconner has joined #bitcoin-core-dev
5022018-06-01T17:37:28 <wumpus> gmaxwell: exactly my point, we don't really want to encourage torv2 after this work we're doing to support torv3 which is better in any way
5032018-06-01T17:37:49 <sipa> wumpus: sorry, i should read first
5042018-06-01T17:41:38 *** bitconner has quit IRC
5052018-06-01T17:45:24 *** timothy has quit IRC
5062018-06-01T17:51:58 *** bitconner has joined #bitcoin-core-dev
5072018-06-01T17:56:59 *** bitconner has quit IRC
5082018-06-01T18:04:29 *** bitconner has joined #bitcoin-core-dev
5092018-06-01T18:08:31 <bitcoin-git> [bitcoin] achow101 opened pull request #13368: Update gitian-build.sh for docker (master...gitian-docker) https://github.com/bitcoin/bitcoin/pull/13368
5102018-06-01T18:08:57 *** bitconner has quit IRC
5112018-06-01T18:14:08 *** bitconner has joined #bitcoin-core-dev
5122018-06-01T18:21:25 *** bitconner has quit IRC
5132018-06-01T18:25:28 <bitcoin-git> [bitcoin] mess110 closed pull request #13364: update transifex doc links (master...fix_transifex_client_config_link) https://github.com/bitcoin/bitcoin/pull/13364
5142018-06-01T18:27:05 *** bitconner has joined #bitcoin-core-dev
5152018-06-01T18:28:33 <bitcoin-git> [bitcoin] mess110 opened pull request #13369: [docs] update transifex doc link (master...fix_transifex_doc_link) https://github.com/bitcoin/bitcoin/pull/13369
5162018-06-01T18:31:02 <echeveria> wumpus: cjd is pretty much exclusively ipv6 in their own range.
5172018-06-01T18:31:27 <echeveria> it's really kind of its own net because you can't reach any of the peers any other way.
5182018-06-01T18:31:45 *** bitconner has quit IRC
5192018-06-01T18:33:53 <wumpus> echeveria: indeed, there are no 'exit nodes'
5202018-06-01T18:36:23 *** bitconner has joined #bitcoin-core-dev
5212018-06-01T18:41:10 *** bitconner has quit IRC
5222018-06-01T18:41:57 *** mess110 has quit IRC
5232018-06-01T18:48:41 *** bitconner has joined #bitcoin-core-dev
5242018-06-01T18:51:01 *** HFRadical has joined #bitcoin-core-dev
5252018-06-01T18:51:03 *** HFRadical has quit IRC
5262018-06-01T18:53:46 *** bitconner has quit IRC
5272018-06-01T18:55:32 *** bitconner has joined #bitcoin-core-dev
5282018-06-01T19:00:10 *** bitconner has quit IRC
5292018-06-01T19:02:33 *** bitconner has joined #bitcoin-core-dev
5302018-06-01T19:07:15 *** bitconner has quit IRC
5312018-06-01T19:07:33 *** bitconner has joined #bitcoin-core-dev
5322018-06-01T19:10:42 *** bitconner has quit IRC
5332018-06-01T19:14:15 *** Randolf has quit IRC
5342018-06-01T19:15:54 *** Randolf has joined #bitcoin-core-dev
5352018-06-01T19:17:42 *** promag_ has joined #bitcoin-core-dev
5362018-06-01T19:18:36 *** promag has joined #bitcoin-core-dev
5372018-06-01T19:19:09 *** bitconner has joined #bitcoin-core-dev
5382018-06-01T19:19:33 *** promag has quit IRC
5392018-06-01T19:20:13 <gmaxwell> cfields: re: the 4/8-way sse/avx hash calculator, one of the reasons why txid computation is a little less interesting other than the complication, is that it's not in the critical path for HB block relay, but tree computation is.
5402018-06-01T19:20:50 *** Randolf has quit IRC
5412018-06-01T19:21:03 <gmaxwell> and so sipa's PR drops HB relay about 5ms per hop, which is a pretty large fraction of the total processing time.
5422018-06-01T19:21:09 *** promag has joined #bitcoin-core-dev
5432018-06-01T19:22:05 *** promag_ has quit IRC
5442018-06-01T19:22:28 *** Randolf has joined #bitcoin-core-dev
5452018-06-01T19:23:39 *** promag__ has joined #bitcoin-core-dev
5462018-06-01T19:25:27 *** promag has quit IRC
5472018-06-01T19:25:29 *** promag__ has quit IRC
5482018-06-01T19:27:40 *** Victorsueca has quit IRC
5492018-06-01T19:28:48 *** Victorsueca has joined #bitcoin-core-dev
5502018-06-01T19:30:35 *** bitconner has quit IRC
5512018-06-01T19:30:44 *** bitconner has joined #bitcoin-core-dev
5522018-06-01T19:43:38 *** drexl has joined #bitcoin-core-dev
5532018-06-01T19:46:17 *** bitconner has quit IRC
5542018-06-01T19:46:39 *** bitconner has joined #bitcoin-core-dev
5552018-06-01T19:47:28 *** SopaXorzTaker has quit IRC
5562018-06-01T19:55:21 *** bitconner has quit IRC
5572018-06-01T19:56:10 *** bitconner has joined #bitcoin-core-dev
5582018-06-01T19:58:27 *** domble has joined #bitcoin-core-dev
5592018-06-01T20:04:34 *** bitconner has quit IRC
5602018-06-01T20:05:09 *** bitconner has joined #bitcoin-core-dev
5612018-06-01T20:05:49 *** laurentmt has joined #bitcoin-core-dev
5622018-06-01T20:06:52 *** AaronvanW has joined #bitcoin-core-dev
5632018-06-01T20:11:42 *** laurentmt has quit IRC
5642018-06-01T20:11:57 *** bitconner has quit IRC
5652018-06-01T21:03:23 *** luke-jr has quit IRC
5662018-06-01T21:03:32 *** luke-jr has joined #bitcoin-core-dev
5672018-06-01T21:06:14 *** justan0theruser has quit IRC
5682018-06-01T21:07:00 *** justanotheruser has joined #bitcoin-core-dev
5692018-06-01T21:26:14 *** promag has joined #bitcoin-core-dev
5702018-06-01T21:34:51 *** Guyver2 has quit IRC
5712018-06-01T21:46:58 <sipa> wumpus: thanks, read the BIP draft now
5722018-06-01T21:47:40 <sipa> it seems strange to use the onioncat embedded for tor v2, if there is a separate network type anyway (it just burdens clients to add/strip/check it )
5732018-06-01T21:48:08 <sipa> varint for 64-bit services... it saves a bit, but they're already 64 bits, and varint can't actually encode anything longer than 64 bits
5742018-06-01T21:48:13 *** vicenteH has joined #bitcoin-core-dev
5752018-06-01T21:52:44 <promag> should unloadwallet PR include UI support so that unloaded wallets are removed?
5762018-06-01T21:57:37 *** bitconner has joined #bitcoin-core-dev
5772018-06-01T21:57:58 <gojo> What tools you are using for debug view uint256?
5782018-06-01T21:59:33 <sipa> it has a GetHex() method for converting to a string
5792018-06-01T22:01:14 <gojo> I mean inside gdb UI
5802018-06-01T22:01:38 <gojo> i use GetHex() method for debug txdb my fork bugs
5812018-06-01T22:02:24 <gojo> I join my own live logging tool for structured logs for fix complex bugs
5822018-06-01T22:02:37 <gojo> I can share my code if needed
5832018-06-01T22:04:07 <gojo> I looking for another way with gdbgui React debug widget
5842018-06-01T22:04:55 <sipa> print pindexBestHeader->phashBlock->GetHex()
5852018-06-01T22:05:11 <sipa> $3 = '0' <repeats 18 times>, "2521d8eb85294864f937918dcbdcc33f42ab0c55c5d5b9"
5862018-06-01T22:06:21 <gojo> Not very optimal with hidden bugs in 100k blocks. I'm looking for something more easy
5872018-06-01T22:06:33 <sipa> i'm not sure what you're asking for
5882018-06-01T22:07:23 <gojo> 1. gdb vars view is wrong for uint256
5892018-06-01T22:07:55 <gojo> 2. gdbgui require React dev for uint256, reason, but not much time for that
5902018-06-01T22:08:16 <sipa> i don't understand that
5912018-06-01T22:08:27 <sipa> what is react?
5922018-06-01T22:08:33 <gojo> 3. my own logging solution is very slow when txdb has bug in 100k+ blocks
5932018-06-01T22:08:47 <gojo> do you know gdbgui?
5942018-06-01T22:08:50 <sipa> no
5952018-06-01T22:09:06 <gojo> https://github.com/cs01/gdbgui
5962018-06-01T22:09:19 <sipa> but what are you trying to achieve?
5972018-06-01T22:09:35 <gojo> well customized browser frontend for gdb
5982018-06-01T22:09:52 <sipa> i know uint256's internal view doesn't match the normal human readable form (your point 1), but i gave you the solution (use print ....GetHex())
5992018-06-01T22:09:54 <gojo> i need for debug my fork step by step each line for 100k blocks
6002018-06-01T22:10:03 <sipa> good luck then
6012018-06-01T22:10:15 <gojo> thanks
6022018-06-01T22:10:37 <gojo> i'm have solution that maybe helps someone
6032018-06-01T22:10:41 *** Chris_Stewart_5 has quit IRC
6042018-06-01T22:11:07 <gojo> i made several forks for Dash, Komodo etc
6052018-06-01T22:11:16 <sipa> off topic here
6062018-06-01T22:11:30 <gojo> btc-core is not offtopic
6072018-06-01T22:11:42 <gojo> i have a logging system for bitcoin-core
6082018-06-01T22:11:52 <gojo> i want to share it for made life easier
6092018-06-01T22:11:56 <sipa> ok
6102018-06-01T22:12:09 <gojo> but maybe someone has better solution
6112018-06-01T22:12:19 <sipa> feel free to open a pull request to improve logging, if you have useful code
6122018-06-01T22:12:22 <sipa> that sounds very welcome
6132018-06-01T22:13:25 <gojo> ok, understand, thanks
6142018-06-01T22:30:43 *** bitconner has quit IRC
6152018-06-01T22:32:09 *** bitconner has joined #bitcoin-core-dev
6162018-06-01T22:42:26 *** lxer has quit IRC
6172018-06-01T22:53:55 *** Victorsueca has quit IRC
6182018-06-01T22:55:26 *** Victorsueca has joined #bitcoin-core-dev
6192018-06-01T22:57:41 *** Randolf has quit IRC
6202018-06-01T23:01:23 *** AaronvanW has quit IRC
6212018-06-01T23:08:51 *** jhfrontz has quit IRC
6222018-06-01T23:10:29 *** lobo_ has joined #bitcoin-core-dev
6232018-06-01T23:11:50 *** lobo_ has quit IRC
6242018-06-01T23:12:04 *** AaronvanW has joined #bitcoin-core-dev
6252018-06-01T23:17:01 *** AaronvanW has quit IRC
6262018-06-01T23:17:28 *** Chris_Stewart_5 has joined #bitcoin-core-dev
6272018-06-01T23:20:50 *** gojo has quit IRC
6282018-06-01T23:32:04 *** AaronvanW has joined #bitcoin-core-dev
6292018-06-01T23:33:05 *** Dizzle has quit IRC
6302018-06-01T23:34:35 *** promag has quit IRC
6312018-06-01T23:36:25 *** roidster has joined #bitcoin-core-dev