1 2017-11-17 00:03:23	0|gmaxwell|jcorgan: after reading NIST tests of varrious CDR media I dunno about trusting any of it-- they found two order of magnitude variations in durability of even 'archival grade' media.  Seemed like the only way to be confident at all is to have an independant lab test it.
  2 2017-11-17 00:05:26	0|gmaxwell|jonasschnelli: probably a short private key with error correction scribed on metal (with a diamond scribe or cryptosteel) is probably the best durability that can be achieved.  Most other alternatives are not especially fire/water durable.
  3 2017-11-17 00:09:09	0|jcorgan|yeah, it's more a convenience than anything to really trust. the US navy testing report i posted above used fairly good methodology and th mdisc fared well. again, though, it's a convenience and only one part of an overall system.
  4 2017-11-17 00:09:31	0|jcorgan|"If it isn't backed up in three different ways and stored in three different places, it is already lost."
  5 2017-11-17 00:10:02	0|gmaxwell|yea, thanks for the pointer.
  6 2017-11-17 00:11:22	0|gmaxwell|FWIW, I've found in research that CD readers actually have far less reading robustness that in theoretically possible.  So for data recovery you could potentially read a lot of unreadable disks with a specialized drive.  (there is a project on github to read audio CDs with a USRP bolted to the photodetector output of a laserdisk player).
  7 2017-11-17 00:11:47	0|bitcoin-git|[13bitcoin] 15CryptAxe closed pull request #11098: [Qt] Add spend all button to the SendCoinsDialog (06master...06spendall) 02https://github.com/bitcoin/bitcoin/pull/11098
  8 2017-11-17 00:12:32	0|gmaxwell|far less == e.g. they use the inner RS code only as a checksum, and the outer only as an erasure code,  and don't do any soft-input or iteration.
  9 2017-11-17 00:16:37	0|jcorgan|i don't think the system was designed around archival, only incidental damage (scratches, etc.)
 10 2017-11-17 00:17:38	0|jcorgan|so none of the commodity write-once optical systems deal with things like fires or chemical damage, etc.
 11 2017-11-17 00:19:24	0|jcorgan|SDR/DSP is magic :-)
 12 2017-11-17 00:21:45	0|jcorgan|physical damage aside, i'm still not sure if any proper bip32 hd-wallet seed/hierarchy designs have emerged
 13 2017-11-17 00:23:41	0|gmaxwell|jonasschnelli: there are two things I'd like to talk to you about with future hardware wallet stuff.
 14 2017-11-17 00:24:22	0|gmaxwell|jonasschnelli: One of them is that we now have a scheme where the host software can protect against a hardware wallet signing maliciously in a way that leaks keys.
 15 2017-11-17 00:24:51	0|gmaxwell|jonasschnelli: perhaps you'd have some interest in implementing that. It requires an extra round trip between the host and HW wallet during signing.
 16 2017-11-17 00:25:55	0|gmaxwell|jonasschnelli: the other thing is this KDF scheme.  Basically, I want to address the problem that you want to enter a password protected seed on a hardware wallet and not expose the password or seed to an untrusted host...  but the hardware wallet does not have enough CPU power to do a meaningful KDF (the 2000 rounds in BIP39 is basically pointless)
 17 2017-11-17 00:26:42	0|gmaxwell|jonasschnelli: so I would suggest we use a scheme proposed some years ago by Adam Back that would let the host computer do the KDF grinding in zero knoweldge-- it learns nothing about the password entered on the hardware wallet.
 18 2017-11-17 00:32:25	0|sipa|link: https://bitcointalk.org/index.php?topic=311000.0
 19 2017-11-17 00:33:51	0|achow101|what does everyone think about putting various docs about things in progress and plans (e.g. sipa's wallet thing) on the wiki here: https://github.com/bitcoin-core/bitcoin-devwiki/wiki
 20 2017-11-17 00:33:59	0|achow101|that's where we did release notes things
 21 2017-11-17 00:39:53	0|sipa|achow101: without large scale effort to commit to keeping something like that up to date, i'm afraid it will very easily go outdated
 22 2017-11-17 00:40:30	0|achow101|sipa: I was thinking more of a repository to keep these writeups that morcos keeps asking for
 23 2017-11-17 00:40:44	0|sipa|ah, yes
 24 2017-11-17 00:40:47	0|achow101|to have them all in one place instead of having to search for all of them
 25 2017-11-17 00:41:02	0|sipa|any reason they couldn't be in the repo?
 26 2017-11-17 00:41:20	0|sipa|https://github.com/bitcoin-core/docs for example
 27 2017-11-17 00:41:41	0|achow101|they could be in the repo I guess
 28 2017-11-17 00:42:38	0|achow101|just somewhere that they can be easily found in one place is good enough
 29 2017-11-17 00:47:14	0|meshcollider|+1
 30 2017-11-17 02:19:00	0|bitcoin-git|[13bitcoin] 15MeshCollider opened pull request #11708: Add P2SH-P2WSH support to signrawtransaction and listunspent RPC (06master...06201711_signrawtransaction_wsh) 02https://github.com/bitcoin/bitcoin/pull/11708
 31 2017-11-17 02:20:46	0|meshcollider|validateaddress is basically an address info call isn't it
 32 2017-11-17 02:21:19	0|meshcollider|so should witnessScript and redeemScript be added to its output?
 33 2017-11-17 02:27:58	0|sipa|i believe my segwit wallet pr does that
 34 2017-11-17 02:28:05	0|sipa|or something similar at least
 35 2017-11-17 02:29:08	0|meshcollider|oh cool, thanks :)
 36 2017-11-17 06:27:15	0|achow101|meshcollider: yes, and that's why I have a PR to move most of the functionality to a new call getaddressinfo
 37 2017-11-17 06:27:41	0|meshcollider|achow101: Ah sweet, will check it out in a second
 38 2017-11-17 06:37:25	0|jonasschnelli|[14:24:20]  <gmaxwell>	jonasschnelli: One of them is that we now have a scheme where the host software can protect against a hardware wallet signing maliciously in a way that leaks keys.
 39 2017-11-17 06:37:37	0|jonasschnelli|That is not adam3us's proposal? Right?
 40 2017-11-17 06:38:25	0|sipa|jonasschnelli: https://www.reddit.com/r/Bitcoin/comments/7a7i69/electrum_30_release/dpaetyn/?context=3
 41 2017-11-17 06:39:11	0|jonasschnelli|sipa... thanks! reading...
 42 2017-11-17 06:59:03	0|jonasschnelli|sipa: so your scheme is to protect against possible malicious HWW (and or it's firmware)?
 43 2017-11-17 07:17:42	0|kallewoof|What was the configure option to enable deadlock detection stuff again?
 44 2017-11-17 07:20:06	0|kallewoof|Got it, I think... (CPPFLAGS=-DDEBUG_LOCKORDER)
 45 2017-11-17 07:44:57	0|sipa|kallewoof: indeed
 46 2017-11-17 07:45:00	0|sipa|jonasschnelli: indeed
 47 2017-11-17 07:46:40	0|jonasschnelli|For now,.. all HWW manufacturer consider the hosts/desktop as compromised.. but it's an interesting perspective (from the user) to get kind of a two factor security between HWW/Desktop
 48 2017-11-17 07:49:43	0|jonasschnelli|sipa: is that scheme: (k1+H(k2,R1))*G = k1*G+H(k2,R1)*G = R1+H(k2,R1)*G compatible with BIP32?
 49 2017-11-17 07:50:55	0|gmaxwell|it doesn't change anything about the public keys used, it changes the nonces in the signatures.
 50 2017-11-17 07:51:33	0|jonasschnelli|gmaxwell: instead of secp256k1_nonce_function_rfc6979 it would use the construction k1+H(k2,R1)?
 51 2017-11-17 07:52:29	0|jonasschnelli|interesting... the desktop could verify the signature before broadcasting.. I see
 52 2017-11-17 07:52:39	0|gmaxwell|a concern is that hw wallets may actually reduce user security, if I were an /evil/ genius, I'd start making counterfeit trezors and selling them on ebay for slightly under the normal retail price... with evil firmware on them.  Backdooring regular computers would be a waste of my resources, but backdooring a hw wallet-- I could be confident that a high percentage of my backdoored devices were g
 53 2017-11-17 07:52:45	0|gmaxwell|oing to get cryptocoins on them.
 54 2017-11-17 07:53:18	0|gmaxwell|jonasschnelli: yes, the hw wallet sends the original R to the desktop and it can verify.  If the HW wallet did something malicious it couldn't get its malicious effect further than the desktop.
 55 2017-11-17 07:54:17	0|gmaxwell|So a backdoored HW wallet would only compromise the user (1) through orignial key generation, if it does that (user can avoid by rolling dice or something for the key),  or (2) with the cooperation of the desktop; which an evil party selling backdoored hardware wallets hopefully wouldn't have.
 56 2017-11-17 07:54:31	0|jonasschnelli|How Digital Bitbox wanted to prevent from that attack was by proving the device authenticity by signing arbitraty data via the HWW device and have the signature verified. But that security model is based on obscurity of the auth-private key inside the device
 57 2017-11-17 07:54:42	0|gmaxwell|at least in that kind of setup a HW wallet couldn't make you less secure than your desktop alone.
 58 2017-11-17 07:55:09	0|gmaxwell|jonasschnelli: right, which could be compromised, and it doesn't help against bad firmware being made at the maker.
 59 2017-11-17 07:55:36	0|gmaxwell|or something like making the compromised devices out of legitimate ones... where it just passes through the tamper detect to the original hardware but intercepts the rest.
 60 2017-11-17 07:55:38	0|jonasschnelli|gmaxwell: bad firmware can't be installed because the bootloader only accepts signed firmware
 61 2017-11-17 07:56:43	0|jonasschnelli|In the case of proving authenticity with a pinned private key in the device,.. this can be made relatively secure when using a EPROM chip with physical extraction measurements
 62 2017-11-17 07:57:01	0|jonasschnelli|It's as hard to extract as the seed on the device
 63 2017-11-17 07:57:58	0|jonasschnelli|But I'd say both schemes should be implemented == more security
 64 2017-11-17 07:58:25	0|sipa|well this protects against the case where the device creator is complicit
 65 2017-11-17 08:02:17	0|jonasschnelli|sipa: Indeed...
 66 2017-11-17 08:03:14	0|jonasschnelli|sipa: those key-exchanges would have to be made for each single private key (input)?
 67 2017-11-17 08:07:41	0|jonasschnelli|One downside: ability to use the HWW on any (untrusted) computer or cellphone ( == portability) would be lost.
 68 2017-11-17 08:08:06	0|gmaxwell|why?
 69 2017-11-17 08:09:29	0|sipa|heh?
 70 2017-11-17 08:11:47	0|jonasschnelli|gmaxwell: sipa: maybe I'm not getting it. Is the key exchange only used for the nonce?
 71 2017-11-17 08:11:55	0|sipa|yes
 72 2017-11-17 08:12:07	0|sipa|at signing time
 73 2017-11-17 08:15:15	0|jonasschnelli|sipa: it would only protect from leaking private key via signatures?
 74 2017-11-17 08:15:47	0|sipa|yes
 75 2017-11-17 08:16:13	0|jonasschnelli|What one probably wants is a security that the device have signed the data it has displayed on the device screen... I guess that hard to achieve
 76 2017-11-17 08:18:03	0|jonasschnelli|But if we assume the host is not fully compromised, then this is not a big deal...
 77 2017-11-17 08:20:26	0|jonasschnelli|Example: Trezor is backdoored. You sign "Send 1 BTC to Bob" (verified with Trezor screen), while it actually signs "Send 1 BTC to Malory". Because your using the online Trezor wallet, it would go undetected.
 78 2017-11-17 08:23:59	0|jonasschnelli|sipa: Thanks for that proposal.. I think that is something the Digital Bitbox guys will implement in the next (hardware) version!
 79 2017-11-17 08:24:13	0|gmaxwell|well that wouldn't be detected if the host checks the resulting transaction and isn't compromised.
 80 2017-11-17 08:24:23	0|jonasschnelli|I'm just worries how easy it is to screw up the implementation. :)
 81 2017-11-17 08:25:04	0|jonasschnelli|gmaxwell: the problem is, users just love this browser based apps!.. they are so easy to compromise IMO
 82 2017-11-17 08:27:14	0|jonasschnelli|gmaxwell, sipa: by looking at a signature, is it impossible to say wether it has used RFC6979 or if it leaks potential key material?
 83 2017-11-17 08:27:22	0|gmaxwell|sure, if the everything the user has is compromised you're out of luck.
 84 2017-11-17 08:27:36	0|gmaxwell|jonasschnelli: right you cannot tell.
 85 2017-11-17 08:28:01	0|jonasschnelli|gmaxwell: So there is a change that plenty of public signatures leak key material and that someone may have already collected those keys?
 86 2017-11-17 08:28:12	0|gmaxwell|Yes, sure.
 87 2017-11-17 08:28:27	0|jonasschnelli|I never thought of this... interesting
 88 2017-11-17 08:28:37	0|gmaxwell|I think we haven't seen attacks like this because it is not (yet) a low hanging fruit.
 89 2017-11-17 08:28:54	0|gmaxwell|Why bother understanding crypto when you can send the user an email that says "click here, you just won a free monkey."
 90 2017-11-17 08:29:24	0|gmaxwell|and the user says "oh hey, I like monkies."  and then all their bitcoins are gone, no signature trickery required.
 91 2017-11-17 08:31:03	0|midnightmagic|I want a free monkey!
 92 2017-11-17 08:31:04	0|jonasschnelli|haha
 93 2017-11-17 08:31:45	0|jonasschnelli|I mean consider the fact that (I think so) Ledger does program their devices in china... they could have implemented that "change"
 94 2017-11-17 08:32:11	0|jonasschnelli|Although a firmware upgrade / verification would reveal that
 95 2017-11-17 08:33:05	0|jonasschnelli|gmaxwell: If you self-compile (and have verified that it uses RFC6979) the firmware, you are pretty safe from that attack? right?
 96 2017-11-17 08:33:20	0|gmaxwell|how can you tell if it's using the code you think it is?
 97 2017-11-17 08:33:30	0|wumpus|yes, the new malware going around on facebook seems to be more subtle psychology than free monkies, "hey I found a video of you", in which the link infects with a malware and auto-sends it to the other friends
 98 2017-11-17 08:33:33	0|jonasschnelli|gmaxwell: self compile it?
 99 2017-11-17 08:33:52	0|jonasschnelli|gmaxwell: aha.. I see
100 2017-11-17 08:33:53	0|wumpus|so many ways to manipulate people into clicking links, even those that don't like free monkeys :)
101 2017-11-17 08:34:44	0|wumpus|if something like that would include a wallet grabber it'd be pretty terrible
102 2017-11-17 08:39:51	0|gmaxwell|jonasschnelli: if you have signed messages and the private key you can tell if 6979 was used by recomputing the nonces yourself, but thats not a useful way to secure a hardware wallet, since the point is to not have the private key laying around. :P  just testing once isn't good enough since an evil wallet could use 6979 for the first N uses or whatnot.
103 2017-11-17 08:41:17	0|jonasschnelli|gmaxwell: At least a special HWW function could recompute all your signatures and the desktop app could verify it agains the public ones...
104 2017-11-17 08:42:18	0|jonasschnelli|I really like the "nonce-leak-prevention"... the cost the implementation if worth the +security one can get
105 2017-11-17 08:42:28	0|jonasschnelli|*is worth
106 2017-11-17 08:42:45	0|jonasschnelli|And IMO there is no UX costs (if done right=
107 2017-11-17 08:43:01	0|gmaxwell|yes, no ux cost, just a little more data between the signer and host.
108 2017-11-17 08:43:12	0|gmaxwell|and some software.
109 2017-11-17 08:43:43	0|jonasschnelli|gmaxwell, sipa: are you going to write a proposal?
110 2017-11-17 08:44:42	0|jonasschnelli|Or is that (https://www.reddit.com/r/Bitcoin/comments/7a7i69/electrum_30_release/dpaetyn/?context=3=) the proposal?
111 2017-11-17 08:51:42	0|wumpus|you're not in the CH timezone are you jonasschnelli :)
112 2017-11-17 09:06:34	0|promag|wumpus: and you?
113 2017-11-17 09:06:54	0|wumpus|I am
114 2017-11-17 09:07:06	0|promag|Heh
115 2017-11-17 09:07:27	0|wumpus|it's morning here
116 2017-11-17 09:48:50	0|wumpus|sigh @ #11466, I hate when something went through a review cycle and it's almost ready for merge
117 2017-11-17 09:48:53	0|gribble|https://github.com/bitcoin/bitcoin/issues/11466 | Specify custom wallet directory with -walletdir param by MeshCollider · Pull Request #11466 · bitcoin/bitcoin · GitHub
118 2017-11-17 09:49:05	0|wumpus|then people come up with "you should do it like this instead"
119 2017-11-17 09:49:18	0|meshcollider|Yeah haha
120 2017-11-17 09:49:31	0|meshcollider|wumpus: I'll rebase it now
121 2017-11-17 09:49:32	0|wumpus|I know it's well meant, but it's no way to cooporate
122 2017-11-17 09:50:08	0|meshcollider|General consensus is that its fine as-is though I think, based on the feedback #11687 got
123 2017-11-17 09:50:10	0|gribble|https://github.com/bitcoin/bitcoin/issues/11687 | External wallet files by ryanofsky · Pull Request #11687 · bitcoin/bitcoin · GitHub
124 2017-11-17 09:50:11	0|wumpus|users have been requesting a way to store their wallets somewhere else for ages
125 2017-11-17 09:50:33	0|meshcollider|Yeah and IMO its not safe enough to start separating them all over the show yet
126 2017-11-17 09:50:41	0|wumpus|so let's just add it, we can always add another mechanism later (then walletdir will just be the *default* wallet directory)
127 2017-11-17 09:53:26	0|wumpus|meshcollider: I agree, the other approach just isn't ready yet
128 2017-11-17 09:53:36	0|wumpus|and having a default wallet directory is useful too.
129 2017-11-17 09:55:38	0|wumpus|meshcollider: yes please rebase, I hope I've saved your PR :)
130 2017-11-17 09:56:57	0|wumpus|I'll help testing it
131 2017-11-17 09:57:37	0|meshcollider|wumpus: rebased, thanks :)
132 2017-11-17 10:23:27	0|meshcollider|Ah 1 sec there has been a change to walletbackup.py which I need to fix
133 2017-11-17 10:36:12	0|wumpus|no hurry...
134 2017-11-17 10:37:11	0|meshcollider|Yep travis is passing now, let me know if you want me to squash the last commit into "Create walletdir if datadir doesn't exist and fix tests"
135 2017-11-17 11:05:09	0|wumpus|meshcollider: seems to work as expected here
136 2017-11-17 11:07:39	0|wumpus|I'd hold off on the squashing, still reviewing/testing
137 2017-11-17 11:08:05	0|meshcollider|wumpus: Okay
138 2017-11-17 11:11:48	0|wumpus|I hopefully got someone else to test it as well
139 2017-11-17 11:16:03	0|wumpus|the only problem with getting testers is that people tend to want it on top of 0.15.x, but if it's relevant for backport at all it makes no sense to do so before it's merged into master
140 2017-11-17 11:45:30	0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/99bc0b428b03...41221126c855
141 2017-11-17 11:45:31	0|bitcoin-git|13bitcoin/06master 146e4cdd6 15James O'Beirne: [docs] Add reference to install_db4.sh in OS X build instructions
142 2017-11-17 11:45:31	0|bitcoin-git|13bitcoin/06master 14af9103e 15James O'Beirne: [build] Add a script for installing db4...
143 2017-11-17 11:45:32	0|bitcoin-git|13bitcoin/06master 144122112 15Wladimir J. van der Laan: Merge #11702: [build] Add a script for installing db4...
144 2017-11-17 11:46:07	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11702: [build] Add a script for installing db4 (06master...06install-db4-script) 02https://github.com/bitcoin/bitcoin/pull/11702
145 2017-11-17 11:46:12	0|meshcollider|wumpus: Alright I'm heading to bed now, if you want I can squash the commits now or just do it tomorrow
146 2017-11-17 11:46:41	0|wumpus|I'm finished with it, ok with me to squash nwo
147 2017-11-17 11:47:32	0|wumpus|I'll ACK
148 2017-11-17 11:52:27	0|meshcollider|wumpus: done, thanks :)
149 2017-11-17 12:08:07	0|bitcoin-git|13bitcoin/06master 14446e261 15practicalswift: [qt] Fix potential memory leak in newPossibleKey(ChangeCWallet *wallet)
150 2017-11-17 12:08:07	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/41221126c855...f6f8d54aff34
151 2017-11-17 12:08:08	0|bitcoin-git|13bitcoin/06master 14f6f8d54 15Wladimir J. van der Laan: Merge #10920: [qt] Fix potential memory leak in newPossibleKey(ChangeCWallet *wallet)...
152 2017-11-17 12:08:22	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10920: [qt] Fix potential memory leak in newPossibleKey(ChangeCWallet *wallet) (06master...06fix-newPossibleKeyChange-memory-leak) 02https://github.com/bitcoin/bitcoin/pull/10920
153 2017-11-17 12:17:52	0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/f6f8d54aff34...ccc70a295fc5
154 2017-11-17 12:17:53	0|bitcoin-git|13bitcoin/06master 14f9cd9b1 15John Newbery: [tests] Move test_framework Bitcoin primitives into separate module...
155 2017-11-17 12:17:54	0|bitcoin-git|13bitcoin/06master 141135c79 15John Newbery: [tests] Tidy up mininode.py module...
156 2017-11-17 12:17:54	0|bitcoin-git|13bitcoin/06master 14ccc70a2 15Wladimir J. van der Laan: Merge #11648: [tests] Add messages.py...
157 2017-11-17 12:18:22	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11648: [tests] Add messages.py (06master...06add_primitives_py) 02https://github.com/bitcoin/bitcoin/pull/11648
158 2017-11-17 12:31:29	0|promag|wumpus: are you going to merge #11466?
159 2017-11-17 12:31:32	0|gribble|https://github.com/bitcoin/bitcoin/issues/11466 | Specify custom wallet directory with -walletdir param by MeshCollider · Pull Request #11466 · bitcoin/bitcoin · GitHub
160 2017-11-17 12:32:05	0|wumpus|promag: I intend to, but would prefer if it gets stilll some more testing of course
161 2017-11-17 12:32:27	0|promag|I was planning to test it after lunch
162 2017-11-17 12:33:10	0|wumpus|great!
163 2017-11-17 12:33:34	0|promag|ok
164 2017-11-17 12:34:47	0|wumpus|I just tested it quite extensively as I was the person to propose the change in the first place, but I didn't try e.g. multiwallet things (though I don't see why there'd be an issue)
165 2017-11-17 12:37:21	0|wumpus|but could always be some edge case
166 2017-11-17 12:55:48	0|fanquake|Hope that wasn't too rude #11709
167 2017-11-17 12:55:49	0|gribble|https://github.com/bitcoin/bitcoin/issues/11709 | issue : Message store directory does not exist · Issue #11709 · bitcoin/bitcoin · GitHub
168 2017-11-17 12:57:38	0|wumpus|fanquake: no, your response is clear and to the point, he's on his own there, we can't provide support for all the gazilion forks
169 2017-11-17 12:58:27	0|wumpus|and if he's able to use git enough to trace it back to our repository he's also able to find the person that made the relevant change for his altcoin...
170 2017-11-17 13:00:14	0|wumpus|I get loads of mail about altcoins as well because my mail is in the git log so often
171 2017-11-17 13:01:34	0|fanquake|Yea, I seem to get random messages on Twitter all the time. Get a few emails as well.
172 2017-11-17 13:02:38	0|fanquake|#11621 Should be able to go in now
173 2017-11-17 13:02:39	0|gribble|https://github.com/bitcoin/bitcoin/issues/11621 | [build] Add temp_bitcoin_locale_qrc to CLEAN_QT to fix make distcheck by fanquake · Pull Request #11621 · bitcoin/bitcoin · GitHub
174 2017-11-17 13:03:55	0|fanquake|I might fixup 11222 over the weekend, and the original author doesn't seem to have time for it.
175 2017-11-17 13:03:59	0|wumpus|fanquake: thanks
176 2017-11-17 13:04:32	0|bitcoin-git|13bitcoin/06master 14a7c949f 15fanquake: [build] Add temp_bitcoin_locale_qrc to CLEAN_QT to fix make distcheck
177 2017-11-17 13:04:32	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/ccc70a295fc5...1f7695b4194b
178 2017-11-17 13:04:33	0|bitcoin-git|13bitcoin/06master 141f7695b 15Wladimir J. van der Laan: Merge #11621: [build] Add temp_bitcoin_locale_qrc to CLEAN_QT to fix make distcheck...
179 2017-11-17 13:05:02	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11621: [build] Add temp_bitcoin_locale_qrc to CLEAN_QT to fix make distcheck (06master...06fix-osx-distcheck) 02https://github.com/bitcoin/bitcoin/pull/11621
180 2017-11-17 13:05:43	0|wumpus|fanquake: my reply there was a last ping, if he doesn't reply or pick it up again I'll close and add a 'up for grabs' label. But yes feel free to pick it up if it's worth doing so :)
181 2017-11-17 13:08:26	0|wumpus|apparently I stumbled on the issue exactly a month after cfields' last comment
182 2017-11-17 13:09:34	0|fanquake|heh, it's easy for PRs to sit and idle for a long time. Little burst of activity and interest, and then it gets a few rebases out of date, or too far buried in the stream of new PRs
183 2017-11-17 13:13:25	0|fanquake|wumpus Thoughts on new PGP key additions? A few recently seem to be submitting their keys for addition before they've even gitian built. There's not really a rule about adding them?
184 2017-11-17 13:14:21	0|fanquake|I think jonass is right in that there are so few builders you don't want to turn anyone away. Keys can also easily be removed later on.
185 2017-11-17 13:14:56	0|wumpus|fanquake: that tends to happen, it's quite common for open source projects, especially busy ones. Though it can be sad if a certain PR gets no review interest at all, e.g. #10994
186 2017-11-17 13:14:58	0|gribble|https://github.com/bitcoin/bitcoin/issues/10994 | Add option to avoid warning on certain network upgrades by ajtowns · Pull Request #10994 · bitcoin/bitcoin · GitHub
187 2017-11-17 13:15:27	0|wumpus|fanquake: we currently have no rules for that, because addition was so rare
188 2017-11-17 13:15:42	0|wumpus|fanquake: I think we should have rules for expiration, remove the key if someone isn't gitian building anymore for e.g. a year
189 2017-11-17 13:16:03	0|wumpus|fanquake: but not for addition so much, if people can gitian build at this point they're awesome
190 2017-11-17 13:16:17	0|wumpus|fanquake: and he's proven he could do it at least once :)
191 2017-11-17 13:16:51	0|fanquake|Indeed https://github.com/bitcoin-core/gitian.sigs/graphs/contributors isn't a long list. Plenty of people in there that haven't built recently as well.
192 2017-11-17 13:17:10	0|wumpus|yes, even expiration might be overkill at this point, it's just not so much of an issue
193 2017-11-17 13:17:24	0|wumpus|not like the repository is getting cluttered with them
194 2017-11-17 13:17:31	0|fanquake|I think the fact that the build process is so much *easier* now is great. Can remember I struggled to get it working for a while.
195 2017-11-17 13:18:40	0|fanquake|Guess #11700 can go in then. If no-one objects.
196 2017-11-17 13:18:42	0|gribble|https://github.com/bitcoin/bitcoin/issues/11700 | Add gitian PGP key: willyko by willyko · Pull Request #11700 · bitcoin/bitcoin · GitHub
197 2017-11-17 13:19:32	0|wumpus|agree
198 2017-11-17 13:20:09	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/1f7695b4194b...595ec11d804f
199 2017-11-17 13:20:10	0|bitcoin-git|13bitcoin/06master 14595ec11 15Wladimir J. van der Laan: Merge #11700: Add gitian PGP key: willyko...
200 2017-11-17 13:20:10	0|bitcoin-git|13bitcoin/06master 14f88d900 15Willy Ko: Add gitian PGP key: willyko
201 2017-11-17 13:20:36	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11700: Add gitian PGP key: willyko (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/11700
202 2017-11-17 13:21:32	0|bitcoin-git|[13bitcoin] 15laanwj opened pull request #11710: cli: Reject arguments to -getinfo (06master...062017_11_getinfo_args) 02https://github.com/bitcoin/bitcoin/pull/11710
203 2017-11-17 13:25:45	0|fanquake|I think #11704 should be ok now. If sipsorcery is committed to getting the Windows build side of things in order, that'll be good.
204 2017-11-17 13:25:46	0|gribble|https://github.com/bitcoin/bitcoin/issues/11704 | Windows build doc update by sipsorcery · Pull Request #11704 · bitcoin/bitcoin · GitHub
205 2017-11-17 13:26:15	0|wumpus|fanquake: it's great to have someone working on that
206 2017-11-17 13:28:57	0|wumpus|I'm going to edit his commit message a bit before merging, he put everything in the subject line
207 2017-11-17 13:32:47	0|bitcoin-git|13bitcoin/06master 141cecea7 15Aaron Clauson: doc: Specify required source location for Windows WSL builds...
208 2017-11-17 13:32:47	0|bitcoin-git|13bitcoin/06master 14ea68190 15Wladimir J. van der Laan: Merge #11704: Windows build doc update...
209 2017-11-17 13:32:47	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/595ec11d804f...ea68190132b2
210 2017-11-17 13:33:12	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11704: Windows build doc update (06master...06windoc) 02https://github.com/bitcoin/bitcoin/pull/11704
211 2017-11-17 13:42:53	0|fanquake|Still not sure about #11526 though. We had discussions about this with an Xcode project a while ago. Ended up in a separate repository, doesn't look like it lasted too long.
212 2017-11-17 13:42:55	0|gribble|https://github.com/bitcoin/bitcoin/issues/11526 | Visual Studio build configuration for Bitcoin Core. by sipsorcery · Pull Request #11526 · bitcoin/bitcoin · GitHub
213 2017-11-17 13:44:52	0|wumpus|I don't know either. I like the idea of making MSVC build easier, but I don't want to expect from people to maintain two build systems when e.g. adding a file.
214 2017-11-17 13:45:33	0|wumpus|certainly not one that only runs on one platform
215 2017-11-17 13:46:40	0|wumpus|I'm ok with merging it though, the author committed to maintaining MSVC support
216 2017-11-17 13:47:42	0|fanquake|There are some other PRs that need merging first. To fix compilation issues, and "a tonne of warnings" apparently. Should probably get those in fix at least, and see what other issues they turn up. If any.
217 2017-11-17 13:48:02	0|fanquake|Mostly in #11558
218 2017-11-17 13:48:03	0|gribble|https://github.com/bitcoin/bitcoin/issues/11558 | Minimal code changes to allow msvc compilation by sipsorcery · Pull Request #11558 · bitcoin/bitcoin · GitHub
219 2017-11-17 13:48:58	0|fanquake|Corys comment re #11196 should get a look too I think
220 2017-11-17 13:49:01	0|gribble|https://github.com/bitcoin/bitcoin/issues/11196 | Switch memory_cleanse implementation to BoringSSLs to ensure memory clearing even with -lto by maaku · Pull Request #11196 · bitcoin/bitcoin · GitHub
221 2017-11-17 13:49:24	0|fanquake|https://github.com/bitcoin/bitcoin/pull/11196#discussion_r137124417
222 2017-11-17 14:00:04	0|wumpus|#11558 is pretty much ready, though I agree with cfields' last comment
223 2017-11-17 14:00:06	0|gribble|https://github.com/bitcoin/bitcoin/issues/11558 | Minimal code changes to allow msvc compilation by sipsorcery · Pull Request #11558 · bitcoin/bitcoin · GitHub
224 2017-11-17 14:00:19	0|wumpus|we should keep the compat header out of the headers
225 2017-11-17 14:01:23	0|bitcoin-git|13bitcoin/06master 14e89adba 15Matt Corallo: Make default issue text all comments to make issues more readable
226 2017-11-17 14:01:23	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/ea68190132b2...5197100704b8
227 2017-11-17 14:01:24	0|bitcoin-git|13bitcoin/06master 145197100 15Wladimir J. van der Laan: Merge #11706: Make default issue text all comments to make issues more readable...
228 2017-11-17 14:01:48	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11706: Make default issue text all comments to make issues more readable (06master...062017-11-shorter-default-issue-redux) 02https://github.com/bitcoin/bitcoin/pull/11706
229 2017-11-17 14:02:33	0|fanquake|Hopefully now the first line I'll see in issue emails will actually contain some information, rather than 99% of the time it being the template text.
230 2017-11-17 14:03:15	0|wumpus|oh yes that's annoying, almost everyone just kept the template text there, usually without even paying attention to it
231 2017-11-17 14:04:03	0|wumpus|I certainly understand why some bug reporting systems (e.g. bugzilla) make people fill in a form, instead of just offering a free text field
232 2017-11-17 14:04:56	0|fanquake|It's a trade off between capturing everything, and missing some obscure bug being reported by an unmotivated passer by
233 2017-11-17 14:04:58	0|wumpus|a template is apparently not a working substitute for that, well who knows, maybe BlueMatt's cleanups improve it
234 2017-11-17 14:05:22	0|wumpus|yes
235 2017-11-17 14:10:25	0|fanquake|wumpus trivial merge or close? #11140
236 2017-11-17 14:10:27	0|gribble|https://github.com/bitcoin/bitcoin/issues/11140 | Trivial: Improve #endif comments by danra · Pull Request #11140 · bitcoin/bitcoin · GitHub
237 2017-11-17 14:27:35	0|bitcoin-git|[13bitcoin] 15fanquake opened pull request #11711: bitcoin_qt.m4: Minor fixes and clean-ups. (06master...06bitcoin-qt-m4-cleanup) 02https://github.com/bitcoin/bitcoin/pull/11711
238 2017-11-17 14:28:01	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #11222: bitcoin_qt.m4: Minor fixes and clean-ups. (06master...06config-fixes) 02https://github.com/bitcoin/bitcoin/pull/11222
239 2017-11-17 14:28:16	0|promag|I would say meh to 11140
240 2017-11-17 14:29:26	0|promag|the blocks are so small I would remove the comments, repeating the condition is kind of unnecessary there
241 2017-11-17 14:33:42	0|wumpus|well he has a point w/ mentioning ==0, and it has an ACK so meh, i'm just going to merge it
242 2017-11-17 14:34:38	0|wumpus|promag: agree that the blocks are so small that mentinoing the condition on the endif is not necessary in the first place
243 2017-11-17 14:34:48	0|wumpus|but it's there, so it should be correct...
244 2017-11-17 14:35:17	0|fanquake|just merge it then heh
245 2017-11-17 14:35:18	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/5197100704b8...142913296f00
246 2017-11-17 14:35:19	0|bitcoin-git|13bitcoin/06master 141429132 15Wladimir J. van der Laan: Merge #11140: Trivial: Improve #endif comments...
247 2017-11-17 14:35:19	0|bitcoin-git|13bitcoin/06master 14ac1cf8d 15danra: Trivial: Improve #endif comments...
248 2017-11-17 14:35:19	0|promag|yes, at the moment the comment is misleading
249 2017-11-17 14:35:31	0|promag|hence the meh
250 2017-11-17 14:35:44	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11140: Trivial: Improve #endif comments (06master...06patch-4) 02https://github.com/bitcoin/bitcoin/pull/11140
251 2017-11-17 14:37:25	0|fanquake|wumpus looking in byteswap, does the protobuf check affect your work in 11622 at all?
252 2017-11-17 14:37:28	0|promag|wumpus: regarding #11466
253 2017-11-17 14:37:31	0|gribble|https://github.com/bitcoin/bitcoin/issues/11466 | Specify custom wallet directory with -walletdir param by MeshCollider · Pull Request #11466 · bitcoin/bitcoin · GitHub
254 2017-11-17 14:37:57	0|promag|first time run is doesn't use -walletdir right?
255 2017-11-17 14:37:58	0|fanquake|I assume not looking at the comments, if the behaviour is assumed to be the same in either case
256 2017-11-17 14:38:32	0|wumpus|fanquake: I think it's harmless to run it, though maybe unnecessary, I don't know
257 2017-11-17 14:38:59	0|wumpus|fanquake: the test is there to check if there is a collision between protobuf and our bswap primitives, so it will always pass if protobuf is not included
258 2017-11-17 14:39:26	0|wumpus|promag: you mean when it's run when the datadir doesn't exist yet?
259 2017-11-17 14:39:32	0|promag|yes
260 2017-11-17 14:39:42	0|wumpus|promag: that would be bad, let's see
261 2017-11-17 14:39:50	0|promag|it's building here so..
262 2017-11-17 14:57:07	0|promag|wumpus: it creates datadir/wallets but uses the provided -walletdir
263 2017-11-17 14:57:15	0|wumpus|promag: yep, that's expected
264 2017-11-17 14:58:25	0|wumpus|promag: there was earlier discussion about that: https://github.com/bitcoin/bitcoin/pull/11466#discussion_r150251905
265 2017-11-17 14:59:45	0|wumpus|not creating all new data directories (including when running without wallets) with a wallets subdirectory would enormously complicate things
266 2017-11-17 15:01:20	0|promag|yes I saw that. But here I've provided -walletdir no there's no need (and no harm) creating datadir/wallets
267 2017-11-17 15:01:36	0|wumpus|it should still be created if you want to run without -walletdir later
268 2017-11-17 15:01:54	0|wumpus|because if not it's too late - it's no longer a new data directory, so it will use legacy layout
269 2017-11-17 15:02:32	0|promag|right
270 2017-11-17 15:02:42	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #9737: Don't disconnect feeler connections prematurely (06master...06ServicesIrrelevantForFeelerConnections) 02https://github.com/bitcoin/bitcoin/pull/9737
271 2017-11-17 15:02:47	0|promag|btw, why not validate walletdir before intro?
272 2017-11-17 15:03:12	0|promag|edge case?
273 2017-11-17 15:03:17	0|wumpus|it's a bit tricky but I think it's the most straightforward and easy to verify way to do this
274 2017-11-17 15:03:47	0|wumpus|promag: doing things before intro is extremely difficult
275 2017-11-17 15:04:09	0|wumpus|e.g. bitcoin.conf hasn't been read yet
276 2017-11-17 15:04:29	0|wumpus|nor have per-network GUI settings
277 2017-11-17 15:04:43	0|wumpus|so if you'd validate walletdir before intro, you'd miss it if it's provided in bitcoin.conf
278 2017-11-17 15:04:44	0|promag|btw, if -walletdir points to a file, the error is still "Error: Specified wallet directory "/Users/promag/foo2" does not exist."
279 2017-11-17 15:05:01	0|wumpus|that could use a clearer error
280 2017-11-17 15:10:22	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #10172: Fix opt-in RBF reliance on compiler integer size (06master...06rbf-numlimits-fix) 02https://github.com/bitcoin/bitcoin/pull/10172
281 2017-11-17 15:13:32	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #10702: [Trivial] Improve end-of-namespace comment consistency (06master...06improve-end-of-namespace-comment-consistence) 02https://github.com/bitcoin/bitcoin/pull/10702
282 2017-11-17 15:35:01	0|promag|https://github.com/bitcoin/bitcoin/pull/11648#discussion_r151709875
283 2017-11-17 15:35:16	0|promag|MarcoFalke: just a question, I saw the moveonly
284 2017-11-17 15:35:42	0|promag|now it can be cleaned right?
285 2017-11-17 15:40:53	0|wumpus|promag: sure
286 2017-11-17 15:58:55	0|MarcoFalke|promag: Not sure if that single change warrants a pull on its own
287 2017-11-17 16:00:24	0|MarcoFalke|I'd prefer if is cleaned up when the function is touched by other reasons. Though, no strong opinion. Just -0
288 2017-11-17 17:53:26	0|meshcollider|wumpus: re net-specific walletdir subdirectories, what do you think of it just using them if they exist, but defaulting to root dir (so the user has to create the subdirectories themselves if they want them)
289 2017-11-17 17:54:14	0|meshcollider|Would be a much simpler change I think
290 2017-11-17 18:35:11	0|jonasschnelli|wumpus: yeah. Not in CH timezone. Right now in Hawaii
291 2017-11-17 20:12:34	0|jonasschnelli|is there a quick way to compile without tests (without re-configure)? I wish i could speed up compile time of pull requests for a quick test...
292 2017-11-17 20:12:48	0|jonasschnelli|compile time is a main show stopper for testing pulls
293 2017-11-17 20:13:03	0|BlueMatt|jonasschnelli: make src/bitcoind (or maybe its just make bitcoind?)
294 2017-11-17 20:13:57	0|jonasschnelli|BlueMatt: hmm.. yes. That could work (now all pre-built,.. need to test with a new PR)
295 2017-11-17 21:47:52	0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #11712: [tests] Split NodeConn from NodeConnCB (06master...06split_nodeconn) 02https://github.com/bitcoin/bitcoin/pull/11712