1 2012-06-01 00:00:15 codder1 has joined
2 2012-06-01 00:00:24 <codder1> Hi
3 2012-06-01 00:00:37 <codder1> Anyone here familliar with bitcoind?
4 2012-06-01 00:00:49 <BlueMatt> ask a question, dont ask to ask ;)
5 2012-06-01 00:01:52 wizkid057 has quit (Quit: changing servers)
6 2012-06-01 00:02:00 <codder1> Ok, I am using bitcoind to accept payments on my site. I would like to know if its possible to get the account address that received the funds
7 2012-06-01 00:02:15 <codder1> Not the sender's address, but the receiver's address.
8 2012-06-01 00:02:23 <codder1> Is it possible?
9 2012-06-01 00:02:24 <sipa> codder1: doesn't listtransactions tell you that?
10 2012-06-01 00:02:32 <sipa> under "address"
11 2012-06-01 00:02:49 <codder1> From what I know, it tells the sender's address but not the receiver's address
12 2012-06-01 00:03:00 <sipa> there is no such thing as a "sender's address" in bitcoin
13 2012-06-01 00:03:19 <codder1> oh!
14 2012-06-01 00:03:20 <luke-jr> (rather, bitcoind hides it)
15 2012-06-01 00:03:48 wizkid057 has joined
16 2012-06-01 00:03:49 <sipa> luke-jr: there is "optionally, recognizable addresses the input coins were previously sent to"
17 2012-06-01 00:04:02 <codder1> So I would need to create a loop and check every single address on my site at every single second to see if there is a new transaction?
18 2012-06-01 00:04:31 <luke-jr> codder1: listtransactions will show all
19 2012-06-01 00:04:33 <gmaxwell> codder1: no, you create a new payment address for every sale and then you know which one based on which address got paid.
20 2012-06-01 00:06:28 <codder1> Ok, I am creating a new payment address for every new client on my site. Since its not event based, will need to create a delay loop to check for new payments on all addresses. Assuming I may have over 2000 clients.
21 2012-06-01 00:06:30 <doublec> you still have to poll though to see if the payment was received
22 2012-06-01 00:06:58 <codder1> omg, I presume that eats allot of CPU
23 2012-06-01 00:07:08 <doublec> codder1: you can poll listtransactions
24 2012-06-01 00:07:13 <doublec> codder1: and look at all new transactions
25 2012-06-01 00:07:24 <doublec> codder1: and see which ones are for addresses you are execpting payments for
26 2012-06-01 00:07:36 <doublec> codder1: you could even do this only when a block arrives
27 2012-06-01 00:07:40 <doublec> codder1: instead of on a timer
28 2012-06-01 00:07:53 sirk390 has quit (Quit: Leaving.)
29 2012-06-01 00:07:56 <doublec> codder1: bitcoind has a way of running something when a block arrives iirc
30 2012-06-01 00:08:59 <doublec> I made the mistake of "poll addresses for payments" in my namecoin exchange. I don't recommend it.
31 2012-06-01 00:10:13 <luke-jr> codder1: -blocknotify "command"
32 2012-06-01 00:10:15 <codder1> I am using the NodeJS version. So I assume I can create a delay loop that checks for a new block number, then once it arrives, I simply loop all my addresses for new transactions
33 2012-06-01 00:10:41 <doublec> codder1: or loop all transactions in that block, looking for payments that belong to you
34 2012-06-01 00:10:52 <doublec> codder1: that should be more efficient
35 2012-06-01 00:10:59 <luke-jr> codder1: just use listtransactions to see *all* transactions to you
36 2012-06-01 00:12:35 <codder1> Ok, I am just finding it crazy to loop 2000 addresses for new transactions at every block. Imagine if it gets to 50 000 users one day!
37 2012-06-01 00:13:19 <doublec> codder1: using luke-jr or my approach you don't need to
38 2012-06-01 00:13:33 <doublec> codder1: either one of those only processes the transactions you actually received
39 2012-06-01 00:13:37 * luke-jr smacks codder1 for not reading
40 2012-06-01 00:14:09 <doublec> because you are correct, the loop 2000 addresses approach is indeed crazy
41 2012-06-01 00:14:19 Graet has joined
42 2012-06-01 00:16:26 <gmaxwell> wow.
43 2012-06-01 00:16:54 <gmaxwell> codder1: I am impressed by your immunity to assistance.
44 2012-06-01 00:18:40 <codder1> What if I create a higher bitcoin demmand, I think its not that bad after all.
45 2012-06-01 00:19:28 <codder1> But thank you very miuch for all your help guys. Once I get the whole concept one day, I will help others all well. I've already introduced plenty of new people ( entrepreneurs ) to this protocol.
46 2012-06-01 00:20:49 Cryo has quit (Ping timeout: 246 seconds)
47 2012-06-01 00:21:32 devrandom has quit (Remote host closed the connection)
48 2012-06-01 00:21:32 MobiusL has quit (Remote host closed the connection)
49 2012-06-01 00:22:31 devrandom has joined
50 2012-06-01 00:25:52 d34th has quit (Quit: Leaving)
51 2012-06-01 00:26:04 d34th has joined
52 2012-06-01 00:26:04 d34th has quit (Changing host)
53 2012-06-01 00:26:04 d34th has joined
54 2012-06-01 00:27:33 d34th has quit (Client Quit)
55 2012-06-01 00:29:17 d34th has joined
56 2012-06-01 00:29:18 d34th has quit (Changing host)
57 2012-06-01 00:29:18 d34th has joined
58 2012-06-01 00:37:39 <BlueMatt> sipa/gmaxwell: I added an -autoprune to prune during chain download, if you feel like benchmarking...
59 2012-06-01 00:38:48 <BlueMatt> its not looking terrible, at checkpoint 134444, on tmpfs, with -loadblock, I get pruning taking 7 seconds
60 2012-06-01 00:39:24 <BlueMatt> anyway...back to cblockstore
61 2012-06-01 00:41:25 phungi has quit (Quit: leaving)
62 2012-06-01 00:43:21 random_cat__ has quit (Ping timeout: 276 seconds)
63 2012-06-01 00:44:15 MobiusL has joined
64 2012-06-01 00:44:38 danbri has quit (Remote host closed the connection)
65 2012-06-01 00:45:03 phungus has quit (Remote host closed the connection)
66 2012-06-01 00:45:19 OneFixt has quit (Ping timeout: 246 seconds)
67 2012-06-01 00:46:43 p0s is now known as p0s-
68 2012-06-01 00:46:53 phungi has joined
69 2012-06-01 00:47:45 phungi_ has joined
70 2012-06-01 00:48:46 OneFixt has joined
71 2012-06-01 00:48:54 <Ukto> gmaxwell: does standard bitcoind throw an error when you use RPC send to an address in its own wallet?
72 2012-06-01 00:49:12 paraipan has quit (Ping timeout: 276 seconds)
73 2012-06-01 00:49:18 <gmaxwell> No.
74 2012-06-01 00:49:50 <Ukto> hmm, mine is throwing back an uncaught error from it
75 2012-06-01 00:49:59 <Ukto> was just gonna work around it, and pre-check before attempting it
76 2012-06-01 00:50:01 <Ukto> just curious
77 2012-06-01 00:50:29 darkee has quit (Ping timeout: 276 seconds)
78 2012-06-01 00:51:26 random_cat__ has joined
79 2012-06-01 00:55:03 phungi_ has quit (Quit: Reconnecting)
80 2012-06-01 00:56:27 phungi_ has joined
81 2012-06-01 01:00:24 ahbritto_ has quit (Remote host closed the connection)
82 2012-06-01 01:02:13 darkee has joined
83 2012-06-01 01:03:13 danbri has joined
84 2012-06-01 01:04:08 danbri has quit (Remote host closed the connection)
85 2012-06-01 01:04:18 RainbowDashh has joined
86 2012-06-01 01:07:04 elkingrey has quit (Quit: Leaving)
87 2012-06-01 01:15:05 d34th has quit (Quit: Leaving)
88 2012-06-01 01:15:11 paraipan has joined
89 2012-06-01 01:18:36 D34TH has joined
90 2012-06-01 01:31:35 balicuzz has joined
91 2012-06-01 01:33:10 osmosis has quit (Quit: Leaving)
92 2012-06-01 01:40:57 minimoose has joined
93 2012-06-01 01:43:11 eoss has quit (Read error: Connection reset by peer)
94 2012-06-01 01:47:37 agricocb has quit (Ping timeout: 246 seconds)
95 2012-06-01 01:53:05 balicuzz is now known as stonewalljackson
96 2012-06-01 01:54:35 Skaag has joined
97 2012-06-01 01:56:41 <gribble> New news from bitcoinrss: TheBlueMatt opened pull request 1408 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1408>
98 2012-06-01 01:58:59 Zarutian has joined
99 2012-06-01 02:03:08 stonewalljackson has quit ()
100 2012-06-01 02:04:59 p0s- has quit (Read error: Connection reset by peer)
101 2012-06-01 02:09:46 andytoshi has joined
102 2012-06-01 02:13:55 enquirer_ has joined
103 2012-06-01 02:16:28 enquirer has quit (Ping timeout: 252 seconds)
104 2012-06-01 02:16:31 enquirer_ is now known as enquirer
105 2012-06-01 02:16:49 Hasbro has quit (Ping timeout: 245 seconds)
106 2012-06-01 02:19:43 RainbowDashh has quit (Quit: RainbowDashh)
107 2012-06-01 02:36:52 RainbowDashh has joined
108 2012-06-01 02:37:06 MobiusL has quit (Ping timeout: 276 seconds)
109 2012-06-01 02:37:24 TheSeven has quit (Disconnected by services)
110 2012-06-01 02:37:32 [7] has joined
111 2012-06-01 02:38:43 osmosis has joined
112 2012-06-01 02:57:04 MobiusL has joined
113 2012-06-01 02:59:25 codder1 has quit (Quit: Page closed)
114 2012-06-01 03:04:05 tower has quit (Quit: | ReactOS - The FOSS alternative to MS Windows! | http://www.reactos.org/ | join #ReactOS |)
115 2012-06-01 03:05:26 Maged has joined
116 2012-06-01 03:06:44 tower has joined
117 2012-06-01 03:06:47 tower has quit (Changing host)
118 2012-06-01 03:06:47 tower has joined
119 2012-06-01 03:12:58 agricocb has joined
120 2012-06-01 03:15:45 paraipan has quit (Quit: Saliendo)
121 2012-06-01 03:17:51 one_zero has joined
122 2012-06-01 03:20:39 wasabi1 has quit (Read error: Connection reset by peer)
123 2012-06-01 03:23:30 brwyatt is now known as brwyatt|Away
124 2012-06-01 03:23:35 brwyatt is now known as Away!~brwyatt@pool-96-226-236-130.dllstx.fios.verizon.net|brwyatt
125 2012-06-01 03:24:00 da2ce7 has quit (Read error: Connection reset by peer)
126 2012-06-01 03:24:49 egecko has quit (Quit: ~ Trillian Astra - www.trillian.im ~)
127 2012-06-01 03:26:01 da2ce7 has joined
128 2012-06-01 03:26:16 Guest77323 has joined
129 2012-06-01 03:26:43 Guest77323 has left ()
130 2012-06-01 03:27:40 Diablo-D3 has joined
131 2012-06-01 03:32:17 RainbowDashh has quit (Quit: RainbowDashh)
132 2012-06-01 03:41:43 Hasbro has joined
133 2012-06-01 03:44:23 RainbowDashh has joined
134 2012-06-01 03:45:19 Zarutian has quit (Quit: Zarutian)
135 2012-06-01 03:48:59 RainbowDashh has quit (Client Quit)
136 2012-06-01 04:03:00 graingert has quit (Read error: Connection reset by peer)
137 2012-06-01 04:05:47 minimoose has quit (Quit: minimoose)
138 2012-06-01 04:15:30 da2ce799 has joined
139 2012-06-01 04:17:35 da2ce7 has quit (Ping timeout: 252 seconds)
140 2012-06-01 04:18:22 da2ce799 is now known as da2ce7
141 2012-06-01 04:19:07 Skaag has quit (Read error: Connection reset by peer)
142 2012-06-01 04:19:39 Skaag has joined
143 2012-06-01 04:20:14 RainbowDashh has joined
144 2012-06-01 04:24:26 da2ce745 has joined
145 2012-06-01 04:26:03 da2ce7 has quit (Ping timeout: 250 seconds)
146 2012-06-01 04:27:31 ivan\ has quit (Quit: ERC Version 5.3 (IRC client for Emacs))
147 2012-06-01 04:28:37 ivan\ has joined
148 2012-06-01 04:33:29 D34TH has quit (Quit: Leaving)
149 2012-06-01 04:42:18 wladston has quit (Quit: Leaving.)
150 2012-06-01 04:46:49 RainbowDashh has quit (Quit: RainbowDashh)
151 2012-06-01 04:46:51 Hasbro has quit (Ping timeout: 250 seconds)
152 2012-06-01 05:00:41 maqr has quit (Ping timeout: 245 seconds)
153 2012-06-01 05:04:55 mmoya has joined
154 2012-06-01 05:05:46 RainbowDashh has joined
155 2012-06-01 05:13:46 ThomasV has joined
156 2012-06-01 05:19:10 danbri has joined
157 2012-06-01 05:20:32 danbri has quit (Read error: Connection reset by peer)
158 2012-06-01 05:20:36 Joric has quit ()
159 2012-06-01 05:20:47 danbri has joined
160 2012-06-01 05:23:19 Maged has quit (Quit: ChatZilla 0.9.88.2 [Firefox 12.0/20120420145725])
161 2012-06-01 05:25:56 danbri_ has joined
162 2012-06-01 05:26:01 danbri has quit (Read error: Connection reset by peer)
163 2012-06-01 05:27:40 brwyatt is now known as brwyatt|Away
164 2012-06-01 05:28:11 danbri has joined
165 2012-06-01 05:28:34 danbri_ has quit (Read error: Connection reset by peer)
166 2012-06-01 05:32:23 danbri has quit (Remote host closed the connection)
167 2012-06-01 05:38:54 danbri has joined
168 2012-06-01 05:46:42 sytse has quit (Ping timeout: 272 seconds)
169 2012-06-01 05:47:01 sytse has joined
170 2012-06-01 05:53:27 da2ce745 is now known as da2ce7
171 2012-06-01 05:54:39 danbri has quit (Read error: Connection reset by peer)
172 2012-06-01 05:55:01 danbri has joined
173 2012-06-01 05:57:30 danbri has quit (Read error: Connection reset by peer)
174 2012-06-01 05:57:37 danbri has joined
175 2012-06-01 05:57:53 danbri has quit (Remote host closed the connection)
176 2012-06-01 06:02:04 TimothyA has quit (Read error: Connection reset by peer)
177 2012-06-01 06:21:35 dvide has joined
178 2012-06-01 06:24:25 t7 has joined
179 2012-06-01 06:25:20 wizkid057 has quit (Ping timeout: 272 seconds)
180 2012-06-01 06:28:31 Snapman[afkers] is now known as Snapman
181 2012-06-01 06:29:37 t7_ has joined
182 2012-06-01 06:31:07 t7 has quit (Ping timeout: 246 seconds)
183 2012-06-01 06:31:11 t7_ is now known as t7
184 2012-06-01 06:34:41 Bigpiggy01Mining is now known as NeedzTweezerstoF
185 2012-06-01 06:36:11 ThomasV has quit (Ping timeout: 252 seconds)
186 2012-06-01 06:42:53 chrisb__ has joined
187 2012-06-01 06:44:11 ThomasV has joined
188 2012-06-01 06:44:25 maqr has joined
189 2012-06-01 06:46:30 ovidiusoft has joined
190 2012-06-01 06:47:56 RainbowDashh has quit (Quit: RainbowDashh)
191 2012-06-01 06:49:46 RainbowDashh has joined
192 2012-06-01 06:50:32 <gmaxwell> The drm in this is an astonishing waste of effort, http://www.tricone-mining.com/faq.html
193 2012-06-01 06:50:40 <gmaxwell> It makes me sad.
194 2012-06-01 06:51:31 ThomasV has quit (Ping timeout: 245 seconds)
195 2012-06-01 06:51:36 Joric has joined
196 2012-06-01 06:51:38 <gmaxwell> I'm glad its not bad for bitcoin like some other crazy things people have floated in relation to mining hardware. but geesh.
197 2012-06-01 06:51:44 Joric has quit (Changing host)
198 2012-06-01 06:51:44 Joric has joined
199 2012-06-01 06:52:47 JZavala has quit (Ping timeout: 244 seconds)
200 2012-06-01 06:54:26 RainbowDashh has quit (Ping timeout: 245 seconds)
201 2012-06-01 06:54:31 RainbowDashh has joined
202 2012-06-01 07:01:23 <JFK911> t l d r looks like a scam to me
203 2012-06-01 07:05:18 <Diablo-D3> JFK911: its not
204 2012-06-01 07:05:30 <Diablo-D3> he gives you the miner and the bitstream for free
205 2012-06-01 07:05:44 <Diablo-D3> all it does is shaves a little off the top
206 2012-06-01 07:05:46 osmosis has quit (Ping timeout: 252 seconds)
207 2012-06-01 07:06:20 <JFK911> see if he reduced that to "get free miner and get 80% of the btc" that is 9 words
208 2012-06-01 07:06:34 <weex> it's 20%?
209 2012-06-01 07:06:44 <JFK911> i didn't read through all the babble to find out
210 2012-06-01 07:06:51 <JFK911> i saw "signcrypted" and hit the x
211 2012-06-01 07:07:08 <Diablo-D3> 20%? no.
212 2012-06-01 07:07:18 <Diablo-D3> whatever 270/258 is
213 2012-06-01 07:07:27 <Diablo-D3> 5%?
214 2012-06-01 07:07:28 <Diablo-D3> w/e
215 2012-06-01 07:07:37 <Diablo-D3> JFK911: heres the big part
216 2012-06-01 07:07:40 <JFK911> 258/270 is 95%
217 2012-06-01 07:07:43 RainbowDashh has quit (Quit: RainbowDashh)
218 2012-06-01 07:07:48 <Diablo-D3> I can take his miner
219 2012-06-01 07:07:53 <Diablo-D3> and hack it to not send him the 5%.
220 2012-06-01 07:08:09 <Diablo-D3> so I get 270 mh on a chip that does 200.
221 2012-06-01 07:08:24 <JFK911> i think i could take his miner and properly power it and load my own code onto it
222 2012-06-01 07:08:34 Joric has quit (Ping timeout: 246 seconds)
223 2012-06-01 07:08:36 Joric_ has joined
224 2012-06-01 07:09:42 <Diablo-D3> power what?
225 2012-06-01 07:09:46 <Diablo-D3> its a piece of software.
226 2012-06-01 07:10:03 <JFK911> Xilinx's tools predict that it should achieve 315MH/s; however we have not yet encountered a board that can supply enough power to reach this figure. Typical performance is 270MH/s per chip.
227 2012-06-01 07:10:16 <JFK911> thats like one of three sentences i read
228 2012-06-01 07:10:22 RainbowDashh has joined
229 2012-06-01 07:11:44 phantomcircuit has quit (Read error: Connection reset by peer)
230 2012-06-01 07:12:38 <Diablo-D3> xilinix's tools are full of shit
231 2012-06-01 07:12:47 <Diablo-D3> it predicted like 250 on the existing streams
232 2012-06-01 07:13:50 <Diablo-D3> OH MAN
233 2012-06-01 07:13:56 <Diablo-D3> Is this like Butterfly Labs' \u201cBuyback Guarantee\u201d?
234 2012-06-01 07:13:56 <Diablo-D3> Butterwho?
235 2012-06-01 07:14:02 * Diablo-D3 does victory dance
236 2012-06-01 07:16:09 molecular has quit (Ping timeout: 252 seconds)
237 2012-06-01 07:17:18 molecular has joined
238 2012-06-01 07:18:06 <JFK911> ive found logic simulations to be timing-accurate
239 2012-06-01 07:18:26 <JFK911> of course i havent tried xilinx
240 2012-06-01 07:19:16 <JFK911> but i have aldec's simulator
241 2012-06-01 07:26:52 <Diablo-D3> stil
242 2012-06-01 07:26:58 <Diablo-D3> it all depends what BFL does now
243 2012-06-01 07:27:42 <Diablo-D3> because 270 mh is like
244 2012-06-01 07:27:49 <Diablo-D3> where did I put that chart
245 2012-06-01 07:29:54 <Diablo-D3> okay so
246 2012-06-01 07:30:30 <Diablo-D3> okay lets say cairnsmore1s sell for $1000 at full price
247 2012-06-01 07:30:38 <Diablo-D3> since the $640 was just a pre-order price and thats gone
248 2012-06-01 07:30:53 <Diablo-D3> thats 1080 mhash for 4 spartan 6s
249 2012-06-01 07:31:34 <Diablo-D3> thats $1/mh on both a cairnsmore1 and a lancelot (2 spartan 6 for $500)
250 2012-06-01 07:32:03 <Diablo-D3> err
251 2012-06-01 07:32:05 <Diablo-D3> 1 mh/$
252 2012-06-01 07:32:11 <Diablo-D3> and 28nm could beat 2 mh/$
253 2012-06-01 07:44:45 setkeh has quit (Ping timeout: 245 seconds)
254 2012-06-01 07:45:12 setkeh has joined
255 2012-06-01 07:50:53 pjorrit has quit (Remote host closed the connection)
256 2012-06-01 07:54:46 erle- has joined
257 2012-06-01 07:55:54 spaola has joined
258 2012-06-01 07:58:35 pierre` has quit (Ping timeout: 248 seconds)
259 2012-06-01 08:00:02 wizkid057 has joined
260 2012-06-01 08:00:35 <MC1984> you guys added a blocks remaining thing in the progress bar, nice
261 2012-06-01 08:00:47 <MC1984> the text should probably be black though
262 2012-06-01 08:00:56 <MC1984> white on neon green is a bit hard
263 2012-06-01 08:01:15 <Diablo-D3> MC1984: no
264 2012-06-01 08:01:18 <Diablo-D3> thats the qt theme
265 2012-06-01 08:01:19 <Diablo-D3> change yours.
266 2012-06-01 08:01:27 <Diablo-D3> mine is happily white on dark blue.
267 2012-06-01 08:01:39 <MC1984> what
268 2012-06-01 08:01:53 <Diablo-D3> dont what me.
269 2012-06-01 08:01:55 <weex> Diablo-D3: people have to change their qt theme?
270 2012-06-01 08:02:04 <Diablo-D3> weex: normally you do.
271 2012-06-01 08:02:11 <Diablo-D3> so it blends in with the rest of your desktop
272 2012-06-01 08:02:16 <MC1984> since when does bitcoin client have themes lol
273 2012-06-01 08:02:19 <Diablo-D3> unless you already run KDE, then its the same theme
274 2012-06-01 08:02:21 <Diablo-D3> MC1984: qt.
275 2012-06-01 08:02:39 <weex> MC1984: you on gnu/linux?
276 2012-06-01 08:02:44 <MC1984> what the blazez are you on about man
277 2012-06-01 08:02:51 <Diablo-D3> =|
278 2012-06-01 08:03:23 <MC1984> im using windows
279 2012-06-01 08:03:27 <Diablo-D3> oh
280 2012-06-01 08:03:33 <Diablo-D3> then quit using windows
281 2012-06-01 08:03:37 <Diablo-D3> because no one gives a fuck about windows.
282 2012-06-01 08:03:49 <MC1984> lol
283 2012-06-01 08:04:34 <neofutur> +1 for "quit using windows"
284 2012-06-01 08:04:46 <neofutur> will be easier to help yourself :p
285 2012-06-01 08:05:20 <MC1984> il get round to it one day, but for my own reasons not because some software snob prick on the internet told me to
286 2012-06-01 08:05:38 <MC1984> untill then, this shit is white on lime green
287 2012-06-01 08:06:27 <Diablo-D3> yes, because windows is lime green
288 2012-06-01 08:06:35 <Diablo-D3> why the fuck did microsoft ever do that
289 2012-06-01 08:06:37 <Diablo-D3> that was nuts
290 2012-06-01 08:06:45 <Diablo-D3> and the fucking fisher price window controls
291 2012-06-01 08:06:49 <Diablo-D3> WHY DID THEY DO THIS
292 2012-06-01 08:07:16 <MC1984> cos it used to be grey and marketing dept wanted something cool
293 2012-06-01 08:07:24 <Diablo-D3> LIME GREEN ISNT COOL
294 2012-06-01 08:07:31 <Diablo-D3> btw, what windows theme are you using?
295 2012-06-01 08:07:41 <Diablo-D3> because if you set it to windows classic, I think QT is smart enough to copy the colors
296 2012-06-01 08:07:58 <MC1984> noir
297 2012-06-01 08:08:07 <Diablo-D3> er, which one is that?
298 2012-06-01 08:08:15 <MC1984> the leaked one
299 2012-06-01 08:08:18 <Diablo-D3> because I only know of the fisher price one, the silver one, and the widows classic one
300 2012-06-01 08:08:29 <Diablo-D3> oh, and aero
301 2012-06-01 08:08:44 <Diablo-D3> aero went back to windows blue on that shit I think
302 2012-06-01 08:09:32 <MC1984> this text has turned black now wtf
303 2012-06-01 08:10:45 <Diablo-D3> pray bitcoin doesn't alter it any further
304 2012-06-01 08:11:16 Xunie has quit (Remote host closed the connection)
305 2012-06-01 08:12:41 <MC1984> gone bak to white now
306 2012-06-01 08:12:47 <MC1984> dafuq
307 2012-06-01 08:13:21 <MC1984> oh it turns blak when the window is unfocused
308 2012-06-01 08:13:24 <MC1984> interdasting
309 2012-06-01 08:16:08 sirk390 has joined
310 2012-06-01 08:17:25 <MC1984> bitcoin is not multi threaded rigth
311 2012-06-01 08:17:38 <Diablo-D3> not in the UI code
312 2012-06-01 08:17:49 <Diablo-D3> you're looking at QT weirdness
313 2012-06-01 08:18:16 <MC1984> im trying to work out why hain download is still so shit and how much room for optimization there is there
314 2012-06-01 08:18:29 <Diablo-D3> you're on 0.6.2 arent you?
315 2012-06-01 08:18:39 <MC1984> i am now
316 2012-06-01 08:19:31 <Diablo-D3> its much faster than it was
317 2012-06-01 08:20:57 <MC1984> avg 1 blok per 5 seconds here
318 2012-06-01 08:22:05 <MC1984> i still pray there are perhaps massive database structure efficiency gains to be made at some point
319 2012-06-01 08:22:09 <MC1984> or something
320 2012-06-01 08:22:43 <MC1984> as if i have a clue what im talking about
321 2012-06-01 08:22:49 <Diablo-D3> there is
322 2012-06-01 08:22:54 <Diablo-D3> gmaxwell and sipa have been working on it
323 2012-06-01 08:23:11 <MC1984> cool
324 2012-06-01 08:23:30 <MC1984> hopefully that an trim the size of the stored blockchain too maybe
325 2012-06-01 08:24:09 <MC1984> the speedups so far seem non existent on slightly older hardware from what ive seen and read
326 2012-06-01 08:24:37 <MC1984> which consigns a lot of people to thin clients only really, certainly anyone outside the west prob
327 2012-06-01 08:30:49 SomeoneWeird has quit (Ping timeout: 246 seconds)
328 2012-06-01 08:31:10 MrTiggr has quit (Ping timeout: 246 seconds)
329 2012-06-01 08:31:22 JZavala has joined
330 2012-06-01 08:32:23 RazielZ has joined
331 2012-06-01 08:34:33 MrTiggr has joined
332 2012-06-01 08:36:33 Guest68995 has joined
333 2012-06-01 08:38:21 <MC1984> wait is blockchain download and indexing etc limited by ram
334 2012-06-01 08:38:46 chrisb__ has quit (Quit: Leaving)
335 2012-06-01 08:40:26 Joric_ has quit ()
336 2012-06-01 08:45:38 <Eliel> MC1984: I was thinking the other day that instead of just seeking and reading the transaction data as needed, it could be done in batches. First reading the index for a large number of transactions, sorting out the data you need to read and then sorting those to disk order and then reading them all in one go.
337 2012-06-01 08:53:40 hnz_ has joined
338 2012-06-01 08:56:03 <MC1984> ok so
339 2012-06-01 08:56:44 <MC1984> currently txns propagate aroudn the whole network much faster than the time to first confirm them in a block
340 2012-06-01 08:57:07 <MC1984> but they are only considered secure after 1+ blocks preferrably more
341 2012-06-01 08:57:10 JZavala has quit (Ping timeout: 260 seconds)
342 2012-06-01 08:57:30 hnz has quit (Ping timeout: 256 seconds)
343 2012-06-01 08:58:07 <weex> MC1984: each block adds to the probably amount of work required to double-spend
344 2012-06-01 08:58:14 <weex> probable*
345 2012-06-01 08:58:28 <MC1984> would it be possible for a node to mitigate double spends in that 10 minute window by comparing the txns its making/receiving to what its hearing on the network right now?
346 2012-06-01 08:58:58 <MC1984> like a cursory double spend check until the first conf comes in
347 2012-06-01 08:59:02 <weex> yes, this is called the observer method
348 2012-06-01 08:59:20 <MC1984> is it a good idea
349 2012-06-01 08:59:21 <Diablo-D3> https://bitcointalk.org/index.php?topic=83985.msg934569#msg934569
350 2012-06-01 09:00:17 mmoya has quit (Ping timeout: 265 seconds)
351 2012-06-01 09:00:37 <MC1984> what
352 2012-06-01 09:00:54 <weex> again with the whats
353 2012-06-01 09:01:33 mmoya has joined
354 2012-06-01 09:02:09 <Diablo-D3> goddamnit, I read what weex said in the new york jew voice
355 2012-06-01 09:02:35 <MC1984> i am astounded of your seeminly arbitrary interjection good sir, pray you elucidate the meaning of this hypertextual link?
356 2012-06-01 09:02:56 <weex> Diablo-D3: fuggedaboutit
357 2012-06-01 09:03:08 <Diablo-D3> weex: organized crime voice.
358 2012-06-01 09:03:30 <Diablo-D3> MC1984: less than 50w bfl single 2.0
359 2012-06-01 09:03:47 <MC1984> is that good
360 2012-06-01 09:05:26 <Diablo-D3> yes
361 2012-06-01 09:05:33 <Diablo-D3> I like the single design, but 80w is just too much
362 2012-06-01 09:06:45 <MC1984> you can passive cool 50w
363 2012-06-01 09:07:13 <MC1984> needs design better than a cube tho
364 2012-06-01 09:07:38 <weex> that's just its gorgeous exterior
365 2012-06-01 09:08:05 <weex> inside i think it's mainly electrical tape and resistors
366 2012-06-01 09:08:17 <Diablo-D3> weex: erm, they've took photos of the inside
367 2012-06-01 09:08:32 <Diablo-D3> its a rather plain high density circuit board
368 2012-06-01 09:08:51 <Diablo-D3> high density as in what video cards and the parts of mobos around the cpu look like
369 2012-06-01 09:09:06 <Diablo-D3> MC1984: 80w you cant reliably passive cool, and 50 is, eh, too high
370 2012-06-01 09:09:18 <Diablo-D3> 25 or 33 could do it with a large enough copper heatsink
371 2012-06-01 09:09:42 hnz_ is now known as hnz
372 2012-06-01 09:13:36 <MC1984> ok so the thing i said
373 2012-06-01 09:13:44 <MC1984> i assume someone thought of it before
374 2012-06-01 09:15:08 <MC1984> seemslike a good idea to me, for instantly securing small txn up to a certain risk threshold
375 2012-06-01 09:15:19 <MC1984> POS in shops maybe
376 2012-06-01 09:15:42 <MC1984> if youre buying a car you can wait an hour for the deal to become airtight
377 2012-06-01 09:16:30 <Diablo-D3> erm
378 2012-06-01 09:16:37 <Diablo-D3> didnt someone already start working on that?
379 2012-06-01 09:16:39 <Diablo-D3> MC1984: btw
380 2012-06-01 09:16:46 <Diablo-D3> bitcoin isnt meant to replace day to day credit card shit
381 2012-06-01 09:16:57 <Diablo-D3> its meant to replace fedwire and online ordering both
382 2012-06-01 09:17:20 <MC1984> well thats a shame
383 2012-06-01 09:17:49 <sipa> for instant payments you want a third-party payment processor on top of bitcoin
384 2012-06-01 09:17:54 <Diablo-D3> yeah what sipa said
385 2012-06-01 09:18:01 <Diablo-D3> you need to centralize transaction management
386 2012-06-01 09:18:09 <Diablo-D3> transactions as in database transactions, not money transactions
387 2012-06-01 09:18:12 <MC1984> cool added cost
388 2012-06-01 09:18:43 <sipa> thankfully, because of bitcoin's inherent digital design, setting up such a processor should be trivial compared to setting up paypal
389 2012-06-01 09:18:47 <Diablo-D3> I could easily do 5 million transactions a second on a single shit computer
390 2012-06-01 09:19:00 <Diablo-D3> I just cant write them to disk fast enough.
391 2012-06-01 09:19:15 <MC1984> but why if you dont need to
392 2012-06-01 09:19:27 <Diablo-D3> MC1984: well I have to account for things
393 2012-06-01 09:19:49 <Diablo-D3> although maybe a future bitcoin transaction processor will use Lugh
394 2012-06-01 09:19:57 <Diablo-D3> (my highly parallel C library)
395 2012-06-01 09:19:59 <MC1984> wouldnt the thing i described provide a seller with a resonable confidence of not getting double spent for a given risk level
396 2012-06-01 09:20:10 <MC1984> normal everyday purchasing shit risk level
397 2012-06-01 09:20:14 <Diablo-D3> MC1984: it must be accountable.
398 2012-06-01 09:20:30 PiZZaMaN2K has quit (Ping timeout: 260 seconds)
399 2012-06-01 09:20:47 <MC1984> how would it not be accountable
400 2012-06-01 09:20:58 <Diablo-D3> joe shmoe needs to pay with instantdick and then immediately be able to whip out his cell phone and see the new transaction on instantdick
401 2012-06-01 09:21:07 <Diablo-D3> the transactions must be recorded.
402 2012-06-01 09:21:56 <MC1984> its just bitcoin with an extra good enough up to x risk level double pend preventer thing
403 2012-06-01 09:22:04 <Diablo-D3> nope, its not.
404 2012-06-01 09:22:12 <Diablo-D3> you have not properly conceptualized the problem.
405 2012-06-01 09:23:02 <MC1984> the problem is not getting double spent on upto maybe $100 of value or whatever
406 2012-06-01 09:23:10 <MC1984> and not having to wait 10 mins
407 2012-06-01 09:23:44 <Diablo-D3> not quite.
408 2012-06-01 09:23:54 <Diablo-D3> you'd have a reloadable bitcard.
409 2012-06-01 09:23:59 <MC1984> just a bitcoind that keeps an ear out for double spends as they come over the wire and calls shenanigans if it sees one, not a complex thing
410 2012-06-01 09:24:34 <sipa> MC1984: i think you want to hide that behind a third party as well
411 2012-06-01 09:24:35 PiZZaMaN2K has joined
412 2012-06-01 09:24:50 <MC1984> lemme guess a trusted third party
413 2012-06-01 09:25:27 <Diablo-D3> yes.
414 2012-06-01 09:25:31 <Diablo-D3> trust isnt an issue for small amounts
415 2012-06-01 09:25:37 <sipa> as a merchant you have a deal with a transaction processor; customers send transactions to transaction processor (but transactions to your address; they can't go run away with your money)
416 2012-06-01 09:26:00 <Diablo-D3> bitcoin is optimized for large transactions, not small ones
417 2012-06-01 09:26:06 <sipa> you pay the processor a small fee, and in return they insure you against double spends
418 2012-06-01 09:26:24 <sipa> they do this by for small transactions just not caring
419 2012-06-01 09:26:24 <MC1984> insurance = added cost
420 2012-06-01 09:26:27 <sipa> of course
421 2012-06-01 09:26:30 <sipa> nothing is free
422 2012-06-01 09:27:00 <MC1984> you guy are talking about something completely different to me
423 2012-06-01 09:27:17 <Diablo-D3> MC1984: you fail at basic computer science
424 2012-06-01 09:27:22 pierre` has joined
425 2012-06-01 09:27:36 <sipa> and for large transactions, they probe for double spends for a short time, before confirming the transaction
426 2012-06-01 09:27:59 <Diablo-D3> parallel, transactionally safe, or fast. pick two _on a good day_.
427 2012-06-01 09:28:20 <MC1984> you fail at understanding
428 2012-06-01 09:28:29 <MC1984> small txn just have to be safe enough
429 2012-06-01 09:28:32 <MC1984> not total safe
430 2012-06-01 09:28:48 <MC1984> no payment system is 100% secure
431 2012-06-01 09:28:50 <sipa> indeed, bitcoin is already far more safe for a merchant than credit cards
432 2012-06-01 09:28:58 <weex> MC1984: so you have to quantify the risk
433 2012-06-01 09:29:04 <Diablo-D3> MC1984: no, you're trying to describe the starbucks system
434 2012-06-01 09:29:14 <Diablo-D3> a few mistakes here and there doesnt cost anything overall
435 2012-06-01 09:29:47 <Diablo-D3> the payment and product-in-a-cup delivery system are async.
436 2012-06-01 09:30:07 <MC1984> what the shit are you on about seriously
437 2012-06-01 09:30:09 <Diablo-D3> problem is bitcoin is NOT a POS payment system and never will be
438 2012-06-01 09:30:21 <Diablo-D3> MC1984: are you fucking kidding me?
439 2012-06-01 09:30:48 <Diablo-D3> Googler, motherfucker, do you use it.
440 2012-06-01 09:30:57 <sipa> please
441 2012-06-01 09:31:05 <MC1984> yeah everyone seems to have given up and resorted to trusted parties and insurance and god damn bitcoin credit cards
442 2012-06-01 09:31:16 <Diablo-D3> sipa: you explain this to him, I give up
443 2012-06-01 09:31:21 <sipa> MC1984: depends what time-fram you're looking at
444 2012-06-01 09:31:42 <MC1984> POS time frame
445 2012-06-01 09:31:49 <weex> and what level of risk you're willing to accept
446 2012-06-01 09:31:53 <MC1984> with acceptable risk of not getting diked on as a merchant
447 2012-06-01 09:31:55 <Diablo-D3> POS time frame is not the best term
448 2012-06-01 09:32:02 <Diablo-D3> not all POS systems use the same time frame
449 2012-06-01 09:32:03 <sipa> but what bitcoin provides imho, is the ability to be completely responsible for your own money, without trusting anyway
450 2012-06-01 09:32:15 <sipa> that does not mean it can be used for any financial transaction
451 2012-06-01 09:32:20 <sipa> or that it is free
452 2012-06-01 09:32:20 <MC1984> say 30 seconds max then
453 2012-06-01 09:32:26 <Diablo-D3> 30 seconds is very high
454 2012-06-01 09:32:29 <Diablo-D3> for some.
455 2012-06-01 09:32:30 <weex> i think mcdonalds has it down to 3 seconds with amex
456 2012-06-01 09:32:33 <Diablo-D3> for others, thats very low.
457 2012-06-01 09:32:35 <weex> or 2
458 2012-06-01 09:32:39 <Diablo-D3> weex: heh
459 2012-06-01 09:32:43 <Diablo-D3> mcdonalds runs its own processing system
460 2012-06-01 09:33:05 <weex> of course but they had to reach out to get that speed
461 2012-06-01 09:33:09 <Diablo-D3> 3 seconds actually sounds high for them
462 2012-06-01 09:33:17 <sipa> it could well be milliseconds for small transactions, if you calculate the risk for double spending or otherwise failed transactions in, with bitcoin
463 2012-06-01 09:33:20 <Diablo-D3> walmart is down to like zero.
464 2012-06-01 09:33:22 <Diablo-D3> I shit you not
465 2012-06-01 09:33:28 <Diablo-D3> they OWN their own transaction processing network
466 2012-06-01 09:33:41 <Diablo-D3> theres only one other merchant that does, and thats amazon (which built theirs from the ground up due to their unique needs)
467 2012-06-01 09:33:49 <MC1984> all i said
468 2012-06-01 09:34:01 <weex> either way, they must have a copy of at least part of amex db
469 2012-06-01 09:34:05 <Diablo-D3> mcd and starbucks both built systems for high speed transaction processing, but still meter it out to backends
470 2012-06-01 09:34:27 <MC1984> was a small addition to bitcoind that would flag and deny double spends as they com in over the wire which would probably always be seconds worldwide max
471 2012-06-01 09:34:42 <MC1984> instead of waiting for first confm before calling bullshit
472 2012-06-01 09:34:47 <Diablo-D3> MC1984: except you're doing it wrong.
473 2012-06-01 09:35:12 <MC1984> that MAY make the risk acceptable to perform direct instant bitcoin sales on smallish value items
474 2012-06-01 09:35:25 <MC1984> thats all i said
475 2012-06-01 09:35:27 <Diablo-D3> starbucks already solved the problem
476 2012-06-01 09:35:28 <Diablo-D3> years ago
477 2012-06-01 09:35:38 <Diablo-D3> go do your research before spouting you have a new idea.
478 2012-06-01 09:35:55 <MC1984> what the dicks has this got to do with starbucks
479 2012-06-01 09:36:08 <weex> MC1984: i think Diablo-D3's trying to say use the best tool for the job
480 2012-06-01 09:36:30 <MC1984> the 'best' tool is visa.....
481 2012-06-01 09:36:35 <weex> of course people will build tech on top of bitcoin that will speed it up
482 2012-06-01 09:36:38 <weex> lower risk
483 2012-06-01 09:37:01 <MC1984> thats just what i proposed
484 2012-06-01 09:37:11 <Diablo-D3> MC1984: _starbucks already built a high speed transaction system that takes into account acceptable risk_
485 2012-06-01 09:37:13 <weex> but eventually they may hit a wall and decide, fuck it, i'm doing my own centralized system
486 2012-06-01 09:37:25 <Diablo-D3> _they already solved the problem and increased sales several million a year_
487 2012-06-01 09:37:45 Guest68995 has quit (Changing host)
488 2012-06-01 09:37:45 Guest68995 has joined
489 2012-06-01 09:37:45 <MC1984> people would be free to make thier own payment sytem ontop of bitcoin
490 2012-06-01 09:37:48 <Diablo-D3> weex: well, bitcoin is the fedwire of the bitcoin network.
491 2012-06-01 09:37:57 <Diablo-D3> weex: its designed to be built on top of.
492 2012-06-01 09:37:58 Guest68995 is now known as SomeoneWeird
493 2012-06-01 09:38:16 <MC1984> but perhaps with a few tweaks regular bitcoind might be good enough for smallish merchants who can afford that to deal direct in bitcoin
494 2012-06-01 09:38:23 <sipa> i doubt it is designed for that - satoshi had plans for advertizing/selling goods directly inside the p2p protocol
495 2012-06-01 09:38:31 <sipa> but i think it's an inevitable evolution
496 2012-06-01 09:38:32 <Diablo-D3> MC1984: no, no merchant wants to accept money themselves
497 2012-06-01 09:38:49 <Diablo-D3> sipa: he had plans to extend the system, thus building on top of what we had
498 2012-06-01 09:39:08 <weex> i like the idea of being able to easily setup a listener network of say 5 machines
499 2012-06-01 09:39:10 <Diablo-D3> what he would have proposed is bad engineering
500 2012-06-01 09:39:10 <sipa> right, but i fundamentally disagree with the idea that that belongs in the bitcoin protocol :)
501 2012-06-01 09:39:18 <MC1984> he didnt have plans to cloister the network away
502 2012-06-01 09:39:19 <weex> when 4 of 5 see the incoming txn i'm good
503 2012-06-01 09:39:21 <Diablo-D3> sipa: exactly
504 2012-06-01 09:39:27 <Diablo-D3> unix engineering always works
505 2012-06-01 09:39:46 <weex> right now, it's hard to keep 5 bitcoind's in sync watching for the same txns
506 2012-06-01 09:40:08 <MC1984> can people not see the value in atleast trying to keep the edge of the network as close to the actual commerce as possible
507 2012-06-01 09:40:26 <MC1984> my idea might be able to make it actually touch the commernce in many more cases
508 2012-06-01 09:40:27 <MC1984> maybe
509 2012-06-01 09:41:04 <weex> MC1984: at a certain point it's about code, i'd like for you to develop the code to make your idea happen
510 2012-06-01 09:41:35 <MC1984> you have shit like gambling sites totally eating the risk of 1BTC instant confirm right now so you can gamble straight away
511 2012-06-01 09:41:55 <sipa> MC1984: are you talking about satoshidice?
512 2012-06-01 09:42:18 <MC1984> with a bit of extra logic that risk eating threshold could rise and thus be more useful
513 2012-06-01 09:42:28 <MC1984> what is satoshidice
514 2012-06-01 09:42:37 <sipa> nvm then
515 2012-06-01 09:43:02 <sipa> because satoshidice does not take the instant confirm risk - their payouts use your inputs, so if you double spend them, your payout becomes invalid as well
516 2012-06-01 09:43:41 <weex> sipa: how do they specify the input to be coins from a specific transaction?
517 2012-06-01 09:44:34 <kinlo> by not using the bitcoin software I guess, the official client still needs a lot of work :/
518 2012-06-01 09:44:40 <MC1984> well, any service that eats instant risk on a small amount, could eat instant risk on larger amounts with some sort of propagation speed double spend flagging patch like i seem to be proposing
519 2012-06-01 09:44:43 <sipa> weex: they use a heavily modified bitcoinj
520 2012-06-01 09:44:54 <MC1984> if i could code id have a go myself
521 2012-06-01 09:44:58 paraipan has joined
522 2012-06-01 09:45:24 <MC1984> end result you can get better cheaper services @ the equivalent risk level i think
523 2012-06-01 09:45:26 <sipa> MC1984: i seem to have missed your original proposal - what exactly do you want to have added?
524 2012-06-01 09:45:57 <sipa> i disagree that it will make merchants want to interact directly with the blockchain, but that doesn't mean it's not useful for others
525 2012-06-01 09:46:28 <MC1984> bitcoind checks txns as they come in the wire aganst the ones its making, instead of only flagging double spends on the next block
526 2012-06-01 09:46:40 <MC1984> thats my idea in a sentence
527 2012-06-01 09:46:51 <sipa> there is no such thing as "flagging double spends"
528 2012-06-01 09:47:04 <sipa> from the point of view from the blockchain, no double spend exists
529 2012-06-01 09:47:23 <MC1984> this is nothing to do with the blockchain
530 2012-06-01 09:47:32 <sipa> well you're talking about blocks
531 2012-06-01 09:47:41 <MC1984> no im not
532 2012-06-01 09:47:51 <MC1984> raw txns on the wire
533 2012-06-01 09:47:54 <sipa> "instead of only flagging double spends on the next block"
534 2012-06-01 09:47:56 <sipa> <- block
535 2012-06-01 09:48:05 <MC1984> ffs
536 2012-06-01 09:48:13 <MC1984> thats the counterexample
537 2012-06-01 09:48:19 <sipa> sorry, i'm not following
538 2012-06-01 09:48:29 <weex> MC1984: bitcoind doesn't accept transactions that would be a double-spend
539 2012-06-01 09:48:34 <weex> but it only knows which one it saw first
540 2012-06-01 09:48:41 <weex> so it's a race across the network
541 2012-06-01 09:48:52 <MC1984> guys you are seriously not getting this
542 2012-06-01 09:48:57 <MC1984> aosu;gdnaWKDUJHVns{oa@LVN'A BMDZ#F
543 2012-06-01 09:48:58 <sipa> i'm not, no
544 2012-06-01 09:49:16 <MC1984> the one it saw first is the one it made
545 2012-06-01 09:49:23 <sipa> yes
546 2012-06-01 09:49:35 <MC1984> anything coming on the wire after that witht he same inputs is suspicious
547 2012-06-01 09:49:41 <MC1984> before blocks are made
548 2012-06-01 09:49:44 <MC1984> just raw txn
549 2012-06-01 09:49:55 <sipa> sure, but it will not see anything in most cases, as it doesn't get forwarded
550 2012-06-01 09:50:00 <sipa> but yes, that is suspicious
551 2012-06-01 09:50:09 <MC1984> yes
552 2012-06-01 09:50:17 <sipa> so, what do you propose to do with it?
553 2012-06-01 09:50:31 <MC1984> deny
554 2012-06-01 09:50:35 <sipa> a second transaction comes in, which conflicts with one that is already in the memory pool
555 2012-06-01 09:50:39 <sipa> that's what happens
556 2012-06-01 09:50:45 <sipa> it's simply discarded
557 2012-06-01 09:50:49 <weex> yes, this happens already
558 2012-06-01 09:51:14 <MC1984> wat
559 2012-06-01 09:51:31 <MC1984> so if i tred to double spend
560 2012-06-01 09:51:48 <MC1984> it would current be cought nearly instantly
561 2012-06-01 09:51:52 <sipa> incoming transactions are only accepted into the memory pool if they do not conflict with the blockchain + what is already in the memory pool
562 2012-06-01 09:51:55 <sipa> yes, of course
563 2012-06-01 09:52:07 <sipa> otherwise 0-conf transactions would be extremely dangerous to accept
564 2012-06-01 09:52:11 <weex> sipa: is there a list of double spend attempts?
565 2012-06-01 09:52:21 <MC1984> so my idea already exists
566 2012-06-01 09:52:28 <sipa> weex: not really, maybe some site tracks them
567 2012-06-01 09:52:32 <sipa> bitcoind doesn't
568 2012-06-01 09:53:08 <MC1984> so for the risk in getting shafted for the price of a can of coke or whatever
569 2012-06-01 09:53:24 <MC1984> the risk in accepting a instant txn is already nearly zero?
570 2012-06-01 09:53:36 <weex> MC1984: if you accept incoming transactions it's not nearly 0
571 2012-06-01 09:53:41 <weex> incoming connections i mean
572 2012-06-01 09:54:00 <MC1984> yes
573 2012-06-01 09:54:04 <weex> because attacker can send you the less-widely-distributed txn first
574 2012-06-01 09:54:09 <MC1984> ok assuming you lock down your connections
575 2012-06-01 09:54:14 <MC1984> the risk is ultra low?
576 2012-06-01 09:54:26 <weex> i'd say a lot lower than this conversation would merit
577 2012-06-01 09:54:36 <sipa> MC1984: there is the finney attack
578 2012-06-01 09:54:41 <weex> and all the other double-spend conversations before it
579 2012-06-01 09:54:49 <weex> quite a popular topic it is
580 2012-06-01 09:54:54 <sipa> which is probably the only viable way of exploiting a 0-conf transaction without massive hash power
581 2012-06-01 09:55:22 <sipa> (though it still requires a ton of hash power)
582 2012-06-01 09:55:25 <MC1984> is this finney attack worth it for the value of say $50 or whatever
583 2012-06-01 09:55:30 <sipa> no
584 2012-06-01 09:55:39 <MC1984> ok
585 2012-06-01 09:55:48 <MC1984> thats what i was talking about
586 2012-06-01 09:56:05 <MC1984> acceptable risk to be able to take bitcoins instantly
587 2012-06-01 09:56:15 <MC1984> without externalities to the network
588 2012-06-01 09:56:23 <sipa> sure, that's possible
589 2012-06-01 09:56:37 <weex> MC1984: you can try a 0-conf txn at coindl if you like (my site)
590 2012-06-01 09:56:47 <MC1984> it seems like you may be able to run a web merchant for smallish sales like this already without getting scammed
591 2012-06-01 09:57:02 <weex> nothing more than $50 on there
592 2012-06-01 09:57:18 <MC1984> so you run a site
593 2012-06-01 09:57:29 <MC1984> and you deal in no more than $50 value sales
594 2012-06-01 09:57:45 <MC1984> and you are happy with the risk of taking 0 conf txns
595 2012-06-01 09:57:59 <weex> sure, i'll let you know when i see a double-spend
596 2012-06-01 09:58:10 <MC1984> because bitcoind will flag any double spend as it comes in off the wire already?
597 2012-06-01 09:58:15 <weex> when the txns stop confirming
598 2012-06-01 09:58:25 <weex> no, it'll just not confirm
599 2012-06-01 09:58:32 <weex> or maybe will confirm once
600 2012-06-01 09:58:35 <weex> or 3 times
601 2012-06-01 09:59:21 <MC1984> say someone paid you to you bitcoind and then your bitcoind sees a double spend come in on the wire
602 2012-06-01 09:59:28 <MC1984> it will just not confirm?
603 2012-06-01 09:59:42 <weex> MC1984: it's like this, bitcoind sees the first transaction it sees
604 2012-06-01 09:59:55 <weex> after that the question is, will that one be included in the blockchain?
605 2012-06-01 10:00:06 <weex> if not, i've been duped
606 2012-06-01 10:00:35 <weex> but that means the attacker made my system think that txn was going to be accepted into the blockchain
607 2012-06-01 10:00:49 <weex> and you can get as elaborate as you want with that modeling, observing
608 2012-06-01 10:01:08 <MC1984> ok
609 2012-06-01 10:01:10 <MC1984> well
610 2012-06-01 10:02:25 <MC1984> it seems like i could trade all day with smallish amounts 0 confirms and be very confident of not getting double spend already
611 2012-06-01 10:03:20 <MC1984> because someone would have to attempt double spend before the next block, and my bitcoind would pick up the dupe txn on the wire almost instantly from anywhere in the world
612 2012-06-01 10:03:26 <MC1984> thats how i understand it
613 2012-06-01 10:03:37 <weex> bitcoind drops any dupe it sees
614 2012-06-01 10:03:49 <MC1984> yes
615 2012-06-01 10:03:59 <weex> to double spend you must transmit competing transactions pretty much simultaneously
616 2012-06-01 10:04:23 <MC1984> maybe as a merchant there should be a patch to make bitcoind flag a fraud attempt instead of quietly dropping then
617 2012-06-01 10:04:25 <MC1984> or somthing
618 2012-06-01 10:05:01 <weex> MC1984: you have consider potential for abuse
619 2012-06-01 10:05:14 <weex> i'm fine with txns not confirming as being notice enough
620 2012-06-01 10:06:03 <MC1984> what other circumstances will a txn not confirm though
621 2012-06-01 10:06:10 <MC1984> apart from not enough fee
622 2012-06-01 10:06:45 <weex> well i suppose if one of it's inputs stops confirming
623 2012-06-01 10:06:48 <weex> its
624 2012-06-01 10:07:38 <Habbie> can a tx even be confirmed if there are unconfirmed inputs?
625 2012-06-01 10:08:36 <weex> i don't know the details of what bitcoind will accept in terms of how many confirms an input has
626 2012-06-01 10:08:40 hnz has quit ()
627 2012-06-01 10:10:38 <weex> it would be handy if i could tell bitcoind to listen and display txns for addresses i send it
628 2012-06-01 10:11:09 <weex> instead of it only listening for addresses that have been fully imported or generated by itself
629 2012-06-01 10:11:23 <sipa> Habbie: no
630 2012-06-01 10:12:33 <Habbie> sipa, good, just checking
631 2012-06-01 10:17:02 <MC1984> bitcoin wont move txns on without atleast 1 confirm right
632 2012-06-01 10:17:23 <sipa> it will relay any transaction that makes it into its own memory pool
633 2012-06-01 10:17:38 <sipa> if it would only relay at one confirmation, no transaction would ever reach a miner
634 2012-06-01 10:17:49 <MC1984> no i mean you cant spend unconfirmed txn
635 2012-06-01 10:18:01 <sipa> the protocol allows that
636 2012-06-01 10:18:15 <sipa> but the client will not, unless it's an output from yourself (change or explicit send-to-self)
637 2012-06-01 10:18:55 <MC1984> say there is a custom client
638 2012-06-01 10:19:32 <MC1984> and an unconfirmed coins gets spent to 5 different people in a row before the next block
639 2012-06-01 10:19:44 <MC1984> but then the block comes in and its a double spend
640 2012-06-01 10:20:09 <MC1984> do those 5 people all reverse
641 2012-06-01 10:20:43 <sipa> depends on whether they received their own transaction in the first place
642 2012-06-01 10:20:45 <sipa> but if they do, yes
643 2012-06-01 10:20:58 <sipa> well, they will keep seeing those transactions, but they will remain at 0 conf
644 2012-06-01 10:23:14 <MC1984> hmm maybe bitcoin should indicate to the user that there is more of a problem than just txns that never confirm
645 2012-06-01 10:23:22 <MC1984> and presumable are now stuck in your client forever
646 2012-06-01 10:23:25 <sipa> i agree
647 2012-06-01 10:23:45 <MC1984> like, indicate to the user that they probably just got defrauded
648 2012-06-01 10:24:09 <sipa> there are plans for introducing "negative confirmations" for this: if a transaction directly or indirectly conflicts with one that is N deep in the blockchain, it would get -N confirmations
649 2012-06-01 10:24:24 <MC1984> i like it
650 2012-06-01 10:24:28 <sipa> and at -6 or something, you could choose to give up and delete the transaction or something
651 2012-06-01 10:24:40 <MC1984> make it red text too
652 2012-06-01 10:24:49 * sipa doesn't touch GUI code
653 2012-06-01 10:24:49 <MC1984> red always means bad
654 2012-06-01 10:25:11 <weex> unless your QT theme is messed up, then it might be green :P
655 2012-06-01 10:25:14 <sipa> but yes, sure, it should be clearly marked "rejected"
656 2012-06-01 10:25:46 O2made has joined
657 2012-06-01 10:26:40 <MC1984> could it give a reason for rejection too
658 2012-06-01 10:27:03 <MC1984> like double spend, too low fee etc
659 2012-06-01 10:27:22 <MC1984> those are the only two i know of that would make a txn not confirm
660 2012-06-01 10:27:29 <sipa> too low fee only influences whether it may end up in the blockchain or not
661 2012-06-01 10:27:41 <sipa> that doesn't make it rejected
662 2012-06-01 10:28:10 <sipa> (read: it's something you as a sender of a transaction can't know for sure)
663 2012-06-01 10:28:50 <MC1984> so only double spend would cause an outright rejection
664 2012-06-01 10:29:22 <sipa> it's just "attempted double spend" really, double spends don't exist from the point of a blockchain
665 2012-06-01 10:29:32 <sipa> and they can occur without malicious intent as well
666 2012-06-01 10:30:27 <MC1984> how, you have to send the same inputs to 2 different addresses at the samet time
667 2012-06-01 10:31:02 <sipa> for example if you copy a wallet.dat file to two systems
668 2012-06-01 10:31:08 <sipa> and send from them simultaneously
669 2012-06-01 10:31:33 <sipa> if one sends before hearing the other's transaction, there is a chance it uses a same input
670 2012-06-01 10:31:42 <MC1984> that doesnt seem like an accident
671 2012-06-01 10:32:01 <sipa> it has happened before :)
672 2012-06-01 10:32:10 <sipa> it doesn't have to be exactly simultaneously
673 2012-06-01 10:32:31 <MC1984> oh
674 2012-06-01 10:32:35 <sipa> for example one system can be offline while the other sends, and the second transaction is done before the first transaction made it into a block
675 2012-06-01 10:32:56 <sipa> so the normal tx propagation doesn't work
676 2012-06-01 10:33:18 <MC1984> well the recipients will still detect it very quick
677 2012-06-01 10:33:37 <sipa> the recipients will most likely only receive the first one
678 2012-06-01 10:40:12 _Fireball has joined
679 2012-06-01 10:41:28 DamascusVG has joined
680 2012-06-01 10:41:44 DamascusVG has quit (Changing host)
681 2012-06-01 10:41:44 DamascusVG has joined
682 2012-06-01 10:42:28 toffoo has quit ()
683 2012-06-01 10:45:46 MobiusL has quit (Remote host closed the connection)
684 2012-06-01 10:46:12 RainbowDashh has quit (Quit: RainbowDashh)
685 2012-06-01 10:47:41 knotwork has quit (Read error: Connection reset by peer)
686 2012-06-01 10:48:03 MobiusL has joined
687 2012-06-01 10:53:15 wizkid057 has quit (Remote host closed the connection)
688 2012-06-01 10:53:37 wizkid057 has joined
689 2012-06-01 10:58:47 RainbowDashh has joined
690 2012-06-01 11:00:44 knotwork has joined
691 2012-06-01 11:01:14 <sipa> ;;bc,tslb
692 2012-06-01 11:01:29 <gribble> Time since last block: 18 minutes and 57 seconds
693 2012-06-01 11:03:50 <drizztbsd> sipa: do you use bitvps.com? :P
694 2012-06-01 11:06:06 <sipa> no
695 2012-06-01 11:13:18 Turingi has quit (Read error: Connection reset by peer)
696 2012-06-01 11:18:22 darkee has quit (Quit: Verlassend)
697 2012-06-01 11:32:04 graingert has joined
698 2012-06-01 11:40:10 egecko has joined
699 2012-06-01 11:42:35 erle- has quit (Quit: erle-)
700 2012-06-01 11:46:26 rdponticelli has joined
701 2012-06-01 11:48:20 sytse has quit (Ping timeout: 272 seconds)
702 2012-06-01 11:48:43 sytse has joined
703 2012-06-01 11:51:42 agricocb has quit (Quit: Leaving.)
704 2012-06-01 12:06:34 comboy_ is now known as comboy
705 2012-06-01 12:10:29 Diapolo has joined
706 2012-06-01 12:14:18 erle- has joined
707 2012-06-01 12:19:48 Diapolo has left ()
708 2012-06-01 12:25:13 datagutt has joined
709 2012-06-01 12:28:35 _flow_ has quit (Ping timeout: 248 seconds)
710 2012-06-01 12:31:46 minimoose has joined
711 2012-06-01 12:32:51 O2made has quit (Ping timeout: 252 seconds)
712 2012-06-01 12:34:41 <sipa> BlueMatt: how much is there left to reimplement in cblockstore?
713 2012-06-01 12:35:08 <BlueMatt> sipa: before pull, Im just gonna do EmitTransaction/CommitTransaction and remove the wallet callbacks at the top of main.cpp, the rest can come in later pulls
714 2012-06-01 12:37:05 <BlueMatt> sipa: shouldnt take me more than a few hours after I finish breakfast
715 2012-06-01 12:39:50 <BlueMatt> sipa: oh, and rename to CHub again
716 2012-06-01 12:39:55 <sipa> BlueMatt: i hope we can encapsulate the actual blockstore (just the blocks database interface) and network node code afterwards
717 2012-06-01 12:39:55 mcorlette is now known as mcorlett
718 2012-06-01 12:40:09 <BlueMatt> sipa: thats my hope
719 2012-06-01 12:40:19 <BlueMatt> or, thats next
720 2012-06-01 12:40:46 <sipa> right, i was just about to mention that again; cblockstore is what you use to interact with the blockchain, but it's not the blockchain itself
721 2012-06-01 12:41:10 <BlueMatt> yea, I just forgot I was gonna rename when I started this branch
722 2012-06-01 12:43:00 <sipa> i do wonder about the node selection algorithm for requesting blocks
723 2012-06-01 12:43:13 <BlueMatt> not the blockchain itself, but it does encapsulate it
724 2012-06-01 12:43:30 <BlueMatt> why?
725 2012-06-01 12:45:03 <BlueMatt> imo net could use an upgrade to request things in general, and if a node doesnt respond, request from someone else
726 2012-06-01 12:46:01 <sipa> ideally, i'd say the top-level code is something like: CBlockStore store(dbenv); store.load(); CHub hub(store); hub.startthreads(); CNetNode node(hub); node.start(); CWallet wallet(hub, dbenv); wallet.load(); CRPCServer server(hub, wallet); server.start();
727 2012-06-01 12:46:43 <sipa> oh certainly, much improvement is possible for the block syncing
728 2012-06-01 12:46:55 danbri has joined
729 2012-06-01 12:47:44 <sipa> just not sure about your actual approach now, but i'll look at it a bit more closely soon
730 2012-06-01 12:48:27 <BlueMatt> hm? the only change is pick a random node with the base block instead of picking the node which triggered the orphan chain request
731 2012-06-01 12:49:17 <sipa> i'll shut up about it for now :)
732 2012-06-01 12:49:43 <BlueMatt> in terms of connecting a CHub to a CBlockStore, I dunno...to me that looks like a nop, you end up with a bunch of 2-line functions in CHub (call to CBlockStore, emit callback)
733 2012-06-01 12:51:01 <sipa> hmm, maybe, but it feels cleaner as you could easily put another blockstore in, without needing to change any hub code
734 2012-06-01 12:51:20 <sipa> if cblockstore becomes a virtual with several implementations
735 2012-06-01 12:51:23 <BlueMatt> thats true, SPVBlockStore FullBlockStore
736 2012-06-01 12:51:29 <sipa> exactly
737 2012-06-01 12:52:19 <BlueMatt> mmm...well yea that may be a bit cleaner...could do that now then
738 2012-06-01 12:52:40 <sipa> or even a dummyblockstore that accepts everything but stores nothing - nice for when you are already behind a single trusted blockchain
739 2012-06-01 12:52:45 <BlueMatt> alright, Ill rename CBlockStore->CHub and make a CBlockStore which CHub calls
740 2012-06-01 12:52:56 agricocb has joined
741 2012-06-01 12:53:15 <sipa> don't think you need the CBlockStore itself now already
742 2012-06-01 12:54:41 <sipa> but it won't hurt of course
743 2012-06-01 12:56:22 gavinandresen has joined
744 2012-06-01 12:56:34 <BlueMatt> alright, well, for now, it seems a CBlockStore would make CHub entirely just an additional call on the stack trace without doing anything, Ill leave it be for now, until we do a CSPVBlockStore or something
745 2012-06-01 12:56:48 <BlueMatt> gavinandresen: me and sipa were just discussing CBlockStore (well, CHub)
746 2012-06-01 12:57:03 <gavinandresen> I'll read the logs...
747 2012-06-01 12:57:55 <sipa> BlueMatt: static functiin calls are pretty cheap, unless inside a tight algorithmic loop that does millions of iterations :)
748 2012-06-01 12:58:34 <BlueMatt> true, but why over-complicate if we arent gonna have a CSPVBlockStore for another few months at the minimum anyway?
749 2012-06-01 12:59:15 <sipa> sure, not arguing that it should be there already, just saying that the argument about an extra stack frame hardly matters
750 2012-06-01 12:59:37 <BlueMatt> that was a way of putting "its a nop" not an actual argument
751 2012-06-01 13:00:02 <sipa> ok!, let's stop meta-arguing about something we agree about
752 2012-06-01 13:00:21 <BlueMatt> ok then
753 2012-06-01 13:01:31 <sipa> oh, and NetworkProxyBlockStore :)
754 2012-06-01 13:01:59 <BlueMatt> yea
755 2012-06-01 13:02:12 <BlueMatt> NetworkProxyHub too
756 2012-06-01 13:02:15 <sipa> or perhaps that should be CProxyHub
757 2012-06-01 13:02:16 <sipa> indeed
758 2012-06-01 13:06:44 tower has quit (Ping timeout: 244 seconds)
759 2012-06-01 13:10:43 <gavinandresen> BlueMatt: Why rename ProcessBlock->EmitBlock ? I think "process" is a better name. Also, I'm still not seeing why you need both boost::signals AND threads; what are the threads for?
760 2012-06-01 13:11:01 Skaag has quit (Read error: Connection reset by peer)
761 2012-06-01 13:11:19 Skaag has joined
762 2012-06-01 13:11:38 TD has joined
763 2012-06-01 13:12:30 tower has joined
764 2012-06-01 13:13:30 <BlueMatt> so that you can call the signals without any locks
765 2012-06-01 13:13:46 <BlueMatt> and without blocking the chain download to callback eg wallet methods
766 2012-06-01 13:14:38 <BlueMatt> process/emit, meh whatever, I dont care, the commit is to indicate its ProcessMessage->CHub::...
767 2012-06-01 13:15:03 <BlueMatt> and, depending on the backend blockstore, it may only be emitting, and not actually processing anything
768 2012-06-01 13:15:05 <gavinandresen> You want the signal notifications to be asynchronous. Ok, but isn't that just an implementation detail?
769 2012-06-01 13:15:25 MobiusL has quit (Ping timeout: 276 seconds)
770 2012-06-01 13:15:35 <BlueMatt> ah, so you are saying launch the threads in the CHub() constructor?
771 2012-06-01 13:15:52 <gavinandresen> Yes, I don't see any reason to expose that implementation detail in the API
772 2012-06-01 13:15:55 _Fireball has quit (Read error: No route to host)
773 2012-06-01 13:16:41 Zarutian has joined
774 2012-06-01 13:16:42 <BlueMatt> that was just so that you can do if (!CreateThread(...)) return false; in AppInit2
775 2012-06-01 13:16:50 _Fireball has joined
776 2012-06-01 13:17:08 <sipa> if that fails, i think you can safely throw a fatal error
777 2012-06-01 13:17:25 <BlueMatt> fair enough, Ill do that...one sec
778 2012-06-01 13:17:26 <gavinandresen> yes, throwing an exception from the blockstore constructor should be fine
779 2012-06-01 13:17:56 <sipa> "woops, kernel has no memory for threads left - let's try to die gracefully!"
780 2012-06-01 13:18:57 <gavinandresen> Does CWallet need a pointer to the CHub? Seems to me it aughtn't....
781 2012-06-01 13:20:57 <BlueMatt> maybe I just hate globals too much...
782 2012-06-01 13:21:18 <gavinandresen> who said anything about a global?
783 2012-06-01 13:21:45 <gavinandresen> what will the wallet use the pBlockStoreToCall pointer for?
784 2012-06-01 13:21:58 <BlueMatt> if it doesnt get a pointer, it has to call (the global) phub->...
785 2012-06-01 13:22:07 <gavinandresen> to do what?
786 2012-06-01 13:22:33 <gavinandresen> ... and could it do CHub::static_method(....) instead ?
787 2012-06-01 13:22:50 <BlueMatt> later it will need it to call eg EmitTransaction
788 2012-06-01 13:22:53 <BlueMatt> on new txes
789 2012-06-01 13:22:59 MobiusL has joined
790 2012-06-01 13:23:11 <gavinandresen> So: CHub::SubmitNewTransaction(....)
791 2012-06-01 13:23:45 <gavinandresen> it doesn't matter which CHub (if you have several) validates and then submits the transaction, does it?
792 2012-06-01 13:24:17 <BlueMatt> you may have different CHubs that are using different blockstore backends
793 2012-06-01 13:24:30 <sipa> so how would CHub::SubmitNewTransaction find a CHub, gavinandresen?
794 2012-06-01 13:24:36 <gavinandresen> implementation detail
795 2012-06-01 13:24:53 <BlueMatt> and in that case, you may want a wallet connected to the non-checking proxied-behind-good-node blockstore, and one to the fully-checking one
796 2012-06-01 13:24:57 <gavinandresen> ... maybe it keeps a static vector of constructed CHubs
797 2012-06-01 13:25:16 <sipa> it seems very natural that every object that interacts with a hub, knows which hub it is interacting with
798 2012-06-01 13:25:18 <BlueMatt> imho that gets messier than just registering a hub to the wallet on wallet creation
799 2012-06-01 13:25:41 <sipa> even if there is only one hub in typical applications
800 2012-06-01 13:26:43 <gavinandresen> BlueMatt: why would the wallet care about which variation of blockstore is being used when it just wants to submit a new wallet transaction?
801 2012-06-01 13:27:06 <sipa> it definitely does not need to know which type of blockstore is used
802 2012-06-01 13:27:08 <BlueMatt> Im saying if you have multiple running, the wallet may care which one it connects to
803 2012-06-01 13:27:13 <gavinandresen> why?
804 2012-06-01 13:27:25 <BlueMatt> ie the user who created the wallets may care, the wallet itself should not need to know
805 2012-06-01 13:27:33 <BlueMatt> just that its connected to the one the user wants it connected to
806 2012-06-01 13:29:12 <sipa> there is a point in splitting the chub core (submit and register stuff) and the interaction layer (emit stuff)
807 2012-06-01 13:30:17 <sipa> you could for example turn the interaction layer into a virtual base class for for class that does interact with hubs
808 2012-06-01 13:30:19 <gavinandresen> I'm still trying to think of use-cases where I create a wallet and then care about which CHub it is connected to.
809 2012-06-01 13:30:47 <gavinandresen> Maybe first you could tell me some (future) use cases where there are multiple CHubs
810 2012-06-01 13:31:40 <gavinandresen> ?? would there be multiple CHubs if there was some type of dual-stack network implementation, with one CHub connected to the bitcoin p2p network and another to some other network that transmits blocks and transactions ??
811 2012-06-01 13:32:06 <sipa> meh, that's similar to the c library exposing a random function but hiding the singleton state array it uses, because nobody would need two random states simultaneously
812 2012-06-01 13:32:45 <BlueMatt> I think those use-cases should be using multiple processes, so, really there arent much of any
813 2012-06-01 13:32:53 <TD> what does a CHub do again?
814 2012-06-01 13:33:07 <TD> i tried to design bitcoinj to allow different types of block store, multiple simultaneous wallets, etc
815 2012-06-01 13:33:21 <BlueMatt> you emit transactions to it, it callsback when you get a new block/tx/etc
816 2012-06-01 13:33:30 <BlueMatt> s/transactions/transactions, blocks, etc/
817 2012-06-01 13:33:37 <sipa> TD: blockchain <-> (network, wallet) interactions
818 2012-06-01 13:33:41 t7_ has joined
819 2012-06-01 13:33:56 <sipa> the hub is the message dispatcher in between
820 2012-06-01 13:34:03 <TD> i see
821 2012-06-01 13:34:15 <TD> so it decides for every tx in a block, for which wallets/arbitrary-listener-things are interested?
822 2012-06-01 13:34:21 <BlueMatt> gavinandresen: meh, whatever, static method, pointer, doesnt matter /that/ much, just seems more logical to me to throw in a pointer
823 2012-06-01 13:34:51 <BlueMatt> TD: for now, it lets the listeners decide and just sends them each block, but actually registering what you are interested could be done
824 2012-06-01 13:35:22 <sipa> i kinda agree with BlueMatt, it doesn't simplify anything to make the method static, and then have it still pick a private global object to dispatch to
825 2012-06-01 13:35:25 <BlueMatt> (because, for now, all the listeners do care about each block, and want to run AddToWalletIfInvolvingMe on each tx)
826 2012-06-01 13:35:58 <TD> i see
827 2012-06-01 13:36:25 <TD> in bitcoinj the BlockChain lets you register Wallets with it and then it tests each transaction for relevance, and sends them to the Wallet class. but i'd like to make it more decoupled.
828 2012-06-01 13:36:33 <BlueMatt> TD: its really exclusively just a refactor, but it adds some nice possibilities down the road
829 2012-06-01 13:36:42 <TD> yes
830 2012-06-01 13:37:30 Skaag has quit (Quit: Is dreams our reality, or is reality our dreams?)
831 2012-06-01 13:38:26 copumpkin has quit (Quit: Computer has gone to sleep.)
832 2012-06-01 13:38:42 <gavinandresen> BlueMatt: holding a pointer to another object triggers my "these things might be too tightly coupled" flag. And makes me nervous because suddenly order of destruction might matter....
833 2012-06-01 13:39:11 <sipa> gavinandresen: the idea is to make chub one day a virtual base class, with several implementations
834 2012-06-01 13:39:30 <sipa> e.g. one that interacts with a block database on another system
835 2012-06-01 13:40:01 <sipa> wallets would interact with the virtual base, but not know which implementation they talk to
836 2012-06-01 13:40:41 Maccer has quit (Ping timeout: 240 seconds)
837 2012-06-01 13:41:33 <sipa> the chub interface is just the general abstraction through which they interact, and exactly allows decoupling, imho
838 2012-06-01 13:41:38 <gavinandresen> TD BlueMatt : if you have time, I'm looking for feedback on some lower-level new RPC commands: https://gist.github.com/2839617
839 2012-06-01 13:43:28 <gavinandresen> sipa: if the only interacting they are doing is submitting (emitting? why emit?) transactions then I think a static method is better, because if you have more than one CHub then I think you're going to want all of them to know about the new transaction.
840 2012-06-01 13:44:08 <TD> jgarzik is doing "transaction bloom filter work"? is that the protocol extension i mentioned before?
841 2012-06-01 13:44:18 <gavinandresen> TD: no, RPC command
842 2012-06-01 13:44:19 <TD> listunspent might be more useful if you could specify a minimum amount
843 2012-06-01 13:44:31 <TD> rather than minimum count (they could be random - what is the use case for min count?)
844 2012-06-01 13:44:41 <Diablo-D3> lol did someone say bloom filter
845 2012-06-01 13:44:48 <Diablo-D3> I wrote a bloom filter once
846 2012-06-01 13:44:51 <Diablo-D3> it took about 20 minutes
847 2012-06-01 13:44:59 <Diablo-D3> I still dont get whats supposed to be so fucking awesome about them
848 2012-06-01 13:45:08 <BlueMatt> gavinandresen: emitting/submitting same thing, doesnt really matter, emit was used because it fits with the async callback naming stuff
849 2012-06-01 13:45:14 <sipa> gavinandresen: wallets are inherently registered to a chub already, since they need to receive callbacks from them
850 2012-06-01 13:45:26 <gavinandresen> TD: ACK on minamount, I think that'd be better. Failure if there aren't at least minamount unspent?
851 2012-06-01 13:45:30 <TD> gavinandresen: sure
852 2012-06-01 13:45:33 <TD> gavinandresen: so what is the RPC for?
853 2012-06-01 13:45:37 <TD> gavinandresen: jeffs, i mean
854 2012-06-01 13:46:10 <sipa> gavinandresen: sure you could argue they will want to register to all hubs that exist, but if someone wants more than one hub, let them deal with but make sure they can
855 2012-06-01 13:46:50 peck has joined
856 2012-06-01 13:46:52 Skaag has joined
857 2012-06-01 13:47:07 <TD> gavinandresen: if sendrawtx fails (insufficient fees? no network?) what is the response?
858 2012-06-01 13:47:11 <gavinandresen> TD: transaction version of -blocknotify
859 2012-06-01 13:47:23 <gavinandresen> (call an external process when 'interesting' transactions happen)
860 2012-06-01 13:48:09 <gavinandresen> TD: json error...
861 2012-06-01 13:48:13 <TD> gavinandresen: i see. it'd be nice if that wasn't an RPC but [also] a regular network message. as a third party program always has the option to talk network to a node to get that data, but other nodes don't have the option to do RPC
862 2012-06-01 13:48:23 <TD> but the bulk of the work is not wiring up to the network/rpc code anyway
863 2012-06-01 13:48:26 <TD> so i'm glad it's happening ....
864 2012-06-01 13:48:31 <Diablo-D3> hey guys
865 2012-06-01 13:48:35 <Diablo-D3> I want your opinion
866 2012-06-01 13:48:44 <Diablo-D3> whats the best program to replace gprof
867 2012-06-01 13:48:48 <sipa> BlueMatt: how about the idea of putting the code for interacting with chub in a separate virtual base class?
868 2012-06-01 13:49:25 <TD> gavinandresen: it looks very reasonable to me. though the idea of people passing around hex encoded strings is a little bizarre :) i guess the next step is a way to save the transactions to a file and let people email them to each other
869 2012-06-01 13:49:42 <sipa> BlueMatt: i can write some code to show if you like
870 2012-06-01 13:50:00 <gavinandresen> TD: sipa and I talked a little about hex-encoded-serialized-format versus something else yesterday
871 2012-06-01 13:50:34 <Diablo-D3> no one wants to comment?
872 2012-06-01 13:50:39 <gavinandresen> The advantage of hex-encoded-serialized-format is it is trivial to parse hex, and then once it is in network-serialized-format we can be pretty sure we've got bug-free code to deal with it
873 2012-06-01 13:50:50 <BlueMatt> sipa: you mean handle the register stuff in a virtual base class and have wallet extend that?
874 2012-06-01 13:51:05 <sipa> BlueMatt: yes
875 2012-06-01 13:51:21 <gavinandresen> Diablo-D3: I've been using callgrind the last couple of times I had to figure out what was slow.
876 2012-06-01 13:51:23 <BlueMatt> sounds good to me, though that is what CHub rev 1 was and everyone hated that...
877 2012-06-01 13:51:32 <BlueMatt> but CHub rev 1 sucked for other reasons
878 2012-06-01 13:51:38 <luke-jr> gavinandresen: forrestv was OK with the single-Object-param change, so I implemented it
879 2012-06-01 13:52:27 <sipa> BlueMatt: so you'd initialize the CHubClient base class with the actual CHub as argument, and you can then just call EmitBlock or SubmitDonkey whatever, and it would get sent to the right chub
880 2012-06-01 13:52:47 <BlueMatt> sounds good, Ill do that as I rename stuff
881 2012-06-01 13:52:53 <sipa> great
882 2012-06-01 13:52:54 <Diablo-D3> gavinandresen: that seems to be my only option but I have to install half of kde to get kcachegrind so I can read the logs
883 2012-06-01 13:54:09 dw has quit (Ping timeout: 265 seconds)
884 2012-06-01 13:54:21 dw has joined
885 2012-06-01 13:54:42 <BlueMatt> Diablo-D3: and those libs totall...less than 1G, get over it ;)
886 2012-06-01 13:55:04 <Diablo-D3> yeah but its just more trash I dont need =/
887 2012-06-01 13:55:22 <BlueMatt> if you're using kcachegrind, you do need it
888 2012-06-01 13:55:34 <Diablo-D3> I dont get why it needs kde though
889 2012-06-01 13:55:38 <Diablo-D3> it does nothing more than qt
890 2012-06-01 13:56:55 wasabi1 has joined
891 2012-06-01 13:58:23 danbri has quit (Remote host closed the connection)
892 2012-06-01 14:00:05 copumpkin has joined
893 2012-06-01 14:03:21 Turingi has joined
894 2012-06-01 14:17:57 blumenkraft has joined
895 2012-06-01 14:18:36 Maccer has joined
896 2012-06-01 14:20:40 drizztbsd has quit (Quit: Konversation terminated!)
897 2012-06-01 14:20:41 NeedzTweezerstoF is now known as Bigpiggy01Mining
898 2012-06-01 14:20:45 egecko has quit (Quit: ~ Trillian Astra - www.trillian.im ~)
899 2012-06-01 14:21:07 drizztbsd has joined
900 2012-06-01 14:21:23 <luke-jr> FWIW, Mac 10.5 user confirmed my gitian bitcoind works
901 2012-06-01 14:21:43 <Diablo-D3> fuck all the osxes.
902 2012-06-01 14:21:59 <TD> luke-jr: awesome!
903 2012-06-01 14:22:11 <TD> btw, why does it need to be cross-compiled ?
904 2012-06-01 14:22:23 <Diablo-D3> you're lucky you can compile it at all
905 2012-06-01 14:22:35 <luke-jr> TD: because only Mac users have Macs?
906 2012-06-01 14:22:36 blumenkraft has quit (Excess Flood)
907 2012-06-01 14:22:38 <Diablo-D3> apple has been braindamaging newer xcodes so you cant compile for earlier osxes
908 2012-06-01 14:23:07 <luke-jr> Diablo-D3: I compiled it on Ubuntu.
909 2012-06-01 14:23:10 <Diablo-D3> then again, if you're dumb enough to buy a mac, you're dumb enough to get locked into that expensive upgrade cycle
910 2012-06-01 14:23:33 <Diablo-D3> luke-jr: only because bitcoind doesnt use objc
911 2012-06-01 14:23:44 <Diablo-D3> and gcc still contains enough to make 10.6 binaries
912 2012-06-01 14:23:53 <luke-jr> Diablo-D3: 10.5
913 2012-06-01 14:24:00 <Diablo-D3> thats not the point
914 2012-06-01 14:24:02 <luke-jr> so you think getting Qt working will be harder
915 2012-06-01 14:24:05 <luke-jr> I already knew that
916 2012-06-01 14:24:17 one_zero has quit ()
917 2012-06-01 14:24:20 <Diablo-D3> osx has basically fucked developers
918 2012-06-01 14:24:24 <Diablo-D3> s/osx/apple/
919 2012-06-01 14:24:31 <Diablo-D3> luke-jr: qt "should" work fine
920 2012-06-01 14:24:33 <Diablo-D3> in theory
921 2012-06-01 14:24:44 <Diablo-D3> they claim all this wonderful osx support, anyways
922 2012-06-01 14:24:52 <luke-jr> Diablo-D3: it uses ObjC ;)
923 2012-06-01 14:25:00 <Diablo-D3> yes but you can use their binaries
924 2012-06-01 14:25:04 <Diablo-D3> so you dont have to compile it
925 2012-06-01 14:25:56 <Diablo-D3> man, I wonder why apple hates developers so much
926 2012-06-01 14:26:59 <BlueMatt> Diablo-D3: not as much as m$ as of windows 8 ;)
927 2012-06-01 14:27:21 <Diablo-D3> classic apps still work in windows 8
928 2012-06-01 14:27:25 <BlueMatt> wanna make traditional applications for the desktop environment you know everyone will be using, buy a damn license!
929 2012-06-01 14:27:31 <Diablo-D3> and no one gives a shit about metro
930 2012-06-01 14:27:37 <BlueMatt> thats my point
931 2012-06-01 14:27:51 <BlueMatt> and you cant build non-metro apps using the new visual studios without paying
932 2012-06-01 14:27:58 <Diablo-D3> yeah
933 2012-06-01 14:27:58 <BlueMatt> for a professional license
934 2012-06-01 14:28:09 <Diablo-D3> but you cant build old osx apps on new xcode
935 2012-06-01 14:28:30 <BlueMatt> thats not hating developers, thought, thats hating users
936 2012-06-01 14:28:32 <Diablo-D3> you need an old version of xcode to do it, which you cant install side by side and wont install on new osxes
937 2012-06-01 14:28:40 <sipa> haha
938 2012-06-01 14:28:49 <Diablo-D3> its hating developers because some devs just dropped osx altogether because of it
939 2012-06-01 14:28:54 <luke-jr> Diablo-D3: except Qt doesn't provide 32-bit 10.5 binaries anymore -.-
940 2012-06-01 14:29:06 <Diablo-D3> luke-jr: dont blame them, 10.5's 32 bit support is fucked
941 2012-06-01 14:29:18 <Diablo-D3> and ppc support in 10.5 is also fucked
942 2012-06-01 14:29:24 <luke-jr> BlueMatt: don't forget that computers shipping Windows 8 can only run Microsoft-signed OS
943 2012-06-01 14:29:36 <luke-jr> Diablo-D3: they don't provide 10.5 or 32-bit at all
944 2012-06-01 14:29:47 <BlueMatt> thats only arm, x86 you can disable it, but, by default, yea
945 2012-06-01 14:29:47 <Diablo-D3> luke-jr: dont blame them really =/
946 2012-06-01 14:30:02 <Diablo-D3> 10.5 was a nightmare
947 2012-06-01 14:30:06 <Diablo-D3> 10.4 was fine, it was ppc only
948 2012-06-01 14:30:12 <Diablo-D3> 10.6 was fine, it was x86-64 only
949 2012-06-01 14:30:19 <Diablo-D3> 10.5 is a fucking pile of shit
950 2012-06-01 14:30:24 <Diablo-D3> they should have never released it
951 2012-06-01 14:31:48 <Diablo-D3> you know what my official stance is with anything Ive written?
952 2012-06-01 14:31:58 <Diablo-D3> if you're on a mac, just install linux.
953 2012-06-01 14:32:05 <Diablo-D3> muuuuch less trouble getting software to run
954 2012-06-01 14:32:08 <helo> luke-jr: computers shipping windows 8 can run linux just fine, you just have to disable secure boot
955 2012-06-01 14:32:25 <Diablo-D3> secure boot isnt even the problem
956 2012-06-01 14:32:42 <luke-jr> helo: ARM?
957 2012-06-01 14:32:49 <Diablo-D3> linux can be setup to secure boot too
958 2012-06-01 14:32:56 <helo> luke-jr: x86
959 2012-06-01 14:32:59 <luke-jr> Diablo-D3: yeah, like Fedora being signed by Microsoft
960 2012-06-01 14:33:05 <luke-jr> helo: well I want ARM
961 2012-06-01 14:33:05 <Diablo-D3> yeah exactly
962 2012-06-01 14:33:16 <Diablo-D3> for security environments, a properly written security hypervisor would be nice
963 2012-06-01 14:33:29 <helo> my android phone is locked down similarly
964 2012-06-01 14:33:36 <Diablo-D3> hardware keys, signed security hypervisor, signed kernel, signed binaries
965 2012-06-01 14:33:41 <Diablo-D3> and no scripting languages
966 2012-06-01 14:33:53 <Diablo-D3> and no compiler
967 2012-06-01 14:34:03 <Diablo-D3> sysadmin heaven ;_;
968 2012-06-01 14:34:17 <luke-jr> helo: I don't like Android either. and in that case it's even illegal.
969 2012-06-01 14:34:32 <helo> i like me some scripting languges when i admin
970 2012-06-01 14:34:54 <helo> luke-jr: isn't it only illegal with gpl3?
971 2012-06-01 14:35:35 * [7] likes the way it works on android, as long as you can opt to boot an unsigned code base if you want to
972 2012-06-01 14:35:39 <helo> well it's not illegal as far as i know, just a license violation
973 2012-06-01 14:37:08 <luke-jr> helo: no, GPLv3 makes an *exception*
974 2012-06-01 14:37:28 <luke-jr> helo: that is, GPLv3 says you can keep signing key sources private iff you allow users to boot unsigned kernels
975 2012-06-01 14:37:37 <luke-jr> GPLv2 just requires all source code be released period
976 2012-06-01 14:37:56 <luke-jr> and license violations are illegal by definition
977 2012-06-01 14:38:42 <helo> the kernel is still gpl2, and the source is released... it just isn't possible to boot an unsigned kernel built from that source
978 2012-06-01 14:39:21 <luke-jr> helo: a signed kernel's source includes the key signing it
979 2012-06-01 14:39:27 darkee has joined
980 2012-06-01 14:39:50 <luke-jr> GPLv2 explicitly states that anything required for building (including compilers) is considered source code
981 2012-06-01 14:39:59 <[7]> anything for building *what*?
982 2012-06-01 14:40:04 <luke-jr> [7]: the binary
983 2012-06-01 14:40:40 <sipa> well, things that are considered commonly available like operating systems and compilers are not source according to GPLv2
984 2012-06-01 14:40:48 <[7]> is it illegal to take a finished binary from an open source project, sign it, and publish the signed binary without publishing the key?
985 2012-06-01 14:40:53 <sipa> but that doesn't hold for signing keus of course
986 2012-06-01 14:41:03 <helo> you can build the kernel binary just fine, just not in a way that can boot on devices with locked bootloaders
987 2012-06-01 14:41:56 <sipa> so that means you are distributing a binary derived from a source that is GPL, in a way that people receiving the binary do not have the same rights as you
988 2012-06-01 14:41:57 <[7]> microsoft signing fedora's code would be illegal in that case as well
989 2012-06-01 14:41:58 Hasbro has joined
990 2012-06-01 14:42:13 <sipa> that sounds like a GPL violation to me, but IANAL
991 2012-06-01 14:42:18 <[7]> i.e. only locking out linux on that hardware would be legal if you don't want to drop the secure boot stuff altogether
992 2012-06-01 14:42:46 <drizztbsd> [7]: only for GPLv3
993 2012-06-01 14:42:53 <luke-jr> sipa: signing keys aren't commonly available :p
994 2012-06-01 14:43:04 <sipa> luke-jr:
995 2012-06-01 14:43:07 <drizztbsd> stallman added that after samba shit agreement
996 2012-06-01 14:43:07 <sipa> but that doesn't hold for signing keus of course
997 2012-06-01 14:43:08 <[7]> drizztbsd: I think only for GPLv2, which linux is
998 2012-06-01 14:43:26 <luke-jr> [7]: it's illegal to take a signed binary from a GPLv2 project, and publish it without publishing the full source including key
999 2012-06-01 14:43:52 <luke-jr> drizztbsd: GPLv3 makes an exception allowing you to keep the signing key private in specific circumstances
1000 2012-06-01 14:44:14 <helo> luke-jr: as far as i know no kernel developers or the fsf feels that way to the extent that they are willing to litigate
1001 2012-06-01 14:44:32 <drizztbsd> I work for a broadband company and we encrypt anythink
1002 2012-06-01 14:44:36 <drizztbsd> anything*
1003 2012-06-01 14:44:36 <luke-jr> [7]: yes, RedHat having Microsoft sign Fedora's kernel is illegal; but who is going to sue a top sponsor of Linux devs?
1004 2012-06-01 14:44:59 <luke-jr> helo: FSF doesn't have legal standing
1005 2012-06-01 14:45:04 Diapolo has joined
1006 2012-06-01 14:45:09 <luke-jr> helo: and yes, Linux copyright holders are basically cowards
1007 2012-06-01 14:45:19 <luke-jr> they should have been suing nvidia a long time ago
1008 2012-06-01 14:45:22 <luke-jr> instead they just make petitions
1009 2012-06-01 14:45:23 <[7]> "nobody wants to litigate" is not what I call a real solution though
1010 2012-06-01 14:45:24 <drizztbsd> luke-jr: why?
1011 2012-06-01 14:45:29 <luke-jr> drizztbsd: ?
1012 2012-06-01 14:45:47 <drizztbsd> what is the problem with nvidia?
1013 2012-06-01 14:45:54 <Diapolo> hi there
1014 2012-06-01 14:46:30 <helo> has the FSF not been attributed copyright over some parts of the kernel?
1015 2012-06-01 14:47:02 <luke-jr> helo: not afaik
1016 2012-06-01 14:47:19 <luke-jr> drizztbsd: they distribute a derivative work of Linux in violation of the GPL
1017 2012-06-01 14:47:56 <drizztbsd> broadcom too
1018 2012-06-01 14:48:04 <drizztbsd> intel too
1019 2012-06-01 14:49:12 <luke-jr> Intel is pretty good usually
1020 2012-06-01 14:58:08 <luke-jr> wtf
1021 2012-06-01 14:58:20 <luke-jr> why is my debug.log now called: debug.l`
1022 2012-06-01 14:58:21 <luke-jr> ?
1023 2012-06-01 15:01:45 rdponticelli_ has joined
1024 2012-06-01 15:02:08 rdponticelli has quit (Ping timeout: 246 seconds)
1025 2012-06-01 15:06:07 rdponticelli_ has quit (Ping timeout: 245 seconds)
1026 2012-06-01 15:07:31 <gavinandresen> luke-jr: gremlins? or do you have your locale set to federation-klingon ?
1027 2012-06-01 15:07:35 Hasbro has quit (Ping timeout: 260 seconds)
1028 2012-06-01 15:09:47 <luke-jr> gavinandresen: no, but I'm debugging next-eligius now
1029 2012-06-01 15:10:08 <luke-jr> makes me worry there's a buffer overflow or something tho
1030 2012-06-01 15:10:20 m00p has quit (Quit: Leaving)
1031 2012-06-01 15:10:25 <luke-jr> but I guess the whole debug.log filename code's got a redo since 0.6.0
1032 2012-06-01 15:10:55 <luke-jr> and I'm more concerned about this stupid deadlock
1033 2012-06-01 15:11:25 <luke-jr> gavinandresen: btw, gmp_bip look good now?
1034 2012-06-01 15:14:11 <gavinandresen> I'm OK with the RPC interface now, can't comment on the BIP (other than saying I think it has too much optional stuff in it) or on the details of what the pull actually does.
1035 2012-06-01 15:15:50 <gavinandresen> how many lines of code does it add to bitcoinrpc.cpp ? If it is more than 100 then I think maybe moving getwork/getmemorypool to a mining.cpp might make sense.
1036 2012-06-01 15:16:14 <gavinandresen> (bitcoinrpc.cpp is getting way too big, in my humble opinion)
1037 2012-06-01 15:16:19 <luke-jr> under 100
1038 2012-06-01 15:16:34 Skaag has quit (Remote host closed the connection)
1039 2012-06-01 15:16:54 Skaag has joined
1040 2012-06-01 15:17:15 <luke-jr> but probably a good idea to clean up bitcoinrpc later anyway
1041 2012-06-01 15:17:29 <luke-jr> I don't like mixing cleanup with code changes, though, as it makes it harder to see what happened
1042 2012-06-01 15:19:07 <gavinandresen> agreed, either cleanup before or after.
1043 2012-06-01 15:21:13 Hasbro has joined
1044 2012-06-01 15:22:20 _flow_ has joined
1045 2012-06-01 15:24:07 andytoshi has quit (Ping timeout: 276 seconds)
1046 2012-06-01 15:29:17 t7_ has quit (Quit: ChatZilla 0.9.88.2 [Firefox 13.0/20120528154913])
1047 2012-06-01 15:34:32 gribble has quit (Quit: brb)
1048 2012-06-01 15:37:30 vigilyn has quit (Quit: Leaving)
1049 2012-06-01 15:37:34 RainbowDashh has quit (Quit: RainbowDashh)
1050 2012-06-01 15:37:37 gribble has joined
1051 2012-06-01 15:41:21 RainbowDashh has joined
1052 2012-06-01 16:13:26 rdponticelli has joined
1053 2012-06-01 16:16:22 Bigpiggy01Mining has quit ()
1054 2012-06-01 16:34:31 t7 has quit (Remote host closed the connection)
1055 2012-06-01 16:35:46 RainbowDashh has quit (Quit: RainbowDashh)
1056 2012-06-01 16:36:38 Detritus has quit (Ping timeout: 246 seconds)
1057 2012-06-01 16:37:04 Detritus has joined
1058 2012-06-01 16:38:21 t7 has joined
1059 2012-06-01 16:43:17 RainbowDashh has joined
1060 2012-06-01 16:43:28 Diapolo has left ()
1061 2012-06-01 16:43:48 silp has joined
1062 2012-06-01 16:44:09 <silp> test
1063 2012-06-01 16:47:19 RainbowDashh has quit (Client Quit)
1064 2012-06-01 16:48:58 erle- has quit (Quit: erle-)
1065 2012-06-01 16:49:17 RainbowDashh has joined
1066 2012-06-01 16:49:40 mmoya has quit (Ping timeout: 260 seconds)
1067 2012-06-01 16:51:50 RainbowDashh has quit (Disconnected by services)
1068 2012-06-01 16:51:50 Rabbit67890 has joined
1069 2012-06-01 16:51:57 <GTRsdk> silp: succeeded
1070 2012-06-01 16:54:08 ThomasV has joined
1071 2012-06-01 16:54:23 <sipa> if this was a test whether IRC could wash your clothes, it presumably failed
1072 2012-06-01 16:56:58 osmosis has joined
1073 2012-06-01 16:58:44 TD has quit (Quit: TD)
1074 2012-06-01 16:59:07 drizztbsd has quit (Quit: Konversation terminated!)
1075 2012-06-01 17:00:41 RainbowDashh has joined
1076 2012-06-01 17:01:33 <nanotube> sipa: mine succeeded. >_> :)
1077 2012-06-01 17:01:43 <nanotube> you must be using an old irc client or something.
1078 2012-06-01 17:02:24 <BlueMatt> nanotube: wait, where do I get this clothes-washing irc client, I really need that
1079 2012-06-01 17:02:47 <nanotube> sorry i'm under an NDA, can't disclose that. >_>
1080 2012-06-01 17:02:55 <BlueMatt> damn
1081 2012-06-01 17:03:11 Rabbit67890 has quit (Ping timeout: 240 seconds)
1082 2012-06-01 17:06:09 _W_ has quit (Excess Flood)
1083 2012-06-01 17:06:14 drizztbsd has joined
1084 2012-06-01 17:06:18 _W_ has joined
1085 2012-06-01 17:06:32 rdponticelli has quit (Ping timeout: 245 seconds)
1086 2012-06-01 17:08:46 MobiusL has quit (Ping timeout: 276 seconds)
1087 2012-06-01 17:14:45 RainbowDashh has quit (Quit: RainbowDashh)
1088 2012-06-01 17:16:31 topi`_ has quit (Quit: leaving)
1089 2012-06-01 17:19:45 gavinandresen has quit (Quit: gavinandresen)
1090 2012-06-01 17:23:58 Diapolo has joined
1091 2012-06-01 17:25:08 RainbowDashh has joined
1092 2012-06-01 17:25:53 D34TH has joined
1093 2012-06-01 17:31:44 hnz has joined
1094 2012-06-01 17:35:00 mmoya has joined
1095 2012-06-01 17:35:07 [7] has quit (Disconnected by services)
1096 2012-06-01 17:35:14 TheSeven has joined
1097 2012-06-01 17:39:59 mmoya has quit (Ping timeout: 256 seconds)
1098 2012-06-01 17:45:38 TheSeven has quit (Disconnected by services)
1099 2012-06-01 17:45:47 [7] has joined
1100 2012-06-01 17:47:32 spiborg has joined
1101 2012-06-01 17:47:58 maqr has quit (Quit: :/)
1102 2012-06-01 17:49:34 MobiusL has joined
1103 2012-06-01 17:50:47 danbri has joined
1104 2012-06-01 18:00:03 TD has joined
1105 2012-06-01 18:01:36 Diapolo has quit (Quit: Leaving.)
1106 2012-06-01 18:05:24 [7] has quit (Disconnected by services)
1107 2012-06-01 18:05:30 TheSeven has joined
1108 2012-06-01 18:10:38 drizztbsd has quit (Remote host closed the connection)
1109 2012-06-01 18:16:37 rdponticelli has joined
1110 2012-06-01 18:19:32 spiborg has quit (Quit: Nettalk6 - www.ntalk.de)
1111 2012-06-01 18:19:46 spiborg has joined
1112 2012-06-01 18:30:11 danbri has quit (Remote host closed the connection)
1113 2012-06-01 18:31:50 Z0rZ0rZ0r has joined
1114 2012-06-01 18:38:46 <BlueMatt> sipa: finally got around to implementing the stuff we talked about this morning in CHub, if you've got a chance, is the CWallet/CHubListener stuff roughly what you were thinking of?
1115 2012-06-01 18:44:52 rdponticelli has quit (Ping timeout: 245 seconds)
1116 2012-06-01 18:45:11 osmosis has quit (Ping timeout: 240 seconds)
1117 2012-06-01 18:48:55 talso has joined
1118 2012-06-01 18:50:41 sgornick has quit (Ping timeout: 240 seconds)
1119 2012-06-01 18:51:15 ahihi2 has quit (Read error: Connection reset by peer)
1120 2012-06-01 18:55:19 ahihi2 has joined
1121 2012-06-01 18:58:10 osmosis has joined
1122 2012-06-01 18:59:06 Turingi has quit (Read error: Connection reset by peer)
1123 2012-06-01 19:02:42 danbri has joined
1124 2012-06-01 19:04:32 sgornick has joined
1125 2012-06-01 19:09:39 darkee has joined
1126 2012-06-01 19:12:16 darkee has quit (Ping timeout: 276 seconds)
1127 2012-06-01 19:12:48 _W_ has quit (Excess Flood)
1128 2012-06-01 19:12:55 MobiusL has quit (Ping timeout: 276 seconds)
1129 2012-06-01 19:12:55 pickett has quit (Ping timeout: 276 seconds)
1130 2012-06-01 19:12:59 _W_ has joined
1131 2012-06-01 19:16:02 tower has quit (Disconnected by services)
1132 2012-06-01 19:16:16 tower has joined
1133 2012-06-01 19:17:50 graingert has quit (Read error: Connection reset by peer)
1134 2012-06-01 19:18:10 Joric has joined
1135 2012-06-01 19:18:11 Joric has quit (Changing host)
1136 2012-06-01 19:18:11 Joric has joined
1137 2012-06-01 19:24:49 p0s has joined
1138 2012-06-01 19:25:14 pickett has joined
1139 2012-06-01 19:26:04 MobiusL has joined
1140 2012-06-01 19:26:37 setkeh` has joined
1141 2012-06-01 19:26:39 setkeh has quit (Read error: No route to host)
1142 2012-06-01 19:27:37 phantomcircuit has joined
1143 2012-06-01 19:28:55 kjj_ has quit (Ping timeout: 260 seconds)
1144 2012-06-01 19:31:34 MC1984 has quit (Quit: Leaving)
1145 2012-06-01 19:34:15 Dyaheon has quit (Ping timeout: 244 seconds)
1146 2012-06-01 19:36:32 Skaag_ has joined
1147 2012-06-01 19:38:56 Skaag has quit (Ping timeout: 245 seconds)
1148 2012-06-01 19:38:56 Skaag_ is now known as Skaag
1149 2012-06-01 19:41:40 kjj_ has joined
1150 2012-06-01 19:41:48 graingert has joined
1151 2012-06-01 19:46:22 Dyaheon has joined
1152 2012-06-01 19:56:18 spaola has quit (Remote host closed the connection)
1153 2012-06-01 19:56:48 <nanotube> hey, would anyone fill me in on what differences there are between keys generated in old wallets, and ones generated in a fresh wallet created with the latest bitcoin client? i recall there being something about key compression, at least. and possibly something else?
1154 2012-06-01 19:57:23 egecko has joined
1155 2012-06-01 19:58:00 spaola has joined
1156 2012-06-01 19:58:59 O2made has joined
1157 2012-06-01 20:00:53 <gmaxwell> nanotube: newly generated keys use the compressed public keys.
1158 2012-06-01 20:01:17 RazielZ has quit (Ping timeout: 252 seconds)
1159 2012-06-01 20:01:20 <gmaxwell> (well keys generated in wallets which have been updated to the latest wallet version)
1160 2012-06-01 20:03:37 Detritus has quit (Ping timeout: 245 seconds)
1161 2012-06-01 20:03:38 <nanotube> gmaxwell: hm, would that affect the verifymessage functionality? specifically, seems electrum's verify_message fails on new-style addresses
1162 2012-06-01 20:03:44 Detritus has joined
1163 2012-06-01 20:03:45 RazielZ has joined
1164 2012-06-01 20:18:40 p0s has quit (Remote host closed the connection)
1165 2012-06-01 20:27:01 guruvan has quit (Ping timeout: 276 seconds)
1166 2012-06-01 20:30:02 MC1984 has joined
1167 2012-06-01 20:35:04 <ThomasV> gmaxwell: indeed this seems to be the issue
1168 2012-06-01 20:35:46 Diablo-D3 has quit (Remote host closed the connection)
1169 2012-06-01 20:36:26 <gmaxwell> nanotube: yes most likelyâ you need to know if the address you're matching was generated from the compressed public key or the non-compressed one.
1170 2012-06-01 20:39:57 <ThomasV> what exactly is a compressed pubkey?
1171 2012-06-01 20:41:07 Detritus has quit (Ping timeout: 245 seconds)
1172 2012-06-01 20:41:16 Detritus has joined
1173 2012-06-01 20:47:29 <freewil> is there a wiki page with the different formats
1174 2012-06-01 20:48:01 phantomcircuit has quit (Remote host closed the connection)
1175 2012-06-01 20:49:16 toffoo has joined
1176 2012-06-01 20:51:09 <helo> ThomasV: http://bitcoin.stackexchange.com/questions/3059/what-is-a-compressed-bitcoin-key
1177 2012-06-01 20:51:14 _W_ has quit (Excess Flood)
1178 2012-06-01 20:51:20 _W_ has joined
1179 2012-06-01 20:51:22 <helo> good analogy in the top response
1180 2012-06-01 20:52:03 <freewil> does the rpc command validateaddress accept compressed formats?
1181 2012-06-01 20:53:03 Turingi has joined
1182 2012-06-01 20:53:03 Turingi has quit (Changing host)
1183 2012-06-01 20:53:03 Turingi has joined
1184 2012-06-01 20:53:07 <gmaxwell> freewil: There no difference from the address side.
1185 2012-06-01 20:53:18 <gmaxwell> You can't tell by looking at an address if it reflects a compressed public key or not.
1186 2012-06-01 20:53:57 <freewil> hmm explain that
1187 2012-06-01 20:55:12 t7 has quit (Remote host closed the connection)
1188 2012-06-01 21:01:08 <ThomasV> gmaxwell: why are bitcoin addresses affected by this? it would have been possible to hash the noncompressed representation in both cases
1189 2012-06-01 21:04:52 <helo> a compressed address is just stored more compactly. the address seen by a user will look the same
1190 2012-06-01 21:05:43 rdponticelli has joined
1191 2012-06-01 21:06:01 <Eliel> but the address for a compressed public key is not the same address as for the same key in uncompressed form.
1192 2012-06-01 21:06:30 <ThomasV> hence my question
1193 2012-06-01 21:06:31 guruvan has joined
1194 2012-06-01 21:06:34 <helo> i think it is
1195 2012-06-01 21:06:41 <ThomasV> no it is not
1196 2012-06-01 21:06:57 <helo> in that case, disregard what i said Oo
1197 2012-06-01 21:07:07 <ThomasV> oh wait, no
1198 2012-06-01 21:07:51 <ThomasV> well, this is how I interpret what gmaxwell said above
1199 2012-06-01 21:08:00 <ThomasV> <gmaxwell> nanotube: yes most likely you need to know if the address you're matching was generated from the compressed public key or the non-compressed one.
1200 2012-06-01 21:09:09 <ThomasV> and the stackexchange page too says that
1201 2012-06-01 21:10:48 <helo> maybe he means you just have to know whether to "decompress" the public key before proceeding
1202 2012-06-01 21:11:03 <ThomasV> yes that's what he means
1203 2012-06-01 21:11:15 <ThomasV> but that does not answer my question
1204 2012-06-01 21:12:31 pickett has quit (Ping timeout: 276 seconds)
1205 2012-06-01 21:12:39 <gmaxwell> ThomasV: becaues it's already in the protocol.
1206 2012-06-01 21:13:01 <gmaxwell> ThomasV: the validation of compressed public keys was not added by anyone it was there from the start.
1207 2012-06-01 21:13:26 <gmaxwell> And the way you describe couldn't be added without a hard fork.
1208 2012-06-01 21:13:55 <gmaxwell> The addres has to be the hash of whatever public key (compressed or not) you'll send over the wire, because thats how the bitcoin protocol works.
1209 2012-06-01 21:14:01 <gmaxwell> s/addres/address/
1210 2012-06-01 21:14:17 <ThomasV> I see... but that's still a strange design decision
1211 2012-06-01 21:14:40 pickett has joined
1212 2012-06-01 21:16:00 <gmaxwell> E.g. look at the standard output script.. "check that the hash of the provided data matches X, check that the signature validates using that data". It's not "normalize the provided data into a pubkey ... hash that.. check ... checksig"
1213 2012-06-01 21:16:07 <gmaxwell> ThomasV: it wasn't designed it was an accident.
1214 2012-06-01 21:16:26 <ThomasV> gmaxwell: were uncompressed addresses used in the blockchain before 0.6 ?
1215 2012-06-01 21:16:30 <gmaxwell> OpenSSL supported compressed pubkeys without being asked to do so.
1216 2012-06-01 21:16:46 <gmaxwell> ThomasV: yes. They got used before anyone got to comment on them.
1217 2012-06-01 21:17:07 <ThomasV> lol. bitcoin really is a strange ecosystem
1218 2012-06-01 21:17:09 <gmaxwell> Otherwise I might have argued for instead forbidding them instead of using them ourselves, but since we were stuck with them, might as well enjoy the space savings.
1219 2012-06-01 21:17:56 <ThomasV> it saves no space in the blockchain since we use addresses
1220 2012-06-01 21:19:28 <Joric> using OpenSSL you just have to set point conversion via EC_KEY_set_conv_form()
1221 2012-06-01 21:19:43 <gmaxwell> ThomasV: ...
1222 2012-06-01 21:19:51 <gmaxwell> ThomasV: the redepitions are smaller.
1223 2012-06-01 21:20:09 <gmaxwell> redemptions*
1224 2012-06-01 21:20:13 <gmaxwell> By quite a bit in fact.
1225 2012-06-01 21:20:13 <Joric> compressed pubkeys are 32 bytes smaller
1226 2012-06-01 21:20:36 <gmaxwell> It makes the scriptsig about 25% smaller in total IIRC.
1227 2012-06-01 21:20:40 <ThomasV> oh sure
1228 2012-06-01 21:21:31 <Eliel> gmaxwell: you only need a signature to spend the compresse pubkey version but both pubkey and signature to spend a regular one?
1229 2012-06-01 21:21:42 <gmaxwell> paytopubkey even more soâ it makes paytopubkey almost competitive with key recovery.
1230 2012-06-01 21:22:19 <gmaxwell> Eliel: no, you still need pubkey and signature but the pubkey is half the size. Key recovery lets you spend with only the signature.
1231 2012-06-01 21:22:43 <gmaxwell> But we can't do that without a BIP16 style half-fork change or a hardfork.
1232 2012-06-01 21:23:04 <gmaxwell> Verifymessage uses key recovery though.
1233 2012-06-01 21:23:47 <Eliel> gmaxwell: so, the pubkey and signature stay but the hashed address goes and that's what saves the space?
1234 2012-06-01 21:24:48 <nanotube> ThomasV: so now electrum needs to learn how to do key recovery from a compressed pubkey :)
1235 2012-06-01 21:25:44 <ThomasV> nanotube: it sucks, doesn't it?
1236 2012-06-01 21:26:45 <ThomasV> gmaxwell: how does verifymessage know which type of pubkey it should use? does it try both?
1237 2012-06-01 21:29:15 <ThomasV> or does it get a clue from the signature?
1238 2012-06-01 21:35:38 <nanotube> Old clients can validate transactions with compressed public keys because Bitcoin sends public keys to OpenSSL without checking their format and OpenSSL automatically processes the public key according to the leading byte (0x04 for uncompressed, 0x02/0x03 for compressed). Â theymos
1239 2012-06-01 21:35:43 <nanotube> ThomasV: ^ from stackexchange
1240 2012-06-01 21:36:18 <nanotube> and yes, it does suck :)
1241 2012-06-01 21:36:40 <ThomasV> nanotube: yes, but verifymessage cannot rely on that; it does not have the pubkey
1242 2012-06-01 21:37:31 <gmaxwell> ThomasV: the signature has a key.
1243 2012-06-01 21:37:42 <ThomasV> ok
1244 2012-06-01 21:37:45 <gmaxwell> (there is an extra bit stuffed iirc)
1245 2012-06-01 21:38:04 <gmaxwell> Eliel: the pubkey itself becomes smaller.
1246 2012-06-01 21:38:45 <Joric> that verifymessage is it supposed mostly for signing oneliners?
1247 2012-06-01 21:39:48 <Joric> i tried to sign a long letter with it doesn't seem reliable to verify (cr/lf etc)
1248 2012-06-01 21:42:18 <Joric> i mean rpc interface / signmessage GUI
1249 2012-06-01 21:42:22 <gmaxwell> Joric: it's reliable if you actually can manage to get the data to it reliably. It doesn't mangle anyting on its own. Though for that sort of thing perhaps you're better off signing a hash.
1250 2012-06-01 21:42:28 silpee has joined
1251 2012-06-01 21:42:48 <gmaxwell> hm. well dunno what the gui does perhaps it does something non-transparent/consistent with cr/lr.
1252 2012-06-01 21:42:54 silp has quit (Ping timeout: 244 seconds)
1253 2012-06-01 21:44:02 <Joric> also why theres a signmessage GUI but no verifymessage GUI ? =)
1254 2012-06-01 21:44:17 Diapolo has joined
1255 2012-06-01 21:44:23 TD has quit (Quit: TD)
1256 2012-06-01 21:48:54 RainbowDashh has quit (Quit: RainbowDashh)
1257 2012-06-01 21:49:18 _Fireball has quit (Quit: HydraIRC -> http://www.hydrairc.com <- Wibbly Wobbly IRC)
1258 2012-06-01 21:52:08 <luke-jr> Joric: because verifymessage is more of a merchant function
1259 2012-06-01 21:52:12 <luke-jr> Joric: but someone added it for 0.7
1260 2012-06-01 21:54:35 tsche has quit (Ping timeout: 252 seconds)
1261 2012-06-01 21:54:54 RainbowDashh has joined
1262 2012-06-01 21:55:43 ThomasV has quit (Quit: Quitte)
1263 2012-06-01 21:56:01 RainbowDashh has quit (Remote host closed the connection)
1264 2012-06-01 21:56:23 RainbowDashh has joined
1265 2012-06-01 21:58:32 <luke-jr> holy crap
1266 2012-06-01 21:58:36 <luke-jr> bitcoind core dumps are 6.1 GB?
1267 2012-06-01 21:59:44 <D34TH> dafuq
1268 2012-06-01 22:01:30 <luke-jr> so⦠I dumped the contents of the memorypool that breaks txn_prio
1269 2012-06-01 22:01:39 <luke-jr> what's the best way to debug it? >.>
1270 2012-06-01 22:02:02 <luke-jr> I'd prefer to make a unit test, but it doesn't seem practical, since it probably depends on the blockchain
1271 2012-06-01 22:03:16 Skaag has quit (Read error: Connection reset by peer)
1272 2012-06-01 22:03:18 agricocb has quit (Remote host closed the connection)
1273 2012-06-01 22:03:35 Skaag has joined
1274 2012-06-01 22:04:58 welterde has quit (Ping timeout: 264 seconds)
1275 2012-06-01 22:06:40 RainbowDashh has quit (Quit: RainbowDashh)
1276 2012-06-01 22:09:49 <gmaxwell> luke-jr: hopefully that dump is a sparse file or something? 0_o
1277 2012-06-01 22:09:55 minimoose has quit (Quit: minimoose)
1278 2012-06-01 22:10:12 datagutt has quit (Quit: Computer has gone to sleep.)
1279 2012-06-01 22:12:24 <Joric> ThomasV has escaped
1280 2012-06-01 22:12:45 dvide has quit ()
1281 2012-06-01 22:13:30 <Joric> what do you guys thing about electrum? does it have future? it's semi-centralized atm there's like only 3 (well, 5) working servers
1282 2012-06-01 22:15:03 O2made has quit (Ping timeout: 244 seconds)
1283 2012-06-01 22:15:35 <luke-jr> gmaxwell: nope
1284 2012-06-01 22:16:04 <luke-jr> I suspect it doesn't compress well too
1285 2012-06-01 22:16:51 welterde has joined
1286 2012-06-01 22:18:43 <luke-jr> 89368e02d9bd17b74c2bd14b5296fcd713f7b7a0e5fd71f0f45783a1b63d8d59 is the txn it was having trouble with it seems
1287 2012-06-01 22:20:48 <luke-jr> hmm
1288 2012-06-01 22:21:03 <luke-jr> it had 17 levels deep of unconfirmed inputs
1289 2012-06-01 22:21:22 <gmaxwell> dicedos.
1290 2012-06-01 22:21:32 <luke-jr> :/
1291 2012-06-01 22:21:42 <luke-jr> gmaxwell: think caching the size of each individual txn would help?
1292 2012-06-01 22:21:50 <luke-jr> perhaps scoped to the GMP call
1293 2012-06-01 22:22:05 <luke-jr> it doesn't help the ordinary use case, but maybe it will fix this DoS
1294 2012-06-01 22:22:57 * luke-jr ponders how practical it would be to precalculate all this stuff as transactions come in and get put in blocks, rather than every CreateNewBlock call
1295 2012-06-01 22:23:30 <luke-jr> (maybe including the whole dependency tree and priority ordersâ¦)
1296 2012-06-01 22:24:23 <luke-jr> I suppose I'd need a flag to enable it, so it doesn't kill performance for non-miners
1297 2012-06-01 22:26:04 Diapolo has left ()
1298 2012-06-01 22:31:24 danbri has quit (Read error: Connection reset by peer)
1299 2012-06-01 22:31:33 danbri has joined
1300 2012-06-01 22:34:34 danbri has quit (Remote host closed the connection)
1301 2012-06-01 22:34:43 spiborg has quit (Ping timeout: 265 seconds)
1302 2012-06-01 22:37:26 RazielZ has quit (Quit: Leaving)
1303 2012-06-01 22:39:55 Diablo-D3 has joined
1304 2012-06-01 22:49:21 spiborg has joined
1305 2012-06-01 22:50:55 erle- has joined
1306 2012-06-01 22:52:10 imsaguy is now known as imsaguyat40
1307 2012-06-01 22:55:52 imsaguyat40 is now known as imsaguy
1308 2012-06-01 22:57:23 ciscoftw has joined
1309 2012-06-01 22:58:26 <ciscoftw> if you were to send .001 bitcoin and not include a transaction fee, is it possible that it never (...or for a long time) gets included into the blockchain?
1310 2012-06-01 22:58:49 <luke-jr> ciscoftw: pretty likely
1311 2012-06-01 22:58:59 <luke-jr> the long time bit anyhow
1312 2012-06-01 22:59:51 <ciscoftw> i send .05 btc from an andorid wallet app and my receiving address never got it (i did NOT send a trans fee)... was curious if that was a possibility
1313 2012-06-01 23:00:09 <luke-jr> how long ago?
1314 2012-06-01 23:00:16 <gmaxwell> .001 is not 0.05 though.
1315 2012-06-01 23:00:16 <ciscoftw> eh? maybe a week or so
1316 2012-06-01 23:00:24 <ciscoftw> it was .05
1317 2012-06-01 23:00:30 <ciscoftw> ...poor example to use .001
1318 2012-06-01 23:00:33 <luke-jr> which Android wallet app?
1319 2012-06-01 23:00:45 <gmaxwell> TXN without otputs under .01 are special and are MUCH less likely to get mined without a fee.
1320 2012-06-01 23:00:48 <ciscoftw> 'bitcoin wallet' 2.1
1321 2012-06-01 23:00:56 <ciscoftw> by andreas schildbach
1322 2012-06-01 23:01:26 <luke-jr> has it been running the whole week?
1323 2012-06-01 23:02:03 <ciscoftw> not the android app... just figured after it was broadcast to network i could shut it down
1324 2012-06-01 23:02:16 <ciscoftw> shut it down 20secs after sending
1325 2012-06-01 23:04:21 <ciscoftw> any doc you would suggest that details how miner choose what tx's to include into their block?
1326 2012-06-01 23:04:45 ovidiusoft has quit (Read error: Operation timed out)
1327 2012-06-01 23:06:10 <luke-jr> ciscoftw: arbitrarily.
1328 2012-06-01 23:06:31 <luke-jr> ciscoftw: you probably need to rebroadcast it at this point
1329 2012-06-01 23:07:18 <luke-jr> ciscoftw: fees are the main incentive for miners to include transactions, FWIW
1330 2012-06-01 23:08:24 <ciscoftw> ?but a txt doenst make a block any more difficult to solve, why not just incldue it?
1331 2012-06-01 23:09:38 <gmaxwell> For example, if someone is jerk they could easily create thousands of low value transactions per second to flood bitcoin... so by default miners have rules to not mine txn that look like a dos attack.
1332 2012-06-01 23:11:41 <luke-jr> ciscoftw: anti-spam, plus if miners always include feeless txns then there's no incentive for people to pay fees
1333 2012-06-01 23:11:49 <luke-jr> and without fees, miners might lose money mining
1334 2012-06-01 23:11:51 maqr has joined
1335 2012-06-01 23:12:08 <ciscoftw> incentive for solving the block isnt enough?
1336 2012-06-01 23:12:19 <luke-jr> ciscoftw: not in the fall, no
1337 2012-06-01 23:12:29 <ciscoftw> i mean fee's arent shit comparded to block solve award
1338 2012-06-01 23:12:39 <luke-jr> when the subsidy halves to 25 BTC, GPU miners cease to be profitable without significant fees
1339 2012-06-01 23:13:07 <ciscoftw> ascii ftw?
1340 2012-06-01 23:13:14 <luke-jr> it seems reasonable that some (many?) of those miners are trying hard to encourage fees to build up by then, so they don't go out of business
1341 2012-06-01 23:13:37 <ciscoftw> thanx for your input too luke-jr/gmaxwell
1342 2012-06-01 23:14:00 Turingi has quit (Read error: Connection reset by peer)
1343 2012-06-01 23:14:36 danbri has joined
1344 2012-06-01 23:14:39 <luke-jr> also, for a more concrete example on risks: Eligius has been crashing lately when there are a lot of txns to process
1345 2012-06-01 23:14:54 <luke-jr> (I'm working on fixing it, of course)
1346 2012-06-01 23:15:16 erle- has quit (Quit: erle-)
1347 2012-06-01 23:15:23 hnz has quit ()
1348 2012-06-01 23:15:46 erle- has joined
1349 2012-06-01 23:15:46 erle- has quit (Client Quit)
1350 2012-06-01 23:16:24 danbri has quit (Remote host closed the connection)
1351 2012-06-01 23:17:26 <luke-jr> and to get a feel for the level of spam, hang out in #bitcoin-watch for a few days ;)
1352 2012-06-01 23:18:05 <sipa> BlueMatt: that's pretty much what i was thinking about
1353 2012-06-01 23:19:03 <sipa> BlueMatt: though connecting to multiple hubs is overkill imho, and it is not only a listener
1354 2012-06-01 23:21:19 <sipa> luke-jr: it probably comtains the entire allocated region of virtual memory
1355 2012-06-01 23:21:52 <sipa> doesn't mean that all of it belongs (or belonged) to the working set at some point
1356 2012-06-01 23:21:54 <luke-jr> probably
1357 2012-06-01 23:25:51 sacredchao has joined
1358 2012-06-01 23:27:41 agricocb has joined
1359 2012-06-01 23:29:02 <BlueMatt> sipa: oops, calling it Listener was stupid, yea
1360 2012-06-01 23:29:04 <BlueMatt> sipa: multiple hubs is probably overkill, yea, but why not support it, its not like its extra code
1361 2012-06-01 23:29:08 <BlueMatt> what if I dont trust any of the blockstores and want to connect to 5 untrusted network proxy hubs?
1362 2012-06-01 23:29:10 <BlueMatt> obviously thats no where near supported atm
1363 2012-06-01 23:29:47 ciscoftw has quit ()
1364 2012-06-01 23:31:07 rdponticelli has quit (Ping timeout: 245 seconds)
1365 2012-06-01 23:33:28 Apexseals has joined
1366 2012-06-01 23:33:49 copumpkin has quit (Quit: Computer has gone to sleep.)
1367 2012-06-01 23:35:35 <sipa> BlueMatt: then you connect the hub to 5 network nodes :)
1368 2012-06-01 23:35:46 <sipa> will certainly be more efficieny
1369 2012-06-01 23:36:38 salitron has joined
1370 2012-06-01 23:37:34 <BlueMatt> sipa: I was thinking I dont wanna run a hub, I connect to 5 web-service hubs that I only marginally trust
1371 2012-06-01 23:37:46 <sipa> right
1372 2012-06-01 23:37:58 <BlueMatt> oh, you mean run 1 hub connected to 5 network blockstores or?
1373 2012-06-01 23:38:29 <sipa> not really, as hub is really a job queue for (one) blockstore for now
1374 2012-06-01 23:39:37 <BlueMatt> thats my point?
1375 2012-06-01 23:40:08 <gmaxwell> you've now spent more time talking about it then it would take to switch from one behavior to the other in the future. :)
1376 2012-06-01 23:40:23 <BlueMatt> gmaxwell: Im coding in the background...
1377 2012-06-01 23:40:40 <sipa> yes, so: no that was not what i was talking about, and that does indeed sound like a reasonable though very futuristic use case
1378 2012-06-01 23:40:44 <gmaxwell> (I agree with bluematt's notion of the future where you might have one wallet talking to multiple blockstores in the futureâ but there is so much code between then and now that I don't think it matters much)
1379 2012-06-01 23:40:55 <sipa> agree
1380 2012-06-01 23:41:28 <BlueMatt> alright, Ill remove the set for now, doesnt matter in the slightest to me
1381 2012-06-01 23:41:28 <sipa> maybe rather for reliability than for reason of trust
1382 2012-06-01 23:42:08 <sipa> since the hub communication isn't really intended to be used in an untrusted environment
1383 2012-06-01 23:42:29 <BlueMatt> yea, thats probably a better use-case
1384 2012-06-01 23:43:20 <luke-jr> maybe require under 20ms latency to hub, just to prevent public hubs?
1385 2012-06-01 23:43:26 <sipa> though i think there you rather want a failoverproxyhub than multihub support in the wallet
1386 2012-06-01 23:44:03 <sipa> luke-jr: right now, hubs are c++ interfaces and not a network protocol, so that's not really a problem :p
1387 2012-06-01 23:44:03 <gmaxwell> an important use case is semi-trusted. E.g. a VPS provider runs one blockstore, multiple wallets connect. Zero trust isn't relevant because the vps provider could still root you... but you don't want gratuitous insecurity.
1388 2012-06-01 23:44:08 <luke-jr> (by "require" I mean "force users to manually set a commandline/config option to override it")
1389 2012-06-01 23:44:16 <luke-jr> sipa: ah, true :P
1390 2012-06-01 23:44:56 <sipa> gmaxwell: good point
1391 2012-06-01 23:46:17 osmosis has quit (Quit: Leaving)
1392 2012-06-01 23:46:42 <sipa> i was thinking
1393 2012-06-01 23:47:00 <sipa> what if my crawler wouldn't only request getaddr's
1394 2012-06-01 23:47:17 <sipa> but also push some addr's to nodes it connects to
1395 2012-06-01 23:47:51 <gmaxwell> seems like a prudent payment for the cost of being crawled in fact.
1396 2012-06-01 23:48:32 <sipa> nice thing: it adds free seeding capability to onion nodes
1397 2012-06-01 23:49:00 <gmaxwell> How so?
1398 2012-06-01 23:49:02 <sipa> bad thing: it only works for nodes that are known to be reachable, so who don't really need it
1399 2012-06-01 23:49:13 <gmaxwell> Right. okay.
1400 2012-06-01 23:49:33 <luke-jr> XD
1401 2012-06-01 23:51:01 <gmaxwell> I think it's generally a fine idea. Along those lines, nodes doing the node hopping thing in the future should probably prefer to relay the nodes they just disconnected. "Sorry it didn't work out, but I'll set you up on a date with my friend!"
1402 2012-06-01 23:51:26 <sipa> gmaxwell: good idea
1403 2012-06-01 23:52:40 copumpkin has joined
1404 2012-06-01 23:53:00 da2ce7 has quit (Read error: Connection reset by peer)
1405 2012-06-01 23:54:06 <sipa> i'd also to like the seeder reachable via P2P (though disconnecting after sending addr's, or silence of 10s)
1406 2012-06-01 23:54:35 da2ce7 has joined
1407 2012-06-01 23:55:34 <sipa> DoS is then just about the corner, probably though
1408 2012-06-01 23:58:29 rdponticelli has joined