1 2013-11-22 01:15:02 <robbak> How do I get the configure script to recognise system ssl on FreeBSD?
2 2013-11-22 01:22:19 <andytoshi> robbak: is SSL in a weird path?
3 2013-11-22 01:22:33 <andytoshi> you can do, for example
4 2013-11-22 01:22:36 <andytoshi> ./configure --with-openssl=/usr/local/ssl/
5 2013-11-22 01:22:40 <andytoshi> which is what i had to do for fedora..
6 2013-11-22 01:23:19 <andytoshi> if that doesn't work, check out config.log to see how it's failing
7 2013-11-22 01:24:19 <robbak> No, only in /usr/lib/libssl.a. It's just that the script uses pkg-config, and ssl is not a added package, it's part of the system.
8 2013-11-22 01:24:43 <robbak> I'l try --with-openssl, though.
9 2013-11-22 01:35:01 <robbak> andytoshi: hmm. --with-openssl is just rejected as an 'unrecognized option'. No change.
10 2013-11-22 01:36:56 <andytoshi> really?
11 2013-11-22 01:37:02 <andytoshi> one sec..
12 2013-11-22 01:37:26 <robbak> This is with current git, by the way.
13 2013-11-22 01:37:30 <andytoshi> i'll be damned, i must've been thinking of a different project..
14 2013-11-22 01:37:35 <andytoshi> sorry,
15 2013-11-22 01:37:51 <robbak> No worries. Thanks anyway.
16 2013-11-22 01:37:53 <andytoshi> you might try LIBS=/usr/lib ./configure
17 2013-11-22 01:37:58 <andytoshi> but /usr/lib is a standard directory
18 2013-11-22 01:38:04 <andytoshi> so i think this is not a paths problem
19 2013-11-22 01:38:19 <robbak> It's trying to find it using pkg-config. That doesn't work, because it's not a package.
20 2013-11-22 01:38:22 <andytoshi> oh, i see, i missed that
21 2013-11-22 01:39:13 <andytoshi> SSL_LIBS="-lssl -lcrypto" ./configure maybe
22 2013-11-22 01:39:43 <andytoshi> four variables to set are, SSL_CFLAGS SSL_LIBS CRYPTO_CFLAGS CRYPTO_LIBS
23 2013-11-22 01:40:08 <robbak> OK. I'll try that.
24 2013-11-22 01:51:43 <lachesis> is there a bug for improving bitcoin's history download to use multiple peers?
25 2013-11-22 01:53:31 <gmaxwell> lachesis: thats the headers first pull. it's planned for 0.9.
26 2013-11-22 01:54:10 <lachesis> gmaxwell, ty
27 2013-11-22 01:54:35 <lachesis> gmaxwell, https://github.com/bitcoin/bitcoin/pull/2964?source=cc ?
28 2013-11-22 01:55:17 <gmaxwell> lachesis: yea.
29 2013-11-22 02:08:30 <robbak> andytoshi; found it. I need to set
30 2013-11-22 02:08:32 <robbak> CRYPTO_LIBS
31 2013-11-22 02:08:33 <robbak> CRYPTO_CFLAGS
32 2013-11-22 02:08:35 <robbak> SSL_LIBS
33 2013-11-22 02:08:36 <robbak> SSL_CFLAGS
34 2013-11-22 02:09:30 <robbak> I'll have to work out what to set those CFLAGS to.
35 2013-11-22 02:09:56 <mappum> how long is the longest blockchain fork so far?
36 2013-11-22 02:10:36 <Luke-Jr> 100 or so?
37 2013-11-22 02:11:10 <mappum> oh, was that the one caused by compatibility issues in a btcoin-qt version?
38 2013-11-22 02:11:56 <andytoshi> robbak: cool, probably just -I/usr/include/ssl
39 2013-11-22 02:13:09 <Luke-Jr> mappum: that was before bitcoin-qt
40 2013-11-22 02:40:13 <gmaxwell> BlueMatt: WTF! https://github.com/bitcoin/bitcoin/pull/3301 :P
41 2013-11-22 02:40:16 <gmaxwell> why did that pass?
42 2013-11-22 02:41:56 <BlueMatt> hah, nice
43 2013-11-22 02:42:14 <gmaxwell> I'm bummed, it would have been great if the bot rejected it.
44 2013-11-22 02:42:22 <BlueMatt> because pull-tester sucks?
45 2013-11-22 02:43:09 <BlueMatt> yea, I have to admit, Im kinda surprised that test-case isnt in there
46 2013-11-22 02:43:25 <BlueMatt> but, hell, we've always known pull-tester sucks, just more proof :p
47 2013-11-22 02:46:59 <Luke-Jr> gmaxwell: because it's essentially a no-op
48 2013-11-22 02:47:09 <Luke-Jr> gmaxwell: MAX_MONEY is only used for some stupid light value checking
49 2013-11-22 02:47:13 <Luke-Jr> not for anything important
50 2013-11-22 05:34:06 <BlueMattBot> Project Bitcoin build #471: FAILURE in 44 min: http://jenkins.bluematt.me/job/Bitcoin/471/
51 2013-11-22 06:01:35 <dexX7> hey, is "[datajunk] OP_DROP" for some reason not allowed? my tx are decoded properly, also signed, but rejected when i try to push them..
52 2013-11-22 06:15:31 <dexX7> also an output with only OP_TRUE..
53 2013-11-22 07:39:22 <pZombie> test
54 2013-11-22 07:39:32 <pZombie> Anyone there?
55 2013-11-22 07:42:35 <tgs3> pZombie: no, just you and 443 zombie
56 2013-11-22 07:42:51 <tgs3> including 2 zombieops
57 2013-11-22 07:42:57 <pZombie> :>
58 2013-11-22 07:45:09 <bitspill> gribble isn't going to answer any questiosn though
59 2013-11-22 07:45:23 <bitspill> unless you know how to talk right to it
60 2013-11-22 07:45:37 <bitspill> ;;gribble
61 2013-11-22 07:45:37 <gribble> yes I am gribble. why do you keep bothering me?
62 2013-11-22 07:45:58 <gribble> Of course.
63 2013-11-22 07:45:58 <pZombie> ;;8ball are there more than 2 people alive in this chat?
64 2013-11-22 07:46:51 <pZombie> Anyway, just wanted to ask if there is a thinkable method to split the work on a single block between miners, in a way that would allow to decentralize the network by allowing everyone to solo mine
65 2013-11-22 07:47:34 <pZombie> without compromising security
66 2013-11-22 07:47:58 <bitspill> pZombie, only think I could think of is: reduce difficulty and reduce the block reward similarly
67 2013-11-22 07:48:15 <bitspill> pZombie, then more blocks would be found but coins would dispense at the same rate
68 2013-11-22 07:48:16 <pZombie> no, that would lower security i think
69 2013-11-22 07:49:03 <pZombie> yes, i already thought about your method, but i was not sure if that would lower security
70 2013-11-22 07:49:23 <pZombie> are you saying that with lower difficulty the bitcoin would remain just as secure?
71 2013-11-22 07:49:47 <bitspill> dunno, but that is basically the entire discussion over altcoins with a fast block time
72 2013-11-22 07:49:52 <pZombie> if so, a dynamically adjusting block reward, rather than difficulty adjusting, would make more sense to me
73 2013-11-22 07:50:07 <gavinandresen> pZombie: you're about to reinvent p2pool, I think
74 2013-11-22 07:51:22 <bitspill> hey, the 8ball didn't lie to us ;)
75 2013-11-22 07:51:23 <pZombie> damn, i think you are right
76 2013-11-22 07:51:42 <pZombie> except, p2pool is on it's "own" network
77 2013-11-22 07:53:42 <wumpus> yes, p2pool is great, it should be used more
78 2013-11-22 07:54:05 <iwilcox> With CPUs though? I think that's where pZombie is going with this.
79 2013-11-22 07:55:37 <pZombie> i think the reason why p2pool is not used more, is because it's not so easy for people to set it up properly
80 2013-11-22 07:56:23 <pZombie> also, the client could possibly build several p2pool networks automatically, and merge enough miners together that are close to each other
81 2013-11-22 07:56:25 <JyZyXEL> wumpus: sadly, centralized services are still what most of people use because they feel more familiar
82 2013-11-22 07:57:33 <wumpus> JyZyXEL: sure, that's why I said 'should', at least to make the network more decentralized, but yes it appears people are ok with a more centralized network
83 2013-11-22 07:58:20 <pZombie> you have to force people to decentralize it. Not everyone is in for the good of bitcoin, but many are in just for the quick buck
84 2013-11-22 07:58:25 <JyZyXEL> it's the traditional way of doing things that we've all gotten so used to, decentralization is still not well understood by the masses
85 2013-11-22 07:58:27 <wumpus> the only way I see it changing is if big mining pools start to misbehave
86 2013-11-22 07:58:48 <Luke-Jr> better if the big pools adopt decentralised mining
87 2013-11-22 07:59:33 <wumpus> pZombie: I don't think the point is to force people to do anything :)
88 2013-11-22 07:59:41 <pZombie> yes it is
89 2013-11-22 08:00:06 <pZombie> if your currency relies on the goodwill of people and people not being greedy, you are dreaming
90 2013-11-22 08:00:24 <pZombie> you might as well ditch it from the beginning
91 2013-11-22 08:00:26 <wumpus> it's too big anyhow to be forced anything by anyone
92 2013-11-22 08:00:44 <Luke-Jr> pZombie: you can't force it
93 2013-11-22 08:01:01 <Luke-Jr> if you break centralised pools, people will just go all cex.io
94 2013-11-22 08:03:59 <pZombie> yes, i guess it's just too convenient for people just to fire up cgminer with name being the payout address and start mining instantly, without having to care about setting up a node that connects to p2pool, downloading the whole chain and whatnot
95 2013-11-22 08:04:21 <JyZyXEL> i wonder if satoshi realized we would be building centralized mining on top of his nice decentralized system
96 2013-11-22 08:05:45 <pZombie> so if you really want people to join decentralized mining, it would have to be a one button push
97 2013-11-22 08:05:50 <pZombie> not sure if that is doable
98 2013-11-22 08:08:06 <pZombie> and not sure if it is doable for the client to match up the various nodes into many little p2pool networks, refusing to let in nodes with too high hashrate, adjusting dynamically as new better ASICs come out
99 2013-11-22 08:09:20 <pZombie> like checking for the hashrate first, then match various IPs that are relatively close to each other in a p2pool with about 10-50 TH each
100 2013-11-22 08:09:57 <pZombie> if someone comes in with a single IP having over 5 TH, he won't be allowed in, until tech advances
101 2013-11-22 08:10:45 <petertodd> pZombie: in summary it appears that it is possible to create *a* crypto-currency system where all activities can be "sharded" such that only a relatively-bandwidth connection is required for any one node, but research is ongoing...
102 2013-11-22 08:11:16 <Luke-Jr> pZombie: it's doable, so long as they have a full node
103 2013-11-22 08:12:00 <petertodd> pZombie: here's an very simple example: https://bitcointalk.org/index.php?topic=88208.msg2445569#msg2445569
104 2013-11-22 08:12:11 <Luke-Jr> pZombie: when I finally get the time, I'm going to make BFGMiner implement GBT completely, so it gets transactions etc from local bitcoind, and still coordinates with a pool server
105 2013-11-22 08:12:25 <Luke-Jr> which is as decentralised as p2pool as far as bitcoin is concerned
106 2013-11-22 08:16:34 <pZombie> good to know you guys are working on such stuff
107 2013-11-22 08:17:22 <pZombie> and there are actually some nice people in the bitcoin community still, being honorable
108 2013-11-22 08:17:45 <petertodd> pZombie: thanks, though it's going to take a long time to turn it into something concrete - even the analysis of the current system is still very immature
109 2013-11-22 08:24:00 <petertodd> Luke-Jr: does eligius have logs with timestamps for when work was pushed to specific hashers?
110 2013-11-22 08:24:15 <Luke-Jr> petertodd: not long-term
111 2013-11-22 08:24:40 <Luke-Jr> that'd get *way* too big :/
112 2013-11-22 08:25:11 <Luke-Jr> even with stratum, that's every 55 seconds
113 2013-11-22 08:25:18 <petertodd> Luke-Jr: ah, but you do have them for a short period of time? might be interesting to figure out the distribution, especially the minimums, of the delta t between when work is pushed out, and you get a new share from a miner
114 2013-11-22 08:25:31 <Luke-Jr> petertodd: maybe
115 2013-11-22 08:25:47 <Luke-Jr> minimums are 0 of course
116 2013-11-22 08:26:02 <Luke-Jr> + network latency
117 2013-11-22 08:26:17 <petertodd> Luke-Jr: + miner hardware and software latency
118 2013-11-22 08:26:31 <Luke-Jr> which is often insignificant
119 2013-11-22 08:27:16 <petertodd> Luke-Jr: I'm not so sure it is actually...
120 2013-11-22 08:27:28 <petertodd> Luke-Jr: but anyway, good to know you have it
121 2013-11-22 08:27:42 <Luke-Jr> we couldn't expire old work without it :p
122 2013-11-22 08:27:53 <petertodd> Luke-Jr: ah, good point
123 2013-11-22 08:30:57 <petertodd> Luke-Jr: the thing is it's a consideration in the analysis I was doing of expected return for blocks - my analysis is really missing states and a second latency constant because of it, although it might actually make the model more simple rather than less
124 2013-11-22 08:32:33 <Luke-Jr> petertodd: BFL and Bitfury chips can't stop work
125 2013-11-22 08:32:57 <petertodd> Luke-Jr: so that gives them, what, 1s latency minimum or something?
126 2013-11-22 08:33:02 <Luke-Jr> older KnC images had some delay changing work too
127 2013-11-22 08:33:06 <Luke-Jr> depends on hashrate
128 2013-11-22 08:33:11 <Luke-Jr> those are the only major dissidents from changing work quickly, I think
129 2013-11-22 08:33:29 <petertodd> Luke-Jr: I thought even the ASIC BFL's were internally comprised of a bunch of chips that individually can't stop work
130 2013-11-22 08:33:53 <Luke-Jr> petertodd: this is true, but BFL-based devices always split work across them
131 2013-11-22 08:34:05 <Luke-Jr> also true of bitfury
132 2013-11-22 08:34:21 <petertodd> Luke-Jr: oh! so they give the chips different parts of the nonce-range?
133 2013-11-22 08:34:24 <Luke-Jr> yes
134 2013-11-22 08:34:36 <Luke-Jr> Chili (BFL-based) splits it across 8 chips
135 2013-11-22 08:35:57 <Polyatomic> have you got some of those luke . Is it true they mine really efficiently on p2pool
136 2013-11-22 08:36:40 <petertodd> Luke-Jr: see, in section 3.2 of https://people.xiph.org/~greg/peter_todd_mining_ev.pdf state 2 is the miner finds another block prior to full propagation, but if t_miner ~= t_prop that can't happen
137 2013-11-22 08:37:41 <Luke-Jr> Polyatomic: I would imagine so
138 2013-11-22 08:37:42 <petertodd> Luke-Jr: however, state 3, particularly 3.1, still can happen
139 2013-11-22 08:52:36 <Luke-Jr> my whole USB subsystem died :<
140 2013-11-22 08:52:42 <Luke-Jr> ACTION stabs Linux for not being more stable
141 2013-11-22 08:53:44 <tgs3> Luke-Jr: does unplugging eth cable fix it?
142 2013-11-22 08:54:00 <Luke-Jr> tgs3: eth? why would it?
143 2013-11-22 08:54:08 <tgs3> I seen such a bug
144 2013-11-22 08:54:11 <Luke-Jr> O.o
145 2013-11-22 08:54:28 <tgs3> so, does it?
146 2013-11-22 08:54:36 <Luke-Jr> no
147 2013-11-22 09:38:10 <sipa> dexX7: that's a non standard script, which is valid in a block but won't be relayed on its own or accepted into memory pools
148 2013-11-22 09:39:42 <sipa> dexX7: there is a more modern mechanism (using an op_return output) that you can use, but really: ask yourself whether it's really necessary to store data
149 2013-11-22 09:40:10 <dexX7> ah thanks. i was just playing around to get a better understanding. :)
150 2013-11-22 09:42:34 <dexX7> it appears that eligius broadcasted one of the tx with OP_DROP
151 2013-11-22 09:45:38 <dexX7> i'm unable to sign a tx that tries to redeem the output with signrawtransaction though ... tx: https://blockchain.info/tx/48e7694b3de213e2ab36cfcfaaa3013a22e1a5dc28168772cb01be99f91a12fa
152 2013-11-22 09:57:20 <stonecoldpat> guys to run stuff like autogen.sh on mac (to start building bitcoin) - what package did you install?
153 2013-11-22 10:00:59 <TD> stonecoldpat: autotools
154 2013-11-22 10:03:26 <robbak> It's parts, or all, or the autotools package.
155 2013-11-22 10:33:28 <tommygunner> can i make the client tell me the transaction size instead of suggesting i pay X fee?
156 2013-11-22 10:35:09 <warren> tommygunner: use Bitcoin 0.8.5 OMG3 (with Coin Control that tells you the tx size before sending)
157 2013-11-22 10:35:32 <tommygunner> hm. weird clients
158 2013-11-22 10:35:49 <wumpus> indeed, with coin control (will also be in 0.9) you can
159 2013-11-22 10:36:31 <tommygunner> i guess thats what i need to use then
160 2013-11-22 10:37:01 <tommygunner> i hope that client can just use the blockchain files of original Qt?
161 2013-11-22 10:38:05 <wumpus> yes
162 2013-11-22 10:38:36 <wumpus> it is the original bitcoin-qt with a few extra patches
163 2013-11-22 10:39:20 <tommygunner> doing a little bit of consolidation
164 2013-11-22 10:39:47 <tommygunner> so i guess the OMG client works with the free transaction relay policy?
165 2013-11-22 10:48:45 <tommygunner> except if Luke-Jr banned that client :P
166 2013-11-22 12:28:44 <acidhacker> Hi bitcoin hackers! I'm building on OSX with homebrew and my configure step fails with 'no working boost sleep implementation found'.
167 2013-11-22 12:28:59 <acidhacker> This seems to happen because boost include dirs are not set when calling AC_TRY_LINK (in configure.ac)
168 2013-11-22 12:29:35 <acidhacker> adding the BOOST_INCLUDES to the CPPFLAGS solves the problem
169 2013-11-22 12:29:37 <acidhacker> CPPFLAGS="$CPPFLAGS $BOOST_CPPFLAGS"
170 2013-11-22 12:30:33 <acidhacker> is it a good idea to do this in configure.ac ?
171 2013-11-22 12:33:12 <wumpus> acidhacker: see https://github.com/bitcoin/bitcoin/issues/3003
172 2013-11-22 12:33:26 <Luke-Jr> acidhacker: added to https://github.com/bitcoin/bitcoin/pull/3242
173 2013-11-22 12:34:10 <acidhacker> yes, that is it
174 2013-11-22 12:35:25 <Luke-Jr> guess there's a bit of overlap >_<
175 2013-11-22 12:42:02 <acidhacker> Luke, your solution fixes ./configure, but then make fails:
176 2013-11-22 12:42:09 <acidhacker> ./allocators.h:13:10: fatal error: 'boost/thread/mutex.hpp' file not found
177 2013-11-22 12:42:09 <acidhacker> #include <boost/thread/mutex.hpp>
178 2013-11-22 12:42:56 <acidhacker> I guess boost include paths are not added anywhere else.
179 2013-11-22 12:43:06 <acidhacker> (and they're not in my system path)
180 2013-11-22 12:43:08 <Luke-Jr> acidhacker: did you try the actual branch, or just that one change?
181 2013-11-22 12:43:16 <acidhacker> just that one change
182 2013-11-22 12:43:54 <acidhacker> let me try the branch
183 2013-11-22 12:44:50 <Luke-Jr> acidhacker: I just pushed an update to it - try that
184 2013-11-22 12:47:33 <michagogo> cloud|Interesting -- I accidentally left my node running overnight (forgot my laptop was on)
185 2013-11-22 12:47:52 <michagogo> cloud|I've got 50 connections, of which 19 are tor (127.0.0.1)
186 2013-11-22 12:51:34 <michagogo> cloud|31 peers on 0.8.5, 5 each on 0.8.1 and 0.8.3, 2 each on 0.8.2.2 (?) and "" (?!?), and one each of the relay peer, 0.8.99, 0.7.2, 0.8.0, and 0.8.4
187 2013-11-22 12:58:40 <acidhacker> Luke-Jr: branch autoconf_pt3 builds fine.
188 2013-11-22 12:58:49 <damethos> can someone tell me what is the max transaction size in testnet?
189 2013-11-22 12:58:50 <acidhacker> thanks !
190 2013-11-22 12:59:06 <Luke-Jr> acidhacker: please leave a comment saying so
191 2013-11-22 13:01:36 <acidhacker> ok done
192 2013-11-22 13:02:47 <michagogo> cloud|damethos: Same as mainnet
193 2013-11-22 13:03:12 <michagogo> cloud|damethos: Testnet is like mainnet, except with IsStandard disabled and the 20-minute rule
194 2013-11-22 13:03:35 <damethos> ah i see
195 2013-11-22 13:17:30 <michagogo> cloud|(well, and parameters like genesis block and netmagic)
196 2013-11-22 13:19:04 <michagogo> cloud|Oh, is cfields theuni?
197 2013-11-22 13:19:29 <Luke-Jr> yes
198 2013-11-22 13:28:06 <michagogo> cloud|Okay, that's another one for the list
199 2013-11-22 13:28:36 <michagogo> cloud|(it took me a very, very long time to realize that wumpus == laanwj)
200 2013-11-22 13:29:16 <wumpus> :D
201 2013-11-22 13:56:47 <Subo1977> michagogo|cloud: where did you see the Clientversion of your connections?
202 2013-11-22 13:56:59 <michagogo> cloud|subver field of getpeerinfo
203 2013-11-22 13:58:59 <Subo1977> michagogo|cloud: thx
204 2013-11-22 14:00:06 <Subo1977> "subver" : "/Satoshi:0.8.99/Gangnam Style:2.1/", whats this?
205 2013-11-22 14:05:56 <damethos> lol thats funny
206 2013-11-22 14:10:31 <michagogo> cloud|Subo1977: read the mailing list
207 2013-11-22 14:10:46 <Subo1977> ok
208 2013-11-22 14:12:20 <michagogo> cloud|;;google lucky --snippet bitcoin development mailing list archives
209 2013-11-22 14:12:21 <gribble> http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development | Mailing Lists ... Email Archive: bitcoin-development (read-only) ... Re: [Bitcoin- development] Even simpler minimum fee calculation formula: f > bounty*fork_rate /Â ...
210 2013-11-22 14:12:28 <michagogo> cloud|Subo1977: ^
211 2013-11-22 14:56:34 <damethos> just found a tx in testnet with a 0.95MB output
212 2013-11-22 14:56:35 <damethos> fun
213 2013-11-22 15:05:36 <helo> on HEAD startup, getting ERROR: CDB() : error Invalid argument (22) opening database environment
214 2013-11-22 15:13:14 <helo> Error initializing wallet database environment /home/helo/.bitcoin!
215 2013-11-22 15:20:19 <tommygunner> gogogo BIP 0038
216 2013-11-22 15:28:32 <helo> fails even when starting with a totally empty (aside from rpcuser/pw in conf)
217 2013-11-22 15:28:49 <tommygunner> do you have write access
218 2013-11-22 15:28:53 <tommygunner> disk space
219 2013-11-22 15:29:16 <helo> apparently db5.1 is totally broken, rather than just breaking backward compat
220 2013-11-22 15:29:21 <helo> yeah
221 2013-11-22 15:30:17 <sipa> the database files are backward compatible
222 2013-11-22 15:30:26 <sipa> the database environment is totally non-compatible
223 2013-11-22 15:30:40 <sipa> so after a clean shutdown you can change versions, but not otherwise
224 2013-11-22 15:30:45 <bitnumus> hi, what is 'time_offset' ?
225 2013-11-22 15:31:11 <bitnumus> "timeoffset" : -73,
226 2013-11-22 15:31:18 <Happzz> lag?
227 2013-11-22 15:31:30 <Happzz> tslb?
228 2013-11-22 15:31:42 <sipa> your measured average clock difference with your peers
229 2013-11-22 15:31:57 <bitnumus> sipa ah thought it would be something like that
230 2013-11-22 15:31:59 <bitnumus> :)
231 2013-11-22 15:32:00 <bitnumus> ta
232 2013-11-22 15:32:08 <Ry4an> in seconds or millis?
233 2013-11-22 15:32:12 <sipa> seconds
234 2013-11-22 15:33:06 <Subo1977> helo: i run db6.0 on ubuntu without probs
235 2013-11-22 15:33:13 <helo> hmm... HEAD?
236 2013-11-22 15:33:46 <sipa> helo: check db.log
237 2013-11-22 15:33:59 <sipa> it may tell you why it couldn't initialize the wallet env
238 2013-11-22 15:34:16 <helo> ahh, "illegal flag combination specified to DB_ENV->open"
239 2013-11-22 15:34:24 <sipa> huh
240 2013-11-22 15:34:30 <sipa> sure you're using 5.1?
241 2013-11-22 15:35:17 <helo> odd... i had to specify --with-incompatible-bdb, but it is linked to a db4.8 sitting happily in /usr/lib/
242 2013-11-22 15:35:55 <helo> must have conflicting installs
243 2013-11-22 15:37:44 <helo> oh, the ppa is pulling in its own db4.8
244 2013-11-22 15:37:58 <helo> i thought it was statically compiled
245 2013-11-22 15:38:15 <helo> *linked
246 2013-11-22 15:44:11 <gulli> Trying to wrap my head around HD wallets and how they work
247 2013-11-22 15:44:13 <gulli> https://bitcointalk.org/index.php?topic=19137.0
248 2013-11-22 15:44:19 <gulli> is the seed some random string?
249 2013-11-22 15:44:57 <sipa> ideally
250 2013-11-22 15:45:44 <sipa> it's the real secret
251 2013-11-22 15:46:40 <tommygunner> the 12 words that electrum wants you to print for example
252 2013-11-22 15:47:27 <sipa> in that case you'll want to preprocess it first into a secret, using some key strengthening
253 2013-11-22 15:48:59 <gulli> I was just thinking about gerenating a random private key and using that as the seed, backing it up on paper ofcourse
254 2013-11-22 15:49:22 <sipa> you can
255 2013-11-22 15:49:34 <sipa> though it's not really a private key - it has no corresponding public key
256 2013-11-22 15:49:40 <sipa> it's just a seed from which keys are generated
257 2013-11-22 15:49:56 <tommygunner> gulli: BIP 0038
258 2013-11-22 15:50:13 <sipa> please don't use that for wallets
259 2013-11-22 15:50:20 <sipa> as it relies on a single-key model
260 2013-11-22 15:50:21 <gulli> sipa, yeah I know, just mean use the same algorithm :)
261 2013-11-22 15:50:36 <sipa> it's fine for transferring single-use keys, like physical coins
262 2013-11-22 15:57:10 <gmaxwell> BIP 0038 has a messy history and is likely to be replaced soon.
263 2013-11-22 15:58:51 <tommygunner> oh
264 2013-11-22 15:59:20 <tommygunner> what is your suggestion as to how i store a non trivial amount of bitcoin?
265 2013-11-22 15:59:42 <stonecoldpat> guys, where is the code for stuff like 'getblockcount()?'
266 2013-11-22 16:00:09 <stonecoldpat> tommygunner: write it on a sticky note, and bury it under the ground
267 2013-11-22 16:00:48 <stonecoldpat> its ok ive found it in rpcblockchain
268 2013-11-22 16:00:52 <tommygunner> i thought about xoring the private key
269 2013-11-22 16:01:18 <tommygunner> but then i realized thats what BIP 0038 kind of is about
270 2013-11-22 16:01:24 <tommygunner> and thought about using it instead
271 2013-11-22 16:04:43 <cfields> ping devrandom
272 2013-11-22 16:23:50 <K1773R> why does bitcoin use /dev/urandom and not /dev/random?
273 2013-11-22 16:26:21 <BlueMatt> why would you use /dev/random?
274 2013-11-22 16:26:58 <stonecoldpat> does /dev/urandom not use /dev/random anyway?
275 2013-11-22 16:27:35 <K1773R> BlueMatt: in case you have a HWRNG
276 2013-11-22 16:27:57 <BlueMatt> if you have a HWRNG, it should be piping its randomness into the urandom seed
277 2013-11-22 16:28:00 <BlueMatt> and then its just as good...
278 2013-11-22 16:28:06 <K1773R> stonecoldpat: well kinda, /dev/urandom is seeded with a PRNG algo from /dev/random
279 2013-11-22 16:28:14 <K1773R> hmm, right!
280 2013-11-22 16:28:27 <K1773R> totally forgot tha
281 2013-11-22 16:28:31 <kjj> if you trust your HW more than you trust the kernel, you should use it directly.
282 2013-11-22 16:28:49 <kjj> but, you should carefully consider whether you really trust your HW more, and why
283 2013-11-22 16:28:51 <stonecoldpat> and i was gonna ask - as i am a noob with c++, i'm trying to use cout << in the main bitcoind program to print out some words, but the only way i can get printing to screen is to return a 'Value' using one of the rpc methods (i created my own method that looks like getbitcoincount and gave it a silly name)
284 2013-11-22 16:28:58 <jgarzik_> if you have a HWRNG, you should be using rngd
285 2013-11-22 16:29:18 <gmaxwell> K1773R: it's constantly reseeded with the same random sources. The distinction is primarly just that one blocks based on an estimator, which if correct (it's not) means the output has information theoretic security.
286 2013-11-22 16:29:20 <K1773R> kjj: i dont trust my HW than my linux kernel.
287 2013-11-22 16:29:35 <kjj> as far as I can tell, there are no cheap HW devices available in the US
288 2013-11-22 16:29:51 <gmaxwell> Entropykey ... but I think they've imploded or something.
289 2013-11-22 16:29:59 <K1773R> jgarzik_: i do use rngd :)
290 2013-11-22 16:30:17 <kjj> gmaxwell: in the UK. I think they'll ship to the US, but I'm not going to get a google wallet to find out
291 2013-11-22 16:30:18 <K1773R> gmaxwell: i ordered some entropykeys half a year back, i never got something...
292 2013-11-22 16:30:41 <gmaxwell> kjj: as K1773R just mentioned, they're not shipping anything now.
293 2013-11-22 16:30:43 <kjj> and in this era, how can you really trust it?
294 2013-11-22 16:31:02 <K1773R> gmaxwell: u know why? got some references?
295 2013-11-22 16:31:27 <K1773R> gmaxwell: all i saw is "will ahve huge delays" or similiar on their order page recently (but not back when i ordered)
296 2013-11-22 16:31:41 <gmaxwell> K1773R: I'd seen some commentary from someone who heard from them, it sounded like someone died or something.
297 2013-11-22 16:32:04 <K1773R> uh, crap
298 2013-11-22 16:32:21 <damethos> hey BlueMatt
299 2013-11-22 16:32:30 <damethos> :D
300 2013-11-22 16:32:35 <BlueMatt> hi
301 2013-11-22 16:35:00 <damethos> made bitcoinj explode earlier with a 0.95MB output
302 2013-11-22 16:35:22 <damethos> well, more like java not bitcoinj
303 2013-11-22 16:39:39 <BlueMatt> hah, nice
304 2013-11-22 16:40:28 <damethos> BlueMatt, wrapping up testnet support and will publish it soon
305 2013-11-22 16:40:48 <damethos> blockexplorer.com got f00ked so this will probably be the only one around for now :p
306 2013-11-22 16:40:55 <BlueMatt> nice
307 2013-11-22 16:40:59 <BlueMatt> (finally)
308 2013-11-22 16:42:51 <damethos> the output was in testnet btw
309 2013-11-22 17:08:28 <diki> blockexplorer.com has expired
310 2013-11-22 17:08:46 <diki> I do suppose no one was interested in it.
311 2013-11-22 17:09:01 <diki> but will it be back?
312 2013-11-22 17:11:26 <damethos> it wasnt working that well anyway
313 2013-11-22 18:04:23 <diki> Who was it that presumably mined block 30-40k?
314 2013-11-22 18:04:46 <diki> I see a lot of coins that originate from blocks that old being the inputs of outputs
315 2013-11-22 18:12:04 <devrandom> cfields: hi
316 2013-11-22 18:24:21 <deantrade> Hello all
317 2013-11-22 18:24:57 <deantrade> So I've developed my own bitcoin coin verification software... and I've been thinking about the transaction lookup/spend data structure
318 2013-11-22 18:25:45 <deantrade> Here's my idea on how it could be improved: 1st, don't store as 1x table. Instead store as many tables
319 2013-11-22 18:26:17 <deantrade> The general process would be that first you'd use one table for the current block, and for the previous block
320 2013-11-22 18:26:43 <deantrade> but once you have 3x blocks of transactions, the 1st and 2nd would be merged into one table, while the latest block would still stay in its own table
321 2013-11-22 18:28:18 <deantrade> The tables would grow like this: 1, 1 1, 2 1, 2 1 1, 2 2 1, 2 2 1 1, 4 2 1, 4 2 1 1, 4 2 2 1, 4 2 2 1 1, 4 4 2 1, ...
322 2013-11-22 18:29:02 <deantrade> Basically you don't allow more than 2x tables to contain the same number of blocks
323 2013-11-22 18:29:45 <deantrade> This could potentially result in excellent improvement in locality and insert performance.
324 2013-11-22 18:30:54 <deantrade> crickets... I guess you guys are all busy watching the bitcoin price?
325 2013-11-22 18:32:13 <tommygunner> give them some time
326 2013-11-22 18:32:32 <tommygunner> or, -> github
327 2013-11-22 18:33:39 <deantrade> I think this data structure would be awsome also because it doesn't require in-memory indexes for old transaction lookup. You'd be able to do a binary search directly on the disk for older tables/block's transactions. O(ln2(N))
328 2013-11-22 18:33:43 <Eliel> deantrade: There's probably not too many people who understand the code you're talking about enough to be able to comment. It's likely going to take a while until one of them is active.
329 2013-11-22 18:34:58 <deantrade> So you'd not have to sit around while the database indexes initialize into memory, very small DRAM requirements while still maintainnig fast O(ln2(N)) lookup
330 2013-11-22 18:35:49 <deantrade> So that would be better for people like me who stop and start their bitcoin database process frequently
331 2013-11-22 18:36:09 <deantrade> Is there a place on github or somewhere where I can post this suggestion?
332 2013-11-22 18:36:54 <Eliel> What I can say is that this is a complex enough topic that you'll likely need to be able to demonstrate the effect for people to get excited. That means implementing it and showing through benchmarks that it actually speeds things up.
333 2013-11-22 18:37:40 <Eliel> there's the bug / feature request tracker at least.
334 2013-11-22 18:38:43 <deantrade> Fair enough. I guess I'll post the idea as a feature request on github, and then also test it on my own bitcoin transaction verifier client when I get the time
335 2013-11-22 18:39:57 <deantrade> Eliel: I implemented multithreading in my client for transaction signature verification... does the official client do that?
336 2013-11-22 18:40:09 <gmaxwell> deantrade: uhh. we don't use in-memory indexes for transaction lookups.
337 2013-11-22 18:40:42 <gmaxwell> Yes, it does.
338 2013-11-22 18:41:19 <deantrade> gmaxwell: ohyea I guess you are right, the official bitcoin client does load up pretty fast.
339 2013-11-22 18:41:34 <gmaxwell> in fact, we don't index most transactions at all.
340 2013-11-22 18:42:04 <deantrade> Its been a year or so since I've looked at the official bitcoin code
341 2013-11-22 18:42:17 <gmaxwell> deantrade: 99% of the startup time is sanity tests that we do on starup. E.g. we rewind the last 288 blocks and play them forward again and make sure that the resulting states agree.
342 2013-11-22 18:42:48 <deantrade> Does it still store DiskTransactions in a single KVP table: transactionHash->DiskTransaction?
343 2013-11-22 18:43:19 <gmaxwell> No. It doesn't have any way to look up most transactions at all, as I just mentioned.
344 2013-11-22 18:43:51 <gmaxwell> all validation is now done against a (currently) ~256 mbyte data structure.
345 2013-11-22 18:44:18 <deantrade> So you just pretty much keep the unspent transactions indexed?
346 2013-11-22 18:44:37 <gmaxwell> Unspent transaction outputs, not the whole transactions.
347 2013-11-22 18:45:16 <gmaxwell> This is most of the reason why 0.8 was roughly 40x faster than prior versions.
348 2013-11-22 18:45:52 <deantrade> Sounds good. So this is a major performance improvement for most use cases of the block chain
349 2013-11-22 18:46:12 <deantrade> But if you want to look up a particular transaction by its hash... then that sucks really bad O(N)
350 2013-11-22 18:46:27 <deantrade> Right?
351 2013-11-22 18:47:01 <gmaxwell> You can optionally turn on an index for historical transactions, but it's not used by normal network operation. It's mostly useful to people using the raw transactions api to build block explorer like things.
352 2013-11-22 18:47:30 <gmaxwell> That index adds about 1gb of additional storage.
353 2013-11-22 18:47:44 <diki> Do you guys have any idea who it might be that moved around 200k coins?
354 2013-11-22 18:48:30 <deantrade> diki, I donno who, but with the bitcoin price going up, I think now more than ever people are starting to worry about tracability
355 2013-11-22 18:49:00 <diki> deantrade:My tracing skills are not very good but I think it might be that pizza guy lazslo
356 2013-11-22 18:49:24 <deantrade> gmaxwell: thanks for your input. I'll have to consider doing a similar thing for my client.
357 2013-11-22 18:50:31 <gmaxwell> ACTION continues to be sad that people are spending time reinventing the wheel instead of advancing things forward
358 2013-11-22 18:51:08 <warren> "FYI, I waited a few days and opened the OMG3-beta client again and it healed itself. Verified the database just fine."
359 2013-11-22 18:51:15 <deantrade> gmaxwell: hey, another question... so when you drop a transactions outputs from the unspent table, you then lose O(ln2(N)) access of where a transaction output is spent?
360 2013-11-22 18:51:48 <gmaxwell> deantrade: sure. Its not needed.
361 2013-11-22 18:52:00 <gmaxwell> (the old txindex methods didn't have that in any case)
362 2013-11-22 18:53:24 <deantrade> gmaxwell: have you seen the mini-blockchain w/ account hash tree idea?
363 2013-11-22 18:53:50 <gmaxwell> deantrade: https://bitcointalk.org/index.php?topic=21995.0
364 2013-11-22 18:54:07 <petertodd> gmaxwell: heh, you beat me too it
365 2013-11-22 18:54:54 <deantrade> k, I'll read into your response
366 2013-11-22 19:00:16 <deantrade> gmaxwell: I agree with your criticisms, although I do not think they are critical issues that would prevent the system from being a useful and efficient money system.
367 2013-11-22 19:02:24 <deantrade> Say for example if such a system could be made w/ O(1) transaction verification and was less complex computationally and required less data storage then bitcion, then potentially transaction fees could be lower and more clients could do ledger verifcation
368 2013-11-22 19:04:35 <gulli> I'm checking out bitcoinj's HD classes and tests
369 2013-11-22 19:05:26 <gulli> in one test the string (which will be used as a seed code I think) a method Hex.decode is used
370 2013-11-22 19:05:43 <gulli> on the string itself, which is aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
371 2013-11-22 19:05:59 <gulli> Like this: byte[] priv = Hex.decode(ckdTestVectors[3 * i]);
372 2013-11-22 19:06:18 <gulli> where the ckdTestVectors[0] is the string
373 2013-11-22 19:06:31 <gulli> why use Hex.decode, anyone know?
374 2013-11-22 19:07:21 <gulli> seems you could just use .getBytes() on the string itself
375 2013-11-22 19:14:28 <sipa> because getBytes doesn't do hex decoding, afaik?
376 2013-11-22 19:15:51 <sipa> or you mean writing the string as "\x12\x34..." ?
377 2013-11-22 19:16:17 <sipa> the bip32 test vectors are specified in hex, so it's probably easier to just copy them
378 2013-11-22 19:17:31 <cfields> devrandom: still around?
379 2013-11-22 19:19:31 <gulli> sipa ahh ok thanks
380 2013-11-22 19:20:51 <gulli> but I dont have to worry about this though if Im not using the test vectors
381 2013-11-22 19:20:54 <gulli> right
382 2013-11-22 19:24:31 <sipa> you should...
383 2013-11-22 19:24:49 <sipa> (if you're reimplementing bip32)
384 2013-11-22 19:34:30 <jgarzik_> grrr
385 2013-11-22 19:34:38 <jgarzik_> configure shits itself on latest ubuntu
386 2013-11-22 19:34:50 <jgarzik_> ^
387 2013-11-22 19:34:50 <jgarzik_> ;
388 2013-11-22 19:34:50 <jgarzik_> conftest.cpp:35:3: warning: statement has no effect [-Wunused-value]
389 2013-11-22 19:34:50 <jgarzik_> conftest.cpp:35:3: warning: statement is a reference, not call, to function 'boost::system::system_category' [-Waddress]
390 2013-11-22 19:34:50 <jgarzik_> conftest.cpp: In function 'int main()':
391 2013-11-22 19:34:52 <jgarzik_> configure:10512: $? = 0
392 2013-11-22 19:34:54 <jgarzik_> configure:10527: result: yes
393 2013-11-22 19:34:56 <jgarzik_> configure:10686: error: Could not find a version of the library!
394 2013-11-22 19:35:07 <diki> #joke perhaps it's time to rewrite configure lol #endjoke
395 2013-11-22 19:35:23 <sipa> jgarzik_: https://github.com/bitcoin/bitcoin/issues/3219
396 2013-11-22 19:35:45 <sipa> is it that?
397 2013-11-22 19:37:40 <jgarzik_> sipa, looks like it
398 2013-11-22 19:38:20 <jgarzik_> apt-get install libboost1.54-all-dev
399 2013-11-22 19:49:41 <jgarzik_> wumpus, bitcoin-cli needs some work?
400 2013-11-22 19:49:53 <cfields> you can thank boost for not using pkg-config
401 2013-11-22 19:49:55 <jgarzik_> error: couldn't connect to server
402 2013-11-22 19:49:55 <jgarzik_> jgarzik@pum:~/repo/bitcoin/src$ ./bitcoin-cli stop
403 2013-11-22 19:49:55 <jgarzik_> jgarzik@pum:~/repo/bitcoin/src$ ./bitcoin-cli -testnet stop