12018-05-28T00:00:31 *** belcher has joined #bitcoin-core-dev
22018-05-28T00:03:22 *** bitconner has quit IRC
32018-05-28T00:14:50 *** vicenteH has quit IRC
42018-05-28T00:19:26 *** promag has quit IRC
52018-05-28T00:47:53 *** Chris_Stewart_5 has joined #bitcoin-core-dev
62018-05-28T00:49:54 *** promag has joined #bitcoin-core-dev
72018-05-28T01:10:42 *** AaronvanW has joined #bitcoin-core-dev
82018-05-28T01:11:59 *** Aaronvan_ has joined #bitcoin-core-dev
92018-05-28T01:15:27 *** AaronvanW has quit IRC
102018-05-28T01:19:06 *** satwo has quit IRC
112018-05-28T01:21:09 *** satwo has joined #bitcoin-core-dev
122018-05-28T01:22:18 <Chris_Stewart_5> is it possible to compile secp256k1 on windows with jni enabled?
132018-05-28T01:23:46 *** Posix has joined #bitcoin-core-dev
142018-05-28T01:33:55 *** satwo has quit IRC
152018-05-28T01:35:13 *** jrayhawk has quit IRC
162018-05-28T01:36:05 *** jrayhawk has joined #bitcoin-core-dev
172018-05-28T01:40:20 *** Sinclair_ has quit IRC
182018-05-28T01:40:48 *** Victorsueca has quit IRC
192018-05-28T01:41:00 *** Posix has quit IRC
202018-05-28T01:42:20 *** Victorsueca has joined #bitcoin-core-dev
212018-05-28T01:44:53 *** TannerR has joined #bitcoin-core-dev
222018-05-28T02:01:12 *** jtimon has quit IRC
232018-05-28T02:13:55 *** bitconner has joined #bitcoin-core-dev
242018-05-28T02:14:02 *** CubicEarths has quit IRC
252018-05-28T02:14:40 *** CubicEarths has joined #bitcoin-core-dev
262018-05-28T02:18:46 *** bitconner has quit IRC
272018-05-28T02:28:35 *** goatpig has quit IRC
282018-05-28T02:29:03 *** Aaronvan_ has quit IRC
292018-05-28T02:39:43 *** satwo has joined #bitcoin-core-dev
302018-05-28T02:53:05 *** TannerR has quit IRC
312018-05-28T03:07:17 *** Krellan has quit IRC
322018-05-28T03:12:44 *** bitconner has joined #bitcoin-core-dev
332018-05-28T03:19:51 *** bitbee has quit IRC
342018-05-28T03:19:51 *** satwo has quit IRC
352018-05-28T03:20:51 *** bitbee has joined #bitcoin-core-dev
362018-05-28T03:25:18 *** TannerR has joined #bitcoin-core-dev
372018-05-28T03:27:30 *** TannerR has quit IRC
382018-05-28T03:33:02 *** satwo has joined #bitcoin-core-dev
392018-05-28T03:35:45 <achow101> jhfrontz: it does 'sudo apt-get' to install a few packages that you need. you can either run the script as sudo or just find the 'sudo apt-get' lines in the script and run them yourself (I recommend that you do this) to install the packges
402018-05-28T03:36:15 <achow101> if you run the entire script as sudo, all of the folders and files that are created will be owned by root
412018-05-28T03:53:08 *** Krellan has joined #bitcoin-core-dev
422018-05-28T03:55:53 *** contrapumpkin has quit IRC
432018-05-28T04:00:29 *** BullShark has quit IRC
442018-05-28T04:04:19 *** rex4539 has joined #bitcoin-core-dev
452018-05-28T04:45:59 *** satwo has quit IRC
462018-05-28T05:26:26 <mryandao> is there any reason why core continues to use boost::chrono as oppose to chrono in the standard library? or this is one of the items where a refactor is welcomed?
472018-05-28T05:32:45 *** Chris_Stewart_5 has quit IRC
482018-05-28T05:54:33 *** adam3us_ has quit IRC
492018-05-28T05:54:33 *** warren has quit IRC
502018-05-28T06:07:35 *** Krellan has quit IRC
512018-05-28T06:08:06 *** Krellan has joined #bitcoin-core-dev
522018-05-28T06:27:19 <kallewoof> mryandao: "if you don't need that additional io functions and don't need c++03 support, use standard library" (https://stackoverflow.com/questions/21559455/c-stdchrono-or-boostchrono) -- I think a refactor is welcomed. :)
532018-05-28T06:27:47 *** rex4539 has quit IRC
542018-05-28T06:28:30 *** rex4539 has joined #bitcoin-core-dev
552018-05-28T06:29:11 *** rex4539 has quit IRC
562018-05-28T06:29:41 *** rex4539 has joined #bitcoin-core-dev
572018-05-28T06:30:31 *** lxer has joined #bitcoin-core-dev
582018-05-28T06:30:49 *** rex4539 has joined #bitcoin-core-dev
592018-05-28T06:43:20 *** tryphe_ has quit IRC
602018-05-28T06:43:58 *** tryphe has joined #bitcoin-core-dev
612018-05-28T07:02:08 <sipa> mryandao: i believe cfields has some.ongoing work to get rid of it
622018-05-28T07:02:18 <sipa> but i'm not sure of the status
632018-05-28T07:06:36 *** Krellan has quit IRC
642018-05-28T07:16:37 <mryandao> oh, i just did an update today and it pains me to need to install that 100MB+ of libboost to compile bitcoin-core
652018-05-28T07:16:51 <mryandao> hence I asked.
662018-05-28T07:18:41 *** promag has quit IRC
672018-05-28T07:18:55 *** promag has joined #bitcoin-core-dev
682018-05-28T07:18:58 *** bitconner has quit IRC
692018-05-28T07:20:23 *** promag has quit IRC
702018-05-28T07:21:31 <wumpus> I think we're also quite near to being able to get rid of boost::thread
712018-05-28T07:23:53 *** promag has joined #bitcoin-core-dev
722018-05-28T07:27:25 *** bitconner has joined #bitcoin-core-dev
732018-05-28T07:28:38 *** promag has quit IRC
742018-05-28T07:32:32 <wumpus> just hiaving to install the boost libraries isn't so bad, you don't *need* all 100MB+ just a few libraries as described in doc/build-unix.md, I think my biggest practical gripe about boost is the unrelible pile of hacks needed to use it in the build system. So many reported issues about not being able to find it, or the right version. esp the boost::sleep
752018-05-28T07:32:49 *** bitconner has quit IRC
762018-05-28T07:33:23 <mryandao> boost::thread alone had 100MB+ of dependencies
772018-05-28T07:34:14 <mryandao> the rest were ok, or by the time all the dependencies were installed, it was pretty much all of libboost
782018-05-28T07:36:00 <wumpus> that's simply not true
792018-05-28T07:37:15 <wumpus> libboost includes tons of stuff (like parsing, physics computation/units), that we don't use. Our use is very targeted and has become a smaller and smaller part over the years.
802018-05-28T07:37:42 <wumpus> you can check the gitian descriptor to see how by far most of the build is disabled
812018-05-28T07:38:32 <wumpus> boost itself has no dependencies outside of boost and the C and C++ basic library (boost::thread will use pthread)
822018-05-28T07:39:11 <mryandao> weird, unless apt-get by default packages all of them together?
832018-05-28T07:39:26 <mryandao> i did put down the `apt-get install libboost-thread-dev`
842018-05-28T07:39:31 <wumpus> I'm all for moving away from boost, over time, but these kinds of cheap digs at the library annoy me too
852018-05-28T07:41:08 <wumpus> strange - I'd write that up to debian instead of fundamental thing with boost itself
862018-05-28T07:42:26 <wumpus> in any case, feel free to help in the move forward to get rid of the boost::thread dependency, it shouldn't be too much work now
872018-05-28T07:49:39 <mryandao> wumpus: cool, thanks.
882018-05-28T07:53:25 <wumpus> see also #12381
892018-05-28T07:53:28 <gribble> https://github.com/bitcoin/bitcoin/issues/12381 | Remove more boost threads by theuni · Pull Request #12381 · bitcoin/bitcoin · GitHub
902018-05-28T07:56:42 *** harrymm has quit IRC
912018-05-28T07:58:23 *** harrymm has joined #bitcoin-core-dev
922018-05-28T08:07:07 *** Krellan has joined #bitcoin-core-dev
932018-05-28T08:09:26 <94KAACTBR> [bitcoin] laanwj pushed 9 new commits to 0.16: https://github.com/bitcoin/bitcoin/compare/50b2c9e0dfbe...bfd1e923335e
942018-05-28T08:09:26 <7YSAAYFCN> [bitcoin] laanwj closed pull request #13317: [0.16.1] Remaining backports (0.16...Mf1805-016ForBackport) https://github.com/bitcoin/bitcoin/pull/13317
952018-05-28T08:09:27 <94KAACTBR> bitcoin/0.16 c71e535 Suhas Daftuar: Bugfix: ensure consistency of m_failed_blocks after reconsiderblock...
962018-05-28T08:09:27 <94KAACTBR> bitcoin/0.16 0948153 Matt Corallo: Do not unlock cs_main in ABC unless we've actually made progress....
972018-05-28T08:09:28 <94KAACTBR> bitcoin/0.16 bb79aaf Jesse Cohen: Fix concurrency-related bugs in ActivateBestChain...
982018-05-28T08:09:28 <gribble> https://github.com/bitcoin/bitcoin/issues/13317 | [0.16.1] Remaining backports by MarcoFalke · Pull Request #13317 · bitcoin/bitcoin · GitHub
992018-05-28T08:09:34 *** setpill has joined #bitcoin-core-dev
1002018-05-28T08:13:54 *** Krellan has quit IRC
1012018-05-28T08:29:08 <bitcoin-git> [bitcoin] eklitzke opened pull request #13335: Implement pinentry wrapper to unlock bitcoin wallet (master...pinentry) https://github.com/bitcoin/bitcoin/pull/13335
1022018-05-28T08:33:13 *** promag has joined #bitcoin-core-dev
1032018-05-28T08:35:53 *** JackH has joined #bitcoin-core-dev
1042018-05-28T08:42:25 *** tum has joined #bitcoin-core-dev
1052018-05-28T08:43:43 *** timothy has joined #bitcoin-core-dev
1062018-05-28T08:48:10 *** drizztbsd has joined #bitcoin-core-dev
1072018-05-28T08:48:37 *** timothy has quit IRC
1082018-05-28T08:52:05 *** drizztbsd is now known as timothy
1092018-05-28T08:52:33 *** berndj has quit IRC
1102018-05-28T08:54:08 *** berndj has joined #bitcoin-core-dev
1112018-05-28T08:57:42 *** raarr has quit IRC
1122018-05-28T09:07:22 *** bitconner has joined #bitcoin-core-dev
1132018-05-28T09:10:21 *** berndj has quit IRC
1142018-05-28T09:13:28 *** berndj has joined #bitcoin-core-dev
1152018-05-28T09:20:07 *** satwo has joined #bitcoin-core-dev
1162018-05-28T09:24:25 *** owowo has quit IRC
1172018-05-28T09:25:28 *** owowo has joined #bitcoin-core-dev
1182018-05-28T09:28:25 * midnightmagic will love whoever it is, forever, who removed boost entirely as a dependency for bitcoin. :)
1192018-05-28T09:39:15 *** fanquake has joined #bitcoin-core-dev
1202018-05-28T09:39:26 <fanquake> wumpus I think #13319 should be ready as well.
1212018-05-28T09:39:28 <gribble> https://github.com/bitcoin/bitcoin/issues/13319 | [0.16.1] gui: Backport bech32 checkbox by MarcoFalke · Pull Request #13319 · bitcoin/bitcoin · GitHub
1222018-05-28T09:41:17 *** jtimon has joined #bitcoin-core-dev
1232018-05-28T09:49:17 *** arowser has quit IRC
1242018-05-28T09:49:35 *** arowser has joined #bitcoin-core-dev
1252018-05-28T09:51:47 *** Victorsueca has quit IRC
1262018-05-28T09:52:25 *** cdecker has joined #bitcoin-core-dev
1272018-05-28T09:52:47 *** arowser_ has joined #bitcoin-core-dev
1282018-05-28T09:52:59 *** Victorsueca has joined #bitcoin-core-dev
1292018-05-28T09:53:39 *** wallet42_ has joined #bitcoin-core-dev
1302018-05-28T09:55:50 *** berndj has quit IRC
1312018-05-28T09:56:22 *** RoBz_ has joined #bitcoin-core-dev
1322018-05-28T09:57:16 *** kinlo_ has joined #bitcoin-core-dev
1332018-05-28T09:57:34 *** berndj has joined #bitcoin-core-dev
1342018-05-28T10:01:16 *** arowser has quit IRC
1352018-05-28T10:01:16 *** jtimon has quit IRC
1362018-05-28T10:01:16 *** herzmeister[m] has quit IRC
1372018-05-28T10:01:16 *** RoBz has quit IRC
1382018-05-28T10:01:16 *** wallet42 has quit IRC
1392018-05-28T10:01:17 *** baldur has quit IRC
1402018-05-28T10:01:18 *** nsh has quit IRC
1412018-05-28T10:01:18 *** kinlo has quit IRC
1422018-05-28T10:01:21 *** wallet42_ is now known as wallet42
1432018-05-28T10:01:22 *** kinlo_ is now known as kinlo
1442018-05-28T10:03:27 *** Dyaheon has quit IRC
1452018-05-28T10:06:32 *** Dyaheon has joined #bitcoin-core-dev
1462018-05-28T10:08:00 <bitcoin-git> [bitcoin] laanwj pushed 4 new commits to 0.16: https://github.com/bitcoin/bitcoin/compare/bfd1e923335e...07fb2a6e166f
1472018-05-28T10:08:01 <bitcoin-git> bitcoin/0.16 ea487f9 Luke Dashjr: GUI: Rephrase Bech32 checkbox text/tooltip...
1482018-05-28T10:08:02 <bitcoin-git> bitcoin/0.16 0eda98d Luke Dashjr: GUI: Allow generating Bech32 addresses with a legacy-address default...
1492018-05-28T10:08:02 <bitcoin-git> bitcoin/0.16 dcb13a0 MarcoFalke: qt: Update translations pre-rc1
1502018-05-28T10:08:22 *** baldur has joined #bitcoin-core-dev
1512018-05-28T10:09:38 <wumpus> fanquake: does that mean we can roll 0.16.0rc1 today?
1522018-05-28T10:09:46 <wumpus> 0.16.1rc1
1532018-05-28T10:09:56 *** herzmeister[m] has joined #bitcoin-core-dev
1542018-05-28T10:10:02 *** nsh- has joined #bitcoin-core-dev
1552018-05-28T10:14:26 <fanquake> wumpus I think we're pretty close. The only thing left tagged for 0.16.1 is #12337, but I don't think we're fixing that now
1562018-05-28T10:14:27 <gribble> https://github.com/bitcoin/bitcoin/issues/12337 | 0.16 Shutdown assertion · Issue #12337 · bitcoin/bitcoin · GitHub
1572018-05-28T10:15:09 <wumpus> was just looking at that - I don't think it has to block anything
1582018-05-28T10:15:54 <fanquake> Yep, I think an rc1 can move ahead. Can always be fixed if it comes up again during testing
1592018-05-28T10:17:06 <fanquake> Have updated all the projects and un-tagged backports etc.
1602018-05-28T10:17:45 *** satwo has quit IRC
1612018-05-28T10:17:46 *** m8tion has joined #bitcoin-core-dev
1622018-05-28T10:23:49 *** belcher has quit IRC
1632018-05-28T10:27:46 *** Austen58Grimes has joined #bitcoin-core-dev
1642018-05-28T10:36:47 <wumpus> thanks!
1652018-05-28T11:00:27 *** jtimon has joined #bitcoin-core-dev
1662018-05-28T11:06:17 <provoostenator> I'd like to get #11658 in if that's still possible.
1672018-05-28T11:06:20 <gribble> https://github.com/bitcoin/bitcoin/issues/11658 | During IBD, when doing pruning, prune 10% extra to avoid pruning again soon after by luke-jr · Pull Request #11658 · bitcoin/bitcoin · GitHub
1682018-05-28T11:06:53 <luke-jr> not sure it's a bugfix
1692018-05-28T11:07:04 *** zautomata has quit IRC
1702018-05-28T11:07:27 *** AaronvanW has joined #bitcoin-core-dev
1712018-05-28T11:07:37 <provoostenator> Oh is 0.16.1 purely backports and not masteR?
1722018-05-28T11:07:50 <provoostenator> In that case it can wait for 0.17
1732018-05-28T11:08:17 <fanquake> provoostenator correct, https://github.com/bitcoin/bitcoin/tree/0.16
1742018-05-28T11:08:27 <luke-jr> the 3rd number of a version is always for bugfixes (and in our case, consensus protocol updates)
1752018-05-28T11:11:21 <wumpus> I'd say that one is not urgent enough to hold up 0.16.1, certainly not right now, there has been enough time to propose that one in the meetings of last weeks, or at other times
1762018-05-28T11:13:52 <fanquake> wumpus will you tag an rc tonight?
1772018-05-28T11:15:11 *** BullShark has joined #bitcoin-core-dev
1782018-05-28T11:27:04 *** harrymm has quit IRC
1792018-05-28T11:32:41 *** arowser_ has quit IRC
1802018-05-28T11:32:58 *** arowser_ has joined #bitcoin-core-dev
1812018-05-28T11:34:56 <wumpus> fanquake: I'm working on doing last-minute checks now
1822018-05-28T11:35:36 <fanquake> wumpus: np, let me know if you need a hand with anything. I'll be up for another couple hours.
1832018-05-28T11:35:49 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to 0.16: https://github.com/bitcoin/bitcoin/compare/07fb2a6e166f...81bc9829cdaf
1842018-05-28T11:35:50 <bitcoin-git> bitcoin/0.16 b42c355 Wladimir J. van der Laan: qt: Pre-rc1 transifex pull...
1852018-05-28T11:35:50 <bitcoin-git> bitcoin/0.16 81bc982 Wladimir J. van der Laan: build: Bump version to 0.16.1...
1862018-05-28T11:38:37 *** Sinclair_ has joined #bitcoin-core-dev
1872018-05-28T11:39:02 <wumpus> fanquake: just trying to build on a few platforms would help
1882018-05-28T11:39:53 *** harrymm has joined #bitcoin-core-dev
1892018-05-28T11:40:28 <fanquake> wumpus: I'll start building 81bc982
1902018-05-28T11:43:13 *** Sinclair_ has quit IRC
1912018-05-28T11:43:59 *** fanquake has quit IRC
1922018-05-28T11:44:05 *** promag has quit IRC
1932018-05-28T11:44:58 *** fanquake has joined #bitcoin-core-dev
1942018-05-28T11:49:08 *** berndj has quit IRC
1952018-05-28T11:52:01 <wumpus> are you going to try OpenBSD?
1962018-05-28T11:52:37 <fanquake> wumpus I can do, it'll probably be 6.2 though
1972018-05-28T11:52:48 <fanquake> Haven't setup a 6.3 VM yet
1982018-05-28T11:53:32 <wumpus> I asked because I have the same problem, I should just be non-lazy and upgrade my VM
1992018-05-28T11:53:51 *** berndj has joined #bitcoin-core-dev
2002018-05-28T11:54:10 <wumpus> at least freebsd is still 11.1, I'll do that one
2012018-05-28T11:59:13 <fanquake> wumpus How about your Windows Vista VM :p
2022018-05-28T12:03:10 <wumpus> you mean the windows XP one? :-)
2032018-05-28T12:03:33 *** SopaXorzTaker has joined #bitcoin-core-dev
2042018-05-28T12:04:50 <fanquake> wumpus You are welcome to test, but we ditched XP with 0.16 :0
2052018-05-28T12:05:49 *** mistergold has joined #bitcoin-core-dev
2062018-05-28T12:06:29 <luke-jr> sigh, btrfs really does suck
2072018-05-28T12:06:57 <fanquake> I think we could backport #13246 for 0.16, worthwhile improvements to the Windows build process.
2082018-05-28T12:06:59 <gribble> https://github.com/bitcoin/bitcoin/issues/13246 | doc: Bump to Ubuntu Bionic 18.04 in build-windows.md by ken2812221 · Pull Request #13246 · bitcoin/bitcoin · GitHub
2092018-05-28T12:07:03 <wumpus> I don't have any other windows VMs though, nor are there any windows computers left here
2102018-05-28T12:07:25 <fanquake> Not necessarily a bad thing
2112018-05-28T12:08:15 <wumpus> luke-jr: what terrible wrong did it do to you today?
2122018-05-28T12:08:41 <luke-jr> wumpus: I started my node an hour or so ago, and it's still 12 days behind (basically where it began)
2132018-05-28T12:08:49 <luke-jr> in the meantime, the whole PC has slowed to a crawl
2142018-05-28T12:09:32 <fanquake> sounds kinda like my laptop whenever there's > 2 VM running
2152018-05-28T12:12:41 <luke-jr> (as well as random unexplained WARNING stack dumps in dmesg)
2162018-05-28T12:24:04 *** qu4ku has joined #bitcoin-core-dev
2172018-05-28T12:28:47 <sipa> provoostenator: 0.16.1 will be created by tagging the 0.16 branch, not master
2182018-05-28T12:29:16 <sipa> 0.16 branched off from master a bit before 0.16.0
2192018-05-28T12:29:59 <sipa> and indeed since the feature freeze (shortly before the branch) there are only bugfixes in it
2202018-05-28T12:30:12 <sipa> which are backports of changes in master
2212018-05-28T12:30:42 <luke-jr> looks like about 10 minutes to process each block -.-
2222018-05-28T12:32:16 <booyah> luke-jr: after all this years? :/
2232018-05-28T12:33:16 <luke-jr> never going to catch up at this rate
2242018-05-28T12:33:53 *** retrop99 has joined #bitcoin-core-dev
2252018-05-28T12:37:50 <wumpus> that's slower than my slowest ARM board FWIW
2262018-05-28T12:38:42 <wumpus> (including lame things such as slow SD cards, slow ethernet, and external USB2 harddrives)
2272018-05-28T12:39:40 <bitcoin-git> [bitcoin] fanquake opened pull request #13336: [0.16.1] doc: Bump to Ubuntu Bionic 18.04 in build-windows.md (0.16...windows-1804) https://github.com/bitcoin/bitcoin/pull/13336
2282018-05-28T12:39:56 <wumpus> fanquake: thanks!
2292018-05-28T12:41:40 <fanquake> I'm doing my testing with 18.04, and getting rid of those work around is a +
2302018-05-28T12:42:00 <wumpus> definitely
2312018-05-28T12:42:10 <wumpus> good to think of that
2322018-05-28T12:43:17 *** drexl has joined #bitcoin-core-dev
2332018-05-28T12:58:08 *** promag has joined #bitcoin-core-dev
2342018-05-28T12:58:46 *** berndj has quit IRC
2352018-05-28T13:00:10 *** berndj has joined #bitcoin-core-dev
2362018-05-28T13:01:47 <luke-jr> moved chainstate to SSD, more like 10 seconds per block now (still btrfs'd)
2372018-05-28T13:03:53 *** arowser_ has quit IRC
2382018-05-28T13:04:11 *** arowser_ has joined #bitcoin-core-dev
2392018-05-28T13:05:08 <bitcoin-git> [bitcoin] laanwj closed pull request #13336: [0.16.1] doc: Bump to Ubuntu Bionic 18.04 in build-windows.md (0.16...windows-1804) https://github.com/bitcoin/bitcoin/pull/13336
2402018-05-28T13:06:47 *** retrop99 has quit IRC
2412018-05-28T13:11:10 *** luke-jr has quit IRC
2422018-05-28T13:14:28 *** berndj has quit IRC
2432018-05-28T13:15:38 *** berndj has joined #bitcoin-core-dev
2442018-05-28T13:17:59 *** luke-jr has joined #bitcoin-core-dev
2452018-05-28T13:20:52 *** SopaXorzTaker has quit IRC
2462018-05-28T13:22:43 *** SopaXorzTaker has joined #bitcoin-core-dev
2472018-05-28T13:23:20 <wumpus> FreeBSD 11.1 and OpenBSD 6.2 builds OK
2482018-05-28T13:23:23 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2492018-05-28T13:24:33 <fanquake> macOS 10.13.5 builds OK. Currently building depends on Windows 10
2502018-05-28T13:28:51 <luke-jr> hm, there must be something wrong. ps claims bitcoin-qt's SIZE is 37 GB :|
2512018-05-28T13:28:57 *** qu4ku has quit IRC
2522018-05-28T13:32:03 <wumpus> (also Ubuntu 16.04 and 18.04, but that's not really surprising)
2532018-05-28T13:32:10 <wumpus> luke-jr: ouch, can you bisect that?
2542018-05-28T13:32:18 *** berndj has quit IRC
2552018-05-28T13:33:20 <luke-jr> wumpus: it's during startup, so.. I'm not sure it's a bug on our end
2562018-05-28T13:33:22 *** berndj has joined #bitcoin-core-dev
2572018-05-28T13:33:45 <luke-jr> my first guess is -fsanitize stuff, so trying again without those
2582018-05-28T13:36:42 *** AaronvanW has quit IRC
2592018-05-28T13:37:06 <luke-jr> btw, does anyone else thing it looks strange to have the border drop to 0 at the "current time" of the network traffic graph?
2602018-05-28T13:37:20 *** AaronvanW has joined #bitcoin-core-dev
2612018-05-28T13:37:31 <luke-jr> think*
2622018-05-28T13:37:59 <luke-jr> (and yes, disabling sanitizers seems to have fixed the insane SIZE)
2632018-05-28T13:38:46 <wumpus> ok, good to know, no worry for 0.16.1 then
2642018-05-28T13:38:56 *** berndj has quit IRC
2652018-05-28T13:41:02 *** berndj has joined #bitcoin-core-dev
2662018-05-28T13:41:21 *** AaronvanW has quit IRC
2672018-05-28T13:44:05 *** arowser_ has quit IRC
2682018-05-28T13:44:23 *** arowser_ has joined #bitcoin-core-dev
2692018-05-28T13:48:35 *** contrapumpkin has joined #bitcoin-core-dev
2702018-05-28T13:49:47 <wumpus> so if anyone else wants to try building the 0.16 branch on various platforms, please do
2712018-05-28T13:50:19 <wumpus> if not, I'm going to tag rc1 after fanquake's windows build succeeds
2722018-05-28T13:54:02 <fanquake> wumpus shouldn't be long. While you're waiting, could look at #13306 or 13295 for master. 2nd is just a trivial doc change.
2732018-05-28T13:54:04 <gribble> https://github.com/bitcoin/bitcoin/issues/13306 | build: split warnings out of CXXFLAGS by theuni · Pull Request #13306 · bitcoin/bitcoin · GitHub
2742018-05-28T13:59:16 *** arowser_ has quit IRC
2752018-05-28T13:59:34 *** arowser_ has joined #bitcoin-core-dev
2762018-05-28T14:00:04 *** belcher has joined #bitcoin-core-dev
2772018-05-28T14:02:12 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/610f4dd719ad...f5a7733ff767
2782018-05-28T14:02:12 <bitcoin-git> bitcoin/master 9e305b5 Cory Fields: build: split warnings out of CXXFLAGS...
2792018-05-28T14:02:13 <bitcoin-git> bitcoin/master f5a7733 Wladimir J. van der Laan: Merge #13306: build: split warnings out of CXXFLAGS...
2802018-05-28T14:03:01 <bitcoin-git> [bitcoin] laanwj closed pull request #13306: build: split warnings out of CXXFLAGS (master...debug_flags) https://github.com/bitcoin/bitcoin/pull/13306
2812018-05-28T14:03:09 *** AaronvanW has joined #bitcoin-core-dev
2822018-05-28T14:03:52 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f5a7733ff767...fb7731089ed2
2832018-05-28T14:03:52 <bitcoin-git> bitcoin/master 1680b8b practicalswift: docs: Update OpenBSD build instructions for OpenBSD 6.3
2842018-05-28T14:03:53 <bitcoin-git> bitcoin/master fb77310 Wladimir J. van der Laan: Merge #13295: docs: Update OpenBSD build instructions for OpenBSD 6.3...
2852018-05-28T14:04:41 <bitcoin-git> [bitcoin] laanwj closed pull request #13295: docs: Update OpenBSD build instructions for OpenBSD 6.3 (master...openbsd-6.3) https://github.com/bitcoin/bitcoin/pull/13295
2862018-05-28T14:08:49 <fanquake> wumpus The depends build, compile and make install completed successfully, using the 18.04 instructions.
2872018-05-28T14:08:58 <fanquake> However the binaries wont launch..
2882018-05-28T14:09:17 <fanquake> Trying another build, otherwise I'll have to try debugging tomorrow.
2892018-05-28T14:09:50 <wumpus> not even bitcoin-cli?
2902018-05-28T14:11:01 *** nsh- is now known as nsh
2912018-05-28T14:12:58 *** BullShark has left #bitcoin-core-dev
2922018-05-28T14:13:15 <fanquake> Got some error output, 1 sec
2932018-05-28T14:14:48 <fanquake> heh, I'm seeing #12337 :(
2942018-05-28T14:14:50 <gribble> https://github.com/bitcoin/bitcoin/issues/12337 | 0.16 Shutdown assertion · Issue #12337 · bitcoin/bitcoin · GitHub
2952018-05-28T14:15:20 <fanquake> https://0bin.net/paste/1iOaeL+DunFWqy0n#gwr6oLIgrjlG45QDIdN4u2yqvUTIHGR3goxtENCMzwJ
2962018-05-28T14:20:48 <fanquake> wumpus ^ I need to sleep. Can continue investigating tomorrow. Up to you about an RC1 tag.
2972018-05-28T14:23:00 *** fanquake has quit IRC
2982018-05-28T14:23:20 <wumpus> thanks, sleep well
2992018-05-28T14:24:48 *** berndj has quit IRC
3002018-05-28T14:26:29 *** arowser_ has quit IRC
3012018-05-28T14:26:47 *** arowser_ has joined #bitcoin-core-dev
3022018-05-28T14:27:12 *** berndj has joined #bitcoin-core-dev
3032018-05-28T14:29:14 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/fb7731089ed2...14a4b4966361
3042018-05-28T14:29:14 <bitcoin-git> bitcoin/master fa9da85 MarcoFalke: qa: Initialize lockstack to prevent null pointer deref
3052018-05-28T14:29:15 <bitcoin-git> bitcoin/master 14a4b49 Wladimir J. van der Laan: Merge #13300: qa: Initialize lockstack to prevent null pointer deref...
3062018-05-28T14:30:07 <bitcoin-git> [bitcoin] laanwj closed pull request #13300: qa: Initialize lockstack to prevent null pointer deref (master...Mf1805-qaLockDebug) https://github.com/bitcoin/bitcoin/pull/13300
3072018-05-28T14:31:36 *** Aaronvan_ has joined #bitcoin-core-dev
3082018-05-28T14:31:55 *** Aaronvan_ has quit IRC
3092018-05-28T14:32:33 *** Aaronvan_ has joined #bitcoin-core-dev
3102018-05-28T14:33:29 *** AaronvanW has quit IRC
3112018-05-28T14:35:42 *** arowser_ has quit IRC
3122018-05-28T14:36:00 *** arowser_ has joined #bitcoin-core-dev
3132018-05-28T14:37:20 *** Aaronvan_ has quit IRC
3142018-05-28T14:38:55 *** arowser_ has quit IRC
3152018-05-28T14:39:13 *** arowser_ has joined #bitcoin-core-dev
3162018-05-28T14:40:31 <wumpus> I think it's ok to tag rc1, even with the known #12337 issue, can always do rc2 if this affcts a lot of users
3172018-05-28T14:40:33 <gribble> https://github.com/bitcoin/bitcoin/issues/12337 | 0.16 Shutdown assertion · Issue #12337 · bitcoin/bitcoin · GitHub
3182018-05-28T14:40:35 *** AaronvanW has joined #bitcoin-core-dev
3192018-05-28T14:52:53 *** contrapumpkin has quit IRC
3202018-05-28T14:54:07 <wumpus> but I'll wait for some other opinions...
3212018-05-28T15:04:35 *** marcoagner has quit IRC
3222018-05-28T15:10:09 *** arowser_ has quit IRC
3232018-05-28T15:10:26 *** arowser_ has joined #bitcoin-core-dev
3242018-05-28T15:10:50 <ken2812221> Should we backport #13131?
3252018-05-28T15:10:52 <gribble> https://github.com/bitcoin/bitcoin/issues/13131 | Add Windows shutdown handler by ken2812221 · Pull Request #13131 · bitcoin/bitcoin · GitHub
3262018-05-28T15:11:03 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/14a4b4966361...a315b79ad2b8
3272018-05-28T15:11:04 <bitcoin-git> bitcoin/master 2885c13 Jonas Schnelli: Qt: use [default wallet] as name for wallet with no name
3282018-05-28T15:11:05 <bitcoin-git> bitcoin/master a315b79 Wladimir J. van der Laan: Merge #13275: Qt: use [default wallet] as name for wallet with no name...
3292018-05-28T15:11:47 <bitcoin-git> [bitcoin] laanwj closed pull request #13275: Qt: use [default wallet] as name for wallet with no name (master...2018/05/loadwallet_gui_name) https://github.com/bitcoin/bitcoin/pull/13275
3302018-05-28T15:12:32 <wumpus> i'm ok with that, for 0.16.2 though
3312018-05-28T15:13:47 <wumpus> we're currently in the process of tagging 0.16.1rc1, so the 0.16 branch is locked unless there's a serious/critical bug fix
3322018-05-28T15:14:32 *** berndj has quit IRC
3332018-05-28T15:15:24 *** promag has quit IRC
3342018-05-28T15:17:17 *** marcoagner has joined #bitcoin-core-dev
3352018-05-28T15:17:45 <ken2812221> ok
3362018-05-28T15:18:06 *** berndj has joined #bitcoin-core-dev
3372018-05-28T15:24:32 *** contrapumpkin has joined #bitcoin-core-dev
3382018-05-28T15:24:40 <jonasschnelli> "A Bech32[2] string is at most 90 characters long and consists of:"... that is not a bech32 limit, right?
3392018-05-28T15:24:48 <jonasschnelli> https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#bech32
3402018-05-28T15:28:41 <Chris_Stewart_5> jonasschnelli: I'm curious why that is in place too. I think the lightning network teams break that rule as well
3412018-05-28T15:28:52 <wumpus> I think the properties would no longer hold with the same checksum length
3422018-05-28T15:29:00 <wumpus> and longer data length
3432018-05-28T15:29:05 <jonasschnelli> Chris_Stewart_5: I guess it refers to the max length for a native P2SH address
3442018-05-28T15:29:18 <jonasschnelli> wumpus: ah. that is a point
3452018-05-28T15:30:28 *** TannerR has joined #bitcoin-core-dev
3462018-05-28T15:31:03 <jonasschnelli> wumpus: https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#checksum-design, yes. your right
3472018-05-28T15:31:42 <jonasschnelli> length 89 is the max for â¤4 wrong chars tolerance
3482018-05-28T15:39:11 <sipa> jonasschnelli: bip173 addresses are at most 74 characters
3492018-05-28T15:39:50 <sipa> bech32 encoding supports up to 90 characters (including prefix and separator)
3502018-05-28T15:40:28 <sipa> in some places a version of bech32 is used that violates that limit (e.g. lightning payments)
3512018-05-28T15:48:19 *** arowser_ has quit IRC
3522018-05-28T15:48:37 *** arowser_ has joined #bitcoin-core-dev
3532018-05-28T15:50:29 <jonasschnelli> sipa: "a version of" means modified code or just exceed of that limit that no longer "guarantees" the 4 chars correction?
3542018-05-28T15:51:14 <jonasschnelli> I though of using Bech32 for a new encoding format for extended keys but not sure if it makes sense at these lengths
3552018-05-28T15:51:20 <jonasschnelli> I *thought
3562018-05-28T15:52:56 <aj> jonasschnelli: https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md -- spec just says it's the same but without the length restriction fwiw
3572018-05-28T15:54:30 <jonasschnelli> thanks aj
3582018-05-28T15:56:50 <sipa> jonasschnelli: for pivate keys you want something else
3592018-05-28T15:57:01 <sipa> addresses only need error detection
3602018-05-28T15:58:00 <sipa> as in case of a failure you can just refuse to decode and force the user to go ask the receiver for a new address
3612018-05-28T15:58:10 <sipa> while failed private keys have no such option
3622018-05-28T15:59:32 *** arowser_ has quit IRC
3632018-05-28T16:00:01 *** arowser_ has joined #bitcoin-core-dev
3642018-05-28T16:02:03 *** Krellan has joined #bitcoin-core-dev
3652018-05-28T16:03:56 *** arowser_ has quit IRC
3662018-05-28T16:04:12 *** arowser_ has joined #bitcoin-core-dev
3672018-05-28T16:13:06 *** arowser_ has quit IRC
3682018-05-28T16:13:26 *** arowser_ has joined #bitcoin-core-dev
3692018-05-28T16:17:56 *** promag has joined #bitcoin-core-dev
3702018-05-28T16:19:21 *** arowser_ has quit IRC
3712018-05-28T16:19:40 *** arowser_ has joined #bitcoin-core-dev
3722018-05-28T16:32:50 *** promag has quit IRC
3732018-05-28T16:34:11 *** m8tion has quit IRC
3742018-05-28T16:54:37 <wumpus> any opinions on tagging rc1 or not?
3752018-05-28T16:56:15 <sipa> any things missing (according to some)?
3762018-05-28T16:57:33 <wumpus> well #12337
3772018-05-28T16:57:34 <gribble> https://github.com/bitcoin/bitcoin/issues/12337 | 0.16 Shutdown assertion · Issue #12337 · bitcoin/bitcoin · GitHub
3782018-05-28T16:59:28 <sipa> otherwise harmless assert failure at shutdown?
3792018-05-28T17:00:43 <wumpus> yes
3802018-05-28T17:02:57 <sipa> can we remove the assert...?
3812018-05-28T17:03:06 * sipa hides
3822018-05-28T17:06:18 <wumpus> that's not a bad idea
3832018-05-28T17:08:36 <wumpus> it doesn't seem to be a problem on master, just 0.16
3842018-05-28T17:08:45 <sipa> hmm
3852018-05-28T17:10:37 <wumpus> removing the assert (and replacing it with, say, a log message) would be a good idea if it doesn't segfault later due to the same problem
3862018-05-28T17:11:15 <wumpus> anyhow, maybe it doesn't matter too much for rc11
3872018-05-28T17:11:17 <wumpus> rc1*
3882018-05-28T17:12:01 <wumpus> depends on how quickly we want to start testing this
3892018-05-28T17:13:11 *** timothy has quit IRC
3902018-05-28T17:14:31 *** Giszmo has joined #bitcoin-core-dev
3912018-05-28T17:17:33 *** arowser_ has quit IRC
3922018-05-28T17:17:52 *** arowser_ has joined #bitcoin-core-dev
3932018-05-28T17:18:01 *** d9b4bef9 has quit IRC
3942018-05-28T17:19:11 *** d9b4bef9 has joined #bitcoin-core-dev
3952018-05-28T17:20:47 *** arowser_ has quit IRC
3962018-05-28T17:21:05 *** arowser_ has joined #bitcoin-core-dev
3972018-05-28T17:23:52 <wumpus> I think in the past it has been useful to get a rc out quick, without waiting too much, because new issues arise during testing anyhow
3982018-05-28T17:24:05 <sipa> ah, you mean fix the assert in rc2/final?
3992018-05-28T17:25:00 <wumpus> yes
4002018-05-28T17:25:12 <sipa> sgtm
4012018-05-28T17:25:31 <wumpus> it makes the process somewhat more parallel instead of serial
4022018-05-28T17:26:24 *** berndj has quit IRC
4032018-05-28T17:28:12 *** berndj has joined #bitcoin-core-dev
4042018-05-28T17:38:01 *** arowser_ has quit IRC
4052018-05-28T17:38:18 *** arowser_ has joined #bitcoin-core-dev
4062018-05-28T17:39:28 *** pergaminho has joined #bitcoin-core-dev
4072018-05-28T17:39:51 <pergaminho> Olá alguém de São Paulo?
4082018-05-28T17:40:04 <sipa> english please
4092018-05-28T17:41:57 <pergaminho> Excuse me, I want to know if there's anyone in Sao Paulo.
4102018-05-28T17:44:12 *** arowser_ has quit IRC
4112018-05-28T17:44:24 <wumpus> that seems very off topic
4122018-05-28T17:44:29 *** arowser_ has joined #bitcoin-core-dev
4132018-05-28T17:51:00 *** nmnkgl has joined #bitcoin-core-dev
4142018-05-28T17:51:38 *** justanotheruser has quit IRC
4152018-05-28T17:51:44 *** bapu has joined #bitcoin-core-dev
4162018-05-28T17:55:20 *** laurentmt has joined #bitcoin-core-dev
4172018-05-28T18:19:30 *** TannerR has quit IRC
4182018-05-28T18:21:23 *** arowser_ has quit IRC
4192018-05-28T18:21:41 *** arowser_ has joined #bitcoin-core-dev
4202018-05-28T18:23:54 <wumpus> * [new tag] v0.16.1rc1 -> v0.16.1rc1
4212018-05-28T18:24:32 <sipa> w00t
4222018-05-28T18:25:36 *** arowser_ has quit IRC
4232018-05-28T18:25:54 *** arowser_ has joined #bitcoin-core-dev
4242018-05-28T18:27:48 *** arowser_ has quit IRC
4252018-05-28T18:28:06 *** arowser_ has joined #bitcoin-core-dev
4262018-05-28T18:30:17 *** arowser_ has joined #bitcoin-core-dev
4272018-05-28T18:31:36 *** Guyver2 has joined #bitcoin-core-dev
4282018-05-28T18:32:36 <achow101> yay
4292018-05-28T18:38:12 *** Chris_Stewart_5 has quit IRC
4302018-05-28T18:38:42 *** laurentmt has quit IRC
4312018-05-28T18:44:31 *** Giszmo has quit IRC
4322018-05-28T18:45:46 <jonasschnelli> sipa: have you explored the field of BCH codes suitable for private keys?
4332018-05-28T18:48:21 <sipa> jonasschnelli: yes, a bit
4342018-05-28T18:48:33 <sipa> but the tradeoffs are hard
4352018-05-28T18:49:02 <sipa> strictly for private keys, you could correct 4 errors with 12 characters of checksum
4362018-05-28T18:49:40 <sipa> but not with an efficient algorithm
4372018-05-28T18:49:57 <jonasschnelli> with private keys you mean 256bits, right?
4382018-05-28T18:50:01 <sipa> yes
4392018-05-28T18:50:56 <jonasschnelli> Hmm... for an xpriv, if the chaincode should also have the same robustness, it is maybe an overkill in length
4402018-05-28T18:52:08 <jonasschnelli> sipa: how are Bech32 properties for 512 bits? How much chars would be guaranteed in the correction?
4412018-05-28T18:52:44 <sipa> if you want to correct 4 errors with an efficient algorithm on 512 bits (103 characters), you need to add 15 characters of checksum
4422018-05-28T18:53:02 <jonasschnelli> I'd say that is accaptable...
4432018-05-28T18:53:27 <jonasschnelli> I would also say 4 error may be acceptable for 103 chars
4442018-05-28T18:53:43 <jonasschnelli> Ideally it would be flexible ("choose your size / robustness")
4452018-05-28T18:53:58 <sipa> such a code would guarantee correction of 4 up to length 1023
4462018-05-28T18:54:13 <sipa> (of which 15 are checksum characters, and 1008 are data)
4472018-05-28T18:54:57 *** Giszmo has joined #bitcoin-core-dev
4482018-05-28T18:55:41 <jonasschnelli> sipa: hmm... and there is no optimised code for something up to 103 chars (512bit in base32).
4492018-05-28T18:55:43 <jonasschnelli> ?
4502018-05-28T18:56:15 <sipa> jonasschnelli: so there is an important distinction here
4512018-05-28T18:56:45 <sipa> a BCH code is a just a subset of cyclic codes, with parameters generated in a specific way
4522018-05-28T18:56:56 <jonasschnelli> the 4 in 1023?
4532018-05-28T18:57:10 <sipa> that specific way guarantees (1) a certain level of error correction and (2) an efficient algorithm to do so
4542018-05-28T18:57:39 <sipa> all these codes are however "better" than what they're designed for
4552018-05-28T18:57:40 <jonasschnelli> so the BCH subset may not be ideal for private keys
4562018-05-28T18:57:50 <sipa> it absolutely is not
4572018-05-28T18:57:54 <sipa> BCH codes are not optimal
4582018-05-28T18:57:57 <sipa> but they're easy
4592018-05-28T18:58:06 <sipa> (and they may be close to optimal)
4602018-05-28T18:58:24 <sipa> bech32 is a BCH code that only guarantees detecting 3 errors up to length 1023... that's the BCH part
4612018-05-28T18:58:51 <sipa> however, out of all possible BCH codes with that property, we searching for one that is "better" in that it also detects 4 errors up to length 89
4622018-05-28T18:59:04 <sipa> that took a few years of CPU time to find out, though :)
4632018-05-28T18:59:13 <jonasschnelli> Yes. I heard that. :)
4642018-05-28T18:59:23 <sipa> the BCH part is just math; i can tell you in an instant how good a code is
4652018-05-28T18:59:50 <sipa> but no, i can't create a BCH code whose _designed_ strength is optimal for 103 characters; no such codes exist
4662018-05-28T19:00:02 <jonasschnelli> I see...
4672018-05-28T19:00:15 <sipa> there do exist BCH codes for length 93, FWIW :)
4682018-05-28T19:00:38 <sipa> with just 13 checksum characters, even
4692018-05-28T19:00:52 <sipa> but the next one up is for length 1023
4702018-05-28T19:01:25 <jonasschnelli> Unsure if 4 chars are enough for a private key...
4712018-05-28T19:01:35 <jonasschnelli> Implementation wise, using bech32 would be a great thing since it will very likely be already present in the code/framework...
4722018-05-28T19:01:58 *** str4d has joined #bitcoin-core-dev
4732018-05-28T19:02:43 <sipa> 19 checksum characters if you want an efficient way to correct 5
4742018-05-28T19:03:00 <jonasschnelli> new proposals may lead to not getting implemented because of a complex implementation,... bech32 would make it pretty simple
4752018-05-28T19:03:13 <sipa> the checksum algorithm for all of these is trivial
4762018-05-28T19:03:20 <sipa> just as simple as bech32, but with larger integers
4772018-05-28T19:03:36 <sipa> the error correction algorithm is more complex (but very fast)
4782018-05-28T19:03:57 *** justanotheruser has joined #bitcoin-core-dev
4792018-05-28T19:04:38 <jonasschnelli> the 19/5 code is in the BCH subset (up to 1023)?
4802018-05-28T19:04:49 <sipa> yup
4812018-05-28T19:05:07 <jonasschnelli> Something you drilled out of your supermachine?
4822018-05-28T19:05:16 <jonasschnelli> (calculated on your own?)
4832018-05-28T19:05:27 <sipa> no, this is just BCH
4842018-05-28T19:05:33 <sipa> it's a simple sage script to compute these
4852018-05-28T19:05:44 <sipa> they're not optimized for anything beyong their design strength
4862018-05-28T19:06:23 <sipa> among all the 19/5 codes (there are likely thousands) i could search for the "best" one according to some extra criteria
4872018-05-28T19:07:16 <jonasschnelli> So it could be possible to find a 19/6 within a length property of l<103?
4882018-05-28T19:07:23 <jonasschnelli> <=
4892018-05-28T19:07:52 <sipa> that seems unlikely, but it's possible yes
4902018-05-28T19:08:03 <sipa> it may also take more computing power than we have
4912018-05-28T19:08:18 <jonasschnelli> I see
4922018-05-28T19:08:45 <sipa> however, if it's just for single private keys, we could use length 93 codes
4932018-05-28T19:09:22 <sipa> where just 13 characters for 4 corrections, or 16 characters for 5, is sufficient
4942018-05-28T19:10:01 *** arowser_ has quit IRC
4952018-05-28T19:10:18 <jonasschnelli> That would not cover encoding an extended private key though....
4962018-05-28T19:10:22 <sipa> yup
4972018-05-28T19:10:40 <sipa> also, codes _designed_ for length 93 will perform terrible beyond it
4982018-05-28T19:10:46 <jonasschnelli> Metadata could be ouside of the cyclic code,.. but within the checksum (is that even possible?)?
4992018-05-28T19:10:53 <sipa> no
5002018-05-28T19:11:11 <sipa> bech32 was designed for length 1023, but optimized for length 89... that's why it performs still fine when you exceed the 89 characters
5012018-05-28T19:11:15 <jonasschnelli> So an additional checksum
5022018-05-28T19:11:24 <sipa> that's a bit ridiculous
5032018-05-28T19:11:45 *** arowser_ has joined #bitcoin-core-dev
5042018-05-28T19:11:52 <jonasschnelli> we only would need to detect errors in the metadata pert... even a parity bit would be okayish?
5052018-05-28T19:12:01 <jonasschnelli> *part
5062018-05-28T19:12:05 <sipa> but metadata includes chaincode etcx
5072018-05-28T19:12:18 <jonasschnelli> chaincode is essential IMO
5082018-05-28T19:12:23 <jonasschnelli> must be within the error correcting part
5092018-05-28T19:12:23 *** pergaminho has quit IRC
5102018-05-28T19:12:30 <sipa> yeah, exactly- i agree
5112018-05-28T19:12:37 <sipa> so a length 93 code is out of the question
5122018-05-28T19:13:00 <jonasschnelli> 512bits seems to be the minimum if it should cover xprivs
5132018-05-28T19:13:10 <jonasschnelli> (other xpriv then m)
5142018-05-28T19:13:22 <jonasschnelli> If we would only cover m, one could think of encoding the seed
5152018-05-28T19:13:42 <jonasschnelli> of the seed & keypath?
5162018-05-28T19:13:58 <jonasschnelli> but meh for hardened protection
5172018-05-28T19:14:25 <jonasschnelli> wait, nm my last line
5182018-05-28T19:15:38 <sipa> 11 char checksum for correcting 3, 15 for correcting 4, 19 for correcting 5
5192018-05-28T19:16:22 *** nmnkgl has quit IRC
5202018-05-28T19:18:21 <jonasschnelli> sipa: don't you think using bech32 with the property of 4 corrections for a pure private key and 3 for a key/chaincode keycombo(xpriv) would be acceptable?
5212018-05-28T19:18:34 <jonasschnelli> Also, reusing bech32 would be very desirable...
5222018-05-28T19:18:40 <sipa> yes, but you can't have both
5232018-05-28T19:18:43 <jonasschnelli> Right now, we have 0 correction with Base58c
5242018-05-28T19:18:50 <sipa> bech32 can only correct 2, and inefficiently
5252018-05-28T19:19:09 *** SopaXorzTaker has quit IRC
5262018-05-28T19:19:11 <sipa> you design for a single combination of length and correction strength
5272018-05-28T19:19:26 <sipa> it will likely be better for shorter lengths, but not have an efficient algorithm to do so
5282018-05-28T19:20:18 <jonasschnelli> Hmm... i though bech32 corrects 4 errors up to length 89?
5292018-05-28T19:20:19 <jonasschnelli> *thought
5302018-05-28T19:20:35 <sipa> no, it *detects* 4
5312018-05-28T19:20:45 <jonasschnelli> ah. I see
5322018-05-28T19:20:48 <sipa> correction strength is always only half of the detection strength
5332018-05-28T19:20:55 <jonasschnelli> meh
5342018-05-28T19:21:05 <jonasschnelli> that is what we need for private keys. :/
5352018-05-28T19:21:38 <jonasschnelli> Yes. I guess then we need another encoding implementation... ideally as simple as bech32
5362018-05-28T19:22:45 *** nmnkgl has joined #bitcoin-core-dev
5372018-05-28T19:24:30 <sipa> what do you think about a 103-character checksum code that can correct 28 errors? :)
5382018-05-28T19:24:47 <sipa> (doubling the length of the string)
5392018-05-28T19:25:40 <gmaxwell> I'm fond of that, but whats the efficiency of the correction code for that?
5402018-05-28T19:25:42 <jonasschnelli> sipa: I think very acceptable.. really
5412018-05-28T19:25:55 <sipa> 206 characters is a lot :)
5422018-05-28T19:26:05 <sipa> gmaxwell: efficiency in terms of what?
5432018-05-28T19:26:06 <jonasschnelli> I think the correct code efficiency is not very important for private keys
5442018-05-28T19:26:19 <jonasschnelli> *correction
5452018-05-28T19:26:21 <gmaxwell> is it a design distance 56 code? with an efficienct locator algorithim?
5462018-05-28T19:26:34 <gmaxwell> jonasschnelli: it matters if its intractably slow.
5472018-05-28T19:26:46 <sipa> gmaxwell: distance 58 actually, design length 341
5482018-05-28T19:27:04 <sipa> so it could have up to 238 data characters
5492018-05-28T19:27:34 *** Kvaciral has joined #bitcoin-core-dev
5502018-05-28T19:27:50 <gmaxwell> sipa: I guess I'd want to try writing down 206 characters and see how much I hate my life. :)
5512018-05-28T19:27:55 <sipa> gmaxwell: why would correct be slow?
5522018-05-28T19:29:00 <gmaxwell> sipa: the thinking behind my question was that if it was a design distance 40 code with an actual distance of 58, and we had to decode beyond the design without an algebraic decoder, it would take days to decode out to the full length.
5532018-05-28T19:29:01 <sipa> factoring the locator polynomial should be fast; the field size is just 32^2
5542018-05-28T19:29:23 <sipa> ah, i see
5552018-05-28T19:29:31 <sipa> all i'm talking about here are algebraic properties
5562018-05-28T19:30:03 <gmaxwell> Thanks, right thats what I was asking, I also realize now that the question is kinda stupid in that you can't _find_ codes that far beyond their design distance.
5572018-05-28T19:30:15 <sipa> indeed :)
5582018-05-28T19:30:19 <gmaxwell> since the search process and the decode process are essential the same.
5592018-05-28T19:32:30 <gmaxwell> sipa: your suggested code also has enough length to have some metadata, a nonce for encryption, etc.
5602018-05-28T19:33:07 <sipa> yup
5612018-05-28T19:33:10 *** AaronvanW has quit IRC
5622018-05-28T19:33:17 <sipa> but 2x length is... a lot
5632018-05-28T19:33:50 <jonasschnelli> To keep the write-down-by-hand property, I guess something beyond bech32 will not be tolerated/used.
5642018-05-28T19:34:03 <gmaxwell> jonasschnelli: huh?
5652018-05-28T19:34:47 <jonasschnelli> gmaxwell: do you think 206 chars are acceptable to write down?
5662018-05-28T19:34:57 <gmaxwell> That doesn't follow from what you're saying there. :)
5672018-05-28T19:34:58 <jonasschnelli> I mean it always depends what sort of key your dealing with...
5682018-05-28T19:35:47 <gmaxwell> If someone is already writing 60 digits for a private key, writing an extra 6 is a non-issue I think... and that would be what you'd be doing for a code with twice the error recovering potential of bech32.
5692018-05-28T19:36:09 <gmaxwell> But yes, writing down 206 might be too much, which is why I said I'd want to try it. :)
5702018-05-28T19:36:25 <gmaxwell> But 206 being too much doesn't mean that beyond bech32 isn't fine.
5712018-05-28T19:36:28 <jonasschnelli> heh.. yes. I need to try that as well...
5722018-05-28T19:36:48 <jonasschnelli> Yes. That is true
5732018-05-28T19:36:59 <gmaxwell> I think bech32 is not very useful for private keys... it barely has error recovery which is what you need for private keys (I see sipa argued this above).
5742018-05-28T19:37:21 *** promag has joined #bitcoin-core-dev
5752018-05-28T19:37:43 <gmaxwell> For a while before sipa was searching for 12 digit checksums (so 6 more digits than bech32).
5762018-05-28T19:37:46 <jonasschnelli> Yes. I wonder now why seed encoding proposals do have no error correction at all (or do they, AFAIL no)?
5772018-05-28T19:38:24 <gmaxwell> I think mostly because people didn't know it was possible. The word-list based ones have some informal error correction since you can figure out the word from part of it.
5782018-05-28T19:38:57 <jonasschnelli> Yes. The stove/stone error that took me days to figure out... :/
5792018-05-28T19:39:23 <gmaxwell> ugh. yes, a problem with informal is that the worst case errors are going to be pretty bad.
5802018-05-28T19:40:03 <jonasschnelli> (also wonder why they have chosen "stove" and "stone" while we know that the n and the v look often very similar)
5812018-05-28T19:41:06 <gmaxwell> There really isn't a lot of good data on visual similarities of letters. This was a challenge in designing bech32 too.
5822018-05-28T19:41:08 <jonasschnelli> "12 digit checksum" (gmaxwell above) would result in 6 chars correction, right?
5832018-05-28T19:41:09 *** TannerR has joined #bitcoin-core-dev
5842018-05-28T19:42:21 *** justanotheruser has quit IRC
5852018-05-28T19:43:02 <gmaxwell> jonasschnelli: only if the code was perfect, which isn't possible for codes of length 32 or more (and we need length around 644). It might be possible for 5 character correction with 12 check digits, but I believe the best 12-digit codes sipa could find only allowed 4 corrections.
5862018-05-28T19:43:21 <gmaxwell> (maybe even only 3? I'm not sure now... but thats why sipa was doing a search)
5872018-05-28T19:44:19 <gmaxwell> It may be that 5 is possible information theoretically but there just aren't any cyclic codes that achieve that performance. Or maybe one does exist but it just hasn't been found yet. There are on the order of 2^55 possible codes...
5882018-05-28T19:45:57 <jonasschnelli> I see
5892018-05-28T19:49:20 <jonasschnelli> The second things â because a new error-correcting encoding proposal could go hand in hand with a seed encoding proposal (which has very similar properties to pure private key and extended private keys encoding), what do you think about the lighning aezeed proposal?
5902018-05-28T19:49:21 <jonasschnelli> https://github.com/lightningnetwork/lnd/tree/master/aezeed
5912018-05-28T19:49:47 <jonasschnelli> I don't see the relevance of the nonce-missuse resistance
5922018-05-28T19:50:16 *** nmnkgl has quit IRC
5932018-05-28T19:51:04 <gmaxwell> I haven't seen it before.
5942018-05-28T19:51:05 <jonasschnelli> A such proposal could also use ChaCha20Poly1305 as AEAD,... though the MAC size would be 128bits instead of the flexible 8 byte AEZ mac length
5952018-05-28T19:51:23 <jonasschnelli> (which results in no longer be 24 words probably)
5962018-05-28T19:51:52 <gmaxwell> a mac could be made whatever length.. so the other wallet people have been regarding authenticated encryption as a negative feature.
5972018-05-28T19:52:25 <gmaxwell> because they want the user to be able to be able to give out different passwords that work.
5982018-05-28T19:52:47 <jonasschnelli> plausible deniable,... yes. that may be a point.
5992018-05-28T19:53:18 *** justanotheruser has joined #bitcoin-core-dev
6002018-05-28T19:53:32 <gmaxwell> My thought was thats really pretty dangerous, since the user could have the wrong key and didn't know it. And the use case is kind of silly and not that realistic. But a compromise could be that if the authentication was small (on the order of 16 to 32 bits) your computer could search for an alternative durress password for you to remember.
6012018-05-28T19:53:46 <gmaxwell> and you'd still get protection against a wrong password.
6022018-05-28T19:54:06 <jonasschnelli> cool!
6032018-05-28T19:54:57 <jonasschnelli> But I guess it could be really cpu-intense to find an alternative version that goes beyond gibberish things...
6042018-05-28T19:55:01 <gmaxwell> the downside being that the user couldn't freely choose the durress password. But I think thats probably acceptable.
6052018-05-28T19:55:30 <gmaxwell> well if the code is 16 bits you can just try a 2^16 words from a dictionary and you're likely to have one match.
6062018-05-28T19:55:59 <roasbeef> gmaxwell: it uses an arbitrary input length tweakable block cipher (aez) to encipher a plaintext wallet payload (internal version, birthday, entropy), aez takes an approach where you add reudndancy to the plaintext, and check for it on decryption. w/ this approach the seed <-> phrase conversion is actually reversible unlike bip 39
6072018-05-28T19:56:05 <gmaxwell> another way to do it that doesn't require search is to store two check values, and one must match.
6082018-05-28T19:56:47 <gmaxwell> roasbeef: the thing jonas linked to made it look like the plaintext key length is limited to 16 bytes tough?
6092018-05-28T19:57:10 <jonasschnelli> That was also my question, why only 128bit entropy?
6102018-05-28T19:57:14 <gmaxwell> jonasschnelli: with the store two check values approach to 'denyability' then there is no search, just the overhead of encoding two values.
6112018-05-28T19:57:19 <roasbeef> never really been convinced w.r.t the whole "plausible deniability thing", but in theory you can adjust the redundancy size to make brute forcing a valid decryption "easier"
6122018-05-28T19:57:46 <roasbeef> yes atm it's 128-bits, the current params allow everything to be encoded in 24 words, as to still be familiar w/ users of bip39
6132018-05-28T19:58:00 <roasbeef> y'all think 128-bits of entropy is insufficient?
6142018-05-28T19:58:13 <gmaxwell> I think the deniability thing is stupid, outright. But it's appealing to a bunch of people (who probably then go and store their keys on their smartphone or whatever), it's silly to have gratitious incompatiblity because of it.
6152018-05-28T19:58:18 <jonasschnelli> Not sure... but if I can choose, I chose 256. :)
6162018-05-28T19:58:21 <jonasschnelli> *choose
6172018-05-28T19:58:42 <gmaxwell> roasbeef: it's probably sufficient, but it means you cannot encode existing values that come from schemes using 256 bits, sadly.
6182018-05-28T19:59:09 <gmaxwell> the BIP39 problem but somewhat less dumb.
6192018-05-28T19:59:31 <roasbeef> yeh, that's one detriment, but it's versioned so another version can be parameterized to store 256 bits
6202018-05-28T20:00:00 <jonasschnelli> roasbeef: is aez beeing considered crypto-analysed enough?
6212018-05-28T20:00:24 <roasbeef> it was amongst the caesar contest finalists, but dropped out iirc as it was difficult to implement efficeitnly in hardware
6222018-05-28T20:01:14 <jonasschnelli> roasbeef: What would be the downsides of using ChaCha20Poly1305? Only the nonce missue protection?
6232018-05-28T20:01:22 <jonasschnelli> or say "resistance"
6242018-05-28T20:02:36 <roasbeef> don't think you'd really care about nonce misuse in this case, one could swap in chacha and simply truncate the mac (if wanted), aez was nice for us as it let use tune the size of the mac nicely to expand the plaintext given the 24 word constraint we imposed
6252018-05-28T20:03:31 <jonasschnelli> Got it. Thanks
6262018-05-28T20:05:58 <roasbeef> fwiw in the scheme the enciperhing is distinct from the encoding to the mnemonic, we take the enciphered payload then prepend a version, append the salt used in the kdf, and finally add a checksum over the entire thing so we can detect incorrect words, for external version 0 these params are set, but can be tweaked to use a more specialized checksum, etc
6272018-05-28T20:07:26 <jonasschnelli> I would strongly prefer ChaCha over AEZ... but I'm not a cryptographer and have little arguments to say why.
6282018-05-28T20:08:23 *** justanotheruser has quit IRC
6292018-05-28T20:09:08 <jonasschnelli> Also, I like the truncated-MAC-approach described by gmaxwell above that would allow the plausible deniability & the two way direction (though with a pre-defined second password)
6302018-05-28T20:09:18 <gmaxwell> roasbeef: since the data being encoded is high entropy, I think a nonce is nearly irrelevant from the perspective of the encryption itself. A nonce is highly useful for the KDF however.
6312018-05-28T20:09:52 <gmaxwell> I'm not sure if truncated mac vs two mac is better. So the biggest argument I have against truncated mac is that if your KDF is slow (As it should be) the search will take a long time.
6322018-05-28T20:10:01 <jonasschnelli> gmaxwell: in KDF, you referring to the salt?
6332018-05-28T20:10:53 <gmaxwell> Yes.
6342018-05-28T20:11:15 <gmaxwell> Without a decently sized nonce/salt the KDF will be gratitiously vulnerable to precomputation.
6352018-05-28T20:11:45 <gmaxwell> As far as KDFs go, reasonable KDFs are incompatible with hardware wallets, unless an outsourcable KDF is used.
6362018-05-28T20:11:59 *** Chris_Stewart_5 has joined #bitcoin-core-dev
6372018-05-28T20:14:00 <jonasschnelli> if you have two macs, an attacker could ask for both passphrases,.. while the current BIP39 approach, there are "infinite" possibilities
6382018-05-28T20:14:18 <jonasschnelli> not sure if this would be a downside
6392018-05-28T20:14:43 <gmaxwell> jonasschnelli: "there is no second passphrase"
6402018-05-28T20:15:04 <gmaxwell> (if one one is used, you just set the other one to a random value)
6412018-05-28T20:15:32 <gmaxwell> with the BIP39 thing someone could also keep demanding your other passphrase while you protest that there isn't one.
6422018-05-28T20:15:43 <jonasschnelli> true
6432018-05-28T20:16:08 <jonasschnelli> though they could do the same if your second mac is based on a random passphrase. :)
6442018-05-28T20:16:24 <jonasschnelli> (or random MAC)
6452018-05-28T20:16:26 <gmaxwell> (I still do think the feature is dumb, also largely because 99.9999% of anyone will leak all sorts of stuff about what addresses they're using all over the place)
6462018-05-28T20:16:47 <jonasschnelli> Yes. I guess it's a "marketing" feature.
6472018-05-28T20:17:32 <jonasschnelli> Also, if lying is something that is often easy detectable and needs more courage that one things
6482018-05-28T20:17:39 <jonasschnelli> *thinks
6492018-05-28T20:17:47 <gmaxwell> Another one of those is secret sharing support. Which I think is also more marketing than pratically useful, but I think probably more useful than denyability.
6502018-05-28T20:18:04 <jonasschnelli> secret sharing?
6512018-05-28T20:18:30 <jonasschnelli> sharing secrets with something like the shamir approach?
6522018-05-28T20:19:00 <gmaxwell> Well I really think the biggest weakness is that even if you successfully lie (remember to lie, decide to do so, etc) that the attacker needs to find just a single address you've used anywhere (put in a tip jar, signed up with on coinbase, etc) to tell that you haven't given him the right passphrase.
6532018-05-28T20:19:30 <gmaxwell> jonasschnelli: yes, being able to split the private key into multiple parts where all parts aren't required.
6542018-05-28T20:19:39 <jonasschnelli> Yes. Indeed. I also don't think that the feature is practical useful.
6552018-05-28T20:19:57 <jonasschnelli> (^ regarding deniability)
6562018-05-28T20:20:25 <jonasschnelli> gmaxwell: I think the secret sharing is way more pratical then the deniability feature)
6572018-05-28T20:22:08 <gmaxwell> I agree, well "more". I'm also dubious of secret sharing in practice. Like the PD it strikes people as really cool, but then in practice it takes a lot of effort.
6582018-05-28T20:22:25 <gmaxwell> but yea, if I had to pick one I'd do SS.
6592018-05-28T20:22:37 <jonasschnelli> Indeed
6602018-05-28T20:22:43 *** Krellan has quit IRC
6612018-05-28T20:23:41 *** Krellan has joined #bitcoin-core-dev
6622018-05-28T20:23:52 <gmaxwell> you can also see it in the tools, a lot of secret sharing code out there is snake oil. e.g. the old armory code where could could recover from two shares regardless of what the threshold was....
6632018-05-28T20:24:59 *** promag has quit IRC
6642018-05-28T20:25:49 * jonasschnelli falls asleep
6652018-05-28T20:28:58 *** drexl has quit IRC
6662018-05-28T20:29:21 *** str4d has quit IRC
6672018-05-28T20:38:30 *** bapu has quit IRC
6682018-05-28T20:59:42 *** promag has joined #bitcoin-core-dev
6692018-05-28T21:00:31 *** AaronvanW has joined #bitcoin-core-dev
6702018-05-28T21:01:39 *** drexl has joined #bitcoin-core-dev
6712018-05-28T21:07:39 *** retrop99 has joined #bitcoin-core-dev
6722018-05-28T21:10:45 *** setpill has quit IRC
6732018-05-28T21:15:22 *** Guyver2 has quit IRC
6742018-05-28T21:34:50 *** bitconner has quit IRC
6752018-05-28T21:35:11 *** bitconner has joined #bitcoin-core-dev
6762018-05-28T21:38:46 *** Chris_Stewart_5 has quit IRC
6772018-05-28T21:40:50 *** bitconner has quit IRC
6782018-05-28T21:56:34 *** retrop99 has quit IRC
6792018-05-28T21:58:44 *** arowser_ has quit IRC
6802018-05-28T21:58:48 *** Chris_Stewart_5 has joined #bitcoin-core-dev
6812018-05-28T21:59:01 *** arowser_ has joined #bitcoin-core-dev
6822018-05-28T22:06:44 *** bitconner has joined #bitcoin-core-dev
6832018-05-28T22:12:38 *** mistergold has quit IRC
6842018-05-28T22:12:47 *** spinza has quit IRC
6852018-05-28T22:13:09 *** mistergold has joined #bitcoin-core-dev
6862018-05-28T22:15:18 *** Krellan has quit IRC
6872018-05-28T22:18:26 *** Krellan has joined #bitcoin-core-dev
6882018-05-28T22:25:30 *** belcher has quit IRC
6892018-05-28T22:27:45 *** spinza has joined #bitcoin-core-dev
6902018-05-28T22:30:55 *** arowser_ has quit IRC
6912018-05-28T22:32:13 *** arowser_ has joined #bitcoin-core-dev
6922018-05-28T22:33:23 <jhfrontz> achow101: the installations appear to be part of creation of the vm/container environment because repeating the same âsetup run results in the same errors.
6932018-05-28T22:34:56 <jhfrontz> in this case, it appears to be installing sudo but is upset about the contents of /etc/sudoers (claiming that it's been modified â I've modified neither the host system's /etc/sudoers nor the vm).
6942018-05-28T22:58:21 *** bitconner has quit IRC
6952018-05-28T23:00:25 *** bitconner has joined #bitcoin-core-dev
6962018-05-28T23:02:33 *** Randolf has joined #bitcoin-core-dev
6972018-05-28T23:05:38 *** lxer has quit IRC
6982018-05-28T23:05:53 *** justanotheruser has joined #bitcoin-core-dev
6992018-05-28T23:19:01 *** promag has quit IRC
7002018-05-28T23:29:26 *** mistergold has quit IRC
7012018-05-28T23:37:39 *** justanotheruser has quit IRC
7022018-05-28T23:41:03 *** justanotheruser has joined #bitcoin-core-dev
7032018-05-28T23:50:37 *** rex4539 has quit IRC