1 2012-02-17 00:21:43 <BlueMatt> gavinandresen: https://github.com/gavinandresen/bitcointools/pull/12
  2 2012-02-17 00:22:26 <BlueMatt> wait, its 8:22 and gavinandresen is online???
  3 2012-02-17 00:22:56 <gavinandresen> barely....
  4 2012-02-17 05:09:33 <echelon> why is the blockchain 1.3Gb.. i thought there were built-in mechanisms to trim it
  5 2012-02-17 05:13:23 <twmz> are there known issues with the 0.6rc and rpcpassword or other rpc authentication functionality?  I am not sure what I am doing wrong, but I can't get remote rpc connections to work no matter what I put in the config file.
  6 2012-02-17 05:13:36 <twmz> but if I specifiy the password on the command line with -rpcpassword it works fine
  7 2012-02-17 05:14:26 <twmz> nevermind.  found my stupid mistake.
  8 2012-02-17 05:21:43 <gmaxwell> twmz: what was your stupid mistake?
  9 2012-02-17 05:22:11 <twmz> rpcusername=myusername instead of rpcuser=myusername
 10 2012-02-17 05:22:44 <twmz> in the config file
 11 2012-02-17 07:39:50 <splatster> Umm, why does bitcoin-qt use the OpenGL framework?
 12 2012-02-17 07:40:14 <splatster> s/does/is my copy of/
 13 2012-02-17 08:06:26 <splatster> Bitcoin-Qt is getting annoying
 14 2012-02-17 09:01:16 <sje> splaster - it shouldn't need to...there's no opengl functionality in there
 15 2012-02-17 09:01:26 <sje> what os?
 16 2012-02-17 09:01:38 <splatster> OS X
 17 2012-02-17 09:01:55 <splatster> and my nick is splat-ster
 18 2012-02-17 09:02:24 <splatster> It has been using 130% CPU
 19 2012-02-17 09:02:39 <diki> ;;seen tcatm
 20 2012-02-17 09:02:39 <gribble> tcatm was last seen in #bitcoin-dev 1 week, 0 days, 4 hours, 10 minutes, and 59 seconds ago: <tcatm> Well, set it to 0.0.0.0 for the next few years before it is removed?
 21 2012-02-17 09:02:46 <diki> zomg, a whole week?
 22 2012-02-17 09:02:55 <splatster> Uses same amount even when internet is turned off
 23 2012-02-17 09:03:43 <splatster> No reason at all.  130% CPU usage is quite a bit for an idle application.
 24 2012-02-17 09:03:50 <cjd> spinning
 25 2012-02-17 09:04:02 <cjd> imo lock contention
 26 2012-02-17 09:31:53 <sje> splatster: sorry, no idea. doesn't sound normal
 27 2012-02-17 09:33:46 <cjd> add printf calls to CRITICAL_BLOCK macro, I bet you'll see threads in a livelock situation
 28 2012-02-17 09:34:08 <cjd> threads should never have been added to programming
 29 2012-02-17 09:34:43 <sje> cjd - ha...but what would we do with all those cores?
 30 2012-02-17 09:35:23 <cjd> most computers have a lot of processes running
 31 2012-02-17 09:37:00 <cjd> problem is in the average program threads don't make anything any faster
 32 2012-02-17 10:24:04 <sje> omg windows build is an absolute PITA!! deps archive outdated...where the f can i get a mingw build of boost for windows?!?
 33 2012-02-17 10:24:11 <sje> i hate developing on windows
 34 2012-02-17 10:24:20 <Joric> you spell PIPA wrong!
 35 2012-02-17 10:24:35 <sje> everything i've ever touched has taken eight days longer to build
 36 2012-02-17 10:24:42 <Joric> sje, i tried to build it aswell
 37 2012-02-17 10:24:52 <sje> i don't want to have to build boost
 38 2012-02-17 10:25:13 <sje> probably easier to cross compile and run on wine ffs
 39 2012-02-17 10:25:16 <Joric> gavinandresen had some kind of dev machine on amazon EC2
 40 2012-02-17 10:26:11 <Joric> amazon asked for my credit card had to kindly refuse
 41 2012-02-17 10:27:33 <Joric> there's was a problem with db-4.8.30.NC it won't work properly
 42 2012-02-17 10:27:59 <Joric> i built boost/bsddb/openssl myself
 43 2012-02-17 10:28:04 <sje> so i could use vc
 44 2012-02-17 10:28:09 <sje> i have 2010 and 2008
 45 2012-02-17 10:28:17 <Joric> i just used mingw from qt
 46 2012-02-17 10:28:26 <sje> but they crack it over double-defined network stuff
 47 2012-02-17 10:28:29 <Joric> you'll need qtsdk anyway
 48 2012-02-17 10:28:35 <sje> i have qtsdk
 49 2012-02-17 10:28:41 <sje> but no boost for ingw
 50 2012-02-17 10:28:44 <sje> mingw
 51 2012-02-17 10:28:49 <sje> that's the problem
 52 2012-02-17 10:28:58 <Joric> well, you may build boost then
 53 2012-02-17 10:29:14 <sje> really? i just read it was incompatible
 54 2012-02-17 10:29:22 <sje> nm i'll try
 55 2012-02-17 10:29:46 <sje> so far from 'apt-get install boost...' :)
 56 2012-02-17 10:29:59 <Joric> bjam.exe --build-type=complete toolset=gcc variant=release link=static
 57 2012-02-17 10:31:09 <Joric> bootstrap.bat mingw to build bjam
 58 2012-02-17 10:33:18 <sipa> sje: official windows built are done via gitian (on Ubuntu)
 59 2012-02-17 10:34:05 <sipa> the fact that that is easier than building on windows itself says enough ;)
 60 2012-02-17 10:34:47 <Joric> even mingw is more compatible with windows than vc - the latter needs a lot of deps/runtumes
 61 2012-02-17 10:35:36 <Joric> vc is way faster than gcc though
 62 2012-02-17 10:35:53 <Joric> i mean compilation )
 63 2012-02-17 10:41:20 <sje> crap state of affairs
 64 2012-02-17 10:42:00 <sje> i could _try_ and fix the header issues...arg
 65 2012-02-17 10:48:51 <sipa> sje: which header issues?
 66 2012-02-17 10:49:45 <sje> sipa - trying to build using vc...first issue is windows.h has a #define max ....
 67 2012-02-17 10:49:50 <sje> which stuffs up boost
 68 2012-02-17 10:50:11 <sje> then there are problems with network struct redefinitions, because winsock2 needs to be included before windows
 69 2012-02-17 10:50:18 <sje> to prevent inclusion of winsock.h
 70 2012-02-17 10:50:33 <sje> now i have 'pid_t' is unknown
 71 2012-02-17 10:50:53 <sipa> oh, you're trying to revive the vc build system?
 72 2012-02-17 10:51:15 <sje> ha no not really, just trying to use what i have and avoid building boost
 73 2012-02-17 10:51:38 <sipa> because vc building has been broken for quite a while now, afaik
 74 2012-02-17 10:52:27 <sje> well, it is that
 75 2012-02-17 10:53:12 <Joric> sje, tell if you succeed, makefile.vc wasn't updated for months
 76 2012-02-17 10:54:22 <sipa> patches definitely welcome if you succeed, but you're pretty much on your own, since none of the core devs use windows afaik
 77 2012-02-17 10:54:58 <wumpus> yes,the windows version is produced using cross cimpile
 78 2012-02-17 10:57:47 <sje> ok will do. hi wumpus - did you get any of my earlier messages?
 79 2012-02-17 10:57:56 <sje> re tray icon & QSettings
 80 2012-02-17 10:59:10 <wumpus> yes, the reason for using a dummy widget instead of show/hide is because combining minimization with hide/show causes problems in a lot of environments
 81 2012-02-17 11:00:01 <wumpus> it crashed my window manager in some combinations, also sometimes the window didn't come back at all
 82 2012-02-17 11:00:20 <wumpus> hence the fix by reparenting to a disconnected widget
 83 2012-02-17 11:02:14 <wumpus> there were many people with problems with minimize to tray, so many that we consider removing the option
 84 2012-02-17 11:02:21 <wumpus> (close to taskbar works file)
 85 2012-02-17 11:02:24 <wumpus> fine*
 86 2012-02-17 11:04:03 <wumpus> qsettings development branch is here: https://github.com/gavinandresen/bitcoin-git/tree/nooptionsinwallet
 87 2012-02-17 11:04:21 <wumpus> (note that it is untested and probably currently doesn't work :-)
 88 2012-02-17 11:04:41 <sipa> untested in satoshi's meaning of the word?
 89 2012-02-17 11:04:59 <wumpus> yes it's just an experiment for now
 90 2012-02-17 11:05:30 <sipa> (when satoshi said something was 'untested', it meant "probably doesn't compile")
 91 2012-02-17 11:05:43 <wumpus> hehe
 92 2012-02-17 11:07:38 <sje> wunpus - did you ever try changing the window to be a tool window, to remove it from the task bar?
 93 2012-02-17 11:07:45 <sje> *wumpus
 94 2012-02-17 11:08:01 <sipa> oh the joy of multi-platform GUI development
 95 2012-02-17 11:08:43 <wumpus> nope...
 96 2012-02-17 11:09:05 <sje> that's a trick i normally use...that is what i'm trying to test on windows
 97 2012-02-17 11:09:18 <wumpus> sipa: well the basic stuff works fine on all platforms with qt, it's just weird options that give trouble
 98 2012-02-17 11:11:07 <Joric> it is joy! unless there's a deadline
 99 2012-02-17 11:14:32 <wumpus> sje: let us know how it goes
100 2012-02-17 11:26:59 <sje> well, mingw boost building :/
101 2012-02-17 11:37:46 <wumpus> sje:  setWindowFlags(windowFlags() | Qt::Tool); on minimized seems to work :)
102 2012-02-17 11:38:32 <sje> wumpus - don't suppose you want to checkout my branch? i did a few other things, like toggle show/hide instead of just show...
103 2012-02-17 11:38:42 <sje> sje397/bitcoin/TrayWindowPos
104 2012-02-17 11:38:49 <sje> save/restore window position, etc
105 2012-02-17 11:39:13 <wumpus> is that needed? I don't have any problems with the window position when not using a dummy widget
106 2012-02-17 11:39:32 <sje> i do - whenever it's shown, it comes up in a corner of my desktop
107 2012-02-17 11:39:40 <sje> that was part of my motivation
108 2012-02-17 11:39:58 <sje> plus, saving/restoring position and size is kinda nice
109 2012-02-17 11:41:07 <sje> i am borrowing from an instant messenger app i did where i worked on this stuff a little...
110 2012-02-17 11:41:50 <wumpus> okay :)
111 2012-02-17 11:41:54 <sje> i added 'IsObscured' so that clicking the icon when the window is covered will bring it to the front instead of hiding
112 2012-02-17 11:44:44 <sje> there is an issue with the window flickering when options are applied in that branch - i think i know what's wrong and how to fix it (problem is listening to 'optionsChanged' signal i added)
113 2012-02-17 11:52:50 <sje> but the issue i wanted to ask about is, immediately after making it a tool window, i lose my minimise button. after a show/hide it's fine, and in every other case it's fine :/ qt bug i think
114 2012-02-17 11:53:37 <sje> far out - looks like mingw build is working ok
115 2012-02-17 11:56:29 <wumpus> https://github.com/bitcoin/bitcoin/pull/853   see this pull request, I only change the window into a tool window when minimized to tray, and change it again to a normal window when shown
116 2012-02-17 11:57:28 <sje> yeah - does it need to be in the taskbar if there's a tray icon?
117 2012-02-17 11:57:36 <sje> personally i like it not there
118 2012-02-17 11:58:52 <gribble> New news from bitcoinrss: laanwj opened pull request 853 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/853>
119 2012-02-17 12:01:33 <diki> gribble is broken
120 2012-02-17 12:01:42 <diki> ;;bc,gen 232000
121 2012-02-17 12:01:50 <gribble> Error: There's really no reason why you should have underscores or brackets in your mathematical expression.  Please remove them.
122 2012-02-17 12:06:39 <sje> yay i builded it
123 2012-02-17 12:09:58 <Joric> gribble, good joke
124 2012-02-17 12:11:24 <wumpus> sje: depends on the setting "minimize to tray"
125 2012-02-17 12:12:21 <wumpus> if that setting is off it minimizes (to the taskbar) like all other windows, if the setting is on it hides the window completely
126 2012-02-17 12:20:49 <sje> wumpus - yes i know...but i mean, i prefer not to have it in the task bar when the window is visible...just personal preference
127 2012-02-17 12:21:11 <sje> makes sense to me since it's accessible via the taskbar icon anyway
128 2012-02-17 12:21:25 <sje> it just clutters the taskbar...
129 2012-02-17 12:21:33 <sje> but tool windows on windows are ugly
130 2012-02-17 12:22:25 <sje> can i push you to change the taskbar click to toggle visibility instead of show?
131 2012-02-17 12:22:35 <sje> (i can do the patch)
132 2012-02-17 12:23:03 <sje> the issue is that when it is behind another window, clicking hides it and that's dodgy...but my 'IsObscured' method fixes that
133 2012-02-17 12:23:23 <sje> (for whatever systems it works on - tested kde and windows)
134 2012-02-17 12:28:34 <sje> why the hell does it need to link every time i press run in qtcreator on windows?!? ffs
135 2012-02-17 13:00:03 <luke-jr> sipa: b0529ff Fix wallet locking locking
136 2012-02-17 13:00:16 <luke-jr> sipa: throw this into 0.5.3 or wait until 0.5.4?
137 2012-02-17 13:04:48 <sipa> luke-jr: it's a pure bugfix, but it has not had much testing (except by myself)
138 2012-02-17 13:08:01 <sipa> luke-jr: #842 is not necessary in 0.5, by the way
139 2012-02-17 13:08:13 <sipa> 25ab175
140 2012-02-17 13:09:37 <luke-jr> sipa: can't hurt either, afaict?
141 2012-02-17 13:09:45 <sipa> indeed
142 2012-02-17 13:10:11 <luke-jr> and a future bugfix could *possibly* change its necessity, so I'm not inclined to take it out <.<
143 2012-02-17 13:10:25 <luke-jr> it's buried a commit back now
144 2012-02-17 13:13:09 <luke-jr> wumpus: -daemon never worked with Bitcoin-Qt, correct?
145 2012-02-17 13:13:48 <wumpus> no, it never worked
146 2012-02-17 13:13:51 <wumpus> it did awful things
147 2012-02-17 13:14:42 <sipa> luke-jr: 0.5.3 does include the Qt GUI, right, despite the branch name "bitcoind-stable" ?
148 2012-02-17 13:14:54 <luke-jr> sipa: yes
149 2012-02-17 13:16:55 <luke-jr> sipa: back to b0529ff, how practical was the problem it fixes?
150 2012-02-17 13:17:30 <sipa> i should test the old version, actually, i'm surprised it worked at all
151 2012-02-17 13:17:36 <sipa> gimme a se
152 2012-02-17 13:17:37 <sipa> c
153 2012-02-17 13:19:21 <Alex360> Hello all
154 2012-02-17 13:19:35 <Alex360> I have a problem with starting Bitcoin on Windows 7 64bit.
155 2012-02-17 13:19:48 <Alex360> The addr.dat fails loading. Deleting the file won't work.
156 2012-02-17 13:20:08 <Alex360> Can anyone help me, please?
157 2012-02-17 13:20:39 <sipa> what error do you get?
158 2012-02-17 13:20:56 <Alex360> Problem with loading addr.dat (translated from Dutch to English)
159 2012-02-17 13:26:22 <Alex360> I tried to reinstall Bitcoin
160 2012-02-17 13:26:38 <sipa> try deleting the database directory
161 2012-02-17 13:28:05 <Alex360> This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information.
162 2012-02-17 13:28:18 <Alex360> bitcoin-qt.exe stopped working
163 2012-02-17 13:28:43 <phantomcircuit> if you haven't already
164 2012-02-17 13:28:46 <phantomcircuit> backup wallet.dat
165 2012-02-17 13:28:47 <phantomcircuit> :)
166 2012-02-17 13:29:05 <Alex360> My wallet is empty, but thanks!
167 2012-02-17 13:29:14 <Alex360> ************************ EXCEPTION: 11DbException        Db::open: Invalid argument        C:Program Files (x86)Bitcoinitcoin-qt.exe in Runaway exception       says the debug.log
168 2012-02-17 13:29:49 <sipa> Alex360: is that when you start it?
169 2012-02-17 13:30:04 <phantomcircuit> it's broked
170 2012-02-17 13:30:11 <Alex360> Yeah
171 2012-02-17 13:30:23 <Alex360> Full debug log for the start
172 2012-02-17 13:30:24 <Alex360> Bitcoin version 0.5.2-beta Default data directory C:UsersinAppDataRoamingBitcoin Loading addresses... dbenv.open strLogDir=C:UsersinAppDataRoamingBitcoin/database strErrorFile=C:UsersinAppDataRoamingBitcoin/db.log Loaded 0 addresses  addresses               264ms Loading block index...   ************************ EXCEPTION: 11DbException        Db::open: Invalid argument        C:Program Files (x86)Bitcoinit
173 2012-02-17 13:30:37 <gribble> New news from bitcoinrss: laanwj opened pull request 854 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/854>
174 2012-02-17 13:30:38 <sipa> ok your blkindex.dat is corrupted
175 2012-02-17 13:31:04 <Alex360> What now? Must i delete that file?
176 2012-02-17 13:31:23 <diki> is bitcoin.org working for you guys?
177 2012-02-17 13:31:26 <diki> appears to be down for me
178 2012-02-17 13:31:41 <Alex360> Yes it's working here.
179 2012-02-17 13:31:56 <Alex360> Now a try with refreshing my cache
180 2012-02-17 13:32:13 <Alex360> Yeah, it's up!
181 2012-02-17 13:33:33 <sipa> luke-jr: the actually-occuring problem fixed by #828 is lingering threads when using the walletlock RPC, but there may be others (race conditions, 100% cpu usage)
182 2012-02-17 13:33:59 <luke-jr> sipa: your call on whether to put it in 0.5.3 or 0.5.4
183 2012-02-17 13:34:19 <sipa> 0.5.3 then
184 2012-02-17 13:34:50 <diki> any bugs in 0.6 rc1?
185 2012-02-17 13:36:46 <sipa> diki: 15 bug fixes so faer
186 2012-02-17 13:36:56 <sipa> after 0.6.0rc12
187 2012-02-17 13:36:57 <sipa> rc1
188 2012-02-17 13:36:58 <Alex360> How can i fix my error?
189 2012-02-17 13:37:07 <sipa> Alex360: still the same problem?
190 2012-02-17 13:37:24 <Alex360> Yes.
191 2012-02-17 13:37:44 <sipa> the solution that most likely works: delete all files except wallet.dat and bitcoin.conf
192 2012-02-17 13:37:55 <sipa> but that will mean redownloading the block chain
193 2012-02-17 13:38:05 <sipa> alternatively, try leaving blk0001.dat and blkindex.dat there
194 2012-02-17 13:39:05 <Alex360> Ok, do i need to delete the folder "database" to?
195 2012-02-17 13:39:42 <sipa> yes
196 2012-02-17 13:39:56 <sipa> have you downgraded, or changed version when this problem started?
197 2012-02-17 13:40:27 <luke-jr> sipa: speaking of which, what happens when someone downgrades from addrman to pre-addrman?
198 2012-02-17 13:40:46 <sipa> luke-jr: they'll get a seemingly empty address database
199 2012-02-17 13:40:53 <gribble> New news from bitcoinrss: sje397 opened pull request 855 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/855>
200 2012-02-17 13:41:41 <luke-jr> sje needs a lesson on using git x.x
201 2012-02-17 13:41:48 <Alex360> No, just a fresh install, but my computer suddenly shut down yesterday because i pressed the button stop mining in GUIminer. Maybe that's the problem?
202 2012-02-17 13:42:23 <Alex360> It's working now, thanks for helping!
203 2012-02-17 13:42:44 <sje> luke-jr: ha. sorry, fixed
204 2012-02-17 13:43:17 <sipa> sje: hmm, not really :)
205 2012-02-17 13:43:27 <sje> hm no :(
206 2012-02-17 13:43:32 <luke-jr> O.O
207 2012-02-17 13:44:05 <sje> ok. lesson? how to fix that? :/
208 2012-02-17 13:44:31 <luke-jr> BlueMatt: is CBlockStore ready for next-test?
209 2012-02-17 13:45:09 <sipa> luke-jr: afaik blockstore is functional (with some performance issues left only), but it will probably conflict with a lot of other changes
210 2012-02-17 13:45:20 <luke-jr> hmm
211 2012-02-17 13:47:15 <sje> there
212 2012-02-17 13:47:21 <sje> bloody git
213 2012-02-17 13:50:59 <gribble> New news from bitcoinrss: sipa opened issue 856 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/856>
214 2012-02-17 13:55:32 <jgarzik> sipa: I am still having trouble understanding "Februari 15th, the protocol changes and 'version' and 'verack' messages get a checksum"
215 2012-02-17 13:55:48 <jgarzik> sipa: I thought those messages have been in there since version '209'
216 2012-02-17 13:55:53 <jgarzik> er, checksums
217 2012-02-17 13:56:03 <sipa> jgarzik: ok, the correct explanation
218 2012-02-17 13:56:27 <sipa> network protocol versions before 209 did not have checksums anywhere, protocol 209 and above has them for all messages
219 2012-02-17 13:56:34 <jgarzik> yes
220 2012-02-17 13:56:42 <sipa> however, new connections are initialized with version 0
221 2012-02-17 13:56:54 <sipa> and they switch protocol versions after the verack
222 2012-02-17 13:57:32 <sipa> after feb20, new connections will initialize as version 209, causing the two initial messages (version and verack) to have a checksum as well
223 2012-02-17 13:59:06 <jgarzik> sipa: you mean "after 0.6 release" not feb20, yes?
224 2012-02-17 13:59:14 <sipa> no, i mean after feb20
225 2012-02-17 13:59:24 <sipa> it has been that way since bitcoin 0.2.9
226 2012-02-17 13:59:38 <jgarzik> sipa: where is this encoded in the code?  net.h?
227 2012-02-17 13:59:43 <sipa> main.cpp
228 2012-02-17 13:59:54 <sipa> wait
229 2012-02-17 14:00:39 <sipa> net.h, indeed
230 2012-02-17 14:00:44 <jgarzik> sipa: I only see a special testnet rule, dated feb 15, in main.cpp
231 2012-02-17 14:00:45 <jgarzik> ok
232 2012-02-17 14:00:53 <sipa> in CNode's constructor
233 2012-02-17 14:01:25 <jgarzik> sipa: ok, I see it, thanks.  that clears everything up.  Just needed to see the specific code being referred to...  :)
234 2012-02-17 14:01:48 <sipa> who would have thought code can be so clear :)
235 2012-02-17 14:02:19 <jgarzik> sipa: since I was unfamiliar with this bit of code, just reading the pull request, it sounded like you were proposing a brand new protocol change
236 2012-02-17 14:02:25 <jgarzik> that took effect feb20
237 2012-02-17 14:03:02 <sipa> oh no, i was dealing with an earlier-scheduled protocol change :)
238 2012-02-17 14:03:21 <jgarzik> too bad this wasn't staged onto testnet a while ago, with "if (fTestNet || (date > foo))"
239 2012-02-17 14:03:38 <jgarzik> water under the bridge
240 2012-02-17 14:20:46 <luke-jr> sipa: ping
241 2012-02-17 14:21:11 <luke-jr> getalltransactions modifies AddAddress, which is removed probably in addrman; how to merge? :x
242 2012-02-17 14:21:48 <sipa> it doesn't modify AddAddress...
243 2012-02-17 14:22:08 <luke-jr> sorry, multilocal I mean
244 2012-02-17 14:22:50 <sipa> AddAddress can be removed, but you need another IsLocal check somewhere
245 2012-02-17 14:22:51 <luke-jr> which also makes the answer clearer
246 2012-02-17 14:23:00 <sipa> i'll merge it
247 2012-02-17 14:23:50 <luke-jr> I figured it out, no rush
248 2012-02-17 14:24:59 <ferroh> How is it possible that blockchain.info can use MtGox yubikeys?
249 2012-02-17 14:25:00 <ferroh> https://blockchain.info/wallet/yubikey
250 2012-02-17 14:25:26 <sipa> luke-jr: in ThreadOpenConnections2 there is a 'addr == addrLocalHost' test; that becomes IsLocal(addr)
251 2012-02-17 14:33:07 <sje> sorry wumpus, i edited that comment - my fault it was broke, i think
252 2012-02-17 14:33:33 <sje> but maximise does seem to be broken
253 2012-02-17 14:33:48 <wumpus> ok I'll look at that
254 2012-02-17 14:41:13 <roconnor> Dear user n27pHgA6KioCvXUCdijzdFjeaa9kHA7kzi, Due to your violation of bitcoin TOS your asset has been frozen and your private key is being disclosed as 9afaa65b092e4c82ea752080bee6ce53398207dca480f64c82f32bdb7f85b7e5. Have a nice day, and thank you for using bitcoin.
255 2012-02-17 14:41:16 <wumpus> sje: I've repushed, can you test? showNormal is no longer overridden now
256 2012-02-17 14:41:37 <sje> hm ok, will try
257 2012-02-17 14:42:36 <wumpus> it's super-simple now, so many lines removed, it would be great if this was enough
258 2012-02-17 14:51:05 <sipa> luke-jr: mind putting aa625ed6 in 0.5.3rc3?
259 2012-02-17 14:52:39 <luke-jr> sipa: sure, not sure why I missed that
260 2012-02-17 14:53:14 <luke-jr> sipa: it seems to have an API change? :/
261 2012-02-17 14:53:52 <sipa> it shouldn't
262 2012-02-17 14:54:07 <luke-jr> -        obj.push_back(Pair("unlocked_until", (boost::int64_t)nWalletUnlockTime));
263 2012-02-17 14:54:08 <luke-jr> +        obj.push_back(Pair("unlocked_until", (boost::int64_t)nWalletUnlockTime / 1000));
264 2012-02-17 14:54:25 <sipa> yes, nWalletUnlockTime is changed to have millisecond precision
265 2012-02-17 14:54:47 <sipa> so to retain API compatibility, it is divided by 1000 there
266 2012-02-17 14:55:05 <luke-jr> I don't see nWalletUnlockTime being assigned differently, hmmk
267 2012-02-17 14:55:19 <luke-jr> ok, I see it
268 2012-02-17 14:55:54 <luke-jr> o wow, 2997 lines of conflicts for cblockstore
269 2012-02-17 14:57:07 <sje> wumpus - now maximizing the window makes it dissapear
270 2012-02-17 14:57:26 <sipa> sje: it's just being maximized into infinity!
271 2012-02-17 14:57:30 <wumpus> wtf
272 2012-02-17 14:58:30 <sje> wumpus - docs for 'setWindowFlags' says it hides the window, or reparents, and you must call show
273 2012-02-17 14:58:52 <sje> in 'changeEvent' you set it to be 'not tool' on maximize
274 2012-02-17 14:58:55 <sje> which hides it
275 2012-02-17 15:01:07 <wumpus> but why would it hide when you set it to be "not tool"?
276 2012-02-17 15:01:15 <wumpus> wouldn't that simply change it to a normal window
277 2012-02-17 15:03:07 <sje> setWindowFlags hides the window if it's visible...just a quirk of the function i think
278 2012-02-17 15:03:27 <wumpus> seems that windowstatechangeevent does have a field "oldstate" ... so it is possible to detect transitions to, and from maximized reliably
279 2012-02-17 15:03:29 <wumpus> let's try that
280 2012-02-17 15:06:40 <luke-jr> github down?
281 2012-02-17 15:11:00 <wumpus> seems so
282 2012-02-17 15:17:17 <sje> you killed it wumpus ;)
283 2012-02-17 15:17:27 <sje> i must sleep - cya
284 2012-02-17 15:17:28 <wumpus> it works again
285 2012-02-17 15:17:31 <wumpus> see ya
286 2012-02-17 15:17:42 <wumpus> sje: I did another re-push, please test when you have the time :)
287 2012-02-17 15:17:52 <sje> will do
288 2012-02-17 15:17:53 <wumpus> now it's actually detecting minimized->unminimized
289 2012-02-17 15:17:56 <wumpus> and the other way around
290 2012-02-17 15:21:20 <copumpkin> has anyone looked at roconnor's thing? that looks scary
291 2012-02-17 15:22:12 <sipa> there's a fix coming up
292 2012-02-17 15:22:18 <sipa> well, fix
293 2012-02-17 15:22:42 <sipa> first step is adding the block's height to the coinbase
294 2012-02-17 15:22:50 <luke-jr> copumpkin: ?
295 2012-02-17 15:22:50 <sipa> then disencouraging blocks that don't
296 2012-02-17 15:23:20 <copumpkin> ;;seen roconnor
297 2012-02-17 15:23:20 <gribble> roconnor was last seen in #bitcoin-dev 42 minutes and 6 seconds ago: <roconnor> Dear user n27pHgA6KioCvXUCdijzdFjeaa9kHA7kzi, Due to your violation of bitcoin TOS your asset has been frozen and your private key is being disclosed as 9afaa65b092e4c82ea752080bee6ce53398207dca480f64c82f32bdb7f85b7e5. Have a nice day, and thank you for using bitcoin.
298 2012-02-17 15:23:26 <copumpkin> luke-jr: what he just said
299 2012-02-17 15:23:31 <wumpus> copumpkin: no use trying that private key, it has no coins on it
300 2012-02-17 15:23:57 <copumpkin> [11:18:02] <roconnor> copumpkin: actually I froze my money; however if I send you money I can freeze it.
301 2012-02-17 15:24:00 <gmaxwell> Oh, he lives!
302 2012-02-17 15:24:04 <copumpkin> [11:19:45] <roconnor> copumpkin: after you spend it, if the money isn't combined with someone else's I can freeze their money.
303 2012-02-17 15:24:14 <ferroh> lol
304 2012-02-17 15:24:17 <gmaxwell> And what the @#$@# is he talking about there?
305 2012-02-17 15:24:20 <ferroh> lolol
306 2012-02-17 15:24:35 <ferroh> Oh man, that's great stuff.
307 2012-02-17 15:24:36 <sipa> http://r6.ca/blog/20120206T005236Z.html
308 2012-02-17 15:24:41 <sipa> read that
309 2012-02-17 15:25:30 <luke-jr> hehe
310 2012-02-17 15:25:35 <copumpkin> "This is not really a
311 2012-02-17 15:26:20 <Diablo-D3> thats pretty dangerous though
312 2012-02-17 15:26:32 <copumpkin> yeah
313 2012-02-17 15:26:39 <sipa> also quite difficulty to pull at real difficulty, but not impossible
314 2012-02-17 15:26:46 <copumpkin> that's why I wanted to see what people thought
315 2012-02-17 15:26:47 <Diablo-D3> it erodes the trust in whatever system you're describing
316 2012-02-17 15:26:56 <ferroh> if that was actually viable, then Alice would have a huge monetary advantage actually
317 2012-02-17 15:27:01 <Diablo-D3> because thats not particularly possible in bitcoin due to the ZOMG DIFF
318 2012-02-17 15:27:06 <Diablo-D3> and sipa beat me to that
319 2012-02-17 15:27:12 <ferroh> well, huge if the number of coins that could be destroyed was large enough
320 2012-02-17 15:27:32 <Diablo-D3> btw, you know catalyst 12.2?
321 2012-02-17 15:27:36 <Diablo-D3> its fucking magic
322 2012-02-17 15:27:48 <Diablo-D3> Ive been told my kernel runs faster on 12.2 on 58xx.
323 2012-02-17 15:27:50 <Diablo-D3> on _58xx_
324 2012-02-17 15:28:49 <wumpus> but is this a problem?
325 2012-02-17 15:29:02 <wumpus> I mean, a bug that should be fixed?
326 2012-02-17 15:29:18 <sipa> wumpus: it's an actual bug
327 2012-02-17 15:29:41 <Diablo-D3> fuck
328 2012-02-17 15:29:41 <gavinandresen> definitely a bug that should be fixed.  I'd like to get duplicate coinbase discouragement into 0.6
329 2012-02-17 15:29:50 <sipa> the fact is that creating a new transaction with the same id causes the former one to be overwritten in the index
330 2012-02-17 15:29:53 <Diablo-D3> "Updated an old p4 box from 12.1 to 12.2 and gained 18mhash, from 262 to 280."
331 2012-02-17 15:30:01 <Diablo-D3> "Radeon 5830, 900 core, 300 mem, 1.01v"
332 2012-02-17 15:30:27 <luke-jr> next, next-test rebased
333 2012-02-17 15:30:29 <gavinandresen> Fixing that is probably a good idea, too (bdb allows multiple records with the same key, if I recall correctly)
334 2012-02-17 15:31:00 <sipa> gavinandresen: that means hardfork...
335 2012-02-17 15:31:08 <Diablo-D3> 262/900/1120*960*1440 = 360 on a 960mhz 5850...
336 2012-02-17 15:31:26 <Diablo-D3> 280/900/1120*960*1440 = 384 on a 960mhz 5850...
337 2012-02-17 15:31:30 <ciscoftw> whats up with the blockexplorer?
338 2012-02-17 15:31:32 <Diablo-D3> thats still slower than on my box!
339 2012-02-17 15:31:35 <gavinandresen> sipa:  good point...
340 2012-02-17 15:31:58 <imsaguy2> some hardforks are worth it
341 2012-02-17 15:32:14 <imsaguy2> a fundamental flaw would be such an occasion
342 2012-02-17 15:32:31 <gavinandresen> If we can fix it without the possibility of a hardfork then we should
343 2012-02-17 15:32:44 <sipa> gavinandresen: yes; just disallow overwriting
344 2012-02-17 15:33:08 <sipa> which requires supermajority and stuff
345 2012-02-17 15:33:14 <gavinandresen> sipa: that sounds easy....
346 2012-02-17 15:34:57 <sipa> gavinandresen: it's exactly the same as what we're doing with discouraging duplicate coinbases, only more strict
347 2012-02-17 15:35:20 <copumpkin> gavinandresen: it's an option you can turn on in bdb, but by default it'll just overwrite I think
348 2012-02-17 15:35:25 <gavinandresen> Reject the transaction/block outright.
349 2012-02-17 15:35:34 <sipa> yes, that's what we should do
350 2012-02-17 15:35:56 <sipa> do not allow a transaction to be in a block whose id already exists (unless it is completely spent)
351 2012-02-17 15:36:54 <sje> don't you have to go down to inputs, not just transactions? i thought the point was that there really isn't a transaction id
352 2012-02-17 15:36:57 <gavinandresen> The "unless it is completely spent" rule so that pruning can happen at some point in the future?
353 2012-02-17 15:37:08 <sje> it would be input sequence yes?
354 2012-02-17 15:37:26 <sipa> gavinandresen: indeed
355 2012-02-17 15:37:49 <gmaxwell> sipa: seems prudent.
356 2012-02-17 15:37:58 <gavinandresen> I'd be happy with a reject duplicates with no exceptions for now, and revisiting that if/when pruning happens.
357 2012-02-17 15:38:15 <gmaxwell> gavinandresen: then deploying pruing will be a fork risk. :(
358 2012-02-17 15:38:17 <sipa> revisiting that will require a hardfork
359 2012-02-17 15:38:19 <luke-jr> ^
360 2012-02-17 15:38:24 <gmaxwell> Right.
361 2012-02-17 15:39:00 <sipa> if you only apply the rule to coinbases, no exceptions is reasonable
362 2012-02-17 15:39:09 <gmaxwell> In the case we were limited to coinbases at least we could say "then don't prune coinbases" and that wasn't too bad.
363 2012-02-17 15:39:45 <luke-jr> completely*
364 2012-02-17 15:39:58 <gmaxwell> But for _all_ transactions (which I think is an a reasonable requirement) we don't get that free pass.
365 2012-02-17 15:40:18 <sipa> you can only create duplicate non-coinbases if duplicate coinbases are possible
366 2012-02-17 15:40:23 <luke-jr> in fact, if we say "don't prune <any txn type>", we can't do headers-only&
367 2012-02-17 15:40:42 <gmaxwell> luke-jr: sure we can, because headers-only don't mine.
368 2012-02-17 15:40:54 <gmaxwell> And so their differential acceptance of transactions isn't harmful.
369 2012-02-17 15:41:27 <sipa> there's two options I think; disallow duplicate coinbases entirely, and you retain the power to identify a transaction with its id
370 2012-02-17 15:41:36 <luke-jr> gmaxwell: I mean headers-only of completely spent blocks
371 2012-02-17 15:42:11 <sipa> or you disallow overwriting unspent any transactions (which sounds more sane, imho), but then a duplicate txid is possible in theory in the future
372 2012-02-17 15:42:56 <gmaxwell> sipa: I don't see it that way.
373 2012-02-17 15:43:12 <gavinandresen> Why is disallowing duplicate coinbases entirely less sane?  Storing every coinbase hash isn't a big deal....
374 2012-02-17 15:43:22 <gmaxwell> sipa: we should do the height thing to prevent duplication, but that takes time to deploy. And we disallow overwriting, which we can do faster I think.
375 2012-02-17 15:44:09 <gavinandresen> Let me clean up and push my latest discourageblocks branch....
376 2012-02-17 15:45:01 <sipa> gmaxwell: if adding the height to the coinbase is implemented as a network rule, all is fine
377 2012-02-17 15:45:32 <gmaxwell> sipa: yes, but we probably can't turn on that rule for some time, where I think we could start dropping blocks with overwrites right away.
378 2012-02-17 15:46:02 <gmaxwell> (there is some small risk of wasting effort extending a dead chain in that case, but only if the attack actually happens)
379 2012-02-17 15:46:04 <sipa> gmaxwell: that requires the same kind of roll-out as BIP16
380 2012-02-17 15:46:22 <gavinandresen> https://github.com/gavinandresen/bitcoin-git/tree/discourageblocks
381 2012-02-17 15:46:25 <gmaxwell> sipa: Does it? I think we're allowed to risk orphaning miners to fix a protocol flaw.
382 2012-02-17 15:47:11 <gavinandresen> The discourageblocks code does a 2-stage rollout:  at 50+% any duplicate coinbase blocks are explictly detected and discouraged
383 2012-02-17 15:47:26 <sipa> gmaxwell: it's not about orphaning miners; it's about adding the possibility for an attacker to create a chain split, which is seen by some, and not by others
384 2012-02-17 15:47:31 <gavinandresen> And at 100% (100 of last 100 blocks) any blocks without the height in them are discouraged
385 2012-02-17 15:47:48 <gmaxwell> If someone does the overwrite attack, it's already an attack that potentially forks the chain. So I think we're allowed to roll fixes that potentially split too.
386 2012-02-17 15:48:49 <gmaxwell> Though we can't roll the height fix that way because it will cause splits even where there is no attack, while the overwrite fix splits only where there is an attack (which would potentially cause an unresolvable split in any case)
387 2012-02-17 15:50:16 <sje> gavinandresen: looks to me like that code wil break if there's less than 100 blocks....i.e. for the next 'xcoin'
388 2012-02-17 15:50:53 <gavinandresen> sje: a) nope.  and b) I don't really care about xcoin....
389 2012-02-17 15:51:11 <gavinandresen> sje: wait:  a) yep
390 2012-02-17 15:51:46 <sje> i don't care about xcoin either :)
391 2012-02-17 15:51:54 <sje> but for testing etc...
392 2012-02-17 15:52:01 <gavinandresen> sje:  it'll probably break bootstrapping from an empty chain.... good catch, I'll fix
393 2012-02-17 15:52:42 <luke-jr> gavinandresen: why would any miner adopt discourageblocks without a safe 0th stage?
394 2012-02-17 15:53:36 <gavinandresen> Because if they don't sipa and gmaxwell and I will tell the world that they're not willing to change to fix a bug?
395 2012-02-17 15:54:02 <luke-jr> s/change/risk all their blocks being orphaned until it has majority adoption/
396 2012-02-17 15:54:18 <gavinandresen> huh?  nothing happens until 50+% upgrade
397 2012-02-17 15:54:43 <luke-jr> autodetected?
398 2012-02-17 15:55:01 <gmaxwell> luke-jr: yes, gavin's thing is autodetected.
399 2012-02-17 15:55:24 <luke-jr> hmm
400 2012-02-17 15:56:03 <gavinandresen> yes, I implemented your idea of looking at previous coinbases (very good idea for a permanent change like this, putting height in the coinbase...)
401 2012-02-17 15:56:19 <gmaxwell> I was seperately proposing that we could outright add a protocol rule against blocks that overwrite. Without any staged rollout. Because the only time is creates a fork risk is where an attack would already be creating one. (though I admit it makes the risk somewhat worse, but prevents an attack)  But thats not what gavin is implementing there.
402 2012-02-17 15:57:20 <luke-jr> personally, I'd be more comfortable with 55-60% (and will probably change it for Eligius)
403 2012-02-17 15:58:24 <luke-jr> what's the probability we see this "50%" before it really has 50%?
404 2012-02-17 16:01:17 <gribble> New news from bitcoinrss: laanwj opened pull request 857 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/857>
405 2012-02-17 16:01:39 <gmaxwell> luke-jr: if you change the threshold you make it _less_ secure.
406 2012-02-17 16:01:52 <gmaxwell> because then you don't apply the rule at the same time other nodes do.
407 2012-02-17 16:01:55 <sipa> the fix is trivial (though it needs massive testing, of course): https://github.com/sipa/bitcoin/commit/6bca1b563144229e95e363df21b67acba066a092
408 2012-02-17 16:02:01 <luke-jr> gmaxwell: but not applying the rule is saf.e
409 2012-02-17 16:03:12 <gmaxwell> luke-jr: no it's not you'll extend a bad block and then the rest of the netwok won't extend you.
410 2012-02-17 16:03:31 <luke-jr> gmaxwell: they will
411 2012-02-17 16:03:33 <gmaxwell> oh right discourage.
412 2012-02-17 16:03:34 <gavinandresen> yup, only applies if somebody is trying to pull off the chainsplit attack....
413 2012-02-17 16:04:10 <gmaxwell> luke-jr: you still create risk for others.
414 2012-02-17 16:04:22 <luke-jr> gmaxwell: how so?
415 2012-02-17 16:04:38 <sipa> perhaps the simplify of the fix and the fact that it fixes a protocol flaw will make it easy to convince miners to upgrade?
416 2012-02-17 16:04:51 <sipa> *simplicity
417 2012-02-17 16:05:04 <gmaxwell> sipa: yea, I mean, I think thats a pretty straight forward fix. (though, of course, it needs testing)
418 2012-02-17 16:06:46 <gavinandresen> luke-jr: you're a mining pool operator, would you be willing to coordinate with the other big pools to get this fixed quickly?
419 2012-02-17 16:07:16 <luke-jr> gavinandresen: looks good from what I see, though I commented where I think it could be improved inline
420 2012-02-17 16:07:24 <luke-jr> oh, you mean me talk to the other poolops for it?
421 2012-02-17 16:07:33 <luke-jr> sure I guess
422 2012-02-17 16:09:21 <gmaxwell> At the moment I think I like the straight no-overwrite protocol rule change more than the discouragement code.
423 2012-02-17 16:09:56 <gavinandresen> agreed.  I still like height-in-the-coinbases as a longer term policy change, though
424 2012-02-17 16:10:30 <sipa> by the way: my patch is completely wrong
425 2012-02-17 16:10:49 <gmaxwell> awesome.
426 2012-02-17 16:11:04 <sipa> the '!' mustn't be there
427 2012-02-17 16:11:06 <gmaxwell> sipa: how do you make it cope with a block that is reorging?
428 2012-02-17 16:11:08 <gavinandresen> Whatever we do, we'll need a test plan, thinking, review, ....
429 2012-02-17 16:11:32 <sipa> gmaxwell: irrelevant; when reorging, the old chain is disconnected first, which results in the txindex being removed from the db
430 2012-02-17 16:11:51 <gmaxwell> Yes, we should do height too. But do we use discouragement now for it? or do we just do no-overwrite + add height.. then later make height a protocol rule (should be easy because the fast deployment for the first will get height widely deployed fast)
431 2012-02-17 16:12:17 <gavinandresen> luke-jr: RE: why push-4-bytes for the height:  I ran a tool that looked at previous coinbases, and no-opcode turned up plausible heights, as did the push-3-bytes-opcode.  push-4 was completely clean for all existing coinbases.
432 2012-02-17 16:12:46 <gavinandresen> (plausible height == a height that could occur before the year 2209)
433 2012-02-17 16:12:50 <luke-jr> ah
434 2012-02-17 16:12:53 <luke-jr> sounds good then
435 2012-02-17 16:13:38 <gmaxwell> sipa: okay, I hadn't looked to see _where_ you'd added that code. e.g. if it was early input rather than in the connecting.
436 2012-02-17 16:16:09 <luke-jr> gavinandresen: is the height network-endian?
437 2012-02-17 16:16:19 <gavinandresen> little-endian
438 2012-02-17 16:17:58 <sipa> updated: https://github.com/sipa/bitcoin/commits/nooverwritetx
439 2012-02-17 16:21:13 <luke-jr> gavinandresen: network/big-endian would be preferrable, for the long-term IMO. any reason to put the 'x00' instead of nHeight>>24?
440 2012-02-17 16:21:38 <sipa> luke-jr: gavin tested both; network order would give rise to more potential conflicts with already existing blocks
441 2012-02-17 16:21:48 <luke-jr> i c
442 2012-02-17 16:22:09 <luke-jr> a shame
443 2012-02-17 16:22:36 <gavinandresen> meh.  little-endian is compatible with CScript::operator<<(int)
444 2012-02-17 16:23:03 <sipa> indeed; except inside crypto-related structures, bitcoin already uses little endian everywhere
445 2012-02-17 16:23:07 <sipa> i'd keep it consistent
446 2012-02-17 16:23:37 <gmaxwell> Also needs code to expose that prefix to getmemorypool.
447 2012-02-17 16:23:55 <gavinandresen> gmaxwell: that's what the new coinbaseprefix is for
448 2012-02-17 16:24:06 <gavinandresen> (and height, for good measure)
449 2012-02-17 16:24:19 <gmaxwell> oh. Okay. I'm looking at an old version.
450 2012-02-17 16:24:48 <gavinandresen> https://github.com/gavinandresen/bitcoin-git/commit/6c75f6ce85b0bf2ba38aca7e7248d627fc79c6fc is latest, as of a few minutes ago
451 2012-02-17 16:25:13 <luke-jr> gavinandresen: does CScript::operator<<(int) behave the same on big and little endian? :p
452 2012-02-17 16:25:24 <luke-jr> sipa: Bitcoin uses big-endian places too
453 2012-02-17 16:25:50 <gavinandresen> we've never supported running on big-endian CPUs
454 2012-02-17 16:26:03 <gavinandresen> (or is it little-endian cpus....)
455 2012-02-17 16:27:06 <gavinandresen> gmaxwell: any progress on bitcoin.org/feb20 web page?  I think the plan was to do an alert today...
456 2012-02-17 16:32:04 <gribble> New news from bitcoinrss: laanwj opened pull request 858 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/858>
457 2012-02-17 16:37:11 <luke-jr> gavinandresen: do you plan backports as with p2sh?
458 2012-02-17 16:38:01 <BlueMatt> luke-jr: depends, yes its fully functional, and I would like to see it make it into the next version
459 2012-02-17 16:38:10 <BlueMatt> luke-jr: however, it will probably conflict with a ton of stuff
460 2012-02-17 16:38:30 <BlueMatt> and there is still the case of the performance bug that really doesnt want to show up
461 2012-02-17 16:39:07 <BlueMatt> luke-jr: Ill probably bring it back up to master later today, though so you can at least wait for that
462 2012-02-17 16:39:12 <BlueMatt> (its behind a week or two)
463 2012-02-17 16:39:49 <luke-jr> BlueMatt: yeah, it looked like it needed rebasing
464 2012-02-17 16:39:55 <luke-jr> you had some other branches mixed in too
465 2012-02-17 16:40:03 <gavinandresen> luke-jr: RE: backports:  depends; if we go with sipa's simple fix then I might not bother backporting the discourageblocks changes (although they should backport easily)
466 2012-02-17 16:41:08 <gmaxwell> ^ but would backport the simple fix.
467 2012-02-17 16:41:14 <gavinandresen> I just broadcast an alert on the testnet:  "See bitcoin.org/feb20 if you have connection problems after 20 February"
468 2012-02-17 16:47:13 <Habbie> url doesn't work (yet?)
469 2012-02-17 16:50:43 <Joric> two cool pictures from draco49 http://i.qkme.me/366nwi.jpg http://i.qkme.me/366ofh.jpg
470 2012-02-17 16:52:35 <gribble> New news from bitcoinrss: laanwj opened pull request 859 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/859>
471 2012-02-17 17:28:03 <jgarzik> just got Google+ spam (a follower) from...  http://globalminingcareers.com/
472 2012-02-17 17:28:22 <Diablo-D3> you know, I just had a hilarious idea
473 2012-02-17 17:28:46 <Diablo-D3> changing DM's license from GPLv3 to AGPLv3
474 2012-02-17 17:28:53 <gavinandresen> jgarzik: me too!
475 2012-02-17 17:29:56 <jine> jgarzik: I get tons of spam responses to all Bitlc-tweets.
476 2012-02-17 17:30:09 <jine> With links and shit.
477 2012-02-17 17:30:24 <Diablo-D3> and then sue anyone who doesnt give me their changes
478 2012-02-17 17:30:59 <luke-jr> Diablo-D3: um, what?
479 2012-02-17 17:31:07 <luke-jr> GPLv3 vs AGPLv3 is *no difference* for DM
480 2012-02-17 17:31:14 <Diablo-D3> no, hear me out on this one
481 2012-02-17 17:31:21 <Diablo-D3> it connects to other software over sockets
482 2012-02-17 17:31:38 <Diablo-D3> so if, say, they connect to a remote pool/
483 2012-02-17 17:31:48 <Diablo-D3> bam, violation of the AGPL if they dont give me their changes
484 2012-02-17 17:32:48 <gmaxwell> Diablo-D3: you have to add functionality to the software to give copies of itself over the network.
485 2012-02-17 17:32:51 <luke-jr> it doesn't work like that
486 2012-02-17 17:33:02 <Diablo-D3> gmaxwell: YES o/
487 2012-02-17 17:33:11 <luke-jr> Diablo-D3: they have to give the changes to the pool, not you
488 2012-02-17 17:33:20 <gmaxwell> (and what luke-jr said too)
489 2012-02-17 17:33:40 <Diablo-D3> luke-jr: no
490 2012-02-17 17:33:43 <Diablo-D3> thats not what AGPL says
491 2012-02-17 17:33:45 <luke-jr> yes it is
492 2012-02-17 17:33:54 <Diablo-D3> AGPL says if a third party connects to your shit over to the network, you're fucked
493 2012-02-17 17:34:25 <luke-jr> which isn't the case
494 2012-02-17 17:34:40 <Diablo-D3> :3
495 2012-02-17 17:34:40 <luke-jr> &
496 2012-02-17 17:48:42 <luke-jr> https://bitcointalk.org/index.php?topic=64323.0
497 2012-02-17 17:58:44 <mad_> where is place for sec bugs? core dev mail?
498 2012-02-17 17:59:45 <luke-jr> mad_: unless it could cause someone to lose money, probably fine
499 2012-02-17 18:01:50 <gmaxwell> Considering mad's issues, I'm going to guess that this something worse.
500 2012-02-17 18:02:19 <gmaxwell> mad_: you should privately mail the core devs, e.g. gavin, sipa (peter), jeff.
501 2012-02-17 18:03:09 <diki> luke-jr:you have finally done something useful luke
502 2012-02-17 18:03:25 <diki> I especially like the coinbaser patch
503 2012-02-17 18:05:43 <diki> On a side-note, google has really cleaned out their html5 player
504 2012-02-17 18:05:53 <diki> You can barely spot the difference between the flash based one
505 2012-02-17 18:09:29 <luke-jr> gmaxwell: if that's the case, then isn't SHA256 broken? :/
506 2012-02-17 18:09:41 <gmaxwell> luke-jr: No. We're only using 32 bits of it.
507 2012-02-17 18:09:59 <luke-jr> and 1 character difference doesn't change those 32 bits?
508 2012-02-17 18:10:06 <gmaxwell> luke-jr: sometimes it doesn't.
509 2012-02-17 18:10:46 <luke-jr> :|
510 2012-02-17 18:12:20 <gmaxwell> If we had a proper error correcting code (which would be damn simple if we used base64) then we could have that property (e.g. no up-to-N character typos produce valid addresses), but we don't.
511 2012-02-17 18:14:58 <luke-jr> it would be nice to implement an address scanner that detects addresses that can be easily typo'd validly, and refuses to generate them (and warns when paying)
512 2012-02-17 18:16:13 <gmaxwell> works less well with determinstic wallets.
513 2012-02-17 18:16:41 <luke-jr> det. wallets could just skip an address here and there? :p
514 2012-02-17 18:17:52 <Diablo-D3> gmaxwell: the internet is for error corrected porn/
515 2012-02-17 18:18:21 <gmaxwell> luke-jr: I suppose they could.
516 2012-02-17 18:24:18 <gribble> New news from bitcoinrss: luke-jr opened issue 860 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/860>
517 2012-02-17 18:24:38 <luke-jr> latest next-test seems bug-ful :/
518 2012-02-17 18:26:34 <luke-jr> gavinandresen: fwiw, testnet alert worked here
519 2012-02-17 18:26:36 <luke-jr> on -qt
520 2012-02-17 18:26:49 <gavinandresen> luke-jr: thanks
521 2012-02-17 18:27:30 <luke-jr> gavinandresen: btw, is the alert hidden on 0.4.4, 0.5.0.4, and 0.5.3+ ?
522 2012-02-17 18:28:07 <gavinandresen> luke-jr: Nope, should display on all versions that support displaying alerts
523 2012-02-17 18:28:08 <diki> gavinandresen:Lately, bitcoin development seems to be more active
524 2012-02-17 18:28:53 <luke-jr> gavinandresen: intentionally?
525 2012-02-17 18:29:19 <gavinandresen> luke-jr: yes... why wouldn't we display the alert on those versions?
526 2012-02-17 18:29:31 <luke-jr> gavinandresen: because those are the versions with the fix?
527 2012-02-17 18:30:14 <gavinandresen> ... so they'll see the alert and know to tell their friends who have trouble connecting to go to the web page
528 2012-02-17 18:30:26 <luke-jr> does it go away ever? >_<
529 2012-02-17 18:30:32 <gavinandresen> Yes'
530 2012-02-17 18:31:06 <gavinandresen> expiration on the testnet alert is 1 day from when it was sent this morning
531 2012-02-17 18:31:51 <luke-jr> cool, sounds like you've got everything covered then
532 2012-02-17 18:54:56 <gribble> New news from bitcoinrss: luke-jr opened issue 861 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/861>
533 2012-02-17 19:03:51 <diki> luke-jr:sending bitcoins from an address you want?
534 2012-02-17 19:06:20 <diki> or TO an address?
535 2012-02-17 19:06:30 <diki> I believe the first will be useful as well
536 2012-02-17 20:05:54 <splatster> Has any progress been made toward solving the OS X CPU bug in v0.6?
537 2012-02-17 20:10:27 <diki> these days, CPU bug is all I hear about...
538 2012-02-17 20:11:52 <denisx> CPU bug?
539 2012-02-17 20:13:02 <luke-jr> hmm
540 2012-02-17 20:13:28 <luke-jr> gmaxwell: any other solutions than putting height in coinbase?
541 2012-02-17 20:14:13 <gmaxwell> luke-jr: there are two things we're talking about, I think we should do both:
542 2012-02-17 20:14:31 <luke-jr> gmaxwell: kinlo pointed out that putting height in coinbase actually creates a problem for us
543 2012-02-17 20:14:40 <luke-jr> or at least, makes things difficult
544 2012-02-17 20:14:57 <gmaxwell> prevent blocks from overwriting transactions as a protocol rule, and adding the height to prevent duplication.
545 2012-02-17 20:15:00 <gmaxwell> luke-jr: why?
546 2012-02-17 20:15:14 <kinlo> luke-jr: you will just have to regenerate your standby pool of getworks after every block
547 2012-02-17 20:15:20 <luke-jr> gmaxwell: Eloipool pregenerates blank coinbases, which get used immediately in the next block
548 2012-02-17 20:15:33 <kinlo> luke-jr: if it is indeed the block number; then it is predicteable
549 2012-02-17 20:15:33 <luke-jr> kinlo: and won't be able to use them for the current one
550 2012-02-17 20:15:49 <luke-jr> right now, if the main merkleroot queue runs out, it uses blanks
551 2012-02-17 20:15:51 <kinlo> no; you'll need 2
552 2012-02-17 20:15:55 <gmaxwell> Well, to the extent that it makes you redo merkel root it discourages the antisocial behavior of not including txn just to avoid calculating the root.
553 2012-02-17 20:16:07 <gmaxwell> You could also just precompute the next block. No biggie.
554 2012-02-17 20:16:17 <luke-jr> gmaxwell: 2x the work :p
555 2012-02-17 20:16:18 <gmaxwell> it's not like you don't know the height in advance.
556 2012-02-17 20:16:38 <gmaxwell> luke-jr: so? whatever. a POS CPU can do millions of SHA256/second.
557 2012-02-17 20:17:10 <luke-jr> gmaxwell: not in Python :p
558 2012-02-17 20:18:34 <gmaxwell> make a module. :)
559 2012-02-17 20:19:17 <luke-jr> gmaxwell: there is a module
560 2012-02-17 20:25:50 <luke-jr> gmaxwell: what do you think of a new mining-accept rule of only one transaction with the same scriptSig-ending per block?
561 2012-02-17 20:25:56 <luke-jr> gmaxwell: to discourage deepspam
562 2012-02-17 20:26:56 <gmaxwell> hm. or a rule to fill the free area the queues first by scriptSig-ending.
563 2012-02-17 20:58:07 <denisx> hmm, I tried the patch from jgarzik for getblockbycound and it crashes my bitcoin 0.5.2
564 2012-02-17 20:58:11 <denisx> is it too old?
565 2012-02-17 20:58:18 <denisx> count
566 2012-02-17 20:58:23 <theymos> Works for me.
567 2012-02-17 20:59:50 <theymos> I'm pretty sure the patch file won't work, so you need to do it by hand.
568 2012-02-17 21:01:04 <denisx> theymos: I did
569 2012-02-17 21:01:41 <denisx> I simply added the getblockbyhash, getblockbycount and BlockToValue methods
570 2012-02-17 21:01:47 <denisx> and the entry in the list for them
571 2012-02-17 21:04:13 <theymos> I'm using an older version of the patch which only included getblockbycount (plus some modifications). Maybe that makes a difference. Here's my version: http://pastebin.com/dUzAqWJK
572 2012-02-17 21:05:36 <theymos> In my version it's called "getblock", though you can change this easily to getblockbycount.
573 2012-02-17 21:21:48 <luke-jr> denisx: dumpblock is more recent
574 2012-02-17 21:22:39 <luke-jr> denisx: I just pushed my rebased branch of it to my repo
575 2012-02-17 21:25:33 <josephcp> doesn't dumpblock only have getblockbyheight equivalent?
576 2012-02-17 21:25:49 <luke-jr> maybe
577 2012-02-17 21:26:19 <luke-jr> I wish the getblock in master supported fulldump
578 2012-02-17 21:27:27 <josephcp> the reason i ask is because the blockexplorer use case is get highest block by count and from their go backwards via hash, otherwise it's either a PITA to program or you risk chain mismatches
579 2012-02-17 21:27:46 <josephcp> from there
580 2012-02-17 21:28:25 <gmaxwell> josephcp: and reprocess the whole chain on every request?
581 2012-02-17 21:28:27 <josephcp> yeah it'd be nice to come stock bitcoin RPC
582 2012-02-17 21:29:05 <josephcp> gmaxwell: you know what i mean :-P
583 2012-02-17 21:30:35 <josephcp> i was just implying if the chain reorgs between iterating through block heights when using dumpblock it can get messy fast
584 2012-02-17 21:30:39 <theymos> Bitcoin Block Explorer updates by checking to see whether the latest block already in the database has changed according to Bitcoin. If it has, delete that block and repeat.
585 2012-02-17 21:31:38 <gmaxwell> theymos: how come it was getting stuck by deep reorgs then?
586 2012-02-17 21:32:21 <theymos> That's not actually how I do it, though I should. I used a fixed 5-block look-back time on mainnet and kill BBE if the oldest of those 5 blocks needs to be deleted.
587 2012-02-17 21:33:16 <theymos> On testnet there's a fixed 10-block lookback time and if the oldest of those fails then the entire chain is rescanned.
588 2012-02-17 21:33:53 <josephcp> oh interesting, is that so people will notice something big is happening? or is that a failsafe/circuitbreaker?
589 2012-02-17 21:34:47 <theymos> Yeah, it's meant to stop the chain from being wiped if there's a huge reorg or a bug.
590 2012-02-17 21:36:11 <josephcp> i guess i can see how something like that can be justified for BBE if people are using it to double-check their transactions haha
591 2012-02-17 21:38:56 <theymos> Yeah, my main goal is correctness. For the badly-needed rewrite I was originally planning to create a Bitcoin network client (and I even wrote an almost-complete PHP version of that), but I've now decided that I will continue to use JSON-RPC methods, as this is most likely to be correct.
592 2012-02-17 21:41:16 <theymos> Is Gavin going to release that alert today? I'm excited to see the first-ever alert! :)
593 2012-02-17 21:42:38 <luke-jr> theymos: not the first ever, I think
594 2012-02-17 21:42:44 <luke-jr> there was one for the encryption bug IIRC
595 2012-02-17 21:42:47 <luke-jr> bbl
596 2012-02-17 21:43:16 <theymos> AFAIK there wasn't one for that, though it was planned.
597 2012-02-17 21:45:58 <gmaxwell> I guess I was confused on when we'd be sending the alert, I thought we'd be sending it the 19th.
598 2012-02-17 21:47:14 <theymos> An alert can be sent with bitcoin.org/feb20 still 404. People don't actually need to go to the page until later.
599 2012-02-17 21:48:04 <helo> placeholder "check back later" > 404
600 2012-02-17 21:49:08 <gmaxwell> theymos: we don't want to create a panic.
601 2012-02-17 21:50:05 <jgarzik> luke-jr / theymos: have conceptual ACK for merging 'dumpblock'
602 2012-02-17 21:50:10 <jgarzik> just need someone to code it :)
603 2012-02-17 21:50:34 <jgarzik> i.e. a getblockbyfoo that dumps all block contents, all transactions
604 2012-02-17 21:50:57 <gmaxwell> jgarzik: we _have_ that.
605 2012-02-17 21:51:00 <theymos> Why is that better than getblockbycount?
606 2012-02-17 21:51:04 <gmaxwell> (getblockbyhash)
607 2012-02-17 21:51:14 <jgarzik> gmaxwell: not full dump
608 2012-02-17 21:52:42 <jgarzik> e.g. output like http://blockexplorer.com/rawblock/000000000000062b96609d9afd5a42855772a5c178bafb796eb0dfee7543ddaf
609 2012-02-17 21:53:13 <gmaxwell> K.
610 2012-02-17 22:02:29 <gmaxwell> sipa did you find any <0.2.10 nodes?
611 2012-02-17 22:06:28 <sipa> gmaxwell: one claimed v103, but i do not think it was a satoshi client
612 2012-02-17 22:12:14 <phantomcircuit> sipa, my python bitcoin client claimed that in a very early version i think
613 2012-02-17 22:13:48 <sipa> phantomcircuit: does it also report nBlocks=-1 ?
614 2012-02-17 22:14:23 <phantomcircuit> no
615 2012-02-17 22:14:36 <phantomcircuit> it reported like 95k i think
616 2012-02-17 22:28:51 <sipa> gmaxwell: currently a 0.3.0, a 0.3.14 and a 0.3.15 node on the network
617 2012-02-17 22:30:08 <gmaxwell> http://people.xiph.org/~greg/feb20.txt  < here is what I sketched up earlier for the Feb 20 message, I'd HTMLize and add a world clock link and probably some footnotes.
618 2012-02-17 22:33:26 <BlueMatt> gmaxwell: looks good, do you not want to mention the addrMe issues at all, or are you assuming because we have so little evidence its really not worth mentioning?
619 2012-02-17 22:33:53 <theymos> Looks good and accurate, but maybe put a large tl;dr at the top like "Summary: Nothing is required of your right now. In the unlikely even that something breaks after Feb 20, come back here."
620 2012-02-17 22:33:54 <gmaxwell> BlueMatt: Right. I think it would be confusing to try to explain it when we don't know enough to say much of anything.
621 2012-02-17 22:34:33 <BlueMatt> gmaxwell: fair enough
622 2012-02-17 22:35:03 <sipa> agree with theymos
623 2012-02-17 22:35:13 <gmaxwell> I do too.
624 2012-02-17 22:37:03 <nanotube> gmaxwell: good writeup.
625 2012-02-17 22:38:03 <gmaxwell> BlueMatt: maybe it's worth saying something with, if there is a summary up top. I'll think for a minute on that.
626 2012-02-17 22:38:59 <theymos> After Feb 20 the page should mention that users should check their clocks if they're having problems and come to #bitcoin-dev if that doesn't help.
627 2012-02-17 22:39:23 <BlueMatt> gmaxwell: can be very downplayed like just "there is a small chance that some rare nats will interact negatively with the change, if you experience problems with this, help test the 0.5.3rc: link to forum thread on 0.5.3"
628 2012-02-17 22:41:22 <gmaxwell> yea, with the summary up top I'm willing to add more to it.
629 2012-02-17 22:49:21 <theymos> This "advisory" alert will still appear in the getinfo "errors" field, which is unfortunate because some people have their systems set up to automatically react to the existence of text in that field (a reasonable safety precaution). A "getCriticalAlerts" RPC method would be nice.
630 2012-02-17 23:03:06 <sipa> when will the alert be sent?
631 2012-02-17 23:09:40 <theymos> Gavin said today, but maybe tomorrow if he's not around anymore today.
632 2012-02-17 23:21:03 <Joric> http://www.wired.com/wiredenterprise/2012/02/cloudera-and-apache/all/1 'the percentage of projects using the GPL dropped from 70 percent in June 2008 to about 57 percent today, while the Apache and the MIT ??? another permissive license ??? have risen to 5 and 11 percent respectively'
633 2012-02-17 23:22:23 <splatster> A question for everyone: What's your favorite text editor? (I'm on OS X)
634 2012-02-17 23:22:42 <splatster> (text editor for programming and web design)
635 2012-02-17 23:22:47 <sipa> mcedit
636 2012-02-17 23:22:57 <theymos> I use Vim for writing code and Notepad2 (Windows) for other stuff.
637 2012-02-17 23:23:12 <Diablo-D3> vim
638 2012-02-17 23:23:27 <Diablo-D3> vims even better when you throw in my epic config of epicness
639 2012-02-17 23:24:13 <theymos> The only thing I don't like about Vim is that the copying/pasting doesn't interface with Windows very well.
640 2012-02-17 23:24:53 <splatster> Vim is a pain with copy paste on OS X
641 2012-02-17 23:26:00 <Joric> splatster, /Applications/TextEdit.app/Contents/MacOS/TextEdit
642 2012-02-17 23:26:16 <theymos> I used to use Notepad++ for coding, but constantly switching from keyboard to mouse was hurting my hand.
643 2012-02-17 23:30:07 <gmaxwell> Joric: cade mets is one of the most unethical journalists I've ever had the displeasure of interacting with.
644 2012-02-17 23:31:19 <Joric> gmaxwell, he's the editor of wired now
645 2012-02-17 23:31:45 <nanotube> gmaxwell: what did he do?
646 2012-02-17 23:31:59 <nanotube> Joric: goes to show you, you don't get to positions of power by being ethical. :P
647 2012-02-17 23:32:07 <gmaxwell> Joric: no he isn't, "wired enterprise" one of their blog sections
648 2012-02-17 23:32:17 <Joric> ah sorry
649 2012-02-17 23:32:35 <nanotube> aw, there goes my snarky comment, foundation pulled right from under it.
650 2012-02-17 23:32:39 <nanotube> damn you gmaxwell :)
651 2012-02-17 23:32:44 <gmaxwell> heh
652 2012-02-17 23:39:25 <Joric> thought he wrote that wired article about that site that sells those things for bitcoins but no it was Adrian Chen