1 2014-04-14 00:26:04 <warren> kristov: no, its static
2 2014-04-14 00:26:11 <warren> kristov: you wont see it
3 2014-04-14 00:26:19 <warren> with ldd
4 2014-04-14 00:30:23 <kristov> warren: gotcha. how can I confirm the version of openssl statically linked in bitcoin-qt 0.8.6?
5 2014-04-14 00:31:50 <warren> kristov: Help -> Debug
6 2014-04-14 00:34:07 <kristov> warren: ahh, good call
7 2014-04-14 00:48:41 <kristov> warren: you've been super helpful, thanks
8 2014-04-14 00:48:50 <kristov> warren: got a tipping address?
9 2014-04-14 00:49:24 <LoRez> kristov: what version is it, ftr?
10 2014-04-14 00:49:37 <kristov> OpenSSL v0.9.8k
11 2014-04-14 00:49:51 <kristov> dated 25 march 2009
12 2014-04-14 00:50:01 <LoRez> so, relatively safe.
13 2014-04-14 00:50:15 <kristov> LoRez: Relatively.
14 2014-04-14 01:26:38 <kayann__> hi
15 2014-04-14 02:36:09 <GAit> Luke-Jr: got a minute?
16 2014-04-14 02:36:17 <Luke-Jr> ?
17 2014-04-14 03:17:43 <jgarzik> Calling all early seeders, for soon-to-be-announced bootstrap.dat updated torrent @ block 295000: http://gtf.org/garzik/bitcoin/bootstrap.dat.torrent If you have an old bootstrap.dat, bittorrent will automatically extend it when you switch to the new torrent. You effectively already have 81% of the new bootstrap.dat.
18 2014-04-14 03:19:55 <jgarzik> magnet:?xt=urn:btih:cb7caf0b4c0ee266cce5fbd8f8ba3903f5efa82e&dn=bootstrap.dat&tr=udp://tracker.openbittorrent.com:80&tr=udp://tracker.publicbt.com:80&tr=udp://tracker.ccc.de:80&tr=udp://tracker.istole.it:80
19 2014-04-14 03:19:59 <warren> jgarzik: have you asked if the linux mirrors would carry bootstrap.dat ?
20 2014-04-14 03:20:35 <jgarzik> warren, heh, thought never crossed my mind. torrent seemed so much more automatic and efficient.
21 2014-04-14 03:20:57 <gmaxwell> ACTION thinks that bootstrap dat has distracted people from hacking on headers first, and we probably shouldn't put more effort into build more infrastructure for it. :)
22 2014-04-14 03:21:04 <jgarzik> warren, having an http download would be quite nice, but would need to qualify mirrors and guarantee that they supported http resume
23 2014-04-14 03:26:12 <jgarzik> gmaxwell, if people want to volunteer HTTP downloads for the block chain, that is IMO positive. The more diverse methods, the better.
24 2014-04-14 03:26:35 <jgarzik> Though I'm tempted to define a canonical blk0000$n.dat rather than continuing to grow that one file
25 2014-04-14 03:26:47 <warren> +1
26 2014-04-14 03:27:02 <Joric> i vote for http nodes as well =)
27 2014-04-14 03:28:00 <jgarzik> headers-first is certainly important as well. We essentially have several thousand nodes in our "swarm", so the replication factor is quite high presuming a fast download
28 2014-04-14 03:28:13 <warren> jgarzik: I think mirrors would do it if they aren't the only one
29 2014-04-14 03:28:18 <Joric> just imagine, fullnode flash clients, js clients!
30 2014-04-14 03:28:57 <gmaxwell> jgarzik: not just that, HF download is inherently faster because it can verify while downloading vs downloading first and then verifying as happens with the torrent. With sipa's patches last year it completed chain sync for me faster than the torrent took to download.
31 2014-04-14 03:29:33 <gmaxwell> and sure, extra mechenisms are fine, but right now bootstrap is papering over sync problems where the reference software is dangrously flawed.
32 2014-04-14 03:35:37 <jgarzik> gmaxwell, sure, though I don't buy the argument all the way to "distraction" Absence of bootstrap.dat would not likely cause the appearance of new sipas with additional coding motivation and bandwidth
33 2014-04-14 03:36:34 <PRab> If there is something easy I can to to integrate it with Tahoe-LAFS I would be willing to.
34 2014-04-14 03:37:11 <PRab> I don't think there would be too much benefit because Tahoe-LAFS has significantly lower adoption than either bitcoin or bittorrent.
35 2014-04-14 03:39:11 <gmaxwell> jgarzik: My thinking there was mostly that sipa's code was working and usable, and hasn't made it in yet because it was a big scarry change that needed a lot of testing. You're probably right in any case.
36 2014-04-14 04:40:11 <warren> jgarzik: btw, pre-indexed insight database would be helpful too
37 2014-04-14 04:40:21 <warren> perhaps even more useful
38 2014-04-14 04:40:24 <warren> given how long it takes
39 2014-04-14 04:40:52 <jgarzik> ACTION grabs largedatasetsRus.io
40 2014-04-14 04:44:06 <warren> jgarzik: may I ask now what you want to do with regard to regtest and bitcore?
41 2014-04-14 04:45:29 <jgarzik> warren, if address versions do not differ, bitcore must pass in a differentiator at object init time
42 2014-04-14 04:45:42 <jgarzik> warren, all objects follow a standard form, so it's just one more input
43 2014-04-14 04:55:30 <michagogo> cloud|ACTION hopes he'll remember the new torrent when he's next at his computer
44 2014-04-14 04:55:54 <michagogo> cloud|jgarzik: how much bigger is the new one?
45 2014-04-14 04:56:21 <michagogo> cloud|(I'll probably just use the python script to bring mine up to date)
46 2014-04-14 04:56:37 <jgarzik> michagogo|cloud, 14G -> 17G
47 2014-04-14 04:57:27 <michagogo> cloud|...yeah, gonna do that then
48 2014-04-14 04:58:43 <michagogo> cloud|(Mind PMing me the blk num and URL?)
49 2014-04-14 05:03:15 <jgarzik> michagogo|cloud, it's up to height 295000.
50 2014-04-14 05:31:41 <super3> jgarzik, around at this early hour?
51 2014-04-14 05:33:05 <jgarzik> super3, da
52 2014-04-14 05:34:10 <super3> playing around in /contrib
53 2014-04-14 05:34:48 <super3> trying to tidy up, you wrote all of pyminer.py right?
54 2014-04-14 05:35:45 <super3> or 'most'
55 2014-04-14 05:42:00 <jgarzik> super3_, yes
56 2014-04-14 05:49:14 <super3> jgarzik: jgarzik, i wanted to drop it from /contrib its a great refrence, but i don't see a use in the active codebase. i had two ideas
57 2014-04-14 05:49:21 <super3> a) just remove it
58 2014-04-14 05:49:37 <super3> b) remove the code, but just keep a link in the index to your repo with the same code
59 2014-04-14 05:51:27 <gmaxwell> Why? has it stopped working?
60 2014-04-14 05:51:57 <wumpus> it's not meant to be used in the current code base
61 2014-04-14 05:52:04 <wumpus> it's an example, a reference
62 2014-04-14 05:52:09 <jgarzik> should still work on testnet as long as getwork exists
63 2014-04-14 05:53:10 <super3> ok that is a valid point
64 2014-04-14 05:53:11 <wumpus> super3: feel free to update it to use getblocktemplate, of course
65 2014-04-14 05:53:23 <jgarzik> ACTION watches python scripts churn away slowly
66 2014-04-14 05:53:38 <jgarzik> ACTION builds a blkNNNNN.dat for each year of bitcoin's life
67 2014-04-14 05:56:26 <super3> after i organize up /contrib i want to fix up bitrpc.py
68 2014-04-14 05:56:52 <super3> maybe even add those fancy autocompletes that i've always wanted
69 2014-04-14 06:02:47 <michagogo> cloud|Was that the one that defined each rpc in the code for some reason?
70 2014-04-14 06:03:21 <super3> michagogo|cloud: yes...
71 2014-04-14 06:03:41 <michagogo> cloud|ACTION doesn't understand why that is
72 2014-04-14 06:04:02 <michagogo> cloud|Especially because only a subset of rpc is in there
73 2014-04-14 06:04:20 <michagogo> cloud|(Or was when I saw it)
74 2014-04-14 06:05:13 <super3> thats correct
75 2014-04-14 06:05:24 <super3> but there is a bunch of redundant code in there
76 2014-04-14 06:05:35 <wumpus> the purpose of that script is to be able to do some RPC calls manually more easily/secure, for example by asking the parameters separately, or using getpass() to securely ask for the passphrase
77 2014-04-14 06:06:16 <wumpus> if you want to improve it, be my guest, but asking 'why is it like this and this' has the usual answer: no one bothered to do it yet
78 2014-04-14 06:15:28 <michagogo> cloud|Is it possible in python to do what the ruby rpc code on the wiki does?
79 2014-04-14 06:16:28 <michagogo> cloud|(It redefines the method_missing function on the BitcoinRPC class to turn any call into an rpc)
80 2014-04-14 06:17:48 <wumpus> how is that different from what the RPC proxy does?
81 2014-04-14 06:18:27 <wumpus> I suggest looking at the python stuff in qa/rpc-tests
82 2014-04-14 06:20:18 <warren> wumpus: in genbuild.sh any suggestions for commands to use to parse the numbers from src/clientversion.h ?
83 2014-04-14 06:20:35 <warren> I would normally use grep and awk, but not sure if that's portable.
84 2014-04-14 06:21:16 <wumpus> it's a shell script, so using grep, sed and awk is the way things are done
85 2014-04-14 06:21:36 <michagogo> cloud|wumpus: as I mentioned before, I don't really remember the details of that -- I just saw it once, and didn't really go through the whole thing, so it's possible I'm not remembering everything
86 2014-04-14 06:21:46 <michagogo> cloud|(And I also don't know python)
87 2014-04-14 06:23:03 <wumpus> warren: I'd suggest using the version info from configure.ac, the duplicate info in clientversion.h is supposed to go away when that's possible
88 2014-04-14 06:23:23 <warren> ok
89 2014-04-14 06:23:59 <Luke-Jr> wumpus: that boost autoconf stuff really needs to be probably entirely rewritten to make it work *correctly*. :/
90 2014-04-14 06:24:21 <wumpus> warren: probably we don't need a genbuild.sh at all anymore; the autotools can do any generation we need
91 2014-04-14 06:24:54 <wumpus> oh wait.. no, I'm wrong, it's stil usefor for the git id
92 2014-04-14 06:25:11 <wumpus> but not for the version, configure has all the version information that anyone needs
93 2014-04-14 06:25:17 <warren> git diff-index --quiet HEAD --
94 2014-04-14 06:25:28 <warren> This is used internally by git describe to detect if something is dirty or not.
95 2014-04-14 06:25:34 <warren> git rev-parse --short HEAD
96 2014-04-14 06:25:39 <warren> This is how to get the short hash.
97 2014-04-14 06:26:04 <wumpus> my suggestion would be to remove anything that has to do with version from genbuild.sh
98 2014-04-14 06:26:06 <warren> I'm just replacing git describe for now.
99 2014-04-14 06:26:12 <warren> uh
100 2014-04-14 06:26:29 <warren> it currently gets the displayed version from there
101 2014-04-14 06:26:30 <wumpus> if you want to change the version you change configure.ac, so you re-run the configure hocus pocus anyway
102 2014-04-14 06:26:40 <wumpus> ... that's crazy
103 2014-04-14 06:26:56 <warren> yes it is
104 2014-04-14 06:27:41 <warren> NEWINFO="#define BUILD_DESC \"$DESC\""
105 2014-04-14 06:28:00 <wumpus> so the version information to be displayed should use the normal FormatVersion() from util.h
106 2014-04-14 06:28:40 <warren> util.cpp
107 2014-04-14 06:28:41 <wumpus> and tack on the git id and dirty/nondirty if appropriate
108 2014-04-14 06:29:08 <wumpus> the way we're doing it now is backwards
109 2014-04-14 06:29:33 <warren> I'll change it to write only the suffix
110 2014-04-14 06:29:37 <warren> from git
111 2014-04-14 06:29:41 <wumpus> great
112 2014-04-14 06:30:16 <wumpus> Luke-Jr: yes, that m4 stuff for boost is thoroughly confused
113 2014-04-14 06:31:07 <wumpus> Luke-Jr: usually the build system doesn't even have to care where libraries are, it just checks if it can link against them, .. but boost has all these crazy name variations that naive probing would take all day
114 2014-04-14 06:31:08 <warren> I'm not sure FormatVersion() is the best way to do it
115 2014-04-14 06:31:24 <warren> you already have preprocessor defines
116 2014-04-14 06:32:00 <wumpus> warren: I don't mind how it's exactly done; but parsing the configure scripts/source code in genbuild.h just to reinsert it in a generated header doesn't make sense
117 2014-04-14 06:32:14 <warren> i agree
118 2014-04-14 06:32:16 <wumpus> warren: if you don't want to use that specific function for some reason it's ok with me
119 2014-04-14 06:32:26 <wumpus> or maybe change the function to be more useful
120 2014-04-14 06:33:20 <wumpus> hmm though it is likely used by the P2P code to send a version identifier, so there is not much wiggle room in changing the formatting
121 2014-04-14 06:33:55 <warren> it writes only the number portion after the :
122 2014-04-14 06:35:43 <warren> found a clean way
123 2014-04-14 06:35:52 <wumpus> good
124 2014-04-14 06:38:12 <splitting> whats the best way to start and stop bitcoind from a python script?
125 2014-04-14 06:39:00 <wumpus> probably subprocess combined with a RPC proxy, see the scripts in qa/rpc-tests
126 2014-04-14 06:40:12 <splitting> thanks :) and another question
127 2014-04-14 06:40:21 <splitting> whats the difference between the -server and -daemon flag?
128 2014-04-14 06:40:52 <wumpus> server enables the RPC server, daemon sends the process to the background
129 2014-04-14 06:41:23 <wumpus> (there is nothing between them in common, so talking about differences doesn't make sense)
130 2014-04-14 06:41:34 <splitting> ah alright, so if I wanted to make rpc api calls to the server I should be launching it with -server instead of -daemon?
131 2014-04-14 06:41:47 <wumpus> or both
132 2014-04-14 06:41:50 <splitting> ah alright, i was just confused, i guess i thought they were the same
133 2014-04-14 06:42:44 <splitting> hmm ok, i was having an issue where when I started up bitcoind and then tried getbalance() it would fail, but if I added a sleep timer to it, it would work, but not reliably
134 2014-04-14 06:43:05 <splitting> is there some kind of process that starts up before the rpc server does?
135 2014-04-14 06:43:30 <wumpus> in the command line bitcoin-cli there is a -wait option that waits for the server to be reachable
136 2014-04-14 06:43:38 <wumpus> you can implement the same in python of course
137 2014-04-14 06:44:19 <splitting> sounds good. what rpc library should I be using ? the one in this qa/rpc-tests directory?
138 2014-04-14 06:44:34 <splitting> i read on the wiki that there are some others out there
139 2014-04-14 06:45:33 <wumpus> i'd recommend petertodd's python-bitcoinlib fork for any of your python bitcoin needs
140 2014-04-14 06:45:46 <wumpus> https://github.com/petertodd/python-bitcoinlib
141 2014-04-14 06:47:10 <splitting> alright, another question, is this library compatible with any other coin that uses the same bitcoin rpc commands?
142 2014-04-14 06:47:11 <splitting> i'd imagine right
143 2014-04-14 06:47:41 <wumpus> no clue
144 2014-04-14 06:47:53 <splitting> seems like it does in the code
145 2014-04-14 06:48:11 <splitting> if you dont define a port/username/address/etc
146 2014-04-14 06:50:45 <rando> drgdrg
147 2014-04-14 06:59:35 <wumpus> any native English speaker with thoughts on this? https://github.com/bitcoin/bitcoin/pull/4015
148 2014-04-14 07:00:27 <warren> wumpus: which English? http://lolsnaps.com/news/77368/0/
149 2014-04-14 07:00:28 <warren> =)
150 2014-04-14 07:01:17 <warren> wumpus: IMHO, both : and ; are awkward in that context
151 2014-04-14 07:01:24 <wumpus> ... lol :) no, doesn't matter which one... just someone that understands punctuation
152 2014-04-14 07:01:41 <wumpus> that was not the kind of answer i was hoping to hear, I'm looking to either close or merge the pull
153 2014-04-14 07:01:50 <warren> they're both bad
154 2014-04-14 07:02:07 <wumpus> sigh: so it isn't an improvement?
155 2014-04-14 07:02:19 <warren> definitely not an improvement
156 2014-04-14 07:02:32 <warren> but the original is bad
157 2014-04-14 07:02:49 <wumpus> submit a new pull then
158 2014-04-14 07:03:06 <warren> I'm tried to test my newly fixed suffix generator
159 2014-04-14 07:03:18 <warren> but I have to rebase openssl to make it run at all
160 2014-04-14 07:05:06 <warren> whoa, not getting enough sleep
161 2014-04-14 07:32:33 <wumpus> anyone with Windows and IPv6 that would like to help testing -rpcbind https://github.com/bitcoin/bitcoin/pull/3695 ?
162 2014-04-14 07:32:46 <wumpus> if so, I can build test executables
163 2014-04-14 07:59:10 <michagogo> cloud|wumpus: I wish :-/
164 2014-04-14 08:02:58 <wumpus> I'm really struggling to get that patch tested, I already asked on the development list once, no response at all
165 2014-04-14 08:03:09 <wumpus> maybe it's only me caring about it and I should close it
166 2014-04-14 08:05:39 <kdomanski> at the time the team is struggling to find a single person running Windows
167 2014-04-14 08:06:00 <buZz> i can run ipv6 windows test tomorrow or maybe day after
168 2014-04-14 08:06:03 <wumpus> btw it's also fine if you want to test it on linux or macosx, but windows is generally the most difficult to find testers for
169 2014-04-14 08:06:22 <buZz> i have ipv6 on linux working ..
170 2014-04-14 08:06:31 <buZz> and could test stuff for you today
171 2014-04-14 08:06:44 <wumpus> I usually do windows testing in wine, but I have no real (non-localhost) IPv6 network
172 2014-04-14 08:06:47 <wumpus> that'd be great!
173 2014-04-14 08:07:10 <wumpus> (and I have a VM with windows xp, also no help with ipv6)
174 2014-04-14 08:07:47 <buZz> the sixxs tunnel stuff works on xp afaik
175 2014-04-14 08:08:12 <buZz> they're just bitches when it comes to following rules
176 2014-04-14 08:08:16 <wumpus> does it? last time I tried, even the ipv6 tests failed on xp, but maybe soe extra software is needed
177 2014-04-14 08:08:51 <buZz> well you might need to install the protocol ;)
178 2014-04-14 08:09:05 <wumpus> heh
179 2014-04-14 08:09:23 <buZz> anyway, just highlight me when you need something tested on a ipv6 enabled machine
180 2014-04-14 08:09:33 <buZz> debian squeeze btw
181 2014-04-14 08:10:04 <wumpus> installing a protocol, how quant, makes me think of the 90's, installing the IPX protocol to be able to network in the house :-)
182 2014-04-14 08:10:05 <michagogo> cloud|I wish IPv6 was a thing for Israeli residential connections
183 2014-04-14 08:10:23 <warren> given that Windows XP has no updates from Microsoft anymore
184 2014-04-14 08:10:27 <michagogo> cloud|(It's not yet afaik)
185 2014-04-14 08:10:37 <buZz> XP had ipv6 on the original disk ..
186 2014-04-14 08:10:39 <wumpus> buZz: ok, I can make a static linux build as well if you'd like to test it on linux
187 2014-04-14 08:10:49 <warren> perhaps we should drop support entirely so as not to encourage use on an insecure platform
188 2014-04-14 08:10:52 <buZz> wumpus: yes, willing and able
189 2014-04-14 08:11:55 <wumpus> warren: it makes some sense, but it's not convincing enough in itself, if you find any other good reason for dropping XP support let's make a list
190 2014-04-14 08:12:47 <wumpus> do you know of any other software that dropped XP support for this reason?
191 2014-04-14 08:12:51 <buZz> i remember, back when i had 100mbit fdx edu link at home, installing XP (SP0) on a system hooked up to external internet
192 2014-04-14 08:13:01 <buZz> you would have a virus before finishing the install ;)
193 2014-04-14 08:13:36 <wumpus> yup :)
194 2014-04-14 08:14:33 <warren> wumpus: when security updates are published for Windows 7, people will dissect them and see if the equivalent is vulnerable on XP... and many are
195 2014-04-14 08:16:11 <wumpus> warren: I know that; but there will be backlash. I'm pretty sure that in practice a sizable % of users (especially outside of the west) will still be on xp....
196 2014-04-14 08:16:33 <wumpus> so then the choice would be to deny them bitcoin completely because it's more secure?
197 2014-04-14 08:16:58 <warren> Multibit? Electrum?
198 2014-04-14 08:17:13 <wumpus> shouldn't they make the same decision?
199 2014-04-14 08:17:44 <wumpus> if it's too insecure to run bitcoin, it's too insecure to run *any* wallet, including online or SPV ones
200 2014-04-14 08:18:21 <warren> hmm
201 2014-04-14 08:18:27 <warren> perhaps we should add a OS warning
202 2014-04-14 08:18:32 <wumpus> I don't want to make that decision for people
203 2014-04-14 08:18:38 <wumpus> yes, a warning would be good
204 2014-04-14 08:23:00 <michagogo> cloud|The warning should have a text box that requires you to type either "I understand that I may lose my bitcoins at any time because I'm running an insecure operating system" or "I work for the UK government and have paid Microsoft millions of pounds to keep updating Windows XP"
205 2014-04-14 08:29:11 <edcba> uk gov or IRS
206 2014-04-14 08:39:06 <warren> wumpus: uh... "If you change this to be version 0.9.99 I'll merge it."
207 2014-04-14 08:39:20 <warren> wumpus: why change it to that when you said the next release from this branch will be 0.9.2?
208 2014-04-14 08:39:35 <warren> wumpus: you're the one who corrected me when I thought the next release would be 0.10
209 2014-04-14 08:40:44 <warren> see my next push
210 2014-04-14 08:40:49 <epscy> michagogo|cloud: yeah sadly the UK gov aren't the only ones who are paying for support for a 10 year old OS
211 2014-04-14 09:10:12 <yuhMappangpang> waz dit voor illegale chat
212 2014-04-14 09:12:22 <kdomanski> wat
213 2014-04-14 09:16:11 <hno> strange. everytime I am to test pool changes on testnet someone else starts to mine like crazy.
214 2014-04-14 09:17:23 <Apocalyptic> they must be watching you
215 2014-04-14 09:19:35 <Luke-Jr> lol
216 2014-04-14 09:19:59 <warren> https://github.com/nightlybitcoin/bitcoin/commits/0.9.1.99-20140414-g76db4e2
217 2014-04-14 09:20:27 <warren> automatically merges whatever PR's I want people to test, builds, signs and pushes
218 2014-04-14 09:21:56 <iajdiojdoaehfef> hello
219 2014-04-14 09:22:06 <iajdiojdoaehfef> how to mining bitcoins using linux mint 16 petra
220 2014-04-14 09:22:14 <iajdiojdoaehfef> how to mine*
221 2014-04-14 09:22:18 <buZz> iajdiojdoaehfef: ask in #bitcoin, not here
222 2014-04-14 09:22:40 <iajdiojdoaehfef> and have anybody any dev tools for bitcoin using the terminal
223 2014-04-14 09:22:50 <buZz> vim, emacs, nano
224 2014-04-14 09:22:52 <iajdiojdoaehfef> which package
225 2014-04-14 09:23:16 <warren> iajdiojdoaehfef: your questions are not suitable for this channel
226 2014-04-14 09:29:45 <nederhoed> Good day, I've ran into a failed build on Launchpad Ubuntu Saucy bitcoin PPA for i386
227 2014-04-14 09:29:47 <nederhoed> http://link.marktplaats.nl/m799401169
228 2014-04-14 09:29:50 <nederhoed> oops
229 2014-04-14 09:31:10 <nederhoed> https://launchpad.net/~bitcoin/+archive/bitcoin/+build/5841913
230 2014-04-14 09:32:55 <nederhoed> I've emailed channel owner Matt last week, but have not yet received a response. This is my second shot: IRC for developers. It would be nice if users of the latest Ubuntu can upgrade their bitcoind easiliy. Thanks.
231 2014-04-14 09:39:23 <gribble> BlueMatt was last seen in #bitcoin-dev 2 days, 16 hours, 21 minutes, and 52 seconds ago: <BlueMatt> (Why is it not posting those messages in here?)
232 2014-04-14 09:39:23 <owowo> !seen BlueMatt
233 2014-04-14 09:39:54 <BlueMatt> hmm?
234 2014-04-14 09:43:45 <owowo> nederhoed: ^
235 2014-04-14 09:44:25 <Luke-Jr> BlueMatt: 0.9.0 fails on PPA apparently
236 2014-04-14 09:45:51 <warren> grrrr
237 2014-04-14 09:45:52 <warren> i686-w64-mingw32-g++: internal compiler error: Killed (program cc1plus)
238 2014-04-14 09:46:04 <warren> gitian =(
239 2014-04-14 09:49:11 <sipa> warren: oo?
240 2014-04-14 09:49:42 <warren> sipa: while building boost in gitian g++ crashes ... but only sometimes
241 2014-04-14 09:49:52 <sipa> oom?
242 2014-04-14 09:50:06 <warren> good question
243 2014-04-14 09:51:53 <Luke-Jr> warren: with the default -j?
244 2014-04-14 09:52:22 <warren> -j4
245 2014-04-14 09:52:31 <sipa> try reducing it
246 2014-04-14 09:52:58 <jaromil> omit it completely, parallel build is likely to break boost
247 2014-04-14 09:54:11 <jaromil> well, -j1 is equivalent to omission
248 2014-04-14 09:54:42 <warren> why are we using boost again?
249 2014-04-14 09:56:03 <jaromil> afaik boost provides quite some needed primitives, but I'm unaware of any progress you've done in 0.9 to omit it. one main reason I like picocoin is that there is no boost::
250 2014-04-14 09:56:34 <jaromil> would be real nice to remove the dep from bitcoind
251 2014-04-14 09:58:53 <jaromil> bitcoin uses boost:: system, filesystem, program_options and thread - sounds like it wouldn't be hard to substitute them
252 2014-04-14 09:59:56 <jaromil> ACTION is petting the idea of a new pull req in his mind
253 2014-04-14 10:00:38 <jaromil> at first glance the culprit is system and filesystem portability on win32
254 2014-04-14 10:01:27 <Luke-Jr> jaromil: isn't picocoin worse (glib)?
255 2014-04-14 10:01:44 <jaromil> Luke-Jr: one may argue, yes. you have a point
256 2014-04-14 10:01:48 <sipa> jaromil: i'm not a very large fan of boost, but right now it's just inevitable
257 2014-04-14 10:01:54 <Luke-Jr> jaromil: if we depend on QtCore for bitcoind, we could use that for filesystem paths
258 2014-04-14 10:02:02 <warren> certainly qt would have suitable replacements for that on windows
259 2014-04-14 10:02:05 <jaromil> ack
260 2014-04-14 10:02:10 <sipa> jaromil: just maintaining a set of win32-compatible file API things is something i'm not eager to do
261 2014-04-14 10:02:28 <jaromil> sipa: no i also wouldn't advice for that
262 2014-04-14 10:02:39 <sipa> Luke-Jr: yuck (bitcoind depending on Qt)
263 2014-04-14 10:02:45 <Luke-Jr> sipa: just QtCore
264 2014-04-14 10:02:59 <sipa> still yuck :)
265 2014-04-14 10:03:09 <jaromil> which is as big and painful as boost:: to compile
266 2014-04-14 10:03:20 <Luke-Jr> we could alternatively drop Windows support for bitcoind? :P
267 2014-04-14 10:03:25 <jaromil> lol yea
268 2014-04-14 10:03:29 <kinlo> eh, doesn't gtk depend on glib, doesn't it make sense to depend on glib for bitcoin too?
269 2014-04-14 10:03:33 <sipa> is there something like reverse-wine ?
270 2014-04-14 10:03:43 <Luke-Jr> kinlo: NO; I don't want glib/gtk garbage
271 2014-04-14 10:03:55 <kinlo> and QT for that matter - qt changed their lib to glib too
272 2014-04-14 10:03:55 <roybadami> cygwin?
273 2014-04-14 10:03:57 <warren> sipa: you mean cygwin?
274 2014-04-14 10:04:04 <Luke-Jr> sipa: Cygwin
275 2014-04-14 10:04:12 <sipa> cygwin can't run linux binaries on windows
276 2014-04-14 10:04:13 <Luke-Jr> kinlo: no, they did n't.
277 2014-04-14 10:04:17 <warren> cygwin doesn't look very well maintained
278 2014-04-14 10:04:28 <sipa> cygwin is a separate environment you can compile for & with
279 2014-04-14 10:04:32 <Luke-Jr> sipa: oh. coLinux then. :P
280 2014-04-14 10:04:33 <sipa> but it's not binary compatible with linux
281 2014-04-14 10:04:42 <warren> Linux can run the win32 binary just fine! =)
282 2014-04-14 10:04:49 <jaromil> QT now depends on glib?!
283 2014-04-14 10:05:05 <Luke-Jr> jaromil: you can optionally compile it to use glib's event loop, then it runs slower
284 2014-04-14 10:05:13 <jaromil> phew
285 2014-04-14 10:05:17 <Luke-Jr> (mainly because glib is slower :P)
286 2014-04-14 10:05:36 <jaromil> yea, i had my horror experience with gstreamer when fiddling with video
287 2014-04-14 10:05:48 <Luke-Jr> ACTION stabs KDE for pushing more glib dependency on things
288 2014-04-14 10:05:50 <jaromil> since then, anything with a g in front is trash to my eyes
289 2014-04-14 10:06:08 <jaromil> qt has better code for sure
290 2014-04-14 10:07:00 <warren> doesn't qt have its own crypto library?
291 2014-04-14 10:07:10 <Luke-Jr> warren: not really.
292 2014-04-14 10:07:23 <Luke-Jr> there's QCA, but IIRC it sucks
293 2014-04-14 10:07:27 <jaromil> gtk was designed as a toolkit to substitute visual basic style stuff. code a video player and put your logo on it, lame stuff
294 2014-04-14 10:07:43 <Luke-Jr> jaromil: this explains a lot..
295 2014-04-14 10:07:58 <jaromil> its my way to explain it in short
296 2014-04-14 10:08:10 <jaromil> the only coder i rly respect in there is pippin (gimp)
297 2014-04-14 10:08:16 <jaromil> who is not using glib anymore afaik
298 2014-04-14 10:08:28 <Luke-Jr> he should defect to Krita :P
299 2014-04-14 10:08:45 <jaromil> ACTION having a look
300 2014-04-14 10:10:04 <jaromil> nice. never tried. i mostly use console and imagemagick :P
301 2014-04-14 10:10:38 <jaromil> i'm not sure pippin defected glib now looking at gegl http://gegl.org
302 2014-04-14 10:11:17 <jaromil> anyway, his latest thing is old-school oriented (but hosted on gnome) https://git.gnome.org/browse/pinpoint/
303 2014-04-14 10:11:59 <jaromil> "a simple presentation tool that hopes to avoid audience death by bullet point" lol
304 2014-04-14 10:13:23 <buZz> jaromil: \o/
305 2014-04-14 10:14:35 <jaromil> hey buzz :) you love it don't you. reminds me of tp (was that the name) but is not perl. now i recall you showed it to me first
306 2014-04-14 10:14:55 <jaromil> anyway i'm still sticking to emacs org-mode context
307 2014-04-14 10:14:59 <buZz> so many of these tools :P
308 2014-04-14 10:15:34 <jaromil> and we play all kinds of music! country AND western!
309 2014-04-14 10:17:36 <buZz> hahaha
310 2014-04-14 10:17:38 <buZz> :D
311 2014-04-14 10:18:43 <wumpus> there are no plans at all to remove the boost dependency from bitcoin
312 2014-04-14 10:19:40 <jaromil> reasonable conclusion. as far as I see there is no good candidate to replace portable C++ filesystem access
313 2014-04-14 10:19:40 <wumpus> boost is a very useful library, and the alternative generally is to roll all kinds of cross-platform wrappers and other boring stuff yourself, with the addional testing and maintenance that brings
314 2014-04-14 10:20:52 <wumpus> (I know that switching to C++11 would get rid of some reasons to use boost, for example threading, but certainly not all of them)
315 2014-04-14 10:21:23 <jaromil> well, genjix is using C++11 to code libbitcoin, yet he is exploiting even more boost:: primitives (and requires the very latest boost release)
316 2014-04-14 10:21:43 <jaromil> so at least in his case c++11 didn't substitute boost
317 2014-04-14 10:22:00 <wumpus> it doesn't
318 2014-04-14 10:22:07 <wumpus> as i said, some parts
319 2014-04-14 10:22:17 <wumpus> but there is lots of usefull code in boost that is not in any standard library
320 2014-04-14 10:23:18 <wumpus> also boost is only one dependency; the alternative would be to have even more dependencies, one for each use case of boost
321 2014-04-14 10:23:49 <wumpus> one dependency for json parsing/formatting, one for signals/slots, one for os-independent pathname handling, one of asynchronous networking, and so on
322 2014-04-14 10:24:38 <warren> eh, don't we include an entire json library?
323 2014-04-14 10:24:55 <wumpus> warren: it's very small though, thanks to boost::spriti
324 2014-04-14 10:25:15 <wumpus> in any case I don't feel like arguing this
325 2014-04-14 10:25:26 <jaromil> boost handles the collection for all those. i remember when spirit was standalone
326 2014-04-14 10:25:52 <jaromil> i also am convinced about boost:: being the best possible dep
327 2014-04-14 10:26:16 <wumpus> depending on boost is not a problem in my eyes, it may be some effort to get it compiled on some platforms, and to link to it (m4 autotools mess), but that's it... there are more important considerations than that
328 2014-04-14 10:27:47 <wumpus> a more worthwhile project would be to make gitian work on windows (without having to resort to LXC container-in-a-VM)
329 2014-04-14 10:28:27 <warren> eh
330 2014-04-14 10:28:41 <warren> you would still need a VM
331 2014-04-14 10:28:50 <wumpus> ... obviously
332 2014-04-14 10:29:06 <wumpus> but only one level, not inception
333 2014-04-14 10:29:07 <warren> and you won't be able to create the VM from windows
334 2014-04-14 10:29:27 <warren> not using gitian itself at least
335 2014-04-14 10:29:57 <wumpus> I'm sure it would be possible, of course you'd need to do some work, you can't rely on the same utilities to exist as on linux
336 2014-04-14 10:30:24 <warren> well, ruby and nearly all the tools would work from cygwin
337 2014-04-14 10:30:35 <warren> you just can't debootstrap from cygwin
338 2014-04-14 10:31:30 <wumpus> I'm not sure it's worth it either, making the current LXC-in-VM easier would be nice already, but it's more productive than say, trying to get rid of boost
339 2014-04-14 10:32:02 <wumpus> it actually attacks the probem instead of running away from it
340 2014-04-14 10:32:27 <warren> how many windows devs do we have?
341 2014-04-14 10:33:19 <wumpus> that doesn't matter, making it easier would probably result in more devs
342 2014-04-14 10:35:44 <wumpus> ideally the gitian build would just be pushing a button
343 2014-04-14 10:47:43 <wumpus> buZz: added test builds https://github.com/bitcoin/bitcoin/pull/3695
344 2014-04-14 10:47:56 <CodeShark> we should still move to C++11, even if it doesn't get rid of all boost dependencies :)
345 2014-04-14 10:48:13 <CodeShark> it's nicer when things like for (auto& item: items) are part of the language
346 2014-04-14 10:48:22 <CodeShark> rather than having to use BOOST_FOREACH and stuff like that
347 2014-04-14 10:48:47 <sipa> CodeShark: yes, absolutely, but as long as we're stuck on supporting older platforms with too old compilers...
348 2014-04-14 10:48:48 <wumpus> CodeShark: yes, it's nicer, but there is not a convincing reason yet and it makes compatibility with older/stable linux distros even more difficult
349 2014-04-14 10:49:11 <wumpus> CodeShark: see https://github.com/bitcoin/bitcoin/pull/4025
350 2014-04-14 10:49:15 <warren> wumpus: with gitian kvm you mentioned that you modified your base images to include all the build deps to make it faster?
351 2014-04-14 10:50:01 <wumpus> warren: that wasn't me; I think it was gavin that uses virtualbox images with all deps installed
352 2014-04-14 10:51:16 <warren> hmm, who was it
353 2014-04-14 10:51:21 <warren> sipa: ?
354 2014-04-14 10:53:00 <CodeShark> by the time some of these old compilers support C++11, we'll already be using C++14 :p
355 2014-04-14 10:54:04 <dexX7> i run into the problem of too many open files and i was wondering, if there is a way to manually close those? the methods in use are listalltransactions, listallunspent and getallbalance https://github.com/dexX7/bitcoin/blob/29b143ff821fb29d00e70025236ed7e549d2042c/src/rpcrawtransaction.cpp#L205 (based on the addrindex branch) + i'm iterating through a block to find the position of a tx in TxToJSON
356 2014-04-14 10:54:05 <CodeShark> I worked on a project recently where I just automated backporting for older compilers
357 2014-04-14 10:54:08 <CodeShark> but yeah, it is a pain
358 2014-04-14 10:54:44 <CodeShark> as long as the backport can be automated using simple pattern search-and-replace, it's not too bad
359 2014-04-14 10:55:23 <CodeShark> but that's only a relatively small subset of all the C++11 features we might want to use
360 2014-04-14 10:55:31 <CodeShark> others require more sophisticated parsing
361 2014-04-14 10:56:01 <CodeShark> however, it's possible to help out the parser by adding formatted comments into the code
362 2014-04-14 10:58:04 <CodeShark> I have to say it's almost worth the effort doing this, if only because of good coding habits that C++11 allows
363 2014-04-14 10:59:53 <buZz> ERROR: certificate common name âviridian.visucore.comâ doesnât match requested host name âdownload.visucore.comâ.
364 2014-04-14 10:59:56 <buZz> sigh
365 2014-04-14 11:01:40 <buZz> wumpus: alright, anything specific you want me to test with it?
366 2014-04-14 11:09:57 <wumpus> buZz: hah, your ssl client doesn't support SNI
367 2014-04-14 11:10:24 <warren> wumpus: that's one sign of Windows XP ...
368 2014-04-14 11:10:26 <wumpus> buZz: test the -rpcbind option, for example make it listen on only a certain IPv6 interface, or IPv6 addr:port
369 2014-04-14 11:12:33 <wumpus> CodeShark: we'll do it eventually, just not yet
370 2014-04-14 11:13:04 <wumpus> at this point it would create more problems than it solves, and if there's anything we have enough of, it's issues
371 2014-04-14 11:14:23 <buZz> hmm, -rpcbind doesnt seem to work at all, no input whatsoever lets me start up a server?
372 2014-04-14 11:14:36 <buZz> $ ./bitcoind.static -rpcbind 127.0.0.1:5555
373 2014-04-14 11:14:36 <buZz> error: no response from server
374 2014-04-14 11:14:44 <wumpus> -rpcbind=
375 2014-04-14 11:14:49 <buZz> derp, ok
376 2014-04-14 11:15:44 <buZz> its not binding to what i specify ..
377 2014-04-14 11:16:45 <buZz> $ ./bitcoind.static -rpcbind=127.0.0.1:8888
378 2014-04-14 11:16:45 <buZz> Bitcoin server starting
379 2014-04-14 11:16:49 <wumpus> does rpcbind= appear in --help output?
380 2014-04-14 11:17:02 <buZz> yet:
381 2014-04-14 11:17:03 <buZz> tcp 0 0 127.0.0.1:8332 0.0.0.0:* LISTEN 13311/bitcoind.stat
382 2014-04-14 11:17:19 <buZz> -rpcbind=<addr> Bind to given address to listen for JSON-RPC connections. Use [host]:port notation for IPv6 (default: bind to all interfaces)
383 2014-04-14 11:17:35 <kdomanski> btw. one of the challenges with moving from boost std facilities is lack of thread interruption feature in std::thread
384 2014-04-14 11:18:17 <wumpus> if so, can you try with -debug=rpc .. messages like "Binding RPC on address" should then appear in the log
385 2014-04-14 11:20:50 <buZz> alright
386 2014-04-14 11:20:54 <wumpus> buZz: oh wait.. yeah, you need to provide an -rpcallowip for bind to work
387 2014-04-14 11:21:28 <wumpus> otherwise it would be allowing everyone that can connect, which could result in accidental security problems
388 2014-04-14 11:21:43 <buZz> 2014-04-14 11:21:14 Binding RPC on address ::1 port 8332 (IPv4+IPv6 bind any: 0)
389 2014-04-14 11:21:47 <wumpus> (providing multiple rpcallowips, or wildcards, is allowed though)
390 2014-04-14 11:22:15 <wumpus> hm, good catch, going to add a warning when -rpcbind is ignored
391 2014-04-14 11:27:45 <warren> is there a standard way to increase the number of cores and RAM you give to gitian?
392 2014-04-14 11:28:33 <warren> crud ... my script unintentionally spams PR's
393 2014-04-14 11:30:42 <Luke-Jr> lechuga_: ping, any updates?
394 2014-04-14 11:49:09 <wumpus> buZz: any luck with -rpcallowip?
395 2014-04-14 12:32:29 <wumpus> @warren, Luke-Jr FYI I removed the de_AT translation, it was giving too many complaints (see #4054, #3918)
396 2014-04-14 12:32:32 <michagogo> cloud|This should work, right? $ cat bootstrap.dat.279000 ../bootstrap.dat.279001-295000 >> bootstrap.dat
397 2014-04-14 12:33:00 <wumpus> michagogo|cloud: yes
398 2014-04-14 12:34:01 <michagogo> cloud|ACTION waits for linearize to exit
399 2014-04-14 13:38:51 <michagogo> cloud|;;later tell BlueMatt Does the PPA have a package for trusty?
400 2014-04-14 13:38:52 <gribble> The operation succeeded.
401 2014-04-14 13:40:02 <daemon> hey all for the version packet, 'Node ID/Random unique ID'
402 2014-04-14 13:40:04 <daemon> what is it?
403 2014-04-14 13:40:19 <daemon> just a bunch of crap
404 2014-04-14 13:40:22 <daemon> or
405 2014-04-14 13:40:44 <daemon> will 'time' do ?
406 2014-04-14 13:40:50 <daemon> its the same size field after all
407 2014-04-14 13:44:25 <jgarzik> blk00000.dat Year 2009, height 0-32489
408 2014-04-14 13:44:25 <jgarzik> blk00001.dat Year 2010, height 32490-100409
409 2014-04-14 13:44:25 <jgarzik> blk00002.dat Year 2011, height 100410-160036
410 2014-04-14 13:44:25 <jgarzik> blk00003.dat Year 2012, height 160037-214562
411 2014-04-14 13:44:25 <jgarzik> blk00004.dat Year 2013, height 214563-277995
412 2014-04-14 13:44:26 <jgarzik> blk00005.dat Year 2014, height 277996-295000
413 2014-04-14 13:44:28 <jgarzik> blk00000.dat Year 2009, height 0-32489
414 2014-04-14 13:44:32 <jgarzik> blk00001.dat Year 2010, height 32490-100409
415 2014-04-14 13:44:34 <jgarzik> blk00002.dat Year 2011, height 100410-160036
416 2014-04-14 13:44:36 <jgarzik> blk00003.dat Year 2012, height 160037-214562
417 2014-04-14 13:44:38 <jgarzik> blk00004.dat Year 2013, height 214563-277995
418 2014-04-14 13:44:40 <jgarzik> blk00005.dat Year 2014, height 277996-295000
419 2014-04-14 13:44:42 <jgarzik> ACTION kicks OSX
420 2014-04-14 13:44:45 <jgarzik> -rw-rw-r-- 1 jgarzik jgarzik 7621604 Apr 14 04:06 blk00000.dat
421 2014-04-14 13:44:46 <jgarzik> -rw-rw-r-- 1 jgarzik jgarzik 53371054 Apr 14 04:22 blk00001.dat
422 2014-04-14 13:44:48 <jgarzik> -rw-rw-r-- 1 jgarzik jgarzik 802206421 Apr 14 04:53 blk00002.dat
423 2014-04-14 13:44:50 <jgarzik> -rw-rw-r-- 1 jgarzik jgarzik 3796927049 Apr 14 05:26 blk00003.dat
424 2014-04-14 13:44:52 <jgarzik> -rw-rw-r-- 1 jgarzik jgarzik 9385919767 Apr 14 06:12 blk00004.dat
425 2014-04-14 13:44:54 <jgarzik> -rw-rw-r-- 1 jgarzik jgarzik 3476010503 Apr 14 13:43 blk00005.dat
426 2014-04-14 13:45:42 <daemon> so, yeah if anyone can offer some guidance on exactly what that field is meant to have
427 2014-04-14 13:45:44 <daemon> woudl be handy ;)
428 2014-04-14 13:46:02 <daemon> if it is just meant to be a unique identifier for my client
429 2014-04-14 13:46:04 <sipa> daemon: it's there so you can detect accidentally connections to yourself
430 2014-04-14 13:46:06 <daemon> how the hell would I know if its unique
431 2014-04-14 13:46:10 <daemon> AH
432 2014-04-14 13:46:23 <daemon> that makes more sence
433 2014-04-14 13:46:26 <daemon> thank you sipa
434 2014-04-14 13:47:32 <daemon> hmm
435 2014-04-14 13:47:35 <daemon> from the docs:
436 2014-04-14 13:47:44 <daemon> Node random nonce, randomly generated every time a version packet is sent. This nonce is used to detect connections to self.
437 2014-04-14 13:47:48 <daemon> why random
438 2014-04-14 13:47:54 <daemon> if its only used to detect connections to my self
439 2014-04-14 13:47:56 <daemon> why can't I make it static
440 2014-04-14 13:48:05 <sipa> if it's not random, other peers may guess it
441 2014-04-14 13:48:08 <daemon> because if more than one person was using my client
442 2014-04-14 13:48:13 <daemon> right
443 2014-04-14 13:48:14 <sipa> and make you think you're connecting to yourself
444 2014-04-14 13:48:29 <daemon> ok thats going to be a major pita with so many outbound connections
445 2014-04-14 13:48:37 <daemon> ill have to keep some sort of local cache of created nonce's
446 2014-04-14 13:49:28 <sipa> bitcoin core just uses a single global variable
447 2014-04-14 13:49:36 <sipa> which is reset before every outgoing request
448 2014-04-14 13:49:41 <sipa> and checked on every incoming one
449 2014-04-14 13:49:50 <sipa> the nice thing about connections to yourself is that they are fast :)
450 2014-04-14 13:50:07 <sipa> so there is little risk over overlapping with another outgoing/incoming request
451 2014-04-14 13:50:32 <daemon> true :) I can make a $nonceCache and make the keys the nonce giving me $nonceCache->{NONCE} = time
452 2014-04-14 13:50:44 <daemon> if ever the time is > 2 I can safely assume its not local
453 2014-04-14 13:50:47 <daemon> and someone is trying to be funny
454 2014-04-14 13:50:53 <michagogo> cloud|jgarzik: Scanning my self-updated bootstrap.dat now
455 2014-04-14 13:51:14 <sipa> daemon: another solution is just keep a nonce per peer (you probably need a per-peer datastructure anyway)
456 2014-04-14 13:51:31 <michagogo> cloud|Is the u[dated file 17522056398 bytes
457 2014-04-14 13:51:32 <michagogo> cloud|?
458 2014-04-14 13:51:35 <michagogo> cloud|updated*
459 2014-04-14 13:51:37 <daemon> its not really compatible with the way I have wrote the client
460 2014-04-14 13:51:43 <daemon> oh wait ... it possible is
461 2014-04-14 13:51:48 <sipa> what client are you writing?
462 2014-04-14 13:51:52 <daemon> my own
463 2014-04-14 13:51:58 <sipa> for doing what?
464 2014-04-14 13:52:00 <daemon> POE-Component-Client-Bitcoin
465 2014-04-14 13:52:04 <daemon> nothing really
466 2014-04-14 13:52:08 <sipa> ic
467 2014-04-14 13:52:09 <jgarzik> michagogo|cloud, yes
468 2014-04-14 13:52:15 <daemon> just thought there isn't one so I will write it
469 2014-04-14 13:52:16 <daemon> lol
470 2014-04-14 13:52:17 <michagogo> cloud|Great, I'll be a seed shortly
471 2014-04-14 13:52:37 <jgarzik> michagogo|cloud, gimme a sec, and I'll give a sha256sum snippet
472 2014-04-14 13:52:45 <michagogo> cloud|(well, tonight and tomorrow is the first day of Pesach, so my computer will be off, but as long as it's on, I'll be a seed
473 2014-04-14 13:53:11 <michagogo> cloud|)
474 2014-04-14 13:55:49 <buZz> oh, lets see
475 2014-04-14 13:55:51 <michagogo> cloud|I wish I could tell this thing to check from the end
476 2014-04-14 14:01:11 <buZz> wumpus: you have a PM
477 2014-04-14 14:03:40 <vetch> michagogo|cloud: which torrent client?
478 2014-04-14 14:04:07 <michagogo> cloud|vetch: μTorrent
479 2014-04-14 14:04:32 <vetch> michagogo|cloud: right click, there's a "verify" command somewhere that will verify the chunks
480 2014-04-14 14:04:52 <michagogo> cloud|Huh?
481 2014-04-14 14:04:56 <michagogo> cloud|I don't think you understand
482 2014-04-14 14:05:16 <michagogo> cloud|I just loaded up a torrent, jgarzik's latest bootstrap.dat
483 2014-04-14 14:05:33 <michagogo> cloud|I generated the file myself, updating what I had before
484 2014-04-14 14:05:53 <vetch> michagogo|cloud: entirely possible. I thought you were manually assembling the new bootstrap file and wanted to check it was consistent with the .torrent.
485 2014-04-14 14:06:00 <michagogo> cloud|Correct
486 2014-04-14 14:06:09 <michagogo> cloud|Now it's scanning that file to verify that it's accurate
487 2014-04-14 14:06:22 <vetch> michagogo|cloud: yeah, right clicking and "force recheck" will verify the files match the SHA1, and discard and redownload any chunks that don't
488 2014-04-14 14:06:24 <michagogo> cloud|I'm just saying, I wish I could tell it to do that scanning from the end
489 2014-04-14 14:06:35 <michagogo> cloud|...it's checking.
490 2014-04-14 14:06:36 <vetch> oh!
491 2014-04-14 14:06:47 <vetch> apologies.
492 2014-04-14 14:06:52 <michagogo> cloud|I'd just like it to check from the end, so I can know now if what I did was correct
493 2014-04-14 14:06:54 <michagogo> cloud|np :)
494 2014-04-14 14:07:39 <vetch> if I'd been around before I'd have generated some parity files for you, quicker and easier.
495 2014-04-14 14:08:11 <vetch> reed-solomon <3
496 2014-04-14 14:08:38 <hno> Is it possible to ask bitcoind to tracka "foreign" address as if it was local, allowing listtransactions etc to query transactions?
497 2014-04-14 14:09:24 <vetch> that's not a feature supported by bitcoind, no. there's a "watch wallet" patch that hasn't been pulled in that does though.
498 2014-04-14 14:09:45 <vetch> don't know if you can merge it with the current head, but it works
499 2014-04-14 14:10:30 <michagogo> cloud|vetch: hm?
500 2014-04-14 14:10:42 <hno> Has that patch been rejected, or simply not yet pulled in?
501 2014-04-14 14:10:56 <michagogo> cloud|I think the pull was closed
502 2014-04-14 14:10:56 <vetch> michagogo|cloud: not sure what I mean by parity, or the watch wallet bit?
503 2014-04-14 14:11:05 <michagogo> cloud|vetch: the torrent thing
504 2014-04-14 14:11:05 <vetch> oh right.
505 2014-04-14 14:11:47 <michagogo> cloud|(the "hm?" was at the torrent thing)
506 2014-04-14 14:13:29 <Luke-Jr> hno: it's buggy
507 2014-04-14 14:13:46 <vetch> michagogo|cloud: well because you have a large portion of the file already, I can create parity data from my complete copy that can be used to very resiliently repair yours. there's a really neat package called "par2" which lets you create recovery data from any file set, it does a great job of recovering even the most utterly destroyed copies of files. I've had copies of files mangled by FTP and par2 has been able to repair them with a few kilobytes of
508 2014-04-14 14:13:47 <vetch> recovery data.
509 2014-04-14 14:14:25 <vetch> michagogo|cloud: it's sort of redundant if the torrent client can work it out, but still a useful tool to know about.
510 2014-04-14 14:14:42 <hno> Any usable code around (preferably python) to watch a wallet?
511 2014-04-14 14:14:58 <Luke-Jr> there isn't even a format for watching a wallet :x
512 2014-04-14 14:15:07 <Luke-Jr> Armory supports watch-only copies of its wallets
513 2014-04-14 14:15:30 <Luke-Jr> bitcoind can do the same if you make an "encrypted" copy with the privkey data deleted
514 2014-04-14 14:15:35 <hearn> hno: you can watch wallets with bitcoinj
515 2014-04-14 14:15:45 <hearn> hno: and thatâs usable from python (jython), so ...
516 2014-04-14 14:15:57 <hno> hearn, thanks!
517 2014-04-14 14:16:51 <michagogo> cloud|vetch: I have most of the data
518 2014-04-14 14:17:28 <michagogo> cloud|What I'm missing is exactly the last 3,299,939,533 bytes
519 2014-04-14 14:17:49 <vetch> michagogo|cloud: heh, want me to make you some recovery data?
520 2014-04-14 14:18:01 <michagogo> cloud|I added those 3,299,939,533 bytes onto the end already, I have the complete file
521 2014-04-14 14:18:08 <vetch> OH
522 2014-04-14 14:18:13 <vetch> yeah I'm going to stop talking
523 2014-04-14 14:18:23 <vetch> keep getting the wrong end of the stick.
524 2014-04-14 14:18:36 <michagogo> cloud|I just need μTorrent to go its checking so it acknowledges that I have the whole thing and starts being a seed
525 2014-04-14 14:18:52 <michagogo> cloud|do*
526 2014-04-14 14:18:56 <vetch> yep.
527 2014-04-14 14:19:39 <michagogo> cloud|The actual update of the data was really easy, thanks to my changes to linearize.py
528 2014-04-14 14:19:52 <michagogo> cloud|(which somehow worked despite my not knowing python)
529 2014-04-14 14:26:41 <hno> Luke-Jr, if I add such shadow key to bitcoind then I suppose it wouldn't be wise to try to use the same bitcoind as a wallet? I guess it will try to pick coins from those addresses as well.
530 2014-04-14 14:29:47 <daemon> heya all, just a quick question on the protocol, for version; the example given is:
531 2014-04-14 14:29:47 <daemon> "/Satoshi:0.7.2/" sub-version string (string is 15 bytes long)
532 2014-04-14 14:30:01 <daemon> I notice that the example has the version/client surrounded by / and /
533 2014-04-14 14:30:07 <daemon> is there any reason for that or can I quite happily use
534 2014-04-14 14:30:12 <daemon> daemonClient:0.0.1
535 2014-04-14 14:30:23 <daemon> or whatever I fancy
536 2014-04-14 14:32:13 <hearn> daemon: thereâs a BIP for it
537 2014-04-14 14:32:44 <daemon> hearn, can you call which, there is no link in the documentation I can see
538 2014-04-14 14:33:08 <hearn> https://github.com/bitcoin/bips/blob/master/bip-0014.mediawiki
539 2014-04-14 14:33:11 <daemon> thank you
540 2014-04-14 14:33:55 <daemon> ah I see
541 2014-04-14 14:33:59 <daemon> thank you again hearn
542 2014-04-14 14:34:02 <hearn> np
543 2014-04-14 14:46:47 <michagogo> cloud|jgarzik: f451257f4e22e83dd49756b368b5b97dc1f92d31fa6dc114a0a9a69442490f4c *bootstrap.dat
544 2014-04-14 14:47:19 <michagogo> cloud|(and I'm a seed now, μTorrent verified it)
545 2014-04-14 14:47:21 <michagogo> cloud|Now, g2g
546 2014-04-14 14:47:22 <michagogo> cloud|bbl
547 2014-04-14 14:47:35 <jgarzik> michagogo|cloud, cool
548 2014-04-14 15:09:15 <Luke-Jr> hno: yeah, you can't mix watch-only-hack with a real wallet
549 2014-04-14 15:21:26 <Arpolix> hey
550 2014-04-14 15:21:45 <Arpolix> are these transactions being modified:
551 2014-04-14 15:21:47 <Arpolix> https://blockchain.info/rawtx/e0b06d0436868479e25ce337982efe42863f1e808b86f3e22200dadf69ca7a98
552 2014-04-14 15:44:39 <helo> Arpolix: ¯\_(ã)_/¯
553 2014-04-14 15:46:25 <helo> kind of like asking "is this signature forged?" without supplying a known valid signature
554 2014-04-14 15:47:21 <Arpolix> transactions modified by oppushdata2 can be told to be so on their own
555 2014-04-14 15:47:28 <Arpolix> they dont need the second transaction
556 2014-04-14 15:47:49 <Arpolix> those modified with oppush2 start with 4d4800
557 2014-04-14 15:47:53 <Arpolix> rather than 48
558 2014-04-14 15:48:00 <Arpolix> i think?
559 2014-04-14 16:12:18 <Decide1000_> Hi all. Does someone know a good tutorial I can follow to create my own cryptocurrency on debian?
560 2014-04-14 16:15:24 <vetch> Decide1000_: hi, this is off topic for #bitcoin-dev, take it elsewhere.
561 2014-04-14 16:16:09 <Decide1000_> srry, thanks
562 2014-04-14 16:19:04 <hno> What is the deal with testnet block 00000000001c356b8062fa69ad3690484f5e91a4abaa13c90e96eb61daff5dcd transaction cdd0ee67961298616f9fa0a86eb1db9d76dbe2a92a255ba442a17f2cace75b2a?
563 2014-04-14 16:20:44 <gmaxwell> hno: not a very useful question, looks ordinary enough to me.
564 2014-04-14 16:22:09 <hno> gmaxwell, for some reason my bitcoind claims that tx is not known to i.
565 2014-04-14 16:22:44 <hno> 00006a47304402204c036a670177fdfac812818c226a9c4e47d15615400c5428455bcec7ef3400ad02204d4ab9ac98134537a4a8ed3af6574b3e6f77e5bc61b622a5d729148e78f2a0e10121024cbc5dfd552927adb39d8ae259120a43fd373830f7888154373b9721fccb2ffeffffffff0200ca9a3b000000001976a9142c21cb02b788012a8d7111f3e3e7dc40ab94b57388acf08e6cd0020000001976a914e82437db0e5449cf0a727807256aea482b12d7bb88ac0000000001000000018f37613b07e979c51411e2c074ee96be6458843ef4734a61cca4f2ce0a47cdef010000006b
566 2014-04-14 16:22:44 <hno> 020000000c37fe646e136b6a1b982b9965a83718c8673ddc84da471f79963b5400000000e4ae0c76b606c1229674a257fee04d8192cb1ac47417048f58f7bf83304062d979cc4953c0ff3f1b204b197c0301000000010000000000000000000000000000000000000000000000000000000000000000ffffffff0d03ec6003012f062f503253482fffffffff0120470395000000002321026d02ffec4078478ffa7df80fc6d1179691dc3f1076c770e83706835cbac78d21ac000000000100000001adb8a667b30613865c9e345c5b2172422745d9963f4db10f8b31470a63db04530100
567 2014-04-14 16:22:44 <hno> 483045022100d6673f91af900ee39f67729061b2108b2c82df164cfa7ea2422f3fbe00f39abe0220085eb486af4fa3c084b997928df1a6dfe3be2a8d876af1c1378de2164c225b460121032282c9a15413feffaac10899f2a0dd2c8d1cba14b9019b4d6fdf49e44a47a59cffffffff0220a10700000000001976a914c36de12e2c3e257552daf9f4736ea05e44ce275288ac30cee205000000001976a91449a5d1f556e1771fd04eb71d7960d5835be5903588ac00000000
568 2014-04-14 16:22:48 <gmaxwell> hno: presumably it's been spent and you're not running with the tx index.
569 2014-04-14 16:22:49 <hno> gah!
570 2014-04-14 16:23:12 <hno> sorry for the paste.
571 2014-04-14 16:23:47 <hno> I can query any other tx I have tried, spent or unspent.
572 2014-04-14 16:25:44 <gmaxwell> are you running with txindex=1 on that node?
573 2014-04-14 16:25:59 <gmaxwell> getrawtransaction on that txid works fine for me, but I do see that its spent.
574 2014-04-14 16:27:32 <hno> gmaxwell, seems I am not. Thanks, will try with it enabled.
575 2014-04-14 16:28:41 <vetch> hno: enabling it needs a very lengthy rescan
576 2014-04-14 16:29:10 <hno> I know
577 2014-04-14 16:29:18 <gmaxwell> it's not that lenghty on testnet.
578 2014-04-14 16:29:52 <hno> Any drawbacks from having it enabled other than somewhat higher disk usage? Any significant difference in memory usage?
579 2014-04-14 16:29:57 <hearn> sipa: ping
580 2014-04-14 16:31:01 <gmaxwell> hno: increases IO somewhat, I wouldn't expect memory usage to increase.
581 2014-04-14 16:32:37 <GAit> i'm not too familiar with the details but I did try to read the dev mailing list, I was wondering why for SPV it was decided to use tor over other things and whether using i2p is feasable and if not what the issues would be.
582 2014-04-14 16:32:42 <vetch> gmaxwell: have you seen testnet3 lately? it's getting very big
583 2014-04-14 16:36:02 <hearn> sipa: i am thinking that the double spending tx reject message does not actually work
584 2014-04-14 16:36:42 <hearn> sipa: double spends end up going down the dead âreplace txâ codepath and not even making a log message, let alone sending a reject. but more generally i wonder how we can reliably detect double spends given the utxo set design where spent coins are deleted.
585 2014-04-14 16:37:08 <hearn> GAit: because thereâs a pure java tor library thatâs dead easy to use (though we got word from another user of it that it has a few bugs)
586 2014-04-14 16:38:26 <WOODMAN> http://bitcoinmacroeconomics.com/2014/04/13/interview-with-director-of-cryptoeconomy-engineering-at-blocktech-mr-bryce-weiner/
587 2014-04-14 16:38:31 <GAit> hearn: I see, pragmatic.
588 2014-04-14 16:38:36 <vetch> WOODMAN: stop spamming your irrelevant crap.
589 2014-04-14 16:39:00 <GAit> hearn: no doubt tor improves a lot on the current situation
590 2014-04-14 16:39:20 <vetch> Tor helps and hinders. with Tor Sybil attacks are costless.
591 2014-04-14 16:39:37 <hearn> which is why bitcoinj doesnât connect to hidden services
592 2014-04-14 16:39:43 <hearn> it just uses tor exits to get to the internet
593 2014-04-14 16:39:48 <GAit> vetch: the way it would work with out server is that SPV is only used to make sure the server is not feeding compromised data
594 2014-04-14 16:40:18 <vetch> GAit: the node can still lie by omission.
595 2014-04-14 16:40:50 <GAit> yes, but it's unlikely for both the third party server and the SPV network to be lieing, you'd hope at least it's an improvement
596 2014-04-14 16:41:29 <GAit> we currently use the electrum network for this purpose but it may make more sense to use the same as other wallets
597 2014-04-14 16:41:36 <vetch> hearn: exiting Tor has it's problems too. there's a very small pool of exiting nodes that can be used as a Syil too.
598 2014-04-14 16:41:41 <hearn> yes
599 2014-04-14 16:42:00 <hearn> the hope is that this is less of an issue than local attackers
600 2014-04-14 16:42:07 <vetch> understood
601 2014-04-14 16:42:53 <hearn> also it may (or may not) hinder traffic analysis
602 2014-04-14 16:43:10 <hearn> though i donât have much hope of beating nsa/gchq level adversaries any time soon. not with our resources
603 2014-04-14 16:43:38 <vetch> hearn: that's not a game you can win.
604 2014-04-14 16:43:59 <hearn> i fear you are right
605 2014-04-14 16:44:02 <hearn> ACTION -> out
606 2014-04-14 16:45:56 <BlueMatt> michagogo|cloud: no
607 2014-04-14 17:29:31 <daemon> hello all
608 2014-04-14 17:29:33 <daemon> in the version packet
609 2014-04-14 17:29:35 <daemon> C0 3E 03 00 - Last block sending node has is block #212672
610 2014-04-14 17:29:35 <daemon> what is:
611 2014-04-14 17:29:53 <daemon> ah last block received
612 2014-04-14 17:30:00 <daemon> but what if you have received nothing so far
613 2014-04-14 17:30:03 <daemon> should it be 00 00 00 00
614 2014-04-14 17:30:11 <daemon> or not included