--- Day changed Mon May 28 2018 00:02 < sipa> mryandao: i believe cfields has some.ongoing work to get rid of it 00:02 < sipa> but i'm not sure of the status 00:06 -!- Krellan [~Krellan@2601:640:4000:9258:c55f:52a7:b8b8:e7df] has quit [Ping timeout: 265 seconds] 00:16 < mryandao> oh, i just did an update today and it pains me to need to install that 100MB+ of libboost to compile bitcoin-core 00:16 < mryandao> hence I asked. 00:18 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 00:18 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 00:18 -!- bitconner [~conner@136.24.175.89] has quit [Ping timeout: 264 seconds] 00:20 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 00:21 < wumpus> I think we're also quite near to being able to get rid of boost::thread 00:23 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 00:27 -!- bitconner [~conner@136.24.175.89] has joined #bitcoin-core-dev 00:28 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 260 seconds] 00: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 00:32 -!- bitconner [~conner@136.24.175.89] has quit [Ping timeout: 248 seconds] 00:33 < mryandao> boost::thread alone had 100MB+ of dependencies 00:34 < mryandao> the rest were ok, or by the time all the dependencies were installed, it was pretty much all of libboost 00:36 < wumpus> that's simply not true 00:37 < 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. 00:37 < wumpus> you can check the gitian descriptor to see how by far most of the build is disabled 00:38 < wumpus> boost itself has no dependencies outside of boost and the C and C++ basic library (boost::thread will use pthread) 00:39 < mryandao> weird, unless apt-get by default packages all of them together? 00:39 < mryandao> i did put down the `apt-get install libboost-thread-dev` 00:39 < wumpus> I'm all for moving away from boost, over time, but these kinds of cheap digs at the library annoy me too 00:41 < wumpus> strange - I'd write that up to debian instead of fundamental thing with boost itself 00:42 < 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 00:49 < mryandao> wumpus: cool, thanks. 00:53 < wumpus> see also #12381 00:53 < gribble> https://github.com/bitcoin/bitcoin/issues/12381 | Remove more boost threads by theuni · Pull Request #12381 · bitcoin/bitcoin · GitHub 00:56 -!- harrymm [~harrymm@104.207.83.35] has quit [] 00:58 -!- harrymm [~harrymm@104.207.83.39] has joined #bitcoin-core-dev 01:07 -!- Krellan [~Krellan@2601:640:4000:9258:c55f:52a7:b8b8:e7df] has joined #bitcoin-core-dev 01:09 < 7YSAAYFCN> [bitcoin] laanwj closed pull request #13317: [0.16.1] Remaining backports (0.16...Mf1805-016ForBackport) https://github.com/bitcoin/bitcoin/pull/13317 01:09 < 94KAACTBR> [bitcoin] laanwj pushed 9 new commits to 0.16: https://github.com/bitcoin/bitcoin/compare/50b2c9e0dfbe...bfd1e923335e 01:09 < 94KAACTBR> bitcoin/0.16 c71e535 Suhas Daftuar: Bugfix: ensure consistency of m_failed_blocks after reconsiderblock... 01:09 < 94KAACTBR> bitcoin/0.16 0948153 Matt Corallo: Do not unlock cs_main in ABC unless we've actually made progress.... 01:09 < gribble> https://github.com/bitcoin/bitcoin/issues/13317 | [0.16.1] Remaining backports by MarcoFalke · Pull Request #13317 · bitcoin/bitcoin · GitHub 01:09 < 94KAACTBR> bitcoin/0.16 bb79aaf Jesse Cohen: Fix concurrency-related bugs in ActivateBestChain... 01:09 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-dev 01:13 -!- Krellan [~Krellan@2601:640:4000:9258:c55f:52a7:b8b8:e7df] has quit [Ping timeout: 260 seconds] 01:29 < bitcoin-git> [bitcoin] eklitzke opened pull request #13335: Implement pinentry wrapper to unlock bitcoin wallet (master...pinentry) https://github.com/bitcoin/bitcoin/pull/13335 01:33 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev 01:35 -!- JackH [~laptop@79-73-185-29.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev 01:42 -!- tum [b4b7b073@gateway/web/freenode/ip.180.183.176.115] has joined #bitcoin-core-dev 01:43 -!- tum [b4b7b073@gateway/web/freenode/ip.180.183.176.115] has quit [Client Quit] 01:43 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev 01:48 -!- drizztbsd [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev 01:48 -!- timothy [~tredaelli@redhat/timothy] has quit [Ping timeout: 252 seconds] 01:52 -!- drizztbsd is now known as timothy 01:52 -!- berndj [~berndj@mail.azna.co.za] has quit [Read error: Connection reset by peer] 01:54 -!- berndj [~berndj@mail.azna.co.za] has joined #bitcoin-core-dev 01:57 -!- raarr [raarr@gateway/vpn/privateinternetaccess/raarr] has quit [Ping timeout: 245 seconds] 02:07 -!- bitconner [~conner@136.24.175.89] has joined #bitcoin-core-dev 02:10 -!- berndj [~berndj@mail.azna.co.za] has quit [Read error: Connection reset by peer] 02:13 -!- berndj [~berndj@mail.azna.co.za] has joined #bitcoin-core-dev 02:20 -!- satwo [~textual@2602:306:378a:6fb0:6497:190e:914d:9c2b] has joined #bitcoin-core-dev 02:24 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 245 seconds] 02:25 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev 02:28 * midnightmagic will love whoever it is, forever, who removed boost entirely as a dependency for bitcoin. :) 02:39 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev 02:39 < fanquake> wumpus I think #13319 should be ready as well. 02:39 < gribble> https://github.com/bitcoin/bitcoin/issues/13319 | [0.16.1] gui: Backport bech32 checkbox by MarcoFalke · Pull Request #13319 · bitcoin/bitcoin · GitHub 02:41 -!- jtimon [~quassel@226.110.132.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 02:49 -!- arowser [~arowser@45.32.248.113] has quit [Remote host closed the connection] 02:49 -!- arowser [~arowser@45.32.248.113] has joined #bitcoin-core-dev 02:51 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer] 02:52 -!- cdecker [~cdecker@mail.snyke.net] has joined #bitcoin-core-dev 02:52 -!- arowser_ [~arowser@45.32.248.113] has joined #bitcoin-core-dev 02:52 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 02:53 -!- wallet42_ [sid154231@gateway/web/irccloud.com/x-wprdbhoyzvvdzufo] has joined #bitcoin-core-dev 02:55 -!- berndj [~berndj@mail.azna.co.za] has quit [Read error: Connection reset by peer] 02:56 -!- RoBz_ [~RoBz@ns362655.ip-91-121-175.eu] has joined #bitcoin-core-dev 02:57 -!- kinlo_ [~peter@unaffiliated/kinlo] has joined #bitcoin-core-dev 02:57 -!- berndj [~berndj@mail.azna.co.za] has joined #bitcoin-core-dev 03:01 -!- wallet42_ is now known as wallet42 03:01 -!- kinlo_ is now known as kinlo 03:03 -!- Dyaheon [~Dya@dsl-trebng21-58c19c-197.dhcp.inet.fi] has quit [Ping timeout: 240 seconds] 03:06 -!- Dyaheon [~Dya@dsl-trebng21-58c19c-197.dhcp.inet.fi] has joined #bitcoin-core-dev 03:08 < bitcoin-git> [bitcoin] laanwj pushed 4 new commits to 0.16: https://github.com/bitcoin/bitcoin/compare/bfd1e923335e...07fb2a6e166f 03:08 < bitcoin-git> bitcoin/0.16 ea487f9 Luke Dashjr: GUI: Rephrase Bech32 checkbox text/tooltip... 03:08 < bitcoin-git> bitcoin/0.16 0eda98d Luke Dashjr: GUI: Allow generating Bech32 addresses with a legacy-address default... 03:08 < bitcoin-git> bitcoin/0.16 dcb13a0 MarcoFalke: qt: Update translations pre-rc1 03:08 -!- baldur [~baldur@pool-100-2-154-254.nycmny.btas.verizon.net] has joined #bitcoin-core-dev 03:09 < wumpus> fanquake: does that mean we can roll 0.16.0rc1 today? 03:09 < wumpus> 0.16.1rc1 03:09 -!- herzmeister[m] [herzmeiste@gateway/shell/matrix.org/x-zbbgvrbjqjbqktbj] has joined #bitcoin-core-dev 03:10 -!- nsh- [~lol@wikipedia/nsh] has joined #bitcoin-core-dev 03:14 < 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 03:14 < gribble> https://github.com/bitcoin/bitcoin/issues/12337 | 0.16 Shutdown assertion · Issue #12337 · bitcoin/bitcoin · GitHub 03:15 < wumpus> was just looking at that - I don't think it has to block anything 03:15 < fanquake> Yep, I think an rc1 can move ahead. Can always be fixed if it comes up again during testing 03:17 < fanquake> Have updated all the projects and un-tagged backports etc. 03:17 -!- satwo [~textual@2602:306:378a:6fb0:6497:190e:914d:9c2b] has quit [Ping timeout: 245 seconds] 03:17 -!- m8tion [~Agence@abo-134-110-68.mrs.modulonet.fr] has joined #bitcoin-core-dev 03:23 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving] 03:27 -!- Austen58Grimes [~Austen58G@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-dev 03:36 < wumpus> thanks! 04:00 -!- jtimon [~quassel@226.110.132.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 04:06 < provoostenator> I'd like to get #11658 in if that's still possible. 04:06 < 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 04:06 < luke-jr> not sure it's a bugfix 04:07 -!- zautomata [~zautomata@41.43.174.236] has quit [Quit: WeeChat 1.9.1] 04:07 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 04:07 < provoostenator> Oh is 0.16.1 purely backports and not masteR? 04:07 < provoostenator> In that case it can wait for 0.17 04:08 < fanquake> provoostenator correct, https://github.com/bitcoin/bitcoin/tree/0.16 04:08 < luke-jr> the 3rd number of a version is always for bugfixes (and in our case, consensus protocol updates) 04:11 < 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 04:13 < fanquake> wumpus will you tag an rc tonight? 04:15 -!- BullShark [uid226214@gateway/web/irccloud.com/x-kpikheobkqoscasw] has joined #bitcoin-core-dev 04:27 -!- harrymm [~harrymm@104.207.83.39] has quit [Ping timeout: 256 seconds] 04:32 -!- arowser_ [~arowser@45.32.248.113] has quit [Remote host closed the connection] 04:32 -!- arowser_ [~arowser@45.32.248.113] has joined #bitcoin-core-dev 04:34 < wumpus> fanquake: I'm working on doing last-minute checks now 04:35 < fanquake> wumpus: np, let me know if you need a hand with anything. I'll be up for another couple hours. 04:35 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to 0.16: https://github.com/bitcoin/bitcoin/compare/07fb2a6e166f...81bc9829cdaf 04:35 < bitcoin-git> bitcoin/0.16 b42c355 Wladimir J. van der Laan: qt: Pre-rc1 transifex pull... 04:35 < bitcoin-git> bitcoin/0.16 81bc982 Wladimir J. van der Laan: build: Bump version to 0.16.1... 04:38 -!- Sinclair_ [sinclair6@gateway/vpn/privateinternetaccess/sinclair6] has joined #bitcoin-core-dev 04:39 < wumpus> fanquake: just trying to build on a few platforms would help 04:39 -!- harrymm [~harrymm@104.207.83.39] has joined #bitcoin-core-dev 04:40 < fanquake> wumpus: I'll start building 81bc982 04:43 -!- Sinclair_ [sinclair6@gateway/vpn/privateinternetaccess/sinclair6] has quit [Client Quit] 04:43 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Remote host closed the connection] 04:44 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Remote host closed the connection] 04:44 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev 04:49 -!- berndj [~berndj@mail.azna.co.za] has quit [Read error: Connection reset by peer] 04:52 < wumpus> are you going to try OpenBSD? 04:52 < fanquake> wumpus I can do, it'll probably be 6.2 though 04:52 < fanquake> Haven't setup a 6.3 VM yet 04:53 < wumpus> I asked because I have the same problem, I should just be non-lazy and upgrade my VM 04:53 -!- berndj [~berndj@mail.azna.co.za] has joined #bitcoin-core-dev 04:54 < wumpus> at least freebsd is still 11.1, I'll do that one 04:59 < fanquake> wumpus How about your Windows Vista VM :p 05:03 < wumpus> you mean the windows XP one? :-) 05:03 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 05:04 < fanquake> wumpus You are welcome to test, but we ditched XP with 0.16 :0 05:05 -!- mistergold [~mistergol@77.243.22.221] has joined #bitcoin-core-dev 05:06 < luke-jr> sigh, btrfs really does suck 05:06 < fanquake> I think we could backport #13246 for 0.16, worthwhile improvements to the Windows build process. 05:06 < 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 05:07 < wumpus> I don't have any other windows VMs though, nor are there any windows computers left here 05:07 < fanquake> Not necessarily a bad thing 05:08 < wumpus> luke-jr: what terrible wrong did it do to you today? 05:08 < luke-jr> wumpus: I started my node an hour or so ago, and it's still 12 days behind (basically where it began) 05:08 < luke-jr> in the meantime, the whole PC has slowed to a crawl 05:09 < fanquake> sounds kinda like my laptop whenever there's > 2 VM running 05:12 < luke-jr> (as well as random unexplained WARNING stack dumps in dmesg) 05:24 -!- qu4ku [~qu4ku@2a01:110f:f73:1b00:e58c:96dd:41b0:8c2] has joined #bitcoin-core-dev 05:28 < sipa> provoostenator: 0.16.1 will be created by tagging the 0.16 branch, not master 05:29 < sipa> 0.16 branched off from master a bit before 0.16.0 05:29 < sipa> and indeed since the feature freeze (shortly before the branch) there are only bugfixes in it 05:30 < sipa> which are backports of changes in master 05:30 < luke-jr> looks like about 10 minutes to process each block -.- 05:32 < booyah> luke-jr: after all this years? :/ 05:33 < luke-jr> never going to catch up at this rate 05:33 -!- retrop99 [~retrop99@cpc98334-croy25-2-0-cust202.19-2.cable.virginm.net] has joined #bitcoin-core-dev 05:37 < wumpus> that's slower than my slowest ARM board FWIW 05:38 < wumpus> (including lame things such as slow SD cards, slow ethernet, and external USB2 harddrives) 05:39 < 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 05:39 < wumpus> fanquake: thanks! 05:41 < fanquake> I'm doing my testing with 18.04, and getting rid of those work around is a + 05:42 < wumpus> definitely 05:42 < wumpus> good to think of that 05:43 -!- drexl [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has joined #bitcoin-core-dev 05:58 -!- promag [~promag@62.28.242.62] has joined #bitcoin-core-dev 05:58 -!- berndj [~berndj@mail.azna.co.za] has quit [Read error: Connection reset by peer] 06:00 -!- berndj [~berndj@mail.azna.co.za] has joined #bitcoin-core-dev 06:01 < luke-jr> moved chainstate to SSD, more like 10 seconds per block now (still btrfs'd) 06:03 -!- arowser_ [~arowser@45.32.248.113] has quit [Remote host closed the connection] 06:04 -!- arowser_ [~arowser@45.32.248.113] has joined #bitcoin-core-dev 06:05 < 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 06:06 -!- retrop99 [~retrop99@cpc98334-croy25-2-0-cust202.19-2.cable.virginm.net] has quit [Ping timeout: 256 seconds] 06:11 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 260 seconds] 06:14 -!- berndj [~berndj@mail.azna.co.za] has quit [Read error: Connection reset by peer] 06:15 -!- berndj [~berndj@mail.azna.co.za] has joined #bitcoin-core-dev 06:17 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 06:20 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Quit: Leaving] 06:22 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 06:23 < wumpus> FreeBSD 11.1 and OpenBSD 6.2 builds OK 06:23 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev 06:24 < fanquake> macOS 10.13.5 builds OK. Currently building depends on Windows 10 06:28 < luke-jr> hm, there must be something wrong. ps claims bitcoin-qt's SIZE is 37 GB :| 06:28 -!- qu4ku [~qu4ku@2a01:110f:f73:1b00:e58c:96dd:41b0:8c2] has quit [Quit: Textual IRC Client: www.textualapp.com] 06:32 < wumpus> (also Ubuntu 16.04 and 18.04, but that's not really surprising) 06:32 < wumpus> luke-jr: ouch, can you bisect that? 06:32 -!- berndj [~berndj@mail.azna.co.za] has quit [Max SendQ exceeded] 06:33 < luke-jr> wumpus: it's during startup, so.. I'm not sure it's a bug on our end 06:33 -!- berndj [~berndj@mail.azna.co.za] has joined #bitcoin-core-dev 06:33 < luke-jr> my first guess is -fsanitize stuff, so trying again without those 06:36 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 06:37 < 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? 06:37 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 06:37 < luke-jr> think* 06:37 < luke-jr> (and yes, disabling sanitizers seems to have fixed the insane SIZE) 06:38 < wumpus> ok, good to know, no worry for 0.16.1 then 06:38 -!- berndj [~berndj@mail.azna.co.za] has quit [Read error: Connection reset by peer] 06:41 -!- berndj [~berndj@mail.azna.co.za] has joined #bitcoin-core-dev 06:41 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 06:44 -!- arowser_ [~arowser@45.32.248.113] has quit [Remote host closed the connection] 06:44 -!- arowser_ [~arowser@45.32.248.113] has joined #bitcoin-core-dev 06:48 -!- contrapumpkin [~copumpkin@haskell/developer/copumpkin] has joined #bitcoin-core-dev 06:49 < wumpus> so if anyone else wants to try building the 0.16 branch on various platforms, please do 06:50 < wumpus> if not, I'm going to tag rc1 after fanquake's windows build succeeds 06:54 < 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. 06:54 < gribble> https://github.com/bitcoin/bitcoin/issues/13306 | build: split warnings out of CXXFLAGS by theuni · Pull Request #13306 · bitcoin/bitcoin · GitHub 06:59 -!- arowser_ [~arowser@45.32.248.113] has quit [Remote host closed the connection] 06:59 -!- arowser_ [~arowser@45.32.248.113] has joined #bitcoin-core-dev 07:00 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev 07:02 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/610f4dd719ad...f5a7733ff767 07:02 < bitcoin-git> bitcoin/master 9e305b5 Cory Fields: build: split warnings out of CXXFLAGS... 07:02 < bitcoin-git> bitcoin/master f5a7733 Wladimir J. van der Laan: Merge #13306: build: split warnings out of CXXFLAGS... 07:03 < bitcoin-git> [bitcoin] laanwj closed pull request #13306: build: split warnings out of CXXFLAGS (master...debug_flags) https://github.com/bitcoin/bitcoin/pull/13306 07:03 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 07:03 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f5a7733ff767...fb7731089ed2 07:03 < bitcoin-git> bitcoin/master 1680b8b practicalswift: docs: Update OpenBSD build instructions for OpenBSD 6.3 07:03 < bitcoin-git> bitcoin/master fb77310 Wladimir J. van der Laan: Merge #13295: docs: Update OpenBSD build instructions for OpenBSD 6.3... 07:04 < 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 07:08 < fanquake> wumpus The depends build, compile and make install completed successfully, using the 18.04 instructions. 07:08 < fanquake> However the binaries wont launch.. 07:09 < fanquake> Trying another build, otherwise I'll have to try debugging tomorrow. 07:09 < wumpus> not even bitcoin-cli? 07:11 -!- nsh- is now known as nsh 07:12 -!- BullShark [uid226214@gateway/web/irccloud.com/x-kpikheobkqoscasw] has left #bitcoin-core-dev [] 07:13 < fanquake> Got some error output, 1 sec 07:14 < fanquake> heh, I'm seeing #12337 :( 07:14 < gribble> https://github.com/bitcoin/bitcoin/issues/12337 | 0.16 Shutdown assertion · Issue #12337 · bitcoin/bitcoin · GitHub 07:15 < fanquake> https://0bin.net/paste/1iOaeL+DunFWqy0n#gwr6oLIgrjlG45QDIdN4u2yqvUTIHGR3goxtENCMzwJ 07:20 < fanquake> wumpus ^ I need to sleep. Can continue investigating tomorrow. Up to you about an RC1 tag. 07:22 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [] 07:23 < wumpus> thanks, sleep well 07:24 -!- berndj [~berndj@mail.azna.co.za] has quit [Read error: Connection reset by peer] 07:26 -!- arowser_ [~arowser@45.32.248.113] has quit [Remote host closed the connection] 07:26 -!- arowser_ [~arowser@45.32.248.113] has joined #bitcoin-core-dev 07:27 -!- berndj [~berndj@197.242.93.84] has joined #bitcoin-core-dev 07:29 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/fb7731089ed2...14a4b4966361 07:29 < bitcoin-git> bitcoin/master fa9da85 MarcoFalke: qa: Initialize lockstack to prevent null pointer deref 07:29 < bitcoin-git> bitcoin/master 14a4b49 Wladimir J. van der Laan: Merge #13300: qa: Initialize lockstack to prevent null pointer deref... 07:30 < 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 07:31 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 07:31 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 07:32 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 07:33 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 256 seconds] 07:35 -!- arowser_ [~arowser@45.32.248.113] has quit [Remote host closed the connection] 07:36 -!- arowser_ [~arowser@45.32.248.113] has joined #bitcoin-core-dev 07:37 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds] 07:38 -!- arowser_ [~arowser@45.32.248.113] has quit [Remote host closed the connection] 07:39 -!- arowser_ [~arowser@45.32.248.113] has joined #bitcoin-core-dev 07:40 < 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 07:40 < gribble> https://github.com/bitcoin/bitcoin/issues/12337 | 0.16 Shutdown assertion · Issue #12337 · bitcoin/bitcoin · GitHub 07:40 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 07:52 -!- contrapumpkin [~copumpkin@haskell/developer/copumpkin] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] 07:54 < wumpus> but I'll wait for some other opinions... 08:04 -!- marcoagner [~user@156.97.60.94.rev.vodafone.pt] has quit [Ping timeout: 240 seconds] 08:10 -!- arowser_ [~arowser@45.32.248.113] has quit [Remote host closed the connection] 08:10 -!- arowser_ [~arowser@45.32.248.113] has joined #bitcoin-core-dev 08:10 < ken2812221> Should we backport #13131? 08:10 < gribble> https://github.com/bitcoin/bitcoin/issues/13131 | Add Windows shutdown handler by ken2812221 · Pull Request #13131 · bitcoin/bitcoin · GitHub 08:11 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/14a4b4966361...a315b79ad2b8 08:11 < bitcoin-git> bitcoin/master 2885c13 Jonas Schnelli: Qt: use [default wallet] as name for wallet with no name 08:11 < bitcoin-git> bitcoin/master a315b79 Wladimir J. van der Laan: Merge #13275: Qt: use [default wallet] as name for wallet with no name... 08:11 < 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 08:12 < wumpus> i'm ok with that, for 0.16.2 though 08:13 < 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 08:14 -!- berndj [~berndj@197.242.93.84] has quit [Read error: Connection reset by peer] 08:15 -!- promag [~promag@62.28.242.62] has quit [Remote host closed the connection] 08:17 -!- marcoagner [~user@156.97.60.94.rev.vodafone.pt] has joined #bitcoin-core-dev 08:17 < ken2812221> ok 08:18 -!- berndj [~berndj@mail.azna.co.za] has joined #bitcoin-core-dev 08:24 -!- contrapumpkin [~copumpkin@haskell/developer/copumpkin] has joined #bitcoin-core-dev 08:24 < jonasschnelli> "A Bech32[2] string is at most 90 characters long and consists of:"... that is not a bech32 limit, right? 08:24 < jonasschnelli> https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#bech32 08:28 < Chris_Stewart_5> jonasschnelli: I'm curious why that is in place too. I think the lightning network teams break that rule as well 08:28 < wumpus> I think the properties would no longer hold with the same checksum length 08:29 < wumpus> and longer data length 08:29 < jonasschnelli> Chris_Stewart_5: I guess it refers to the max length for a native P2SH address 08:29 < jonasschnelli> wumpus: ah. that is a point 08:30 -!- TannerR [~TannerR@h166.14.22.98.dynamic.ip.windstream.net] has joined #bitcoin-core-dev 08:31 < jonasschnelli> wumpus: https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#checksum-design, yes. your right 08:31 < jonasschnelli> length 89 is the max for ≤4 wrong chars tolerance 08:39 < sipa> jonasschnelli: bip173 addresses are at most 74 characters 08:39 < sipa> bech32 encoding supports up to 90 characters (including prefix and separator) 08:40 < sipa> in some places a version of bech32 is used that violates that limit (e.g. lightning payments) 08:48 -!- arowser_ [~arowser@45.32.248.113] has quit [Remote host closed the connection] 08:48 -!- arowser_ [~arowser@45.32.248.113] has joined #bitcoin-core-dev 08:50 < jonasschnelli> sipa: "a version of" means modified code or just exceed of that limit that no longer "guarantees" the 4 chars correction? 08:51 < jonasschnelli> I though of using Bech32 for a new encoding format for extended keys but not sure if it makes sense at these lengths 08:51 < jonasschnelli> I *thought 08:52 < 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 08:54 < jonasschnelli> thanks aj 08:56 < sipa> jonasschnelli: for pivate keys you want something else 08:57 < sipa> addresses only need error detection 08:58 < 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 08:58 < sipa> while failed private keys have no such option 08:59 -!- arowser_ [~arowser@45.32.248.113] has quit [Remote host closed the connection] 09:00 -!- arowser_ [~arowser@45.32.248.113] has joined #bitcoin-core-dev 09:02 -!- Krellan [~Krellan@2601:640:4000:9258:c55f:52a7:b8b8:e7df] has joined #bitcoin-core-dev 09:03 -!- arowser_ [~arowser@45.32.248.113] has quit [Remote host closed the connection] 09:04 -!- arowser_ [~arowser@45.32.248.113] has joined #bitcoin-core-dev 09:13 -!- arowser_ [~arowser@45.32.248.113] has quit [Remote host closed the connection] 09:13 -!- arowser_ [~arowser@45.32.248.113] has joined #bitcoin-core-dev 09:17 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 09:19 -!- arowser_ [~arowser@45.32.248.113] has quit [Remote host closed the connection] 09:19 -!- arowser_ [~arowser@45.32.248.113] has joined #bitcoin-core-dev 09:32 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 09:34 -!- m8tion [~Agence@abo-134-110-68.mrs.modulonet.fr] has quit [Read error: Connection reset by peer] 09:54 < wumpus> any opinions on tagging rc1 or not? 09:56 < sipa> any things missing (according to some)? 09:57 < wumpus> well #12337 09:57 < gribble> https://github.com/bitcoin/bitcoin/issues/12337 | 0.16 Shutdown assertion · Issue #12337 · bitcoin/bitcoin · GitHub 09:59 < sipa> otherwise harmless assert failure at shutdown? 10:00 < wumpus> yes 10:02 < sipa> can we remove the assert...? 10:03 * sipa hides 10:06 < wumpus> that's not a bad idea 10:08 < wumpus> it doesn't seem to be a problem on master, just 0.16 10:08 < sipa> hmm 10:10 < 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 10:11 < wumpus> anyhow, maybe it doesn't matter too much for rc11 10:11 < wumpus> rc1* 10:12 < wumpus> depends on how quickly we want to start testing this 10:13 -!- timothy [~tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!] 10:14 -!- Giszmo [~leo@pc-72-54-46-190.cm.vtr.net] has joined #bitcoin-core-dev 10:17 -!- arowser_ [~arowser@45.32.248.113] has quit [Remote host closed the connection] 10:17 -!- arowser_ [~arowser@45.32.248.113] has joined #bitcoin-core-dev 10:18 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection] 10:19 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev 10:20 -!- arowser_ [~arowser@45.32.248.113] has quit [Remote host closed the connection] 10:21 -!- arowser_ [~arowser@45.32.248.113] has joined #bitcoin-core-dev 10:23 < 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 10:24 < sipa> ah, you mean fix the assert in rc2/final? 10:25 < wumpus> yes 10:25 < sipa> sgtm 10:25 < wumpus> it makes the process somewhat more parallel instead of serial 10:26 -!- berndj [~berndj@mail.azna.co.za] has quit [Read error: Connection reset by peer] 10:28 -!- berndj [~berndj@mail.azna.co.za] has joined #bitcoin-core-dev 10:38 -!- arowser_ [~arowser@45.32.248.113] has quit [Remote host closed the connection] 10:38 -!- arowser_ [~arowser@45.32.248.113] has joined #bitcoin-core-dev 10:39 -!- pergaminho [~Cleber@201.47.91.172] has joined #bitcoin-core-dev 10:39 < pergaminho> Olá alguém de São Paulo? 10:40 < sipa> english please 10:41 < pergaminho> Excuse me, I want to know if there's anyone in Sao Paulo. 10:44 -!- arowser_ [~arowser@45.32.248.113] has quit [Remote host closed the connection] 10:44 < wumpus> that seems very off topic 10:44 -!- arowser_ [~arowser@45.32.248.113] has joined #bitcoin-core-dev 10:51 -!- nmnkgl [~nmnkgl@c-73-189-35-88.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 10:51 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 260 seconds] 10:51 -!- bapu [d5c4e451@gateway/web/freenode/ip.213.196.228.81] has joined #bitcoin-core-dev 10:55 -!- laurentmt [~Thunderbi@185.94.189.189] has joined #bitcoin-core-dev 11:19 -!- TannerR [~TannerR@h166.14.22.98.dynamic.ip.windstream.net] has quit [Ping timeout: 252 seconds] 11:21 -!- arowser_ [~arowser@45.32.248.113] has quit [Remote host closed the connection] 11:21 -!- arowser_ [~arowser@45.32.248.113] has joined #bitcoin-core-dev 11:23 < wumpus> * [new tag] v0.16.1rc1 -> v0.16.1rc1 11:24 < sipa> w00t 11:25 -!- arowser_ [~arowser@45.32.248.113] has quit [Remote host closed the connection] 11:25 -!- arowser_ [~arowser@45.32.248.113] has joined #bitcoin-core-dev 11:27 -!- arowser_ [~arowser@45.32.248.113] has quit [Remote host closed the connection] 11:28 -!- arowser_ [~arowser@45.32.248.113] has joined #bitcoin-core-dev 11:30 -!- arowser_ [~arowser@45.32.248.113] has quit [Remote host closed the connection] 11:30 -!- arowser_ [~arowser@45.32.248.113] has joined #bitcoin-core-dev 11:31 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev 11:32 < achow101> yay 11:38 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 252 seconds] 11:38 -!- laurentmt [~Thunderbi@185.94.189.189] has quit [Quit: laurentmt] 11:44 -!- Giszmo [~leo@pc-72-54-46-190.cm.vtr.net] has quit [Ping timeout: 256 seconds] 11:45 < jonasschnelli> sipa: have you explored the field of BCH codes suitable for private keys? 11:48 < sipa> jonasschnelli: yes, a bit 11:48 < sipa> but the tradeoffs are hard 11:49 < sipa> strictly for private keys, you could correct 4 errors with 12 characters of checksum 11:49 < sipa> but not with an efficient algorithm 11:49 < jonasschnelli> with private keys you mean 256bits, right? 11:50 < sipa> yes 11:50 < jonasschnelli> Hmm... for an xpriv, if the chaincode should also have the same robustness, it is maybe an overkill in length 11:52 < jonasschnelli> sipa: how are Bech32 properties for 512 bits? How much chars would be guaranteed in the correction? 11:52 < 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 11:53 < jonasschnelli> I'd say that is accaptable... 11:53 < jonasschnelli> I would also say 4 error may be acceptable for 103 chars 11:53 < jonasschnelli> Ideally it would be flexible ("choose your size / robustness") 11:53 < sipa> such a code would guarantee correction of 4 up to length 1023 11:54 < sipa> (of which 15 are checksum characters, and 1008 are data) 11:54 -!- Giszmo [~leo@pc-72-54-46-190.cm.vtr.net] has joined #bitcoin-core-dev 11:55 < jonasschnelli> sipa: hmm... and there is no optimised code for something up to 103 chars (512bit in base32). 11:55 < jonasschnelli> ? 11:56 < sipa> jonasschnelli: so there is an important distinction here 11:56 < sipa> a BCH code is a just a subset of cyclic codes, with parameters generated in a specific way 11:56 < jonasschnelli> the 4 in 1023? 11:57 < sipa> that specific way guarantees (1) a certain level of error correction and (2) an efficient algorithm to do so 11:57 < sipa> all these codes are however "better" than what they're designed for 11:57 < jonasschnelli> so the BCH subset may not be ideal for private keys 11:57 < sipa> it absolutely is not 11:57 < sipa> BCH codes are not optimal 11:57 < sipa> but they're easy 11:58 < sipa> (and they may be close to optimal) 11:58 < sipa> bech32 is a BCH code that only guarantees detecting 3 errors up to length 1023... that's the BCH part 11:58 < 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 11:59 < sipa> that took a few years of CPU time to find out, though :) 11:59 < jonasschnelli> Yes. I heard that. :) 11:59 < sipa> the BCH part is just math; i can tell you in an instant how good a code is 11:59 < sipa> but no, i can't create a BCH code whose _designed_ strength is optimal for 103 characters; no such codes exist 12:00 < jonasschnelli> I see... 12:00 < sipa> there do exist BCH codes for length 93, FWIW :) 12:00 < sipa> with just 13 checksum characters, even 12:00 < sipa> but the next one up is for length 1023 12:01 < jonasschnelli> Unsure if 4 chars are enough for a private key... 12:01 < jonasschnelli> Implementation wise, using bech32 would be a great thing since it will very likely be already present in the code/framework... 12:01 -!- str4d [~str4d@27.110.123.92] has joined #bitcoin-core-dev 12:02 < sipa> 19 checksum characters if you want an efficient way to correct 5 12:03 < jonasschnelli> new proposals may lead to not getting implemented because of a complex implementation,... bech32 would make it pretty simple 12:03 < sipa> the checksum algorithm for all of these is trivial 12:03 < sipa> just as simple as bech32, but with larger integers 12:03 < sipa> the error correction algorithm is more complex (but very fast) 12:03 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 12:04 < jonasschnelli> the 19/5 code is in the BCH subset (up to 1023)? 12:04 < sipa> yup 12:05 < jonasschnelli> Something you drilled out of your supermachine? 12:05 < jonasschnelli> (calculated on your own?) 12:05 < sipa> no, this is just BCH 12:05 < sipa> it's a simple sage script to compute these 12:05 < sipa> they're not optimized for anything beyong their design strength 12:06 < sipa> among all the 19/5 codes (there are likely thousands) i could search for the "best" one according to some extra criteria 12:07 < jonasschnelli> So it could be possible to find a 19/6 within a length property of l<103? 12:07 < jonasschnelli> <= 12:07 < sipa> that seems unlikely, but it's possible yes 12:08 < sipa> it may also take more computing power than we have 12:08 < jonasschnelli> I see 12:08 < sipa> however, if it's just for single private keys, we could use length 93 codes 12:09 < sipa> where just 13 characters for 4 corrections, or 16 characters for 5, is sufficient 12:10 -!- arowser_ [~arowser@45.32.248.113] has quit [Ping timeout: 268 seconds] 12:10 < jonasschnelli> That would not cover encoding an extended private key though.... 12:10 < sipa> yup 12:10 < sipa> also, codes _designed_ for length 93 will perform terrible beyond it 12:10 < jonasschnelli> Metadata could be ouside of the cyclic code,.. but within the checksum (is that even possible?)? 12:10 < sipa> no 12: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 12:11 < jonasschnelli> So an additional checksum 12:11 < sipa> that's a bit ridiculous 12:11 -!- arowser_ [~arowser@45.32.248.113] has joined #bitcoin-core-dev 12:11 < jonasschnelli> we only would need to detect errors in the metadata pert... even a parity bit would be okayish? 12:12 < jonasschnelli> *part 12:12 < sipa> but metadata includes chaincode etcx 12:12 < jonasschnelli> chaincode is essential IMO 12:12 -!- pergaminho [~Cleber@201.47.91.172] has quit [Quit: Saindo] 12:12 < jonasschnelli> must be within the error correcting part 12:12 < sipa> yeah, exactly- i agree 12:12 < sipa> so a length 93 code is out of the question 12:13 < jonasschnelli> 512bits seems to be the minimum if it should cover xprivs 12:13 < jonasschnelli> (other xpriv then m) 12:13 < jonasschnelli> If we would only cover m, one could think of encoding the seed 12:13 < jonasschnelli> of the seed & keypath? 12:13 < jonasschnelli> but meh for hardened protection 12:14 < jonasschnelli> wait, nm my last line 12:15 < sipa> 11 char checksum for correcting 3, 15 for correcting 4, 19 for correcting 5 12:16 -!- nmnkgl [~nmnkgl@c-73-189-35-88.hsd1.ca.comcast.net] has quit [Remote host closed the connection] 12:18 < 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? 12:18 < jonasschnelli> Also, reusing bech32 would be very desirable... 12:18 < sipa> yes, but you can't have both 12:18 < jonasschnelli> Right now, we have 0 correction with Base58c 12:18 < sipa> bech32 can only correct 2, and inefficiently 12:19 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Quit: Leaving] 12:19 < sipa> you design for a single combination of length and correction strength 12:19 < sipa> it will likely be better for shorter lengths, but not have an efficient algorithm to do so 12:20 < jonasschnelli> Hmm... i though bech32 corrects 4 errors up to length 89? 12:20 < jonasschnelli> *thought 12:20 < sipa> no, it *detects* 4 12:20 < jonasschnelli> ah. I see 12:20 < sipa> correction strength is always only half of the detection strength 12:20 < jonasschnelli> meh 12:21 < jonasschnelli> that is what we need for private keys. :/ 12:21 < jonasschnelli> Yes. I guess then we need another encoding implementation... ideally as simple as bech32 12:22 -!- nmnkgl [~nmnkgl@c-73-189-35-88.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 12:24 < sipa> what do you think about a 103-character checksum code that can correct 28 errors? :) 12:24 < sipa> (doubling the length of the string) 12:25 < gmaxwell> I'm fond of that, but whats the efficiency of the correction code for that? 12:25 < jonasschnelli> sipa: I think very acceptable.. really 12:25 < sipa> 206 characters is a lot :) 12:26 < sipa> gmaxwell: efficiency in terms of what? 12:26 < jonasschnelli> I think the correct code efficiency is not very important for private keys 12:26 < jonasschnelli> *correction 12:26 < gmaxwell> is it a design distance 56 code? with an efficienct locator algorithim? 12:26 < gmaxwell> jonasschnelli: it matters if its intractably slow. 12:26 < sipa> gmaxwell: distance 58 actually, design length 341 12:27 < sipa> so it could have up to 238 data characters 12:27 -!- Kvaciral [~Kvaciral@5ED6B9A2.cm-7-7c.dynamic.ziggo.nl] has joined #bitcoin-core-dev 12:27 < gmaxwell> sipa: I guess I'd want to try writing down 206 characters and see how much I hate my life. :) 12:27 < sipa> gmaxwell: why would correct be slow? 12:29 < 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. 12:29 < sipa> factoring the locator polynomial should be fast; the field size is just 32^2 12:29 < sipa> ah, i see 12:29 < sipa> all i'm talking about here are algebraic properties 12:30 < 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. 12:30 < sipa> indeed :) 12:30 < gmaxwell> since the search process and the decode process are essential the same. 12:32 < gmaxwell> sipa: your suggested code also has enough length to have some metadata, a nonce for encryption, etc. 12:33 < sipa> yup 12:33 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 12:33 < sipa> but 2x length is... a lot 12:33 < jonasschnelli> To keep the write-down-by-hand property, I guess something beyond bech32 will not be tolerated/used. 12:34 < gmaxwell> jonasschnelli: huh? 12:34 < jonasschnelli> gmaxwell: do you think 206 chars are acceptable to write down? 12:34 < gmaxwell> That doesn't follow from what you're saying there. :) 12:34 < jonasschnelli> I mean it always depends what sort of key your dealing with... 12:35 < 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. 12:36 < gmaxwell> But yes, writing down 206 might be too much, which is why I said I'd want to try it. :) 12:36 < gmaxwell> But 206 being too much doesn't mean that beyond bech32 isn't fine. 12:36 < jonasschnelli> heh.. yes. I need to try that as well... 12:36 < jonasschnelli> Yes. That is true 12:36 < 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). 12:37 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 12:37 < gmaxwell> For a while before sipa was searching for 12 digit checksums (so 6 more digits than bech32). 12:37 < jonasschnelli> Yes. I wonder now why seed encoding proposals do have no error correction at all (or do they, AFAIL no)? 12:38 < 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. 12:38 < jonasschnelli> Yes. The stove/stone error that took me days to figure out... :/ 12:39 < gmaxwell> ugh. yes, a problem with informal is that the worst case errors are going to be pretty bad. 12:40 < jonasschnelli> (also wonder why they have chosen "stove" and "stone" while we know that the n and the v look often very similar) 12:41 < gmaxwell> There really isn't a lot of good data on visual similarities of letters. This was a challenge in designing bech32 too. 12:41 < jonasschnelli> "12 digit checksum" (gmaxwell above) would result in 6 chars correction, right? 12:41 -!- TannerR [~TannerR@h166.14.22.98.dynamic.ip.windstream.net] has joined #bitcoin-core-dev 12:42 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds] 12:43 < 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. 12:43 < gmaxwell> (maybe even only 3? I'm not sure now... but thats why sipa was doing a search) 12:44 < 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... 12:45 < jonasschnelli> I see 12:49 < 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? 12:49 < jonasschnelli> https://github.com/lightningnetwork/lnd/tree/master/aezeed 12:49 < jonasschnelli> I don't see the relevance of the nonce-missuse resistance 12:50 -!- nmnkgl [~nmnkgl@c-73-189-35-88.hsd1.ca.comcast.net] has quit [] 12:51 < gmaxwell> I haven't seen it before. 12:51 < 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 12:51 < jonasschnelli> (which results in no longer be 24 words probably) 12:51 < gmaxwell> a mac could be made whatever length.. so the other wallet people have been regarding authenticated encryption as a negative feature. 12:52 < gmaxwell> because they want the user to be able to be able to give out different passwords that work. 12:52 < jonasschnelli> plausible deniable,... yes. that may be a point. 12:53 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 12:53 < 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. 12:53 < gmaxwell> and you'd still get protection against a wrong password. 12:54 < jonasschnelli> cool! 12:54 < jonasschnelli> But I guess it could be really cpu-intense to find an alternative version that goes beyond gibberish things... 12:55 < gmaxwell> the downside being that the user couldn't freely choose the durress password. But I think thats probably acceptable. 12:55 < 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. 12:55 < 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 12:56 < gmaxwell> another way to do it that doesn't require search is to store two check values, and one must match. 12:56 < gmaxwell> roasbeef: the thing jonas linked to made it look like the plaintext key length is limited to 16 bytes tough? 12:57 < jonasschnelli> That was also my question, why only 128bit entropy? 12:57 < gmaxwell> jonasschnelli: with the store two check values approach to 'denyability' then there is no search, just the overhead of encoding two values. 12:57 < 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" 12:57 < 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 12:58 < roasbeef> y'all think 128-bits of entropy is insufficient? 12:58 < 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. 12:58 < jonasschnelli> Not sure... but if I can choose, I chose 256. :) 12:58 < jonasschnelli> *choose 12:58 < gmaxwell> roasbeef: it's probably sufficient, but it means you cannot encode existing values that come from schemes using 256 bits, sadly. 12:59 < gmaxwell> the BIP39 problem but somewhat less dumb. 12:59 < roasbeef> yeh, that's one detriment, but it's versioned so another version can be parameterized to store 256 bits 13:00 < jonasschnelli> roasbeef: is aez beeing considered crypto-analysed enough? 13:00 < roasbeef> it was amongst the caesar contest finalists, but dropped out iirc as it was difficult to implement efficeitnly in hardware 13:01 < jonasschnelli> roasbeef: What would be the downsides of using ChaCha20Poly1305? Only the nonce missue protection? 13:01 < jonasschnelli> or say "resistance" 13:02 < 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 13:03 < jonasschnelli> Got it. Thanks 13:05 < 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 13:07 < jonasschnelli> I would strongly prefer ChaCha over AEZ... but I'm not a cryptographer and have little arguments to say why. 13:08 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 256 seconds] 13:09 < 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) 13:09 < 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. 13:09 < 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. 13:10 < jonasschnelli> gmaxwell: in KDF, you referring to the salt? 13:10 < gmaxwell> Yes. 13:11 < gmaxwell> Without a decently sized nonce/salt the KDF will be gratitiously vulnerable to precomputation. 13:11 < gmaxwell> As far as KDFs go, reasonable KDFs are incompatible with hardware wallets, unless an outsourcable KDF is used. 13:11 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev 13:14 < jonasschnelli> if you have two macs, an attacker could ask for both passphrases,.. while the current BIP39 approach, there are "infinite" possibilities 13:14 < jonasschnelli> not sure if this would be a downside 13:14 < gmaxwell> jonasschnelli: "there is no second passphrase" 13:15 < gmaxwell> (if one one is used, you just set the other one to a random value) 13:15 < gmaxwell> with the BIP39 thing someone could also keep demanding your other passphrase while you protest that there isn't one. 13:15 < jonasschnelli> true 13:16 < jonasschnelli> though they could do the same if your second mac is based on a random passphrase. :) 13:16 < jonasschnelli> (or random MAC) 13:16 < 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) 13:16 < jonasschnelli> Yes. I guess it's a "marketing" feature. 13:17 < jonasschnelli> Also, if lying is something that is often easy detectable and needs more courage that one things 13:17 < jonasschnelli> *thinks 13:17 < 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. 13:18 < jonasschnelli> secret sharing? 13:18 < jonasschnelli> sharing secrets with something like the shamir approach? 13:19 < 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. 13:19 < gmaxwell> jonasschnelli: yes, being able to split the private key into multiple parts where all parts aren't required. 13:19 < jonasschnelli> Yes. Indeed. I also don't think that the feature is practical useful. 13:19 < jonasschnelli> (^ regarding deniability) 13:20 < jonasschnelli> gmaxwell: I think the secret sharing is way more pratical then the deniability feature) 13:22 < 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. 13:22 < gmaxwell> but yea, if I had to pick one I'd do SS. 13:22 < jonasschnelli> Indeed 13:22 -!- Krellan [~Krellan@2601:640:4000:9258:c55f:52a7:b8b8:e7df] has quit [Read error: Connection reset by peer] 13:23 -!- Krellan [~Krellan@2601:640:4000:9258:c55f:52a7:b8b8:e7df] has joined #bitcoin-core-dev 13:23 < 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.... 13:24 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 13:25 * jonasschnelli falls asleep 13:28 -!- drexl [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has quit [Quit: drexl] 13:29 -!- str4d [~str4d@27.110.123.92] has quit [Ping timeout: 248 seconds] 13:38 -!- bapu [d5c4e451@gateway/web/freenode/ip.213.196.228.81] has quit [Quit: Page closed] 13:59 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 14:00 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 14:01 -!- drexl [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has joined #bitcoin-core-dev 14:07 -!- retrop99 [~retrop99@213.152.161.181] has joined #bitcoin-core-dev 14:10 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/] 14:15 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)] 14:34 -!- bitconner [~conner@136.24.175.89] has quit [Ping timeout: 245 seconds] 14:35 -!- bitconner [~conner@136.24.175.89] has joined #bitcoin-core-dev 14:38 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 264 seconds] 14:40 -!- bitconner [~conner@136.24.175.89] has quit [Ping timeout: 260 seconds] 14:56 -!- retrop99 [~retrop99@213.152.161.181] has quit [Quit: My iMac has gone to sleep. ZZZzzz…] 14:58 -!- arowser_ [~arowser@45.32.248.113] has quit [Remote host closed the connection] 14:58 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 14:59 -!- arowser_ [~arowser@45.32.248.113] has joined #bitcoin-core-dev 15:06 -!- bitconner [~conner@64-71-8-130.static.wiline.com] has joined #bitcoin-core-dev 15:12 -!- mistergold [~mistergol@77.243.22.221] has quit [Read error: Connection reset by peer] 15:12 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...] 15:13 -!- mistergold [~mistergol@77.243.22.221] has joined #bitcoin-core-dev 15:15 -!- Krellan [~Krellan@2601:640:4000:9258:c55f:52a7:b8b8:e7df] has quit [Ping timeout: 260 seconds] 15:18 -!- Krellan [~Krellan@2601:640:4000:9258:c55f:52a7:b8b8:e7df] has joined #bitcoin-core-dev 15:25 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving] 15:27 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev 15:30 -!- arowser_ [~arowser@45.32.248.113] has quit [Remote host closed the connection] 15:32 -!- arowser_ [~arowser@45.32.248.113] has joined #bitcoin-core-dev 15:33 < 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. 15:34 < 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). 15:58 -!- bitconner [~conner@64-71-8-130.static.wiline.com] has quit [Ping timeout: 240 seconds] 16:00 -!- bitconner [~conner@64-71-8-130.static.wiline.com] has joined #bitcoin-core-dev 16:02 -!- Randolf [~randolf@96.53.47.42] has joined #bitcoin-core-dev 16:05 -!- lxer [~lx@ip5f5bd657.dynamic.kabel-deutschland.de] has quit [Ping timeout: 256 seconds] 16:05 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 16:19 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 16:29 -!- mistergold [~mistergol@77.243.22.221] has quit [Read error: Connection reset by peer] 16:37 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 268 seconds] 16:41 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 16:50 -!- rex4539 [~textual@2a02:587:3501:ea00:ddae:bd3e:4685:9ffe] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 17:01 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection] 17:01 < achow101> jhfrontz: I think it's supposed to be modifying the vm /etc/sudoers file as part of the setup. I believe that is part of whatever vmbuilder does. however I think vmbuilder had an update recently which breaks gitian 17:20 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev 17:24 -!- zivl [~zivl@2601:19a:837f:e4e1:39ab:2d1f:1ee2:33be] has quit [Ping timeout: 260 seconds] 17:32 -!- zivl [~zivl@2601:19a:837f:e4e1:3c61:99c2:c08:a488] has joined #bitcoin-core-dev 17:34 -!- MisterPaz [~PazPazPaz@176.10.116.112] has quit [Ping timeout: 260 seconds] 17:36 -!- satwo [~textual@2602:306:378a:6fb0:55b9:b64f:131:22e6] has joined #bitcoin-core-dev 17:55 -!- Giszmo [~leo@pc-72-54-46-190.cm.vtr.net] has quit [Ping timeout: 265 seconds] 17:55 -!- TannerR [~TannerR@h166.14.22.98.dynamic.ip.windstream.net] has quit [Quit: Leaving] 17:57 -!- CubicEarths [~cubiceart@c-73-181-185-197.hsd1.wa.comcast.net] has quit [Remote host closed the connection] 18:03 -!- Giszmo [~leo@pc-72-54-46-190.cm.vtr.net] has joined #bitcoin-core-dev 18:05 -!- CubicEarths [~cubiceart@c-73-181-185-197.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 18:05 -!- CubicEarths [~cubiceart@c-73-181-185-197.hsd1.wa.comcast.net] has quit [Remote host closed the connection] 18:06 -!- CubicEarths [~cubiceart@c-73-181-185-197.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 18:08 -!- CubicEarths [~cubiceart@c-73-181-185-197.hsd1.wa.comcast.net] has quit [Remote host closed the connection] 18:09 -!- CubicEarths [~cubiceart@c-73-181-185-197.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 18:13 -!- CubicEarths [~cubiceart@c-73-181-185-197.hsd1.wa.comcast.net] has quit [Ping timeout: 252 seconds] 18:17 -!- drexl [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has quit [Quit: drexl] 18:20 -!- CubicEarths [~cubiceart@c-73-181-185-197.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 18:30 < achow101> if anyone wants to try gitian building with docker instead of lxc or kvm, I have an experimental branch for that: https://github.com/achow101/gitian-builder/tree/docker 18:30 < achow101> It seems to work, but I don't know if it produces the same binaries yet 18:31 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 264 seconds] 18:44 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [] 19:01 -!- arowser_ [~arowser@45.32.248.113] has quit [Remote host closed the connection] 19:01 -!- arowser_ [~arowser@45.32.248.113] has joined #bitcoin-core-dev 19:05 -!- victorSN [~victorSN@ipc-hosting.de] has quit [Quit: Ping timeout (120 seconds)] 19:05 -!- victorSN [~victorSN@ipc-hosting.de] has joined #bitcoin-core-dev 19:05 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 19:07 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 256 seconds] 19:24 -!- fronti [~fronti@irc.fh-biergarten.de] has quit [Ping timeout: 256 seconds] 19:24 -!- comboy [~quassel@tesuji.pl] has quit [Remote host closed the connection] 19:24 -!- fronti [~fronti@irc.fh-biergarten.de] has joined #bitcoin-core-dev 19:26 -!- comboy [~quassel@tesuji.pl] has joined #bitcoin-core-dev 19:34 -!- Krellan [~Krellan@2601:640:4000:9258:c55f:52a7:b8b8:e7df] has quit [Read error: Connection reset by peer] 19:34 -!- Krellan [~Krellan@2601:640:4000:9258:4433:dd5:9ea1:1c28] has joined #bitcoin-core-dev 19:37 -!- Netsplit *.net <-> *.split quits: ajtowns[m], stepa[m], kewde[m], squarfed[m] 19:37 -!- Netsplit over, joins: kewde[m], squarfed[m], stepa[m], Magma, ajtowns[m] 19:39 -!- Netsplit over, joins: arubi, ghost43, intcat 19:40 -!- kewde[m] [kewdematri@gateway/shell/matrix.org/x-gqehuqvktzbalvgd] has quit [Ping timeout: 240 seconds] 19:40 -!- Dyaheon [~Dya@dsl-trebng21-58c19c-197.dhcp.inet.fi] has quit [Ping timeout: 260 seconds] 19:41 -!- ajtowns[m] [ajtownsmat@gateway/shell/matrix.org/x-bfpczunmqsplsaye] has quit [Ping timeout: 240 seconds] 19:41 -!- stepa[m] [stepamatri@gateway/shell/matrix.org/x-yrzbveofyuudvfmd] has quit [Max SendQ exceeded] 19:41 -!- squarfed[m] [squarfedma@gateway/shell/matrix.org/x-ruzyqdsmjswxxbir] has quit [Ping timeout: 240 seconds] 19:41 -!- herzmeister[m] [herzmeiste@gateway/shell/matrix.org/x-zbbgvrbjqjbqktbj] has quit [Ping timeout: 260 seconds] 19:41 -!- joshb[m] [joshbmatri@gateway/shell/matrix.org/x-qickicpdqrbywaij] has quit [Ping timeout: 260 seconds] 19:42 -!- Netsplit over, joins: contrapumpkin, victorSN 19:42 -!- Dyaheon [~Dya@dsl-trebng21-58c19c-197.dhcp.inet.fi] has joined #bitcoin-core-dev 19:45 -!- Netsplit over, joins: windsok, jonasschnelli, helo, dgenr8, paracyst, lightningbot, nullptr|, callonme, Aliencorpse, cryptapus (+9 more) 19:47 -!- Netsplit *.net <-> *.split quits: jchysk, RoBz_, wumpus, jcorgan, rev_strangehope, murrayn, MarcoFalke, tryphe, bitbee, treyzania, (+17 more, use /NETSPLIT to show all of them) 19:47 -!- Netsplit over, joins: kallewoof, bitconner, jtimon, phantomcircuit, mdrollette, tryphe, treyzania, jpe, RoBz_, murrayn (+4 more) 19:48 -!- rodarmor [sid210835@gateway/web/irccloud.com/x-tcjkgflitnihyxmp] has quit [Ping timeout: 245 seconds] 19:48 -!- Netsplit over, joins: sturles, spinza, bitbee, rev_strangehope, zhrek, TD-Linux, jcorgan, thaumavorio, earlz, TheCharlatan (+3 more) 19:49 -!- rodarmor [sid210835@gateway/web/irccloud.com/x-srkejydsozfgaquv] has joined #bitcoin-core-dev 19:49 -!- zivl [~zivl@2601:19a:837f:e4e1:3c61:99c2:c08:a488] has quit [Ping timeout: 245 seconds] 19:50 -!- Netsplit *.net <-> *.split quits: DrFeelGood, jimpo, Squidicuz, dc, qrestlove, Austen58Grimes, Anduck, booyah, dcousens, nsh, (+35 more, use /NETSPLIT to show all of them) 19:50 -!- Netsplit over, joins: booyah, jimpo, cfields, qinfengling, nsh, dcousens, zxzzt, adiabat, nickler, Victorsueca (+9 more) 19:51 -!- Netsplit over, joins: CubicEarths, lnostdal, a5m0, harrymm, kabaum, BCBot, Anduck, Randolf, Austen58Grimes, Kvaciral (+16 more) 19:51 -!- CubicEarths [~cubiceart@c-73-181-185-197.hsd1.wa.comcast.net] has quit [Max SendQ exceeded] 19:54 -!- CubicEarths [~cubiceart@c-73-181-185-197.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 20:00 < achow101> damnit the binaries don't match 20:10 < achow101> oh wait, I built the wrong binaries :/ 20:11 -!- joshb[m] [joshbmatri@gateway/shell/matrix.org/x-inxpfvsqcjycsuhm] has joined #bitcoin-core-dev 20:29 -!- ajtowns[m] [ajtownsmat@gateway/shell/matrix.org/x-ozndzjebxzcewbqi] has joined #bitcoin-core-dev 20:29 -!- kewde[m] [kewdematri@gateway/shell/matrix.org/x-nzjgqhecgujomajv] has joined #bitcoin-core-dev 20:29 -!- herzmeister[m] [herzmeiste@gateway/shell/matrix.org/x-khckyxeptpwresdl] has joined #bitcoin-core-dev 20:29 -!- squarfed[m] [squarfedma@gateway/shell/matrix.org/x-gyxbpwhvxaexmxfz] has joined #bitcoin-core-dev 20:29 -!- stepa[m] [stepamatri@gateway/shell/matrix.org/x-fjfvzsdxxguvnyxp] has joined #bitcoin-core-dev 20:43 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev 20:45 -!- bitconner [~conner@64-71-8-130.static.wiline.com] has quit [Ping timeout: 248 seconds] 21:34 -!- Randolf [~randolf@96.53.47.42] has quit [Ping timeout: 252 seconds] 21:41 -!- Krellan [~Krellan@2601:640:4000:9258:4433:dd5:9ea1:1c28] has quit [Read error: Connection reset by peer] 21:42 -!- Krellan [~Krellan@2601:640:4000:9258:4433:dd5:9ea1:1c28] has joined #bitcoin-core-dev 21:55 -!- str4d [~str4d@27.110.123.92] has joined #bitcoin-core-dev 21:57 -!- rex4539 [~textual@2a02:587:3501:ea00:8dc5:d53f:23d:59ca] has joined #bitcoin-core-dev 22:53 -!- Randolf [~randolf@24.244.23.217] has joined #bitcoin-core-dev 23:16 < jonasschnelli> sipa: one thing that stuck with me over night,.. if the Bech32 BCH can detect 4 chars and correct two (length <=89), wouldn't it be trivial to brute-force the eventually present other 2 errors? Brute-force to fit the error-free checksum. 23:21 < sipa> jonasschnelli: i don't understand 23:22 < sipa> it's a very fundamental property that you can only correct half 23:22 < sipa> of what you can detect 23:23 < jonasschnelli> sipa: Okay. But wouldn't you know that there are two other errors (since it can detect 4) and where those errors are (index)? 23:24 < jonasschnelli> I guess I get the error correction right... 23:25 < jonasschnelli> I where under the assumption that if you have a encoded key with 4 errors, it will point out those 4 errors, ... the BCH correction can fix two errors, so decode again after correction and figure out where the other two error where made.... 23:25 < jonasschnelli> (sry, no need for decode again) 23:27 < sipa> jonasschnelli: the point is that there may be multiple ways of making 4 changes to your invalid codeword to turn it into a valid one; but at most one will be the correct one 23:28 -!- bitconner [~conner@136.24.175.89] has joined #bitcoin-core-dev 23:28 < sipa> if any two code words are at least different in 5 positions (which is the case for bech32), making up to 4 changes to a valid codeword will never result in another valid.codeword, so you'll never fail to detect 23:29 < sipa> however, if 3 errors are made, it may be possible to "correct" it by modifying two other unrelated positions 23:29 < sipa> resulting in a valid, but incorrect codeword 23:30 < jonasschnelli> I'm trying to understand if there is a more "forensic" approach of reconstructing an 4 chars error BCH codeword.. if you have an address (or another validation-indicator) of you now-invalid key, brute-forcing and comparing against your validation-indicator could be possible? 23:31 < jonasschnelli> For keys, error correction could be very cpu-intense IMO 23:31 < sipa> yes, you can list decode 23:32 < sipa> if you accept there are multiple possible decodi gs 23:32 < sipa> and you can tey all of them 23:32 < sipa> what we mean with "error correcting" power is how many errors there can be up to the point where you can uniquely identify the error 23:32 < jonasschnelli> Worst case stupid-dummy correction would brute forcing all 4 error positions with 32^4 23:32 < sipa> you can alwaus go try to make more changes and see if that ends up with valid codes 23:33 < sipa> yes 23:33 < sipa> adding a few checksum characters is generally easier :) 23:33 < jonasschnelli> Yes... I guess so. :) 23:33 < sipa> but if there is a lot of money at stake, you should totally do list decoding 23:33 -!- Randolf [~randolf@24.244.23.217] has quit [Ping timeout: 240 seconds] 23:34 < jonasschnelli> This somehow makes me convinced that the Bech32 properties are not utterly bad, maybe feasible for private key encoding. 23:36 -!- jtimon [~quassel@226.110.132.37.dynamic.jazztel.es] has quit [Ping timeout: 248 seconds] 23:43 -!- lxer [~lx@ip5f5bd657.dynamic.kabel-deutschland.de] has joined #bitcoin-core-dev 23:45 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection] 23:48 -!- retrop99 [~retrop99@109.232.227.133] has joined #bitcoin-core-dev 23:53 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 23:56 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 245 seconds]