< 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
< 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...
< 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>
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?
< 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/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
< 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`?
< 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>
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