1 2011-12-20 00:00:27 <Diablo-D3> well, for most people, the creation of new transactions is only done once, on a brand new wallet
  2 2011-12-20 00:00:36 <Diablo-D3> so why are you backing up a wallet that has nothing in it
  3 2011-12-20 00:00:56 <Diablo-D3> I could be wrong about when its generated, though
  4 2011-12-20 00:03:14 <dooglus> Diablo-D3: it's an old wallet, with funds
  5 2011-12-20 00:03:37 <dooglus> I used to back it up regularly, but released today that I hadn't for quite a while - more than 100 transactions worth, probably
  6 2011-12-20 00:03:49 <dooglus> so wanted to increase the pool size, to avoid future disaster
  7 2011-12-20 00:04:23 <dooglus> Diablo-D3: I think you may have mis-typed there - new transactions are created whenever you make a payment...
  8 2011-12-20 00:04:55 <Diablo-D3> most people dont change the pool size on existing wallets
  9 2011-12-20 00:05:25 <Diablo-D3> and no, I didnt mistype, why fill the pool until someone makes a new transaction.
 10 2011-12-20 00:10:16 <CIA-100> libbitcoin: genjix * r69ba60bbcd27 / (configure.ac include/bitcoin/Makefile.am src/Makefile.am): --enable-berkdb -> --enable-bdb http://tinyurl.com/7dv42b4
 11 2011-12-20 00:10:17 <CIA-100> libbitcoin: genjix * r888df5197f81 / (4 files in 3 dirs): Updated postgresql_blockchain for recent changes to blockchain interface. http://tinyurl.com/77nwo83
 12 2011-12-20 00:12:31 <BlueMattBot> Yippie, build fixed!
 13 2011-12-20 00:12:32 <BlueMattBot> Project Bitcoin build #141: FIXED in 40 min: http://jenkins.bluematt.me/job/Bitcoin/141/
 14 2011-12-20 00:12:40 <BlueMatt> took long enough
 15 2011-12-20 00:12:50 <BlueMattBot> Project Bitcoind-Sanitytest build #117: FAILURE in 13 sec: http://jenkins.bluematt.me/job/Bitcoind-Sanitytest/117/
 16 2011-12-20 00:12:58 <BlueMatt> bullshit
 17 2011-12-20 00:13:19 <dooglus> Diablo-D3: because I want to have a backup before risking lost funds, not after.  If I wait until after receiving funds to back up, I risk losing the funds if the disk crashes between transaction and backup
 18 2011-12-20 00:13:56 <Diablo-D3> dooglus: ask gavin
 19 2011-12-20 00:14:09 <Diablo-D3> or maybe BlueMatt or gmaxwell knows
 20 2011-12-20 00:14:15 <BlueMatt> knows what?
 21 2011-12-20 00:14:38 <Diablo-D3> bluematt: when is the pool filled, at wallet.dat creation or at first transaction?
 22 2011-12-20 00:14:50 <Diablo-D3> dooglus: btw, if your wallet.dat already exists, it might not actually get bigger
 23 2011-12-20 00:14:58 <BlueMatt> used to be first transaction, but now its both
 24 2011-12-20 00:15:11 <BlueMatt> (someone lost coins because of it)
 25 2011-12-20 00:15:16 <Diablo-D3> dooglus: berkeleydb file size does not reflect the size of the data in it
 26 2011-12-20 00:15:24 <BlueMatt> (like a very serious quantity of coins iirc)
 27 2011-12-20 00:16:28 <Diablo-D3> blueMatt: yeah, I can see that
 28 2011-12-20 00:45:37 <BlueMatt> wumpus: ping
 29 2011-12-20 00:46:29 <wumpus> BlueMatt: pong
 30 2011-12-20 00:47:29 <BlueMatt> wumpus: have a sec? I wondered if you had any further objections to #593 and/or what your current opinion was?
 31 2011-12-20 00:47:42 <wumpus> let's see
 32 2011-12-20 01:02:04 <wumpus> yeah :/
 33 2011-12-20 01:02:44 <wumpus> why the newrecipientallowed bit in sendcoinsdialog?
 34 2011-12-20 01:03:32 <BlueMatt> so that you cant add a new recipient while the confirm dialog is open
 35 2011-12-20 01:03:53 <BlueMatt> ie click confirm, open url, url shouldnt be added
 36 2011-12-20 01:06:42 <wumpus> makes sense
 37 2011-12-20 01:06:55 <wumpus> well apart from that no comments on the code
 38 2011-12-20 01:07:18 <BlueMatt> since when does bitcoin have comments? ;)
 39 2011-12-20 01:07:30 <wumpus> hehe
 40 2011-12-20 01:07:55 <BlueMatt> I was under the impression we had some odd compiler flags set that make compile fail with comments...oh well
 41 2011-12-20 01:07:59 <wumpus> maybe we should first introduce this as an option, and not yet make it default, so people can test it
 42 2011-12-20 01:08:23 <BlueMatt> I dunno, URL support is a REALLY important feature imo
 43 2011-12-20 01:08:26 <wumpus> I'm still worried about the security implications of this
 44 2011-12-20 01:08:47 <wumpus> browsers are insecureland
 45 2011-12-20 01:09:06 <BlueMatt> yea, but everything is pretty closely checked after it gets input
 46 2011-12-20 01:09:16 <BlueMatt> gmaxwell: ping
 47 2011-12-20 01:10:53 <BlueMatt> wumpus: the thing is, bitcoin usability doubles with url support, and if its optional no one will turn it on...
 48 2011-12-20 01:11:07 <BlueMatt> wumpus: it also encourages people to set up their systems the right way
 49 2011-12-20 01:11:18 <BlueMatt> instead of idiots using signmessage and such to do accounting
 50 2011-12-20 01:14:32 <gmaxwell> BlueMatt: bloop.
 51 2011-12-20 01:14:42 <wumpus> I agree with you
 52 2011-12-20 01:14:47 <wumpus> I think it's a great thing
 53 2011-12-20 01:15:09 <BlueMatt> gmaxwell: do you feel like reading through #593 and beating on it for a bit?
 54 2011-12-20 01:15:46 <BlueMatt> wumpus: I agree that browsers are insecure land, but the thing is, with desktop financial software, we have to assume that there are other processes which are just as evil and insecure
 55 2011-12-20 01:15:50 <wumpus> but I'm sure people will try to abuse it from all angles as soon as it exists
 56 2011-12-20 01:16:01 <BlueMatt> so though I agree, and it makes attacking easier...
 57 2011-12-20 01:17:57 <BlueMattBot> Yippie, build fixed!
 58 2011-12-20 01:23:11 <wumpus> great
 59 2011-12-20 01:24:52 <BlueMatt> that is a jenkins fixed, not build fixed...
 60 2011-12-20 01:31:44 <wumpus> but your approach would be "release it, enable it by default, then see if it holds up" ? (not that I see a better alternative)
 61 2011-12-20 01:34:40 <BlueMatt> true, but thats the point of both rc times and pull requests
 62 2011-12-20 01:34:59 <BlueMatt> it gives a chance for people to read through it, make sure its safe, beat on it, and then release as alpha
 63 2011-12-20 01:37:06 <wumpus> btw:  on_sendButton_clicked copies the list of recipients to a local variable before showing the confirmation; even without fNewRecipientAllowed it does nothing to add recipients while the confirmation dialog is shown? (or do I see this wrong, it's late)
 64 2011-12-20 01:38:48 <BlueMatt> it might be, but it would still be better to not show up behind the confirm dialog imo
 65 2011-12-20 01:43:28 <wumpus> ah yes
 66 2011-12-20 01:50:29 <wumpus> btw, thanks for re-adding "start on system startup", interesting to see it doesn't depend on qt at all
 67 2011-12-20 01:55:10 <BlueMatt> heh, yea, did that because gavin was complaining that upgrading from wx to qt results in wx still autostarting at startup...
 68 2011-12-20 01:55:18 <BlueMatt> (as wx isnt removed)
 69 2011-12-20 01:55:25 <wumpus> ,
 70 2011-12-20 01:56:18 <wumpus> yeah, it solves an issue that was there for a while. I had tried to find a way to make qt programs start at window system startup, but hadn't noticed the current implementation wasn't even dependent on wx
 71 2011-12-20 01:56:44 <wumpus> (as it was in the gui cpp)
 72 2011-12-20 01:56:58 <BlueMatt> heh, yea, it would be nice if qt had a nice way to register url handling with the os, autostart, etc
 73 2011-12-20 01:57:04 <BlueMatt> but I guess that just falls out of scope...
 74 2011-12-20 01:59:23 <wumpus> yes it sort of falls out of scope of a pure ui library, though they also have networking and file access libraries, so it wouldn't be so strange
 75 2011-12-20 01:59:45 <BlueMatt> meh, whatever
 76 2011-12-20 02:00:45 <wumpus> btw I think it's nonsense to distinguish between bitcoin-qt and bitcoind in the client id, they both use the satoshi core so should be treated the same on the network
 77 2011-12-20 02:00:53 <wumpus> (re luke-jr)
 78 2011-12-20 02:01:01 <BlueMatt> I think everyone but luke thinks that...
 79 2011-12-20 02:01:28 <wumpus> heh
 80 2011-12-20 02:05:11 <gmaxwell> I think gavin managed to make him happy.
 81 2011-12-20 02:07:20 <BlueMatt> howd he do that?
 82 2011-12-20 02:10:43 <gmaxwell> changed it from bitcoin-qt to satoshi. Apparently luke was holding the position that 'bitcoin-qt' was a lie.
 83 2011-12-20 02:10:54 <BlueMatt> wtf?
 84 2011-12-20 02:11:00 <gmaxwell> And that being vague was superior to lying.
 85 2011-12-20 02:11:19 <BlueMatt> its the same damn...oh whatever
 86 2011-12-20 02:11:34 <gmaxwell> yea, my thought too. A reasonable compromise in any case.
 87 2011-12-20 02:11:53 <gmaxwell> and I think it did highlight that we ought to be using RFC 2119 words in BIPs.
 88 2011-12-20 02:11:57 <BlueMatt> yea, bitcoin-qt/satoshi same thing...
 89 2011-12-20 02:12:08 <BlueMatt> yea, definitely
 90 2011-12-20 02:15:30 <wumpus> yes satoshi is a good choice
 91 2011-12-20 02:16:58 <gmaxwell> well, I'm not keen, because it increases the satoshi mistique ever so slightly but ::shrugs::
 92 2011-12-20 02:19:17 <wumpus> nah, you're right but, mystique or not, he originally made the thing so deserves credit
 93 2011-12-20 02:20:42 <sipa> ok, c++ question; i have the following code: { map[ip] = id; printf("%i\n", map[ip]); } ... the number printed is 0 instead of id
 94 2011-12-20 02:20:50 <sipa> any reason why that can be?
 95 2011-12-20 02:22:20 <roconnor> sipa: threads
 96 2011-12-20 02:22:59 <sipa> roconnor: in that case it would be indeterminstic
 97 2011-12-20 02:23:04 <sipa> it's consistently always 0
 98 2011-12-20 02:23:16 <roconnor> is id 0
 99 2011-12-20 02:23:18 <phantomcircuit> sipa, on linux?
100 2011-12-20 02:23:33 <sipa> roconnor: no
101 2011-12-20 02:23:34 <sipa> phantomcircuit: yes
102 2011-12-20 02:23:45 <phantomcircuit> gcc initializes int to 0 always
103 2011-12-20 02:24:06 <phantomcircuit> bitcoin assumes that all over the place
104 2011-12-20 02:24:07 <sipa> ...
105 2011-12-20 02:24:11 <roconnor> what is %i  Probably some size issue
106 2011-12-20 02:24:14 <gmaxwell> ...
107 2011-12-20 02:24:24 <sipa> it's just a number put into an std::map
108 2011-12-20 02:24:28 <sipa> and it's not there afterwards
109 2011-12-20 02:24:42 <gmaxwell> phantomcircuit: for _static_, which is defined that way by the C/C++ standards.
110 2011-12-20 02:25:00 <phantomcircuit> gmaxwell, first or second line?
111 2011-12-20 02:25:04 <phantomcircuit> gcc does it for all ints
112 2011-12-20 02:25:12 <phantomcircuit> im not sure about bitcoin actually
113 2011-12-20 02:25:15 <gmaxwell> No sir it does not.
114 2011-12-20 02:25:32 <gmaxwell> I'll make you a demo, one sec.
115 2011-12-20 02:26:04 <wumpus> no, only for static ints, not those on the stack
116 2011-12-20 02:26:18 <phantomcircuit> gmaxwell, http://codepad.org/73YOlMpO
117 2011-12-20 02:26:21 <wumpus> those are not initialized at all so have some fun value
118 2011-12-20 02:26:26 <roconnor> what woudl happen if ip was negative?
119 2011-12-20 02:26:28 <gmaxwell> yea, you fail.
120 2011-12-20 02:26:57 <sipa> ok, there was a mistake in my operator<
121 2011-12-20 02:26:58 <sipa> sigh
122 2011-12-20 02:27:01 <wumpus> sipa: weird; what happens if you assign the result of map[ip] to a temporary int and print that?
123 2011-12-20 02:27:12 <wumpus> uh ok so your map was broken
124 2011-12-20 02:27:13 <wumpus> :P
125 2011-12-20 02:27:18 <sipa> no, my ip was :)
126 2011-12-20 02:28:43 <phantomcircuit> gmaxwell, lol i rigged it codepad specifically initializes to 0
127 2011-12-20 02:29:00 <phantomcircuit> gmaxwell, however dynamically allocated ints are always initialized to 0 by gcc
128 2011-12-20 02:29:04 <phantomcircuit> which is what was happening
129 2011-12-20 02:29:11 <gmaxwell> No, they really aren't.
130 2011-12-20 02:29:25 <phantomcircuit> try it
131 2011-12-20 02:30:11 <phantomcircuit> maybe it's just random chance
132 2011-12-20 02:30:43 <gmaxwell> Yes, its just random chance and that the stack is normally prefilled with zeros.
133 2011-12-20 02:31:17 <phantomcircuit> hmm
134 2011-12-20 02:31:23 <sipa> std::deque::size() returns -1
135 2011-12-20 02:31:25 <sipa> is that normal?
136 2011-12-20 02:31:26 <phantomcircuit> heap allocation
137 2011-12-20 02:31:48 <phantomcircuit> sipa, no
138 2011-12-20 02:31:53 <gmaxwell> phantomcircuit: the heap is also undefined when you use it, except if you use calloc. malloc recycles free memory.
139 2011-12-20 02:33:19 <gmaxwell> phantomcircuit: http://pastebin.mozilla.org/1413205
140 2011-12-20 02:33:38 <phantomcircuit> oh
141 2011-12-20 02:33:39 <phantomcircuit> sorry
142 2011-12-20 02:33:44 <gmaxwell> (higher optimization levels remove the behavior in _this_ case because the compiler constifies everything)
143 2011-12-20 02:33:44 <phantomcircuit> i meant when you call new
144 2011-12-20 02:34:08 <phantomcircuit> new int() seems to always return a pointer to a 0 int
145 2011-12-20 02:34:10 <gmaxwell> New depends on the constructor of the object. I dunno what C++ does there for int.
146 2011-12-20 02:34:16 <phantomcircuit> probably version specific
147 2011-12-20 02:34:16 <wumpus> calling new doesn't initialize the memory to zeros either does it ?
148 2011-12-20 02:34:29 <gmaxwell> That may be defined that way or not. I'm not c++ clueful, alas.
149 2011-12-20 02:34:31 <wumpus> ints are not initialized by c++ automatically in structs/objects
150 2011-12-20 02:34:44 <phantomcircuit> gmaxwell, i obviously wouldn't count on it, but it seems to always return 0
151 2011-12-20 02:34:57 <wumpus> depends on the compiler, don't rely on it
152 2011-12-20 02:35:24 <sipa> wumpus: you know that? std::deque::size() returns -1
153 2011-12-20 02:35:30 <wumpus> if anything, it's generally better to be explicit
154 2011-12-20 02:35:31 <sipa> is that possible?
155 2011-12-20 02:35:35 <wumpus> sipa: nope :o
156 2011-12-20 02:36:10 <gmaxwell> phantomcircuit: if it actually is undefined like the stack ones are then the compiler can do awesome optimizations on code that depends on it.. like removing the code entirely.
157 2011-12-20 02:36:41 <gmaxwell> phantomcircuit: anyways, what bitcoin depends on is that statics are initilized... and thats true and required by the standard.
158 2011-12-20 02:38:08 <phantomcircuit> gmaxwell, well my version of gcc atleast is always returning 0 for new int()
159 2011-12-20 02:38:10 <phantomcircuit> who knows
160 2011-12-20 02:38:22 <wumpus> phantomcircuit: http://stackoverflow.com/questions/7546620/operator-new-initializes-memory-to-zero
161 2011-12-20 02:38:33 <wumpus> new int() always returns 0, new int doesn't
162 2011-12-20 02:38:47 <wumpus> because the () acts as initialization expression for the int
163 2011-12-20 02:38:48 <BlueMatt> am I allowed to tell people off for constantly +1ing #415? ie can we agree that github is NOT the place to post comments that contain only "+1"
164 2011-12-20 02:39:08 <gmaxwell> phantomcircuit: see the stack example I gave you.. it would be really easy to _think_ it did, but it doesn't really.
165 2011-12-20 02:39:43 <phantomcircuit> gmaxwell, yeah i never assume things are initialized
166 2011-12-20 02:40:29 <phantomcircuit> sipa, btw std::map::operator[] will call the default constructor for T when you access an element that does not yet exist
167 2011-12-20 02:40:37 <phantomcircuit> it's pretty annoying actually
168 2011-12-20 02:40:38 <sipa> phantomcircuit: i know that
169 2011-12-20 02:41:10 <wumpus> BlueMatt: thanks for letting me know about that pull request at all, didn't even know it had a qt gui now
170 2011-12-20 02:41:17 <luke-jr> wumpus: client id is not FOR the network, it's for HUMANS
171 2011-12-20 02:41:25 <BlueMatt> wumpus: which one?
172 2011-12-20 02:41:32 <wumpus> 415
173 2011-12-20 02:41:37 <BlueMatt> ah
174 2011-12-20 02:41:39 <AAA_awright> BlueMatt: https://github.com/bitcoin/bitcoin/pull/415 ?
175 2011-12-20 02:41:45 <BlueMatt> AAA_awright: yea
176 2011-12-20 02:42:52 <wumpus> luke-jr: humans shouldn't care either whether you're running the UI or a daemon
177 2011-12-20 02:43:56 <luke-jr> wumpus: it's for statistics. like saying X% runs Bitcoin-Qt, X% runs bitcoind, X% runs Spesmilo, etc
178 2011-12-20 02:43:58 <wumpus> I'd argue for revealing as little about the software you're running as possible, except what's needed for protocol versioning
179 2011-12-20 02:44:06 <luke-jr> wumpus: in any case, bitcoind claiming to be bitcoin-qt is just wrong
180 2011-12-20 02:44:13 <luke-jr> fine, then leave it null :p
181 2011-12-20 02:44:25 <wumpus> yes I agree with that, but both returning "satoshi" is fine
182 2011-12-20 02:44:47 <luke-jr> yes, that's what my patch did (mainly)
183 2011-12-20 02:44:53 <luke-jr> but Gavin refuses to merge it
184 2011-12-20 02:45:18 <luke-jr> (it also allows me to -D PUBLIC_CLIENT_NAME or such to get the full version)
185 2011-12-20 02:46:12 <BlueMatt> can I get some agreement that github is NOT the place to post a +1?
186 2011-12-20 02:47:26 <luke-jr> BlueMatt: GitHub posts should at the minimum contribute a "someone gave me a binary to test this with, and it worked for me" IMO
187 2011-12-20 02:47:46 <BlueMatt> agreed
188 2011-12-20 02:48:17 <BlueMatt> anyone have any complaints to https://github.com/bitcoin/bitcoin/pull/415#issuecomment-3214053 ?
189 2011-12-20 02:49:01 <luke-jr> well, some things don't require 10 minutes to test IMO, but it gets the point across either way
190 2011-12-20 02:49:14 <BlueMatt> meh, close enough
191 2011-12-20 02:50:37 <BlueMatt> awww, I was only #4/91 in my compsci class...damn
192 2011-12-20 02:50:47 <BlueMatt> oh well, guess I should have gone to class
193 2011-12-20 02:51:01 <upb> yeah, remember that you are studying for your own good
194 2011-12-20 02:51:24 <upb> i forgot that too many times when in uni )
195 2011-12-20 02:53:07 <BlueMatt> anyone else have problems with gnome refusing to switch focus between windows until you logout/in?
196 2011-12-20 02:53:30 <phantomcircuit> no
197 2011-12-20 02:54:39 <phantomcircuit> ha
198 2011-12-20 02:54:43 <phantomcircuit> you're using gnome 3?
199 2011-12-20 02:54:45 <phantomcircuit> fool
200 2011-12-20 02:54:47 <BlueMatt> no, gnome2
201 2011-12-20 02:54:48 <phantomcircuit> :X
202 2011-12-20 02:54:53 <BlueMatt> Im on 11.04
203 2011-12-20 02:54:55 <phantomcircuit> unity?
204 2011-12-20 02:54:56 <phantomcircuit> ah
205 2011-12-20 02:54:57 <BlueMatt> no
206 2011-12-20 02:55:00 <phantomcircuit> not a fool
207 2011-12-20 02:55:01 <phantomcircuit> :)
208 2011-12-20 02:55:04 <BlueMatt> refused to upgrade to unity
209 2011-12-20 02:55:38 <BlueMatt> anyone use mint debian?
210 2011-12-20 02:58:15 <luke-jr> GNOME sucks
211 2011-12-20 02:59:49 <rjk2> isnt Mint like simplified ubuntu
212 2011-12-20 02:59:56 <rjk2> in other words fail
213 2011-12-20 03:00:06 <BlueMatt> luke-jr: you are on gentoo with which kde version?
214 2011-12-20 03:00:27 <luke-jr> 4.7
215 2011-12-20 03:00:35 <luke-jr> rjk2: Mint is Ubuntu with proprietary crap by default
216 2011-12-20 03:00:39 <BlueMatt> rjk2: mint debian is based on debian-testing so rolling release, which is why Im looking at it
217 2011-12-20 03:00:46 <BlueMatt> so not ubuntu-based
218 2011-12-20 03:21:32 <sipa> bitcoin seeder v0.1 is up and running at seedtest.bitcoin.sipa.be
219 2011-12-20 03:21:48 <BlueMatt> sipa: what desktop do you run again?
220 2011-12-20 03:22:02 <BlueMatt> sipa: also, nice!
221 2011-12-20 03:22:06 <BlueMatt> is the code up anywhere?
222 2011-12-20 03:22:29 <sipa> bitcoin-seeder repo in github
223 2011-12-20 03:22:36 <sipa> BlueMatt: none, for the moment
224 2011-12-20 03:23:07 <sipa> it's currently crawling with 100 threads simultaneously
225 2011-12-20 03:23:08 <BlueMatt> meant gnome/kde/xfce/etc
226 2011-12-20 03:23:13 <sipa> xmonad
227 2011-12-20 03:23:17 <sipa> -> 2% cpu on my vps
228 2011-12-20 03:23:25 <BlueMatt> nice
229 2011-12-20 03:24:21 <BlueMatt> (to both a new desktop environment and sipa's new dnsseed)
230 2011-12-20 03:24:46 <midnightmagic> sipa: what's the purpose of bitcoin-seeder?
231 2011-12-20 03:25:10 <sipa> midnightmagic: specialized DNS server that crawls the network, and returns a random set of good nodes at each invocation
232 2011-12-20 03:26:28 <rjk2> sort of a weighted round robin?
233 2011-12-20 03:27:04 <sipa> not weighted
234 2011-12-20 03:27:09 <sipa> and not round
235 2011-12-20 03:27:40 <nanotube> and it's not a bird either
236 2011-12-20 03:28:54 <jgarzik> sipa: source code anywhere that I may browse?
237 2011-12-20 03:29:00 <midnightmagic> https://github.com/sipa/bitcoin-seeder.git
238 2011-12-20 03:31:11 <sipa> jgarzik: sure, and feel free to comment
239 2011-12-20 03:31:28 <sipa> (except "needs moar comments!!!111")
240 2011-12-20 03:31:31 <rjk2> could you add weight to nodes that have good uptime and connectivity?
241 2011-12-20 03:31:46 <rjk2> or do you insist on it being random
242 2011-12-20 03:31:47 <sipa> rjk2: no, i only report nodes that have good uptime and commectivity
243 2011-12-20 03:31:53 <rjk2> ok :)
244 2011-12-20 03:33:59 <midnightmagic> looks like nodes can get banned for all kinds of infarctions sipa
245 2011-12-20 03:34:22 <BlueMatt> midnightmagic: as they should
246 2011-12-20 03:34:43 <sipa> midnightmagic: yes, intentionally
247 2011-12-20 03:34:47 <midnightmagic> i make no judgements, i'm just adding to sipa's comment above re: uptime and connectivity
248 2011-12-20 03:34:55 <midnightmagic> yes, clearly it's on purpose.
249 2011-12-20 03:35:07 <sipa> if a node reports a bad version, i don't want to retry connecting to it for a month ;)
250 2011-12-20 03:35:14 <midnightmagic> in other words, I'm filling in some additional information for people who aren't reading the code right now.
251 2011-12-20 03:35:15 <sipa> chances are small it will upgrade
252 2011-12-20 03:35:22 <BlueMatt> heh, no sipa is just such a bad yet talented coder that he wrote in a ton of checks without intending them...
253 2011-12-20 03:35:55 <rjk2> lol
254 2011-12-20 03:36:01 <Diablo-D3> uh
255 2011-12-20 03:36:11 <midnightmagic> whoah, there are a lot of people who are stuck on older versions and/or are choosing to stay on the versions that satoshi last touched..
256 2011-12-20 03:36:32 <midnightmagic> MIN_VERSION is your seeder is 40000
257 2011-12-20 03:36:48 <midnightmagic> what version does that correspond to?
258 2011-12-20 03:36:53 <BlueMatt> 0.4
259 2011-12-20 03:36:53 <Diablo-D3> midnightmagic: yes and we have a right to bannindate them
260 2011-12-20 03:37:07 <midnightmagic> Diablo-D3: And your reason is?
261 2011-12-20 03:37:49 <gmaxwell> midnightmagic: nodes with the pre-.24 anti-flooding logic are terrible peers for new nodes, since they'll randomly hang up while feeding the chain.
262 2011-12-20 03:38:07 <Diablo-D3> midnightmagic: we need a reason?
263 2011-12-20 03:38:14 <midnightmagic> gmaxwell: so?
264 2011-12-20 03:38:43 <gmaxwell> midnightmagic: they slow down initial syncup for new nodes.
265 2011-12-20 03:38:44 <midnightmagic> Diablo-D3: If you are capricious and without reason, then you are the reason to trust the network less.
266 2011-12-20 03:38:49 <midnightmagic> gmaxwell: That's it?
267 2011-12-20 03:38:54 <BlueMatt> gmaxwell: its actually >0.3.20 && < 0.3.23 iirc
268 2011-12-20 03:39:09 <gmaxwell> <=.23 no?
269 2011-12-20 03:39:16 <gmaxwell> .24 was basically that fix.
270 2011-12-20 03:39:26 <BlueMatt> oh, yea <=.23
271 2011-12-20 03:39:32 <Diablo-D3> midnightmagic: no, you asked whats my reason on saying we have a right to ban nodes
272 2011-12-20 03:39:33 <gmaxwell> midnightmagic: not slightly, but enormously.
273 2011-12-20 03:39:38 <Diablo-D3> midnightmagic: thats a nonsensical question
274 2011-12-20 03:39:43 <gmaxwell> midnightmagic: ignore Diablo-D3's he's a troll.
275 2011-12-20 03:39:56 <Diablo-D3> gmaxwell: I am not, and I was here long before you.
276 2011-12-20 03:40:08 <cjdelisle> heh you have the right to ban nodes and they have the right to lie about their version, it's like a 1 line patch :P
277 2011-12-20 03:40:25 <BlueMatt> s/would be a better place/would seem like a better place
278 2011-12-20 03:40:28 <BlueMatt> /
279 2011-12-20 03:40:32 <Diablo-D3> bah
280 2011-12-20 03:40:41 <midnightmagic> Diablo-D3: Your english words imply that there is a reason, not just that you have a capricious right to ban random people. However, if you are saying you have no reason, then that is answer enough.
281 2011-12-20 03:41:10 <Diablo-D3> midnightmagic: my words imply there might be a reason, yes
282 2011-12-20 03:41:25 <Diablo-D3> that doesnt mean I had a reason in mind when I said it, but, usually, yes, people have reasons
283 2011-12-20 03:41:31 <Diablo-D3> not everyone is awesome, sadly.
284 2011-12-20 03:41:34 <midnightmagic> gmaxwell: I'm familiar with D3. :) I guess I haven't been talking enough in here to keep his mind fresh as to who I am. :)
285 2011-12-20 03:41:58 <Diablo-D3> no, I remember you
286 2011-12-20 03:42:01 <Diablo-D3> I think gmaxwell forgot you
287 2011-12-20 03:42:10 <gmaxwell> midnightmagic: it's also the case that there are some mild security weaknesses in sufficiently old nodes that might adversely impact the perception of bitcoin. E.g. the showing/fowarding txn that multispend the same input.
288 2011-12-20 03:42:29 <gmaxwell> ... I have not, hell, I'm the one always telling people where the missing bitcoin went.
289 2011-12-20 03:42:47 <Diablo-D3> btw
290 2011-12-20 03:42:58 <Diablo-D3> why arent we just routinely banning nodes that are older than, say, 1 year?
291 2011-12-20 03:43:00 <midnightmagic> Diablo-D3: :-P
292 2011-12-20 03:43:11 <Diablo-D3> just to force consistent upgrade behavior
293 2011-12-20 03:43:14 <gmaxwell> Diablo-D3: because there simply is no reason to.
294 2011-12-20 03:43:21 <gmaxwell> upgrades aren't a good thing, really, except when they are.
295 2011-12-20 03:43:23 <Diablo-D3> gmaxwell: even if it impacts the security?
296 2011-12-20 03:43:44 <gmaxwell> if people upgraded like sheep at every version ... it would make bitcoin a centeralized system effectively.
297 2011-12-20 03:43:57 <gmaxwell> Diablo-D3: nothing has been bad enough to cause gavin to send an alert...
298 2011-12-20 03:44:01 <midnightmagic> gmaxwell: You're talking about wallet encryption too, right? So here's the issue. merged-mining patches from vince currently don't cleanly apply to #head bitcoin. There are some of us who are stuck on the older version without doing some significant effort to seamlessly merge those patches.
299 2011-12-20 03:44:32 <gmaxwell> then nag vince.
300 2011-12-20 03:44:37 <midnightmagic> and vince appears to have gone silent.
301 2011-12-20 03:44:43 <gmaxwell> goodbye namecoin
302 2011-12-20 03:44:48 <midnightmagic> codewise at least.
303 2011-12-20 03:44:52 <rjk2> sucks
304 2011-12-20 03:45:17 <Diablo-D3> heh
305 2011-12-20 03:46:58 <midnightmagic> Ah, looks like he posted two notes on Dec 16 in the namecoin forum. One-liners.
306 2011-12-20 03:48:32 <midnightmagic> http://dot-bit.org/forum/viewtopic.php?p=2387#p2387
307 2011-12-20 03:49:04 <midnightmagic> so, nevermind. My information was a few days old..
308 2011-12-20 03:49:29 <luke-jr> http://paste.pocoo.org/show/523374/
309 2011-12-20 03:51:25 <midnightmagic> i guess i'll just have to fake my reported version then.
310 2011-12-20 03:52:05 <gmaxwell> midnightmagic: ... because what?
311 2011-12-20 03:52:22 <midnightmagic> otherwise i get punished by bitcoin-seeder
312 2011-12-20 03:52:38 <gmaxwell> midnightmagic: ... What version are you?
313 2011-12-20 03:52:53 <jrmithdobbs> you really need to upgrade to .3.24
314 2011-12-20 03:52:56 <jrmithdobbs> seriously
315 2011-12-20 03:53:10 <midnightmagic> .. hrm..   looks like an early 0.3.24 version.
316 2011-12-20 03:53:31 <luke-jr> &
317 2011-12-20 03:53:38 <midnightmagic> jrmithdobbs: this is the part where you explain why
318 2011-12-20 03:53:39 <gmaxwell> As far as being 'punished'. It doesn't matter if you're listed in the seeder or not.
319 2011-12-20 03:53:40 <luke-jr> he needs to upgrade to 0.4.2 :P
320 2011-12-20 03:54:01 <gmaxwell> And I'm super confused there because 0.4 was out long before the merged mining patches.
321 2011-12-20 03:54:04 <luke-jr> midnightmagic: 0.3.x is unmaintained, and have some issues
322 2011-12-20 03:54:14 <jrmithdobbs> gmaxwell: ya seriously
323 2011-12-20 03:54:34 <midnightmagic> nothing's in it right now, it's just a blank miner that forwards on coins automatically to some other places.
324 2011-12-20 03:54:51 <luke-jr> midnightmagic: vince's MM stuff is lame anyhow
325 2011-12-20 03:55:29 <midnightmagic> luke-jr: the ones explained above right?  the flood-control hangups, no wallet encryption, and forwarding double-output txn right?
326 2011-12-20 03:55:50 <jrmithdobbs> the first and last are fairly important
327 2011-12-20 03:56:55 <luke-jr> midnightmagic: use my MM stuff :P
328 2011-12-20 03:57:14 <jrmithdobbs> but if you're just one of "those guys" that'll attach an unpatched xp box to the internet for max masochism
329 2011-12-20 03:57:17 <jrmithdobbs> go right ahead
330 2011-12-20 03:57:46 <midnightmagic> luke-jr: lol I made an effort to merge in your stuff the other day but I couldn't track down the specific branches and patches to do it. But I've already asked you about it twice, so I didn't want to bug you a third time. Because that would suggest I'm extra-lazy. ha ha.. really it's just a time thing, honest.
331 2011-12-20 03:58:12 <gmaxwell> midnightmagic: perhaps you shouldn't be running a mining node then, if you can't bother to maintain your software.
332 2011-12-20 03:58:16 <luke-jr> I must have missed it :P
333 2011-12-20 03:58:25 <gmaxwell> I've heard there are some people who run zero fee pools.
334 2011-12-20 03:58:35 <midnightmagic> jrmithdobbs: yeah..  good analogy. "own my entire home network" vs. "might forward on scary-looking txn that hurt perception, and hang-up on newbs."
335 2011-12-20 03:59:02 <gmaxwell> (zero fee pools.. with merged mining in fact...)
336 2011-12-20 03:59:10 <midnightmagic> gmaxwell: I have been watching very carefully all the issues I can as they come out. So far, I see no security implications for myself nor my miners.
337 2011-12-20 03:59:19 <jrmithdobbs> midnightmagic: for now. i'm pretty sure the flooding issue could probably be exploited by someone bored enough to cause your node to dos itself
338 2011-12-20 03:59:48 <jrmithdobbs> midnightmagic: there's also a few other dos related issues that have been improved greatly just due to code cleanup
339 2011-12-20 04:00:16 <midnightmagic> yes, I'ma ware of them. pools that then have my IP connected to payouts, pools that can be dos'd which my miners then have to failover around, pools that then punish me for failing away from them and back because they went down due to dos.
340 2011-12-20 04:00:45 <jrmithdobbs> what
341 2011-12-20 04:02:02 <midnightmagic> meanwhile I get screwed by latency, have to QoS my huge mining traffic, and etc ad nauseum. i have enough hashrate to solo, and will for the foreseeable future. pool mining is contrary to the nature of the currency.
342 2011-12-20 04:02:13 <luke-jr> midnightmagic: Eligius doesn't punish at least :P
343 2011-12-20 04:02:46 <gmaxwell> midnightmagic: it's pretty sad when I'm suggesting that pools are _superior_ to solo because you don't give a shit about keeping your software up to date.
344 2011-12-20 04:02:47 <midnightmagic> luke-jr: Yes, I liked eligius when I had some test hashrate on it. :) what took me away was more hashrate came online, and merged-mining came along.
345 2011-12-20 04:03:06 <jgarzik> sipa: I'm vaguely tempted to see it in the tree, as a way to spur evolution of libbitcoin
346 2011-12-20 04:03:07 <luke-jr> midnightmagic: Eligius does merged-mining too :p
347 2011-12-20 04:03:32 <luke-jr> jgarzik: you're aware there is already an independent C++ implementation named libbitcoin?
348 2011-12-20 04:03:34 <midnightmagic> gmaxwell: You are making a huge unfounded assumption there.
349 2011-12-20 04:03:41 <gmaxwell> I moved back off solo mining to eligius due to merged mining. The vinced patches/shimdaemon sucked, and I see I made the right decision. :)
350 2011-12-20 04:03:44 <jgarzik> luke-jr: yes.  don't like it.
351 2011-12-20 04:03:59 <jgarzik> luke-jr: I prefer a natural evolution from Satoshi codebase to a libbitcoin
352 2011-12-20 04:04:08 <luke-jr> jgarzik: haven't look at it myself, but name conflicts are annoying :p
353 2011-12-20 04:04:18 <jgarzik> luke-jr: libsatoshi :)
354 2011-12-20 04:04:28 <luke-jr> hah
355 2011-12-20 04:04:28 <midnightmagic> gmaxwell: lol ooookay. been drinking tonight or something? usually you're not this vehement over what appears to be a non-technical reason.
356 2011-12-20 04:05:14 <_W_> the client and daemon crashes on windows when the %appdata%/Bitcoin directory is a symlink (or whatever it's called on windows) that points to somewhere that no longer exist
357 2011-12-20 04:05:23 <gmaxwell> midnightmagic: hm? sorry, I'm perhaps coming off more intense then I actually am. But really, you ought to be in the habbit of upgrading your software or you're going retard the growth and health of bitcoin.
358 2011-12-20 04:05:25 <jrmithdobbs> midnightmagic: it is a technical reason
359 2011-12-20 04:05:44 <sipa> jgarzik: "see it in the tree" ?
360 2011-12-20 04:05:49 <jrmithdobbs> it's the same reason you should patch any other software
361 2011-12-20 04:05:52 <midnightmagic> jrmithdobbs: Please do enlighten me. Do you have specifics other than what's been mentioned?
362 2011-12-20 04:05:56 <gmaxwell> midnightmagic: right now every block you mine is a vote against OP_EVAL for example, which I hope and doubt you oppose... but unless you feel like getting off your butt and applying the patch...
363 2011-12-20 04:06:54 <midnightmagic> I do not oppose it.
364 2011-12-20 04:07:11 <luke-jr> gmaxwell: speaking of which, did we decide OP_EVAL2 was practical, or do I still want to delay OP_EVAL for key recovery?
365 2011-12-20 04:07:19 <luke-jr> midnightmagic: an unpatched miner by default opposes it.
366 2011-12-20 04:07:22 <gmaxwell> luke-jr: it's pratical I think.
367 2011-12-20 04:07:30 <midnightmagic> I am not my miner.
368 2011-12-20 04:08:11 <midnightmagic> Doesn't tycho still run 0.3.x?
369 2011-12-20 04:08:29 <luke-jr> midnightmagic: Eligius runs a heavily patched 0.3.23 ;)
370 2011-12-20 04:08:31 <midnightmagic> I thought someone was still going on about refusing to leave satoshi's version due to the issues that kept cropping up with the new code..
371 2011-12-20 04:08:56 <luke-jr> midnightmagic: that's (one reason why) I'm maintaining 0.4.x
372 2011-12-20 04:09:04 <gmaxwell> midnightmagic: tycho is active here, and will backport stuff to whatever the heck he's running.
373 2011-12-20 04:09:31 <gmaxwell> midnightmagic: I don't really care what version you run, so long as you apply the relevant fixes.
374 2011-12-20 04:09:45 <gmaxwell> usually the easiest way to do that is to simply run recent versions.
375 2011-12-20 04:10:12 <gmaxwell> If there are bugs and/or feature gaps in the recent versions then you should keep on the pressure (and support) to get them fixed.
376 2011-12-20 04:10:29 <jgarzik> sipa: in bitcoin/bitcoin.git/contrib
377 2011-12-20 04:10:57 <jgarzik> sipa: thus encouraging (a) intra-tree code sharing, and (b) people running the dns seed
378 2011-12-20 04:11:52 <gmaxwell> hm. if we're going to encourage more people to run seeds, perhaps -dnsseed should take arguments...
379 2011-12-20 04:14:24 <BlueMatt> jgarzik: Ive always kinda disagreed with the idea of putting a dnsseed server in bitcoin/bitcoin, it just means updates to it take longer
380 2011-12-20 04:14:36 <BlueMatt> and/or encourages the bitcoin/bitcoin version to be outdated
381 2011-12-20 04:15:00 <BlueMatt> if its a highly-related project ok, but not if its a separate project like a dnsseed server
382 2011-12-20 04:15:25 <gmaxwell> hm. it would actually be kinda neat to just have bitcoind itself run one except for the pesky trouble of binding to port 53.
383 2011-12-20 04:16:17 <BlueMatt> and the idea of running a dnsseed on a full node codebase...
384 2011-12-20 04:16:52 <gmaxwell> well. .. along with that addr rumoring logic needs to be fixed, as a prereq there in any case.
385 2011-12-20 04:17:05 <BlueMatt> that needs to happen anyway
386 2011-12-20 04:17:24 <luke-jr> &
387 2011-12-20 04:17:31 <luke-jr> Bitcoin's p2p protocol already functions as a seed
388 2011-12-20 04:17:36 <luke-jr> no need for DNS everywhere
389 2011-12-20 04:17:36 <midnightmagic> gmaxwell: I think maybe you have the wrong idea. I do watch every issue that is reported. I watch most of the conversation about it. So far I don't really see a pressing broken-ness of the older code.. and I still mine on top of the OP_EVAL.. so..
390 2011-12-20 04:17:56 <luke-jr> .. actually, this DNS seed thing IS kindof silly if we're running custom sw for it :/
391 2011-12-20 04:18:09 <gmaxwell> midnightmagic: but you'll also mine an invalid op_eval and get yourself split, once op_eval is enforced.
392 2011-12-20 04:18:34 <midnightmagic> is op_eval enforced?
393 2011-12-20 04:19:14 <gmaxwell> luke-jr: it's not the custom software gets around the current lack of node sanity checks, can run on VPSs with little memory, and the DNS requests are superior to normal rumoring because you don't need to establish a (resource hungry) connection so you can serve a lot more users with fewer resources.
394 2011-12-20 04:19:16 <midnightmagic> and if a split is coming, are we going to fix the god-damned 2016th block timewarp bug?
395 2011-12-20 04:19:44 <gmaxwell> midnightmagic: it will be enforced, as of feb 1st in the current patches, but it won't cause a hard split.
396 2011-12-20 04:20:04 <midnightmagic> what does that mean?
397 2011-12-20 04:20:05 <gmaxwell> It'll just cause miners that mine or extend blocks with invalid op_eval to get orphaned.
398 2011-12-20 04:20:23 <jrmithdobbs> luke-jr: having to run a full node just to aggregate a seed list would be a retarded waste of resources
399 2011-12-20 04:20:25 <midnightmagic> but aren't I ignoring op_eval? or am I mining it in?
400 2011-12-20 04:20:28 <gmaxwell> if you don't mine non-standard txn you'll be fine unless someone else does and you extend theirs.
401 2011-12-20 04:20:49 <gmaxwell> midnightmagic: you're ignoring it. And you ignore it if its valid or not.
402 2011-12-20 04:21:08 <midnightmagic> so I'm not mining invalid op_eval anyway.
403 2011-12-20 04:21:11 <gmaxwell> (hopefully, unless you're patched to mine non-standard txn, in which case you may include it too)
404 2011-12-20 04:21:29 <gmaxwell> midnightmagic: but you'll extend someone elses block that mined an invalid op_eval.
405 2011-12-20 04:21:40 <midnightmagic> if it's relayed to me.
406 2011-12-20 04:21:43 <gmaxwell> yes.
407 2011-12-20 04:22:09 <midnightmagic> hrm.
408 2011-12-20 04:22:16 <gmaxwell> and you'll relay them to others.
409 2011-12-20 04:22:23 <jgarzik> I still think a DNS seed could be much, much more simple
410 2011-12-20 04:22:27 <midnightmagic> well that's feb 1 then, if it happens at all.
411 2011-12-20 04:22:35 <jgarzik> just create a "getaddresses" RPC, which returns a random list
412 2011-12-20 04:22:42 <jgarzik> from bitcoind's address db
413 2011-12-20 04:22:52 <BlueMatt> jgarzik: first bitcoins address db would have to be sane
414 2011-12-20 04:22:53 <jgarzik> populate tinydns/BIND
415 2011-12-20 04:22:57 <gmaxwell> jgarzik: that would be pretty much intolerable crap.
416 2011-12-20 04:22:58 <BlueMatt> but yea, it could be
417 2011-12-20 04:23:16 <gmaxwell> most of the addresses returned on long running nodes will be non-working.
418 2011-12-20 04:23:16 <jrmithdobbs> jgarzik: then you still have to run a full node
419 2011-12-20 04:23:34 <jrmithdobbs> jgarzik: at whiche point you might as well just db_dump addr.dat every 5 minutes
420 2011-12-20 04:24:31 <jgarzik> no, the address db merely needs the well-discussed pruning that should occur anyway
421 2011-12-20 04:24:50 <jgarzik> auto-
422 2011-12-20 04:24:59 <gmaxwell> my addr.dat is .. something like 13 megabytes.. there are only 5k listening nodes.
423 2011-12-20 04:25:10 <jgarzik> handy DNS seed list is a useful side effect of non-stupid address db maint
424 2011-12-20 04:25:13 <gmaxwell> oh okay, assuming thats all fixed then sure.
425 2011-12-20 04:25:14 <sipa> still, my dnsseed actively tries to monitor each good node it knows about
426 2011-12-20 04:25:19 <sipa> a full node doesn't need to do that
427 2011-12-20 04:25:25 <jrmithdobbs> gmaxwell: would accomplish the same thing as doing it through the rpc is what i'm saying
428 2011-12-20 04:25:35 <jrmithdobbs> gmaxwell: neither are a good idea imho
429 2011-12-20 04:25:39 <jrmithdobbs> (was the point)
430 2011-12-20 04:25:41 <gmaxwell> I think it's okay. Diversity is good.
431 2011-12-20 04:25:46 <gmaxwell> We should have both kinds of seeds.
432 2011-12-20 04:26:01 <jgarzik> yep
433 2011-12-20 04:28:28 <midnightmagic> hey looks like a hashrate vote is being taken for op_eval anyway.
434 2011-12-20 04:28:43 <midnightmagic> that's what you were talking about..
435 2011-12-20 04:29:16 <jrmithdobbs> jgarzik: anyways, pruning makes it better but still requires running a full node. that's a lot of ram for a measely dns server
436 2011-12-20 04:29:29 <gmaxwell> midnightmagic: kinda, there is no algorithimic enforcement of it.. the code as written will take effect feb 1st. But the vote is there, so that if its failing to get a majority the date can be postponed.
437 2011-12-20 04:29:42 <sipa> jrmithdobbs: my seed uses 7MB of memory now
438 2011-12-20 04:29:56 <jrmithdobbs> sipa: awesome
439 2011-12-20 04:29:57 <gmaxwell> midnightmagic: because we can have >>50% with just three pools which can be manually coordinated, thats adequate.
440 2011-12-20 04:29:57 <helo> gmaxwell: any idea what the current vote is?
441 2011-12-20 04:30:15 <jrmithdobbs> sipa: now that's dns server friendly ;p
442 2011-12-20 04:30:53 <midnightmagic> so..  the votes of the rest of the network are irrelevant. so in essence, 3 people (plus devs) get to decide the future of the network.
443 2011-12-20 04:31:10 <jrmithdobbs> welcome to the consequences of pools
444 2011-12-20 04:31:10 <midnightmagic> are the pools taking a vote of their own users?
445 2011-12-20 04:31:29 <gmaxwell> midnightmagic: thats a fault of the community, unfortunately.
446 2011-12-20 04:31:59 <midnightmagic> so, that's a demonstration of power concentration.
447 2011-12-20 04:32:03 <phantomcircuit> sipa, seed?
448 2011-12-20 04:32:09 <gmaxwell> the right criteria for activation is >>50% and two/three pools are necessary and sufficient. :(
449 2011-12-20 04:32:10 <midnightmagic> and you're worried about how weird txn look in debug.log to new users?
450 2011-12-20 04:32:15 <jrmithdobbs> phantomcircuit: https://github.com/sipa/bitcoin-seeder
451 2011-12-20 04:32:23 <gmaxwell> midnightmagic: er.. in debug.log, hardly.
452 2011-12-20 04:32:25 <jrmithdobbs> phantomcircuit: good stuff
453 2011-12-20 04:32:33 <sipa> phantomcircuit: integrate network crawler + dns server
454 2011-12-20 04:32:44 <sipa> *integrated
455 2011-12-20 04:32:45 <phantomcircuit> sipa, ah
456 2011-12-20 04:32:50 <gmaxwell> midnightmagic: the double input have been used txn have been used to rob people. (well, fools who accept 0-confirm, but still)
457 2011-12-20 04:33:22 <jrmithdobbs> sipa: there a reason you decided to actually implement dns instead of dump to a couple well known zone formats?
458 2011-12-20 04:33:26 <midnightmagic> gmaxwell: If you're talking about mybitcoin, that looked way more like they just ran off with it, to me.
459 2011-12-20 04:33:40 <sipa> jrmithdobbs: because i want to return a different result for each query
460 2011-12-20 04:34:11 <gmaxwell> nah, I've seen the transactions on the network too. They were even showing up on bitcoin charts until it was upgraded.. so you could even convince people that the 0-confirm txn was well propagated. :(
461 2011-12-20 04:34:11 <jrmithdobbs> sipa: you can do that trivially with any modern dns server
462 2011-12-20 04:34:45 <gmaxwell> jrmithdobbs: start your patching.
463 2011-12-20 04:35:00 <jrmithdobbs> ya i might play with it
464 2011-12-20 04:35:15 <jrmithdobbs> gmaxwell: already looking at it
465 2011-12-20 04:35:27 <midnightmagic> ... and effective Tycho + someone else deciding to go ahead with op_eval isn't.. a little more worrisome than 0-confirm txn looking weird to newbs?
466 2011-12-20 04:36:25 <gmaxwell> midnightmagic: come on, those are _both_ issues, one doesn't diminish the other. And "not looking weird" but "being useful to rob people"
467 2011-12-20 04:36:56 <midnightmagic> gmaxwell: I see tycho+1 guy deciding a change in the network as a farce of a vote. That sort of thing worries me. 0-confirm txn doesn't bother me. And it shouldn't bother you either unless you've specifically seen it used to rob someone.
468 2011-12-20 04:36:59 <gmaxwell> midnightmagic: presumably if there was non-trivial pushback both the devs and pools would back off, but no one seems much opposed to it now in any case.
469 2011-12-20 04:37:21 <jrmithdobbs> midnightmagic: i've specifically seen it used to rob someone in #bitcoin
470 2011-12-20 04:37:28 <jrmithdobbs> end of discussion, criteria met
471 2011-12-20 04:37:32 <midnightmagic> geh, brutal. shades of the testnet reset..
472 2011-12-20 04:37:44 <midnightmagic> jrmithdobbs: actually not, unless he saw it too.
473 2011-12-20 04:37:49 <gmaxwell> midnightmagic: well, again, fucking fix it. Because I think it's terrible.
474 2011-12-20 04:37:51 <jrmithdobbs> haha
475 2011-12-20 04:38:33 <gmaxwell> midnightmagic: I'm not completely sure if what I saw was someone being robbed or someone lying. But it doesn't matter, its a somewhat minor security vulnerability that closes as more nodes are upgraded.
476 2011-12-20 04:38:39 <midnightmagic> gmaxwell: Hey man, I'm not saying "don't fix the 0-confirm txn relay" I'm just sitting here wondering why there's even the facade of a vote.
477 2011-12-20 04:38:55 <jrmithdobbs> sipa: pretty nifty stuff though
478 2011-12-20 04:39:22 <gmaxwell> midnightmagic: because we actually need a way of telling for quasisure that people did apply the patch and weren't just saying they would.
479 2011-12-20 04:40:02 <gmaxwell> midnightmagic: and because its a good mechenism to use for the future... when hopefully we won't have this fucked up situation where bitcoin is no longer decenteralized.
480 2011-12-20 04:40:06 <gmaxwell> :-/
481 2011-12-20 04:40:07 <sipa> jrmithdobbs: far from finished though; still on TODO: export/import node db to a file, command-line options, comments in the code, some extra configuration options, ...
482 2011-12-20 04:40:32 <jrmithdobbs> sipa: think it also needs to be able to bootstrap via a --conect=
483 2011-12-20 04:40:53 <gmaxwell> jrmithdobbs: why not bootstrap via .. dnsseed?
484 2011-12-20 04:41:01 <jrmithdobbs> having to bootstrap dns seeds off of dns could end badly during catastrophe
485 2011-12-20 04:41:18 <jrmithdobbs> gmaxwell: just as an option
486 2011-12-20 04:41:33 <sipa> it actually bootstraps now off BlueMatt's seed...
487 2011-12-20 04:41:38 <sipa> which seems to work fine
488 2011-12-20 04:41:42 <jrmithdobbs> ya that's why i mentioned
489 2011-12-20 04:41:56 <sipa> but if all dns seed are all booting off eachother... we may have a problem
490 2011-12-20 04:42:10 <jrmithdobbs> right, that's all i was saying
491 2011-12-20 04:44:15 <jrmithdobbs> sipa: like the CAddrInfo stuff
492 2011-12-20 04:44:54 <sipa> that's what CAddress should be in bitcoin as well
493 2011-12-20 04:45:19 <sipa> maybe not as complex
494 2011-12-20 04:45:20 <jrmithdobbs> jgarzik: sipas got most of the work done on being able to prune addr.dat if you want to clean bitcoin to merge it, heh
495 2011-12-20 04:45:38 <jrmithdobbs> sipa: no i think that's about what it should be
496 2011-12-20 04:45:52 <sipa> i'm keeping more statistics now than i actually use
497 2011-12-20 04:45:58 <phantomcircuit> tcatm, ps bcc is shitting itself
498 2011-12-20 04:46:17 <jrmithdobbs> sipa: could be useful for reporting
499 2011-12-20 04:48:03 <helo> the wiki needs to make it easier to find out how to generate encrypted wallet from the get-go...
500 2011-12-20 04:48:18 <helo> 10 minutes of searching and counting
501 2011-12-20 04:48:44 <rjk2> maybe cause its so obvious in the gui?
502 2011-12-20 04:48:47 <rjk2> dunno
503 2011-12-20 04:48:56 <midnightmagic> uh, for what it's worth, I do fully intend to upgrade asap, i'm not just being an ass..  so thanks for the spirited discussion, it's given me hopefully the motivation to update to luke's merged-mining patches..
504 2011-12-20 04:50:32 <helo> rjk2: i don't want to encrypt my wallet after it has been saved to my disk... without understanding the specifics of the disk tech that is being used, it's very likely leaking information. seems like a common need to be able to generate a new encrypted wallet directly
505 2011-12-20 04:51:00 <helo> i guess i could link ~/.bitcoin to /dev/shm, encrypt, and then copy it to disk
506 2011-12-20 04:51:27 <rjk2> the encrypted wallet overwrites the area where the unencrypted one was initially created, i *think*
507 2011-12-20 04:51:38 <jrmithdobbs> rjk2: it can't
508 2011-12-20 04:51:38 <rjk2> gmaxwell: can you confirm
509 2011-12-20 04:51:47 <jrmithdobbs> i think it "tries" to
510 2011-12-20 04:51:49 <rjk2> i thought it was something similar to that
511 2011-12-20 04:51:51 <jrmithdobbs> but that shit doesn't work on any modern fs
512 2011-12-20 04:51:53 <gmaxwell> rjk2: no. It doesn't.
513 2011-12-20 04:51:55 <helo> rjk2: what if you're using ssd with wear-leveling, so it tries not to overwrite the same blocks if possible?
514 2011-12-20 04:52:01 <jrmithdobbs> or there was talk of making it
515 2011-12-20 04:52:37 <jrmithdobbs> helo: you don't even have to go that far, most fses don't immediately reuse blocks even if rewriting to the same logical place
516 2011-12-20 04:52:43 <jrmithdobbs> helo: haven't for a decade
517 2011-12-20 04:52:49 <gmaxwell> helo: if you encrypt a wallet it will retire all the potentially leaked keys in the keypool.
518 2011-12-20 04:52:53 <helo> so fucked on all fronts
519 2011-12-20 04:53:07 <gmaxwell> helo: so _presuming_ there are no other bugs, all you do is startup with a new wallet and encrypt it and you're fine.
520 2011-12-20 04:53:40 <gmaxwell> (any address you get post encrypting will be a born-encrypted address)
521 2011-12-20 04:53:41 <jrmithdobbs> can't you start with the encrypted wallet flag with no wallet.dat and it'll create it?
522 2011-12-20 04:53:58 <helo> gmaxwell: so if i open the client, encrypt the wallet, and do a getaddressbyaccount, the address will be from a private key that was never written to disk unencrypted?
523 2011-12-20 04:54:04 <gmaxwell> jrmithdobbs: no, you have to startup unencrypted, but see above: it doesn't matter. If you start, then encrypt, you'll be all set.
524 2011-12-20 04:54:05 <helo> ahh good
525 2011-12-20 04:54:09 <sipa> helo: yes
526 2011-12-20 04:54:12 <gmaxwell> helo: yep.
527 2011-12-20 04:54:34 <gmaxwell> This is because sipa is a very smart person and realized that this simply solved the problem even though we can't reliably overwrite on the disk.
528 2011-12-20 04:54:41 <rjk2> see, they think of everything :)
529 2011-12-20 04:55:02 <sipa> gmaxwell: can't remember that i came up with that
530 2011-12-20 04:57:24 <gmaxwell> I think so. I mostly remember feeling stupid for not realizing it myself!
531 2011-12-20 04:57:42 <gmaxwell> (esp after thinking many times that it sucked that there was no reasonable way to have a wallet born encrypted!)
532 2011-12-20 04:57:57 <gmaxwell> You're still smart even if I'm wrongfully crediting you. :)
533 2011-12-20 05:03:02 <helo> hah, that is pretty magical
534 2011-12-20 05:03:23 <helo> particularly since it only encrypts the private keys, so you can still get addresses without even typing the passphrase
535 2011-12-20 05:05:49 <gmaxwell> helo: right, thats an important part of the design... means you can keep it encrypted 99% of the time you're _using_ bitcoin.
536 2011-12-20 05:07:58 <jrmithdobbs> i just don't have a wallet on a listening node
537 2011-12-20 05:37:07 <helo> someone will get a 1BTC donation from me for this in the morning :)
538 2011-12-20 05:40:26 <genjix> helo: the wiki is editable you know
539 2011-12-20 05:40:32 <genjix> so go ahead and explain it there
540 2011-12-20 06:00:24 <Mqrius> Where can I check pending transactions? bitcoincharts doesn't seem to be responding
541 2011-12-20 06:02:41 <phantomcircuit> Mqrius, bitcoinchain.info
542 2011-12-20 06:02:57 <phantomcircuit> blockchain.info i mean
543 2011-12-20 06:04:50 <Mqrius> Thanks
544 2011-12-20 06:32:55 <Kireji> the latest bitcoind version I ran was bitcoin-0.3.24 (on linux/console) I'm upgrading to bitcoin-0.5.1-linux - can I just leave my ~/.bitcoin directory in place and fire up the new client?
545 2011-12-20 06:33:31 <phantomcircuit> Kireji, backup first just for super safety
546 2011-12-20 06:33:36 <phantomcircuit> but yes it will just work
547 2011-12-20 06:34:01 <Kireji> backup, meaning copy all the files in .bitcoin into another area?
548 2011-12-20 06:35:43 <sipa> Kireji: just wallet.dat
549 2011-12-20 06:36:23 <Kireji> the blk0001.dat and blkindex.dat are the 800MB - do I delete those or leave them?
550 2011-12-20 06:36:29 <sipa> leave them
551 2011-12-20 06:36:56 <sipa> otherwise you'll need to download them again
552 2011-12-20 06:40:52 <MC1984> do it it will be fun
553 2011-12-20 06:45:38 <Kireji> MC1984: badurrr, ok
554 2011-12-20 06:45:48 <Kireji> ;)
555 2011-12-20 06:46:05 <MC1984> they made it super fast download now bro, i promise
556 2011-12-20 06:46:52 <Kireji> what's the total size of .bitcoin directory now?
557 2011-12-20 06:47:40 <Kireji> I'm assuming all clients still download the whole block chain, as before - is that still how the client works?
558 2011-12-20 06:48:20 <terrytibbs> Kireji: correct
559 2011-12-20 06:48:48 <terrytibbs> allchains reports a chain size of about 800mb
560 2011-12-20 06:49:09 <terrytibbs> that can depend on how many orphan blocks and other nasty stuff they've accumulated over time, though
561 2011-12-20 06:49:21 <terrytibbs> a clean download would be a tad bit smaller
562 2011-12-20 06:49:48 <Kireji> kk, thanks
563 2011-12-20 06:57:45 <Kireji> ok, so where is wallet.dat now?
564 2011-12-20 06:59:06 <Kireji> without a wallet.dat file, "bitcoind listreceivedbyaddress 0 true" and "bitcoind getbalance" still return results
565 2011-12-20 06:59:16 <Kireji> but don't seem to access of use my old wallet.dat
566 2011-12-20 06:59:56 <sipa> wallet.dat is still where it used to be
567 2011-12-20 07:00:32 <Kireji> :/
568 2011-12-20 07:03:25 <Kireji> perhaps copying and moveing the file out from unerneighth the running server is not such a good idea
569 2011-12-20 07:03:31 <Kireji> s/moving/
570 2011-12-20 07:04:19 <Kireji> it's all good
571 2011-12-20 07:04:23 <Kireji> it's all there
572 2011-12-20 07:04:36 <Kireji> thanks all - g'night and happy holiday season
573 2011-12-20 08:22:48 <netxshare> anyone have anyidea why listtransactions would give out data the first time around, but fail the second time?
574 2011-12-20 08:22:58 <netxshare> I was able to get the txid just fine but now it returns nothing
575 2011-12-20 09:14:31 <Diablo-D3> http://news.ycombinator.com/item?id=3368539
576 2011-12-20 09:14:33 <Diablo-D3> NEED MORE KARMA
577 2011-12-20 09:37:40 <edcba> there are always a lot of "experts" cited by journalists :)
578 2011-12-20 09:38:33 <edcba> we had some cyberterrorism expert showing some c++ course in arabic in french television :)
579 2011-12-20 09:38:55 <edcba> citing it was some terrorism bible or whatever
580 2011-12-20 09:39:39 <edcba> http://www.reddit.com/r/programming/comments/cu5t5/according_to_french_terrorism_expert_roland/
581 2011-12-20 09:40:35 <edcba> journalists are often quite unprofessional/stupids
582 2011-12-20 11:32:18 <mcorlett> I've created a nice proof-of-concept script showing how easy it is for entities to accept donations anonymously via Bitcoin, i.e. new address for every user. It's very simple, but neat. Would someone be willing to host a demo of it in action? It's PHP, no dependencies, but needs a connection to a Bitcoin RPC server.
583 2011-12-20 12:00:19 <lianj> why do you need bitcoind rpc?
584 2011-12-20 12:08:04 <[Tycho]> mcorlett: actually most entities need NOT anonymous donations, that's the problem :)
585 2011-12-20 12:58:04 <sipa> ;;later tell BlueMatt how many "good" nodes does your seed find?
586 2011-12-20 12:58:05 <gribble> The operation succeeded.
587 2011-12-20 13:38:38 <helo> no donation address on bitcoin.org?
588 2011-12-20 13:38:56 <sipa> who do you want to donate to?
589 2011-12-20 13:39:50 <helo> good question... i'd prefer not to have to pick a particular dev, as you're all important :)
590 2011-12-20 13:40:22 <helo> oh well
591 2011-12-20 14:36:12 <[Tycho]> Are there any OP_EVAL TXes in testnet ?
592 2011-12-20 15:16:48 <helo> when sending an amount from a wallet with balances on multiple addresses, what criteria does bitcoin use to select the ones it sends from? addresses age? encryption status? fewest addresses required?
593 2011-12-20 15:37:54 <imsaguy2> helo: its a mess right now
594 2011-12-20 15:38:15 <sipa> it first tries to use only 6+-confirms
595 2011-12-20 15:38:24 <sipa> if that doesn't work, it allows 1+-confirms
596 2011-12-20 15:38:34 <sipa> if that doesn't work, it allows 0-confirms for own txouts
597 2011-12-20 15:38:52 <sipa> in each attempt, a greedy matching algorithm is used that tries to minimize the number of coins used
598 2011-12-20 15:42:14 <helo> that is probably good... it would be nice if the client would tell you what your secure (encrypted privkey) and insecure balances are
599 2011-12-20 15:42:33 <helo> or if you only have secure balances, to alert you if you receive funds to an unencrypted address
600 2011-12-20 15:42:59 <sipa> that's either 0 or everything
601 2011-12-20 15:43:26 <sipa> it encrypts all keys when enabling encryption
602 2011-12-20 15:43:35 <sipa> so there are never unencrypted addresses left
603 2011-12-20 15:44:34 <helo> but it can't be guaranteed that unencrypted versions of the addresses aren't still on a block device somewhere
604 2011-12-20 15:44:42 <helo> so there are "less secure" addresses
605 2011-12-20 15:45:23 <sipa> there is no "unencrypted version of an address"
606 2011-12-20 15:45:38 <sipa> it's the private keys that are encrypted
607 2011-12-20 15:45:44 <sipa> and those are not put in the block chain
608 2011-12-20 15:45:57 <helo> yes, replace that with "addresses from unencrypted keys"
609 2011-12-20 15:46:10 <helo> err... "unencrypted keys" bah
610 2011-12-20 15:46:13 <sipa> but you don't have the unencrypted keys anymore
611 2011-12-20 15:46:47 <sipa> now, there could be keys that previously touched disk in unencrypted form, yes
612 2011-12-20 15:47:01 <sipa> so an attacker who has a copy of an older wallet may have access to those
613 2011-12-20 15:47:13 <helo> yes, that is what i'm trying to say :)
614 2011-12-20 15:48:26 <helo> and bitcoin won't give you addresses from the keys that were previously on disk in unencrypted form, right?
615 2011-12-20 15:48:44 <sipa> no
616 2011-12-20 15:49:37 <helo> (quoting gmax earlier) "if you encrypt a wallet it will retire all the potentially leaked keys in the keypool."
617 2011-12-20 15:50:47 <helo> i took that to mean that if i encrypt my wallet, and then get an address, that address will be from a newly generated key that never touched disk unencrypted
618 2011-12-20 15:51:06 <gavinandresen> helo:  From the 0.5 release notes:  "If your encrypted wallet.dat may have been copied or stolen, send
619 2011-12-20 15:51:27 <sipa> helo: that is correct
620 2011-12-20 15:52:21 <helo> so there are some addresses (the ones that have been retired) in the wallet that are less reliably secure than others, that may still receive funds
621 2011-12-20 15:52:28 <CIA-100> bitcoin: Gavin Andresen master * rbd846c0 / (src/serialize.h src/uint256.h src/util.h): Cleanup: removed dead code, and use C99 typedefs for int64 (supported by all modern c++ compilers) - http://git.io/N-mHSg https://github.com/bitcoin/bitcoin/commit/bd846c0e565ca0db276cb6b7eac7763bebe19b84
622 2011-12-20 15:52:29 <CIA-100> bitcoin: Gavin Andresen master * r9ef7fa3 / (src/key.h src/main.cpp): Code cleanup: use ECDSA_size() instead of fixed 10,000 byte sig buffer, and explicity init static var - http://git.io/blmAUw https://github.com/bitcoin/bitcoin/commit/9ef7fa344741cb34ba4e15cff06d61d1c7a74e24
623 2011-12-20 15:52:30 <sipa> true
624 2011-12-20 15:53:06 <helo> i'm asking whether the bitcoin client indicates when funds are received by retired addresses vs "safe" addresses
625 2011-12-20 15:53:40 <helo> and if not, how one can determine whether that has happened
626 2011-12-20 15:54:37 <luke-jr> helo: the client doesn't know the difference
627 2011-12-20 15:55:41 <helo> how does it avoid giving out addresses that have been retired (pre-encryption)?
628 2011-12-20 15:55:57 <CIA-100> bitcoin: Gavin Andresen master * r387c8e3 / (src/util.cpp src/util.h): Merge pull request #673 from mndrix/less-time-data ... https://github.com/bitcoin/bitcoin/commit/387c8e3c5b1e00c6e9e57bfb069a6bfed09411d9
629 2011-12-20 15:56:37 <BlueMattBot> Project Bitcoin build #142: FAILURE in 36 sec: http://jenkins.bluematt.me/job/Bitcoin/142/
630 2011-12-20 15:56:38 <BlueMattBot> * michael: Only log time samples in debug mode
631 2011-12-20 15:56:39 <BlueMattBot> * gavinandresen: Cleanup: removed dead code, and use C99 typedefs for int64 (supported by all modern c++ compilers)
632 2011-12-20 15:56:40 <BlueMattBot> * gavinandresen: Code cleanup: use ECDSA_size() instead of fixed 10,000 byte sig buffer, and explicity init static var
633 2011-12-20 15:56:47 <BlueMatt> wtf?
634 2011-12-20 15:56:49 <sipa> helo: by removing them from the bool
635 2011-12-20 15:56:59 <sipa> *pool
636 2011-12-20 15:57:05 <luke-jr> sigh
637 2011-12-20 15:57:07 <BlueMatt> heh, who broke the build?
638 2011-12-20 15:57:24 <luke-jr> Gavin seems to be focussing on "cleanup" before merging the ACK'd features :/
639 2011-12-20 15:57:37 <luke-jr> I bet that will mean everything has to be rebased
640 2011-12-20 15:58:20 <luke-jr> helo: it never gives out used addresses, pre-encryption or not
641 2011-12-20 15:58:28 <helo> ahhh, right
642 2011-12-20 15:58:38 <jgarzik> luke-jr: what pulls have been ACK'd but not merged?
643 2011-12-20 15:59:42 <helo> so it marks all pre-encryption addresses as used... so when it receives funds, it's always going to be to an address that isn't in the pool any longer, and it won't know whether they were removed from the pool
644 2011-12-20 16:00:26 <helo> s/whether/why/
645 2011-12-20 16:00:56 <sipa> helo: the pool is the list of addresses marked as 'not used yet'
646 2011-12-20 16:01:08 <sipa> and when you request a new address from the client, it picks one from that list
647 2011-12-20 16:01:24 <sipa> when encrypting, that list is emptied, and a new set of pool keys is generated
648 2011-12-20 16:01:44 <helo> yeah, i think i get it now
649 2011-12-20 16:01:45 <sipa> (while the actual keys in there remain in your wallet, they are just never returned when asking for a new address)
650 2011-12-20 16:03:06 <sipa> BlueMatt: i currently have a set of +- 1070 nodes considered 'good' by my seed
651 2011-12-20 16:03:23 <BlueMatt> sipa: I usually get somewhere around 1500 when things are working well
652 2011-12-20 16:03:25 <gavinandresen> BlueMatt: I broke the build, fixing now...
653 2011-12-20 16:03:35 <BlueMatt> gavin...
654 2011-12-20 16:03:39 <sipa> BlueMatt: you include 0.3.24 though, right?
655 2011-12-20 16:03:47 <BlueMatt> thats true
656 2011-12-20 16:04:33 <CIA-100> bitcoin: Gavin Andresen master * r0e87f34 / src/serialize.h : Include limits, not climints (using std::numeric_limits now) - http://git.io/YY1-Lg https://github.com/bitcoin/bitcoin/commit/0e87f34bed1fac9b2ac2fa2b38c2f2a91b5b6c42
657 2011-12-20 16:04:53 <gavinandresen> (grumbles about sub-includes not being standardized across compilers....)
658 2011-12-20 16:08:19 <luke-jr> jgarzik: coinbaser, signmessage_gui, etc
659 2011-12-20 16:10:04 <CIA-100> bitcoin: Kamil Domanski * r4b7c4f285146 gentoo/net-p2p/libbitcoin/ (Manifest libbitcoin-9999.ebuild): net-p2p/libbitcoin-9999: berkdb use_enable updated http://tinyurl.com/ctku7x6
660 2011-12-20 16:10:43 <gavinandresen> jgarzik:  I defer to your judgement on coinbaser, I don't care.
661 2011-12-20 16:10:59 <gavinandresen> wumpus: I defer to your judgement on signmessage_gui.
662 2011-12-20 16:11:26 <gavinandresen> (I have no objections to either)
663 2011-12-20 16:16:03 <gmaxwell> sipa: a little troubling that you're finding so few recent nodes. ... I lost track, did anyone ever fix the upnp to re-register?
664 2011-12-20 16:16:22 <BlueMatt> gmaxwell: iirc, no
665 2011-12-20 16:16:26 <sipa> gmaxwell: ?
666 2011-12-20 16:16:45 <BlueMatt> gmaxwell: thats how many nodes Ive had for months and months
667 2011-12-20 16:18:01 <gmaxwell> sipa: the upnp is one-shot, this means the pinhole will eventually stop forwarding (when depending on the behavior of the nat device)
668 2011-12-20 16:18:34 <sipa> uhu, that probably causes a serious loss of connectable nodes
669 2011-12-20 16:21:34 <BlueMatt> (among other things)
670 2011-12-20 16:24:04 <sipa> ip over dns?
671 2011-12-20 16:24:09 <BlueMatt> yep
672 2011-12-20 16:24:32 <BlueMatt> (the paid-for wifi hotspots people put up rarely block dns before you pay, so if you do ip-over-dns you get free wifi)
673 2011-12-20 16:24:35 <sipa> bit slow, but works nicely :)
674 2011-12-20 16:24:53 <BlueMatt> yep
675 2011-12-20 16:25:06 <sipa> i used it before i had data on my cell phone
676 2011-12-20 16:25:30 <BlueMatt> yep, same here, but it no longer exists on my vps so I need to install it as a cell modem isnt gonna work well on an airplane...
677 2011-12-20 16:26:16 <sipa> and dns works in a plane? :o
678 2011-12-20 16:26:26 <BlueMatt> yep, well if you have the inflight wifi stuff
679 2011-12-20 16:26:54 <gmaxwell> BlueMatt: also running a ssh server on tcp 53 sometimes works, and is way better than ssh tunnel
680 2011-12-20 16:26:58 <gmaxwell> er dns tunnel
681 2011-12-20 16:27:24 <BlueMatt> mmm, never tried that...that one sounds fun too (but probably easier to do openvpn tunnel on tcp 53...)
682 2011-12-20 16:27:32 <gmaxwell> This is especially useful because pay wifi portals are just simply broken a lot of the time.
683 2011-12-20 16:27:50 <BlueMatt> yep, Im counting on that for later...
684 2011-12-20 16:28:07 <sipa> i found iodine barely usable... just ssh, very slowly
685 2011-12-20 16:28:35 <sipa> i can't imagine what iodine on an airplane is going to be like...
686 2011-12-20 16:28:49 <BlueMatt> Ive done it before, it wasnt too terrible, but it wasnt fun
687 2011-12-20 16:28:59 <BlueMatt> its not like Im gonna use it for anything but irc and ssh anyway
688 2011-12-20 16:37:19 <BlueMattBot> Yippie, build fixed!
689 2011-12-20 16:37:20 <BlueMattBot> Project Bitcoin build #143: FIXED in 31 min: http://jenkins.bluematt.me/job/Bitcoin/143/
690 2011-12-20 16:55:05 <gavinandresen> sipa: I commented on your Bitcoin Script 2.0 gist: https://gist.github.com/1262449
691 2011-12-20 17:00:05 <CIA-100> bitcoin: Kamil Domanski * r3288087d2395 gentoo/net-p2p/libbitcoin/ (Manifest libbitcoin-0.1.0_alpha1.ebuild): net-p2p/libbitcoin: 0.1.0_alpha1 http://tinyurl.com/c9vc2oe
692 2011-12-20 17:00:07 <CIA-100> bitcoin: Kamil Domanski * r65c6b4e1314d gentoo/app-crypt/subvertx/ (Manifest subvertx-0.1.0.ebuild): app-crypt/subvertx: 0.1.0 http://tinyurl.com/d9vmjhp
693 2011-12-20 17:29:32 <BlueMatt> yay, connected over dnstunnel :)
694 2011-12-20 17:30:49 <sipa> gavinandresen: i believe TD is the expert on those things
695 2011-12-20 17:34:02 <sipa> BlueMatt: cool
696 2011-12-20 17:34:07 <sipa> where are you flying?
697 2011-12-20 17:34:26 <BlueMatt> san fransisco (my dad's parents are out there)
698 2011-12-20 17:34:34 <sipa> cool
699 2011-12-20 17:34:42 <sipa> nice city :)
700 2011-12-20 17:35:16 <BlueMatt> yea, probably wont spend too much time in the city, one of my dads parents is in sacramento and the other is in livermore...
701 2011-12-20 17:35:36 <luke-jr> BlueMatt: good luck, people know to ban domains now
702 2011-12-20 17:35:59 <sipa> BlueMatt: and where are you now, actually?
703 2011-12-20 17:36:04 <BlueMatt> luke-jr: well we'll see, ive got plenty to work on even if I dont have internet anyway...
704 2011-12-20 17:36:11 <BlueMatt> sipa: will by flying out of charlotte
705 2011-12-20 17:43:55 <BlueMatt> gavinandresen: setting something to load at startup isnt an initialization thing imo, its something that happens at runtime?
706 2011-12-20 17:45:15 <gavinandresen> BlueMatt: I think of init.cpp as "all the stuff that has to happen to get bitcoin up and running."  And that includes "... up and running when the window system starts up" in my head.
707 2011-12-20 17:47:33 <BlueMatt> doesnt connect in my mind, but its not like it matters...Ill move it
708 2011-12-20 17:49:07 <BlueMatt> though if I do move it I have to add yet another #include to qt/optionsmodel.cpp...
709 2011-12-20 17:49:36 <gavinandresen> Speaking of #includes...   I've been sorely tempted to get rid of #include "headers.h"
710 2011-12-20 17:49:54 <gavinandresen> Is anybody actually using headers.h as it was intended-- to implement precompiled headers?
711 2011-12-20 17:50:37 <BlueMatt> headers.h should always have been removed
712 2011-12-20 17:50:51 <BlueMatt> not all files which include it need everything in headers
713 2011-12-20 17:51:51 <BlueMatt> gavinandresen: ok, moved (I dont feel like commenting while running on dns-based internet...)
714 2011-12-20 17:51:59 <BlueMatt> (well the git push might take a minute...)
715 2011-12-20 17:52:24 <gavinandresen> BlueMatt: did you get my early-Christmas-present email?
716 2011-12-20 17:53:18 <BlueMatt> let me switch back to a sane vpn-based internet...
717 2011-12-20 17:55:57 <wumpus> headers.h should go
718 2011-12-20 17:56:12 <wumpus> it's ugly to include all headers indiscriminately in all files
719 2011-12-20 17:56:21 <wumpus> and also slows compile
720 2011-12-20 17:56:55 <BlueMatt> gavinandresen: thanks, will do :)
721 2011-12-20 17:57:08 <gavinandresen> I've been moving code from .h to .ccp as I change things...
722 2011-12-20 17:57:38 <BlueMatt> nice
723 2011-12-20 17:57:48 <BlueMatt> (finally some cleanup...
724 2011-12-20 17:57:49 <BlueMatt> )
725 2011-12-20 18:13:37 <gavinandresen> I've run out of reasons NOT to pull OP_EVAL/multisig into 0.6; any objections before I do?
726 2011-12-20 18:15:22 <BlueMatt> wooo, 0.6 is gonna be a big release :)
727 2011-12-20 18:15:57 <midnightmagic> wumpus: it takes my 6-core machine less than 5 seconds to compile bitcoin..?
728 2011-12-20 18:16:24 <BlueMatt> midnightmagic: it takes the jenkins vps like 5 minutes...
729 2011-12-20 18:16:30 <wumpus> midnightmagic: why would your cpu speed interest me? :p
730 2011-12-20 18:16:55 <midnightmagic> woops..  s/bitcoin/bitcoind/
731 2011-12-20 18:17:49 <gavinandresen> BlueMatt: RE: the anonymity patch, and 0.6 in general:  I want to start moving away from "default answer is NO" towards "as long as it has general support, is well-written, and we can't think of any way it might compromise security/stability, the answer is yes"
732 2011-12-20 18:18:01 <midnightmagic> wumpus: ah.. you were mentioning compile speed as a motivator for reorg .h.. I agree the reorg is good, I just don't think compile time is much of a reason..
733 2011-12-20 18:18:24 <wumpus> exactly gavinandresen... I'm not saying either that we should merge it asap, but I think it's a pretty good pull request and we shouldn't just reject it out of the blue
734 2011-12-20 18:18:52 <jgarzik> gavinandresen: IMO "as long as there is an audience"
735 2011-12-20 18:18:56 <wumpus> midnightmagic: we don't all have fast 6-core machines
736 2011-12-20 18:19:04 <jgarzik> don't wanna pull stuff that has one user (luke-jr!) and that's it
737 2011-12-20 18:19:04 <midnightmagic> BlueMatt: that's a long time. you think header files reorg will fix a 5-minute compile time?
738 2011-12-20 18:19:08 <gavinandresen> jgarzik: yes, that too.
739 2011-12-20 18:19:09 <wumpus> jgarzik: agreed
740 2011-12-20 18:19:20 <wumpus> jgarzik: but if you reject features please do it immediately, and not after 6 months :P
741 2011-12-20 18:19:38 <wumpus> the guy kept it up to date through a ui change
742 2011-12-20 18:19:39 <BlueMatt> midnightmagic: no, but it will speed it up
743 2011-12-20 18:19:50 <BlueMatt> gavinandresen: well Im not saying no, Im saying be weary of pushing bitcoin's anonimity
744 2011-12-20 18:19:56 <BlueMatt> gavinandresen: if its an option, thats fine with me too
745 2011-12-20 18:20:04 <BlueMatt> gavinandresen: but Id really prefer it to not appear by default...
746 2011-12-20 18:20:13 <wumpus> yes it's an advanced setting
747 2011-12-20 18:20:21 <wumpus> as I also said it's too complicated for default users
748 2011-12-20 18:20:29 <gavinandresen> What is the wording of the advanced setting?
749 2011-12-20 18:20:42 <gavinandresen> ("coin control" would be better than "anonymity", I think)
750 2011-12-20 18:20:58 <gavinandresen> (I'm very sympathetic to the "don't promise more than we deliver" argument)
751 2011-12-20 18:21:03 <wumpus> "Enable godmode"
752 2011-12-20 18:21:04 <midnightmagic> gavinandresen: May I ask which pull request that is?
753 2011-12-20 18:21:09 <wumpus> yes good name gavinandresen
754 2011-12-20 18:21:12 <jgarzik> wumpus: RE 6 months, I wasn't referring to any specific commit.  But in particular, sometimes one must wait-and-see before it is apparent whether or not something wants rejecting or accepting
755 2011-12-20 18:21:31 <jgarzik> gavinandresen: good messaging (re "coin control")
756 2011-12-20 18:21:33 <gavinandresen> midnightmagic: https://github.com/bitcoin/bitcoin/pull/415
757 2011-12-20 18:21:36 <wumpus> "enable advanced coin control features"
758 2011-12-20 18:22:09 <midnightmagic> "- select which address(es) to send from, rather than letting the client to chose for you"  WHOAH!!
759 2011-12-20 18:22:12 <midnightmagic> yes, PLEASE
760 2011-12-20 18:23:14 <BlueMatt> gavinandresen: the "default no" stuff is imo a safe fallback as long as the code is fairly messy and not well abstracted, but we are slowly moving towards better abstraction (CWallet, etc) so default no should shift away over time (IMO)
761 2011-12-20 18:23:43 <wumpus> gavinandresen: agreed on the "don't overpromise"
762 2011-12-20 18:24:52 <wumpus> jgarzik: why? one can say immediately wether it would fit in the client or not (if it's purely a code quality issue, that's something else, but that means the requester has to improve the code first)
763 2011-12-20 18:27:13 <jgarzik> wumpus: see above re "audience"    To give a real world example from past bitcoin history, we may see a wide variety of mining-code changes that would fit in the client... but they may have only a single user and be widely ignored by other miners
764 2011-12-20 18:27:25 <wumpus> the problem with default no is that you discourage people from contributing
765 2011-12-20 18:27:44 <wumpus> jgarzik: if it only has a single user I don't see a reason for including it
766 2011-12-20 18:27:50 <jgarzik> wumpus: or feedback is needed to examine performance claims match submitted request (mining code optimizations) etc.
767 2011-12-20 18:28:10 <jgarzik> wumpus: yes
768 2011-12-20 18:28:11 <wumpus> sure, of course you can think of exceptions
769 2011-12-20 18:28:36 <jgarzik> wumpus: we have a great many exceptions, to the point that making a "accept or reject immediately" rule useless and unproductive
770 2011-12-20 18:28:45 <wumpus> sigh, whatever...
771 2011-12-20 18:28:57 <BlueMatt> wumpus: well Ive always fallen in the default no category because at one point or another Ive always felt like someone has been working on cleaning up code, but overtime code cleanup really hasnt happened and Ive softened my tone (a bit)...
772 2011-12-20 18:29:34 <jgarzik> note this is tangential to the "default no" discussion.  not referring to "default no", only "accept or reject immediately"
773 2011-12-20 18:30:04 <wumpus> jgarzik: I simply meant that remarks like "we don't want advanced anonymity" should be made soon after the pull request was made, can you at least agree with that?
774 2011-12-20 18:30:59 <wumpus> BlueMatt: agreed
775 2011-12-20 18:31:16 <gavinandresen> Question for y'all:  I'm reading through pull 415, and I don't like the use of a global variable (sendFromAddressRestriction) to influence the coin selection algorithm.  Seems to me a refactor is in order, but would that be out of scope for the pull request?  Asking the submitter to do that kind of deep refactoring (maybe using boost::bind to pass in a more general coin selection criteria function that could be extended/changed/etc
776 2011-12-20 18:32:00 <sipa> i'm not sure how much you can still ask so much time after the origin request
777 2011-12-20 18:32:08 <wumpus> I think that's too much to ask
778 2011-12-20 18:32:16 <wumpus> he made the commit in the style of the current code
779 2011-12-20 18:32:36 <wumpus> though I agree it's not nice
780 2011-12-20 18:32:44 <BlueMatt> Im off, Ill see yall later
781 2011-12-20 18:32:55 <wumpus> this should be a parameter
782 2011-12-20 18:32:56 <wumpus> later BlueMatt
783 2011-12-20 18:32:59 <wumpus> not a global
784 2011-12-20 18:33:12 <jgarzik> gavinandresen: you ask the age-old FOSS question ;-)
785 2011-12-20 18:33:20 <jgarzik> gavinandresen: Linux kernel has not solved this problem, either
786 2011-12-20 18:33:52 <midnightmagic> mmm..  that patch would be absolutely perfect for namecoin.
787 2011-12-20 18:34:22 <midnightmagic> there, it matters quite a bit more which names came from where.
788 2011-12-20 18:34:51 <jgarzik> gavinandresen: ex.:  dev Wang Fu Bar submits a driver enabling hardware and, prior to his appearance, did not work under Linux.  Unfortunately, his driver is x86-specific (not portable), and requires monumental refactoring before it can be accepted.  Plus it reinvents some kernel code (new RAID stack!).
789 2011-12-20 18:35:06 <jgarzik> gavinandresen: we don't want said code as-is, and refactoring is a huge effort.
790 2011-12-20 18:35:15 <jgarzik> what to do?  Good question...
791 2011-12-20 18:35:46 <sipa> it was Fu Bar code?
792 2011-12-20 18:36:08 <sipa> sorry, couldn't resist :)
793 2011-12-20 18:36:15 <wumpus> gavinandresen: I think you can comment on that; he shouldn't use a global to communicate a transient value from the send coind dialog ui to the core
794 2011-12-20 18:36:33 <gavinandresen> Added a "how hard would it be" comment....
795 2011-12-20 18:36:36 <wumpus> gavinandresen: it should pass through the walletmodel at least
796 2011-12-20 18:37:07 <gavinandresen> I actually refactored SelectCoins a bit way back when for one of my many "decided it wasn't a good idea after all" patches....
797 2011-12-20 18:37:52 <wumpus> he's subverting my "I don't communciate with the core directly from UI classes" by defining an external std::string explicitly
798 2011-12-20 18:38:08 <jgarzik> wumpus: that seems like a fair criticism
799 2011-12-20 18:38:12 <gavinandresen> Restriction on the wallet makes more sense, that would be a reasonable way to do it
800 2011-12-20 18:38:24 <wumpus> yep
801 2011-12-20 18:42:57 <CIA-100> bitcoin: Gavin Andresen master * rf06e3e0 / (4 files in 3 dirs): Merge pull request #717 from TheBlueMatt/installerqtupgrade ... https://github.com/bitcoin/bitcoin/commit/f06e3e0ea6c8da90585a9f0936c390659dcece37
802 2011-12-20 18:42:59 <CIA-100> bitcoin: Matt Corallo master * rf18a119 / (4 files in 3 dirs): Implement "Start on window system startup" on Win32 + Linux. - http://git.io/IZmNDw https://github.com/bitcoin/bitcoin/commit/f18a119ac057a3256efffb3ec7d131949ccf48d3
803 2011-12-20 18:51:23 <luke-jr> jgarzik: most things only have one user until merged and released. ;)
804 2011-12-20 18:52:13 <luke-jr> jgarzik: I don't submit pull requests for things that aren't generally useful.
805 2011-12-20 18:52:44 <gmaxwell> luke-jr: we really need a higher degree of testing for bitcoin, even though it's 'beta'. Bitcoin is critical financial software with most of the confidence of a currency riding on it.
806 2011-12-20 18:54:20 <luke-jr> gmaxwell: sure. if you want, feel free to build my next-test branch :P
807 2011-12-20 18:54:34 <luke-jr> though somehow I seem to be missing out on various things Gavin has been pulling
808 2011-12-20 18:54:42 <luke-jr> maybe I need to review the pull req list again
809 2011-12-20 18:55:36 <CIA-100> bitcoin: Gavin Andresen master * r5959255 / (27 files in 2 dirs): Merge branch 'op_eval' - http://git.io/cVl4Vw https://github.com/bitcoin/bitcoin/commit/595925592d36fb5d5d34beea3c3e71fca2b6726e
810 2011-12-20 18:55:44 <sipa> historic moment!
811 2011-12-20 18:56:24 <luke-jr> OP_EVAL isn't *that* great :P
812 2011-12-20 18:56:33 <jrmithdobbs> ya it is
813 2011-12-20 18:56:38 <gavinandresen> gmaxwell: Agreed, we need more testing.... but until there is a release candidate with binaries, it is hard to get much testing effort.
814 2011-12-20 18:56:42 <luke-jr> gavinandresen: you forgot to merge coinbaser first x.x
815 2011-12-20 18:57:35 <gmaxwell> gavinandresen: get the jenkins setup to produce binaries for every build it runs.
816 2011-12-20 18:57:53 <luke-jr> gmaxwell: I think that's BlueMattBot
817 2011-12-20 18:58:03 <gmaxwell> gavinandresen: there is a jenkins plugin called 'promotion' (I think) that can make it publish only builds which pass tests and build everwhere.
818 2011-12-20 18:58:24 <gmaxwell> luke-jr: I wasn't attempting to direct gavin specifically.
819 2011-12-20 18:58:34 <luke-jr> gmaxwell: ?
820 2011-12-20 18:58:42 <luke-jr> ah
821 2011-12-20 18:59:10 <jrmithdobbs> needs more hudson
822 2011-12-20 18:59:14 <jrmithdobbs> <3 hudson
823 2011-12-20 18:59:20 <gavinandresen> gmaxwell: good idea. You willing to make that happen?
824 2011-12-20 18:59:22 <gmaxwell> I mean "the bitcoin project could do X to address the issue of people not testing bleeding edge stuff".  Although I was hopeful things would get bettwe with the elimination of WX. It's _much_ easier to build now.
825 2011-12-20 18:59:44 <luke-jr> jgarzik: wtf? why did you close coinbaser? it was ALREADY accepted
826 2011-12-20 19:00:13 <EvanR-work> im out of date here, what is the master plan regarding the giant blockchain which only expected to grow faster?
827 2011-12-20 19:00:13 <gmaxwell> gavinandresen: I'll give it a shot.
828 2011-12-20 19:00:16 <jgarzik> luke-jr: gavinandresen said "up to jgarzik".  I did not see the already-accepted memo or logic behind such decision.
829 2011-12-20 19:00:28 <jrmithdobbs> EvanR-work: pruning
830 2011-12-20 19:00:33 <EvanR-work> whats pruning
831 2011-12-20 19:00:47 <jrmithdobbs> EvanR-work: you can prune out already spent/checkpointed blocks
832 2011-12-20 19:00:52 <jrmithdobbs> and just leave the metadata
833 2011-12-20 19:00:57 <jrmithdobbs> s/blocks/transactions/
834 2011-12-20 19:00:59 <EvanR-work> which ones are checkpointed?
835 2011-12-20 19:01:06 <EvanR-work> most of them?
836 2011-12-20 19:01:09 <sipa> jrmithdobbs: non-NODE_NETWORK nodes can
837 2011-12-20 19:01:18 <gmaxwell> EvanR-work: I recommend you read the original bitcoin paper, http://bitcoin.org/bitcoin.pdf  it's a pretty easy read and covers a lot of core concepts (if not any details...
838 2011-12-20 19:01:21 <gmaxwell> )
839 2011-12-20 19:01:27 <EvanR-work> ok
840 2011-12-20 19:02:01 <luke-jr> jgarzik: whatever, maybe someone will fork with all this bs then.
841 2011-12-20 19:02:36 <jrmithdobbs> what's wrong with coinbaser?
842 2011-12-20 19:02:37 <gavinandresen> Personally, I think a mining-pool-only fork of bitcoind is overdue
843 2011-12-20 19:02:49 <gmaxwell> jgarzik: nak-ing coinbaser doesn't bode well for keeping major miner nodes on the stock protocol.
844 2011-12-20 19:03:29 <gavinandresen> ... but the mining pools don't seem to like to share code much.
845 2011-12-20 19:03:32 <gmaxwell> E.g. you end up with more of that discussion last night with midnightmagic where his solo mining node is on .23 because he's carring a bunch of mining specific patches.
846 2011-12-20 19:03:47 <luke-jr> gavinandresen: maybe because they see that those who do (like me/Eligius), it's a waste of effort and time
847 2011-12-20 19:03:52 <gmaxwell> gavinandresen: yes, they don't. Luke does, and we just closed one of his pulls. :)
848 2011-12-20 19:03:58 <jrmithdobbs> luke-jr: i don't see a reason not to include coinbaser if it makes you feel better ;p
849 2011-12-20 19:04:22 <jrmithdobbs> luke-jr: then again i was saying that should be merged before you even requested it be merged, haha
850 2011-12-20 19:04:26 <luke-jr> jrmithdobbs: what pisses me off is that I had the understanding it would be one of the first things merged into 0.6 for a while now
851 2011-12-20 19:04:33 <luke-jr> and now a complete flop
852 2011-12-20 19:04:37 <gavinandresen> The needs of mining pools (servicing gazillions of getwork requests) doesn't really match the needs of users or merchants...
853 2011-12-20 19:04:51 <luke-jr> gavinandresen: might as well remove getwork altogether then
854 2011-12-20 19:04:57 <gavinandresen> That's tempting.
855 2011-12-20 19:04:59 <jrmithdobbs> luke-jr: that's ok where'd my key import/export go
856 2011-12-20 19:05:04 <gmaxwell> gavinandresen: it's true, but they aren't mutually exclusive most of the time. merchants aren't served by a QT GUI.
857 2011-12-20 19:05:16 <luke-jr> jrmithdobbs: key import/export actually has real issues blocking it
858 2011-12-20 19:05:26 <sipa> key import/export was merged
859 2011-12-20 19:05:35 <sipa> (not wallet import/export though)
860 2011-12-20 19:05:37 <luke-jr> sipa: O.o
861 2011-12-20 19:05:48 <EvanR-work> O.o
862 2011-12-20 19:05:48 <sipa> after 6 months...
863 2011-12-20 19:05:51 <luke-jr> I would have expected the inverse, since it's the key import/export part with the issues :P
864 2011-12-20 19:05:56 <gavinandresen> gmaxwell: that's very tempting, too.  I'm constantly struggling to figure out where to draw the lines between "core bitcoin" and "everything else"