1 2018-05-28 01:21:21	0|Chris_Stewart_5|is it possible to compile secp256k1 on windows with jni enabled?
  2 2018-05-28 03:34:48	0|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
  3 2018-05-28 03:35:18	0|achow101|if you run the entire script as sudo, all of the folders and files that are created will be owned by root
  4 2018-05-28 05:25:29	0|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?
  5 2018-05-28 06:26:22	0|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. :)
  6 2018-05-28 07:01:11	0|sipa|mryandao: i believe cfields has some.ongoing work to get rid of it
  7 2018-05-28 07:01:20	0|sipa|but i'm not sure of the status
  8 2018-05-28 07:15:40	0|mryandao|oh, i just did an update today and it pains me to need to install that 100MB+ of libboost to compile bitcoin-core
  9 2018-05-28 07:15:54	0|mryandao|hence I asked.
 10 2018-05-28 07:20:34	0|wumpus|I think we're also quite near to being able to get rid of boost::thread
 11 2018-05-28 07:31:35	0|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
 12 2018-05-28 07:32:25	0|mryandao|boost::thread alone had 100MB+ of dependencies
 13 2018-05-28 07:33:17	0|mryandao|the rest were ok, or by the time all the dependencies were installed, it was pretty much all of libboost
 14 2018-05-28 07:35:03	0|wumpus|that's simply not true
 15 2018-05-28 07:36:18	0|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.
 16 2018-05-28 07:36:45	0|wumpus|you can check the gitian descriptor to see how by far most of the build is disabled
 17 2018-05-28 07:37:35	0|wumpus|boost itself has no dependencies outside of boost and the C and C++ basic library (boost::thread will use pthread)
 18 2018-05-28 07:38:14	0|mryandao|weird, unless apt-get by default packages all of them together?
 19 2018-05-28 07:38:28	0|mryandao|i did put down the `apt-get install libboost-thread-dev`
 20 2018-05-28 07:38:34	0|wumpus|I'm all for moving away from boost, over time, but these kinds of cheap digs at the library annoy me too
 21 2018-05-28 07:40:11	0|wumpus|strange - I'd write that up to debian instead of fundamental thing with boost itself
 22 2018-05-28 07:41:29	0|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
 23 2018-05-28 07:48:41	0|mryandao|wumpus: cool, thanks.
 24 2018-05-28 07:52:28	0|wumpus|see also #12381
 25 2018-05-28 07:52:31	0|gribble|https://github.com/bitcoin/bitcoin/issues/12381 | Remove more boost threads by theuni · Pull Request #12381 · bitcoin/bitcoin · GitHub
 26 2018-05-28 08:08:28	0|7YSAAYFCN|[13bitcoin] 15laanwj closed pull request #13317: [0.16.1] Remaining backports (060.16...06Mf1805-016ForBackport) 02https://github.com/bitcoin/bitcoin/pull/13317
 27 2018-05-28 08:08:29	0|94KAACTBR|[13bitcoin] 15laanwj pushed 9 new commits to 060.16: 02https://github.com/bitcoin/bitcoin/compare/50b2c9e0dfbe...bfd1e923335e
 28 2018-05-28 08:08:30	0|94KAACTBR|13bitcoin/060.16 140948153 15Matt Corallo: Do not unlock cs_main in ABC unless we've actually made progress....
 29 2018-05-28 08:08:30	0|94KAACTBR|13bitcoin/060.16 14c71e535 15Suhas Daftuar: Bugfix: ensure consistency of m_failed_blocks after reconsiderblock...
 30 2018-05-28 08:08:30	0|gribble|https://github.com/bitcoin/bitcoin/issues/13317 | [0.16.1] Remaining backports by MarcoFalke · Pull Request #13317 · bitcoin/bitcoin · GitHub
 31 2018-05-28 08:08:31	0|94KAACTBR|13bitcoin/060.16 14bb79aaf 15Jesse Cohen: Fix concurrency-related bugs in ActivateBestChain...
 32 2018-05-28 08:28:10	0|bitcoin-git|[13bitcoin] 15eklitzke opened pull request #13335: Implement pinentry wrapper to unlock bitcoin wallet (06master...06pinentry) 02https://github.com/bitcoin/bitcoin/pull/13335
 33 2018-05-28 09:38:28	0|fanquake|wumpus I think #13319 should be ready as well.
 34 2018-05-28 09:38:31	0|gribble|https://github.com/bitcoin/bitcoin/issues/13319 | [0.16.1] gui: Backport bech32 checkbox by MarcoFalke · Pull Request #13319 · bitcoin/bitcoin · GitHub
 35 2018-05-28 10:07:03	0|bitcoin-git|[13bitcoin] 15laanwj pushed 4 new commits to 060.16: 02https://github.com/bitcoin/bitcoin/compare/bfd1e923335e...07fb2a6e166f
 36 2018-05-28 10:07:04	0|bitcoin-git|13bitcoin/060.16 140eda98d 15Luke Dashjr: GUI: Allow generating Bech32 addresses with a legacy-address default...
 37 2018-05-28 10:07:04	0|bitcoin-git|13bitcoin/060.16 14ea487f9 15Luke Dashjr: GUI: Rephrase Bech32 checkbox text/tooltip...
 38 2018-05-28 10:07:05	0|bitcoin-git|13bitcoin/060.16 14dcb13a0 15MarcoFalke: qt: Update translations pre-rc1
 39 2018-05-28 10:08:41	0|wumpus|fanquake: does that mean we can roll 0.16.0rc1 today?
 40 2018-05-28 10:08:49	0|wumpus|0.16.1rc1
 41 2018-05-28 10:13:28	0|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
 42 2018-05-28 10:13:30	0|gribble|https://github.com/bitcoin/bitcoin/issues/12337 | 0.16 Shutdown assertion · Issue #12337 · bitcoin/bitcoin · GitHub
 43 2018-05-28 10:14:12	0|wumpus|was just looking at that - I don't think it has to block anything
 44 2018-05-28 10:14:57	0|fanquake|Yep, I think an rc1 can move ahead. Can always be fixed if it comes up again during testing
 45 2018-05-28 10:16:09	0|fanquake|Have updated all the projects and un-tagged backports etc.
 46 2018-05-28 10:35:49	0|wumpus|thanks!
 47 2018-05-28 11:05:20	0|provoostenator|I'd like to get #11658 in if that's still possible.
 48 2018-05-28 11:05:23	0|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
 49 2018-05-28 11:05:55	0|luke-jr|not sure it's a bugfix
 50 2018-05-28 11:06:39	0|provoostenator|Oh is 0.16.1 purely backports and not masteR?
 51 2018-05-28 11:06:52	0|provoostenator|In that case it can wait for 0.17
 52 2018-05-28 11:07:20	0|fanquake|provoostenator correct, https://github.com/bitcoin/bitcoin/tree/0.16
 53 2018-05-28 11:07:30	0|luke-jr|the 3rd number of a version is always for bugfixes (and in our case, consensus protocol updates)
 54 2018-05-28 11:10:24	0|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
 55 2018-05-28 11:12:54	0|fanquake|wumpus will you tag an rc tonight?
 56 2018-05-28 11:33:59	0|wumpus|fanquake: I'm working on doing last-minute checks now
 57 2018-05-28 11:34:39	0|fanquake|wumpus: np, let me know if you need a hand with anything. I'll be up for another couple hours.
 58 2018-05-28 11:34:52	0|bitcoin-git|13bitcoin/060.16 14b42c355 15Wladimir J. van der Laan: qt: Pre-rc1 transifex pull...
 59 2018-05-28 11:34:52	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 060.16: 02https://github.com/bitcoin/bitcoin/compare/07fb2a6e166f...81bc9829cdaf
 60 2018-05-28 11:34:53	0|bitcoin-git|13bitcoin/060.16 1481bc982 15Wladimir J. van der Laan: build: Bump version to 0.16.1...
 61 2018-05-28 11:38:05	0|wumpus|fanquake: just trying to build on a few platforms would help
 62 2018-05-28 11:39:30	0|fanquake|wumpus: I'll start building 81bc982
 63 2018-05-28 11:51:04	0|wumpus|are you going to try OpenBSD?
 64 2018-05-28 11:51:40	0|fanquake|wumpus I can do, it'll probably be 6.2 though
 65 2018-05-28 11:51:51	0|fanquake|Haven't setup a 6.3 VM yet
 66 2018-05-28 11:52:35	0|wumpus|I asked because I have the same problem, I should just be non-lazy and upgrade my VM
 67 2018-05-28 11:53:12	0|wumpus|at least freebsd is still 11.1, I'll do that one
 68 2018-05-28 11:58:15	0|fanquake|wumpus How about your Windows Vista VM :p
 69 2018-05-28 12:02:13	0|wumpus|you mean the windows XP one? :-)
 70 2018-05-28 12:03:53	0|fanquake|wumpus You are welcome to test, but we ditched XP with 0.16 :0
 71 2018-05-28 12:05:32	0|luke-jr|sigh, btrfs really does suck
 72 2018-05-28 12:05:59	0|fanquake|I think we could backport #13246 for 0.16, worthwhile improvements to the Windows build process.
 73 2018-05-28 12:06:02	0|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
 74 2018-05-28 12:06:05	0|wumpus|I don't have any other windows VMs though, nor are there any windows computers left here
 75 2018-05-28 12:06:28	0|fanquake|Not necessarily a bad thing
 76 2018-05-28 12:07:18	0|wumpus|luke-jr: what terrible wrong did it do to you today?
 77 2018-05-28 12:07:44	0|luke-jr|wumpus: I started my node an hour or so ago, and it's still 12 days behind (basically where it began)
 78 2018-05-28 12:07:52	0|luke-jr|in the meantime, the whole PC has slowed to a crawl
 79 2018-05-28 12:08:34	0|fanquake|sounds kinda like my laptop whenever there's > 2 VM running
 80 2018-05-28 12:11:44	0|luke-jr|(as well as random unexplained WARNING stack dumps in dmesg)
 81 2018-05-28 12:27:49	0|sipa|provoostenator: 0.16.1 will be created by tagging the 0.16 branch, not master
 82 2018-05-28 12:28:19	0|sipa|0.16 branched off from master a bit before 0.16.0
 83 2018-05-28 12:29:01	0|sipa|and indeed since the feature freeze (shortly before the branch) there are only bugfixes in it
 84 2018-05-28 12:29:15	0|sipa|which are backports of changes in master
 85 2018-05-28 12:29:45	0|luke-jr|looks like about 10 minutes to process each block -.-
 86 2018-05-28 12:31:19	0|booyah|luke-jr: after all this years? :/
 87 2018-05-28 12:32:19	0|luke-jr|never going to catch up at this rate
 88 2018-05-28 12:36:53	0|wumpus|that's slower than my slowest ARM board FWIW
 89 2018-05-28 12:37:44	0|wumpus|(including lame things such as slow SD cards, slow ethernet, and external USB2 harddrives)
 90 2018-05-28 12:38:43	0|bitcoin-git|[13bitcoin] 15fanquake opened pull request #13336: [0.16.1] doc: Bump to Ubuntu Bionic 18.04 in build-windows.md (060.16...06windows-1804) 02https://github.com/bitcoin/bitcoin/pull/13336
 91 2018-05-28 12:38:58	0|wumpus|fanquake: thanks!
 92 2018-05-28 12:40:42	0|fanquake|I'm doing my testing with 18.04, and getting rid of those work around is a +
 93 2018-05-28 12:41:03	0|wumpus|definitely
 94 2018-05-28 12:41:12	0|wumpus|good to think of that
 95 2018-05-28 13:00:50	0|luke-jr|moved chainstate to SSD, more like 10 seconds per block now (still btrfs'd)
 96 2018-05-28 13:04:11	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #13336: [0.16.1] doc: Bump to Ubuntu Bionic 18.04 in build-windows.md (060.16...06windows-1804) 02https://github.com/bitcoin/bitcoin/pull/13336
 97 2018-05-28 13:22:22	0|wumpus|FreeBSD 11.1 and OpenBSD 6.2 builds OK
 98 2018-05-28 13:23:35	0|fanquake|macOS 10.13.5 builds OK. Currently building depends on Windows 10
 99 2018-05-28 13:27:54	0|luke-jr|hm, there must be something wrong. ps claims bitcoin-qt's SIZE is 37 GB :|
100 2018-05-28 13:31:05	0|wumpus|(also Ubuntu 16.04 and 18.04, but that's not really surprising)
101 2018-05-28 13:31:12	0|wumpus|luke-jr: ouch, can you bisect that?
102 2018-05-28 13:32:23	0|luke-jr|wumpus: it's during startup, so.. I'm not sure it's a bug on our end
103 2018-05-28 13:32:48	0|luke-jr|my first guess is -fsanitize stuff, so trying again without those
104 2018-05-28 13:36:09	0|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?
105 2018-05-28 13:36:34	0|luke-jr|think*
106 2018-05-28 13:37:02	0|luke-jr|(and yes, disabling sanitizers seems to have fixed the insane SIZE)
107 2018-05-28 13:37:48	0|wumpus|ok, good to know, no worry for 0.16.1 then
108 2018-05-28 13:48:50	0|wumpus|so if anyone else wants to try building the 0.16 branch on various platforms, please do
109 2018-05-28 13:49:21	0|wumpus|if not, I'm going to tag rc1 after fanquake's windows build succeeds
110 2018-05-28 13:53:05	0|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.
111 2018-05-28 13:53:06	0|gribble|https://github.com/bitcoin/bitcoin/issues/13306 | build: split warnings out of CXXFLAGS by theuni · Pull Request #13306 · bitcoin/bitcoin · GitHub
112 2018-05-28 14:01:15	0|bitcoin-git|13bitcoin/06master 149e305b5 15Cory Fields: build: split warnings out of CXXFLAGS...
113 2018-05-28 14:01:15	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/610f4dd719ad...f5a7733ff767
114 2018-05-28 14:01:16	0|bitcoin-git|13bitcoin/06master 14f5a7733 15Wladimir J. van der Laan: Merge #13306: build: split warnings out of CXXFLAGS...
115 2018-05-28 14:02:04	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #13306: build: split warnings out of CXXFLAGS (06master...06debug_flags) 02https://github.com/bitcoin/bitcoin/pull/13306
116 2018-05-28 14:02:54	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/f5a7733ff767...fb7731089ed2
117 2018-05-28 14:02:55	0|bitcoin-git|13bitcoin/06master 141680b8b 15practicalswift: docs: Update OpenBSD build instructions for OpenBSD 6.3
118 2018-05-28 14:02:55	0|bitcoin-git|13bitcoin/06master 14fb77310 15Wladimir J. van der Laan: Merge #13295: docs: Update OpenBSD build instructions for OpenBSD 6.3...
119 2018-05-28 14:03:44	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #13295: docs: Update OpenBSD build instructions for OpenBSD 6.3 (06master...06openbsd-6.3) 02https://github.com/bitcoin/bitcoin/pull/13295
120 2018-05-28 14:07:52	0|fanquake|wumpus The depends build, compile and make install completed successfully, using the 18.04 instructions.
121 2018-05-28 14:08:01	0|fanquake|However the binaries wont launch..
122 2018-05-28 14:08:20	0|fanquake|Trying another build, otherwise I'll have to try debugging tomorrow.
123 2018-05-28 14:08:53	0|wumpus|not even bitcoin-cli?
124 2018-05-28 14:12:18	0|fanquake|Got some error output, 1 sec
125 2018-05-28 14:13:51	0|fanquake|heh, I'm seeing #12337 :(
126 2018-05-28 14:13:52	0|gribble|https://github.com/bitcoin/bitcoin/issues/12337 | 0.16 Shutdown assertion · Issue #12337 · bitcoin/bitcoin · GitHub
127 2018-05-28 14:14:22	0|fanquake|https://0bin.net/paste/1iOaeL+DunFWqy0n#gwr6oLIgrjlG45QDIdN4u2yqvUTIHGR3goxtENCMzwJ
128 2018-05-28 14:19:51	0|fanquake|wumpus ^ I need to sleep. Can continue investigating tomorrow. Up to you about an RC1 tag.
129 2018-05-28 14:22:22	0|wumpus|thanks, sleep well
130 2018-05-28 14:28:16	0|bitcoin-git|13bitcoin/06master 14fa9da85 15MarcoFalke: qa: Initialize lockstack to prevent null pointer deref
131 2018-05-28 14:28:16	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/fb7731089ed2...14a4b4966361
132 2018-05-28 14:28:17	0|bitcoin-git|13bitcoin/06master 1414a4b49 15Wladimir J. van der Laan: Merge #13300: qa: Initialize lockstack to prevent null pointer deref...
133 2018-05-28 14:29:10	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #13300: qa: Initialize lockstack to prevent null pointer deref (06master...06Mf1805-qaLockDebug) 02https://github.com/bitcoin/bitcoin/pull/13300
134 2018-05-28 14:39:33	0|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
135 2018-05-28 14:39:36	0|gribble|https://github.com/bitcoin/bitcoin/issues/12337 | 0.16 Shutdown assertion · Issue #12337 · bitcoin/bitcoin · GitHub
136 2018-05-28 14:53:10	0|wumpus|but I'll wait for some other opinions...
137 2018-05-28 15:09:53	0|ken2812221|Should we backport #13131?
138 2018-05-28 15:09:55	0|gribble|https://github.com/bitcoin/bitcoin/issues/13131 | Add Windows shutdown handler by ken2812221 · Pull Request #13131 · bitcoin/bitcoin · GitHub
139 2018-05-28 15:10:06	0|bitcoin-git|13bitcoin/06master 142885c13 15Jonas Schnelli: Qt: use [default wallet] as name for wallet with no name
140 2018-05-28 15:10:06	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/14a4b4966361...a315b79ad2b8
141 2018-05-28 15:10:07	0|bitcoin-git|13bitcoin/06master 14a315b79 15Wladimir J. van der Laan: Merge #13275: Qt: use [default wallet] as name for wallet with no name...
142 2018-05-28 15:10:50	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #13275: Qt: use [default wallet] as name for wallet with no name (06master...062018/05/loadwallet_gui_name) 02https://github.com/bitcoin/bitcoin/pull/13275
143 2018-05-28 15:11:35	0|wumpus|i'm ok with that, for 0.16.2 though
144 2018-05-28 15:12:50	0|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
145 2018-05-28 15:16:48	0|ken2812221|ok
146 2018-05-28 15:23:43	0|jonasschnelli|"A Bech32[2] string is at most 90 characters long and consists of:"... that is not a bech32 limit, right?
147 2018-05-28 15:23:51	0|jonasschnelli|https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#bech32
148 2018-05-28 15:27:43	0|Chris_Stewart_5|jonasschnelli: I'm curious why that is in place too. I think the lightning network teams break that rule as well
149 2018-05-28 15:27:54	0|wumpus|I think the properties would no longer hold with the same checksum length
150 2018-05-28 15:28:03	0|wumpus|and longer data length
151 2018-05-28 15:28:08	0|jonasschnelli|Chris_Stewart_5: I guess it refers to the max length for a native P2SH address
152 2018-05-28 15:28:21	0|jonasschnelli|wumpus: ah. that is a point
153 2018-05-28 15:30:06	0|jonasschnelli|wumpus: https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#checksum-design, yes. your right
154 2018-05-28 15:30:45	0|jonasschnelli|length 89 is the max for ≤4 wrong chars tolerance
155 2018-05-28 15:38:13	0|sipa|jonasschnelli: bip173 addresses are at most 74 characters
156 2018-05-28 15:38:52	0|sipa|bech32 encoding supports up to 90 characters (including prefix and separator)
157 2018-05-28 15:39:31	0|sipa|in some places a version of bech32 is used that violates that limit (e.g. lightning payments)
158 2018-05-28 15:49:32	0|jonasschnelli|sipa: "a version of" means modified code or just exceed of that limit that no longer "guarantees" the 4 chars correction?
159 2018-05-28 15:50:16	0|jonasschnelli|I though of using Bech32 for a new encoding format for extended keys but not sure if it makes sense at these lengths
160 2018-05-28 15:50:22	0|jonasschnelli|I *thought
161 2018-05-28 15:51:58	0|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
162 2018-05-28 15:53:33	0|jonasschnelli|thanks aj
163 2018-05-28 15:55:52	0|sipa|jonasschnelli: for pivate keys you want something else
164 2018-05-28 15:56:03	0|sipa|addresses only need error detection
165 2018-05-28 15:57:02	0|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
166 2018-05-28 15:57:12	0|sipa|while failed private keys have no such option
167 2018-05-28 16:53:39	0|wumpus|any opinions on tagging rc1 or not?
168 2018-05-28 16:55:18	0|sipa|any things missing (according to some)?
169 2018-05-28 16:56:35	0|wumpus|well #12337
170 2018-05-28 16:56:37	0|gribble|https://github.com/bitcoin/bitcoin/issues/12337 | 0.16 Shutdown assertion · Issue #12337 · bitcoin/bitcoin · GitHub
171 2018-05-28 16:58:30	0|sipa|otherwise harmless assert failure at shutdown?
172 2018-05-28 16:59:45	0|wumpus|yes
173 2018-05-28 17:01:59	0|sipa|can we remove the assert...?
174 2018-05-28 17:05:21	0|wumpus|that's not a bad idea
175 2018-05-28 17:07:38	0|wumpus|it doesn't seem to be a problem on master, just 0.16
176 2018-05-28 17:07:47	0|sipa|hmm
177 2018-05-28 17:09:39	0|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
178 2018-05-28 17:10:17	0|wumpus|anyhow, maybe it doesn't matter too much for rc11
179 2018-05-28 17:10:19	0|wumpus|rc1*
180 2018-05-28 17:11:03	0|wumpus|depends on how quickly we want to start testing this
181 2018-05-28 17:22:54	0|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
182 2018-05-28 17:23:08	0|sipa|ah, you mean fix the assert in rc2/final?
183 2018-05-28 17:24:03	0|wumpus|yes
184 2018-05-28 17:24:14	0|sipa|sgtm
185 2018-05-28 17:24:33	0|wumpus|it makes the process somewhat more parallel instead of serial
186 2018-05-28 17:38:54	0|pergaminho|Olá alguém de São Paulo?
187 2018-05-28 17:39:06	0|sipa|english please
188 2018-05-28 17:40:59	0|pergaminho|Excuse me, I want to know if there's anyone in Sao Paulo.
189 2018-05-28 17:43:27	0|wumpus|that seems very off topic
190 2018-05-28 18:22:57	0|wumpus|* [new tag]                                                                           v0.16.1rc1 -> v0.16.1rc1
191 2018-05-28 18:23:34	0|sipa|w00t
192 2018-05-28 18:31:38	0|achow101|yay
193 2018-05-28 18:44:49	0|jonasschnelli|sipa: have you explored the field of BCH codes suitable for private keys?
194 2018-05-28 18:47:23	0|sipa|jonasschnelli: yes, a bit
195 2018-05-28 18:47:36	0|sipa|but the tradeoffs are hard
196 2018-05-28 18:48:05	0|sipa|strictly for private keys, you could correct 4 errors with 12 characters of checksum
197 2018-05-28 18:48:43	0|sipa|but not with an efficient algorithm
198 2018-05-28 18:49:00	0|jonasschnelli|with private keys you mean 256bits, right?
199 2018-05-28 18:49:03	0|sipa|yes
200 2018-05-28 18:49:59	0|jonasschnelli|Hmm... for an xpriv, if the chaincode should also have the same robustness, it is maybe an overkill in length
201 2018-05-28 18:51:10	0|jonasschnelli|sipa: how are Bech32 properties for 512 bits? How much chars would be guaranteed in the correction?
202 2018-05-28 18:51:46	0|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
203 2018-05-28 18:52:05	0|jonasschnelli|I'd say that is accaptable...
204 2018-05-28 18:52:29	0|jonasschnelli|I would also say 4 error may be acceptable for 103 chars
205 2018-05-28 18:52:46	0|jonasschnelli|Ideally it would be flexible ("choose your size / robustness")
206 2018-05-28 18:53:01	0|sipa|such a code would guarantee correction of 4 up to length 1023
207 2018-05-28 18:53:15	0|sipa|(of which 15 are checksum characters, and 1008 are data)
208 2018-05-28 18:54:44	0|jonasschnelli|sipa: hmm... and there is no optimised code for something up to 103 chars (512bit in base32).
209 2018-05-28 18:54:45	0|jonasschnelli|?
210 2018-05-28 18:55:17	0|sipa|jonasschnelli: so there is an important distinction here
211 2018-05-28 18:55:47	0|sipa|a BCH code is a just a subset of cyclic codes, with parameters generated in a specific way
212 2018-05-28 18:55:58	0|jonasschnelli|the 4 in 1023?
213 2018-05-28 18:56:12	0|sipa|that specific way guarantees (1) a certain level of error correction and (2) an efficient algorithm to do so
214 2018-05-28 18:56:41	0|sipa|all these codes are however "better" than what they're designed for
215 2018-05-28 18:56:42	0|jonasschnelli|so the BCH subset may not be ideal for private keys
216 2018-05-28 18:56:53	0|sipa|it absolutely is not
217 2018-05-28 18:56:57	0|sipa|BCH codes are not optimal
218 2018-05-28 18:57:00	0|sipa|but they're easy
219 2018-05-28 18:57:08	0|sipa|(and they may be close to optimal)
220 2018-05-28 18:57:27	0|sipa|bech32 is a BCH code that only guarantees detecting 3 errors up to length 1023... that's the BCH part
221 2018-05-28 18:57:54	0|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
222 2018-05-28 18:58:07	0|sipa|that took a few years of CPU time to find out, though :)
223 2018-05-28 18:58:16	0|jonasschnelli|Yes. I heard that. :)
224 2018-05-28 18:58:25	0|sipa|the BCH part is just math; i can tell you in an instant how good a code is
225 2018-05-28 18:58:53	0|sipa|but no, i can't create a BCH code whose _designed_ strength is optimal for 103 characters; no such codes exist
226 2018-05-28 18:59:05	0|jonasschnelli|I see...
227 2018-05-28 18:59:17	0|sipa|there do exist BCH codes for length 93, FWIW :)
228 2018-05-28 18:59:40	0|sipa|with just 13 checksum characters, even
229 2018-05-28 18:59:54	0|sipa|but the next one up is for length 1023
230 2018-05-28 19:00:28	0|jonasschnelli|Unsure if 4 chars are enough for a private key...
231 2018-05-28 19:00:37	0|jonasschnelli|Implementation wise, using bech32 would be a great thing since it will very likely be already present in the code/framework...
232 2018-05-28 19:01:45	0|sipa|19 checksum characters if you want an efficient way to correct 5
233 2018-05-28 19:02:03	0|jonasschnelli|new proposals may lead to not getting implemented because of a complex implementation,... bech32 would make it pretty simple
234 2018-05-28 19:02:16	0|sipa|the checksum algorithm for all of these is trivial
235 2018-05-28 19:02:23	0|sipa|just as simple as bech32, but with larger integers
236 2018-05-28 19:02:39	0|sipa|the error correction algorithm is more complex (but very fast)
237 2018-05-28 19:03:41	0|jonasschnelli|the 19/5 code is in the BCH subset (up to 1023)?
238 2018-05-28 19:03:52	0|sipa|yup
239 2018-05-28 19:04:09	0|jonasschnelli|Something you drilled out of your supermachine?
240 2018-05-28 19:04:19	0|jonasschnelli|(calculated on your own?)
241 2018-05-28 19:04:29	0|sipa|no, this is just BCH
242 2018-05-28 19:04:36	0|sipa|it's a simple sage script to compute these
243 2018-05-28 19:04:47	0|sipa|they're not optimized for anything beyong their design strength
244 2018-05-28 19:05:26	0|sipa|among all the 19/5 codes (there are likely thousands) i could search for the "best" one according to some extra criteria
245 2018-05-28 19:06:19	0|jonasschnelli|So it could be possible to find a 19/6 within a length property of l<103?
246 2018-05-28 19:06:26	0|jonasschnelli|<=
247 2018-05-28 19:06:55	0|sipa|that seems unlikely, but it's possible yes
248 2018-05-28 19:07:06	0|sipa|it may also take more computing power than we have
249 2018-05-28 19:07:21	0|jonasschnelli|I see
250 2018-05-28 19:07:48	0|sipa|however, if it's just for single private keys, we could use length 93 codes
251 2018-05-28 19:08:25	0|sipa|where just 13 characters for 4 corrections, or 16 characters for 5, is sufficient
252 2018-05-28 19:09:21	0|jonasschnelli|That would not cover encoding an extended private key though....
253 2018-05-28 19:09:24	0|sipa|yup
254 2018-05-28 19:09:42	0|sipa|also, codes _designed_ for length 93 will perform terrible beyond it
255 2018-05-28 19:09:48	0|jonasschnelli|Metadata could be ouside of the cyclic code,.. but within the checksum (is that even possible?)?
256 2018-05-28 19:09:55	0|sipa|no
257 2018-05-28 19:10:14	0|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
258 2018-05-28 19:10:17	0|jonasschnelli|So an additional checksum
259 2018-05-28 19:10:26	0|sipa|that's a bit ridiculous
260 2018-05-28 19:10:55	0|jonasschnelli|we only would need to detect errors in the metadata pert... even a parity bit would be okayish?
261 2018-05-28 19:11:04	0|jonasschnelli|*part
262 2018-05-28 19:11:08	0|sipa|but metadata includes chaincode etcx
263 2018-05-28 19:11:20	0|jonasschnelli|chaincode is essential IMO
264 2018-05-28 19:11:26	0|jonasschnelli|must be within the error correcting part
265 2018-05-28 19:11:32	0|sipa|yeah, exactly- i agree
266 2018-05-28 19:11:39	0|sipa|so a length 93 code is out of the question
267 2018-05-28 19:12:03	0|jonasschnelli|512bits seems to be the minimum if it should cover xprivs
268 2018-05-28 19:12:13	0|jonasschnelli|(other xpriv then m)
269 2018-05-28 19:12:25	0|jonasschnelli|If we would only cover m, one could think of encoding the seed
270 2018-05-28 19:12:45	0|jonasschnelli|of the seed & keypath?
271 2018-05-28 19:13:00	0|jonasschnelli|but meh for hardened protection
272 2018-05-28 19:13:27	0|jonasschnelli|wait, nm my last line
273 2018-05-28 19:14:40	0|sipa|11 char checksum for correcting 3, 15 for correcting 4, 19 for correcting 5
274 2018-05-28 19:17:24	0|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?
275 2018-05-28 19:17:37	0|jonasschnelli|Also, reusing bech32 would be very desirable...
276 2018-05-28 19:17:42	0|sipa|yes, but you can't have both
277 2018-05-28 19:17:46	0|jonasschnelli|Right now, we have 0 correction with Base58c
278 2018-05-28 19:17:53	0|sipa|bech32 can only correct 2, and inefficiently
279 2018-05-28 19:18:14	0|sipa|you design for a single combination of length and correction strength
280 2018-05-28 19:18:28	0|sipa|it will likely be better for shorter lengths, but not have an efficient algorithm to do so
281 2018-05-28 19:19:21	0|jonasschnelli|Hmm... i though bech32 corrects 4 errors up to length 89?
282 2018-05-28 19:19:22	0|jonasschnelli|*thought
283 2018-05-28 19:19:37	0|sipa|no, it *detects* 4
284 2018-05-28 19:19:48	0|jonasschnelli|ah. I see
285 2018-05-28 19:19:50	0|sipa|correction strength is always only half of the detection strength
286 2018-05-28 19:19:58	0|jonasschnelli|meh
287 2018-05-28 19:20:08	0|jonasschnelli|that is what we need for private keys. :/
288 2018-05-28 19:20:40	0|jonasschnelli|Yes. I guess then we need another encoding implementation... ideally as simple as bech32
289 2018-05-28 19:23:32	0|sipa|what do you think about a 103-character checksum code that can correct 28 errors? :)
290 2018-05-28 19:23:49	0|sipa|(doubling the length of the string)
291 2018-05-28 19:24:43	0|gmaxwell|I'm fond of that, but whats the efficiency of the correction code for that?
292 2018-05-28 19:24:45	0|jonasschnelli|sipa: I think very acceptable.. really
293 2018-05-28 19:24:58	0|sipa|206 characters is a lot :)
294 2018-05-28 19:25:08	0|jonasschnelli|I think the correct code efficiency is not very important for private keys
295 2018-05-28 19:25:08	0|sipa|gmaxwell: efficiency in terms of what?
296 2018-05-28 19:25:22	0|jonasschnelli|*correction
297 2018-05-28 19:25:24	0|gmaxwell|is it a design distance 56 code? with an efficienct locator algorithim?
298 2018-05-28 19:25:37	0|gmaxwell|jonasschnelli: it matters if its intractably slow.
299 2018-05-28 19:25:49	0|sipa|gmaxwell: distance 58 actually, design length 341
300 2018-05-28 19:26:06	0|sipa|so it could have up to 238 data characters
301 2018-05-28 19:26:53	0|gmaxwell|sipa: I guess I'd want to try writing down 206 characters and see how much I hate my life. :)
302 2018-05-28 19:26:57	0|sipa|gmaxwell: why would correct be slow?
303 2018-05-28 19:28:03	0|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.
304 2018-05-28 19:28:04	0|sipa|factoring the locator polynomial should be fast; the field size is just 32^2
305 2018-05-28 19:28:25	0|sipa|ah, i see
306 2018-05-28 19:28:34	0|sipa|all i'm talking about here are algebraic properties
307 2018-05-28 19:29:06	0|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.
308 2018-05-28 19:29:18	0|sipa|indeed :)
309 2018-05-28 19:29:22	0|gmaxwell|since the search process and the decode process are essential the same.
310 2018-05-28 19:31:33	0|gmaxwell|sipa: your suggested code also has enough length to have some metadata, a nonce for encryption, etc.
311 2018-05-28 19:32:10	0|sipa|yup
312 2018-05-28 19:32:19	0|sipa|but 2x length is... a lot
313 2018-05-28 19:32:53	0|jonasschnelli|To keep the write-down-by-hand property, I guess something beyond bech32 will not be tolerated/used.
314 2018-05-28 19:33:06	0|gmaxwell|jonasschnelli: huh?
315 2018-05-28 19:33:50	0|jonasschnelli|gmaxwell: do you think 206 chars are acceptable to write down?
316 2018-05-28 19:34:00	0|gmaxwell|That doesn't follow from what you're saying there. :)
317 2018-05-28 19:34:00	0|jonasschnelli|I mean it always depends what sort of key your dealing with...
318 2018-05-28 19:34:50	0|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.
319 2018-05-28 19:35:12	0|gmaxwell|But yes, writing down 206 might be too much, which is why I said I'd want to try it. :)
320 2018-05-28 19:35:27	0|gmaxwell|But 206 being too much doesn't mean that beyond bech32 isn't fine.
321 2018-05-28 19:35:31	0|jonasschnelli|heh.. yes. I need to try that as well...
322 2018-05-28 19:35:50	0|jonasschnelli|Yes. That is true
323 2018-05-28 19:36:02	0|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).
324 2018-05-28 19:36:46	0|gmaxwell|For a while before sipa was searching for 12 digit checksums (so 6 more digits than bech32).
325 2018-05-28 19:36:49	0|jonasschnelli|Yes. I wonder now why seed encoding proposals do have no error correction at all (or do they, AFAIL no)?
326 2018-05-28 19:37:26	0|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.
327 2018-05-28 19:38:00	0|jonasschnelli|Yes. The stove/stone error that took me days to figure out... :/
328 2018-05-28 19:38:25	0|gmaxwell|ugh. yes, a problem with informal is that the worst case errors are going to be pretty bad.
329 2018-05-28 19:39:05	0|jonasschnelli|(also wonder why they have chosen "stove" and "stone" while we know that the n and the v look often very similar)
330 2018-05-28 19:40:08	0|gmaxwell|There really isn't a lot of good data on visual similarities of letters. This was a challenge in designing bech32 too.
331 2018-05-28 19:40:11	0|jonasschnelli|"12 digit checksum" (gmaxwell above) would result in 6 chars correction, right?
332 2018-05-28 19:42:04	0|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.
333 2018-05-28 19:42:24	0|gmaxwell|(maybe even only 3? I'm not sure now... but thats why sipa was doing a search)
334 2018-05-28 19:43:22	0|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...
335 2018-05-28 19:45:00	0|jonasschnelli|I see
336 2018-05-28 19:48:22	0|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?
337 2018-05-28 19:48:23	0|jonasschnelli|https://github.com/lightningnetwork/lnd/tree/master/aezeed
338 2018-05-28 19:48:49	0|jonasschnelli|I don't see the relevance of the nonce-missuse resistance
339 2018-05-28 19:50:07	0|gmaxwell|I haven't seen it before.
340 2018-05-28 19:50:07	0|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
341 2018-05-28 19:50:26	0|jonasschnelli|(which results in no longer be 24 words probably)
342 2018-05-28 19:50:54	0|gmaxwell|a mac could be made whatever length.. so the other wallet people have been regarding authenticated encryption as a negative feature.
343 2018-05-28 19:51:28	0|gmaxwell|because they want the user to be able to be able to give out different passwords that work.
344 2018-05-28 19:51:49	0|jonasschnelli|plausible deniable,... yes. that may be a point.
345 2018-05-28 19:52:35	0|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.
346 2018-05-28 19:52:49	0|gmaxwell|and you'd still get protection against a wrong password.
347 2018-05-28 19:53:09	0|jonasschnelli|cool!
348 2018-05-28 19:54:00	0|jonasschnelli|But I guess it could be really cpu-intense to find an alternative version that goes beyond gibberish things...
349 2018-05-28 19:54:04	0|gmaxwell|the downside being that the user couldn't freely choose the durress password. But I think thats probably acceptable.
350 2018-05-28 19:54:33	0|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.
351 2018-05-28 19:55:01	0|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
352 2018-05-28 19:55:07	0|gmaxwell|another way to do it that doesn't require search is to store two check values, and one must match.
353 2018-05-28 19:55:49	0|gmaxwell|roasbeef: the thing jonas linked to made it look like the plaintext key length is limited to 16 bytes tough?
354 2018-05-28 19:56:13	0|jonasschnelli|That was also my question, why only 128bit entropy?
355 2018-05-28 19:56:16	0|gmaxwell|jonasschnelli: with the store two check values approach to 'denyability' then there is no search, just the overhead of encoding two values.
356 2018-05-28 19:56:21	0|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"
357 2018-05-28 19:56:49	0|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
358 2018-05-28 19:57:02	0|roasbeef|y'all think 128-bits of entropy is insufficient?
359 2018-05-28 19:57:15	0|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.
360 2018-05-28 19:57:21	0|jonasschnelli|Not sure... but if I can choose, I chose 256. :)
361 2018-05-28 19:57:24	0|jonasschnelli|*choose
362 2018-05-28 19:57:44	0|gmaxwell|roasbeef: it's probably sufficient, but it means you cannot encode existing values that come from schemes using 256 bits, sadly.
363 2018-05-28 19:58:12	0|gmaxwell|the BIP39 problem but somewhat less dumb.
364 2018-05-28 19:58:34	0|roasbeef|yeh, that's one detriment, but it's versioned so another version can be parameterized to store 256 bits
365 2018-05-28 19:59:03	0|jonasschnelli|roasbeef: is aez beeing considered crypto-analysed enough?
366 2018-05-28 19:59:27	0|roasbeef|it was amongst the caesar contest finalists, but dropped out iirc as it was difficult to implement efficeitnly in hardware
367 2018-05-28 20:00:16	0|jonasschnelli|roasbeef: What would be the downsides of using ChaCha20Poly1305? Only the nonce missue protection?
368 2018-05-28 20:00:25	0|jonasschnelli|or say "resistance"
369 2018-05-28 20:01:38	0|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
370 2018-05-28 20:02:34	0|jonasschnelli|Got it. Thanks
371 2018-05-28 20:05:01	0|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
372 2018-05-28 20:06:29	0|jonasschnelli|I would strongly prefer ChaCha over AEZ... but I'm not a cryptographer and have little arguments to say why.
373 2018-05-28 20:08:11	0|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)
374 2018-05-28 20:08:21	0|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.
375 2018-05-28 20:08:55	0|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.
376 2018-05-28 20:09:04	0|jonasschnelli|gmaxwell: in KDF, you referring to the salt?
377 2018-05-28 20:09:55	0|gmaxwell|Yes.
378 2018-05-28 20:10:17	0|gmaxwell|Without a decently sized nonce/salt the KDF will be gratitiously vulnerable to precomputation.
379 2018-05-28 20:10:47	0|gmaxwell|As far as KDFs go, reasonable KDFs are incompatible with hardware wallets, unless an outsourcable KDF is used.
380 2018-05-28 20:13:03	0|jonasschnelli|if you have two macs, an attacker could ask for both passphrases,.. while the current BIP39 approach, there are "infinite" possibilities
381 2018-05-28 20:13:21	0|jonasschnelli|not sure if this would be a downside
382 2018-05-28 20:13:45	0|gmaxwell|jonasschnelli: "there is no second passphrase"
383 2018-05-28 20:14:06	0|gmaxwell|(if one one is used, you just set the other one to a random value)
384 2018-05-28 20:14:35	0|gmaxwell|with the BIP39 thing someone could also keep demanding your other passphrase while you protest that there isn't one.
385 2018-05-28 20:14:45	0|jonasschnelli|true
386 2018-05-28 20:15:10	0|jonasschnelli|though they could do the same if your second mac is based on a random passphrase. :)
387 2018-05-28 20:15:26	0|jonasschnelli|(or random MAC)
388 2018-05-28 20:15:29	0|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)
389 2018-05-28 20:15:49	0|jonasschnelli|Yes. I guess it's a "marketing" feature.
390 2018-05-28 20:16:35	0|jonasschnelli|Also, if lying is something that is often easy detectable and needs more courage that one things
391 2018-05-28 20:16:42	0|jonasschnelli|*thinks
392 2018-05-28 20:16:49	0|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.
393 2018-05-28 20:17:07	0|jonasschnelli|secret sharing?
394 2018-05-28 20:17:32	0|jonasschnelli|sharing secrets with something like the shamir approach?
395 2018-05-28 20:18:02	0|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.
396 2018-05-28 20:18:33	0|gmaxwell|jonasschnelli: yes, being able to split the private key into multiple parts where all parts aren't required.
397 2018-05-28 20:18:41	0|jonasschnelli|Yes. Indeed. I also don't think that the feature is practical useful.
398 2018-05-28 20:19:00	0|jonasschnelli|(^ regarding deniability)
399 2018-05-28 20:19:27	0|jonasschnelli|gmaxwell: I think the secret sharing is way more pratical then the deniability feature)
400 2018-05-28 20:21:10	0|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.
401 2018-05-28 20:21:28	0|gmaxwell|but yea, if I had to pick one I'd do SS.
402 2018-05-28 20:21:40	0|jonasschnelli|Indeed
403 2018-05-28 20:22:55	0|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....
404 2018-05-28 22:32:26	0|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.
405 2018-05-28 22:33:59	0|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).