1 2011-10-07 03:08:57 <wereHamster> does bitcoind support ipv6?
  2 2011-10-07 03:41:25 <CIA-101> DiabloMiner: Patrick McFarland master * r478623c / src/main/java/com/diablominer/DiabloMiner/DiabloMiner.java : Improve FPS timing to handle slow devices better - http://git.io/YICpUw
  3 2011-10-07 04:52:01 <mizerydearia> heya mmoya.  Check out #bitcoin-es
  4 2011-10-07 05:19:45 <snimpy> ;;bc,diffchange
  5 2011-10-07 05:19:46 <gribble> Estimated percent change in difficulty this period | -8.30056399422 % based on data since last change | -9.1641614174 % based on data for last three days
  6 2011-10-07 05:30:22 <mizerydearia> Would anyone else here be interested to help bootstrap foreign bitcoin channels with some users?  See https://bitcointalk.org/index.php?topic=47057
  7 2011-10-07 05:30:37 <nathan7> Hi mizerydearia
  8 2011-10-07 05:30:40 <mizerydearia> hiya
  9 2011-10-07 05:50:47 <CIA-101> bitcoin: jedi95 * r30f838629811 Phoenix-Miner/: Screwed up with Git big time, had to redo repo.
 10 2011-10-07 05:52:28 <Diablo-D3> jesus christ.
 11 2011-10-07 05:52:32 <Diablo-D3> seriously?
 12 2011-10-07 05:52:37 <Diablo-D3> how the fuck do people fuck up with git
 13 2011-10-07 05:52:40 <Diablo-D3> its almost bullet proof
 14 2011-10-07 06:03:55 <Ycros> bulletproof, luls.
 15 2011-10-07 06:04:19 <Ycros> it'd help if it had a sane UI.
 16 2011-10-07 08:35:42 <Diablo-D3> heh
 17 2011-10-07 08:35:44 <Diablo-D3> hn is down
 18 2011-10-07 08:35:50 <Diablo-D3> but I cant start a hn thread to say hn is down
 19 2011-10-07 08:41:27 <nathan7> lol
 20 2011-10-07 11:04:32 <iGlad> is this our satoshi? http://www.amren.com/mtnews/archives/2011/10/dr_satoshi_kana.php
 21 2011-10-07 11:05:27 <phedny> Nakamoto != Kanazawa
 22 2011-10-07 11:05:43 <iGlad> ooh
 23 2011-10-07 11:05:56 <iGlad> i never knew his last name
 24 2011-10-07 11:06:08 <iGlad> but i thought satoshi was made up
 25 2011-10-07 11:06:13 <sipa> i believe so too
 26 2011-10-07 11:06:29 <iGlad> i didnt think i'd encounter news of someone else called satoshi
 27 2011-10-07 11:07:00 <phedny> if you Google satoshi you may conclude that it must be a common name in Japan
 28 2011-10-07 11:07:15 <sipa> http://en.wikipedia.org/wiki/Ash_Ketchum
 29 2011-10-07 11:07:48 <phedny> Gotta catch 'em all?
 30 2011-10-07 11:09:40 <gmaxwell> iGlad: iirc satoshi is a common name, it's like "john"
 31 2011-10-07 11:10:57 <phedny> gmaxwell: does nakamoto happen to be a common last name, like "doe"?
 32 2011-10-07 11:13:09 <gmaxwell> phedny: yes. kinda.
 33 2011-10-07 11:13:34 <sipa> "satoshi nakamoto" certainly doesn't have the same connotation as "john doe", though
 34 2011-10-07 11:14:26 <gmaxwell> it's more of a name permutation. Though I think japanese names have lower entropy than european or american names generally.
 35 2011-10-07 11:15:39 <gmaxwell> In any case, his relative anonymity has done us all a good service I think.  I've been involved with several projects who have a very centeral founder and they always suffer with the difficulty of growing beyond his vision.
 36 2011-10-07 11:17:37 <sipa> lower entropy per romaji character, or per hiragana character?
 37 2011-10-07 11:18:38 <gmaxwell> sipa: per word.  Well, it's an interesting question that I could answer objectively rather than speculating about, I suppose. :)
 38 2011-10-07 11:18:51 <gmaxwell> But not interesting enough to go find some big name lists.
 39 2011-10-07 12:00:40 <has> hello
 40 2011-10-07 12:31:34 <BlueMatt> gavinandresen: 565c4771b6eba0eeb82f8602735100bbcf4b053e kills build on linux xcompile and probably win32 also, it removes the def of __WXMSW__ from the makefile but its still used in ie headers.h to include things that should be included...
 41 2011-10-07 12:33:47 <gavinandresen> BlueMatt: what is the correct #define?  WX is no more....
 42 2011-10-07 12:35:31 <BlueMatt> WIN32 I think
 43 2011-10-07 12:36:58 <BlueMatt> also, the bitcoin-qt.pro file defines __WXMSW__ if you are removing defines for wx, you could do that as well ;)
 44 2011-10-07 12:41:44 <gavinandresen> Yes, I'll do that.
 45 2011-10-07 12:42:45 <gavinandresen> Does the Makefile have to define WIN32 or is that auto-magically defined when compiling/cross-compiling?
 46 2011-10-07 12:43:06 <sipa> gavinandresen: what isn't finished about the import/export pullreq is walletdump/walletimport, and all the smart things it uses to avoid rescanning unnecessary parts of the block chain
 47 2011-10-07 12:43:37 <sipa> gavinandresen: but importprivkey/dumpprivkey are finished as far as i'm concerned (no known bugs...)
 48 2011-10-07 12:43:52 <BlueMatt> gavinandresen: i think it is currently defined, which is why I said WIN32, but you can define whatever you want
 49 2011-10-07 12:43:56 <sipa> except the potential issue with possible double spend attempts and how the wallet code deals with it
 50 2011-10-07 12:44:01 <BlueMatt> WINDOWS or WIN32 or BITCOIN_WIN32
 51 2011-10-07 12:45:10 <gavinandresen> Looks like WIN32 and _WINDOWS are defined in the makefiles already...
 52 2011-10-07 12:45:49 <gavinandresen> ... except for the qt.pro
 53 2011-10-07 12:47:43 <gavinandresen> hrmm, got __WXMAC_OSX__ too...
 54 2011-10-07 12:50:31 <sipa> gavinandresen: want me to make a pullreq without dumpwallet/importwallet?
 55 2011-10-07 12:51:16 <gavinandresen> sipa: yes, please
 56 2011-10-07 12:57:00 <luke-jr> gavinandresen: there should be a __WIN32__ or somethign
 57 2011-10-07 12:59:39 <gavinandresen> There is already a -DWIN32, I'm going to stick with that.  And rename __WXMAC_OSX__ to -DMAC_OSX
 58 2011-10-07 13:01:15 <luke-jr> yawn
 59 2011-10-07 13:02:13 <wumpus> is WIN32 correct though?
 60 2011-10-07 13:02:19 <wumpus> should there be WIN64 too?
 61 2011-10-07 13:04:18 <CIA-101> bitcoin: Gavin Andresen master * r6853e62 / (13 files in 2 dirs):
 62 2011-10-07 13:04:47 <gavinandresen> No, we don't compile 64-bit windows, there's no reason to.
 63 2011-10-07 13:05:16 <sipa> we don't - maybe someone else does? :)
 64 2011-10-07 13:05:18 <wumpus> yes but someone might want to do it
 65 2011-10-07 13:05:30 <wumpus> but my question was because WIN32 implies 32 bit.. WINDOWS is more generic
 66 2011-10-07 13:05:40 <sipa> i don't think the source tree should just accomodate the builds we do ourselves
 67 2011-10-07 13:05:54 <CIA-101> bitcoin: Luke Dashjr 0.4.x * r65ba3e2f5024 bitcoind-stable/src/net.cpp: Bugfix: report error creating ThreadSocketHandler thread just like the rest
 68 2011-10-07 13:05:55 <CIA-101> bitcoin: Luke Dashjr 0.4.x * r030d7acf7d7b bitcoind-stable/src/net.cpp: Merge commit '65ba3e2f5024e1e38e119a0c25d5fc30c896cd65' into 0.4.x
 69 2011-10-07 13:05:56 <gavinandresen> So somebody else can go through the code and every place it says #ifdef WIN32 they can figure out whether that should be #ifdef _WINDOWS or #ifdef WIN32 or #ifdef WIN64 or.....
 70 2011-10-07 13:05:57 <CIA-101> bitcoin: Victor Leschuk 0.4.x * r600dc6255971 bitcoind-stable/src/util.h: Fix for 64bit build
 71 2011-10-07 13:06:12 <wumpus> it might build with win64 with win32 set though :-)
 72 2011-10-07 13:06:49 <gavinandresen> building win64 is Officially Unsupported until somebody steps up and says "I'm a windows expert, and I'm going to support it!"
 73 2011-10-07 13:07:05 <gavinandresen> even then, there's no reason to ship win64 binaries.
 74 2011-10-07 13:07:33 <wumpus> I don't think so either, unless processor manufacturers plan on deprecating 32 bit mode some day
 75 2011-10-07 13:08:24 <wumpus> but that's not an issue now
 76 2011-10-07 13:11:12 <gmaxwell> gavinandresen: well, at the current rate of blockchain growth 32 bit systems will run out of virtual memory in about 480 days. (probably eariler due to not all 2g of userspace vm being available and chain growth acceleration)
 77 2011-10-07 13:11:31 <sipa> the block chain isn't loaded into memory?
 78 2011-10-07 13:11:37 <gmaxwell> It's mmaped.
 79 2011-10-07 13:11:41 <sipa> oh, really
 80 2011-10-07 13:11:57 <gavinandresen> Really?  I didn't think so...
 81 2011-10-07 13:12:09 <gmaxwell> Oh, I thought it was, perhaps I'm stupid.
 82 2011-10-07 13:12:13 <gmaxwell> Stupid is always possible.
 83 2011-10-07 13:12:39 <gmaxwell> If its not then bitcoin has some serious virtual memory bloat.
 84 2011-10-07 13:12:40 <gavinandresen> I'm 99% sure it is not-- plain old file operations used to seek/read
 85 2011-10-07 13:12:57 <gmaxwell> okay, then ignore me, but I wonder where the VM bloat comes from?
 86 2011-10-07 13:13:03 <gavinandresen> ... and Satoshi keeps the blk000n.dat files under 4gig
 87 2011-10-07 13:13:10 <sipa> under 1 gig even
 88 2011-10-07 13:13:15 <sipa> *at
 89 2011-10-07 13:13:49 <gavinandresen> (I was thinking the other day that mmaping the blk000n.dat file would be a good optimization....)
 90 2011-10-07 13:14:29 <gmaxwell> ha. It would be except for that VM issue. :) I'd just seen the large VM use bit bitcoin and assumed it was doing that it's sort of the obvious thing to do.
 91 2011-10-07 13:24:05 <wumpus> I don't think we should be doing mmapping in bitcoin itself, it is fraught with issues, especially in 32 bit... let the database lib do it for you
 92 2011-10-07 13:24:51 <sipa> the block chain file is no databasr
 93 2011-10-07 13:24:56 <sipa> database
 94 2011-10-07 13:25:26 <gmaxwell> Besides, it's not like it should be much of a database. It's a pretty simple data structure.
 95 2011-10-07 13:27:34 <gmaxwell> jrmithdobbs had been working on some software that stored blocks in files e.g. blocks/xx/yy/zzzzzzz which has its attractiveness and limitations.
 96 2011-10-07 13:27:34 <sipa> well, if we want to do pruning it does need to be more than that
 97 2011-10-07 13:27:35 <gavinandresen> sipa: has removeprivkey been thoroughly tested?  Seems like there are a lot of possible edge-cases with it...
 98 2011-10-07 13:27:39 <gavinandresen> (I agree with TD, disk space is cheap, pruning for full nodes doesn't make sense)
 99 2011-10-07 13:27:40 <BlueMatt> yay, bitcoin-qt built now when you try to open it I get an empty error popup and then it exits...and nothing in debug.log
100 2011-10-07 13:27:42 <sipa> gavinandresen: it's conceptually simple enough: remove the key, and drop anything in the wallet that is neither from or to us anymore
101 2011-10-07 13:27:57 <sipa> but it could use more testing, yes
102 2011-10-07 13:29:07 <gavinandresen> sipa:  so if I sendfrom "account" <to somebody> amount confirmations "Payment to blah" ... and then removeprivkey the key that happened to receive the funds that funded that sendfrom...  the wtx with the payment comment will go away?
103 2011-10-07 13:29:38 <sipa> yes, and the account balance should go negative
104 2011-10-07 13:30:40 <sipa> ah, the payment itself goes away as well of course
105 2011-10-07 13:31:15 <sipa> so, yes, the comment gets lost
106 2011-10-07 13:31:50 <sipa> it isn't "we" anymore that did that payment
107 2011-10-07 13:32:06 <gavinandresen> The payment going away and the account that 'owned' the private key going negative is OK.  But the fact that a payment happened getting lost could cause major problems for a service that uses the comment field to tie bitcoin transactions to transactions in some other database.
108 2011-10-07 13:33:10 <sipa> agree, but i don't see any other reasonable semantics
109 2011-10-07 13:33:30 <gavinandresen> what is the use case for removeprivkey?
110 2011-10-07 13:33:42 <gavinandresen> (besides "I want to remove a private key from my wallet")
111 2011-10-07 13:33:51 <sipa> moving coins to another wallet
112 2011-10-07 13:34:01 <gavinandresen> ... that's what send* is for....
113 2011-10-07 13:34:12 <gmaxwell> In particular being sure you don't double spend a key you just gave to someone else.
114 2011-10-07 13:34:19 <gmaxwell> (via export)
115 2011-10-07 13:35:44 <sipa> note that it takes a privkey and not an address as argument
116 2011-10-07 13:35:46 <luke-jr> adhoc bug report via IRC: bitcoind's test JSON-RPC client doesn't work with -testnet anymore
117 2011-10-07 13:36:14 <sipa> so you can't delete a key without knowing the privkey
118 2011-10-07 13:37:11 <gavinandresen> sipa: I'm worried that online services will shoot themselves in the foot by deciding it is a good idea to delete 'old' private keys, and not figuring out that screws up accounts
119 2011-10-07 13:37:48 <gavinandresen> luke-jr:   what is the 'test JSON-RPC client' ????
120 2011-10-07 13:37:55 <luke-jr> gavinandresen: ./bitcoind getinfo
121 2011-10-07 13:38:24 <luke-jr> gavinandresen: it used to read/use .bitcoin/testnet/bitcoin.conf if you passed -testnet
122 2011-10-07 13:43:52 <gavinandresen> luke-jr:  it has always read .bitcoin/bitcoin.conf for both testnet and regular net.
123 2011-10-07 13:43:55 <gavinandresen> (I actually coded it the other way and Satoshi changed it before committing the first testnet changes)
124 2011-10-07 13:43:57 <gavinandresen> (sigh)
125 2011-10-07 13:43:58 <gavinandresen> sipa: possible alternative semantics:  refuse to remove a private key if doing so would change some unrelated account's balance or remove a send* transaction from that key
126 2011-10-07 13:50:01 <gavinandresen> Here's the scenario I worry about:   some shared wallet provider notices their wallet.dat is getting big, and takes a while to load when they restart bitcoin.
127 2011-10-07 13:50:38 <gavinandresen> So they decide it would be a good idea to get all the spent 'change' addresses and remove them from their wallet.
128 2011-10-07 13:51:31 <gavinandresen> They run their script, relaunch their service... and then have a heart attack when all of their customers' account balances are screwy
129 2011-10-07 13:51:56 <gavinandresen> I suppose we could say "don't do that".  Or "they can just restore from backup."
130 2011-10-07 13:55:25 <lianj> shared wallet provider sounds scary anw
131 2011-10-07 13:55:57 <gavinandresen> Any service that lets you deposit bitcoins and then spend them is a shared wallet provider
132 2011-10-07 13:56:51 <gavinandresen> ... and they are scary, because you have to trust that they won't run off with your bitcoins.
133 2011-10-07 13:58:19 <gavinandresen> Anybody else concerned, or am I just being irrationally cranky?
134 2011-10-07 13:58:55 <diki> gavinandresen:i'd like to ask, when using the -proxy switch, does bitcoind still listen on the local 8332 port?
135 2011-10-07 13:59:02 <UukGoblin> about micromanaging addresses in a wallet? I think we should allow it in an "advanced" view
136 2011-10-07 13:59:39 <sipa> gavinandresen: would a warning in the RPC helptext "Warning: this will chance credits and debits of related transactions, remove irrelevant transactions from the wallet, and change balances of affected accounts." ?
137 2011-10-07 14:00:28 <sipa> i agree that there a definite risks for people shooting themselves in the foot
138 2011-10-07 14:00:31 <gavinandresen> sipa: yes, a Use With Extreme Caution warning in the RPC help would be good
139 2011-10-07 14:00:59 <gavinandresen> diki: do you mean the 8333 bitcoin-protocol port?  8332 is RPC...
140 2011-10-07 14:01:11 <sipa> but there is definitely a use for this (see the long discussion on the forum thread about it), and the popularity of pywallet
141 2011-10-07 14:01:57 <diki> gavinandresen:listen on port 8332 but relay through proxy?
142 2011-10-07 14:02:46 <gavinandresen> diki: I don't recall off the top of my head, I'd have to read the code.
143 2011-10-07 14:06:03 <gavinandresen> sipa:  RE: the message:  I think it could change the balances of unrelated accounts
144 2011-10-07 14:07:55 <luke-jr> sipa: how about returning a list of the effects "Decreased balance by N", etc, as well as a final copy of the privkey
145 2011-10-07 14:08:05 <luke-jr> sipa: then when they go OMG WTF DID I DO, they can easily import
146 2011-10-07 14:08:06 <sipa> gavinandresen: agree
147 2011-10-07 14:08:20 <sipa> luke-jr: at that point the transaction messages are lost
148 2011-10-07 14:08:27 <luke-jr> ?
149 2011-10-07 14:08:30 <sipa> if i remove the key corresponding to address X, the account that address is labelled as will lose its credits, and all accounts payments were made from using those coins will lose their debits
150 2011-10-07 14:08:52 <sipa> luke-jr: the comments about that transaction
151 2011-10-07 14:08:59 <luke-jr> oh
152 2011-10-07 14:09:04 <gavinandresen> sipa: maybe removeprivkey could dump out all the transactions affected by the removal,along with comments/etc
153 2011-10-07 14:09:15 <gavinandresen> ... so you would SEE what got affected
154 2011-10-07 14:09:35 <sipa> in that case there should be a way to do so in a "dry run" fashion
155 2011-10-07 14:09:42 <gavinandresen> good idea
156 2011-10-07 14:09:42 <luke-jr> sounds like removeprivkey should MOVE the pubkey from "active" to "past" with a timestamp :p
157 2011-10-07 14:09:50 <luke-jr> so it can log the debits
158 2011-10-07 14:10:01 <luke-jr> of course, that makes it complex
159 2011-10-07 14:10:16 <luke-jr> and import shouldn't show debits probably :|
160 2011-10-07 14:10:29 <sipa> gavinandresen: another possbility is first implementing the "watched addresses" feature (for which no actual private key is available in the wallet)
161 2011-10-07 14:10:45 <sipa> and have removeprivkey change a key from available to unavailable, leaving all transactions intact
162 2011-10-07 14:11:36 <diki> why would someone remove a private key?
163 2011-10-07 14:11:52 <sipa> diki: because i gave it to you, and don't want to accidentally spend its funds
164 2011-10-07 14:13:10 <gavinandresen> I just got 400 trillion dollars in the mail!   They're Zimbabwe dollars, but still, pretty cool!
165 2011-10-07 14:13:29 <diki> time to pay america's debt then :D
166 2011-10-07 14:13:44 <BlueMatt> what are they actually worth?
167 2011-10-07 14:13:50 <BlueMatt> also...why?
168 2011-10-07 14:13:50 <diki> 0.01 bitcoins
169 2011-10-07 14:14:16 <luke-jr> sipa: but if you remove the key, you probably don't want to see *future* txns either
170 2011-10-07 14:14:23 <sipa> luke-jr: agree
171 2011-10-07 14:14:30 <jrmithdobbs> gmaxwell: oh i never started working on that, i've done it for other projects though
172 2011-10-07 14:14:39 <jrmithdobbs> gmaxwell: never started working on it for bitcoin, i mean
173 2011-10-07 14:14:52 <luke-jr> sipa: otoh, importers MIGHT want to see history
174 2011-10-07 14:15:29 <diki> jrmithdobbs:what are u doing here?
175 2011-10-07 14:20:06 <jrmithdobbs> diki: what
176 2011-10-07 14:21:25 <sipa> what is probably the best behaviour is 1) removing the key 2) not seeing any future transactions 3) leave all existing transactions in place 4) book virtual "key removed" transaction for all remaining credits from that key
177 2011-10-07 14:22:05 <sipa> that would be major change to the wallet system, and probably overkill for the intended use case
178 2011-10-07 14:22:21 <sipa> the intended use case being "the key is not mine anymore"
179 2011-10-07 14:52:31 <freewil> in the rpc call sendfrom what is the purpose for the minconf param
180 2011-10-07 15:00:01 <phantomcircuit> gavinandresen, the default minconf is 6 right
181 2011-10-07 15:00:20 <jrmithdobbs> diki: what did you mean why am i here?
182 2011-10-07 15:00:27 <jrmithdobbs> phantomcircuit: 5
183 2011-10-07 15:00:32 <gavinandresen> phantomcircuit: default minconf for all the RPC commands is 1
184 2011-10-07 15:00:34 <jrmithdobbs> phantomcircuit: cause the block it's in doesn't count iirc (please correct me could be misremembering)
185 2011-10-07 15:01:05 <freewil> i am looking at the sendfrom function on 0.3.24 and it defaults to 1
186 2011-10-07 15:01:21 <freewil> so it calls getAccountBalance with nMinDepth 1
187 2011-10-07 15:01:40 <freewil> GetAccountBalance(strAccount, nMinDepth);
188 2011-10-07 15:10:12 <upb> [A
189 2011-10-07 15:10:14 <upb> [A
190 2011-10-07 15:12:18 <phantomcircuit> gavinandresen, interesting
191 2011-10-07 15:13:25 <gavinandresen> phantomcircuit: ... if I could go back in time I think I'd change the default to '3' ...  maybe not a bad idea to change it now...
192 2011-10-07 15:16:07 <jrmithdobbs> why 3?
193 2011-10-07 15:17:30 <freewil> seems like 6 has become the pseudo-standard
194 2011-10-07 15:21:46 <luke-jr> gavinandresen: Spesmilo uses 3 stages
195 2011-10-07 15:22:08 <luke-jr> 0-2 is validating; 3-6 is processing; 7+ is confirmed
196 2011-10-07 15:22:23 <freewil> what is Spesmilo
197 2011-10-07 15:22:41 <jrmithdobbs> freewil: a gui that just calls bitcoind rpc
198 2011-10-07 15:22:47 <gavinandresen> 3 is a magic number. Yes it is.  It's a magic number.
199 2011-10-07 15:23:46 <gavinandresen> http://www.youtube.com/watch?v=yPzAjiLr5Zw
200 2011-10-07 15:25:23 <phantomcircuit> lol
201 2011-10-07 15:25:25 <freewil> does bitcoin and bitcoind interact with each other as separate processes or do they just share the same library
202 2011-10-07 15:26:25 <jrmithdobbs> freewil: they are the same binary
203 2011-10-07 15:27:41 <freewil> jrmithdobbs, so is it possible to run the rpc server with the gui
204 2011-10-07 15:27:47 <jrmithdobbs> yes
205 2011-10-07 15:27:54 <BlueMatt> bitcoin.exe -server
206 2011-10-07 15:28:35 <freewil> so the only difference is that bitcoind doesnt launch the gui?
207 2011-10-07 15:28:51 <BlueMatt> mostly that gui isnt linked
208 2011-10-07 15:29:11 <freewil> hm good to know
209 2011-10-07 15:49:32 <luke-jr> What is wrong with this block? :/ http://paste.pocoo.org/show/489033/
210 2011-10-07 15:51:14 <luke-jr> ProcessMessage(block, 166 bytes) : Exception 'ReadCompactSize() : size too large' caught
211 2011-10-07 15:51:16 <luke-jr> ProcessMessage(block, 166 bytes) FAILED
212 2011-10-07 15:51:17 <luke-jr> PROCESSMESSAGE SKIPPED 4 BYTES
213 2011-10-07 16:27:34 <BlueMattBot> Project Bitcoin build #61: FAILURE in 22 min: http://jenkins.bluematt.me/job/Bitcoin/61/
214 2011-10-07 16:28:06 <BlueMatt> arg wtf
215 2011-10-07 16:28:29 <BlueMatt> hmmm...might not by my fault this time...
216 2011-10-07 16:32:42 <luke-jr> BlueMatt: looks like it's trying to build wxBitcoin
217 2011-10-07 16:33:04 <BlueMatt> its just calling make -f makefile.linux-mingw in other words it would be a bug in the makefile
218 2011-10-07 16:34:38 <gavinandresen> bug in the makefile
219 2011-10-07 16:34:58 <gavinandresen> need to remove obj/ui_res.o from the dependencies
220 2011-10-07 16:35:15 <BlueMatt> yep
221 2011-10-07 16:35:28 <luke-jr> argh
222 2011-10-07 16:35:34 <luke-jr> C++ makes debugging impossible -.-
223 2011-10-07 16:35:43 <CIA-101> bitcoin: Gavin Andresen  * rc1131a2 / (src/makefile.linux-mingw src/makefile.mingw): Remove ui_res from makefiles - http://git.io/bu2nVA
224 2011-10-07 16:35:52 <BlueMatt> and boost makes it worse (didnt even think it was possible...)
225 2011-10-07 16:36:33 <luke-jr> so how can I figure out why bitcoind is barfing on the block data?
226 2011-10-07 16:36:47 <luke-jr> manual deconstruction seems ok
227 2011-10-07 16:36:50 <BlueMatt> a lot of fprintf(stderr, ...)s
228 2011-10-07 16:37:02 <luke-jr> x.x
229 2011-10-07 16:37:07 <luke-jr> and waiting for it to stop/start
230 2011-10-07 16:37:28 <gavinandresen> why can't you put a breakpoint in ProcessBlock and step through?
231 2011-10-07 16:37:53 <luke-jr> it never gets to ProcessBlock
232 2011-10-07 16:37:54 <gavinandresen> (err, ProcessMessage, the 'block' case...)
233 2011-10-07 16:38:04 <BlueMatt> then your breakpoint is too late
234 2011-10-07 16:38:14 <luke-jr> gavinandresen: gdb can't step into templates
235 2011-10-07 16:38:29 <luke-jr> vRecv >> block; <-- last gdb-able line
236 2011-10-07 16:38:49 <luke-jr> BlueMatt: where would I even put the printfs? :/
237 2011-10-07 16:39:05 <BlueMatt> well thats the other problem...
238 2011-10-07 16:39:07 <gavinandresen> break before then, then add a breakpoint in ReadCompactSize
239 2011-10-07 16:39:18 <luke-jr> gavinandresen: that's templated. gdb can't handle it at all.
240 2011-10-07 16:39:19 <gavinandresen> ... and see what bytes it is getting.
241 2011-10-07 16:39:33 <phantomcircuit> well it kind of can
242 2011-10-07 16:39:40 <phantomcircuit> you just have to decode the function name first
243 2011-10-07 16:39:42 <phantomcircuit> good luck with that
244 2011-10-07 16:40:44 <luke-jr> sure, I can set a breakpoint with the decoded func name
245 2011-10-07 16:40:49 <luke-jr> but gdb still won't show me the lines
246 2011-10-07 16:40:53 <luke-jr> or let me step in it
247 2011-10-07 16:41:34 <gavinandresen> I agree, C++ sucks for debugging.  And compiler error messages, too....
248 2011-10-07 16:42:06 <gavinandresen> Or maybe:  every implementation of C++ I've ever used has sucked for debugging and error messages.....
249 2011-10-07 16:55:07 <phantomcircuit> luke-jr, yeah you can do it... if you strip debug symbols
250 2011-10-07 16:55:09 <phantomcircuit> fun right
251 2011-10-07 16:55:11 <gmaxwell> gavinandresen: the STL means that every C++ program is full of complicated meta-programming, I think providing good error messages is fundimentally hard in that context.
252 2011-10-07 17:02:16 <BlueMattBot> Yippie, build fixed!
253 2011-10-07 17:02:17 <BlueMattBot> gavinandresen: Remove ui_res from makefiles
254 2011-10-07 17:52:35 <iddo> can someone explain the time travel issue, why telling other nodes a wrong timestamp on block you generated gives you advantage for an attack? https://bitcointalk.org/index.php?topic=42417.msg517020#msg517020
255 2011-10-07 17:54:44 <phantomcircuit> iddo, because you can convince half the network the block is valid and the other half that it's invalid
256 2011-10-07 17:55:04 <phantomcircuit> if you can maintain that long enough you will be able to double spend
257 2011-10-07 17:56:21 <iddo> are you sure that double-spending was the objective here? i thought it managed to generate more new blocks compared to other miners?
258 2011-10-07 17:56:47 <luke-jr> ProcessBlock: ACCEPTED]
259 2011-10-07 17:57:37 <phantomcircuit> iddo, no it's a double spend attack
260 2011-10-07 17:57:48 <phantomcircuit> iddo, i guess you can also do funny stuff
261 2011-10-07 17:59:34 <iddo> why did you say half the network thinks the block is valid? you broadcast two different timestamps for the block you generated?
262 2011-10-07 17:59:46 <luke-jr> impossible
263 2011-10-07 18:00:22 <iddo> ah the timestamp is part of the data signed with sha256
264 2011-10-07 18:01:34 <iddo> so i still don't understand what advantage it gives you for an attack
265 2011-10-07 18:02:27 <jrmithdobbs> you can do some other non-double-spend stuff with it
266 2011-10-07 18:03:44 <iddo> i fail to understand neither how you double-spend nor whatever else you can do
267 2011-10-07 18:04:41 <phantomcircuit> iddo, you move the "network time" for half hte network up
268 2011-10-07 18:04:48 <phantomcircuit> and the "network time" for the other half down
269 2011-10-07 18:04:54 <phantomcircuit> then you generate a block in the middle
270 2011-10-07 18:05:04 <phantomcircuit> shazam you've split the network because of the hard limits
271 2011-10-07 18:05:30 <iddo> how do you move only half the network?
272 2011-10-07 18:07:46 <jrmithdobbs> by handing out bogus times to nodes
273 2011-10-07 18:07:56 <jrmithdobbs> that are just under the 2h limit
274 2011-10-07 18:08:03 <jrmithdobbs> pretty straightforward
275 2011-10-07 18:08:38 <iddo> but the nodes broadcast your block to other nodes, so why does it affect only half the network and not the entire network?
276 2011-10-07 18:09:02 <jrmithdobbs> because you split half the network up the other half down
277 2011-10-07 18:09:03 <iddo> hmm what is the 2h limit ?
278 2011-10-07 18:09:11 <jrmithdobbs> hardcoded magic number
279 2011-10-07 18:10:00 <lianj> ?
280 2011-10-07 18:10:25 <iddo> split how? you broadcast a timestamp that half of nodes will accept when it reaches them, and other half will reject because it reached too late?
281 2011-10-07 18:10:25 <lianj> oh nevermind..
282 2011-10-07 18:11:44 <lianj> broadcast timestamp still means broadcast valid blocks with these timestamps in them right?
283 2011-10-07 18:12:25 <luke-jr> no
284 2011-10-07 18:13:27 <lianj> how can you just broadcast timestamps and why would other nodes care about them
285 2011-10-07 19:17:38 <smart990_> hello
286 2011-10-07 23:01:05 <diki> wow
287 2011-10-07 23:01:18 <diki> i am using phoenix with rollntime mod and efficiency is nice
288 2011-10-07 23:01:28 <diki> 70 shares for 8 getworks
289 2011-10-07 23:37:56 <diki> the efficiency is just too blinding
290 2011-10-07 23:38:06 <diki> 274 shares yet just 27 getworks