1 2015-10-30 00:00:08 <Luke-Jr> sipa: well, the goal of reading bitcoin.conf in the first place is to not require any specific configuration
 2 2015-10-30 00:00:17 <gmaxwell> warren: among many other problems; including the fact that the redhat scripts for bitcoind used to set the rpcpassword with only 32bits of entropy :(, the rpcpassword stuff is an outright violation of good security practices,  in particular; you have no way to selectively revoke access with it.
 3 2015-10-30 00:00:45 <warren> For the moment I planned on making only bitcoind/bitcoin-qt executing in its own selinux context capable of read/write of anything in datadirs, adding an exception for a particular file for arbitrary other users to read is not so simple.  They're probably better off using rpcuser/rpcpassword the old fashioned way.
 4 2015-10-30 00:00:54 <CodeShark> we're already violating good security practices with the RPC on so many levels...lol
 5 2015-10-30 00:01:27 <gmaxwell> warren: it shouldn't be arbritary users, they should add the role to users they want to have access to the daemon.
 6 2015-10-30 00:01:34 <warren> gmaxwell: Red Hat scripts?  Nobody packaged it at Red Hat/Fedora in the past aside from some end-users, wasn't that 32bit entropy problem in the Debian package?
 7 2015-10-30 00:01:59 <gmaxwell> warren: no, was _also_ in the debian package, and then later got recreated in the fedora packages someone was distributing. :(
 8 2015-10-30 00:02:29 <warren> bitcoin never was distributed in Fedora or Red Hat yet, which is why I'm carefully planning to do it right when it does.
 9 2015-10-30 00:02:39 <gmaxwell> warren: the whole thing is a security trap, how many thousands of bitcoins must be lost due to rpcauth configuration screwups before people will admit the interface is intrensically unsafe?
10 2015-10-30 00:02:43 <warren> I already got them to wait for 0.12 for libsecp256k1.
11 2015-10-30 00:03:05 <Luke-Jr> warren: you have an exception to use the bundled LevelDB and libsecp256k1?
12 2015-10-30 00:03:40 <warren> Luke-Jr: not yet, need to work on building the justification and convincing allies within Red Hat to help argue
13 2015-10-30 00:03:44 <gmaxwell> warren: even without SElinux, you'd just make the authcookie thing readable by group bitcoin_users and then add users you want to access the daemon to that group.
14 2015-10-30 00:04:10 <warren> gmaxwell: ok, good point
15 2015-10-30 00:04:13 <gmaxwell> warren: then you can revoke access by removing group membership and bouncing the cookie.
16 2015-10-30 00:04:46 <gmaxwell> (someone should actually test that the update mechenism doesn't nuke permissions when the file is already there. :) )
17 2015-10-30 00:04:51 <warren> This works only for clients running on the same machine.
18 2015-10-30 00:05:03 <sipa> rightfully so
19 2015-10-30 00:05:07 <warren> what update mechanism?
20 2015-10-30 00:05:14 <gmaxwell> warren: yes, absolutely, for the rest you use the normal rpcuser/password but for that you must make other configuration changes as we only bind localhost by default.
21 2015-10-30 00:05:30 <gmaxwell> warren: the rewriting the cookie on restart.
22 2015-10-30 00:05:36 <warren> ah
23 2015-10-30 00:05:42 <Luke-Jr> warren: get more signatures (we only had 6⁈) and show them this https://bitcoinmagazine.com/articles/linux-distribution-packaging-and-bitcoin-1374549783
24 2015-10-30 00:06:39 <gmaxwell> we're in the wrong channel for this, incidentally
25 2015-10-30 10:59:23 <cjcj> btcdrak: Reading through yesterdays meeting I have a question: Why did maaku stop working on CSV?
26 2015-10-30 10:59:57 <btcdrak> cjcj: I think he is just busy with other things.
27 2015-10-30 12:28:41 <jtimon> can someone remind me where are the instructions to build with the zmq stuff?
28 2015-10-30 12:30:13 <jtimon> travis says I broke something in zmqpublishnotifier.cpp and I would be able to break it locally
29 2015-10-30 12:31:15 <jtimon> https://travis-ci.org/bitcoin/bitcoin/builds/88319280
30 2015-10-30 12:32:02 <sdaftuar> jtimon: i think the doc/build-unix.md indicates the dependencies you need to build with zmq
31 2015-10-30 12:32:20 <sdaftuar> (that's about the extent of my ability to diagnose build issues though)
32 2015-10-30 12:40:01 <jtimon> ./autogen.sh
33 2015-10-30 12:40:01 <jtimon> ./configure
34 2015-10-30 12:40:01 <jtimon> sdaftuar: thanks but...
35 2015-10-30 12:40:01 <jtimon> sudo apt install libzmq3
36 2015-10-30 12:40:02 <jtimon> checking for ZMQ... no
37 2015-10-30 12:40:04 <jtimon> configure: WARNING: libzmq version 4.x or greater not found, disabling
38 2015-10-30 12:42:47 <jtimon> sdaftuar: never mind it was libzmq3-dev, thanks
39 2015-10-30 12:43:00 <sdaftuar> yep np
40 2015-10-30 15:06:11 <jcorgan> what is the url for the meeting notes from yesterday?
41 2015-10-30 15:11:23 <mcelrath> https://docs.google.com/document/d/1t3kGkAUQ-Yui57P29YhDll5WyJuTiGrUhCW8so-E-iQ/edit
42 2015-10-30 15:11:37 <mcelrath> irc logs link at bottom of that doc if that's what you want
43 2015-10-30 15:21:57 <Luke-Jr> jcorgan: [20:01:46] <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-10-29-19.02.html
44 2015-10-30 15:43:39 <jcorgan> thanks
45 2015-10-30 16:22:35 <btcdrak> response to it has been extremely warm. You wouldnt know something is controversial until find out other's opinions.
46 2015-10-30 16:22:35 <btcdrak> sipa: gmaxwell: it occurs to be sometimes the word "controversial" is being abused. A change like #6914 maybe invasive to consensus code and therefore risky, but it does not make it controversial. It's not what the word means. Controversial is how to increase blocksize, #6914 is risky maybe and requires careful review, but there isnt any controversy,
47 2015-10-30 16:27:45 <sipa> btcdrak: i'm just adding it because i would personally be fine with people saying "this is too invasive, we can't do tgat"
48 2015-10-30 16:28:06 <sipa> so it is a suggested approach
49 2015-10-30 16:37:12 <mcelrath> Oooh!  I'm getting moderated!  ;-)
50 2015-10-30 17:09:18 <hardyred> hey quick question - If I am working on connecting to a bitcoind instance running on another server
51 2015-10-30 17:09:44 <hardyred> Do I need to have my rpcconnect property in the config pointing to the specific server?
52 2015-10-30 17:13:35 <sipa> rpcconnect is an option to bitcoin-cli, not bitcoind
53 2015-10-30 17:13:47 <sipa> bitcoin-cli is a command line tool to connect to a bitcoind rpc server
54 2015-10-30 17:14:05 <sipa> presumably your application would be another client
55 2015-10-30 17:15:20 <hardyred> sipa: So if I wanted to run bitcoin-cli on one host and access bitcoind from another host
56 2015-10-30 17:16:19 <hardyred> sipa: Which option would I use to allow the remote host to access bitcoind?
57 2015-10-30 17:19:45 <sipa> -rpcallow
58 2015-10-30 17:20:11 <hardyred> Will that act basically as a wildcard?
59 2015-10-30 17:20:12 <sipa> -rpcallowip
60 2015-10-30 17:20:13 <hardyred> I keep receiving a "connection rejected: 403 forbidden"
61 2015-10-30 17:20:21 <sipa> read the fine manual :)
62 2015-10-30 17:20:26 <sipa> bitcoind --help
63 2015-10-30 17:20:46 <hardyred> Ok thanks
64 2015-10-30 17:44:27 <mcelrath> Can someone look at the list moderation?  I want to talk about my UTXO commitment idea here...
65 2015-10-30 17:46:38 <jcorgan> done
66 2015-10-30 17:46:52 <mcelrath> thanks
67 2015-10-30 17:49:17 <mcelrath> sipa: it's an iteration of the unworkable xor idea we discussed a week or so ago.
68 2015-10-30 21:14:54 <dansmith_btc> right now when building txindex all 32 bytes of txid are written. Have there been considerations to write first 4 bytes instead? If there are multiple txid with colliding first 4 bytes, just look up all of them to see which one is correct. (i assume txindex is only needed for getrawtransaction)
69 2015-10-30 21:22:13 <gmaxwell> dansmith_btc: I think that could be done, it would potentially make reorgs much more expensive.
70 2015-10-30 21:22:49 <gmaxwell> It would probably be wise to have a per node key that used to randomize the collissions so that attackers can't easily grind colliding IDs and then break txindex using nodes ability to reorg.
71 2015-10-30 21:23:11 <gmaxwell> txindex is gratitiously inefficient in many ways.
72 2015-10-30 21:24:43 <rodkeys> gmaxwell: hey were you able to check out my pm earlier?
73 2015-10-30 21:25:01 <gmaxwell> rodkeys: no been on calls, will soon.
74 2015-10-30 21:25:14 <rodkeys> gmaxwell: no problem at all, thanks