1 2018-05-28T00:00:31  *** belcher has joined #bitcoin-core-dev
  2 2018-05-28T00:03:22  *** bitconner has quit IRC
  3 2018-05-28T00:14:50  *** vicenteH has quit IRC
  4 2018-05-28T00:19:26  *** promag has quit IRC
  5 2018-05-28T00:47:53  *** Chris_Stewart_5 has joined #bitcoin-core-dev
  6 2018-05-28T00:49:54  *** promag has joined #bitcoin-core-dev
  7 2018-05-28T01:10:42  *** AaronvanW has joined #bitcoin-core-dev
  8 2018-05-28T01:11:59  *** Aaronvan_ has joined #bitcoin-core-dev
  9 2018-05-28T01:15:27  *** AaronvanW has quit IRC
 10 2018-05-28T01:19:06  *** satwo has quit IRC
 11 2018-05-28T01:21:09  *** satwo has joined #bitcoin-core-dev
 12 2018-05-28T01:22:18  <Chris_Stewart_5> is it possible to compile secp256k1 on windows with jni enabled?
 13 2018-05-28T01:23:46  *** Posix has joined #bitcoin-core-dev
 14 2018-05-28T01:33:55  *** satwo has quit IRC
 15 2018-05-28T01:35:13  *** jrayhawk has quit IRC
 16 2018-05-28T01:36:05  *** jrayhawk has joined #bitcoin-core-dev
 17 2018-05-28T01:40:20  *** Sinclair_ has quit IRC
 18 2018-05-28T01:40:48  *** Victorsueca has quit IRC
 19 2018-05-28T01:41:00  *** Posix has quit IRC
 20 2018-05-28T01:42:20  *** Victorsueca has joined #bitcoin-core-dev
 21 2018-05-28T01:44:53  *** TannerR has joined #bitcoin-core-dev
 22 2018-05-28T02:01:12  *** jtimon has quit IRC
 23 2018-05-28T02:13:55  *** bitconner has joined #bitcoin-core-dev
 24 2018-05-28T02:14:02  *** CubicEarths has quit IRC
 25 2018-05-28T02:14:40  *** CubicEarths has joined #bitcoin-core-dev
 26 2018-05-28T02:18:46  *** bitconner has quit IRC
 27 2018-05-28T02:28:35  *** goatpig has quit IRC
 28 2018-05-28T02:29:03  *** Aaronvan_ has quit IRC
 29 2018-05-28T02:39:43  *** satwo has joined #bitcoin-core-dev
 30 2018-05-28T02:53:05  *** TannerR has quit IRC
 31 2018-05-28T03:07:17  *** Krellan has quit IRC
 32 2018-05-28T03:12:44  *** bitconner has joined #bitcoin-core-dev
 33 2018-05-28T03:19:51  *** bitbee has quit IRC
 34 2018-05-28T03:19:51  *** satwo has quit IRC
 35 2018-05-28T03:20:51  *** bitbee has joined #bitcoin-core-dev
 36 2018-05-28T03:25:18  *** TannerR has joined #bitcoin-core-dev
 37 2018-05-28T03:27:30  *** TannerR has quit IRC
 38 2018-05-28T03:33:02  *** satwo has joined #bitcoin-core-dev
 39 2018-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
 40 2018-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
 41 2018-05-28T03:53:08  *** Krellan has joined #bitcoin-core-dev
 42 2018-05-28T03:55:53  *** contrapumpkin has quit IRC
 43 2018-05-28T04:00:29  *** BullShark has quit IRC
 44 2018-05-28T04:04:19  *** rex4539 has joined #bitcoin-core-dev
 45 2018-05-28T04:45:59  *** satwo has quit IRC
 46 2018-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?
 47 2018-05-28T05:32:45  *** Chris_Stewart_5 has quit IRC
 48 2018-05-28T05:54:33  *** adam3us_ has quit IRC
 49 2018-05-28T05:54:33  *** warren has quit IRC
 50 2018-05-28T06:07:35  *** Krellan has quit IRC
 51 2018-05-28T06:08:06  *** Krellan has joined #bitcoin-core-dev
 52 2018-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. :)
 53 2018-05-28T06:27:47  *** rex4539 has quit IRC
 54 2018-05-28T06:28:30  *** rex4539 has joined #bitcoin-core-dev
 55 2018-05-28T06:29:11  *** rex4539 has quit IRC
 56 2018-05-28T06:29:41  *** rex4539 has joined #bitcoin-core-dev
 57 2018-05-28T06:30:31  *** lxer has joined #bitcoin-core-dev
 58 2018-05-28T06:30:49  *** rex4539 has joined #bitcoin-core-dev
 59 2018-05-28T06:43:20  *** tryphe_ has quit IRC
 60 2018-05-28T06:43:58  *** tryphe has joined #bitcoin-core-dev
 61 2018-05-28T07:02:08  <sipa> mryandao: i believe cfields has some.ongoing work to get rid of it
 62 2018-05-28T07:02:18  <sipa> but i'm not sure of the status
 63 2018-05-28T07:06:36  *** Krellan has quit IRC
 64 2018-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
 65 2018-05-28T07:16:51  <mryandao> hence I asked.
 66 2018-05-28T07:18:41  *** promag has quit IRC
 67 2018-05-28T07:18:55  *** promag has joined #bitcoin-core-dev
 68 2018-05-28T07:18:58  *** bitconner has quit IRC
 69 2018-05-28T07:20:23  *** promag has quit IRC
 70 2018-05-28T07:21:31  <wumpus> I think we're also quite near to being able to get rid of boost::thread
 71 2018-05-28T07:23:53  *** promag has joined #bitcoin-core-dev
 72 2018-05-28T07:27:25  *** bitconner has joined #bitcoin-core-dev
 73 2018-05-28T07:28:38  *** promag has quit IRC
 74 2018-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
 75 2018-05-28T07:32:49  *** bitconner has quit IRC
 76 2018-05-28T07:33:23  <mryandao> boost::thread alone had 100MB+ of dependencies
 77 2018-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
 78 2018-05-28T07:36:00  <wumpus> that's simply not true
 79 2018-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.
 80 2018-05-28T07:37:42  <wumpus> you can check the gitian descriptor to see how by far most of the build is disabled
 81 2018-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)
 82 2018-05-28T07:39:11  <mryandao> weird, unless apt-get by default packages all of them together?
 83 2018-05-28T07:39:26  <mryandao> i did put down the `apt-get install libboost-thread-dev`
 84 2018-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
 85 2018-05-28T07:41:08  <wumpus> strange - I'd write that up to debian instead of fundamental thing with boost itself
 86 2018-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
 87 2018-05-28T07:49:39  <mryandao> wumpus: cool, thanks.
 88 2018-05-28T07:53:25  <wumpus> see also #12381
 89 2018-05-28T07:53:28  <gribble> https://github.com/bitcoin/bitcoin/issues/12381 | Remove more boost threads by theuni · Pull Request #12381 · bitcoin/bitcoin · GitHub
 90 2018-05-28T07:56:42  *** harrymm has quit IRC
 91 2018-05-28T07:58:23  *** harrymm has joined #bitcoin-core-dev
 92 2018-05-28T08:07:07  *** Krellan has joined #bitcoin-core-dev
 93 2018-05-28T08:09:26  <94KAACTBR> [bitcoin] laanwj pushed 9 new commits to 0.16: https://github.com/bitcoin/bitcoin/compare/50b2c9e0dfbe...bfd1e923335e
 94 2018-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
 95 2018-05-28T08:09:27  <94KAACTBR> bitcoin/0.16 c71e535 Suhas Daftuar: Bugfix: ensure consistency of m_failed_blocks after reconsiderblock...
 96 2018-05-28T08:09:27  <94KAACTBR> bitcoin/0.16 0948153 Matt Corallo: Do not unlock cs_main in ABC unless we've actually made progress....
 97 2018-05-28T08:09:28  <94KAACTBR> bitcoin/0.16 bb79aaf Jesse Cohen: Fix concurrency-related bugs in ActivateBestChain...
 98 2018-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
 99 2018-05-28T08:09:34  *** setpill has joined #bitcoin-core-dev
100 2018-05-28T08:13:54  *** Krellan has quit IRC
101 2018-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
102 2018-05-28T08:33:13  *** promag has joined #bitcoin-core-dev
103 2018-05-28T08:35:53  *** JackH has joined #bitcoin-core-dev
104 2018-05-28T08:42:25  *** tum has joined #bitcoin-core-dev
105 2018-05-28T08:43:43  *** timothy has joined #bitcoin-core-dev
106 2018-05-28T08:48:10  *** drizztbsd has joined #bitcoin-core-dev
107 2018-05-28T08:48:37  *** timothy has quit IRC
108 2018-05-28T08:52:05  *** drizztbsd is now known as timothy
109 2018-05-28T08:52:33  *** berndj has quit IRC
110 2018-05-28T08:54:08  *** berndj has joined #bitcoin-core-dev
111 2018-05-28T08:57:42  *** raarr has quit IRC
112 2018-05-28T09:07:22  *** bitconner has joined #bitcoin-core-dev
113 2018-05-28T09:10:21  *** berndj has quit IRC
114 2018-05-28T09:13:28  *** berndj has joined #bitcoin-core-dev
115 2018-05-28T09:20:07  *** satwo has joined #bitcoin-core-dev
116 2018-05-28T09:24:25  *** owowo has quit IRC
117 2018-05-28T09:25:28  *** owowo has joined #bitcoin-core-dev
118 2018-05-28T09:28:25  * midnightmagic will love whoever it is, forever, who removed boost entirely as a dependency for bitcoin. :)
119 2018-05-28T09:39:15  *** fanquake has joined #bitcoin-core-dev
120 2018-05-28T09:39:26  <fanquake> wumpus I think #13319 should be ready as well.
121 2018-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
122 2018-05-28T09:41:17  *** jtimon has joined #bitcoin-core-dev
123 2018-05-28T09:49:17  *** arowser has quit IRC
124 2018-05-28T09:49:35  *** arowser has joined #bitcoin-core-dev
125 2018-05-28T09:51:47  *** Victorsueca has quit IRC
126 2018-05-28T09:52:25  *** cdecker has joined #bitcoin-core-dev
127 2018-05-28T09:52:47  *** arowser_ has joined #bitcoin-core-dev
128 2018-05-28T09:52:59  *** Victorsueca has joined #bitcoin-core-dev
129 2018-05-28T09:53:39  *** wallet42_ has joined #bitcoin-core-dev
130 2018-05-28T09:55:50  *** berndj has quit IRC
131 2018-05-28T09:56:22  *** RoBz_ has joined #bitcoin-core-dev
132 2018-05-28T09:57:16  *** kinlo_ has joined #bitcoin-core-dev
133 2018-05-28T09:57:34  *** berndj has joined #bitcoin-core-dev
134 2018-05-28T10:01:16  *** arowser has quit IRC
135 2018-05-28T10:01:16  *** jtimon has quit IRC
136 2018-05-28T10:01:16  *** herzmeister[m] has quit IRC
137 2018-05-28T10:01:16  *** RoBz has quit IRC
138 2018-05-28T10:01:16  *** wallet42 has quit IRC
139 2018-05-28T10:01:17  *** baldur has quit IRC
140 2018-05-28T10:01:18  *** nsh has quit IRC
141 2018-05-28T10:01:18  *** kinlo has quit IRC
142 2018-05-28T10:01:21  *** wallet42_ is now known as wallet42
143 2018-05-28T10:01:22  *** kinlo_ is now known as kinlo
144 2018-05-28T10:03:27  *** Dyaheon has quit IRC
145 2018-05-28T10:06:32  *** Dyaheon has joined #bitcoin-core-dev
146 2018-05-28T10:08:00  <bitcoin-git> [bitcoin] laanwj pushed 4 new commits to 0.16: https://github.com/bitcoin/bitcoin/compare/bfd1e923335e...07fb2a6e166f
147 2018-05-28T10:08:01  <bitcoin-git> bitcoin/0.16 ea487f9 Luke Dashjr: GUI: Rephrase Bech32 checkbox text/tooltip...
148 2018-05-28T10:08:02  <bitcoin-git> bitcoin/0.16 0eda98d Luke Dashjr: GUI: Allow generating Bech32 addresses with a legacy-address default...
149 2018-05-28T10:08:02  <bitcoin-git> bitcoin/0.16 dcb13a0 MarcoFalke: qt: Update translations pre-rc1
150 2018-05-28T10:08:22  *** baldur has joined #bitcoin-core-dev
151 2018-05-28T10:09:38  <wumpus> fanquake: does that mean we can roll 0.16.0rc1 today?
152 2018-05-28T10:09:46  <wumpus> 0.16.1rc1
153 2018-05-28T10:09:56  *** herzmeister[m] has joined #bitcoin-core-dev
154 2018-05-28T10:10:02  *** nsh- has joined #bitcoin-core-dev
155 2018-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
156 2018-05-28T10:14:27  <gribble> https://github.com/bitcoin/bitcoin/issues/12337 | 0.16 Shutdown assertion · Issue #12337 · bitcoin/bitcoin · GitHub
157 2018-05-28T10:15:09  <wumpus> was just looking at that - I don't think it has to block anything
158 2018-05-28T10:15:54  <fanquake> Yep, I think an rc1 can move ahead. Can always be fixed if it comes up again during testing
159 2018-05-28T10:17:06  <fanquake> Have updated all the projects and un-tagged backports etc.
160 2018-05-28T10:17:45  *** satwo has quit IRC
161 2018-05-28T10:17:46  *** m8tion has joined #bitcoin-core-dev
162 2018-05-28T10:23:49  *** belcher has quit IRC
163 2018-05-28T10:27:46  *** Austen58Grimes has joined #bitcoin-core-dev
164 2018-05-28T10:36:47  <wumpus> thanks!
165 2018-05-28T11:00:27  *** jtimon has joined #bitcoin-core-dev
166 2018-05-28T11:06:17  <provoostenator> I'd like to get #11658 in if that's still possible.
167 2018-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
168 2018-05-28T11:06:53  <luke-jr> not sure it's a bugfix
169 2018-05-28T11:07:04  *** zautomata has quit IRC
170 2018-05-28T11:07:27  *** AaronvanW has joined #bitcoin-core-dev
171 2018-05-28T11:07:37  <provoostenator> Oh is 0.16.1 purely backports and not masteR?
172 2018-05-28T11:07:50  <provoostenator> In that case it can wait for 0.17
173 2018-05-28T11:08:17  <fanquake> provoostenator correct, https://github.com/bitcoin/bitcoin/tree/0.16
174 2018-05-28T11:08:27  <luke-jr> the 3rd number of a version is always for bugfixes (and in our case, consensus protocol updates)
175 2018-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
176 2018-05-28T11:13:52  <fanquake> wumpus will you tag an rc tonight?
177 2018-05-28T11:15:11  *** BullShark has joined #bitcoin-core-dev
178 2018-05-28T11:27:04  *** harrymm has quit IRC
179 2018-05-28T11:32:41  *** arowser_ has quit IRC
180 2018-05-28T11:32:58  *** arowser_ has joined #bitcoin-core-dev
181 2018-05-28T11:34:56  <wumpus> fanquake: I'm working on doing last-minute checks now
182 2018-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.
183 2018-05-28T11:35:49  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to 0.16: https://github.com/bitcoin/bitcoin/compare/07fb2a6e166f...81bc9829cdaf
184 2018-05-28T11:35:50  <bitcoin-git> bitcoin/0.16 b42c355 Wladimir J. van der Laan: qt: Pre-rc1 transifex pull...
185 2018-05-28T11:35:50  <bitcoin-git> bitcoin/0.16 81bc982 Wladimir J. van der Laan: build: Bump version to 0.16.1...
186 2018-05-28T11:38:37  *** Sinclair_ has joined #bitcoin-core-dev
187 2018-05-28T11:39:02  <wumpus> fanquake: just trying to build on a few platforms would help
188 2018-05-28T11:39:53  *** harrymm has joined #bitcoin-core-dev
189 2018-05-28T11:40:28  <fanquake> wumpus: I'll start building 81bc982
190 2018-05-28T11:43:13  *** Sinclair_ has quit IRC
191 2018-05-28T11:43:59  *** fanquake has quit IRC
192 2018-05-28T11:44:05  *** promag has quit IRC
193 2018-05-28T11:44:58  *** fanquake has joined #bitcoin-core-dev
194 2018-05-28T11:49:08  *** berndj has quit IRC
195 2018-05-28T11:52:01  <wumpus> are you going to try OpenBSD?
196 2018-05-28T11:52:37  <fanquake> wumpus I can do, it'll probably be 6.2 though
197 2018-05-28T11:52:48  <fanquake> Haven't setup a 6.3 VM yet
198 2018-05-28T11:53:32  <wumpus> I asked because I have the same problem, I should just be non-lazy and upgrade my VM
199 2018-05-28T11:53:51  *** berndj has joined #bitcoin-core-dev
200 2018-05-28T11:54:10  <wumpus> at least freebsd is still 11.1, I'll do that one
201 2018-05-28T11:59:13  <fanquake> wumpus How about your Windows Vista VM :p
202 2018-05-28T12:03:10  <wumpus> you mean the windows XP one? :-)
203 2018-05-28T12:03:33  *** SopaXorzTaker has joined #bitcoin-core-dev
204 2018-05-28T12:04:50  <fanquake> wumpus You are welcome to test, but we ditched XP with 0.16 :0
205 2018-05-28T12:05:49  *** mistergold has joined #bitcoin-core-dev
206 2018-05-28T12:06:29  <luke-jr> sigh, btrfs really does suck
207 2018-05-28T12:06:57  <fanquake> I think we could backport #13246 for 0.16, worthwhile improvements to the Windows build process.
208 2018-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
209 2018-05-28T12:07:03  <wumpus> I don't have any other windows VMs though, nor are there any windows computers left here
210 2018-05-28T12:07:25  <fanquake> Not necessarily a bad thing
211 2018-05-28T12:08:15  <wumpus> luke-jr: what terrible wrong did it do to you today?
212 2018-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)
213 2018-05-28T12:08:49  <luke-jr> in the meantime, the whole PC has slowed to a crawl
214 2018-05-28T12:09:32  <fanquake> sounds kinda like my laptop whenever there's > 2 VM running
215 2018-05-28T12:12:41  <luke-jr> (as well as random unexplained WARNING stack dumps in dmesg)
216 2018-05-28T12:24:04  *** qu4ku has joined #bitcoin-core-dev
217 2018-05-28T12:28:47  <sipa> provoostenator: 0.16.1 will be created by tagging the 0.16 branch, not master
218 2018-05-28T12:29:16  <sipa> 0.16 branched off from master a bit before 0.16.0
219 2018-05-28T12:29:59  <sipa> and indeed since the feature freeze (shortly before the branch) there are only bugfixes in it
220 2018-05-28T12:30:12  <sipa> which are backports of changes in master
221 2018-05-28T12:30:42  <luke-jr> looks like about 10 minutes to process each block -.-
222 2018-05-28T12:32:16  <booyah> luke-jr: after all this years? :/
223 2018-05-28T12:33:16  <luke-jr> never going to catch up at this rate
224 2018-05-28T12:33:53  *** retrop99 has joined #bitcoin-core-dev
225 2018-05-28T12:37:50  <wumpus> that's slower than my slowest ARM board FWIW
226 2018-05-28T12:38:42  <wumpus> (including lame things such as slow SD cards, slow ethernet, and external USB2 harddrives)
227 2018-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
228 2018-05-28T12:39:56  <wumpus> fanquake: thanks!
229 2018-05-28T12:41:40  <fanquake> I'm doing my testing with 18.04, and getting rid of those work around is a +
230 2018-05-28T12:42:00  <wumpus> definitely
231 2018-05-28T12:42:10  <wumpus> good to think of that
232 2018-05-28T12:43:17  *** drexl has joined #bitcoin-core-dev
233 2018-05-28T12:58:08  *** promag has joined #bitcoin-core-dev
234 2018-05-28T12:58:46  *** berndj has quit IRC
235 2018-05-28T13:00:10  *** berndj has joined #bitcoin-core-dev
236 2018-05-28T13:01:47  <luke-jr> moved chainstate to SSD, more like 10 seconds per block now (still btrfs'd)
237 2018-05-28T13:03:53  *** arowser_ has quit IRC
238 2018-05-28T13:04:11  *** arowser_ has joined #bitcoin-core-dev
239 2018-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
240 2018-05-28T13:06:47  *** retrop99 has quit IRC
241 2018-05-28T13:11:10  *** luke-jr has quit IRC
242 2018-05-28T13:14:28  *** berndj has quit IRC
243 2018-05-28T13:15:38  *** berndj has joined #bitcoin-core-dev
244 2018-05-28T13:17:59  *** luke-jr has joined #bitcoin-core-dev
245 2018-05-28T13:20:52  *** SopaXorzTaker has quit IRC
246 2018-05-28T13:22:43  *** SopaXorzTaker has joined #bitcoin-core-dev
247 2018-05-28T13:23:20  <wumpus> FreeBSD 11.1 and OpenBSD 6.2 builds OK
248 2018-05-28T13:23:23  *** Chris_Stewart_5 has joined #bitcoin-core-dev
249 2018-05-28T13:24:33  <fanquake> macOS 10.13.5 builds OK. Currently building depends on Windows 10
250 2018-05-28T13:28:51  <luke-jr> hm, there must be something wrong. ps claims bitcoin-qt's SIZE is 37 GB :|
251 2018-05-28T13:28:57  *** qu4ku has quit IRC
252 2018-05-28T13:32:03  <wumpus> (also Ubuntu 16.04 and 18.04, but that's not really surprising)
253 2018-05-28T13:32:10  <wumpus> luke-jr: ouch, can you bisect that?
254 2018-05-28T13:32:18  *** berndj has quit IRC
255 2018-05-28T13:33:20  <luke-jr> wumpus: it's during startup, so.. I'm not sure it's a bug on our end
256 2018-05-28T13:33:22  *** berndj has joined #bitcoin-core-dev
257 2018-05-28T13:33:45  <luke-jr> my first guess is -fsanitize stuff, so trying again without those
258 2018-05-28T13:36:42  *** AaronvanW has quit IRC
259 2018-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?
260 2018-05-28T13:37:20  *** AaronvanW has joined #bitcoin-core-dev
261 2018-05-28T13:37:31  <luke-jr> think*
262 2018-05-28T13:37:59  <luke-jr> (and yes, disabling sanitizers seems to have fixed the insane SIZE)
263 2018-05-28T13:38:46  <wumpus> ok, good to know, no worry for 0.16.1 then
264 2018-05-28T13:38:56  *** berndj has quit IRC
265 2018-05-28T13:41:02  *** berndj has joined #bitcoin-core-dev
266 2018-05-28T13:41:21  *** AaronvanW has quit IRC
267 2018-05-28T13:44:05  *** arowser_ has quit IRC
268 2018-05-28T13:44:23  *** arowser_ has joined #bitcoin-core-dev
269 2018-05-28T13:48:35  *** contrapumpkin has joined #bitcoin-core-dev
270 2018-05-28T13:49:47  <wumpus> so if anyone else wants to try building the 0.16 branch on various platforms, please do
271 2018-05-28T13:50:19  <wumpus> if not, I'm going to tag rc1 after fanquake's windows build succeeds
272 2018-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.
273 2018-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
274 2018-05-28T13:59:16  *** arowser_ has quit IRC
275 2018-05-28T13:59:34  *** arowser_ has joined #bitcoin-core-dev
276 2018-05-28T14:00:04  *** belcher has joined #bitcoin-core-dev
277 2018-05-28T14:02:12  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/610f4dd719ad...f5a7733ff767
278 2018-05-28T14:02:12  <bitcoin-git> bitcoin/master 9e305b5 Cory Fields: build: split warnings out of CXXFLAGS...
279 2018-05-28T14:02:13  <bitcoin-git> bitcoin/master f5a7733 Wladimir J. van der Laan: Merge #13306: build: split warnings out of CXXFLAGS...
280 2018-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
281 2018-05-28T14:03:09  *** AaronvanW has joined #bitcoin-core-dev
282 2018-05-28T14:03:52  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f5a7733ff767...fb7731089ed2
283 2018-05-28T14:03:52  <bitcoin-git> bitcoin/master 1680b8b practicalswift: docs: Update OpenBSD build instructions for OpenBSD 6.3
284 2018-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...
285 2018-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
286 2018-05-28T14:08:49  <fanquake> wumpus The depends build, compile and make install completed successfully, using the 18.04 instructions.
287 2018-05-28T14:08:58  <fanquake> However the binaries wont launch..
288 2018-05-28T14:09:17  <fanquake> Trying another build, otherwise I'll have to try debugging tomorrow.
289 2018-05-28T14:09:50  <wumpus> not even bitcoin-cli?
290 2018-05-28T14:11:01  *** nsh- is now known as nsh
291 2018-05-28T14:12:58  *** BullShark has left #bitcoin-core-dev
292 2018-05-28T14:13:15  <fanquake> Got some error output, 1 sec
293 2018-05-28T14:14:48  <fanquake> heh, I'm seeing #12337 :(
294 2018-05-28T14:14:50  <gribble> https://github.com/bitcoin/bitcoin/issues/12337 | 0.16 Shutdown assertion · Issue #12337 · bitcoin/bitcoin · GitHub
295 2018-05-28T14:15:20  <fanquake> https://0bin.net/paste/1iOaeL+DunFWqy0n#gwr6oLIgrjlG45QDIdN4u2yqvUTIHGR3goxtENCMzwJ
296 2018-05-28T14:20:48  <fanquake> wumpus ^ I need to sleep. Can continue investigating tomorrow. Up to you about an RC1 tag.
297 2018-05-28T14:23:00  *** fanquake has quit IRC
298 2018-05-28T14:23:20  <wumpus> thanks, sleep well
299 2018-05-28T14:24:48  *** berndj has quit IRC
300 2018-05-28T14:26:29  *** arowser_ has quit IRC
301 2018-05-28T14:26:47  *** arowser_ has joined #bitcoin-core-dev
302 2018-05-28T14:27:12  *** berndj has joined #bitcoin-core-dev
303 2018-05-28T14:29:14  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/fb7731089ed2...14a4b4966361
304 2018-05-28T14:29:14  <bitcoin-git> bitcoin/master fa9da85 MarcoFalke: qa: Initialize lockstack to prevent null pointer deref
305 2018-05-28T14:29:15  <bitcoin-git> bitcoin/master 14a4b49 Wladimir J. van der Laan: Merge #13300: qa: Initialize lockstack to prevent null pointer deref...
306 2018-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
307 2018-05-28T14:31:36  *** Aaronvan_ has joined #bitcoin-core-dev
308 2018-05-28T14:31:55  *** Aaronvan_ has quit IRC
309 2018-05-28T14:32:33  *** Aaronvan_ has joined #bitcoin-core-dev
310 2018-05-28T14:33:29  *** AaronvanW has quit IRC
311 2018-05-28T14:35:42  *** arowser_ has quit IRC
312 2018-05-28T14:36:00  *** arowser_ has joined #bitcoin-core-dev
313 2018-05-28T14:37:20  *** Aaronvan_ has quit IRC
314 2018-05-28T14:38:55  *** arowser_ has quit IRC
315 2018-05-28T14:39:13  *** arowser_ has joined #bitcoin-core-dev
316 2018-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
317 2018-05-28T14:40:33  <gribble> https://github.com/bitcoin/bitcoin/issues/12337 | 0.16 Shutdown assertion · Issue #12337 · bitcoin/bitcoin · GitHub
318 2018-05-28T14:40:35  *** AaronvanW has joined #bitcoin-core-dev
319 2018-05-28T14:52:53  *** contrapumpkin has quit IRC
320 2018-05-28T14:54:07  <wumpus> but I'll wait for some other opinions...
321 2018-05-28T15:04:35  *** marcoagner has quit IRC
322 2018-05-28T15:10:09  *** arowser_ has quit IRC
323 2018-05-28T15:10:26  *** arowser_ has joined #bitcoin-core-dev
324 2018-05-28T15:10:50  <ken2812221> Should we backport #13131?
325 2018-05-28T15:10:52  <gribble> https://github.com/bitcoin/bitcoin/issues/13131 | Add Windows shutdown handler by ken2812221 · Pull Request #13131 · bitcoin/bitcoin · GitHub
326 2018-05-28T15:11:03  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/14a4b4966361...a315b79ad2b8
327 2018-05-28T15:11:04  <bitcoin-git> bitcoin/master 2885c13 Jonas Schnelli: Qt: use [default wallet] as name for wallet with no name
328 2018-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...
329 2018-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
330 2018-05-28T15:12:32  <wumpus> i'm ok with that, for 0.16.2 though
331 2018-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
332 2018-05-28T15:14:32  *** berndj has quit IRC
333 2018-05-28T15:15:24  *** promag has quit IRC
334 2018-05-28T15:17:17  *** marcoagner has joined #bitcoin-core-dev
335 2018-05-28T15:17:45  <ken2812221> ok
336 2018-05-28T15:18:06  *** berndj has joined #bitcoin-core-dev
337 2018-05-28T15:24:32  *** contrapumpkin has joined #bitcoin-core-dev
338 2018-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?
339 2018-05-28T15:24:48  <jonasschnelli> https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#bech32
340 2018-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
341 2018-05-28T15:28:52  <wumpus> I think the properties would no longer hold with the same checksum length
342 2018-05-28T15:29:00  <wumpus> and longer data length
343 2018-05-28T15:29:05  <jonasschnelli> Chris_Stewart_5: I guess it refers to the max length for a native P2SH address
344 2018-05-28T15:29:18  <jonasschnelli> wumpus: ah. that is a point
345 2018-05-28T15:30:28  *** TannerR has joined #bitcoin-core-dev
346 2018-05-28T15:31:03  <jonasschnelli> wumpus: https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#checksum-design, yes. your right
347 2018-05-28T15:31:42  <jonasschnelli> length 89 is the max for ≤4 wrong chars tolerance
348 2018-05-28T15:39:11  <sipa> jonasschnelli: bip173 addresses are at most 74 characters
349 2018-05-28T15:39:50  <sipa> bech32 encoding supports up to 90 characters (including prefix and separator)
350 2018-05-28T15:40:28  <sipa> in some places a version of bech32 is used that violates that limit (e.g. lightning payments)
351 2018-05-28T15:48:19  *** arowser_ has quit IRC
352 2018-05-28T15:48:37  *** arowser_ has joined #bitcoin-core-dev
353 2018-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?
354 2018-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
355 2018-05-28T15:51:20  <jonasschnelli> I *thought
356 2018-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
357 2018-05-28T15:54:30  <jonasschnelli> thanks aj
358 2018-05-28T15:56:50  <sipa> jonasschnelli: for pivate keys you want something else
359 2018-05-28T15:57:01  <sipa> addresses only need error detection
360 2018-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
361 2018-05-28T15:58:10  <sipa> while failed private keys have no such option
362 2018-05-28T15:59:32  *** arowser_ has quit IRC
363 2018-05-28T16:00:01  *** arowser_ has joined #bitcoin-core-dev
364 2018-05-28T16:02:03  *** Krellan has joined #bitcoin-core-dev
365 2018-05-28T16:03:56  *** arowser_ has quit IRC
366 2018-05-28T16:04:12  *** arowser_ has joined #bitcoin-core-dev
367 2018-05-28T16:13:06  *** arowser_ has quit IRC
368 2018-05-28T16:13:26  *** arowser_ has joined #bitcoin-core-dev
369 2018-05-28T16:17:56  *** promag has joined #bitcoin-core-dev
370 2018-05-28T16:19:21  *** arowser_ has quit IRC
371 2018-05-28T16:19:40  *** arowser_ has joined #bitcoin-core-dev
372 2018-05-28T16:32:50  *** promag has quit IRC
373 2018-05-28T16:34:11  *** m8tion has quit IRC
374 2018-05-28T16:54:37  <wumpus> any opinions on tagging rc1 or not?
375 2018-05-28T16:56:15  <sipa> any things missing (according to some)?
376 2018-05-28T16:57:33  <wumpus> well #12337
377 2018-05-28T16:57:34  <gribble> https://github.com/bitcoin/bitcoin/issues/12337 | 0.16 Shutdown assertion · Issue #12337 · bitcoin/bitcoin · GitHub
378 2018-05-28T16:59:28  <sipa> otherwise harmless assert failure at shutdown?
379 2018-05-28T17:00:43  <wumpus> yes
380 2018-05-28T17:02:57  <sipa> can we remove the assert...?
381 2018-05-28T17:03:06  * sipa hides
382 2018-05-28T17:06:18  <wumpus> that's not a bad idea
383 2018-05-28T17:08:36  <wumpus> it doesn't seem to be a problem on master, just 0.16
384 2018-05-28T17:08:45  <sipa> hmm
385 2018-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
386 2018-05-28T17:11:15  <wumpus> anyhow, maybe it doesn't matter too much for rc11
387 2018-05-28T17:11:17  <wumpus> rc1*
388 2018-05-28T17:12:01  <wumpus> depends on how quickly we want to start testing this
389 2018-05-28T17:13:11  *** timothy has quit IRC
390 2018-05-28T17:14:31  *** Giszmo has joined #bitcoin-core-dev
391 2018-05-28T17:17:33  *** arowser_ has quit IRC
392 2018-05-28T17:17:52  *** arowser_ has joined #bitcoin-core-dev
393 2018-05-28T17:18:01  *** d9b4bef9 has quit IRC
394 2018-05-28T17:19:11  *** d9b4bef9 has joined #bitcoin-core-dev
395 2018-05-28T17:20:47  *** arowser_ has quit IRC
396 2018-05-28T17:21:05  *** arowser_ has joined #bitcoin-core-dev
397 2018-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
398 2018-05-28T17:24:05  <sipa> ah, you mean fix the assert in rc2/final?
399 2018-05-28T17:25:00  <wumpus> yes
400 2018-05-28T17:25:12  <sipa> sgtm
401 2018-05-28T17:25:31  <wumpus> it makes the process somewhat more parallel instead of serial
402 2018-05-28T17:26:24  *** berndj has quit IRC
403 2018-05-28T17:28:12  *** berndj has joined #bitcoin-core-dev
404 2018-05-28T17:38:01  *** arowser_ has quit IRC
405 2018-05-28T17:38:18  *** arowser_ has joined #bitcoin-core-dev
406 2018-05-28T17:39:28  *** pergaminho has joined #bitcoin-core-dev
407 2018-05-28T17:39:51  <pergaminho> Olá alguém de São Paulo?
408 2018-05-28T17:40:04  <sipa> english please
409 2018-05-28T17:41:57  <pergaminho> Excuse me, I want to know if there's anyone in Sao Paulo.
410 2018-05-28T17:44:12  *** arowser_ has quit IRC
411 2018-05-28T17:44:24  <wumpus> that seems very off topic
412 2018-05-28T17:44:29  *** arowser_ has joined #bitcoin-core-dev
413 2018-05-28T17:51:00  *** nmnkgl has joined #bitcoin-core-dev
414 2018-05-28T17:51:38  *** justanotheruser has quit IRC
415 2018-05-28T17:51:44  *** bapu has joined #bitcoin-core-dev
416 2018-05-28T17:55:20  *** laurentmt has joined #bitcoin-core-dev
417 2018-05-28T18:19:30  *** TannerR has quit IRC
418 2018-05-28T18:21:23  *** arowser_ has quit IRC
419 2018-05-28T18:21:41  *** arowser_ has joined #bitcoin-core-dev
420 2018-05-28T18:23:54  <wumpus>  * [new tag]                                                                           v0.16.1rc1 -> v0.16.1rc1
421 2018-05-28T18:24:32  <sipa> w00t
422 2018-05-28T18:25:36  *** arowser_ has quit IRC
423 2018-05-28T18:25:54  *** arowser_ has joined #bitcoin-core-dev
424 2018-05-28T18:27:48  *** arowser_ has quit IRC
425 2018-05-28T18:28:06  *** arowser_ has joined #bitcoin-core-dev
426 2018-05-28T18:30:17  *** arowser_ has joined #bitcoin-core-dev
427 2018-05-28T18:31:36  *** Guyver2 has joined #bitcoin-core-dev
428 2018-05-28T18:32:36  <achow101> yay
429 2018-05-28T18:38:12  *** Chris_Stewart_5 has quit IRC
430 2018-05-28T18:38:42  *** laurentmt has quit IRC
431 2018-05-28T18:44:31  *** Giszmo has quit IRC
432 2018-05-28T18:45:46  <jonasschnelli> sipa: have you explored the field of BCH codes suitable for private keys?
433 2018-05-28T18:48:21  <sipa> jonasschnelli: yes, a bit
434 2018-05-28T18:48:33  <sipa> but the tradeoffs are hard
435 2018-05-28T18:49:02  <sipa> strictly for private keys, you could correct 4 errors with 12 characters of checksum
436 2018-05-28T18:49:40  <sipa> but not with an efficient algorithm
437 2018-05-28T18:49:57  <jonasschnelli> with private keys you mean 256bits, right?
438 2018-05-28T18:50:01  <sipa> yes
439 2018-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
440 2018-05-28T18:52:08  <jonasschnelli> sipa: how are Bech32 properties for 512 bits? How much chars would be guaranteed in the correction?
441 2018-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
442 2018-05-28T18:53:02  <jonasschnelli> I'd say that is accaptable...
443 2018-05-28T18:53:27  <jonasschnelli> I would also say 4 error may be acceptable for 103 chars
444 2018-05-28T18:53:43  <jonasschnelli> Ideally it would be flexible ("choose your size / robustness")
445 2018-05-28T18:53:58  <sipa> such a code would guarantee correction of 4 up to length 1023
446 2018-05-28T18:54:13  <sipa> (of which 15 are checksum characters, and 1008 are data)
447 2018-05-28T18:54:57  *** Giszmo has joined #bitcoin-core-dev
448 2018-05-28T18:55:41  <jonasschnelli> sipa: hmm... and there is no optimised code for something up to 103 chars (512bit in base32).
449 2018-05-28T18:55:43  <jonasschnelli> ?
450 2018-05-28T18:56:15  <sipa> jonasschnelli: so there is an important distinction here
451 2018-05-28T18:56:45  <sipa> a BCH code is a just a subset of cyclic codes, with parameters generated in a specific way
452 2018-05-28T18:56:56  <jonasschnelli> the 4 in 1023?
453 2018-05-28T18:57:10  <sipa> that specific way guarantees (1) a certain level of error correction and (2) an efficient algorithm to do so
454 2018-05-28T18:57:39  <sipa> all these codes are however "better" than what they're designed for
455 2018-05-28T18:57:40  <jonasschnelli> so the BCH subset may not be ideal for private keys
456 2018-05-28T18:57:50  <sipa> it absolutely is not
457 2018-05-28T18:57:54  <sipa> BCH codes are not optimal
458 2018-05-28T18:57:57  <sipa> but they're easy
459 2018-05-28T18:58:06  <sipa> (and they may be close to optimal)
460 2018-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
461 2018-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
462 2018-05-28T18:59:04  <sipa> that took a few years of CPU time to find out, though :)
463 2018-05-28T18:59:13  <jonasschnelli> Yes. I heard that. :)
464 2018-05-28T18:59:23  <sipa> the BCH part is just math; i can tell you in an instant how good a code is
465 2018-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
466 2018-05-28T19:00:02  <jonasschnelli> I see...
467 2018-05-28T19:00:15  <sipa> there do exist BCH codes for length 93, FWIW :)
468 2018-05-28T19:00:38  <sipa> with just 13 checksum characters, even
469 2018-05-28T19:00:52  <sipa> but the next one up is for length 1023
470 2018-05-28T19:01:25  <jonasschnelli> Unsure if 4 chars are enough for a private key...
471 2018-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...
472 2018-05-28T19:01:58  *** str4d has joined #bitcoin-core-dev
473 2018-05-28T19:02:43  <sipa> 19 checksum characters if you want an efficient way to correct 5
474 2018-05-28T19:03:00  <jonasschnelli> new proposals may lead to not getting implemented because of a complex implementation,... bech32 would make it pretty simple
475 2018-05-28T19:03:13  <sipa> the checksum algorithm for all of these is trivial
476 2018-05-28T19:03:20  <sipa> just as simple as bech32, but with larger integers
477 2018-05-28T19:03:36  <sipa> the error correction algorithm is more complex (but very fast)
478 2018-05-28T19:03:57  *** justanotheruser has joined #bitcoin-core-dev
479 2018-05-28T19:04:38  <jonasschnelli> the 19/5 code is in the BCH subset (up to 1023)?
480 2018-05-28T19:04:49  <sipa> yup
481 2018-05-28T19:05:07  <jonasschnelli> Something you drilled out of your supermachine?
482 2018-05-28T19:05:16  <jonasschnelli> (calculated on your own?)
483 2018-05-28T19:05:27  <sipa> no, this is just BCH
484 2018-05-28T19:05:33  <sipa> it's a simple sage script to compute these
485 2018-05-28T19:05:44  <sipa> they're not optimized for anything beyong their design strength
486 2018-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
487 2018-05-28T19:07:16  <jonasschnelli> So it could be possible to find a 19/6 within a length property of l<103?
488 2018-05-28T19:07:23  <jonasschnelli> <=
489 2018-05-28T19:07:52  <sipa> that seems unlikely, but it's possible yes
490 2018-05-28T19:08:03  <sipa> it may also take more computing power than we have
491 2018-05-28T19:08:18  <jonasschnelli> I see
492 2018-05-28T19:08:45  <sipa> however, if it's just for single private keys, we could use length 93 codes
493 2018-05-28T19:09:22  <sipa> where just 13 characters for 4 corrections, or 16 characters for 5, is sufficient
494 2018-05-28T19:10:01  *** arowser_ has quit IRC
495 2018-05-28T19:10:18  <jonasschnelli> That would not cover encoding an extended private key though....
496 2018-05-28T19:10:22  <sipa> yup
497 2018-05-28T19:10:40  <sipa> also, codes _designed_ for length 93 will perform terrible beyond it
498 2018-05-28T19:10:46  <jonasschnelli> Metadata could be ouside of the cyclic code,.. but within the checksum (is that even possible?)?
499 2018-05-28T19:10:53  <sipa> no
500 2018-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
501 2018-05-28T19:11:15  <jonasschnelli> So an additional checksum
502 2018-05-28T19:11:24  <sipa> that's a bit ridiculous
503 2018-05-28T19:11:45  *** arowser_ has joined #bitcoin-core-dev
504 2018-05-28T19:11:52  <jonasschnelli> we only would need to detect errors in the metadata pert... even a parity bit would be okayish?
505 2018-05-28T19:12:01  <jonasschnelli> *part
506 2018-05-28T19:12:05  <sipa> but metadata includes chaincode etcx
507 2018-05-28T19:12:18  <jonasschnelli> chaincode is essential IMO
508 2018-05-28T19:12:23  <jonasschnelli> must be within the error correcting part
509 2018-05-28T19:12:23  *** pergaminho has quit IRC
510 2018-05-28T19:12:30  <sipa> yeah, exactly- i agree
511 2018-05-28T19:12:37  <sipa> so a length 93 code is out of the question
512 2018-05-28T19:13:00  <jonasschnelli> 512bits seems to be the minimum if it should cover xprivs
513 2018-05-28T19:13:10  <jonasschnelli> (other xpriv then m)
514 2018-05-28T19:13:22  <jonasschnelli> If we would only cover m, one could think of encoding the seed
515 2018-05-28T19:13:42  <jonasschnelli> of the seed & keypath?
516 2018-05-28T19:13:58  <jonasschnelli> but meh for hardened protection
517 2018-05-28T19:14:25  <jonasschnelli> wait, nm my last line
518 2018-05-28T19:15:38  <sipa> 11 char checksum for correcting 3, 15 for correcting 4, 19 for correcting 5
519 2018-05-28T19:16:22  *** nmnkgl has quit IRC
520 2018-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?
521 2018-05-28T19:18:34  <jonasschnelli> Also, reusing bech32 would be very desirable...
522 2018-05-28T19:18:40  <sipa> yes, but you can't have both
523 2018-05-28T19:18:43  <jonasschnelli> Right now, we have 0 correction with Base58c
524 2018-05-28T19:18:50  <sipa> bech32 can only correct 2, and inefficiently
525 2018-05-28T19:19:09  *** SopaXorzTaker has quit IRC
526 2018-05-28T19:19:11  <sipa> you design for a single combination of length and correction strength
527 2018-05-28T19:19:26  <sipa> it will likely be better for shorter lengths, but not have an efficient algorithm to do so
528 2018-05-28T19:20:18  <jonasschnelli> Hmm... i though bech32 corrects 4 errors up to length 89?
529 2018-05-28T19:20:19  <jonasschnelli> *thought
530 2018-05-28T19:20:35  <sipa> no, it *detects* 4
531 2018-05-28T19:20:45  <jonasschnelli> ah. I see
532 2018-05-28T19:20:48  <sipa> correction strength is always only half of the detection strength
533 2018-05-28T19:20:55  <jonasschnelli> meh
534 2018-05-28T19:21:05  <jonasschnelli> that is what we need for private keys. :/
535 2018-05-28T19:21:38  <jonasschnelli> Yes. I guess then we need another encoding implementation... ideally as simple as bech32
536 2018-05-28T19:22:45  *** nmnkgl has joined #bitcoin-core-dev
537 2018-05-28T19:24:30  <sipa> what do you think about a 103-character checksum code that can correct 28 errors? :)
538 2018-05-28T19:24:47  <sipa> (doubling the length of the string)
539 2018-05-28T19:25:40  <gmaxwell> I'm fond of that, but whats the efficiency of the correction code for that?
540 2018-05-28T19:25:42  <jonasschnelli> sipa: I think very acceptable.. really
541 2018-05-28T19:25:55  <sipa> 206 characters is a lot :)
542 2018-05-28T19:26:05  <sipa> gmaxwell: efficiency in terms of what?
543 2018-05-28T19:26:06  <jonasschnelli> I think the correct code efficiency is not very important for private keys
544 2018-05-28T19:26:19  <jonasschnelli> *correction
545 2018-05-28T19:26:21  <gmaxwell> is it a design distance 56 code? with an efficienct locator algorithim?
546 2018-05-28T19:26:34  <gmaxwell> jonasschnelli: it matters if its intractably slow.
547 2018-05-28T19:26:46  <sipa> gmaxwell: distance 58 actually, design length 341
548 2018-05-28T19:27:04  <sipa> so it could have up to 238 data characters
549 2018-05-28T19:27:34  *** Kvaciral has joined #bitcoin-core-dev
550 2018-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. :)
551 2018-05-28T19:27:55  <sipa> gmaxwell: why would correct be slow?
552 2018-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.
553 2018-05-28T19:29:01  <sipa> factoring the locator polynomial should be fast; the field size is just 32^2
554 2018-05-28T19:29:23  <sipa> ah, i see
555 2018-05-28T19:29:31  <sipa> all i'm talking about here are algebraic properties
556 2018-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.
557 2018-05-28T19:30:15  <sipa> indeed :)
558 2018-05-28T19:30:19  <gmaxwell> since the search process and the decode process are essential the same.
559 2018-05-28T19:32:30  <gmaxwell> sipa: your suggested code also has enough length to have some metadata, a nonce for encryption, etc.
560 2018-05-28T19:33:07  <sipa> yup
561 2018-05-28T19:33:10  *** AaronvanW has quit IRC
562 2018-05-28T19:33:17  <sipa> but 2x length is... a lot
563 2018-05-28T19:33:50  <jonasschnelli> To keep the write-down-by-hand property, I guess something beyond bech32 will not be tolerated/used.
564 2018-05-28T19:34:03  <gmaxwell> jonasschnelli: huh?
565 2018-05-28T19:34:47  <jonasschnelli> gmaxwell: do you think 206 chars are acceptable to write down?
566 2018-05-28T19:34:57  <gmaxwell> That doesn't follow from what you're saying there. :)
567 2018-05-28T19:34:58  <jonasschnelli> I mean it always depends what sort of key your dealing with...
568 2018-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.
569 2018-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. :)
570 2018-05-28T19:36:25  <gmaxwell> But 206 being too much doesn't mean that beyond bech32 isn't fine.
571 2018-05-28T19:36:28  <jonasschnelli> heh.. yes. I need to try that as well...
572 2018-05-28T19:36:48  <jonasschnelli> Yes. That is true
573 2018-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).
574 2018-05-28T19:37:21  *** promag has joined #bitcoin-core-dev
575 2018-05-28T19:37:43  <gmaxwell> For a while before sipa was searching for 12 digit checksums (so 6 more digits than bech32).
576 2018-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)?
577 2018-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.
578 2018-05-28T19:38:57  <jonasschnelli> Yes. The stove/stone error that took me days to figure out... :/
579 2018-05-28T19:39:23  <gmaxwell> ugh. yes, a problem with informal is that the worst case errors are going to be pretty bad.
580 2018-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)
581 2018-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.
582 2018-05-28T19:41:08  <jonasschnelli> "12 digit checksum" (gmaxwell above) would result in 6 chars correction, right?
583 2018-05-28T19:41:09  *** TannerR has joined #bitcoin-core-dev
584 2018-05-28T19:42:21  *** justanotheruser has quit IRC
585 2018-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.
586 2018-05-28T19:43:21  <gmaxwell> (maybe even only 3? I'm not sure now... but thats why sipa was doing a search)
587 2018-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...
588 2018-05-28T19:45:57  <jonasschnelli> I see
589 2018-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?
590 2018-05-28T19:49:21  <jonasschnelli> https://github.com/lightningnetwork/lnd/tree/master/aezeed
591 2018-05-28T19:49:47  <jonasschnelli> I don't see the relevance of the nonce-missuse resistance
592 2018-05-28T19:50:16  *** nmnkgl has quit IRC
593 2018-05-28T19:51:04  <gmaxwell> I haven't seen it before.
594 2018-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
595 2018-05-28T19:51:23  <jonasschnelli> (which results in no longer be 24 words probably)
596 2018-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.
597 2018-05-28T19:52:25  <gmaxwell> because they want the user to be able to be able to give out different passwords that work.
598 2018-05-28T19:52:47  <jonasschnelli> plausible deniable,... yes. that may be a point.
599 2018-05-28T19:53:18  *** justanotheruser has joined #bitcoin-core-dev
600 2018-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.
601 2018-05-28T19:53:46  <gmaxwell> and you'd still get protection against a wrong password.
602 2018-05-28T19:54:06  <jonasschnelli> cool!
603 2018-05-28T19:54:57  <jonasschnelli> But I guess it could be really cpu-intense to find an alternative version that goes beyond gibberish things...
604 2018-05-28T19:55:01  <gmaxwell> the downside being that the user couldn't freely choose the durress password. But I think thats probably acceptable.
605 2018-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.
606 2018-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
607 2018-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.
608 2018-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?
609 2018-05-28T19:57:10  <jonasschnelli> That was also my question, why only 128bit entropy?
610 2018-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.
611 2018-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"
612 2018-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
613 2018-05-28T19:58:00  <roasbeef> y'all think 128-bits of entropy is insufficient?
614 2018-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.
615 2018-05-28T19:58:18  <jonasschnelli> Not sure... but if I can choose, I chose 256. :)
616 2018-05-28T19:58:21  <jonasschnelli> *choose
617 2018-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.
618 2018-05-28T19:59:09  <gmaxwell> the BIP39 problem but somewhat less dumb.
619 2018-05-28T19:59:31  <roasbeef> yeh, that's one detriment, but it's versioned so another version can be parameterized to store 256 bits
620 2018-05-28T20:00:00  <jonasschnelli> roasbeef: is aez beeing considered crypto-analysed enough?
621 2018-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
622 2018-05-28T20:01:14  <jonasschnelli> roasbeef: What would be the downsides of using ChaCha20Poly1305? Only the nonce missue protection?
623 2018-05-28T20:01:22  <jonasschnelli> or say "resistance"
624 2018-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
625 2018-05-28T20:03:31  <jonasschnelli> Got it. Thanks
626 2018-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
627 2018-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.
628 2018-05-28T20:08:23  *** justanotheruser has quit IRC
629 2018-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)
630 2018-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.
631 2018-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.
632 2018-05-28T20:10:01  <jonasschnelli> gmaxwell: in KDF, you referring to the salt?
633 2018-05-28T20:10:53  <gmaxwell> Yes.
634 2018-05-28T20:11:15  <gmaxwell> Without a decently sized nonce/salt the KDF will be gratitiously vulnerable to precomputation.
635 2018-05-28T20:11:45  <gmaxwell> As far as KDFs go, reasonable KDFs are incompatible with hardware wallets, unless an outsourcable KDF is used.
636 2018-05-28T20:11:59  *** Chris_Stewart_5 has joined #bitcoin-core-dev
637 2018-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
638 2018-05-28T20:14:18  <jonasschnelli> not sure if this would be a downside
639 2018-05-28T20:14:43  <gmaxwell> jonasschnelli: "there is no second passphrase"
640 2018-05-28T20:15:04  <gmaxwell> (if one one is used, you just set the other one to a random value)
641 2018-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.
642 2018-05-28T20:15:43  <jonasschnelli> true
643 2018-05-28T20:16:08  <jonasschnelli> though they could do the same if your second mac is based on a random passphrase. :)
644 2018-05-28T20:16:24  <jonasschnelli> (or random MAC)
645 2018-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)
646 2018-05-28T20:16:47  <jonasschnelli> Yes. I guess it's a "marketing" feature.
647 2018-05-28T20:17:32  <jonasschnelli> Also, if lying is something that is often easy detectable and needs more courage that one things
648 2018-05-28T20:17:39  <jonasschnelli> *thinks
649 2018-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.
650 2018-05-28T20:18:04  <jonasschnelli> secret sharing?
651 2018-05-28T20:18:30  <jonasschnelli> sharing secrets with something like the shamir approach?
652 2018-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.
653 2018-05-28T20:19:30  <gmaxwell> jonasschnelli: yes, being able to split the private key into multiple parts where all parts aren't required.
654 2018-05-28T20:19:39  <jonasschnelli> Yes. Indeed. I also don't think that the feature is practical useful.
655 2018-05-28T20:19:57  <jonasschnelli> (^ regarding deniability)
656 2018-05-28T20:20:25  <jonasschnelli> gmaxwell: I think the secret sharing is way more pratical then the deniability feature)
657 2018-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.
658 2018-05-28T20:22:25  <gmaxwell> but yea, if I had to pick one I'd do SS.
659 2018-05-28T20:22:37  <jonasschnelli> Indeed
660 2018-05-28T20:22:43  *** Krellan has quit IRC
661 2018-05-28T20:23:41  *** Krellan has joined #bitcoin-core-dev
662 2018-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....
663 2018-05-28T20:24:59  *** promag has quit IRC
664 2018-05-28T20:25:49  * jonasschnelli falls asleep
665 2018-05-28T20:28:58  *** drexl has quit IRC
666 2018-05-28T20:29:21  *** str4d has quit IRC
667 2018-05-28T20:38:30  *** bapu has quit IRC
668 2018-05-28T20:59:42  *** promag has joined #bitcoin-core-dev
669 2018-05-28T21:00:31  *** AaronvanW has joined #bitcoin-core-dev
670 2018-05-28T21:01:39  *** drexl has joined #bitcoin-core-dev
671 2018-05-28T21:07:39  *** retrop99 has joined #bitcoin-core-dev
672 2018-05-28T21:10:45  *** setpill has quit IRC
673 2018-05-28T21:15:22  *** Guyver2 has quit IRC
674 2018-05-28T21:34:50  *** bitconner has quit IRC
675 2018-05-28T21:35:11  *** bitconner has joined #bitcoin-core-dev
676 2018-05-28T21:38:46  *** Chris_Stewart_5 has quit IRC
677 2018-05-28T21:40:50  *** bitconner has quit IRC
678 2018-05-28T21:56:34  *** retrop99 has quit IRC
679 2018-05-28T21:58:44  *** arowser_ has quit IRC
680 2018-05-28T21:58:48  *** Chris_Stewart_5 has joined #bitcoin-core-dev
681 2018-05-28T21:59:01  *** arowser_ has joined #bitcoin-core-dev
682 2018-05-28T22:06:44  *** bitconner has joined #bitcoin-core-dev
683 2018-05-28T22:12:38  *** mistergold has quit IRC
684 2018-05-28T22:12:47  *** spinza has quit IRC
685 2018-05-28T22:13:09  *** mistergold has joined #bitcoin-core-dev
686 2018-05-28T22:15:18  *** Krellan has quit IRC
687 2018-05-28T22:18:26  *** Krellan has joined #bitcoin-core-dev
688 2018-05-28T22:25:30  *** belcher has quit IRC
689 2018-05-28T22:27:45  *** spinza has joined #bitcoin-core-dev
690 2018-05-28T22:30:55  *** arowser_ has quit IRC
691 2018-05-28T22:32:13  *** arowser_ has joined #bitcoin-core-dev
692 2018-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.
693 2018-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).
694 2018-05-28T22:58:21  *** bitconner has quit IRC
695 2018-05-28T23:00:25  *** bitconner has joined #bitcoin-core-dev
696 2018-05-28T23:02:33  *** Randolf has joined #bitcoin-core-dev
697 2018-05-28T23:05:38  *** lxer has quit IRC
698 2018-05-28T23:05:53  *** justanotheruser has joined #bitcoin-core-dev
699 2018-05-28T23:19:01  *** promag has quit IRC
700 2018-05-28T23:29:26  *** mistergold has quit IRC
701 2018-05-28T23:37:39  *** justanotheruser has quit IRC
702 2018-05-28T23:41:03  *** justanotheruser has joined #bitcoin-core-dev
703 2018-05-28T23:50:37  *** rex4539 has quit IRC