1 2011-10-10 02:15:14 <CIA-101> bitcoin: imsaguy * redf3af2b6665 supybot-bitcoin-marketmonitor/GPG/plugin.py: Removed quotes to match all the other responses.
  2 2011-10-10 02:15:15 <CIA-101> bitcoin: imsaguy * r5d55dbbec2fd supybot-bitcoin-marketmonitor/GPG/helperscripts/bitcoin-otc-gpg-eauth-mirc.mrc: New version of the mIRC helper script. It has been almost entirely rewritten.
  3 2011-10-10 02:15:16 <CIA-101> bitcoin: nanotube * r10ee11ed84f5 supybot-bitcoin-marketmonitor/GPG/ (helperscripts/bitcoin-otc-gpg-eauth-mirc.mrc plugin.py): Merge pull request #20 from imsaguy/master
  4 2011-10-10 02:35:15 <CIA-101> bitcoin: Daniel Folkinshteyn * r4cbdba41548a supybot-bitcoin-marketmonitor/GPG/plugin.py: GPG: fix error in nested ident when target user was not identified.
  5 2011-10-10 03:20:14 <orange-hand> Hi
  6 2011-10-10 03:20:27 <orange-hand> What prevents the following attack:
  7 2011-10-10 03:20:51 <orange-hand> someone adds a huge amount of mining power for a short while
  8 2011-10-10 03:21:01 <orange-hand> and when the hardness resets, they stop mining
  9 2011-10-10 03:21:18 <orange-hand> thus transactions will occur very slowly for a long period of time
 10 2011-10-10 03:21:22 <nanotube> orange-hand: the fact that it'd cost a crapload of money to do that to the bitcoin network
 11 2011-10-10 03:21:36 <orange-hand> can't a botnet do that?
 12 2011-10-10 03:21:39 <gmaxwell> The most the difficulty can change in one cycle is 4x.
 13 2011-10-10 03:21:52 <gmaxwell> No, not botnets that exist today.
 14 2011-10-10 03:22:00 <orange-hand> ok
 15 2011-10-10 03:22:09 <orange-hand> ty
 16 2011-10-10 03:22:26 <orange-hand> or if someone hijacked the amazon cloud :D
 17 2011-10-10 03:22:33 <gmaxwell> Again, not useful.
 18 2011-10-10 03:22:33 <orange-hand> just for a short period of time
 19 2011-10-10 03:23:35 <gmaxwell> Overall bitcoin hashpower right now is equal to around a million high end quad core cpus.
 20 2011-10-10 03:23:59 <nanotube> well, if someone like google/amazon/government wanted to grief bitcoin, maybe they could :)
 21 2011-10-10 03:24:14 <nanotube> (i.e., not with a profit motive, but with a motive to spend resources just to screw with bitcoin)
 22 2011-10-10 03:24:26 <gmaxwell> But again, in one difficulty cycle it will only change by up to 4x.
 23 2011-10-10 03:24:38 <nanotube> they'd have to do it for several cycles
 24 2011-10-10 03:25:00 <nanotube> and of course, if they wanted to grief, and have enough hash power to raise diff by many times... they can do better things
 25 2011-10-10 03:25:01 <orange-hand> even 4x would make transactions mighty slow
 26 2011-10-10 03:25:03 <gmaxwell> Well, and have the expoentially greater computing power required to do that.
 27 2011-10-10 03:25:04 <nanotube> (like prevent tx conf)
 28 2011-10-10 03:28:09 <gmaxwell> orange-hand: moving it to 4x in a half week using the current cheapest option would cost about ~20 million dollars. If you want to spend 20 million to screw with bitcoin you could do so more effectively (and lawfully) with TV ads.
 29 2011-10-10 03:28:57 <nanotube> heh i'm not so sure... having tv ads about bitcoin, even if they're negative ads, would probably have the effect of increasing bitcoin awareness, more than anything else :P
 30 2011-10-10 03:29:41 <gmaxwell> I'm skeptical that the computing power actually exist under any single parties control to do it even in that timeframe.  Thats certantly more computing power than google is claimed to have.
 31 2011-10-10 03:30:01 <nanotube> nsa
 32 2011-10-10 03:30:03 <nanotube> maybe :)
 33 2011-10-10 03:30:16 <gmaxwell> Yea, if they have an FPGA farm with fpgas which are big enough.
 34 2011-10-10 03:30:35 <gmaxwell> I'm actually skeptical that they do though they will probably within a few years if they don't currently.
 35 2011-10-10 03:30:41 <nanotube> well, they can just take their gpu farms that they use to crack other encryption
 36 2011-10-10 03:30:48 <nanotube> and put them to use mining bitcoin for a week
 37 2011-10-10 03:31:05 <nanotube> if they can swallow the opportunity cost
 38 2011-10-10 03:31:16 <gmaxwell> IIRC they have big fpga farms for that, thats why intel has a fab in new jersey (nsa doesn't want parts fabbed outside of the US)
 39 2011-10-10 03:31:36 <AlexWaters> IMO if someone can create a 5-10s bitcoin POS at a processing rate lower than 2% - Bitcoin would explode
 40 2011-10-10 03:31:38 <nanotube> smart, that
 41 2011-10-10 03:31:59 <AlexWaters> and that would be the most cost-effective way to increase the price =P
 42 2011-10-10 03:32:25 <nanotube> yes that'd help, and i think bit-pay and btcinch are working on those
 43 2011-10-10 03:32:26 <gmaxwell> AlexWaters: increasing the price is subject matter for #btc-value not #bitcoin-dev. :)
 44 2011-10-10 03:33:58 <AlexWaters> gmaxwell: my bad - wrong channel =0
 45 2011-10-10 03:35:43 <nanotube> gmaxwell: well, it's about the development of pos, hence -dev :P
 46 2011-10-10 03:37:42 <ThomasV> what is wrong with current POS solutions?
 47 2011-10-10 03:38:31 <gmaxwell> Thats fine, but I really don't like the distraction of "omg drive up bitcoin price" good development is good development.
 48 2011-10-10 03:39:12 <ThomasV> omg! a squirrel!!
 49 2011-10-10 03:40:59 <ThomasV> I, mean, for POS, you don't really have to fear double spend attacks; someone with enough resources to attempt it would not do it for small change
 50 2011-10-10 03:42:26 <nanotube> gmaxwell: yea i know, just felt like throwing that out there :D
 51 2011-10-10 03:42:50 <nanotube> ThomasV: indeed, monitoring something like transactionradar should be plenty good enough.
 52 2011-10-10 03:43:33 <gmaxwell> ThomasV: a zero confirm double spend doesn't take any resouces.
 53 2011-10-10 03:43:51 <ThomasV> indeed, but it would be visible
 54 2011-10-10 03:44:09 <nanotube> well, it takes /some/, if you want to have a reasonable chance of controlling which of the spends is more likely to be mined.
 55 2011-10-10 03:44:38 <nanotube> iow, the merchant's node has to receive the 'tx to merchant' while 'all other nodes or as many as possible' receive the doublespend tx
 56 2011-10-10 03:45:35 <nanotube> so you need to at least have some infrastructure, and to do some homework to locate merchant's node
 57 2011-10-10 03:45:37 <gmaxwell> nanotube: It doesn't have to be successful every time I could easily make a script that every time I make a payment, it makes a conflicting payment and announces it 1 second later far away in the network.
 58 2011-10-10 03:45:52 <ThomasV> most importantly, the merchant's node has to not receive the 2nd spend
 59 2011-10-10 03:46:11 <gmaxwell> It won't because the first spend will make it deaf.
 60 2011-10-10 03:46:19 <nanotube> gmaxwell: true, so you can end up not paying for 1 out of 100 bagels you buy. whopdeedoo. :)
 61 2011-10-10 03:46:40 <ThomasV> gmaxwell: will make it deaf? why?
 62 2011-10-10 03:46:57 <nanotube> the default client ignores conflicting tx. it only accepts first it sees.
 63 2011-10-10 03:47:01 <nanotube> ThomasV: ^
 64 2011-10-10 03:47:02 <gmaxwell> ThomasV: because nodes never forward conflicting transactions.
 65 2011-10-10 03:47:42 <gmaxwell> So e.g. I give merchant TX1, he gives it to his peers.. in the meantime I shoot it straight to a couple pool after a slight delay.
 66 2011-10-10 03:47:59 <gmaxwell> er s/it/TX2/
 67 2011-10-10 03:48:05 <gmaxwell> (the second it)
 68 2011-10-10 03:48:22 <ThomasV> hmm, isn't that a weakness? I mean, they could forward it with the mention that it is conflicting, "for information"
 69 2011-10-10 03:48:54 <gmaxwell> Makes it trivial to dos a network by just generating endless conflicting txn.
 70 2011-10-10 03:49:23 <ThomasV> hmm, you are right
 71 2011-10-10 03:49:34 <gmaxwell> Well, it can be solved. I posted about this someplace.
 72 2011-10-10 03:49:49 <ThomasV> gmaxwell: how about allowing only one conflicting tx per private key?
 73 2011-10-10 03:50:17 <gmaxwell> Basically it would be possible to make a "conflict notice" for each conflicted input. And you ship an example conflict with it to prove that it's a real conflict.
 74 2011-10-10 03:50:33 <ThomasV> yes, exactly
 75 2011-10-10 03:51:00 <gmaxwell> Yea. There are some corner cases that you have to cope with... but it can be done.
 76 2011-10-10 03:51:00 <ThomasV> that's actually how I thought it worked :-D
 77 2011-10-10 03:51:27 <nanotube> or just have third-party services providing that info (a la txradar)
 78 2011-10-10 03:51:47 <nanotube> if the guy can 'hook up' with some major mining pools, that'd be even better
 79 2011-10-10 03:52:36 <ThomasV> oh I did not know txradar
 80 2011-10-10 03:53:58 <ThomasV> maybe that's a solution, although not a decentralized one
 81 2011-10-10 03:54:45 <gmaxwell> well, we ultimately should have both.
 82 2011-10-10 03:55:07 <gmaxwell> txradar like service will be cheaper and more effective with conflict forwarding.
 83 2011-10-10 03:55:22 <nanotube> mm
 84 2011-10-10 03:55:41 <nanotube> maybe you should write up a BEP (or whatever they decided to call the proposals) :)
 85 2011-10-10 03:56:46 <gmaxwell> It wasn't mostly my proposal, someone else was pushing it. (I think I just commented about how you can solve the DOS problem)
 86 2011-10-10 03:56:52 <ThomasV> gmaxwell said he posted about it somewhere
 87 2011-10-10 03:57:24 <gmaxwell> I'm not sure what miners should do when they hear a conflict.
 88 2011-10-10 03:57:35 <ThomasV> what was your solution for DOS ?
 89 2011-10-10 03:57:41 <gmaxwell> Ideally you'd want all miners to pick the same txn and everyone else to know which they picked.
 90 2011-10-10 03:58:01 <ThomasV> maybe miners would pick the highest fee :-)
 91 2011-10-10 03:58:15 <gmaxwell> Yes, that much is obvious, and what about when its the same?
 92 2011-10-10 03:58:45 <ThomasV> what they do now
 93 2011-10-10 03:58:53 <ThomasV> chronology
 94 2011-10-10 03:58:56 <gmaxwell> Well, heard first doesn't help here..
 95 2011-10-10 03:59:11 <gmaxwell> because you don't want bot txn getting mined by different miners.
 96 2011-10-10 03:59:14 <gmaxwell> s/bot/both/
 97 2011-10-10 03:59:23 <ThomasV> isn't it what they do now?
 98 2011-10-10 03:59:42 <gmaxwell> Yes, but it's not ideal in the case of conflicts.
 99 2011-10-10 03:59:58 <gmaxwell> It means that even if the whole network hears of the conflict you might see 1 confirm that eventually goes away.
100 2011-10-10 04:00:32 <gmaxwell> Ideally all miners would pick the same one when they're aware of a conflict the risk of going 1 confirm that goes away is reduced.
101 2011-10-10 04:01:05 <ThomasV> but broadcasting a conflict notice is not bloadcasting a tx ; I don't see why you also want to change the current protocol for valid tx
102 2011-10-10 04:02:46 <gmaxwell> You _must_ brodcast at least one conflicting TX or the conflict notice could be a lie.
103 2011-10-10 04:03:28 <gmaxwell> s/brodcast/broadcast/
104 2011-10-10 04:03:58 <gmaxwell> I don't want to change anything when there isn't a conflict I only want to change the conflict case. And I thought I explained why changing the behavior there would be valuable?
105 2011-10-10 04:04:21 <gmaxwell> Right now about 1% of the time a mined block is eventually orphaned because different mined block get extended first.
106 2011-10-10 04:04:32 <ThomasV> hmm, trying to reread whay tou wrote - sorry I don't get it
107 2011-10-10 04:04:41 <ThomasV> *you*
108 2011-10-10 04:05:12 <gmaxwell> In these cases, if the losing conflicting txn made it into the block that eventually loses the extension war then some nodes will see that txn go to 1 confirmed and then later go to 0 confirmed (forever).
109 2011-10-10 04:05:38 <gmaxwell> So if you make the conflict resolution determinstic then it will be very unlikely for that to happen.
110 2011-10-10 04:06:02 <nanotube> gmaxwell: my understanding of your proposal is that rather than rebroadcasting all conflicting tx, you just broadcast a conflict notice once per conflict (i.e., subsequent conflicting tx don't keep getting rebroadcast). so you solve the dos problem. ?
111 2011-10-10 04:06:20 <gmaxwell> (it would only happen for miners that ignore the determinstic rule, or when the a non-prefered conflict is mined before the notice spreads out)
112 2011-10-10 04:07:27 <gmaxwell> nanotube: Notice per _input_ which is conflicted, and the notice will reference two conflicting txn, which you need to also hand to the peer (so they can see that there is indeed a conflict)
113 2011-10-10 04:08:11 <ThomasV> <gmaxwell> You _must_ brodcast at least one conflicting TX or the conflict notice could be a lie.   <--- I think this is the part I do not understand. a signed lie?
114 2011-10-10 04:08:45 <nanotube> gmaxwell: right.
115 2011-10-10 04:09:02 <gmaxwell> ThomasV: you send a txn. I hate you. I tell all my peers that your txn is conflicting another txn. Now your txn gets delayed. Thats bad.
116 2011-10-10 04:09:42 <nanotube> ThomasV: only way to be sure it's real, is to have two signed messages from the tx originator both trying to spend the same bitcoins.
117 2011-10-10 04:09:49 <ThomasV> gmaxwell: but how can you tell it's conflicting, if you don't have the key to sign it?
118 2011-10-10 04:09:52 <gmaxwell> Instead, I propose, you send a txn ... I can't tell people there is a conflict because to do so I must provide copies of the two transactions. Then they can see you signed both.
119 2011-10-10 04:09:54 <nanotube> which means, you must include two transactions.
120 2011-10-10 04:10:22 <ThomasV> nanotube: it depends what you mean by "include"
121 2011-10-10 04:10:32 <nanotube> provide along with your 'conflict' message
122 2011-10-10 04:10:37 <gmaxwell> I send the txn IDs and I'm willing to provide them if they get them from me.
123 2011-10-10 04:10:37 <nanotube> to prove you're not making shit up
124 2011-10-10 04:10:44 <gmaxwell> (or I just pack them along)
125 2011-10-10 04:10:56 <gmaxwell> The former is more efficient because they'll likely have at least one already.
126 2011-10-10 04:12:15 <ThomasV> gmaxwell: oh, did not realize that you tried to save bandwidth
127 2011-10-10 04:14:07 <forrestv> hm ... allow conflicting txns to be included a block, with the miner collecting the entire value of them :P
128 2011-10-10 04:14:22 <forrestv> and prefer blocks that include conflicting txns
129 2011-10-10 04:14:32 <ThomasV> :)
130 2011-10-10 04:14:49 <nanotube> hehe nice thought, forrestv :)
131 2011-10-10 04:14:57 <midnightmagic> would two txn in one mined block that conflict be accepted by other bitcoind?
132 2011-10-10 04:14:58 <nanotube> good way to discourage double spends
133 2011-10-10 04:15:05 <nanotube> midnightmagic: no currently not.
134 2011-10-10 04:15:10 <nanotube> that would require a chain split
135 2011-10-10 04:15:21 <forrestv> actually, the 'prefer blocks' part would allow people to easily override previous blocks ... so that needs more thought
136 2011-10-10 04:15:42 <nanotube> forrestv: well, so forget about the prefer bit
137 2011-10-10 04:15:51 <ThomasV> forrestv: also, encourage double spend because they grow the economy faster
138 2011-10-10 04:15:54 <nanotube> that only matters in case of block races anyway
139 2011-10-10 04:16:10 <Scarab> anyone awake]
140 2011-10-10 04:16:19 <forrestv> heh
141 2011-10-10 04:16:20 <nanotube> or should be anyway :P
142 2011-10-10 04:16:37 <Graet> most of us talk best in our sleep :P
143 2011-10-10 04:16:45 <gmaxwell> There are innocent ways to produce double spends, alas.
144 2011-10-10 04:16:45 <Scarab> haha fair enough
145 2011-10-10 04:17:23 <gmaxwell> e.g. you spend, ... but then crash... and come back up without knowing about the first spend.. then you spend again.. BZZZT.
146 2011-10-10 04:17:32 <Scarab> im attempting to update puddins cuda miner with cuda API info
147 2011-10-10 04:17:52 <Scarab> and the newest build of bitcoin
148 2011-10-10 04:17:59 <Diablo-D3> Scarab: why? its slower than diablominer.
149 2011-10-10 04:18:39 <Scarab> because i have seen cuda fly doing hashes before when properly optimized to the api
150 2011-10-10 04:18:49 <Diablo-D3> yes, and its still slower than diablominer.
151 2011-10-10 04:19:05 <Scarab> unlikely when done right
152 2011-10-10 04:19:13 <Diablo-D3> bwahaha, sure.
153 2011-10-10 04:19:26 <Scarab> how fast is a gtx 570 on diablominer
154 2011-10-10 04:19:27 <Diablo-D3> opencl and cuda shaders are both compiled by the same compiler
155 2011-10-10 04:19:44 <Scarab> right now on puddin it is like 140
156 2011-10-10 04:20:01 <Diablo-D3> its faster than 140, but I dont know how fast
157 2011-10-10 04:20:01 <Scarab> done right should be able to break 300
158 2011-10-10 04:20:10 <Diablo-D3> no one is dumb enough to use nvidia to mine
159 2011-10-10 04:20:16 <Diablo-D3> break 300? probably not
160 2011-10-10 04:20:30 <Diablo-D3> break 200? possibly.
161 2011-10-10 04:20:36 <Scarab> seen it do sha 256 far faster than this
162 2011-10-10 04:20:44 <Diablo-D3> nvidia gpus have extremely shitty integer performance
163 2011-10-10 04:20:47 <midnightmagic> if a miner returns a solution to nBestHeight why doesn't bitcoind overwrite the one received from the network and begin working on the next beyond that? it'll be a vanishingly small advantage to work on a second local block but it is an advantage..?
164 2011-10-10 04:20:51 <Diablo-D3> you cant fix that, its a hardware flaw
165 2011-10-10 04:21:14 <Scarab> you can optimize around the card though
166 2011-10-10 04:21:34 <Diablo-D3> you cant optimize around instructions radeon 5/6xxx have and nvidia doesnt.
167 2011-10-10 04:21:35 <nanotube> Scarab: well, at worst, it will be a very educational exercise :)
168 2011-10-10 04:21:53 <Scarab> http://blog.cuvilib.com/2010/06/09/nvidia-cuda-difference-between-fermi-and-previous-architectures/
169 2011-10-10 04:22:11 <Diablo-D3> Scarab: fermi has no goddamned integer performance
170 2011-10-10 04:22:12 <Diablo-D3> period
171 2011-10-10 04:22:34 <Scarab> a little defensive are we
172 2011-10-10 04:22:37 <Diablo-D3> radeon 5/6xxx can do things in 1 cycle that would take 3-4 cycles on radeon 4xxx or anything nvidia.
173 2011-10-10 04:22:48 <Diablo-D3> defensive? no. you're arguing with someone who understands the hardware inside out.
174 2011-10-10 04:23:07 <Diablo-D3> everything that could have been done has already been done.
175 2011-10-10 04:23:16 <midnightmagic> Scarab: don't take his annoyance too seriously, he answers the same questions a dozen times a day with new people who keep coming in asking the same thing. I'm surprised he keeps answering at all, no offence. :)
176 2011-10-10 04:23:36 <Diablo-D3> midnightmagic: I dont know why I keep answering either.
177 2011-10-10 04:23:38 <Diablo-D3> its pointless.
178 2011-10-10 04:23:46 <Scarab> answering the same question doesnt make one an expert or correct
179 2011-10-10 04:24:09 <Scarab> and being more of an AMD fan does not mean all other hardware sucks
180 2011-10-10 04:24:27 <midnightmagic> Diablo-D3: It's fighting against misapprehension. Really it's a question of promoting truth. My surprise is born of your persistence in spreading the truth. I personally am finding your stamina admirable. (no innuendo intended)
181 2011-10-10 04:24:46 <gjs278> what is the truth
182 2011-10-10 04:24:51 <Diablo-D3> writing a miner, reading nvidia's own goddamned cuda/opencl optimization guides, and also reading the goddamned programming manual for nvidia, and also spending a large amount of time trying to get more power out of nvidia.
183 2011-10-10 04:24:51 <lianj> ^^
184 2011-10-10 04:24:59 <Diablo-D3> THAT makes me an expert
185 2011-10-10 04:25:44 <nanotube> Scarab: well, why not give it a shot and see what you can accomplish. i'm no hw expert, but it is a generally accepted fact in the bitcoin community, borne out by a bunch of guys who actually wrote a bunch of miners and know their stuff. but regardless, if you can have fun and learn some stuff, go for it.
186 2011-10-10 04:25:45 <gjs278> ;;bc,stats
187 2011-10-10 04:25:47 <gjs278> ;;bc,mtgox
188 2011-10-10 04:25:48 <gribble> Current Blocks: 148769 | Current Difficulty: 1689334.4045971 | Next Difficulty At Block: 149183 | Next Difficulty In: 414 blocks | Next Difficulty In About: 3 days, 4 hours, 42 minutes, and 18 seconds | Next Difficulty Estimate: 1529280.89462308 | Estimated Percent Change: -9.47435330379
189 2011-10-10 04:25:53 <Diablo-D3> miners to not depend on shaders, they do not depend on caches, or memory, or thread count or width, or even effective instruction parallelism.
190 2011-10-10 04:25:59 <midnightmagic> Scarab: no, that's on the surface correct. But I'm explaining where the irritation comes from, not where the correct answers come from.
191 2011-10-10 04:26:11 <Scarab> writing a miner writen for open cl which runs on cude is not as ever going to work as well as writing for cuda directly
192 2011-10-10 04:26:16 <Diablo-D3> they depend on how fast a processor can execute a very small number of instructions.
193 2011-10-10 04:26:34 <gjs278> there already is a cuda miner
194 2011-10-10 04:26:46 <Diablo-D3> Scarab: [02:19:27] <Diablo-D3> opencl and cuda shaders are both compiled by the same compiler
195 2011-10-10 04:27:14 <Scarab> how they are compiled is not the same as accessing the same api
196 2011-10-10 04:27:17 <Diablo-D3> the compiler has multiple language lexers.
197 2011-10-10 04:27:25 <Diablo-D3> actually, IS the same as accessing the same API
198 2011-10-10 04:27:37 <Diablo-D3> the opencl lib is a dumb wrapper for the equiv in cuda.
199 2011-10-10 04:27:43 <Scarab> then obvously you lied about studying nvidia
200 2011-10-10 04:28:06 <Diablo-D3> not at all. Ive seen exactly what the driver does.
201 2011-10-10 04:28:53 <Scarab> this is pointless, it seems obvious you have not intention of assisting or improving your own miner which is probably why is is far from the most popular
202 2011-10-10 04:29:01 <Diablo-D3> LOL
203 2011-10-10 04:29:05 <Diablo-D3> its official, Scarab is a troll
204 2011-10-10 04:29:44 <midnightmagic> Scarab: I recommend you begin writing it. When you have some results, I highly recommend coming back in and waving them around triumphantly. :) Nothing more satisfying than making people eat their words, bro, but arguing about it here is pointless.
205 2011-10-10 04:29:47 <nanotube> Scarab: why argue - if you can accomplish significant performance improvements, you'll get massive cred, so give it a shot. if you can't well, nothing lost.
206 2011-10-10 04:29:57 <nanotube> midnightmagic: ++ :)
207 2011-10-10 04:30:08 <midnightmagic> nanotube: ++ :)
208 2011-10-10 04:30:12 <midnightmagic> lol
209 2011-10-10 04:30:15 <nanotube> hehe
210 2011-10-10 04:30:45 <Scarab> imnot in it for the credit, never take credit just for improving on someone elses work
211 2011-10-10 04:30:51 <imsaguy> copumpkin: ++ :)
212 2011-10-10 04:30:55 <Scarab> was more looking for assistance
213 2011-10-10 04:31:00 <imsaguy> (everyone else is doing it)
214 2011-10-10 04:31:00 <midnightmagic> Scarab: Why not? That's the essence of science.
215 2011-10-10 04:31:33 <Scarab> because i never wanted a name as a programmer, its something i do when bored and need to challenge myself
216 2011-10-10 04:32:09 <Scarab> worked on more than a few dozen open source projects and most people dont know who i am and i like it that way, i make my improvement and move on to the next thing
217 2011-10-10 04:32:49 <midnightmagic> Then do it for the challenge; I think you have an answer to the questions you came in here to ask. :)
218 2011-10-10 04:33:40 <midnightmagic> Now go forth, and do secret science!
219 2011-10-10 04:33:54 <Scarab> you are right, it seems the answer is no, kind of disapointing for an open source community
220 2011-10-10 04:34:33 <midnightmagic> Get used to it.
221 2011-10-10 04:35:42 <midnightmagic> Also, I'm 100% certain patch submissions are welcome--somewhere!
222 2011-10-10 04:40:18 <neofutur> Scarab: your problem is you dont want to submit a patch or fork it ?
223 2011-10-10 04:40:51 <coderrr> AlexWaters, sorry, was just gonna ask a question about updating the pull request, but i figured it out, kinda sucks cuz i had it pointed at v0.3.24+coderrr, so I had to actually move that branch to point to the 0.4 code
224 2011-10-10 04:41:00 <Scarab> no my problem is i am rusty at C++ been doing C# more lately
225 2011-10-10 04:41:25 <midnightmagic> ##c++  !!
226 2011-10-10 04:41:54 <neofutur> ah if you prefer C# i understand better the problem :p
227 2011-10-10 04:42:19 <AlexWaters> coderrr: I'm sorry I had to ask you to do this. Do you have a test plan for your pull so that I can test and confirm it tonight?
228 2011-10-10 04:43:09 <coderrr> AlexWaters, nah, no tests, I should probly just close that pull request cuz I know it'll never be merged and it's just wasting your time
229 2011-10-10 04:43:55 <Scarab> dont specifically prefer it, just been using it more often lately
230 2011-10-10 04:44:13 <Scarab> recent projects have called for it
231 2011-10-10 04:44:56 <AlexWaters> coderrr: if you think it's a valuable addition, and I can test it for you - there is no reason it wouldn't be merged shortly
232 2011-10-10 04:47:22 <coderrr> AlexWaters, whether I think it's valuable or not doesn't affect whether it gets merged or not sadly :P
233 2011-10-10 04:53:03 <Scarab> http://upcommons.upc.edu/pfc/bitstream/2099.1/7933/1/Masteoppgave.pdf
234 2011-10-10 04:53:49 <AlexWaters> coderrr: increased anonymity is definitely a desirable improvement for many people. I think it would be worth while to write up a test plan - and I'll do my best to get it merged. Do you think you could rebase it for QT and include unit tests / GUI test-plan?
235 2011-10-10 04:54:56 <AlexWaters> coderrr: no need to close the pull if you don't have time for it, I won't close it if we can get an ETA
236 2011-10-10 04:56:07 <coderrr> AlexWaters, k yea I'll look into qt and doing tests
237 2011-10-10 04:56:12 <coderrr> thx
238 2011-10-10 04:56:18 <AlexWaters> coderrr: awesome, thank you. cheers
239 2011-10-10 06:53:46 <CIA-101> bitcoinj: hearn@google.com * r226 /trunk/src/com/google/bitcoin/core/ (8 files):
240 2011-10-10 08:28:46 <iddo> can miners detect if the pool does backdoor merged-mining, i.e. not sharing the namecoin reward with the miners? there's a suspicion in the forums that pools are doing that right now
241 2011-10-10 08:29:25 <Ycros> iddo: sure, check the block that the pool generates
242 2011-10-10 08:29:50 <sipa> when using getwork() it can't know in advance
243 2011-10-10 08:29:59 <Ycros> maybe
244 2011-10-10 08:30:00 <Ycros> hmm
245 2011-10-10 08:30:11 <iddo> and see if the nonce in that block contains hash of recent namecoin block?
246 2011-10-10 08:31:47 <Ycros> inspect the work you're doing
247 2011-10-10 08:31:59 <Ycros> the work is the header of the block you'r etrying to solve
248 2011-10-10 08:32:06 <Ycros> you should be able to work out from that what it is
249 2011-10-10 08:32:23 <iddo> but it's a regular bitcoin block
250 2011-10-10 08:32:41 <DrHaribo> isn't the merged mining stuff in the transactions, not in the header?
251 2011-10-10 08:32:42 <sipa> the merged mining header is in the generation coinbase
252 2011-10-10 08:32:49 <sipa> you can't see it in the header
253 2011-10-10 08:32:58 <sipa> as it is masked via the tx hashes and the merkle tree
254 2011-10-10 08:33:30 <iddo> if it cannot be detected then miners might need to switch to merge-mining pools to avoid being cheated
255 2011-10-10 08:33:43 <Ycros> sipa: sure, but you can match up the headers you've mined on to generated blocks
256 2011-10-10 08:34:03 <Ycros> and thus a) detect which blocks your pool has generated, and b) see what's in them
257 2011-10-10 08:34:09 <sipa> Ycros: sure, afterwards
258 2011-10-10 08:34:21 <Ycros> indeed
259 2011-10-10 08:34:51 <iddo> so we can just inspect the blocks that pools generated, and see if they generated merged-mining blocks?
260 2011-10-10 08:34:52 <Ycros> it would be nice to see mining clients do this automatically, perhaps working off blockexplorer APIs
261 2011-10-10 08:35:00 <Eliel> merged mining should be easy to detect, just look at the blocks your pool finds. If they're not published, you shouldn't be using the pool anyway.
262 2011-10-10 08:35:19 <DrHaribo> Any specs somewhere on how to implement merged mining?
263 2011-10-10 08:35:25 <Ycros> of course doing this you can also detect if a pool is withholding blocks from payouts
264 2011-10-10 08:35:27 <iddo> what exactly do you look for in the block that your pool found?
265 2011-10-10 08:35:37 <Ycros> really people should be doing this already
266 2011-10-10 08:36:04 <sipa> DrHaribo: start by reading this: https://bitcointalk.org/index.php?topic=7219.0
267 2011-10-10 08:36:06 <Eliel> DrHaribo: I hear there is one implementation. luke-jr said it's badly implemented. I haven't looked at it myself :)
268 2011-10-10 08:36:14 <sipa> the actual implementation used by namecoin - not sure
269 2011-10-10 08:36:33 <DrHaribo> thanks :)
270 2011-10-10 08:36:51 <mrb_> heh - I was wondering about that Sleep(2000)
271 2011-10-10 08:36:53 <mrb_> https://github.com/bitcoin/bitcoin/commit/32ebde46123046d5dd41789b40578d2d43f1e7ef#src/main.cpp
272 2011-10-10 08:36:58 <mrb_> just got removed.
273 2011-10-10 08:39:03 <mrb_> that would help some of the alt chains with very fast block periods
274 2011-10-10 09:28:09 <anddam> anyone about the wxwidgets question?
275 2011-10-10 09:29:48 <sipa> anddam: the readme should explain that wx 2.9 is required
276 2011-10-10 09:30:01 <sipa> but for 0.5, the wx gui is dropped, and we'll be switching to qt
277 2011-10-10 09:36:31 <anddam> sipa: can't find it, but I'm browsing 0.3.22 source
278 2011-10-10 09:36:39 <anddam> actually I was grepping it
279 2011-10-10 09:37:33 <anddam> I'll fetch 0.4.0
280 2011-10-10 09:38:03 <sipa> read doc/build-unix.txt
281 2011-10-10 09:38:37 <anddam> I think you already discussed it: why didn't you go with a Java GUI in first place?
282 2011-10-10 09:38:47 <anddam> let me rephrase
283 2011-10-10 09:39:18 <anddam> did you discuss about a Java GUI on developers' mailing list?
284 2011-10-10 09:39:53 <sipa> there's a java gui called multibit for bitcoinj
285 2011-10-10 09:40:08 <sipa> the original implementation was written by satoshi, including the wx ui
286 2011-10-10 09:40:18 <sipa> and is in C++
287 2011-10-10 09:40:35 <anddam> I see
288 2011-10-10 09:40:51 <anddam> I knew there was a java GUI but it's not in codebase
289 2011-10-10 09:40:59 <anddam> just a curiosity of mine, tho'
290 2011-10-10 09:44:02 <da2ce7> sipa is the RC1 of 0.5 out yet?
291 2011-10-10 09:44:40 <sipa> no
292 2011-10-10 09:55:39 <anddam> dmg file is uncomfortable to update from cli
293 2011-10-10 09:56:09 <anddam> can a -macosx tarball or zip be added to release files?
294 2011-10-10 10:08:21 <anddam> sipa: build-unix seems little unix-ish
295 2011-10-10 10:08:30 <anddam> and more debian-ish
296 2011-10-10 10:10:02 <sipa> then submit a patch to improve it :)
297 2011-10-10 10:14:01 <snimpy> ;;bc,diffchange
298 2011-10-10 10:14:02 <gribble> Estimated percent change in difficulty this period | -9.67248129526 % based on data since last change | -14.0872555416 % based on data for last three days
299 2011-10-10 10:14:13 <snimpy> ;;bc,diffchange
300 2011-10-10 10:14:15 <gribble> Estimated percent change in difficulty this period | -9.67248129526 % based on data since last change | -14.0872555416 % based on data for last three days
301 2011-10-10 10:23:41 <anddam> sipa: is codebase github hosted?
302 2011-10-10 10:23:56 <anddam> https://github.com/bitcoin/bitcoin ?
303 2011-10-10 10:23:59 <sipa> yes
304 2011-10-10 11:12:18 <luke-jr> anddam: Java sucks.
305 2011-10-10 11:15:55 <da2ce7> luke-jr and Diablo-D3 are in a love-hate relationship
306 2011-10-10 11:19:28 <Diablo-D3> da2ce7: you mean a hate hate relationship
307 2011-10-10 11:20:42 <Diablo-D3> hes catholic and Im straight
308 2011-10-10 11:20:51 <da2ce7> :O
309 2011-10-10 11:21:01 <da2ce7> lawl
310 2011-10-10 11:40:11 <diki> http://www.dartlang.org
311 2011-10-10 11:40:29 <diki> time to get started with that folks, google is planning something big with it
312 2011-10-10 11:40:54 <b4epoche_> like they were with wave?
313 2011-10-10 11:41:21 <diki> https://gist.github.com/1208618
314 2011-10-10 11:41:26 <Diablo-D3> b4epoche: wrong joke
315 2011-10-10 11:41:32 <Diablo-D3> itym "like they did with Go"
316 2011-10-10 11:42:21 <b4epoche_> Did they kill Go too?
317 2011-10-10 11:44:45 <UukGoblin> how many Mhash in a typical browser? ;-)
318 2011-10-10 11:49:48 <Diablo-D3> b4epoche_: its not like anyone uses Go
319 2011-10-10 11:49:53 <Diablo-D3> UukGoblin: lawlz
320 2011-10-10 11:50:42 <PK> Can webgl be used to do gpu mining? :)
321 2011-10-10 11:53:33 <UukGoblin> PK, I guess you'd need webCl. but if you were creative with shaders...
322 2011-10-10 11:54:44 <PK> I wonder how many browsers support webcl though.
323 2011-10-10 11:56:21 <Diablo-D3> PK: webgl is just a js api wrapper for opengl
324 2011-10-10 11:56:23 <Diablo-D3> so, no
325 2011-10-10 11:57:30 <PK> then it's all about being creative with shaders :) mapping the key on a texture and all the old tricks.
326 2011-10-10 11:57:43 <makomk> OK, hopefully now I've fixed the reference counting bug this should now work >.>
327 2011-10-10 12:23:19 <graingert> nanotube: poke
328 2011-10-10 12:23:56 <nanotube> graingert: pop
329 2011-10-10 12:27:46 <imsaguy2> pop.. tricky
330 2011-10-10 12:33:02 <makomk> https://github.com/makomk/bitcoin/tree/poolserv-work-gen https://github.com/makomk/pushpool/tree/local-work-gen - any pool owners feeling brave/foolish? ;-)
331 2011-10-10 12:37:40 <nathan7> brave, foolish or both
332 2011-10-10 12:37:44 <nathan7> [=
333 2011-10-10 12:40:59 <Graet> i'm both
334 2011-10-10 12:41:13 <Graet> i'll run it past the code team tho :P
335 2011-10-10 12:41:17 <Diablo-D3> nothing wrong with being foolish
336 2011-10-10 12:42:03 <Graet> thank you Diablo-D3 - thats the nicest thing you hyave ever said to me :)
337 2011-10-10 12:42:22 <makomk> nathan7: both, in this case. It's meant to move most of the work of work generation across to pushpool, but it's totally untested and there's an awful lot that could go wrong...
338 2011-10-10 12:44:10 <makomk> Actually, wait, don't do that *facepalm*.
339 2011-10-10 12:44:22 <shadders> what's with the local generation fad... luke's doing the same thing so am I with psj... must be hip to make yr own work these days ;)
340 2011-10-10 12:44:38 <makomk> shadders: neat, how're you doing it?
341 2011-10-10 12:45:56 <shadders> I've being doing some work on bitcoinj adding all the bits it needs... it's not a full node capable of proper verification yet so it will still rely on bitcoind to filter tx's...
342 2011-10-10 12:46:44 <shadders> haven't decided yet whether to use getmemory pool or to just listen to my bitcoind using bitcoin protocol..
343 2011-10-10 12:47:01 <makomk> I've taken the lazy approach and just got bitcoin to let me muck with the coinbase transation in the work it generates.
344 2011-10-10 12:48:12 <shadders> hmm.. I'm building the block inside psj... but like you I'm taking all the components from bitcoind.
345 2011-10-10 12:49:39 <shadders> just finished a merkle tree implementation today that's log2(nTx) more efficient than the crazy bitcoind implementation
346 2011-10-10 12:50:02 <luke-jr> shadders: copycat :P
347 2011-10-10 12:50:13 <makomk> Yeah, I had a patch lying around somewhere to make bitcoin's merkle tree updates faster actually...
348 2011-10-10 12:50:59 <luke-jr> my new pool software can generate 6000 works in under a second :D
349 2011-10-10 12:51:03 <shadders> luke-jr: just coz I can keep my mouth shut don't make me a copycat :p
350 2011-10-10 12:53:13 <shadders> well I don't wanna set myself up for a CH fall but going on my calcs you should be able to get 20000 sustained... and that's with java so probably several million with C
351 2011-10-10 12:54:34 <sipa> i wrote this in februari: https://svn.ulyssis.org/repos/sipa/libbtc/merklecalc.cpp
352 2011-10-10 12:54:51 <sipa> iirc it calculated 100000 merkle roots per second
353 2011-10-10 12:55:33 <shadders> actually luke I've always wanted to do internal generation but last I looked at it there was I lot I needed to know to do it that I hadn't leared yet... you mentioning gememorypool the other day got me thinking and realised I have actually covered all the essential parts since then so I got straight at it...
354 2011-10-10 12:55:58 <shadders> sipa how many nodes? and how big are the nodes?
355 2011-10-10 12:56:57 <shadders> luke-jr: then your mentioned yr secret project which pissed me off coz I thought I was gonna be first past the post
356 2011-10-10 12:57:26 <sipa> shadders: can't remember, i'd need to try running it again
357 2011-10-10 12:58:40 <makomk> It looks like I'm limited to 3000 getworks/sec with this. Oh well.
358 2011-10-10 12:59:23 <makomk> (Unfortunately it also doesn't provide midstate currently, which will probably break some mining software.)
359 2011-10-10 13:00:08 <shadders> I'm luke can tell you which miner it breaks ;)
360 2011-10-10 13:04:06 <sipa> shadders: 100 transactions (including coinbase), 65000 merkle roots per second cpu time on a C2D 6400 @ 2.16 GHz
361 2011-10-10 13:04:50 <shadders> I see yr markdirty... does differential updates to the tree?
362 2011-10-10 13:05:22 <sipa> yes
363 2011-10-10 13:05:58 <shadders> makes a huge difference
364 2011-10-10 13:06:07 <sipa> sure... O(log n) vs. O(n)
365 2011-10-10 13:06:38 <shadders> 99 hashes vs 7
366 2011-10-10 13:10:38 <shadders> I won't dare to suggest that's why luke-jr's only getting 6k/sec.  If it is he should probably deny it :p
367 2011-10-10 13:11:23 <sipa> there are other things to do as well, like maintaining the transactions themselves
368 2011-10-10 13:11:33 <sipa> not sure what is included in that number
369 2011-10-10 13:12:48 <shadders> I'm relying on bitcoind to do that part... bitcoinj is a fair way off verification etc...
370 2011-10-10 13:15:53 <CIA-101> bitcoin: Gavin Andresen  * reab61cd / (doc/build-unix.txt src/bitcoinrpc.cpp): Merge branch 'master' of github.com:bitcoin/bitcoin - http://git.io/NGHalg
371 2011-10-10 13:15:54 <CIA-101> bitcoin: Gavin Andresen  * rb50ac8f / (bitcoin-qt.pro contrib/create_osx_dmg.sh src/makefile.osx):
372 2011-10-10 13:15:55 <CIA-101> bitcoin: Update create_osx_dmg.sh script to use macdeployqt tool.
373 2011-10-10 13:20:31 <CIA-101> bitcoin: Gavin Andresen  * rab877a2 / (3 files in 3 dirs):
374 2011-10-10 13:20:59 <CIA-101> bitcoin: Gavin Andresen  * re99b8ea / src/qt/locale/bitcoin_es.ts :
375 2011-10-10 13:25:57 <CIA-101> bitcoin: Gavin Andresen  * ref49d8a / bitcoin-qt.pro : Add spanish translation to TRANSLATIONS - http://git.io/Cssfiw
376 2011-10-10 13:34:53 <luke-jr> makomk: cgminer and DM can't handle midstate missing yet (it's being removed from bitcoind tho)
377 2011-10-10 13:35:37 <luke-jr> shadders: I'm only *trying* to do 6k ;)
378 2011-10-10 13:36:16 <luke-jr> hence *under* a second
379 2011-10-10 13:39:14 <makomk> Ah, OK.
380 2011-10-10 13:39:45 <shadders> k well post when you've got real stats so we can all get our works out and see who's got the biggest
381 2011-10-10 13:43:45 <makomk> Unfortunately, cgminer seems to want a different version of jansson to pushpoold...
382 2011-10-10 13:44:29 <makomk> Even more annoyingly, although it has a built-in copy of jansson, there's no way to tell it not to use the system one.
383 2011-10-10 13:44:49 <BlueMatt> gavinandresen: whats up with 0.5.0 release process here?
384 2011-10-10 13:45:02 <gavinandresen> I just tagged the tree rc1
385 2011-10-10 13:45:07 <BlueMatt> (also https://github.com/bitcoin/bitcoin/issues/571 should be considered a blocker)
386 2011-10-10 13:45:37 <gavinandresen> BlueMatt: anybody reproduce?
387 2011-10-10 13:45:54 <gavinandresen> (I can try it on OSX....)
388 2011-10-10 13:46:30 <BlueMatt> gavinandresen: it was reported here a while ago (dont remember who) and I was able to reproduce right away
389 2011-10-10 13:46:36 <BlueMatt> so afaik it effects all win32 users...
390 2011-10-10 13:47:12 <b4epoche_> seems like it would also have to affect osx too
391 2011-10-10 13:47:25 <gavinandresen> If it doesn't happen on Linux/Mac, then we can release rc1 binaries on those platforms, and spin an rc2 with a fix for windows.  I want release testing to start
392 2011-10-10 13:47:53 <luke-jr> shadders: also, mine is just Python right now
393 2011-10-10 13:47:56 <b4epoche_> is it only 0.5rc1?  did wallet locking code change?
394 2011-10-10 13:48:16 <BlueMatt> well release of win32 aint gonna happen till friday at least if you are looking for gitian releases or builds from me (damn miderm on thurs)
395 2011-10-10 13:48:43 <luke-jr> BlueMatt: pretty sure the gitian stuff is all broken right now anyway
396 2011-10-10 13:48:53 <luke-jr> at least, last I looked the gitian descriptors still tried to build wx
397 2011-10-10 13:49:15 <BlueMatt> luke-jr: yea, because people like you change the makefiles dramatically without updating gitian files...
398 2011-10-10 13:49:21 <BlueMatt> well actually you didnt do that...
399 2011-10-10 13:49:24 <b4epoche_> gavinandresen:  do you know anything about writing Cocoa/ObjC code?
400 2011-10-10 13:49:38 <BlueMatt> gavin did and all the qt stuff just fucked gitian and ignore it...
401 2011-10-10 13:49:59 <luke-jr> BlueMatt: I did update the gitian file for my makefile change
402 2011-10-10 13:50:00 <gavinandresen> b4epoche_: nope
403 2011-10-10 13:50:02 <louigi> hey guys, I see that some sites on the web track block count and payment confirmations. Is there any public API for web developers to use?
404 2011-10-10 13:50:14 <luke-jr> louigi: JSON-RPC
405 2011-10-10 13:50:24 <louigi> luke-jr, hey
406 2011-10-10 13:50:30 <gavinandresen> BlueMatt: no worries, don't stress out...
407 2011-10-10 13:50:30 <louigi> btw, did you get those files?
408 2011-10-10 13:50:32 <b4epoche_> I've pretty much finished the wallet locking Cocoa GUI but would like someone to look it over
409 2011-10-10 13:51:18 <b4epoche_> are there outward facing (GUI) changes planned in 0.5?
410 2011-10-10 13:51:29 <luke-jr> louigi: yes
411 2011-10-10 13:51:30 <BlueMatt> b4epoche: a lot...
412 2011-10-10 13:51:39 <sipa> i'd say about 100.0%
413 2011-10-10 13:51:52 <gavinandresen> yes, 100% would be about right.
414 2011-10-10 13:51:52 <luke-jr> louigi: the problem was semi-diagnosed and discussed in here, but I don't think anyone ever implemented the fix
415 2011-10-10 13:52:02 <louigi> luke-jr, what was the problem?
416 2011-10-10 13:52:09 <luke-jr> b4epoche_: everything
417 2011-10-10 13:52:30 <b4epoche_> I'm talking functionality, not appearance
418 2011-10-10 13:52:34 <luke-jr> louigi: apparently bitcoind & co can't survive a system crash when it's accepting a block
419 2011-10-10 13:52:55 <luke-jr> b4epoche_: bitcoin-qt has sendmany
420 2011-10-10 13:53:03 <sipa> and export to csv
421 2011-10-10 13:53:17 <louigi> luke-jr, if I regularly backup the blockcount files can I just replace broken files with backups without any harm to the wallet?
422 2011-10-10 13:54:50 <luke-jr> louigi: bitcoind must not be running when you backup and restore
423 2011-10-10 13:54:56 <sipa> that was inevitable when we switched to Qt without a unified build system
424 2011-10-10 13:55:01 <gavinandresen> BlueMatt: The GUI is much easier to build now.
425 2011-10-10 13:55:17 <gavinandresen> I'm very tempted to write a qmake .pro file for bitcoind....
426 2011-10-10 13:55:24 <BlueMatt> gavinandresen: please do
427 2011-10-10 13:55:33 <gavinandresen> ... but makefiles are lowest-common-denominator
428 2011-10-10 13:55:35 <BlueMatt> having two completely separate build systems is just stupid...
429 2011-10-10 13:55:40 <gavinandresen> agreed
430 2011-10-10 13:56:05 <louigi> luke-jr, understood. I am asking because on sourceforge site it is adviced AGAINST using their blockcount files with the existing wallet. Why is that?
431 2011-10-10 13:56:16 <gavinandresen> ... and patches welcome....   build systems aren't in the "make the network more secure or stable" category, so they're not high priority
432 2011-10-10 13:56:23 <b4epoche_> any tips for building with qt on osx?
433 2011-10-10 13:56:42 <gavinandresen> b4epoche_: use macports
434 2011-10-10 13:57:12 <BlueMatt> gavinandresen: qmake is a standalone package in debian/ubuntu, so I would say it would be fine (whereas downloading all of qt-dev for building would be a problem IMHO)
435 2011-10-10 13:57:33 <gavinandresen> b4epoche_:  I answered a question on bitcoin.stackexchange.com  RE: building on mac
436 2011-10-10 13:57:34 <luke-jr> louigi: uh, no?
437 2011-10-10 13:57:50 <gavinandresen> BlueMatt: thanks, didn't know that
438 2011-10-10 13:58:06 <sipa> how about mingw, osx, bsd, fedora, ...?
439 2011-10-10 13:58:07 <BlueMatt> p
440 2011-10-10 13:58:25 <gavinandresen> Anybody here know a lot more about qt .pro files than I do?  It'll take me several hours to learn everything i need to know to create a bitcoind.pro  ....
441 2011-10-10 13:58:29 <luke-jr> gavinandresen: in case you missed it, if bitcoin crashes whilest accepting a block, it irreversibly corrupts the block chain file and never recovers
442 2011-10-10 13:58:43 <luke-jr> gavinandresen: qmake is pretty simple, actually
443 2011-10-10 13:58:47 <gavinandresen> luke-jr: regression or has that always been true?
444 2011-10-10 13:58:53 <sipa> gavinandresen: always been true
445 2011-10-10 13:58:59 <luke-jr> could probably make bitcoin-qt.pro into a bitcoin.pro with GUI=qt or something even
446 2011-10-10 13:59:02 <louigi> luke-jr, here is the quote: If you have a wallet with unprocessed transactions, the client may not recognize them. Thus, the above warning: Only use these data files IF YOU DO NOT ALREADY HAVE A WALLET.
447 2011-10-10 13:59:18 <luke-jr> louigi: no idea
448 2011-10-10 13:59:22 <louigi> k
449 2011-10-10 13:59:23 <BlueMatt> two makefiles sucks, one .pro would be best
450 2011-10-10 13:59:34 <luke-jr> IMO best would be automake/autoconf tho
451 2011-10-10 13:59:49 <BlueMatt> well no one stepped up to do that
452 2011-10-10 13:59:53 <luke-jr> but automake/autoconf devs are rare 9
453 2011-10-10 13:59:56 <BlueMatt> and now we have qmake pro file that works
454 2011-10-10 13:59:59 <sipa> agree, a *maintained* automake solution would be preferrab;e
455 2011-10-10 14:02:01 <sipa> that shouldn't be
456 2011-10-10 14:02:13 <BlueMatt> agreed
457 2011-10-10 14:04:46 <BlueMatt> oh great, now bitcoin-qt.exe is 19MB...
458 2011-10-10 14:08:10 <louigi> luke-jr, can this crash thing be fixed theoretically?
459 2011-10-10 14:09:58 <gavinandresen> 0.5rc1 announcement:  https://bitcointalk.org/index.php?topic=47586
460 2011-10-10 14:11:41 <ThomasV> cool
461 2011-10-10 14:12:01 <sipa> gavinandresen: no chance for getting showwallet in, even without removeprivkey if that's controversial?
462 2011-10-10 14:12:29 <freewil> omg listsinceblock!
463 2011-10-10 14:12:29 <gavinandresen> sipa:  no, we're feature-frozen.
464 2011-10-10 14:12:30 <kinlo> I'd vote for that too
465 2011-10-10 14:12:45 <kinlo> would be nice to have them in
466 2011-10-10 14:13:08 <gavinandresen> sipa:  I want to get into the habit of regular releases, and there is PLENTY in this one!
467 2011-10-10 14:13:16 <sipa> ok, i like that idea
468 2011-10-10 14:13:29 <BlueMatt> (as long as build system is able to support it)
469 2011-10-10 14:13:31 <kinlo> is it just my subjective view on things or is the merge window very short?
470 2011-10-10 14:14:06 <sipa> on the good side, there will soon be a new merge window :)
471 2011-10-10 14:14:15 <gavinandresen> exactly
472 2011-10-10 14:14:24 <kinlo> heh, if releases are going out that fast...
473 2011-10-10 14:14:35 <BlueMatt> also, gavinandresen, is it just me who feels like shit is getting committed that is just messy and is just making stuff more and more complicated for no reason?
474 2011-10-10 14:14:44 <gavinandresen> I think it is just you
475 2011-10-10 14:14:49 <BlueMatt> oh, ok
476 2011-10-10 14:14:50 <gavinandresen> (what do other people think?)
477 2011-10-10 14:15:04 <gavinandresen> BlueMatt: anything in particular you don't like?
478 2011-10-10 14:15:27 <gavinandresen> I THINK everything added has a reason, and there were several clean-up fixes included....
479 2011-10-10 14:15:36 <gavinandresen> (like getting rid of deprecated RPC methods)
480 2011-10-10 14:15:37 <BlueMatt> not that I dont like, but generally the rate of pulls without enough discussion, eg https://github.com/bitcoin/bitcoin/pull/573 Mostly-ACK followed by a pull?
481 2011-10-10 14:15:50 <BlueMatt> seems hasty to me
482 2011-10-10 14:16:03 <sipa> i kinda agree with BlueMatt here
483 2011-10-10 14:16:13 <sipa> (in this particular case)
484 2011-10-10 14:16:20 <gavinandresen> That one WAS hasty, but I'm finding it hard to generate discussion before pulling.
485 2011-10-10 14:16:37 <sipa> also true
486 2011-10-10 14:16:40 <BlueMatt> well that is also a problem
487 2011-10-10 14:16:55 <kinlo> what's the proper way to have the discussion?
488 2011-10-10 14:16:59 <gavinandresen> Ideally, there's general consensus that something like getmemorypool is a good idea, etc etc... but if you look, there was very little discussion and NO dissent on the forums for that one.  So I pulled it.
489 2011-10-10 14:17:09 <BlueMatt> also, boost's constant strict-aliasing rule-breaking warnings are fairly annoying...
490 2011-10-10 14:17:25 <BlueMatt> oh, I have no problem with getmemorypool
491 2011-10-10 14:17:40 <b4epoche_> sh*t!
492 2011-10-10 14:17:42 <BlueMatt> but that particular case, its a ton more code to do something that is just "cleaner"
493 2011-10-10 14:17:46 <b4epoche_> qt4 build failed
494 2011-10-10 14:18:01 <gavinandresen> I pulled the mostly-ACK because it was a change to the new getmemorypool RPC api, and not breaking apis if you can help it is a good thing
495 2011-10-10 14:18:25 <BlueMatt> so...maybe we just need more people to start ack-ing stuff?
496 2011-10-10 14:18:40 <gavinandresen> yes, that would be good
497 2011-10-10 14:18:53 <sipa> also, the dev community seems split
498 2011-10-10 14:19:02 <sipa> some people on github, some on the mailinglist, some on the forum
499 2011-10-10 14:19:07 <sipa> and far from everyone everywhere
500 2011-10-10 14:19:25 <louigi> sipa, seems to me time might fix this situation
501 2011-10-10 14:19:34 <sipa> probably
502 2011-10-10 14:19:38 <louigi> every young community has this
503 2011-10-10 14:19:42 <louigi> from my experience
504 2011-10-10 14:19:55 <BlueMatt> anyway, got to go...maybe Ill be back on later but damn hist midterm is screwing me...bitcoin-qt xcompile doesnt seem like its gonna be to bad in the end, but I need to find time to do it...also gavin what is the status with your gitian-capabilities
505 2011-10-10 14:19:58 <BlueMatt> sipa as well there?
506 2011-10-10 14:20:28 <gavinandresen> BlueMatt: I've got the hardware, will be doing a unix gitian 0.5 build this afternoon I hope
507 2011-10-10 14:20:45 <BlueMatt> heh, have fun getting the current gitian scripts working...
508 2011-10-10 14:20:47 <gavinandresen> ... but I don't know nuthin about mingw cross-compiling.....
509 2011-10-10 14:20:51 <sipa> BlueMatt: sorry, my desktop is still not fully reinstalled
510 2011-10-10 14:20:57 <sipa> and my laptop isn't capable
511 2011-10-10 14:21:13 <BlueMatt> sipa: ah, ok just wondered...would be nice to actually do a gitian build w/ 0.5
512 2011-10-10 14:21:37 <makomk> OK, midstate generation done, cgminer appears happy... *grin*
513 2011-10-10 14:22:07 <sipa> gavinandresen: assuming the win32 bug gets fixed tomorrow and no further blocking bugs... when is 0.5 final?
514 2011-10-10 14:22:11 <freewil> im looking at this new rpc call 'listsinceblock': is there a way to tell what block a given transaction is in?
515 2011-10-10 14:22:35 <gavinandresen> sipa: a week or two.
516 2011-10-10 14:25:06 <freewil> lol wut is this
517 2011-10-10 14:25:56 <b4epoche_> gavinandresen:  what osx version you have?
518 2011-10-10 14:26:04 <gavinandresen> b4epoche_: 10.6
519 2011-10-10 14:26:18 <b4epoche_> hmm...
520 2011-10-10 14:26:27 <b4epoche_> qt4 is not liking 10.7
521 2011-10-10 14:26:53 <gavinandresen> b4epoche_:   can't help you there, I'm not a 10.7 or qt4 expert
522 2011-10-10 14:27:10 <BlueMatt-mobile> freewil its stuff like that tsar I'm taking about, bitcoin is a, mess
523 2011-10-10 14:27:34 <b4epoche_> gavinandresen:  Yea, I figured&  I'll try to figure out what's up and document the solution
524 2011-10-10 14:27:38 <BlueMatt-mobile> Also swype sucks
525 2011-10-10 14:27:50 <freewil> ha
526 2011-10-10 14:27:57 <freewil> im assuming that was some sort of debug message
527 2011-10-10 14:27:59 <gavinandresen> b4epoche_:   I do compile my macports a little differently-- compile everything single-architecture i386, to avoid problems with "this port doesn't support x86_64" and to make the compiles faster/smaller.
528 2011-10-10 14:28:03 <freewil> not real helpful
529 2011-10-10 14:28:16 <imsaguy2> gavinandresen, how do you feel about accept a patch to add a commandline argument to allow a person to specify where their wallet.dat file is (not the whole data dir) so a person can have it on a truecrypt/usb/etc without having to store/encrypt the blockchain with it?
530 2011-10-10 14:28:21 <b4epoche_> gavinandresen:  I often do the same
531 2011-10-10 14:28:34 <freewil> imsaguy, +1
532 2011-10-10 14:28:48 <gavinandresen> freewil BlueMatt-mobile : patches welcome, especially tiny little ones that improve RPC error messages that should be more descriptive
533 2011-10-10 14:29:38 <imsaguy2> brb
534 2011-10-10 14:29:39 <gavinandresen> imsaguy2: as long as it remains impossible to shoot yourself in the foot by running it on a network-attached drive that you accidently run two copies of bitcoin against, sure....
535 2011-10-10 14:30:35 <BlueMatt-mobile> and again who the hell decided it was a good idea to put enter right below backspace
536 2011-10-10 14:30:57 <gavinandresen> BlueMatt-mobile: now you're just procrastinating, and I'm going to stop talking to you so you can be a good responsible history-learning person.
537 2011-10-10 14:31:28 <BlueMatt-mobile> I'm walking to lunch not much I could be doing
538 2011-10-10 14:31:42 <gavinandresen> mmmm, lunch, good idea.....
539 2011-10-10 14:32:25 <BlueMatt-mobile> Otoh most is the previous conversion was from my compsci lect
540 2011-10-10 14:34:03 <nanotube> gavinandresen: so basically you're saying... stuff a lockfile next to the wallet, eh? :)
541 2011-10-10 14:34:41 <gavinandresen> nanotube: there is already a lockfile in the datadir, but yes, do something smart
542 2011-10-10 14:35:16 <gavinandresen> (just reading wallet.dat from a different path is the easy-but-dumb way)
543 2011-10-10 14:35:31 <nanotube> right, i know there's a lockfile in datadir. :) now question is... is there a place in the wallet.dat file itself to put a lock flag?
544 2011-10-10 14:35:48 <nanotube> so we don't have to have two lockfiles one for blockchain-et-al and one for wallet.
545 2011-10-10 14:36:47 <freewil> that sounds dangerous... using the wallet.data file itself as a lockfile?
546 2011-10-10 14:36:49 <nanotube> btw, good point on the foot shooting generally - i didn't think of that before you mentioned it. :)
547 2011-10-10 14:37:31 <nanotube> freewil: well, wallet is a database... so just sticking a flag in there somewhere that says "this file is being used" should work. that said... if bitcoin crashes
548 2011-10-10 14:37:37 <nanotube> that'll leave wallet in perma-locked state
549 2011-10-10 14:37:40 <nanotube> which would be a pain
550 2011-10-10 14:37:45 <nanotube> requiring editing the db
551 2011-10-10 14:38:22 <freewil> nanotube, but what if two instances at the same time try to update the flag?
552 2011-10-10 14:38:24 <nanotube> well, we'll let imsaguy2 figure it out :D
553 2011-10-10 14:38:40 <nanotube> freewil: same thing as if two instances try to create the lock file at the same time
554 2011-10-10 14:38:43 <nanotube> one of them will win. :)
555 2011-10-10 14:39:06 <freewil> well i guess, is the check and update atomic?
556 2011-10-10 14:39:28 <gavinandresen> The -datadir lock mechanism works nicely (boost has solved all of the 'what if it crashes' problems in a cross-platform way for us), extending that is probably the right thing to do
557 2011-10-10 14:39:41 <gavinandresen> (if wallet is not in datadir, write a second lockfile....)
558 2011-10-10 14:40:51 <nanotube> yea probably beats reinventing the wheel
559 2011-10-10 14:48:04 <gribble> The average time to generate a block at 300000000 Khps, given the supplied difficulty of 94035.9021742, is 22 minutes and 26 seconds
560 2011-10-10 14:48:04 <luke-jr> ;;bc,calcd 300000000 94035.9021742
561 2011-10-10 14:49:35 <sipa> gavinandresen: just use a second lockfile in every case
562 2011-10-10 14:51:55 <imsaguy2> its not like lockfile's are that expensive
563 2011-10-10 14:51:59 <imsaguy2> it'd be an edge case
564 2011-10-10 14:52:03 <imsaguy2> not every user is going to use it
565 2011-10-10 14:53:10 <freewil> sure would make it easier to share the blockchain across different wallets
566 2011-10-10 14:53:22 <imsaguy2> yes
567 2011-10-10 14:53:49 <imsaguy2> and if both datadir and wallet location are specified, let wallet location win
568 2011-10-10 14:54:06 <freewil> yes
569 2011-10-10 14:54:10 <Graet> yes
570 2011-10-10 14:54:25 <imsaguy2> ok, that will be tonight's project
571 2011-10-10 14:54:27 <sipa> "win" ?
572 2011-10-10 14:54:54 <imsaguy2> if you specify both a datadir and a wallet location, it will use the wallet location
573 2011-10-10 14:55:04 <sipa> what else?
574 2011-10-10 14:55:14 <sipa> use the datadir for the data, use the walletdir for the wallet
575 2011-10-10 14:55:36 <sipa> the question is whether you do it within the same database environnement or not
576 2011-10-10 14:55:42 <strat-o-caster> How about the bitcoin technology as a voting system? https://github.com/rbragg/PeerElect
577 2011-10-10 14:55:43 <sipa> i.e., whether you use the same db log files
578 2011-10-10 14:55:47 <luke-jr> yay, I think I have merged mining working on Eligius :P
579 2011-10-10 14:55:58 <strat-o-caster> I'm not a good enough developer for this...
580 2011-10-10 14:56:09 <sipa> bitcoin is a voting system
581 2011-10-10 14:56:20 <luke-jr> strat-o-caster: how do you prevent someone from voting twice?
582 2011-10-10 14:56:27 <sipa> miners vote for transactions and blocks with their cpu/gpu power
583 2011-10-10 14:56:50 <imsaguy2> I'd lean towards two seperate sets of log files
584 2011-10-10 14:56:55 <strat-o-caster> read on the github my thoughts... too much for this quick chat...
585 2011-10-10 14:58:31 <strat-o-caster> Also, too much for me to develop.  I am not as good as all of you at this kind of thing... just a thought...
586 2011-10-10 14:58:53 <strat-o-caster> I am a simple musician...
587 2011-10-10 14:58:56 <luke-jr> fwiw, people are already reporting real-world problems with merged-mining-proxy
588 2011-10-10 15:09:04 <strat-o-caster> sipa: yes, your right, it is!  with just a few tweeks, it could be a real along-side simple voting system.
589 2011-10-10 15:09:45 <sipa> strat-o-caster: i'm not sure you want voting proportional to computation power, for anything but the bitcoin chain itself
590 2011-10-10 15:10:06 <luke-jr> gavinandresen: hey, aren't you going to merge the latest fixes from the qt branch? :x
591 2011-10-10 15:11:07 <gavinandresen> I don't know nuthin about fixes on the qt branch.  Poke the fixers and tell them to ask me to pull
592 2011-10-10 15:11:32 <luke-jr> sigh
593 2011-10-10 15:17:22 <strat-o-caster> sipa: your right, I don't want it to be proportional to computation power!  that would be unfair.  I have a simple outline here https://github.com/rbragg/PeerElect.  Ov course this would never take place of voting as of today yet...
594 2011-10-10 15:18:22 <sipa> strat-o-caster: afaik there are far better (e.g., more anonymous) ways to do digital voting
595 2011-10-10 15:18:40 <strat-o-caster> forget about the concept of the minors.  there would be no need for that.
596 2011-10-10 15:19:29 <nathan7> anonymous voting without the possibility of double-voting is impossible, no?
597 2011-10-10 15:19:40 <sipa> how can you do decentralized voting? who makes sure no-one votes twice?
598 2011-10-10 15:20:27 <gmaxwell> Timecube elections.
599 2011-10-10 15:20:54 <strat-o-caster> Take a read through my thoughts at my simple github page.  It addresses these
600 2011-10-10 15:21:32 <gmaxwell> It does?"
601 2011-10-10 15:21:38 <gmaxwell> "In order for any peer to vote, each peer would have to register with the creator of the election by means outside the scope of this project."
602 2011-10-10 15:21:56 <gmaxwell> Sounds like a complete copout on the only technically difficult part.
603 2011-10-10 15:21:59 <sipa> ok, so it's just not decentralized
604 2011-10-10 15:22:09 <strat-o-caster> It's not perfect, but the burdon is on the person who creates the vote...
605 2011-10-10 15:22:23 <strat-o-caster> yes it is
606 2011-10-10 15:22:45 <sipa> you need a central authority to give out the voting rights
607 2011-10-10 15:22:54 <strat-o-caster> It does not solve all the problems today, but many...
608 2011-10-10 15:22:57 <gmaxwell> You also don't describe at all how the blinding is to work but I guess thats okay because there are solutions for that, even if you don't know about them.
609 2011-10-10 15:23:08 <gmaxwell> It doesn't solve anything because it doesn't exist.
610 2011-10-10 15:23:40 <strat-o-caster> Of course it does not exists yet, what does that mean?
611 2011-10-10 15:24:42 <gmaxwell> well, if it doesn't exist it doesn't solve anything. It's not worth any of my attention while it is pure vapor I can't make any useful suggestions or evaluate it against alternatives.
612 2011-10-10 15:25:12 <strat-o-caster> Let me put out front, I am looking for peer review! this does not exists yet.  It is just a thought.
613 2011-10-10 15:25:38 <strat-o-caster> I welcome criticism!
614 2011-10-10 15:25:51 <gmaxwell> I think it's too vague at this point to get more review that you've just recieved from us.
615 2011-10-10 15:26:40 <strat-o-caster> I am not a developer, and this is not developed.  Just a thought. sorry.  I will go elsewhere.
616 2011-10-10 15:26:50 <gmaxwell> strat-o-caster: look up chaumian blinding for how you can actually accomplish what you've described.
617 2011-10-10 15:26:57 <gmaxwell> Oh well.
618 2011-10-10 15:27:04 <gmaxwell> Am I mean?
619 2011-10-10 15:30:04 <makomk> https://bitcointalk.org/index.php?topic=47609.0 - another boredom-relief project completed. Wonder if any pools will use it...
620 2011-10-10 15:30:31 <[Tycho]> Hello.
621 2011-10-10 15:33:30 <makomk> Hiya Tycho. Don't suppose you're in the process of writing/have written a way of generating getwork responses outside of bitcoind? It seems to be an oddly popular thing to code...
622 2011-10-10 15:34:04 <[Tycho]> Generating new work for miners ?
623 2011-10-10 15:34:19 <makomk> Yep.
624 2011-10-10 15:38:06 <[Tycho]> No. It's a good idea, but my bitcoind optimizations allow me to use it.
625 2011-10-10 15:39:09 <makomk> Ah, I see. Makes sense.
626 2011-10-10 15:39:09 <TD[gone]> makomk: i think shadders is implementing that as well
627 2011-10-10 15:39:28 <strat-o-caster> Hi, I need to go for a while on another channel.  Thanks for the invite!  Lots of issues, lots of solutions.  peace!
628 2011-10-10 15:39:51 <makomk> TD: yeah, he mentioned he was when I talked about it earlier, hence my comment about it being oddly popular.
629 2011-10-10 15:40:52 <TD> well, i guess it makes large pools cheaper to run
630 2011-10-10 15:41:08 <TD> and it's an obvious Next Step along with the merged mining stuff
631 2011-10-10 15:41:20 <TD> although i kind of wish the p2pool stuff would take off more
632 2011-10-10 15:41:26 <TD> that's how things should work
633 2011-10-10 15:41:41 <makomk> Yeah, I'm guessing it might have something to do with merged mining; certainly that's what inspired me.
634 2011-10-10 15:41:56 <TD> i'm glad to see the merged mining stuff take off
635 2011-10-10 15:42:00 <TD> that's what i wanted when i wrote the wiki page.
636 2011-10-10 15:43:47 <luke-jr> gavinandresen: missed these https://github.com/bitcoin/bitcoin/pull/578
637 2011-10-10 15:43:52 <luke-jr> (I missed them, that is)
638 2011-10-10 15:45:29 <CIA-101> bitcoin: Luke Dashjr bitcoind_build_improvements * ra1e0bb5a09be bitcoind-personal/src/makefile.unix: Allow users to customize CXX, CXXFLAGS, and LDFLAGS normally
639 2011-10-10 15:55:02 <makomk> "[ERROR] Failed to execute goal on project bitcoin-poolserverj: Could not resolve dependencies for project com.shadworld:bitcoin-poolserverj:jar:0.0.2-SNAPSHOT" - I really hate Java...
640 2011-10-10 15:55:44 <urstroyer> you get that on execute @makomk?
641 2011-10-10 15:56:42 <makomk> Nope, compile.
642 2011-10-10 15:57:57 <TD> makomk: which dependency did it fail to get?
643 2011-10-10 15:58:34 <diki> makomk:i hate python more
644 2011-10-10 15:58:40 <makomk> "Could not find artifact com.shadworld:shadtools-sql:jar:0.0.1-SNAPSHOT" - I think?
645 2011-10-10 16:00:39 <TD> hmm not sure. maybe his website is down
646 2011-10-10 16:02:05 <makomk> It's meant to be a local package in the hg repository. Turns out I wasn't installing it into Maven's repository correctly.
647 2011-10-10 16:05:19 <CIA-101> bitcoin: Luke Dashjr * r3ee9a470ddf4 gentoo/net-p2p/bitcoind/ (8 files): net-p2p/bitcoind: Bugfix: typo in BOOST_INC var name :p
648 2011-10-10 16:05:20 <CIA-101> bitcoin: Luke Dashjr * re21b6cdeab68 gentoo/net-p2p/bitcoind/ (3 files in 2 dirs): net-p2p/bitcoind-9999: Update to latest HEAD
649 2011-10-10 16:06:45 <makomk> "package org.apache.commons.lang does not exist" - oh, for...
650 2011-10-10 16:08:06 <luke-jr> >_<
651 2011-10-10 16:09:04 <jgarzik> gavinandresen / BlueMatt: rc1 builds in process?
652 2011-10-10 16:10:31 <BlueMatt> jgarzik: gitian xcompile scripts not yet done...so no win32 rc1 builds yet possible...same for linux though those shouldnt be hard to write
653 2011-10-10 16:11:05 <gavinandresen> jgarzik: do you have some time to help do builds?
654 2011-10-10 16:11:38 <gavinandresen> from-a-trusted-developer rc1 builds is fine with me for now...
655 2011-10-10 16:12:02 <BlueMattBot> Project Bitcoind-Sanitytest build #62: FAILURE in 1 hr 0 min: http://jenkins.bluematt.me/job/Bitcoind-Sanitytest/62/
656 2011-10-10 16:12:02 <jgarzik> gavinandresen: I can help with uploading...  but I intentionally avoid creating builds for patent-related reasons
657 2011-10-10 16:12:06 <BlueMatt> for rc I would agree
658 2011-10-10 16:12:25 <BlueMatt> that is probably a result of the change in linking...
659 2011-10-10 16:12:48 <BlueMatt> (something else for the todo)
660 2011-10-10 16:13:13 <BlueMatt> (though last several rcs do need to be gitian as changes in build process has caused issues in the past)
661 2011-10-10 16:15:16 <CIA-101> bitcoin: Luke Dashjr * r946a3cfb6555 gentoo/net-p2p/bitcoind/ (Manifest bitcoind-0.5.0_rc1.ebuild): net-p2p/bitcoind-0.5.0_rc1
662 2011-10-10 16:25:50 <makomk> shadders: has anyone compiled PoolServerJ using maven recently, out of interest?
663 2011-10-10 16:30:55 <CIA-101> bitcoin: Luke Dashjr 0.4.x * raec5c5fe2629 bitcoind-stable/ (5 files in 4 dirs): Bump version to 0.4.1
664 2011-10-10 16:31:35 <luke-jr> gavinandresen: if I make a tarball from that 0.4.1rc1 source, will you post it?
665 2011-10-10 16:32:51 <gavinandresen> luke-jr: too busy with 0.5 to review a 0.4.1, sorry
666 2011-10-10 16:33:15 <luke-jr> gavinandresen: np, I mean so other people can find it to review ;P
667 2011-10-10 16:34:54 <BlueMatt> luke-jr: where is the git repo with 0.4.1?
668 2011-10-10 16:35:40 <luke-jr> BlueMatt: http://gitorious.org/+bitcoin-stable-developers/bitcoin/bitcoind-stable
669 2011-10-10 16:39:23 <BlueMatt> nice, looks good to me
670 2011-10-10 16:41:51 <luke-jr> yeah, not easy to break stuff when there's only a couple of minor changes XD
671 2011-10-10 16:42:04 <BlueMatt> heh true
672 2011-10-10 16:42:36 <luke-jr> BlueMatt: any chance you wanna make some gitian builds? :D
673 2011-10-10 16:43:33 <BlueMatt> if I have time, will do
674 2011-10-10 16:45:20 <BlueMatt> luke-jr: oh, hold 0.4.1 till there is a fix for the win32 locking issue if you could please
675 2011-10-10 16:47:06 <luke-jr> BlueMatt: I'm on the same schedule as 0.5.0
676 2011-10-10 16:47:15 <luke-jr> BlueMatt: does that issue affect 0.4? O.o
677 2011-10-10 16:47:23 <BlueMatt> yes it effects 0.4.0
678 2011-10-10 16:47:36 <BlueMatt> thats the problem with no one using windows and no windows testers
679 2011-10-10 16:47:46 <BlueMatt> well more like no testers...
680 2011-10-10 16:47:49 <luke-jr> :p
681 2011-10-10 16:50:17 <CIA-101> bitcoin: Luke Dashjr * rc7eb6aa1ca24 gentoo/net-p2p/bitcoind/ (Manifest bitcoind-0.4.1_rc1.ebuild): net-p2p/bitcoind-0.4.1_rc1
682 2011-10-10 16:51:08 <c_k> I suspect there is a bug in bitcoind that stops more than ~120 connections even though something like maxconnections=512 is specified
683 2011-10-10 16:51:50 <c_k> we need testers?
684 2011-10-10 16:51:54 <BlueMatt> always
685 2011-10-10 16:51:54 <c_k> damn, I'm in
686 2011-10-10 16:51:57 <c_k> where do I sign up
687 2011-10-10 16:52:10 <BlueMatt> ask AlexWaters
688 2011-10-10 16:52:12 <c_k> ok
689 2011-10-10 16:52:12 <luke-jr> c_k: my (heavily patched) bitcoind has well over 120 often
690 2011-10-10 16:52:23 <luke-jr> c_k: just grab the git branches and test? :P
691 2011-10-10 16:52:30 <c_k> luke-jr: yeah I've heard about your ~800 connections ;)
692 2011-10-10 16:52:48 <c_k> I'm keen to get the standard release going over ~120 though
693 2011-10-10 16:53:05 <BlueMatt> shouldnt be a problem
694 2011-10-10 16:53:14 <c_k> and there lies the problem
695 2011-10-10 16:53:20 <c_k> it never seems to do it
696 2011-10-10 16:53:35 <BlueMatt> debug.log show anything interesting, or iptables/router limit?
697 2011-10-10 16:53:43 <c_k> hmm, I should look
698 2011-10-10 16:54:17 <c_k> from what I can tell it is a common problem
699 2011-10-10 16:54:57 <c_k> for anyone using the standard daemon
700 2011-10-10 16:54:58 <BlueMatt> Ive heard of it, never seen it (nor tried)
701 2011-10-10 16:55:03 <BlueMatt> memory usage limit?
702 2011-10-10 16:55:13 <BlueMatt> select() limit?
703 2011-10-10 16:55:21 <BlueMatt> fd limit?
704 2011-10-10 16:56:57 <luke-jr> select() limit is 1024 IIRC
705 2011-10-10 16:57:42 <makomk> Ick, the bitcoin messaging code looks ugly. I wish it did use select()
706 2011-10-10 16:58:01 <BlueMatt> all of the bitcoin code looks ugly
707 2011-10-10 16:58:08 <BlueMatt> its a fucking mess
708 2011-10-10 16:58:24 <makomk> Ah, apparently it does... it just polls elsewhere >.<
709 2011-10-10 16:58:28 <BlueMatt> luke-jr: so I thought, but it is customizable iirc
710 2011-10-10 16:58:53 <luke-jr> BlueMatt: at compile-time
711 2011-10-10 16:59:07 <BlueMatt> mmm
712 2011-10-10 16:59:08 <luke-jr> BlueMatt: select() is also O(n) to use
713 2011-10-10 16:59:18 <luke-jr> poll/variants are much faster/extensible ;P
714 2011-10-10 16:59:28 <BlueMatt> patches welcome ;)
715 2011-10-10 16:59:34 <TD> ugly is relative :)
716 2011-10-10 16:59:37 <luke-jr> I don't think I need over 1000 connections :
717 2011-10-10 16:59:44 <TD> i prefer the bitcoin code to some of the crap i've seen elsewhere
718 2011-10-10 17:00:12 <BlueMatt> heh there is always worse, but then again that isnt much of an excuse
719 2011-10-10 17:00:48 <BlueMatt> gavinandresen: what happened to the script someone mentioned which automatically converts the old wx translations to qt ones?
720 2011-10-10 17:00:53 <TD> i suspect satoshi learned (or did most of) his programming in the early/mid 90s
721 2011-10-10 17:00:54 <BlueMatt> why was that never used?
722 2011-10-10 17:00:58 <TD> it's that type of style
723 2011-10-10 17:01:40 <BlueMatt> that would make sense given the little we know about him
724 2011-10-10 17:02:22 <gavinandresen> BlueMatt: dunno, I'm looking for somebody who knows about translating stuff to organize the translating stuff stuff
725 2011-10-10 17:03:12 <BlueMatt> mmm, see discussion at #521
726 2011-10-10 17:03:59 <gavinandresen> translation patches very welcome.  Although half-assed translations might be worse than none at all.
727 2011-10-10 17:04:16 <BlueMatt> I would disagree
728 2011-10-10 17:05:05 <BlueMatt> something in your local language that makes more sense is better than a language you dont speak
729 2011-10-10 17:05:12 <gavinandresen> Vraiment?  Seems to me that a little-of-this and un peu de ca is maybe worse than all one or the other
730 2011-10-10 17:05:13 <BlueMatt> if you speak english too then yea, probably not...
731 2011-10-10 17:06:01 <gavinandresen> (excuse my french)
732 2011-10-10 17:08:37 <BlueMatt> hmmm...I thought I remembered someone writing a script to convert translations...guess not
733 2011-10-10 17:08:48 <BlueMatt> just seems like a shame to lose all of that...
734 2011-10-10 17:21:14 <makomk> Ewwww. I see how that works, and it's nasty.
735 2011-10-10 17:22:06 <luke-jr> makomk: I didn't even mess with that :P
736 2011-10-10 17:23:24 <TD> makomk: what a bizarre function
737 2011-10-10 17:24:02 <makomk> TD: apparently it's used to prevent the same work being used twice on the same chain...
738 2011-10-10 17:24:50 <TD> i assume the magic numbers are arbitrary
739 2011-10-10 17:25:06 <makomk> It selects a pseudo-random slot in the merged-mining Merkle tree that the work for a particular chain has to go in based on its chain ID and an arbitrarily-selected nonce (which merged-mine-proxy sets to 0)
740 2011-10-10 17:25:50 <makomk> I'm not sure merged-mine-proxy checks for collisions in which more than one chain claims the same slot. It doesn't look like it does.
741 2011-10-10 17:29:04 <makomk> In theory I guess you should increment the nonce until there's no collision, giving up and increasing the merkle tree size if necessary.
742 2011-10-10 17:30:41 <TD> it's trying to construct a globally unique tree?
743 2011-10-10 17:30:42 <TD> why?
744 2011-10-10 17:35:45 <makomk> Not exactly; it needs to come up with a combination of nonce and merkle tree size for which every aux chain gets assigned a unique slot in the merkle tree. I guess whoever designed this didn't want to explicitly record which chain went in which slot for scalability reasons.
745 2011-10-10 17:40:23 <CIA-101> bitcoin: Luke Dashjr * r90817d0264f7 gentoo/app-misc/cgminer/ (Manifest cgminer-2.0.6.ebuild): app-misc/cgminer-2.0.6
746 2011-10-10 17:54:54 <diki> ,,seen conman
747 2011-10-10 17:54:55 <gribble> (seen [<channel>] <nick>) -- Returns the last time <nick> was seen and what <nick> was last seen saying. <channel> is only necessary if the message isn't sent on the channel itself. <nick> may contain * as a wildcard.
748 2011-10-10 17:55:02 <diki> ,,seen bitcoin conman