1 2014-08-29 00:06:58 <BlueMatt> sipa: yea...I know, sadly relay network came up and I want to move it forward while its still fresh in people's minds
2 2014-08-29 01:18:11 <BlueMatt> ACTION does the block dance
3 2014-08-29 01:24:26 <nullbyte> was just thinking about the relay...
4 2014-08-29 01:43:02 <BlueMatt> nullbyte: so I started the work
5 2014-08-29 01:43:18 <BlueMatt> and did the fun part (wrote a client in python which speaks the relay protocol)
6 2014-08-29 01:43:27 <BlueMatt> but havent touched integrating it elsewhere or speaking the p2p protocol
7 2014-08-29 01:43:42 <BlueMatt> I'd kinda like to go incorporate it as-is into eliopool, p2pool, etc
8 2014-08-29 01:43:50 <BlueMatt> and then also have a wrapper that speaks bitcoind p2p
9 2014-08-29 01:52:48 <BlueMatt> Luke-Jr: would you take the time to integrate a relay node client class into eloipool?
10 2014-08-29 01:53:20 <BlueMatt> Luke-Jr: ie a simple interface that eats and spits byte arrays, just forward txn and blocks
11 2014-08-29 01:53:50 <BlueMatt> or wizkid057
12 2014-08-29 01:54:18 <Luke-Jr> BlueMatt: I'd certainly merge it.. is your code Python3-friendly?
13 2014-08-29 01:54:48 <BlueMatt> its python3-required
14 2014-08-29 01:55:33 <BlueMatt> Luke-Jr: any suggestions for where to put hooks to eg relay_node.relay_block(), relay_node.relay_tx() and receive_block?
15 2014-08-29 01:55:50 <Luke-Jr> BlueMatt: lol, good luck with p2pool then :P
16 2014-08-29 01:56:14 <BlueMatt> Luke-Jr: yea...I'll try to remove the dep later
17 2014-08-29 01:56:18 <Luke-Jr> BlueMatt: I would think you want something post-proposal, and something for the actual block submit
18 2014-08-29 01:56:23 <BlueMatt> I think its only for OrderedDict
19 2014-08-29 01:56:58 <Luke-Jr> merklemaker.py:538: self.logger.debug('Updating merkle tree with template from \'%s\'' % (BestMT.source,))
20 2014-08-29 01:57:28 <Luke-Jr> eloipool.py:570: bcnode.submitBlock(payload)
21 2014-08-29 01:57:55 <BlueMatt> awesome
22 2014-08-29 01:58:36 <Luke-Jr> BlueMatt: ideally, it'd be nice to configure it in config.py
23 2014-08-29 01:59:15 <Luke-Jr> if you're aiming for a common Python module, maybe wrap it in a try:import rather than putting the code in Eloipool itslef
24 2014-08-29 02:02:52 <BlueMatt> Luke-Jr: farrr too much effort for me, that
25 2014-08-29 02:03:06 <Luke-Jr> ?
26 2014-08-29 02:04:18 <Luke-Jr> well, get me something that works and I'll poke at the minor details
27 2014-08-29 02:05:40 <BlueMatt> Luke-Jr: https://github.com/TheBlueMatt/RelayNode/blob/master/RelayNetworkClient.py
28 2014-08-29 02:05:52 <BlueMatt> right now that succeeds in receiving blocks/txn and looping them back to the relay node
29 2014-08-29 02:06:04 <BlueMatt> needs either python3 or ordereddict from pip
30 2014-08-29 02:07:22 <gmaxwell> I don't know if doing this in eloipool makes sense in that any big eloipool user runs multiple ones... and to work efficient the client must have large state shared with the far end?
31 2014-08-29 02:07:56 <gmaxwell> eloipool should care to recieve unverified blocks...
32 2014-08-29 02:08:20 <Luke-Jr> gmaxwell: other end - broadcasting blocks
33 2014-08-29 02:08:55 <gmaxwell> Luke-Jr: yes, but the protocol is only really efficient if you're using it for both.
34 2014-08-29 02:09:05 <Luke-Jr> I suppose
35 2014-08-29 02:09:24 <Luke-Jr> so what you're saying is, we're going to want it using bitcoind directly *anyway*, no point adding it to Eloipool
36 2014-08-29 02:09:49 <BlueMatt> gmaxwell: my goal is to make it more readily accessible
37 2014-08-29 02:09:50 <Luke-Jr> BlueMatt: that being said, note Eloipool *does* have the p2p protocol implemented to some extent
38 2014-08-29 02:10:24 <Luke-Jr> I don't think I ever got it to work reliably, but part of that may have been because of/before the p2p-protocol-hardfork a few years ago
39 2014-08-29 02:10:27 <BlueMatt> integrating into p2pool, Eloipool will be essentially an entirely separate thing, but it makes it easier for people to --relay-network-connect NODE
40 2014-08-29 02:10:39 <gmaxwell> well, the relay client could implement a p2p listener socket eloipool could spam with blocks.
41 2014-08-29 02:11:20 <BlueMatt> gmaxwell: I'm lazy...easier to call relayNode.relayBlock(binary_array)
42 2014-08-29 02:12:09 <gmaxwell> BlueMatt: you're mooting all the advantages if eligius is running 40 relay clients in one data center.
43 2014-08-29 02:12:22 <BlueMatt> gmaxwell: hopefully they would only run it on one...
44 2014-08-29 02:12:33 <gmaxwell> BlueMatt: it runs some large number of eloipools.
45 2014-08-29 02:12:41 <BlueMatt> gmaxwell: yea, and you'd only peer on one
46 2014-08-29 02:12:44 <Luke-Jr> self.logger.debug('Received block inv over p2p for %s' % (b2a_hex(blkhash[::-1]).decode('ascii'),))
47 2014-08-29 02:12:45 <Luke-Jr> ;)
48 2014-08-29 02:12:48 <BlueMatt> I mean they're all gonna get blocks quick, no?
49 2014-08-29 02:12:53 <gmaxwell> BlueMatt: all of them potentially have blocks to announce.
50 2014-08-29 02:13:08 <BlueMatt> gmaxwell: and announcing them between each other should be damn quick?
51 2014-08-29 02:13:15 <gmaxwell> BlueMatt: yea but thats silly then, might as well just make it part of the bitcoind.
52 2014-08-29 02:13:32 <gmaxwell> BlueMatt: they don't announce them between each other currently.
53 2014-08-29 02:13:48 <gmaxwell> (AFAIK, luke will correct I'm sure0
54 2014-08-29 02:14:01 <Luke-Jr> gmaxwell: you're correct
55 2014-08-29 02:14:50 <BlueMatt> gmaxwell: whatever is lower barrier to a poolop, and I think thats always gonna be --relay-pool-peer, not python ./RelayPoolPeer.py
56 2014-08-29 02:15:23 <gmaxwell> so you're going to get 40 clients in one site then, and pool ops complaining about the memory usage. :P
57 2014-08-29 02:15:33 <BlueMatt> gmaxwell: also, I dont want to implement p2p
58 2014-08-29 02:15:45 <gmaxwell> so, make a patch to bitcoind?
59 2014-08-29 02:15:48 <BlueMatt> gmaxwell: it doesnt use that much memory, and hopefully no poolop would do that...
60 2014-08-29 02:15:58 <BlueMatt> gmaxwell: and then go around to poolops to convince them to use it....
61 2014-08-29 02:16:04 <Luke-Jr> BlueMatt: Eloipool implements p2p. Copy the code.
62 2014-08-29 02:16:08 <BlueMatt> gmaxwell: i wouldnt want to see that merged into bitcoind...
63 2014-08-29 02:16:27 <Luke-Jr> I wouldn't want to see miners running unpatched bitcoind
64 2014-08-29 02:16:45 <gmaxwell> BlueMatt: your guarenteed buffer is what, 2000 txn? so thats a peak usage of 200mbytes.
65 2014-08-29 02:17:24 <BlueMatt> 1000 txn * 10kb + 20 txn * 250kb
66 2014-08-29 02:17:37 <BlueMatt> 15mb
67 2014-08-29 02:17:48 <BlueMatt> + overhead of various maps and such
68 2014-08-29 02:17:54 <BlueMatt> *2 for outbound + inbound
69 2014-08-29 02:18:11 <BlueMatt> though outbound in java is just hashes, not txn, in python i havent done that yet
70 2014-08-29 02:18:16 <gmaxwell> BlueMatt: max relable and isStandard txn size is 100kb
71 2014-08-29 02:18:51 <BlueMatt> gmaxwell: so I should set 250kb to 100kb?
72 2014-08-29 02:18:51 <Luke-Jr> ACTION hopes the relay network isn't giving preferential treatment to miners with certain policies over others
73 2014-08-29 02:19:21 <gmaxwell> Luke-Jr: I dunno what you're talking about wrt unpatched bitcoind.
74 2014-08-29 02:19:23 <BlueMatt> Luke-Jr: it will give preferential treatment to those who are on it, but it does not care which txn you send it, as long as you're sending the txn you're gonna mine its fine
75 2014-08-29 02:20:00 <Luke-Jr> gmaxwell: my point is that miners should already be patching bitcoind, one more patch shouldn't hurt, nor should it be expected every patch should be merged
76 2014-08-29 02:20:40 <Luke-Jr> in response to BlueMatt's fear of having to get it merged
77 2014-08-29 02:22:38 <gmaxwell> Since its code that wouldn't even run unless you specifically configure it, the only reason I'd have to not just merge it is that it probably should be actively developed for a bit and thats easier if its not lockstep with bitcoin versions.
78 2014-08-29 02:23:47 <gmaxwell> in any case for p2pool since the p2pool node bitcoin daemon relationship is 1:1, having it in p2pool is basically the same as having it standalone... so I don't see any issue with putting it there.
79 2014-08-29 02:24:13 <gmaxwell> BlueMatt: if you're only queueing 20 >10k transactions ... thats going to reduce the hitrate a fair amount.
80 2014-08-29 02:25:02 <gmaxwell> for the elopool case the architecture is pretty different.
81 2014-08-29 02:25:40 <gmaxwell> eloipool is also only one of serveral poolservers.
82 2014-08-29 02:26:06 <BlueMatt> gmaxwell: oh? I see relatively few >10k txn in recent blocks
83 2014-08-29 02:26:39 <BlueMatt> gmaxwell: 0 more often than not
84 2014-08-29 02:26:39 <gmaxwell> byte-hitrate is what counts for bandwidth reduction, so you need to weigh the results by the bytes sent.
85 2014-08-29 02:26:52 <BlueMatt> indeed
86 2014-08-29 02:27:07 <BlueMatt> but thats the reasonf or the limited exception
87 2014-08-29 02:27:47 <BlueMatt> if you really want to include a gian, unrelayble, txn, you can
88 2014-08-29 02:28:25 <gmaxwell> transactions > 10k are perfectly relayable 0_o
89 2014-08-29 02:29:00 <BlueMatt> oh, that comment was just general
90 2014-08-29 02:29:13 <BlueMatt> if you really want to mine something large as a miner, the relay network will not punish you
91 2014-08-29 02:30:25 <BlueMatt> ACTION -> dinner
92 2014-08-29 02:30:44 <gmaxwell> well, it will, so long as you have more than 20 of them or are relaying any transactions you consider valid but aren't making your mining cut. (which is currently how nodes behave)
93 2014-08-29 02:39:07 <gmaxwell> BlueMatt: odd, there are fewer large transactions than there used to be.
94 2014-08-29 03:27:23 <roasbeef> BlueMatt: OrderedDict exists both in Python 2.7 and 3K under the same 'collections' module, your RelayNode implementation in Python should work for both and for p2pool since it requires 2.7
95 2014-08-29 07:58:20 <wumpus> cfields: what would be the advantage of all the wrapping-symbols stuff if we can just link against the Qt 4.6 headers?
96 2014-08-29 07:58:36 <wumpus> cfields: it seems kind of pointless to do all this work, the current solution is working
97 2014-08-29 07:58:51 <cfields> wumpus: you can't link against headers
98 2014-08-29 07:58:58 <wumpus> doh I mean compile against headers
99 2014-08-29 07:59:13 <cfields> because you have to link against something :)
100 2014-08-29 07:59:18 <wumpus> use 4.8 for that
101 2014-08-29 07:59:24 <wumpus> it doesn't matter , it's backward compatible
102 2014-08-29 07:59:43 <wumpus> in the end you'll reach the same result
103 2014-08-29 07:59:49 <wumpus> but with lots of extra work
104 2014-08-29 08:00:00 <cfields> then we're completely at the mercy of whatever's installed on the system, which is the exact opposite intention of the depends
105 2014-08-29 08:00:24 <wumpus> well if you need to link against something *build* 4.8, and use the 4.6.3 headers?
106 2014-08-29 08:00:27 <wumpus> it could be an easy switch
107 2014-08-29 08:00:51 <wumpus> ie, if we don't want 4.6.3 compat we can easily switch it off and just build against the 4.8 headers
108 2014-08-29 08:01:20 <cfields> where do the headers come from?
109 2014-08-29 08:01:39 <wumpus> from the qt source distribution, see the gitian discriptor for qt linux
110 2014-08-29 08:02:20 <cfields> wumpus: right, that's the same thing my PR does, but without having to restort to patching things around
111 2014-08-29 08:02:37 <cfields> wumpus: your patch works because it sets the QT_VERSION to 4.6
112 2014-08-29 08:03:34 <wumpus> that's not all, though
113 2014-08-29 08:03:46 <wumpus> it's not like I didn't try that, to use the 4.8 headers and just change the version definition
114 2014-08-29 08:04:49 <wumpus> there is some mess with inlined functions that makes it use symbols not available in 4.6 libraries
115 2014-08-29 08:06:21 <wumpus> you know what, we should just require 4.8 for 0.10 and be done with this
116 2014-08-29 08:07:21 <wumpus> at some point the amount of work to maintain compatibility escalates and one just has to cut the know
117 2014-08-29 08:07:27 <wumpus> knot*
118 2014-08-29 08:09:15 <cfields> i'd be ok with that
119 2014-08-29 08:09:18 <cfields> but
120 2014-08-29 08:09:25 <cfields> it's worth giving this a try on 4.6 first
121 2014-08-29 08:09:35 <cfields> looking at that config in gitian again, i don't see any reason why this wouldn't work
122 2014-08-29 08:09:48 <cfields> none of the api's are overwritten in your config
123 2014-08-29 08:10:13 <wumpus> ok... if not too much work, that'd be very cool, but if possible I'd like to avoid adding qt symbol wrappers in bitcoind as well
124 2014-08-29 08:10:40 <cfields> i found 3 things that affect the abi: session management, openssl compile, and static lib external linkage
125 2014-08-29 08:11:01 <cfields> well i agree with you there. If there aren't any actual users of it, there's no need ot maintain it
126 2014-08-29 08:11:02 <wumpus> its' bad enough we have to wrap glibc and libc++ for compatibility, but at least that's at a base level, the GUI just isn't worth the same amount of maintenance work
127 2014-08-29 08:11:40 <cfields> but. I believe all it should cost us for this one is that define -> macro. There's not much overhead there...
128 2014-08-29 08:11:56 <cfields> so i suppose it's really a matter of finding out what support we'd be dropping, and how much it matters
129 2014-08-29 08:11:56 <wumpus> defining and macros are fine
130 2014-08-29 08:12:02 <wumpus> just no c++ symbol magic okay ? :-)
131 2014-08-29 08:12:11 <cfields> heh, there's not any :)
132 2014-08-29 08:12:43 <wumpus> *phew* ok I'll calm down now
133 2014-08-29 08:13:24 <cfields> wumpus: this is the "magic" https://github.com/theuni/bitcoin/commit/13803a233f2a161497afd55d5e7cff6bf3e1e3c0
134 2014-08-29 08:13:39 <cfields> don't be scared by the diff size, it's 99% sed work
135 2014-08-29 08:15:10 <wumpus> I tried that at some point, it didn't work for me
136 2014-08-29 08:16:01 <wumpus> but ok, doesn't hurt to give it a try too
137 2014-08-29 08:17:22 <cfields> wumpus: it won't bother me at all to drop it, i just wanted to put forward a solution
138 2014-08-29 08:18:00 <wumpus> cfields: I'm just surprised if you can get this to work, "do not use any >4.6 symbols" seems like the obvious way to be compatible with 4.6, but it didn't work for me
139 2014-08-29 08:18:13 <cfields> i'll see if i can throw together some vm's this weekend to test. if it works, we'll have data points. Not to say we actually need to keep the compat, but we'll know where we stand
140 2014-08-29 08:18:55 <cfields> wumpus: well it's also sensitive to how you build the other deps. openssl in particular.
141 2014-08-29 08:19:10 <cfields> qt needed a bit of patching to cope
142 2014-08-29 08:20:06 <cfields> because we have static qt and qt ends up with it too. You solved it by dropping the symbols with the linker script, but that doesn't solve the runtime resolving
143 2014-08-29 08:20:51 <cfields> *static openssl
144 2014-08-29 08:21:18 <wumpus> well it did solve the problem and made the executables working well on the old-hat VMs I was testing on
145 2014-08-29 08:21:47 <wumpus> but if you're redoing all of this I'd say don't bother
146 2014-08-29 08:22:49 <cfields> i swear i'm not just redoing things for the sake of NIH :)
147 2014-08-29 08:22:58 <cfields> (as much as it may seem)
148 2014-08-29 08:23:26 <cfields> I just don't want to introduce a dependency outside of our control, after eliminating all of the others
149 2014-08-29 08:23:28 <wumpus> too much time has already been spent down this particular rabbit hole, I'm sure there are actual issues blocking the 0.10 release
150 2014-08-29 08:25:27 <cfields> well i need this built _somehow_ to get the gitian descriptors merged in, that's why i'm giving it attention
151 2014-08-29 08:27:48 <wumpus> agreed
152 2014-08-29 08:30:14 <wumpus> well, anyhow, if you need any executables tested on old VMs just send them
153 2014-08-29 08:30:20 <cfields> wumpus: QT_VISIBILITY_AVAILABLE would've been the other major one to take care of
154 2014-08-29 08:30:39 <cfields> maybe your local install didn't have that defined?
155 2014-08-29 08:30:45 <wumpus> I don't know
156 2014-08-29 08:31:43 <cfields> heh. i get the sense that we're equally done with this topic for now :)
157 2014-08-29 08:31:48 <cfields> zzz time, nnite
158 2014-08-29 08:32:40 <wumpus> night
159 2014-08-29 09:08:00 <stoyvo> Anyone around that knows centos?
160 2014-08-29 09:10:11 <stoyvo> i keep getting the error "configure error: No working boost sleep implementation found."
161 2014-08-29 09:10:11 <sturles> stoyvo: Wrong question. Try "Anyone around who knows the solution to <your exact problem>?"
162 2014-08-29 09:10:14 <stoyvo> however, it's there.....
163 2014-08-29 09:10:33 <sturles> That's better.
164 2014-08-29 09:10:50 <sturles> Did you check configure.log?
165 2014-08-29 09:10:51 <stoyvo> Sorry... I realized how vage the question was.
166 2014-08-29 09:11:00 <sturles> The problem can be something else.
167 2014-08-29 09:11:01 <stoyvo> Yes, one sec.
168 2014-08-29 09:11:15 <wumpus> does that happen with master?
169 2014-08-29 09:11:27 <stoyvo> i'm on tag v0.9.2.1
170 2014-08-29 09:11:41 <wumpus> there have been various changes to the build system to improve boost autodetection
171 2014-08-29 09:11:59 <wumpus> ok, then you probably have to provide --with-boost-libpath=<directory>
172 2014-08-29 09:12:22 <stoyvo> hmm, tried that.
173 2014-08-29 09:12:35 <stoyvo> --with-boost-libdir=/home/bitcoind/deps/lib (custom location)
174 2014-08-29 09:12:52 <stoyvo> the default yum install is located in /usr/lb64
175 2014-08-29 09:13:07 <stoyvo> . /usr/lib64
176 2014-08-29 09:13:54 <wumpus> it's a well-known issue anyway, see https://github.com/bitcoin/bitcoin/issues/3003
177 2014-08-29 09:15:17 <wumpus> maybe try git cherry-pick 2041365
178 2014-08-29 09:15:54 <wumpus> oh, that's from 2013, that should be in 0.9.2.1...
179 2014-08-29 09:17:19 <stoyvo> haha, I read that thread
180 2014-08-29 09:18:07 <stoyvo> geez....
181 2014-08-29 09:18:08 <wumpus> you'll need to do some autoconf debugging to find out *why* it doesn't find a boost sleep
182 2014-08-29 09:18:30 <wumpus> I think we can exclude the library path, but it may still be something with includes
183 2014-08-29 09:18:36 <wumpus> what does config.log say?
184 2014-08-29 09:18:52 <stoyvo> I've tried a few things, such as using boost v1.56, setting custom location vs default, etc
185 2014-08-29 09:19:05 <stoyvo> one sec, trying master
186 2014-08-29 09:19:12 <wumpus> boost version shouldn't make a difference, bitcoin is compatible with extrememly old boost versions
187 2014-08-29 09:19:22 <wumpus> it's just the autodetection that fails
188 2014-08-29 09:20:22 <stoyvo> hmm, good point
189 2014-08-29 09:20:30 <stoyvo> what should --with-boost be pointed to?
190 2014-08-29 09:20:45 <stoyvo> currently I have the option undeclared as a param
191 2014-08-29 09:20:59 <stoyvo> eerr, sorry. That param is not declared*
192 2014-08-29 09:21:02 <wumpus> not sure, but can you pastebin your config.log after getting that error?
193 2014-08-29 09:21:13 <stoyvo> sure, one sec
194 2014-08-29 09:21:20 <wumpus> and yes, trying with master is good for reference
195 2014-08-29 09:21:27 <wumpus> at least then we know if it's fixed there
196 2014-08-29 09:26:51 <stoyvo> Sorry, had to map VM to the host
197 2014-08-29 09:28:53 <wumpus> IIRC --with-boost just sets a base prefix where boost is installed, so it's equivalent to --with-boost-libpath=$X/lib --with-boost-includepath=$X/include
198 2014-08-29 09:31:58 <moa> which is oldest boost version that has boost-chrono might be worth asking also
199 2014-08-29 09:32:36 <wumpus> well the pulltester uses boost 1.4x, and it works with that
200 2014-08-29 09:33:16 <wumpus> I wouldn't worry about boost versions, you do have to make sure all necessary boost libraries (and their development headers) are installed
201 2014-08-29 09:33:51 <wumpus> so, indeed, if your boost has/needs chrono, make sure it is installed
202 2014-08-29 09:41:15 <stoyvo> i haven't left, im reading messages
203 2014-08-29 09:41:57 <stoyvo> I'm having trouble now getting the kernel headers just so I can install these stupid vm tools so I can grab this file...... Overly complicated for something so silly
204 2014-08-29 09:50:57 <yrashk> bitcoind returns TX rejected (code -22), Electrum returns {u'message': u'64: non-canonical', u'code': -26}
205 2014-08-29 09:50:57 <yrashk> Hi, guys, hoping somebody can help. I am having a rejected custom transaction. I've checked everything I could think of: signature canonicity, and whether sigs and pubkeys are made from the same *right* addresses, the fee is there, only one OP_RETURN, its value is non-zero (I've done nValue=1 OP_RETURNs successfully before). I must be forgetting something
206 2014-08-29 09:50:57 <yrashk> really simple and stupid as I wasted over half a day on this already: https://gist.github.com/yrashk/bc0a2548d2d86026497b
207 2014-08-29 10:03:20 <stoyvo> wumpus, still around?
208 2014-08-29 10:03:38 <stoyvo> http://pastebin.com/zwxM9fZm
209 2014-08-29 10:09:07 <wumpus> /bin/ld: /home/bitcoind/deps/lib/libboost_system.a(error_code.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
210 2014-08-29 10:09:36 <wumpus> if you are building static boost to be linked against bitcoind, you must compile with -fPIC
211 2014-08-29 10:10:08 <wumpus> (or, alternatively, build bitcoind without harding so that it won't use ASLR)
212 2014-08-29 10:10:19 <wumpus> s/harding/hardening
213 2014-08-29 10:11:02 <stoyvo> haha
214 2014-08-29 10:11:06 <stoyvo> hmmm
215 2014-08-29 10:11:08 <wumpus> or just use a dynamic boost library
216 2014-08-29 10:11:17 <stoyvo> boost-devel?
217 2014-08-29 10:11:27 <wumpus> boost-devel?
218 2014-08-29 10:11:38 <stoyvo> err, by dnamic, what do you mean?
219 2014-08-29 10:11:42 <wumpus> a .so
220 2014-08-29 10:11:49 <stoyvo> ah, okay
221 2014-08-29 10:12:06 <wumpus> those are always compiled with -fPIC to make them relocatable
222 2014-08-29 10:12:39 <stoyvo> -fPIC is compiled on boost or bitcoin
223 2014-08-29 10:12:56 <wumpus> both
224 2014-08-29 10:13:11 <stoyvo> i was able to set it on boost, but bitcoin won't accept it
225 2014-08-29 10:13:28 <wumpus> well at least you shouldn't get this error anymore
226 2014-08-29 10:13:38 <stoyvo> haha it wont compile at all ;)
227 2014-08-29 10:14:55 <wumpus> see contrib/gitian-descriptors/boost-linux.yml on how to build a static boost that can be used with bitcoind
228 2014-08-29 10:17:28 <stoyvo> thanks wumpus, will play around with this
229 2014-08-29 10:17:45 <wumpus> in practice, building a shared library and using that is much easier, or just using your OS's boost library and headers instead of building your own, but you probably have a reason for that
230 2014-08-29 10:18:27 <stoyvo> only tried to use my own because the packages version of boost wasn't working
231 2014-08-29 10:18:31 <stoyvo> I assumed it was the issue
232 2014-08-29 10:19:00 <wumpus> then you're getting into a lot of trouble for nothing
233 2014-08-29 10:19:29 <stoyvo> okay, going to start from the top again and get rid of everything custom
234 2014-08-29 10:21:06 <wumpus> yes, let's figure out why it doesn't work with your os' headers/libs
235 2014-08-29 10:21:43 <wumpus> if that really doesn't work you can always go back to the hell of building boost yourself
236 2014-08-29 10:23:33 <stoyvo> haha
237 2014-08-29 10:23:37 <stoyvo> indeed it was hell
238 2014-08-29 10:23:48 <stoyvo> this is how i'm building bitcoin
239 2014-08-29 10:23:58 <stoyvo> LD_LIBRARY_PATH=/home/bitcoind/deps/lib LIBS='-lssl -lcrypto' CPPFLAGS=-I/home/bitcoind/deps/include LDFLAGS=-L/home/bitcoind/deps/lib SSL_CFLAGS=-I/home/bitcoind/deps/include SSL_LIBS=-L/home/bitcoind/deps/lib CRYPTO_CFLAGS=-I/home/bitcoind/deps/include CRYPTO_LIBS=-L/home/bitcoind/deps/lib ./configure --prefix=/home/bitcoind
240 2014-08-29 10:25:50 <stoyvo> ok..... so it worked
241 2014-08-29 10:25:51 <stoyvo> :D
242 2014-08-29 10:26:14 <stoyvo> i'm not sure what the hell I did wrong the firs time, but I spent about 4 hours debugging :D haha
243 2014-08-29 10:26:34 <stoyvo> Thank you for your help wumpus! btc address? I would like to tip for your help
244 2014-08-29 10:29:47 <wumpus> hah, that's strange
245 2014-08-29 10:53:55 <wumpus> ideally the "No working boost sleep implementation found." should be more descriptive, ie mention what libraries failed to be linked
246 2014-08-29 13:37:51 <jeremias_> hi, are read-only addresses planned for bitcoin-qt?
247 2014-08-29 13:39:04 <wumpus> you mean watch-only?
248 2014-08-29 13:39:10 <wumpus> that's already implemented in master
249 2014-08-29 13:40:15 <wumpus> to use it, you have to use importaddress in the console
250 2014-08-29 15:07:34 <Raccoon> Bitcoin's Earliest Adopter, Hal Finney, Died Thursday... Is Cryonically Freezing His Body To See The Future -- http://www.wired.com/2014/08/hal-finney/
251 2014-08-29 15:07:53 <Raccoon> Just how rich did he get off of bitcoin? What was his IRC nick?
252 2014-08-29 15:11:45 <Luke-Jr> Raccoon: this is -dev
253 2014-08-29 15:17:06 <Raccoon> Luke-Jr: Indeed, it quite rightly is.
254 2014-08-29 15:17:18 <Raccoon> I am asking about a developer of bitcoin who just died yesterday.
255 2014-08-29 15:17:42 <Apocalyptic> Hal was no developer afaik
256 2014-08-29 15:17:54 <Raccoon> I assume he might even have frequented this channel or its predecessor
257 2014-08-29 15:18:04 <Raccoon> oh. The article says he was
258 2014-08-29 15:20:37 <Raccoon> It does read that he didn't get rich off bitcoin though, alas. They cashed it in for medical bills long before it skyrocketed
259 2014-08-29 15:20:44 <wumpus> he was a developer but not a bitcoin developer :) and he was never in this channel IIRC, he had problems with typing way before
260 2014-08-29 15:21:14 <Raccoon> >Even Finneyâs ALS diagnosis in 2009 didnât slow his technological experimentation. As paralysis set in, he continued to contribute to bitcoin discussions and write code using software that translated his eye movements into text. He even created software that allowed him to use his eyes to adjust his own mechanized wheelchairâs position.
261 2014-08-29 15:21:45 <wumpus> please don't try to argue this
262 2014-08-29 15:21:56 <Raccoon> it's not an argument.
263 2014-08-29 15:22:01 <Raccoon> just putting it out there.
264 2014-08-29 15:22:01 <tholenst> This channel is about bitcoin development. It's not about bitcoin developers.
265 2014-08-29 15:22:20 <Raccoon> tough crowd.
266 2014-08-29 15:22:42 <wumpus> this really belongs in #bitcoin
267 2014-08-29 15:30:07 <jeremias_> wumpus: ok, so the importaddress command should be in the next release?
268 2014-08-29 15:30:17 <jeremias_> or is it currently already in some release?
269 2014-08-29 15:31:55 <sipa> jeremias_: it will be in 0.10
270 2014-08-29 15:34:50 <jeremias_> sipa: thanks
271 2014-08-29 18:19:21 <cfields> gavinandresen: around? I need to figure out how to get some source files on the core dev server
272 2014-08-29 18:19:41 <gavinandresen> cfields: yes
273 2014-08-29 18:20:54 <cfields> gavinandresen: most important is the osx sdk so that we can enable the osx build for travis, but it'd be nice to get the rest of the sources up as well. let me know when you've got some free time to push em up?
274 2014-08-29 18:35:27 <DiabloD3> hey gmaxwell
275 2014-08-29 18:35:31 <DiabloD3> ever heard of http://www.hashersunited.com/
276 2014-08-29 18:35:32 <DiabloD3> ?
277 2014-08-29 18:39:23 <cfields> wumpus: ping
278 2014-08-29 20:24:14 <jtimon> it's just me or the current master doesn't build with after ./configure --disable-wallet ?
279 2014-08-29 20:29:51 <jtimon> ok, I think I found the issue