< fanquake> \o/
< midnightmagic> sweet, so, some success (so far) with the gitian builds in a strictly manually-upgraded image, with a small change to the grab-manifest.sh file.
< bitcoin-git> [bitcoin] sipa opened pull request #15427: Add support for descriptors to utxoupdatepsbt (master...201902_utxoupdatepsbtdesc) https://github.com/bitcoin/bitcoin/pull/15427
< fanquake> wumpus think 15398, 15426, 15425 should all be mergeable
< wumpus> thank you, will check
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/f60d029a2a76...e9c190044df8
< bitcoin-git> bitcoin/master d067e81 Chun Kuan Lee: msvc: add rapid check property tests
< bitcoin-git> bitcoin/master e9c1900 Wladimir J. van der Laan: Merge #15398: msvc: add rapidcheck property tests
< bitcoin-git> [bitcoin] laanwj merged pull request #15398: msvc: add rapidcheck property tests (master...appveyor-rapid-check) https://github.com/bitcoin/bitcoin/pull/15398
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/e9c190044df8...2d0337992d81
< bitcoin-git> bitcoin/master a607c9a David A. Harding: [Doc] importmulti: add missing description of keypool option
< bitcoin-git> bitcoin/master 2d03379 Wladimir J. van der Laan: Merge #15426: [Doc] importmulti: add missing description of keypool option...
< bitcoin-git> [bitcoin] laanwj merged pull request #15426: [Doc] importmulti: add missing description of keypool option (master...2019-02-importmulti-keypool) https://github.com/bitcoin/bitcoin/pull/15426
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/2d0337992d81...4064d048d61c
< bitcoin-git> bitcoin/master d3661a3 David A. Harding: [Doc] add missing newline to witnessScript in listunspent help
< bitcoin-git> bitcoin/master 4064d04 Wladimir J. van der Laan: Merge #15425: [Doc] add missing newline to listunspent help for witnessScr...
< bitcoin-git> [bitcoin] laanwj merged pull request #15425: [Doc] add missing newline to listunspent help for witnessScript (master...2019-02-help-listunspent-missing-newline) https://github.com/bitcoin/bitcoin/pull/15425
< wumpus> fanquake: yeh those were easy
< bitcoin-git> [bitcoin] luke-jr opened pull request #15428: GUI: Add Pairing tab with Tor onion address as copyable text and QR code (master...tor_gui_pairing) https://github.com/bitcoin/bitcoin/pull/15428
< luke-jr> I guess the last step is to add tor to gitian binaries..
< luke-jr> unfortunately, Tor abandoned gitian, so that may prove controversial since it complicates verifying builds :x
< luke-jr> (especially with simply launching tor being apparently controversial for some reason)
< sipa> luke-jr: were you thinking of including tor in gitian builds?
< fanquake> wumpus I'll find something more difficult then :p
< sipa> i don't think we should be shipping our own tor binary....
< luke-jr> sipa: yes
< luke-jr> sipa: current thought is to use Tor's own deterministic binaries and just copy the files out of it
< luke-jr> so it's not quite "our own"
< sipa> sure, but why not use the system's tor binary?
< luke-jr> Windows system doesn't have one
< gmaxwell> maybe we should ask the tor project what they think?
< gmaxwell> on one hand, it would be really good to radically increase the number of nodes running tor. OTOH, I am highly wary about shipping another binary with a huge attack surface.
< gmaxwell> like will we have to do emergency releases whenever tor has a vuln? ... will we finally get rid of the openssl induced firedrills in bitcoin only to regain them via tor? etc..
< luke-jr> how often does Tor have vulns?
< gmaxwell> In terms of effort vs benefit, getting some form of nat forwarding working again would probably be a bigger win...
< luke-jr> NAT doesn't provide authentication
< gmaxwell> luke-jr: IIRC it exposes openssl implemented HTTPS to the world, so any openssl https vuln is a tor vuln too. (I could be mistaken, but thats my belief)
< luke-jr> O.o why would it do that? :/
< gmaxwell> luke-jr: no, but if you care about authentication the bitcoin crypto/auth proposals are better for that...
< gmaxwell> luke-jr: because TOR's p2p comms uses HTTPS in order to be more DPI immune.
< luke-jr> gmaxwell: well, I also care that some users literally *can't* get a port forwarded
< luke-jr> Tor is kind of a one-size-fits-all solution
< gmaxwell> yes, sure, some can't... but a vast number can but currently don't because we have no port forwarding by default anymore.
< luke-jr> (and lots of people have dynamic IPs)
< sipa> tor for additional connections should be a pretty no-brainer default win, but adding hidden services that aren't "chosen" sort of reduces sybil reisstance too
< luke-jr> gmaxwell: I'm not looking at this from the perspective of more listening nodes; I'm looking at it as a way for users to more easily use mobile wallets with their own node
< gmaxwell> also presumably if you care about authenticated inbound enough to use onion, installing tor is not that much more to ask... you don't get an authenticated peering without doing something manually...
< luke-jr> gmaxwell: the last PR adds the QR code to the GUI
< gmaxwell> luke-jr: oh thats cool.
< gmaxwell> but what wallet is this actually useful for?
< luke-jr> hopefully the ones with trusted node support will add peering via QR code in response
< gmaxwell> IIRC almost all of them require some server... like android wallet doesn't but afaik is mostly unusable and also doesn't let you manually specify an onion to -connect to.
< luke-jr> GreenBits and Hodlwallet I hear let you put in an IP currently
< luke-jr> of a normal node
< gmaxwell> never heard of hodlwallet.
< luke-jr> some Bread fork
< luke-jr> (maybe Bread does too, I dunno)
< sipa> that doesn't mean they support tor
< luke-jr> AFAIK, there's some library to do Tor connections on Android at least
< luke-jr> (also, from what I've heard, Tor is basically needed to use Lightning already?)
< luke-jr> (FWIW, #tor (OFTC) has a "no[t a problem]" response to my inquiry)
< sipa>
< sipa> gmaxwell: you should probably open an assumevalid uodate PR
< echeveria> jesus christ don't bundle tor.
< echeveria> luke-jr: any of these wallets which allow you to "use your own node" provide basically meaningless security or privacy gain. it's snake oil.
< echeveria> bundling tor in any situation immensely increases attack surface, will get people flagged absolutely everywhere for the binaries it runs and the traffic it creates. given the ease of sybil attacking HS peer rumoring it's of a significant disadvantage to even use it at all.
< echeveria> if you want authenticated peers, great, there's drafts for peer authentication around.
< echeveria> if you want obfuscation, you probably don't, but luckily TCP traffic is easily encapsulated.
< echeveria> wanting more ability to open listening sockets is probably more debatable, but realistically the myriad of absolutely shitty peers on the network tells me that residential connections aren't holding up anyway.
< bitcoin-git> [bitcoin] gmaxwell opened pull request #15429: Update assumevalid, minimumchainwork, and getchaintxstats to height 563378 (master...201902-assumevalid) https://github.com/bitcoin/bitcoin/pull/15429
< gmaxwell> sipa: as requested, https://github.com/bitcoin/bitcoin/pull/15429 you might want to 0.18 tag.
< echeveria> gmaxwell: isn't the block hash usually set back a bit from the tip?
< echeveria> the one in the pull request is approximately now.
< fanquake> by the time that PR gets merged, and then 0.18.0 released, it should be back from the tip. testnet is usually set back a larger amount.
< echeveria> right, sure
< gmaxwell> echeveria: it will be by the time it gets merged.
< gmaxwell> IIRC the first time I did it I set it further back, but then noticed how long it took to get merged, since then I've set it right at the tip after first looking to see if I could find a competing block
< bitcoin-git> [bitcoin] practicalswift closed pull request #15215: rpc: Use the return value of GetProxy(...) in GetNetworksInfo(). Mark GetProxy(...) with [[nodiscard]]. (master...getnetworkinfo-getproxy) https://github.com/bitcoin/bitcoin/pull/15215
< bitcoin-git> [bitcoin] ken2812221 opened pull request #15431: msvc: scripted-diff: Remove NDEBUG pre-define in project file (master...msvc-no-ndebug) https://github.com/bitcoin/bitcoin/pull/15431
< wumpus> I don't think we should be shipping tor binaries at all, at least not with the default download, I'm fine with a "tor bitcoin core" bundle
< wumpus> but tor is illegal in some countries where bitcoin is not so coupling them as the only option is a bad idea
< wumpus> could get some people in trouble
< bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/4064d048d61c...b72c787dc8f7
< bitcoin-git> bitcoin/master 8a1f0a3 Chun Kuan Lee: scripted-diff: Remove NDEBUG pre-define
< bitcoin-git> bitcoin/master 3ec56be Chun Kuan Lee: appveyor: Remove unused NDEBUG removal
< bitcoin-git> bitcoin/master b72c787 MarcoFalke: Merge #15431: msvc: scripted-diff: Remove NDEBUG pre-define in project fil...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #15431: msvc: scripted-diff: Remove NDEBUG pre-define in project file (master...msvc-no-ndebug) https://github.com/bitcoin/bitcoin/pull/15431
< jonasschnelli> 2019-02-17T19:08:42Z [dummy23] Wallet completed loading in 38110ms
< jonasschnelli> a simple regtest wallet took 38110ms to load (happend on master)
< jonasschnelli> 2019-02-17T19:08:03Z [dummy23] Keys: 2007 plaintext, 0 encrypted, 2007 w/ metadata, 2007 total. Unknown wallet records: 0
< jonasschnelli> in case someone else hit this as well (I'll take a closer look soon)
< harding> 1136ms here, plaintext, default wallet at node startup, master from earlier today
< achow101> jonasschnelli: harding: probably just the upgrade to the new key metadata?
< echeveria> wumpus: many VPS and server hosts will instantly ban you if you run a process named ‘tor’.
< achow101> is it consistently slow or just that one time
< achow101> although 38 secs is a really long time even with the upgrade
< jonasschnelli> I will profile it.. thanks for the hint achow101
< luke-jr> wumpus: why would tor be illegal?
< luke-jr> as opposed to using tor to bypass blocking
< midnightmagic> ownership of the tools to break into a house is almost as illegal as breaking into a house in some places.
< luke-jr> midnightmagic: but computers aren't illegal
< midnightmagic> algorithms are apparently illegal to export, even in the US when shipping to canada.
< midnightmagic> It's not such a big leap to weird autocratic countries where they'll chop you up and send pieces of you to your family if you run a tor node or are caught with the software on your hdd
< echeveria> luke-jr: look that's nice and all, but remember that you live in a country with laws about what sorts of encryption you're allowed to use and distribute. don't get lost in your own feelings and stick to what actually happens in the real world.
< midnightmagic> I had to fill out some stupid form just the other day promising that my stuff won't end up in a military application. I mean how the hell am I supposed to know what happens to fingernail-sized chips after I sell them?
< * midnightmagic> grumbles
< midnightmagic> too much weird security theatre.
< luke-jr> echeveria: according to Tor's FAQs, nobody has ever been arrested for using Tor
< echeveria> luke-jr: did I say they had?
< luke-jr> you implied it, considering the context of the discussion was whether tor is illegal or not
< echeveria> I've never suggested or implied that anybody has been arrested for using Tor.
< luke-jr> "what actually happens in the real world" in this context means arrests or not
< echeveria> wtf no it doesn't.
< echeveria> I was talking about export cryptography laws in the US.