< 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.
< 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.
< 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.
< jcorgan> "If it isn't backed up in three different ways and stored in three different places, it is already lost."
< gmaxwell> yea, thanks for the pointer.
< 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).
< bitcoin-git> [bitcoin] CryptAxe closed pull request #11098: [Qt] Add spend all button to the SendCoinsDialog (master...spendall) https://github.com/bitcoin/bitcoin/pull/11098
< 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.
< jcorgan> i don't think the system was designed around archival, only incidental damage (scratches, etc.)
< jcorgan> so none of the commodity write-once optical systems deal with things like fires or chemical damage, etc.
< jcorgan> SDR/DSP is magic :-)
< jcorgan> physical damage aside, i'm still not sure if any proper bip32 hd-wallet seed/hierarchy designs have emerged
< gmaxwell> jonasschnelli: there are two things I'd like to talk to you about with future hardware wallet stuff.
< 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.
< 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.
< 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)
< 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.
< 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
< achow101> that's where we did release notes things
< 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
< achow101> sipa: I was thinking more of a repository to keep these writeups that morcos keeps asking for
< sipa> ah, yes
< achow101> to have them all in one place instead of having to search for all of them
< sipa> any reason they couldn't be in the repo?
< achow101> they could be in the repo I guess
< achow101> just somewhere that they can be easily found in one place is good enough
< meshcollider> +1
< bitcoin-git> [bitcoin] MeshCollider opened pull request #11708: Add P2SH-P2WSH support to signrawtransaction and listunspent RPC (master...201711_signrawtransaction_wsh) https://github.com/bitcoin/bitcoin/pull/11708
< meshcollider> validateaddress is basically an address info call isn't it
< meshcollider> so should witnessScript and redeemScript be added to its output?
< sipa> i believe my segwit wallet pr does that
< sipa> or something similar at least
< meshcollider> oh cool, thanks :)
< achow101> meshcollider: yes, and that's why I have a PR to move most of the functionality to a new call getaddressinfo
< meshcollider> achow101: Ah sweet, will check it out in a second
< 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.
< jonasschnelli> That is not adam3us's proposal? Right?
< jonasschnelli> sipa... thanks! reading...
< jonasschnelli> sipa: so your scheme is to protect against possible malicious HWW (and or it's firmware)?
< kallewoof> What was the configure option to enable deadlock detection stuff again?
< kallewoof> Got it, I think... (CPPFLAGS=-DDEBUG_LOCKORDER)
< sipa> kallewoof: indeed
< sipa> jonasschnelli: indeed
< 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
< jonasschnelli> sipa: is that scheme: (k1+H(k2,R1))*G = k1*G+H(k2,R1)*G = R1+H(k2,R1)*G compatible with BIP32?
< gmaxwell> it doesn't change anything about the public keys used, it changes the nonces in the signatures.
< jonasschnelli> gmaxwell: instead of secp256k1_nonce_function_rfc6979 it would use the construction k1+H(k2,R1)?
< jonasschnelli> interesting... the desktop could verify the signature before broadcasting.. I see
< 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
< gmaxwell> oing to get cryptocoins on them.
< 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.
< 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.
< 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
< gmaxwell> at least in that kind of setup a HW wallet couldn't make you less secure than your desktop alone.
< gmaxwell> jonasschnelli: right, which could be compromised, and it doesn't help against bad firmware being made at the maker.
< 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.
< jonasschnelli> gmaxwell: bad firmware can't be installed because the bootloader only accepts signed firmware
< 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
< jonasschnelli> It's as hard to extract as the seed on the device
< jonasschnelli> But I'd say both schemes should be implemented == more security
< sipa> well this protects against the case where the device creator is complicit
< jonasschnelli> sipa: Indeed...
< jonasschnelli> sipa: those key-exchanges would have to be made for each single private key (input)?
< jonasschnelli> One downside: ability to use the HWW on any (untrusted) computer or cellphone ( == portability) would be lost.
< gmaxwell> why?
< sipa> heh?
< jonasschnelli> gmaxwell: sipa: maybe I'm not getting it. Is the key exchange only used for the nonce?
< sipa> yes
< sipa> at signing time
< jonasschnelli> sipa: it would only protect from leaking private key via signatures?
< sipa> yes
< 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
< jonasschnelli> But if we assume the host is not fully compromised, then this is not a big deal...
< 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.
< jonasschnelli> sipa: Thanks for that proposal.. I think that is something the Digital Bitbox guys will implement in the next (hardware) version!
< gmaxwell> well that wouldn't be detected if the host checks the resulting transaction and isn't compromised.
< jonasschnelli> I'm just worries how easy it is to screw up the implementation. :)
< jonasschnelli> gmaxwell: the problem is, users just love this browser based apps!.. they are so easy to compromise IMO
< 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?
< gmaxwell> sure, if the everything the user has is compromised you're out of luck.
< gmaxwell> jonasschnelli: right you cannot tell.
< jonasschnelli> gmaxwell: So there is a change that plenty of public signatures leak key material and that someone may have already collected those keys?
< gmaxwell> Yes, sure.
< jonasschnelli> I never thought of this... interesting
< gmaxwell> I think we haven't seen attacks like this because it is not (yet) a low hanging fruit.
< gmaxwell> Why bother understanding crypto when you can send the user an email that says "click here, you just won a free monkey."
< gmaxwell> and the user says "oh hey, I like monkies." and then all their bitcoins are gone, no signature trickery required.
< midnightmagic> I want a free monkey!
< jonasschnelli> haha
< jonasschnelli> I mean consider the fact that (I think so) Ledger does program their devices in china... they could have implemented that "change"
< jonasschnelli> Although a firmware upgrade / verification would reveal that
< jonasschnelli> gmaxwell: If you self-compile (and have verified that it uses RFC6979) the firmware, you are pretty safe from that attack? right?
< gmaxwell> how can you tell if it's using the code you think it is?
< 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
< jonasschnelli> gmaxwell: self compile it?
< jonasschnelli> gmaxwell: aha.. I see
< wumpus> so many ways to manipulate people into clicking links, even those that don't like free monkeys :)
< wumpus> if something like that would include a wallet grabber it'd be pretty terrible
< 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.
< jonasschnelli> gmaxwell: At least a special HWW function could recompute all your signatures and the desktop app could verify it agains the public ones...
< jonasschnelli> I really like the "nonce-leak-prevention"... the cost the implementation if worth the +security one can get
< jonasschnelli> *is worth
< jonasschnelli> And IMO there is no UX costs (if done right=
< gmaxwell> yes, no ux cost, just a little more data between the signer and host.
< gmaxwell> and some software.
< jonasschnelli> gmaxwell, sipa: are you going to write a proposal?
< * jonasschnelli> falls asleep
< wumpus> you're not in the CH timezone are you jonasschnelli :)
< promag> wumpus: and you?
< wumpus> I am
< promag> Heh
< wumpus> it's morning here
< wumpus> sigh @ #11466, I hate when something went through a review cycle and it's almost ready for merge
< gribble> https://github.com/bitcoin/bitcoin/issues/11466 | Specify custom wallet directory with -walletdir param by MeshCollider · Pull Request #11466 · bitcoin/bitcoin · GitHub
< wumpus> then people come up with "you should do it like this instead"
< meshcollider> Yeah haha
< meshcollider> wumpus: I'll rebase it now
< wumpus> I know it's well meant, but it's no way to cooporate
< meshcollider> General consensus is that its fine as-is though I think, based on the feedback #11687 got
< gribble> https://github.com/bitcoin/bitcoin/issues/11687 | External wallet files by ryanofsky · Pull Request #11687 · bitcoin/bitcoin · GitHub
< wumpus> users have been requesting a way to store their wallets somewhere else for ages
< meshcollider> Yeah and IMO its not safe enough to start separating them all over the show yet
< wumpus> so let's just add it, we can always add another mechanism later (then walletdir will just be the *default* wallet directory)
< wumpus> meshcollider: I agree, the other approach just isn't ready yet
< wumpus> and having a default wallet directory is useful too.
< wumpus> meshcollider: yes please rebase, I hope I've saved your PR :)
< wumpus> I'll help testing it
< meshcollider> wumpus: rebased, thanks :)
< meshcollider> Ah 1 sec there has been a change to walletbackup.py which I need to fix
< wumpus> no hurry...
< 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"
< wumpus> meshcollider: seems to work as expected here
< wumpus> I'd hold off on the squashing, still reviewing/testing
< meshcollider> wumpus: Okay
< wumpus> I hopefully got someone else to test it as well
< 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
< bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/99bc0b428b03...41221126c855
< bitcoin-git> bitcoin/master af9103e James O'Beirne: [build] Add a script for installing db4...
< bitcoin-git> bitcoin/master 6e4cdd6 James O'Beirne: [docs] Add reference to install_db4.sh in OS X build instructions
< bitcoin-git> bitcoin/master 4122112 Wladimir J. van der Laan: Merge #11702: [build] Add a script for installing db4...
< bitcoin-git> [bitcoin] laanwj closed pull request #11702: [build] Add a script for installing db4 (master...install-db4-script) https://github.com/bitcoin/bitcoin/pull/11702
< meshcollider> wumpus: Alright I'm heading to bed now, if you want I can squash the commits now or just do it tomorrow
< wumpus> I'm finished with it, ok with me to squash nwo
< wumpus> I'll ACK
< meshcollider> wumpus: done, thanks :)
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/41221126c855...f6f8d54aff34
< bitcoin-git> bitcoin/master 446e261 practicalswift: [qt] Fix potential memory leak in newPossibleKey(ChangeCWallet *wallet)
< bitcoin-git> bitcoin/master f6f8d54 Wladimir J. van der Laan: Merge #10920: [qt] Fix potential memory leak in newPossibleKey(ChangeCWallet *wallet)...
< bitcoin-git> [bitcoin] laanwj closed pull request #10920: [qt] Fix potential memory leak in newPossibleKey(ChangeCWallet *wallet) (master...fix-newPossibleKeyChange-memory-leak) https://github.com/bitcoin/bitcoin/pull/10920
< bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/f6f8d54aff34...ccc70a295fc5
< bitcoin-git> bitcoin/master f9cd9b1 John Newbery: [tests] Move test_framework Bitcoin primitives into separate module...
< bitcoin-git> bitcoin/master 1135c79 John Newbery: [tests] Tidy up mininode.py module...
< bitcoin-git> bitcoin/master ccc70a2 Wladimir J. van der Laan: Merge #11648: [tests] Add messages.py...
< bitcoin-git> [bitcoin] laanwj closed pull request #11648: [tests] Add messages.py (master...add_primitives_py) https://github.com/bitcoin/bitcoin/pull/11648
< promag> wumpus: are you going to merge #11466?
< gribble> https://github.com/bitcoin/bitcoin/issues/11466 | Specify custom wallet directory with -walletdir param by MeshCollider · Pull Request #11466 · bitcoin/bitcoin · GitHub
< wumpus> promag: I intend to, but would prefer if it gets stilll some more testing of course
< promag> I was planning to test it after lunch
< wumpus> great!
< promag> ok
< 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)
< wumpus> but could always be some edge case
< fanquake> Hope that wasn't too rude #11709
< gribble> https://github.com/bitcoin/bitcoin/issues/11709 | issue : Message store directory does not exist · Issue #11709 · bitcoin/bitcoin · GitHub
< 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
< 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...
< wumpus> I get loads of mail about altcoins as well because my mail is in the git log so often
< fanquake> Yea, I seem to get random messages on Twitter all the time. Get a few emails as well.
< fanquake> #11621 Should be able to go in now
< 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
< fanquake> I might fixup 11222 over the weekend, and the original author doesn't seem to have time for it.
< wumpus> fanquake: thanks
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ccc70a295fc5...1f7695b4194b
< bitcoin-git> bitcoin/master a7c949f fanquake: [build] Add temp_bitcoin_locale_qrc to CLEAN_QT to fix make distcheck
< bitcoin-git> bitcoin/master 1f7695b Wladimir J. van der Laan: Merge #11621: [build] Add temp_bitcoin_locale_qrc to CLEAN_QT to fix make distcheck...
< bitcoin-git> [bitcoin] laanwj closed pull request #11621: [build] Add temp_bitcoin_locale_qrc to CLEAN_QT to fix make distcheck (master...fix-osx-distcheck) https://github.com/bitcoin/bitcoin/pull/11621
< 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 :)
< wumpus> apparently I stumbled on the issue exactly a month after cfields' last comment
< 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
< 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?
< 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.
< 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
< 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
< wumpus> fanquake: we currently have no rules for that, because addition was so rare
< 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
< wumpus> fanquake: but not for addition so much, if people can gitian build at this point they're awesome
< wumpus> fanquake: and he's proven he could do it at least once :)
< 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.
< wumpus> yes, even expiration might be overkill at this point, it's just not so much of an issue
< wumpus> not like the repository is getting cluttered with them
< 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.
< fanquake> Guess #11700 can go in then. If no-one objects.
< gribble> https://github.com/bitcoin/bitcoin/issues/11700 | Add gitian PGP key: willyko by willyko · Pull Request #11700 · bitcoin/bitcoin · GitHub
< wumpus> agree
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1f7695b4194b...595ec11d804f
< bitcoin-git> bitcoin/master f88d900 Willy Ko: Add gitian PGP key: willyko
< bitcoin-git> bitcoin/master 595ec11 Wladimir J. van der Laan: Merge #11700: Add gitian PGP key: willyko...
< bitcoin-git> [bitcoin] laanwj closed pull request #11700: Add gitian PGP key: willyko (master...master) https://github.com/bitcoin/bitcoin/pull/11700
< bitcoin-git> [bitcoin] laanwj opened pull request #11710: cli: Reject arguments to -getinfo (master...2017_11_getinfo_args) https://github.com/bitcoin/bitcoin/pull/11710
< 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.
< gribble> https://github.com/bitcoin/bitcoin/issues/11704 | Windows build doc update by sipsorcery · Pull Request #11704 · bitcoin/bitcoin · GitHub
< wumpus> fanquake: it's great to have someone working on that
< wumpus> I'm going to edit his commit message a bit before merging, he put everything in the subject line
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/595ec11d804f...ea68190132b2
< bitcoin-git> bitcoin/master 1cecea7 Aaron Clauson: doc: Specify required source location for Windows WSL builds...
< bitcoin-git> bitcoin/master ea68190 Wladimir J. van der Laan: Merge #11704: Windows build doc update...
< bitcoin-git> [bitcoin] laanwj closed pull request #11704: Windows build doc update (master...windoc) https://github.com/bitcoin/bitcoin/pull/11704
< 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.
< gribble> https://github.com/bitcoin/bitcoin/issues/11526 | Visual Studio build configuration for Bitcoin Core. by sipsorcery · Pull Request #11526 · bitcoin/bitcoin · GitHub
< 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.
< wumpus> certainly not one that only runs on one platform
< wumpus> I'm ok with merging it though, the author committed to maintaining MSVC support
< 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.
< fanquake> Mostly in #11558
< gribble> https://github.com/bitcoin/bitcoin/issues/11558 | Minimal code changes to allow msvc compilation by sipsorcery · Pull Request #11558 · bitcoin/bitcoin · GitHub
< fanquake> Corys comment re #11196 should get a look too I think
< 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
< wumpus> #11558 is pretty much ready, though I agree with cfields' last comment
< gribble> https://github.com/bitcoin/bitcoin/issues/11558 | Minimal code changes to allow msvc compilation by sipsorcery · Pull Request #11558 · bitcoin/bitcoin · GitHub
< wumpus> we should keep the compat header out of the headers
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ea68190132b2...5197100704b8
< bitcoin-git> bitcoin/master e89adba Matt Corallo: Make default issue text all comments to make issues more readable
< bitcoin-git> bitcoin/master 5197100 Wladimir J. van der Laan: Merge #11706: Make default issue text all comments to make issues more readable...
< bitcoin-git> [bitcoin] laanwj closed pull request #11706: Make default issue text all comments to make issues more readable (master...2017-11-shorter-default-issue-redux) https://github.com/bitcoin/bitcoin/pull/11706
< 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.
< wumpus> oh yes that's annoying, almost everyone just kept the template text there, usually without even paying attention to it
< 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
< fanquake> It's a trade off between capturing everything, and missing some obscure bug being reported by an unmotivated passer by
< wumpus> a template is apparently not a working substitute for that, well who knows, maybe BlueMatt's cleanups improve it
< wumpus> yes
< fanquake> wumpus trivial merge or close? #11140
< gribble> https://github.com/bitcoin/bitcoin/issues/11140 | Trivial: Improve #endif comments by danra · Pull Request #11140 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] fanquake opened pull request #11711: bitcoin_qt.m4: Minor fixes and clean-ups. (master...bitcoin-qt-m4-cleanup) https://github.com/bitcoin/bitcoin/pull/11711
< bitcoin-git> [bitcoin] fanquake closed pull request #11222: bitcoin_qt.m4: Minor fixes and clean-ups. (master...config-fixes) https://github.com/bitcoin/bitcoin/pull/11222
< promag> I would say meh to 11140
< promag> the blocks are so small I would remove the comments, repeating the condition is kind of unnecessary there
< wumpus> well he has a point w/ mentioning ==0, and it has an ACK so meh, i'm just going to merge it
< wumpus> promag: agree that the blocks are so small that mentinoing the condition on the endif is not necessary in the first place
< wumpus> but it's there, so it should be correct...
< fanquake> just merge it then heh
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5197100704b8...142913296f00
< bitcoin-git> bitcoin/master ac1cf8d danra: Trivial: Improve #endif comments...
< promag> yes, at the moment the comment is misleading
< bitcoin-git> bitcoin/master 1429132 Wladimir J. van der Laan: Merge #11140: Trivial: Improve #endif comments...
< promag> hence the meh
< bitcoin-git> [bitcoin] laanwj closed pull request #11140: Trivial: Improve #endif comments (master...patch-4) https://github.com/bitcoin/bitcoin/pull/11140
< fanquake> wumpus looking in byteswap, does the protobuf check affect your work in 11622 at all?
< promag> wumpus: regarding #11466
< gribble> https://github.com/bitcoin/bitcoin/issues/11466 | Specify custom wallet directory with -walletdir param by MeshCollider · Pull Request #11466 · bitcoin/bitcoin · GitHub
< promag> first time run is doesn't use -walletdir right?
< fanquake> I assume not looking at the comments, if the behaviour is assumed to be the same in either case
< wumpus> fanquake: I think it's harmless to run it, though maybe unnecessary, I don't know
< 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
< wumpus> promag: you mean when it's run when the datadir doesn't exist yet?
< promag> yes
< wumpus> promag: that would be bad, let's see
< promag> it's building here so..
< promag> wumpus: it creates datadir/wallets but uses the provided -walletdir
< wumpus> promag: yep, that's expected
< wumpus> promag: there was earlier discussion about that: https://github.com/bitcoin/bitcoin/pull/11466#discussion_r150251905
< wumpus> not creating all new data directories (including when running without wallets) with a wallets subdirectory would enormously complicate things
< promag> yes I saw that. But here I've provided -walletdir no there's no need (and no harm) creating datadir/wallets
< wumpus> it should still be created if you want to run without -walletdir later
< wumpus> because if not it's too late - it's no longer a new data directory, so it will use legacy layout
< promag> right
< bitcoin-git> [bitcoin] fanquake closed pull request #9737: Don't disconnect feeler connections prematurely (master...ServicesIrrelevantForFeelerConnections) https://github.com/bitcoin/bitcoin/pull/9737
< promag> btw, why not validate walletdir before intro?
< promag> edge case?
< wumpus> it's a bit tricky but I think it's the most straightforward and easy to verify way to do this
< wumpus> promag: doing things before intro is extremely difficult
< wumpus> e.g. bitcoin.conf hasn't been read yet
< wumpus> nor have per-network GUI settings
< wumpus> so if you'd validate walletdir before intro, you'd miss it if it's provided in bitcoin.conf
< promag> btw, if -walletdir points to a file, the error is still "Error: Specified wallet directory "/Users/promag/foo2" does not exist."
< wumpus> that could use a clearer error
< bitcoin-git> [bitcoin] fanquake closed pull request #10172: Fix opt-in RBF reliance on compiler integer size (master...rbf-numlimits-fix) https://github.com/bitcoin/bitcoin/pull/10172
< bitcoin-git> [bitcoin] fanquake closed pull request #10702: [Trivial] Improve end-of-namespace comment consistency (master...improve-end-of-namespace-comment-consistence) https://github.com/bitcoin/bitcoin/pull/10702
< promag> MarcoFalke: just a question, I saw the moveonly
< promag> now it can be cleaned right?
< wumpus> promag: sure
< MarcoFalke> promag: Not sure if that single change warrants a pull on its own
< MarcoFalke> I'd prefer if is cleaned up when the function is touched by other reasons. Though, no strong opinion. Just -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)
< meshcollider> Would be a much simpler change I think
< jonasschnelli> wumpus: yeah. Not in CH timezone. Right now in Hawaii
< 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...
< jonasschnelli> compile time is a main show stopper for testing pulls
< BlueMatt> jonasschnelli: make src/bitcoind (or maybe its just make bitcoind?)
< jonasschnelli> BlueMatt: hmm.. yes. That could work (now all pre-built,.. need to test with a new PR)
< bitcoin-git> [bitcoin] jnewbery opened pull request #11712: [tests] Split NodeConn from NodeConnCB (master...split_nodeconn) https://github.com/bitcoin/bitcoin/pull/11712