< bitcoin-git> [bitcoin] benma opened pull request #9822: Refactor: Split part of AppInitMain() into a new function (master...appinitmain) https://github.com/bitcoin/bitcoin/pull/9822
< wumpus> jonasschnelli, others: any idea about OS-specific random API on OSX? I heard about "SecRandom" (https://opensource.apple.com/source/Security/Security-55471/sec/Security/SecRandom.h), is that what should be used?
< jonasschnelli> wumpus: Yes. That's simple
< wumpus> will try to add it to #9821. So SecRandomRef can be left NULL?
< gribble> https://github.com/bitcoin/bitcoin/issues/9821 | util: Specific GetOSRandom for Linux/FreeBSD/OpenBSD by laanwj · Pull Request #9821 · bitcoin/bitcoin · GitHub
< jonasschnelli> Let me look at it...
< jonasschnelli> I know there are other projects that already did this
< sipa> that's a psuedo random number
< sipa> i believe we're looking for a pseudo random number!
< wumpus> kSecRandomDefault
< sipa> defining a new name for NULL through an external symbol?
< wumpus> very random, just happens to have all the bits turned off every time
< sipa> that's pretty inefficient!
< jonasschnelli> @function SecRandomCopyBytes
< jonasschnelli> @abstract Return count random bytes in *bytes, allocated by the caller.
< jonasschnelli> It is critical to check the return value for error
< jonasschnelli> "Generates an array of cryptographically secure random bytes"
< jonasschnelli> IMO SecRandomCopyBytes is CPRNG
< wumpus> it's inefficient, though that is not really our worry here, this is the slow path
< jonasschnelli> I think this is the way to go: "if (SecRandomCopyBytes(kSecRandomDefault, entropy.length, entropy.mutableBytes) != 0) return nil;"
< wumpus> jonasschnelli: I guess MacOSX also supports the sysctl(ARND), inherited from NetBSD?
< jonasschnelli> Yes. I think so. But not sure which makes more sense. Maybe add entropy from both?
< jonasschnelli> I quickly check what apples recommends (that doesn't say it the solution we should go()
< wumpus> I'd like to keep the GetOSRandom abtraction simple - just get random from the OS, whatever a good option is for that OS. Combining shouldn't make sense there
< wumpus> an alternative way of going about this would be to check all randomness sources that are available , and somehow call all of them every time and combine them, but I'm not sure whether that's voodoo coding or sensible paranoia
< wumpus> and note we already combine the output with randomness from other sources in an outer function
< jonasschnelli> wumpus: has the idea with using fortuna for mixing all sorts of entropy died?
< wumpus> using the MacOSX API doesn't mean anything scary like using objective c++ does it? all the examples I see have NSLog and NSMutableString etc in them
< jonasschnelli> No. It's pure C
< jonasschnelli> You need to link against the Security.frameowkr
< jonasschnelli> T
< jonasschnelli> We already link against other framework...
< wumpus> jonasschnelli: I don't know, but I don't see a reason to combine multiple random streams coming from the OS and portrayed as cryptographic APIs
< jonasschnelli> wumpus: I think the only reason could be if you are enough paranoid. :)
< jonasschnelli> What speaks against using /dev/(u)random on OSX? Concurrency? It would be the simplest approach?
< jonasschnelli> Apples states that /dev/random is CPRNG
< wumpus> we already use /dev/urandom
< jonasschnelli> wumpus: So SecRandomCopyBytes would give additional entrtopy?
< wumpus> and that will remain the fallback if nothing else is availalbe, however in sandboxes it's not always available
< wumpus> that was what prompted this, not 'we don't trust /dev/urandom'
< wumpus> e.g. user created containers and chroots won't have the /dev/urandom device, some sandboxes (such as cluodabi/capsicum) don' t have file access at all (not that we can support those at the moment in bitcoin core). Direct system calls are the new way to get randomness from the OS.
< jonasschnelli> Apples says "This function reads from /dev/random to obtain an array of cryptographically-secure random bytes" about SecRandomCopyBytes
< wumpus> lol. okay, so it won't help :)
< jonasschnelli> Not sure what internal fallback mechanisms are provided
< jonasschnelli> I think that part is closed source
< wumpus> thanks for looking that up, that's very useful information
< jonasschnelli> And yes. It reads from /dev/random :)
< jonasschnelli> If that's not available, it returns 0.
< wumpus> yup. So going through all the trouble to link another framework and calling it isn't worth it
< jonasschnelli> Yes.
< cfields> er, i don't think we link in frameworks for bitcoind do we?
< cfields> (seems the point's moot anyway now, though)
< jonasschnelli> cfields: Good point. I guess only for the Qt parts.
< wumpus> a different thing I noticed is that our code is opening and closing the /dev/urandom device every call to GetOSRand. Nothing wrong with that in itself, though reserving a fd for it would mean it's always available.
< jonasschnelli> I wonder if it would make more sense to have the random
< jonasschnelli> ...
< jonasschnelli> the randomness thins abstracted into a library...
< jonasschnelli> I think there are lots of other application that also wants to deal with this without openssl
< wumpus> well it's abstracted to random.o now :-)
< wumpus> which is sort of a one-file randomness library. Idon't think it depends on any bitcoin specific things
< jonasschnelli> Hah. indeed. What are the dependencies?
< luke-jr> jonasschnelli: gnutls? :P
< * jonasschnelli> stabs luke-jr
< jonasschnelli> my testnet dns seeder will be down for a couple of hours (moving location)
< wumpus> ok, thanks for letting us know
< jonasschnelli> Does anyone know how I can avoid sudo password prompt in gbuild using LXC? I have added /usr/bin/lxc-start and execute to sudoers (nopassword)
< Victorsueca> sudo -i ?
< luke-jr> jonasschnelli: check syslog
< wumpus> to have passwordless sudo you need to edit sudoers, you can either make all sudo use passwordless or specific commands
< wumpus> I don't know the syntax by heart, though. Always have to look at up (and fail at leat three times at it)
< jonasschnelli> But why does gbuild require root?
< luke-jr> also, some distros have non-root LXC now
< luke-jr> because LXC historically has required root
< wumpus> jonasschnelli: spinning up a fully featured LXC container requires root
< jonasschnelli> okay... I see.
< wumpus> this is because the user creating the LXC container will be root in the container (without capabilities), which can be somewhat dangerous if there are security bugs in the kernel
< luke-jr> (which there have been)
< wumpus> and indeed as luke-jr says it is possible on more recent kernels to create a user LXC, but these have a few restrictions which I'm fairly sure we can't cope with right now
< jonasschnelli> it's not just lxc-start and lxc-execute that requires root?
< wumpus> it's just those no
< wumpus> no->two
< wumpus> maybe only lxc-execute
< wumpus> not sure. I think there's an example of editing your sudoers file to allow this in gitian-building?
< jonasschnelli> Yes. I have set those... still got the sudo promot
< jonasschnelli> Ah! Wrong machine... damit
< jonasschnelli> Can we have different shell background colors per host?!
< wumpus> jonasschnelli: I have different prompt colors per host
< wumpus> (even a script to randomly generate them :-)
< jonasschnelli> wumpus: That is very clever... I need to do this as well...
< jonasschnelli> wumpus: thanks!
< wumpus> setting terminal background is more involved; you can set it with the same escape sequences, however many programs will reset the background
< jonasschnelli> I think the background switch should be done on the client side... but the prompt is good enought
< wumpus> fairly sure tmux and some terminal emulators such as gnome=terminal have the option of having different profiles, so you could e.g. launch a different profile before ssh'ing. But yeah too much hassle
< luke-jr> deterministic generation might be more useful
< wumpus> KDE term had/has a nice feature where you could set an icon for the tab too
< wumpus> luke-jr: but some combinations are ugly, so I determine them once when setting up the host then just write that into ~/.profile
< luke-jr> too bad there's not a nice way to have it colour differently for local vs remote
< wumpus> yes I started doing this consistently after shutting down the wrong host one time too many :-)
< luke-jr> I disabled the rm command for root, and alias'd it with -i for my normal user :p
< wumpus> that's a good idea. Some historical UNIXes had that as default IIRC
< wumpus> well the -i thing. Don't know about disabling rm completely
< Victorsueca> is there going to be a 0.14.0rc2 or is the rc1 definitive so far unless a critical issue appears in the wild?
< wumpus> there have already been some issues to warrant rc2
< wumpus> for example #9810
< gribble> https://github.com/bitcoin/bitcoin/issues/9810 | 0.14 not loading mempool.dat? · Issue #9810 · bitcoin/bitcoin · GitHub
< jonasschnelli> Gitian does by default avoid recompiling the dependencies on every build? Right?
< wumpus> and #9817
< gribble> https://github.com/bitcoin/bitcoin/issues/9817 | Fix segfault crash when shutdown the GUI in disablewallet mode by jonasschnelli · Pull Request #9817 · bitcoin/bitcoin · GitHub
< wumpus> jonasschnelli: yes, the dependency caching system should make sure of that
< Victorsueca> ahh how not, it had to be yet another thing windows copied and changed slightly to make it incompatible
< wumpus> it will recompile if either the dependency definitions changed, or the compilation environment changed
< Victorsueca> such CRLF
< jonasschnelli> I wonder why that crash (https://github.com/bitcoin/bitcoin/issues/9814) happens
< wumpus> Victorsueca: yep :/ the DOS legacy in this case
< wumpus> jonasschnelli: yes it's weird
< wumpus> jonasschnelli: it happens deep in the bowels of qt, in the X platform handling
< jonasschnelli> Yes. Looks like.
< jonasschnelli> I wonder if he would get the same crashed building 0.13.1 (I would say so).
< jonasschnelli> *crashes
< wumpus> jonasschnelli: weird. it looks like both Thread 1 and Thread 2 are in libqxcb.so
< wumpus> is some auxiliary thread trying to do rendering / change the GUI?
< wumpus> ok on the other hand this is just "xcb_wait_for_event" so probably this is just the event loop
< wumpus> no, doesn't seem worrying
< wumpus> the traceback of Thread 1 is completely Qt and upstream libraries - none of our own code
< jonasschnelli> wumpus: I can't find any link between the crash(es) and our code in both stack traces
< jonasschnelli> I think we should recommend to try to compile against a different Qt version
< wumpus> thread 1 is the GUI thread so should be the only one that matters here
< wumpus> so this is either a race with cleaning up objects (deleteLater or such), or something in Qt/X11 itself. I suspect the second as it happens in the X library not in Qt.
< wumpus> cfields: didn't we have some scary xcb compatibility issues before?
< cfields> wumpus: heh, i was just clicking the above link with the same thought
< cfields> wumpus: only applies to static qt builds
< cfields> (it's qt's internal x stubs that cause that issue)
< cfields> it's possible that qt manages to crash there in some ugly way if there's no display plugin available, though
< cfields> (i haven't read the logs yet, if bitcoin-qt launches at all obviously that's not the culprit)
< cfields> wumpus: there was a touchscreen bug like that that rings a bell, though
< cfields> wacom, iirc
< cfields> headed to bed, nnite
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #9823: qa: Set correct path for binaries in rpc tests (master...Mf1702-qaPath) https://github.com/bitcoin/bitcoin/pull/9823
< jonasschnelli> wumpus: F.Y.I: "%sudo ALL=NOPASSWD: /usr/bin/lxc-execute" hasn't worked for me... I had to allow it per user "jonasschnelli ALL=NOPASSWD:/usr/bin/lxc-execute".
< wumpus> strange. It does seem to be the right syntax
< jonasschnelli> The goup or per user line?
< wumpus> oh, you're not in the sudo group?
< wumpus> both
< jonasschnelli> Ah... yes.. that could be the issue.. :)
< jonasschnelli> Do I need to assign the LXC container specific amount of ram? Or does it share it with the host?
< jonasschnelli> I try now -j5
< * jonasschnelli> needs to go afk
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #9824: qa: Check return code when stopping nodes (master...Mf1702-qaRet) https://github.com/bitcoin/bitcoin/pull/9824
< wumpus> jonasschnelli: LXC limits work in a different way, I've never set any at least
< MarcoFalke> wumpus: Can you add jnewbery_ to the list of members on github?
< MarcoFalke> Maybe also ryanofsky
< wumpus> yes, good idea
< wumpus> ok invited both to bitcoin and bitcoin-core
< wumpus> re: release notes, would it make sense to group the two qt debug console changes?
< wumpus> I mena "Nested RPC Commands in Debug Console" and "Sensitive Data Is No Longer Stored In Debug Console History"
< wumpus> we also have "GUI Changes"
< Victorsueca> that's a nice thing, I used to CTRL+L after typing sensitive data
< wumpus> yes, it's certainly a nice thing, it's just spread out a bit haphazardly
< wumpus> in the release notes
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5628c70f2a44...92dd6c8dfdd6
< bitcoin-git> bitcoin/master a87d02a Marko Bencun: use EXIT_ codes instead of magic numbers...
< bitcoin-git> bitcoin/master 92dd6c8 Wladimir J. van der Laan: Merge #9815: Trivial: use EXIT_ codes instead of magic numbers...
< bitcoin-git> [bitcoin] laanwj closed pull request #9815: Trivial: use EXIT_ codes instead of magic numbers (master...exitcode) https://github.com/bitcoin/bitcoin/pull/9815
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/92dd6c8dfdd6...5b583efaa721
< bitcoin-git> bitcoin/master 3b4dd2a Peter Todd: Add seed.btc.petertodd.org to mainnet DNS seeds
< bitcoin-git> bitcoin/master 5b583ef Wladimir J. van der Laan: Merge #9805: Add seed.btc.petertodd.org to mainnet DNS seeds...
< bitcoin-git> [bitcoin] laanwj closed pull request #9805: Add seed.btc.petertodd.org to mainnet DNS seeds (master...2017-02-add-pt-mainnet-seed) https://github.com/bitcoin/bitcoin/pull/9805
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5b583efaa721...a8c575103815
< bitcoin-git> bitcoin/master eaea2bb gubatron: Removed redundant parameter from mempool.PrioritiseTransaction...
< bitcoin-git> bitcoin/master a8c5751 Wladimir J. van der Laan: Merge #9801: Removed redundant parameter from mempool.PrioritiseTransaction...
< bitcoin-git> [bitcoin] laanwj closed pull request #9801: Removed redundant parameter from mempool.PrioritiseTransaction (master...refactor-mempool-prioritisetx) https://github.com/bitcoin/bitcoin/pull/9801
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a8c575103815...ba7220b5e82f
< bitcoin-git> bitcoin/master e2e2f4c Russell Yanofsky: Return errors from importmulti if complete rescans are not successful
< bitcoin-git> bitcoin/master ba7220b Wladimir J. van der Laan: Merge #9773: Return errors from importmulti if complete rescans are not successful...
< bitcoin-git> [bitcoin] laanwj closed pull request #9773: Return errors from importmulti if complete rescans are not successful (master...pr/multicheck) https://github.com/bitcoin/bitcoin/pull/9773
< bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.14: https://github.com/bitcoin/bitcoin/commit/9072395e5fddb1f2590138a179ab0868646a38a0
< bitcoin-git> bitcoin/0.14 9072395 Russell Yanofsky: Return errors from importmulti if complete rescans are not successful...
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ba7220b5e82f...1efc99c4dc4d
< bitcoin-git> bitcoin/master bc8fd12 Alex Morcos: Remove harmless read of unusued priority estimates
< bitcoin-git> bitcoin/master 1efc99c Wladimir J. van der Laan: Merge #9819: Remove harmless read of unusued priority estimates...
< bitcoin-git> [bitcoin] laanwj closed pull request #9819: Remove harmless read of unusued priority estimates (master...removeExtraRead) https://github.com/bitcoin/bitcoin/pull/9819
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1efc99c4dc4d...bed5b30a5622
< bitcoin-git> bitcoin/master 9949ebf John Newbery: [Trivial] Remove incorrect help message from gettxoutproof()
< bitcoin-git> bitcoin/master bed5b30 Wladimir J. van der Laan: Merge #9711: [Trivial] Remove incorrect help message from gettxoutproof()...
< bitcoin-git> [bitcoin] laanwj closed pull request #9711: [Trivial] Remove incorrect help message from gettxoutproof() (master...gettxoutproofhelp) https://github.com/bitcoin/bitcoin/pull/9711
< abhishekcs10_> Hello everyone :)
< abhishekcs10_> I am new to bitcoin and eager to learn about it.
< lopp> I recently pulled down the changes for Bitcoin Core 0.14 into my Statoshi fork, but one of the metrics is no longer populating and I'm hoping someone can explain if this is by design or if I screwed up
< lopp> the specific metric is the "block" inv message (MSG_BLOCK) that I'm populating here: https://github.com/jlopp/statoshi/blob/master/src/net_processing.cpp#L1571
< lopp> the "MSG_TX" inv type metric is populating fine (several lines earlier)
< abhishekcs10_> I am having problem understanding following parameters in bitcoin/src/chainparams.cpp
< abhishekcs10_> How can I edit interblock timing
< abhishekcs10_> Eg. Setting it to 1min retargetted every 5min
< sdaftuar> lopp: i'm guessing that is because your peers are using headers or cmpctblocks to announce new blocks, rather than inv's
< sdaftuar> lopp: if all your peers or 0.12 or later - i think? - then it's unlikely you'll get block invs, except in rare cases
< sdaftuar> maybe 0.11 or later
< jlopp> OK I figured it was likely due to protocol changes; my test node is behind a NAT that I don't port forward so it only has 8 peers
< jlopp> I'll double check the peer versions
< sdaftuar> oh yep that will do it then
< sdaftuar> we have preferential peering logic that will make it unlikely for you to connect outbound to older peers (in preparation for segwit)
< jlopp> ahhh
< sdaftuar> so most likely all your peers are 0.13.1 or later
< lopp> @sdaftuar confirmed; they're all 0.13.1+
< * BlueMatt> . Now providing RaaS
< BlueMatt> Review as a Service, that is
< BlueMatt> in exchange for review of #9725
< gribble> https://github.com/bitcoin/bitcoin/issues/9725 | CValidationInterface Cleanups by TheBlueMatt · Pull Request #9725 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] ryanofsky opened pull request #9827: Improve ScanForWalletTransactions return value (master...pr/scanret) https://github.com/bitcoin/bitcoin/pull/9827
< luke-jr> fun, left my CTableView bitcoin tx log overnight and no substantial memory usage growth. :D
< luke-jr> (I haven't implemented a limit to the log yet, but set it up to use only weak_ptrs)
< luke-jr> thinking of making it use maybe 500 lines of non-weak ptrs, and up to 10000 lines of weak_ptrs, or something
< bitcoin-git> [bitcoin] ryanofsky opened pull request #9828: Avoid -Wshadow warnings in wallet_tests (master...pr/multishadow) https://github.com/bitcoin/bitcoin/pull/9828
< bitcoin-git> [bitcoin] ryanofsky opened pull request #9829: Fix importmulti returning rescan errors for wrong keys (master...pr/multiinc) https://github.com/bitcoin/bitcoin/pull/9829
< jtimon> mhmm, in rpcwallet and rpcdump, ensure EnsureWalletIsAvailable( is called before showing the help. if the user selected help but the wallet is not available, the function will return NullUniValue instead of actually showing the help
< jtimon> is this the desired behaviour?
< jtimon> it seems not, and it's simple to fix
< warren> I used linearize-data.py to generate in-order *.blk files. I want to make the very deep historical blocks read-only at the filesystem level and hard-linked into the blocks/ directory to be used by multiple separate instances of bitcoind on the same machine. It seems that bitcoind currently requires opening all *.blk files as writable so it is incompatible with this use case. http://pastebin.com/DMUcTJuT debug.log and relevant parts of b
< warren> itcoind source.
< warren> I could make a temporary hack for myself, but is there any reason to not support this in the future?
< luke-jr> jtimon: it's the intended behaviour, presumably so -wallet=0 behaves the same as if it was compiled without
< luke-jr> (I don't mind if someone changes it though)
< warren> oh, *.dat files
< warren> blk*.dat
< jtimon> luke-jr: I see, the other 2 options would be to either throw the error even if fHelp is true, or show the help even if the wallet is not available
< luke-jr> wouldn't throwing an error break `help`?
< tussssss> Buy/Sell ( Bitcoin - Perfect money - webmoney - western union - moneygram - skrill - neteller ) & giftcards/prepaids ( llike amazon-ebay etc... ) Contact Skype : rodrige.amin ICQ : 690490649
< jtimon> luke-jr: help is already broken if the wallet is not available
< jtimon> why are all these functions declared as extern? https://github.com/bitcoin/bitcoin/blob/master/src/rpc/server.h#L188
< luke-jr> jtimon: is it? :/
< jtimon> luke-jr: if the wallet is not available, the function returns NullUniValue before having the opportunity to check if (fHelp || params.size() < 2 || params.size() > 6) (well, of course the exact check depends on the function)
< luke-jr> jtimon: and `help` upon getting null just skips it, no?
< jtimon> my preferred behaviour would be to only check if the wallet is available after checking if it should show the help, and when doing so, if it's not available just throw the error as if fHelp was false
< jtimon> luke-jr: no, if fHelp=false, it returns false, EnsureWalletIsAvailable() returns false instead of throwing the error, thus the calling function returns NullUniValue before having the chance to check if the help should be shown
< jtimon> I guess I'll just write my prefferred fix and see what people think
< luke-jr> jtimon: …
< luke-jr> jtimon: foomethod() returns null to help(), which just skips foomethod
< jtimon> what help() function ?
< luke-jr> rpc/server.cpp
< luke-jr> std::string CRPCTable::help(const std::string& strCommand) const
< jtimon> oh, no I don't mean the general help, I mean the help for a specific rpc call (or when you have an invalid number of parameters for that call)
< jtimon> but let me read that method...
< jtimon> I see, yeah, that's the point of returning null instead of launching the error or giving it the opportunity to get the help first
< luke-jr> fHelp is only ever true via that method
< jtimon> mhmm, if I start the deamon with -wallet=0 and then with the client do sendtoaddress --help it shows the doc...
< jtimon> how can I make pwalletMain=NULL ?
< jtimon> btw, IIRC we talked before about moving the rpc wallet stuff from BTC to satoshis, but it breaks the interface. Are we decided to never do that?
< jtimon> would this be a good time?
< luke-jr> `sendtoaddress --help` is simply an invalid address
< jtimon> ?? then why it shows the help instead of "Invalid Bitcoin address"
< ryanofsky> i know "sendfrom" RPC is deprecated, but is it also broken? I don't see 'fromaccount'
< ryanofsky> argument actually used for coin selection
< jeremyrubin> no that's not broken
< jeremyrubin> As far as I understand, accounts were meant to be internal accounting
< jeremyrubin> meaning negative balances could be reported
< jeremyrubin> So if I spend 2 from account Y with real balance 1, Y's new balance should be -1
< jeremyrubin> so account info has no bearing on coin selection
< sipa> that ^
< sipa> coins are independent from accounts
< sipa> accounts only have a balance