1 2018-05-29 00:00:05	0|achow101|jhfrontz: I think it's supposed to be modifying the vm /etc/sudoers file as part of the setup. I believe that is part of whatever vmbuilder does. however I think vmbuilder had an update recently which breaks gitian
  2 2018-05-29 01:29:31	0|achow101|if anyone wants to try gitian building with docker instead of lxc or kvm, I have an experimental branch for that: https://github.com/achow101/gitian-builder/tree/docker
  3 2018-05-29 01:29:53	0|achow101|It seems to work, but I don't know if it produces the same binaries yet
  4 2018-05-29 02:59:12	0|achow101|damnit the binaries don't match
  5 2018-05-29 03:10:00	0|achow101|oh wait, I built the wrong binaries :/
  6 2018-05-29 06:15:26	0|jonasschnelli|sipa: one thing that stuck with me over night,.. if the Bech32 BCH can detect 4 chars and correct two (length <=89), wouldn't it be trivial to brute-force the eventually present other 2 errors? Brute-force to fit the error-free checksum.
  7 2018-05-29 06:20:45	0|sipa|jonasschnelli: i don't understand
  8 2018-05-29 06:21:19	0|sipa|it's a very fundamental property that you can only correct half
  9 2018-05-29 06:21:28	0|sipa|of what you can detect
 10 2018-05-29 06:22:13	0|jonasschnelli|sipa: Okay. But wouldn't you know that there are two other errors (since it can detect 4) and where those errors are (index)?
 11 2018-05-29 06:23:22	0|jonasschnelli|I guess I get the error correction right...
 12 2018-05-29 06:24:12	0|jonasschnelli|I where under the assumption that if you have a encoded key with 4 errors, it will point out those 4 errors, ... the BCH  correction can fix two errors, so decode again after correction and figure out where the other two error where made....
 13 2018-05-29 06:24:36	0|jonasschnelli|(sry, no need for decode again)
 14 2018-05-29 06:26:33	0|sipa|jonasschnelli: the point is that there may be multiple ways of making 4 changes to your invalid codeword to turn it into a valid one; but at most one will be the correct one
 15 2018-05-29 06:27:49	0|sipa|if any two code words are at least different in 5 positions (which is the case for bech32), making up to 4 changes to a valid codeword will never result in another valid.codeword, so you'll never fail to detect
 16 2018-05-29 06:28:23	0|sipa|however, if 3 errors are made, it may be possible to "correct" it by modifying two other unrelated positions
 17 2018-05-29 06:28:34	0|sipa|resulting in a valid, but incorrect codeword
 18 2018-05-29 06:29:49	0|jonasschnelli|I'm trying to understand if there is a more "forensic" approach of reconstructing an 4 chars error BCH codeword.. if you have an address (or another validation-indicator) of you now-invalid key, brute-forcing and comparing against your validation-indicator could be possible?
 19 2018-05-29 06:30:29	0|jonasschnelli|For keys, error correction could be very cpu-intense IMO
 20 2018-05-29 06:30:55	0|sipa|yes, you can list decode
 21 2018-05-29 06:31:06	0|sipa|if you accept there are multiple possible decodi gs
 22 2018-05-29 06:31:14	0|sipa|and you can tey all of them
 23 2018-05-29 06:31:45	0|sipa|what we mean with "error correcting" power is how many errors there can be up to the point where you can uniquely identify the error
 24 2018-05-29 06:31:56	0|jonasschnelli|Worst case stupid-dummy correction would brute forcing all 4 error positions with 32^4
 25 2018-05-29 06:31:58	0|sipa|you can alwaus go try to make more changes and see if that ends up with valid codes
 26 2018-05-29 06:32:02	0|sipa|yes
 27 2018-05-29 06:32:31	0|sipa|adding a few checksum characters is generally easier :)
 28 2018-05-29 06:32:40	0|jonasschnelli|Yes... I guess so. :)
 29 2018-05-29 06:32:55	0|sipa|but if there is a lot of money at stake, you should totally do list decoding
 30 2018-05-29 06:33:10	0|jonasschnelli|This somehow makes me convinced that the Bech32 properties are not utterly bad, maybe feasible for private key encoding.
 31 2018-05-29 07:20:13	0|ken2812221|achow101: I've tested your docker method and got the same binaries. Its setup is easier than Lxc's.
 32 2018-05-29 07:26:26	0|sipa|ken2812221, achow101: you reproduced the same 0.16.1rc1 binaries as others using docker?
 33 2018-05-29 07:28:37	0|wumpus|at least all the signatures in the gitian.sigs repository match at this moment
 34 2018-05-29 07:30:16	0|ken2812221|Yes, I built the binaries using both lxc and docker, they are the same.
 35 2018-05-29 07:31:40	0|fanquake|ken2812221 Where is the docker method available?
 36 2018-05-29 07:32:53	0|ken2812221|achow101 mentioned that on top, https://github.com/achow101/gitian-builder/tree/docker
 37 2018-05-29 07:33:25	0|fanquake|ken2812221 thanks, will take a look
 38 2018-05-29 07:33:26	0|wumpus|oh I had to patch gverify to use gpg2 instead of gpg to be able to verify ken2812221's signatures at all
 39 2018-05-29 07:33:36	0|wumpus|gpg: BAD signature from "Chun Kuan Lee(ken2812221) <ken2812221@gmail.com>" [unknown]
 40 2018-05-29 07:33:36	0|wumpus|gpg:                using ECDSA key 0x4B79F986CBDF8736
 41 2018-05-29 07:33:39	0|wumpus|ken2812221: BAD SIGNATURE
 42 2018-05-29 07:33:44	0|wumpus|the other ones check out
 43 2018-05-29 07:35:10	0|wumpus|(it's a ?bad signature? this doesn't imply that your build differs)
 44 2018-05-29 07:36:36	0|wumpus|ken2812221: checking the assert manually - looks like your executables do match, but you need to re-sign it
 45 2018-05-29 07:37:16	0|wumpus|rm bitcoin-win-0.16-build.assert.sig && gpg2 --detach-sign bitcoin-win-0.16-build.assert     or something like that
 46 2018-05-29 07:38:34	0|wumpus|(but first check if verification fails there too)
 47 2018-05-29 07:39:30	0|ken2812221|OK, I'll check it
 48 2018-05-29 07:40:54	0|wumpus|(simply "gpg2 bitcoin-win-0.16-build.assert.gpg" in your 0.16.1rc1 directory should do it)
 49 2018-05-29 07:44:14	0|wumpus|(I'm only insisting on the gpg2 thing because of Ubuntu 16.04 - in 18.04, gpg is gpg2 by default,thankfully...)
 50 2018-05-29 07:52:05	0|wumpus|ken2812221: thanks, that fixed it
 51 2018-05-29 07:53:40	0|ken2812221|Sorry, maybe I did something wrong with my hardware key before.
 52 2018-05-29 07:55:23	0|wumpus|what kind of token do you use that supports ECDSA signing in hardware?
 53 2018-05-29 07:56:47	0|wumpus|seems even the most recent yubikey still does only RSA
 54 2018-05-29 07:57:42	0|ken2812221|ledger-nano-s
 55 2018-05-29 07:58:31	0|wumpus|thanks
 56 2018-05-29 07:58:58	0|wumpus|I didn't know that could be used with gpg :)
 57 2018-05-29 08:04:54	0|ken2812221|Yes it can. But the client is a third party software.
 58 2018-05-29 08:06:50	0|mryandao|would it be realistic to look at an api to integrate hardware wallet usage in Core?
 59 2018-05-29 08:07:03	0|mryandao|*designing an api
 60 2018-05-29 08:08:13	0|wumpus|though it's nistp256 not secpp256
 61 2018-05-29 08:08:56	0|wumpus|ruby is easier than I thought (patches gverify to take an arbitrary verification program) https://github.com/devrandom/gitian-builder/pull/182
 62 2018-05-29 08:09:24	0|wumpus|mryandao: to make that feasible such an API should be generic, not 'just for Core'
 63 2018-05-29 08:09:31	0|wumpus|mryandao: jonasschnelli has been looking into this
 64 2018-05-29 08:09:48	0|jonasschnelli|mryandao: Yes.
 65 2018-05-29 08:10:12	0|jonasschnelli|BIP174 is a great basepoint...
 66 2018-05-29 08:10:22	0|jonasschnelli|Though its serialization format is not optimized for HWW/MCUs
 67 2018-05-29 08:10:59	0|jonasschnelli|For Core&HWW, the question is what standard we would follow... we can't use proprietary vendor specific USB communication
 68 2018-05-29 08:11:09	0|jonasschnelli|Ideally it would be similar to how SSH/GPG agents work
 69 2018-05-29 08:11:17	0|wumpus|it's kind of frustrating how this is different enough for standard smartcard crypto APIs that it requires something entirely new
 70 2018-05-29 08:11:37	0|jonasschnelli|wumpus: Yes. Those standard didn't bothered about verification...
 71 2018-05-29 08:11:45	0|wumpus|yes, definitely, there would need to be an external driver, and this standard should describe how to communicate with that
 72 2018-05-29 08:11:46	0|jonasschnelli|They are happy if the key is on the card...
 73 2018-05-29 08:12:08	0|jonasschnelli|Extra driver is something users dislike... thats why I once proposed the URI scheme.
 74 2018-05-29 08:12:13	0|wumpus|the details, such as how communication with the device happens, is up to the vendor
 75 2018-05-29 08:12:23	0|wumpus|we're not going to do low-level USB stuff in bitcoin core
 76 2018-05-29 08:12:31	0|mryandao|isnt there libusb?
 77 2018-05-29 08:12:33	0|jonasschnelli|Yes!
 78 2018-05-29 08:12:52	0|wumpus|(nor link against libhid or any other nightmare abominations)
 79 2018-05-29 08:13:00	0|jonasschnelli|Core has already too much dependencies...
 80 2018-05-29 08:13:04	0|jonasschnelli|What we want is communicate with a "bridge-application"
 81 2018-05-29 08:13:19	0|wumpus|"> Extra driver is something users dislike" is there any other realistic option?!
 82 2018-05-29 08:14:03	0|jonasschnelli|URI schemes would allow that an application opens "sign://<data>" where to OS would start the application that have registered sign://
 83 2018-05-29 08:14:09	0|wumpus|smartcards, yubikeys etc also have their own driver, it's not like gpg2 includes low-level support for all of them.
 84 2018-05-29 08:14:19	0|wumpus|so that's effectively a driver
 85 2018-05-29 08:14:33	0|wumpus|what you are documenting is the communication protocol with it, which could use an URI, sure...
 86 2018-05-29 08:15:03	0|jonasschnelli|It would avoid a daemon and it would be portable (probably)
 87 2018-05-29 08:15:23	0|wumpus|sure, it could be a process that is launched on demand, it dosn't have to be an always-on daemon
 88 2018-05-29 08:15:30	0|mryandao|it wouldn't be that painful to install an agent like gpg i'd imagine
 89 2018-05-29 08:15:58	0|wumpus|I also dislike things that have to run always, especially if it concerns the wallet, you want to be able to remove the device at any time anyway
 90 2018-05-29 08:16:29	0|wumpus|on the other hand, to be honest, at this point I'd prefer *any* standard for HW wallets to the jungle there is now, can always optimize the details later
 91 2018-05-29 08:16:32	0|mryandao|but the agent that's up 24/7 wouldnt be holding the keys no?
 92 2018-05-29 08:18:16	0|wumpus|it could, but for a HSM it wouldn't hold the keys itself, at most identifiers.
 93 2018-05-29 08:19:12	0|wumpus|though there could be a agent that uses, say, a CPU secure enclave instead of a real hardware wallet, that's up to the vendor
 94 2018-05-29 08:21:03	0|mryandao|sounds like the painpoints alone warrant a workshop on integration of HSMs with Bitcoin
 95 2018-05-29 08:21:07	0|wumpus|(or if, say, TPM3.0 standard would include cryptocurrency wallet support, could use the motherboard TPM module)
 96 2018-05-29 08:21:59	0|wumpus|in any case, the wallet software shouldn't need to care about those details at all
 97 2018-05-29 08:22:33	0|mryandao|i thought the community as a whole finds TPMs to be distasteful
 98 2018-05-29 08:26:07	0|wumpus|smartcards, security tokens, etc are essentially pluggable TPMs
 99 2018-05-29 08:28:37	0|wumpus|and in my opinion there are certainly distasteful uses of them, such as OS vendor lock-in and DRM, but this is getting off topic, I was just illustrating that there is a large range of possibilities.
100 2018-05-29 08:33:04	0|wumpus|< mryandao> sounds like the painpoints alone warrant a workshop on integration of HSMs with Bitcoin <- I agree, it's something that could use more concentrated effort
101 2018-05-29 08:34:37	0|wumpus|I've always been surprised how little the hardware wallets vendors care about this, they just carve out their little space with their own proprietary protocols and software, instead of starting some bitcoin HSM working group
102 2018-05-29 08:35:15	0|wumpus|even if you don't care about "use of Bitcoin Core as wallet" (like Trezor), it seems that other wallets would benefit from the same
103 2018-05-29 08:35:18	0|wumpus|anyhow </soapbox>
104 2018-05-29 09:49:18	0|bitcoin-git|[13bitcoin] 15harrymckinnon86 opened pull request #13338: Test (06master...06test) 02https://github.com/bitcoin/bitcoin/pull/13338
105 2018-05-29 09:49:48	0|bitcoin-git|[13bitcoin] 15harrymckinnon86 closed pull request #13338: Test (06master...06test) 02https://github.com/bitcoin/bitcoin/pull/13338
106 2018-05-29 12:15:15	0|jonasschnelli|roasbeef: have you considered hardware wallet during your aezeed specs? Is scrypt(n=32768, r=8, p=1) something that works on a tiny MCU (like those ones used by Trezor, Ledger, Bitbox)?
107 2018-05-29 13:06:18	0|promag|thoughts on #13160?
108 2018-05-29 13:06:21	0|gribble|https://github.com/bitcoin/bitcoin/issues/13160 | wallet: Unlock spent outputs by promag · Pull Request #13160 · bitcoin/bitcoin · GitHub
109 2018-05-29 13:11:45	0|bitcoin-git|[13bitcoin] 15laanwj pushed 6 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/a315b79ad2b8...56fe3dc235a0
110 2018-05-29 13:11:46	0|bitcoin-git|13bitcoin/06master 144e91820 15Pieter Wuille: Make IsMine stop distinguishing solvable/unsolvable
111 2018-05-29 13:11:46	0|bitcoin-git|13bitcoin/06master 146d714c3 15Pieter Wuille: Make coincontrol use IsSolvable to determine solvability
112 2018-05-29 13:11:47	0|bitcoin-git|13bitcoin/06master 14b5802a9 15Pieter Wuille: Simplify IsMine logic
113 2018-05-29 13:12:36	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #13142: Separate IsMine from solvability (06master...06201804_separate_ismine_solvable) 02https://github.com/bitcoin/bitcoin/pull/13142
114 2018-05-29 13:24:06	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/56fe3dc235a0...3fd0c2336a12
115 2018-05-29 13:24:07	0|bitcoin-git|13bitcoin/06master 1413c3a65 15João Barbosa: Qt/Bugfix: fix handling default wallet with no name
116 2018-05-29 13:24:07	0|bitcoin-git|13bitcoin/06master 143fd0c23 15Wladimir J. van der Laan: Merge #13273: Qt/Bugfix: fix handling default wallet with no name...
117 2018-05-29 13:24:52	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #13273: Qt/Bugfix: fix handling default wallet with no name (06master...062018/05/loadwallet_fix) 02https://github.com/bitcoin/bitcoin/pull/13273
118 2018-05-29 13:27:51	0|wumpus|promag: lgtm
119 2018-05-29 13:28:50	0|wumpus|promag: so I think removing spent UTXOs from the locked set automatically is a better solution than the other PR, also the code change is cleaner, but it seems not many people weigh in
120 2018-05-29 13:29:00	0|promag|right
121 2018-05-29 13:29:23	0|promag|I also think other should give feedback there
122 2018-05-29 13:30:18	0|wumpus|I disagree with the opinion in the other PR that yours is 'a breaking change', I mean this is the behavior already, the only change is that the UTXOs don't linger around forever
123 2018-05-29 13:31:27	0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/3fd0c2336a12...70d354131379
124 2018-05-29 13:31:28	0|bitcoin-git|13bitcoin/06master 1487fe292 15Wladimir J. van der Laan: doc: Mention disabling BIP61 in bips.md
125 2018-05-29 13:31:28	0|bitcoin-git|13bitcoin/06master 14fe16dd8 15Wladimir J. van der Laan: net: Add option `-enablebip61` to configure sending of BIP61 notifications...
126 2018-05-29 13:31:29	0|bitcoin-git|13bitcoin/06master 1470d3541 15Wladimir J. van der Laan: Merge #13134: net: Add option `-enablebip61` to configure sending of BIP61 notifications...
127 2018-05-29 13:32:08	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #13134: net: Add option `-enablebip61` to configure sending of BIP61 notifications (06master...062018_05_optional_bip61) 02https://github.com/bitcoin/bitcoin/pull/13134
128 2018-05-29 13:45:13	0|bitcoin-git|[13bitcoin] 15promag opened pull request #13339: wallet: Replace %w by wallet name in -walletnotify script (06master...062018-05-walletnotify) 02https://github.com/bitcoin/bitcoin/pull/13339
129 2018-05-29 13:46:02	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #13281: test: Move linters to test/lint, add readme (06master...06Mf1805-qaLint) 02https://github.com/bitcoin/bitcoin/pull/13281
130 2018-05-29 13:50:46	0|bitcoin-git|[13bitcoin] 15fanquake opened pull request #13340: doc: remove leftover check-doc documentation (06master...06move-check-doc) 02https://github.com/bitcoin/bitcoin/pull/13340
131 2018-05-29 13:51:02	0|fanquake|wumpus #13340 is a trivial follow up to fix the doc nit
132 2018-05-29 13:51:05	0|gribble|https://github.com/bitcoin/bitcoin/issues/13340 | doc: remove leftover check-doc documentation by fanquake · Pull Request #13340 · bitcoin/bitcoin · GitHub
133 2018-05-29 13:57:57	0|bitcoin-git|13bitcoin/06master 14f44a0eb 15Jeff Frontz: Ensure gitian-build.sh uses bash...
134 2018-05-29 13:57:57	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/2ac6315f44a8...e08c130c25ed
135 2018-05-29 13:57:58	0|bitcoin-git|13bitcoin/06master 14e08c130 15Wladimir J. van der Laan: Merge #13320: Ensure gitian-build.sh uses bash...
136 2018-05-29 13:58:22	0|wumpus|fanquake: thanks!
137 2018-05-29 14:00:31	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #13320: Ensure gitian-build.sh uses bash (06master...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/13320
138 2018-05-29 14:03:01	0|bitcoin-git|13bitcoin/06master 1493843f6 15fanquake: doc: remove leftover check-doc documentation
139 2018-05-29 14:03:01	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/e08c130c25ed...3a8e3f480612
140 2018-05-29 14:03:02	0|bitcoin-git|13bitcoin/06master 143a8e3f4 15Wladimir J. van der Laan: Merge #13340: doc: remove leftover check-doc documentation...
141 2018-05-29 14:03:56	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #13340: doc: remove leftover check-doc documentation (06master...06move-check-doc) 02https://github.com/bitcoin/bitcoin/pull/13340
142 2018-05-29 15:48:58	0|jnewbery|wumpus: I'm out for this Thursdays's meeting. Now that 0.16.1rc1 is out and the high priority list is a bit shorter, can we consider adding #13058? It's the next in the dynamic wallet load/unload series.
143 2018-05-29 15:49:00	0|gribble|https://github.com/bitcoin/bitcoin/issues/13058 | [wallet] `createwallet` RPC - create new wallet at runtime by jnewbery · Pull Request #13058 · bitcoin/bitcoin · GitHub
144 2018-05-29 16:59:24	0|bitcoin-git|[13bitcoin] 15krab closed pull request #12783: macOS: Disable AppNap (06master...06macos-disable-appnap) 02https://github.com/bitcoin/bitcoin/pull/12783
145 2018-05-29 17:03:32	0|wumpus|jnewbery: sure
146 2018-05-29 17:04:23	0|bitcoin-git|[13bitcoin] 15krab reopened pull request #12783: macOS: Disable AppNap (06master...06macos-disable-appnap) 02https://github.com/bitcoin/bitcoin/pull/12783
147 2018-05-29 17:05:37	0|wumpus|added
148 2018-05-29 17:26:20	0|promag|wumpus: we could hash(wallet.name) and use that in listwallets, -walletnotify etc..
149 2018-05-29 17:38:30	0|promag|looks like mempool_persist.py is flaky
150 2018-05-29 18:01:48	0|bitcoin-git|13bitcoin/06master 1459e9688 15Chun Kuan Lee: Travis: Build tests on Ubuntu 18.04 with docker
151 2018-05-29 18:01:48	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/3a8e3f480612...f8a29ca823fb
152 2018-05-29 18:01:49	0|bitcoin-git|13bitcoin/06master 14f8a29ca 15Wladimir J. van der Laan: Merge #13215: Travis: Build tests on Ubuntu 18.04 with docker...
153 2018-05-29 18:02:38	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #13215: Travis: Build tests on Ubuntu 18.04 with docker (06master...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/13215
154 2018-05-29 19:10:02	0|roasbeef|jonasschnelli: likely to high of params (actually a real kdf) to be feasible on hardware wallets, idea was to add an additional external version w/ lighter weight params
155 2018-05-29 19:24:10	0|jonasschnelli|roasbeef: yeah. real KDF for HWW is hard. Especially memory based like scrypt
156 2018-05-29 19:24:38	0|jonasschnelli|I just tested PBKDF with 20k rounds on a Bitbox. Takes 30 seconds
157 2018-05-29 19:25:06	0|jonasschnelli|acceptable IMO for seed and recovery... but not for a device PIN KDF.
158 2018-05-29 19:25:38	0|sipa|outsourcable hardening would be nice
159 2018-05-29 19:26:13	0|jonasschnelli|sipa: yes. but imo that concept needs to be specified and analysed further more
160 2018-05-29 19:27:41	0|sipa|absolutely
161 2018-05-29 19:27:52	0|jonasschnelli|I think it's acceptable to wait 30s on a HWW during encrypted seed backup (seed with optional encryption) as well as during a wallet restore
162 2018-05-29 19:28:42	0|jonasschnelli|30s PBKDF results in acceptable 40ms on my Intel corei7
163 2018-05-29 19:29:17	0|jonasschnelli|optional, the rounds could be flexible and make it into the seed serialization format
164 2018-05-29 19:29:47	0|jonasschnelli|wait longer == better KDF / brute force / wordlist resistance
165 2018-05-29 20:20:23	0|bitcoin-git|[13bitcoin] 15achow101 closed pull request #13289: [Qt] Re-setup args after translator setup to translate help text (06master...06qt-help-translations) 02https://github.com/bitcoin/bitcoin/pull/13289