1 2011-03-24 00:02:06 <CIA-96> bitcoin: Luke Dashjr <luke-jr+git@utopios.org> * re5ee25b77f3b spesmilo/settings.py: allow user to configure whether their preferred unit's TLA is shown or not
2 2011-03-24 00:03:14 <Sargun_Screen> phantomcircuit: Nah, I was going to build a custom rig for it
3 2011-03-24 00:03:23 <phantomcircuit> oh
4 2011-03-24 00:03:35 <Sargun_Screen> If I lease all the gear needed plus power, it'd be about $300/mo
5 2011-03-24 00:05:28 <Ruudjah> any guides for building good rigs?
6 2011-03-24 00:06:10 <Ruudjah> thinking of buying a dual-quad-hex pciex16 mobo, then put 2-4-6 5970 on it
7 2011-03-24 00:08:09 <xenon481> Don't waste your money on multiple x16 slots.
8 2011-03-24 00:08:25 <xenon481> The cards mine just as fast when running on x1 slots
9 2011-03-24 00:08:37 <[Tycho]> Ruudjah, don't forget about cooling.
10 2011-03-24 00:08:45 <noagendamarket> theres plenty of random miners with 6ghsh or more
11 2011-03-24 00:09:13 <[Tycho]> Ruudjah, if you are going to pug cards directly into MB, there may be cooling problems if no free space is left between them
12 2011-03-24 00:09:18 <[Tycho]> *plug
13 2011-03-24 00:09:40 <xenon481> noagendamarket: Yeah, it's just coincidence, I was just seeing if I could track it down as a puzzle for me.
14 2011-03-24 00:10:05 <xenon481> But the anonymity is part of the BTC beauty.
15 2011-03-24 00:10:40 <noagendamarket> tell me if you ever find it lol
16 2011-03-24 00:11:01 <Ruudjah> true
17 2011-03-24 00:11:03 <noagendamarket> *squirrel
18 2011-03-24 00:11:08 <Ruudjah> prolly would need watercooling
19 2011-03-24 00:11:21 <Ruudjah> or just 2 graka
20 2011-03-24 00:11:25 <xenon481> I don't think I'll be able to find it since it isn't one of the pools
21 2011-03-24 00:12:07 <[Tycho]> Watercooling is good, but not cost-effective at all.
22 2011-03-24 00:12:10 <Ruudjah> "6ghsh" ?
23 2011-03-24 00:12:43 <Ruudjah> [Tycho]: I doubt that. It mainly depends on the reusability of the connectors/cool blocks
24 2011-03-24 00:13:01 <Ruudjah> e.g. I bought 2x alpha coolers for my bp6 (long time ago)
25 2011-03-24 00:13:34 <Ruudjah> worked on 2x celly 300, p3 coppermine
26 2011-03-24 00:13:59 <Ruudjah> --> generic cooling gear should be able to be reused across platforms
27 2011-03-24 00:14:18 <Ruudjah> noagendamarket: "6ghsh"?
28 2011-03-24 00:14:35 <xenon481> Ruudjah: 6 GHash/sec mining speed.
29 2011-03-24 00:15:26 <bitcoinNewb> can someone explain pooling?
30 2011-03-24 00:16:08 <[Tycho]> bitcoinNewb, it's a cooperative mining with many other users.
31 2011-03-24 00:16:25 <xenon481> bitcoinNewb: A bunch of people work together and then split the profits.
32 2011-03-24 00:16:47 <[Tycho]> bitcoinNewb, welcome to my mining pool :) http://deepbit.net
33 2011-03-24 00:16:52 <bitcoinNewb> I see
34 2011-03-24 00:18:45 <bitcoinNewb> Have you guys seen interest spike since slashdot article
35 2011-03-24 00:20:06 <noagendamarket> yes
36 2011-03-24 00:20:30 <bitcoinNewb> I've been looking for a way better way to transfer money between countries, and this is awesome, but I think its way over my head
37 2011-03-24 00:21:21 <joepie91> good morning all
38 2011-03-24 00:21:23 <joepie91> or well, evening :P
39 2011-03-24 00:21:37 <[Tycho]> ;;bc,gen 100000
40 2011-03-24 00:21:44 <[Tycho]> ;;bc,calc 100000
41 2011-03-24 00:21:45 <gribble> The average time to generate a block at 100000 Khps, given current difficulty of 76193.9710474 , is 5 weeks, 2 days, 21 hours, 1 minute, and 46 seconds
42 2011-03-24 00:22:16 <joepie91> I managed to get a 7gbps flood directed at my site yesterday.
43 2011-03-24 00:22:17 <joepie91> how fun is that.
44 2011-03-24 00:22:44 <joepie91> apparently somewhat knocked over the dc or something... at least the upstream provider called the dc because their network was affected
45 2011-03-24 00:23:03 <CIA-96> bitcoin: phantomcircuit <phantomcircuit@covertinferno.org> sqlalchemy * r084ac9daf6a9 bitcoin-alt/bitcoin/ (net/peer.py peer.py peers.py storage.py): Cleaned some stuff up
46 2011-03-24 00:24:17 <Impala> ;;bc,gen 160000
47 2011-03-24 00:24:18 <gribble> The expected generation output, at 160000 Khps, given current difficulty of 76193.9710474 , is 2.11214271526 BTC per day and 0.0880059464691 BTC per hour.
48 2011-03-24 00:24:30 <[Tycho]> ;;bc,calc 485000
49 2011-03-24 00:24:31 <gribble> The average time to generate a block at 485000 Khps, given current difficulty of 76193.9710474 , is 1 week, 0 days, 19 hours, 25 minutes, and 43 seconds
50 2011-03-24 00:24:37 <[Tycho]> ;;bc,gen 485000
51 2011-03-24 00:24:38 <gribble> The expected generation output, at 485000 Khps, given current difficulty of 76193.9710474 , is 6.40243260563 BTC per day and 0.266768025234 BTC per hour.
52 2011-03-24 00:24:56 <phantomcircuit> crap i just realized something
53 2011-03-24 00:25:42 <phantomcircuit> if i batch these transactions/blocks into sql transactions with a uniqueness constraint on the db and have multiple overlapping peers the odds of ever having a trasnaction commit are basically zero
54 2011-03-24 00:25:45 <phantomcircuit> >.>
55 2011-03-24 00:34:53 <[Tycho]> ;;bc,gen 300000
56 2011-03-24 00:34:55 <gribble> The expected generation output, at 300000 Khps, given current difficulty of 76193.9710474 , is 3.96026759111 BTC per day and 0.16501114963 BTC per hour.
57 2011-03-24 00:35:55 <Bosma> ;;bc,stats
58 2011-03-24 00:35:57 <gribble> Current Blocks: 114761 | Current Difficulty: 76193.9710474 | Next Difficulty At Block: 114911 | Next Difficulty In: 150 blocks | Next Difficulty In About: 1 day, 2 hours, 55 minutes, and 0 seconds | Next Difficulty Estimate: 68457.74108195
59 2011-03-24 00:36:06 <Bosma> ;;bc,gend 310000 68457
60 2011-03-24 00:36:07 <gribble> The expected generation output, at 310000 Khps, given the supplied difficulty of 68457, is 4.55478326513 BTC per day and 0.189782636047 BTC per hour.
61 2011-03-24 00:46:21 <phantomcircuit> lol i've got my storage all mixed up with my networking
62 2011-03-24 00:46:29 <phantomcircuit> i had it so loverly before
63 2011-03-24 00:46:30 <alex___> ;;bc,gen 800
64 2011-03-24 00:46:30 <gribble> The expected generation output, at 800 Khps, given current difficulty of 76193.9710474 , is 0.0105607135763 BTC per day and 0.000440029732346 BTC per hour.
65 2011-03-24 00:46:31 <phantomcircuit> now it's a mess
66 2011-03-24 00:46:33 <phantomcircuit> :(((
67 2011-03-24 00:55:01 <manveru> heya
68 2011-03-24 00:55:22 <manveru> is the bitcoin-bin package on archlinux still recommended against?
69 2011-03-24 00:57:12 <phantomcircuit> manveru, probably
70 2011-03-24 00:57:48 <manveru> i can't build bitcoin... fails with some error because i have gtk 2.22 instead of 2.4
71 2011-03-24 00:59:11 <manveru> bitcoin-bin has stuff like "Please use bitcoin instead of bitcoin-bin if possible" all over the place, but no reason why...
72 2011-03-24 01:01:32 <phantomcircuit> wait
73 2011-03-24 01:01:44 <phantomcircuit> the nonce is a 32bit unsigned int that uses up 64 bits?
74 2011-03-24 01:01:45 <phantomcircuit> lol wtf
75 2011-03-24 01:05:31 <manveru> also weird that all flags are like -gen/-server/-rescan but help is --help
76 2011-03-24 01:20:37 <slush> [Tycho]: do you already sending payments with sendmany?
77 2011-03-24 01:20:47 <slush> [Tycho]: how long it take to be included in the block?
78 2011-03-24 01:23:15 <[Tycho]> I'm accepting sendmany in my blocks, but don't plan to crete them myself yet.
79 2011-03-24 01:23:28 <[Tycho]> *create
80 2011-03-24 01:24:20 <[Tycho]> By the way, have you seen big combining txes in queue with multiple 0.02 inputs ?
81 2011-03-24 01:29:53 <slush> yes, looking on it right now
82 2011-03-24 01:30:01 <slush> new way of spam? :)
83 2011-03-24 01:30:27 <[Tycho]> May be he assumed that people is ignoring 0.01 at output :)
84 2011-03-24 01:31:04 <slush> But it is really weird why bitcoin does not accept my sendmany transaction with the fee
85 2011-03-24 01:31:21 <[Tycho]> Which bitcoin ?
86 2011-03-24 01:31:37 <slush> any bitcoin, for example my pool instances
87 2011-03-24 01:31:38 <[Tycho]> Oh, you are talking about creating it ?
88 2011-03-24 01:31:52 <[Tycho]> Haven't tried yet.
89 2011-03-24 01:32:12 <slush> I have blocked free transcations, but don't see reason why to reject multitx
90 2011-03-24 01:33:11 <slush> I have to go sleep. Hope I'll find any explanation tomorrow
91 2011-03-24 01:51:57 <[Tycho]> Looks like your sendmany made it into my block
92 2011-03-24 01:53:43 <devrandom> I'm curious - since sendmany is a new transaction type, most people won't relay it. so how does it get to miners?
93 2011-03-24 01:54:02 <devrandom> I guess since slush is effectively a miner, he can get it into a block himself?
94 2011-03-24 01:55:04 <[Tycho]> It was a lucky transaction :)
95 2011-03-24 01:55:13 <slush> devrandom: correct, but I've using many bitcoin instances and there is no easy way how to tell them "this is my tx" :)
96 2011-03-24 01:56:16 <devrandom> as long as all the instances have the sendmany patch, then they'll accept it into the currently mined block?
97 2011-03-24 01:58:49 <LobsterMan> is www.bitcoin.org down or something?
98 2011-03-24 01:59:20 <LobsterMan> it redirects to bitcoin.it
99 2011-03-24 02:00:34 <nanotube> LobsterMan: deliberate, to weather the /. effect
100 2011-03-24 02:00:40 <LobsterMan> ah...lol
101 2011-03-24 02:01:02 <devrandom> slush - I guess the problem would be if your instances are not directly connected to each-other
102 2011-03-24 02:01:45 <slush> they are
103 2011-03-24 02:03:58 <devrandom> in that case, they should all be accepting the tx and using it to mine... that's not happening?
104 2011-03-24 02:04:23 <luke-jr> https://en.bitcoin.it/w/index.php?title=Special:RecentChanges&from=20110324020552&days=30&limit=500
105 2011-03-24 02:04:25 <luke-jr> spammer alert
106 2011-03-24 02:04:31 <devrandom> (slush - sorry if I'm jumping into the middle of a longer discussion)
107 2011-03-24 02:04:32 <luke-jr> nanotube: MagicalTux
108 2011-03-24 02:05:36 <slush> devrandom: no prob :)
109 2011-03-24 02:06:05 <slush> well, I have custom changes to reject free transactions to speed up new block processing
110 2011-03-24 02:06:18 <slush> maybe it is somehow related, but now I don't see clearly how
111 2011-03-24 02:06:24 <nanotube> luke-jr: tx for pointing out. blocking user and deleting his crap.
112 2011-03-24 02:06:44 <slush> I'll discuss it tomorrow with people and if it will go well, I'll start accepting free tx again
113 2011-03-24 02:07:12 <MagicalTux> ?
114 2011-03-24 02:08:35 <MagicalTux> oh
115 2011-03-24 02:09:22 <nanotube> MagicalTux: the spammers come out of the woodwork....
116 2011-03-24 02:09:31 <MagicalTux> spammers are always around
117 2011-03-24 02:09:47 <MagicalTux> if you want me to install a captcha plugin for mediawiki (or something else), let me know
118 2011-03-24 02:10:00 <nanotube> MagicalTux: yea, probably a recaptcha on user registration wouldn't hurt.
119 2011-03-24 02:10:11 <MagicalTux> :p
120 2011-03-24 02:10:31 <Kiba> do newer peer refuse to communicate with older versions
121 2011-03-24 02:10:35 <Kiba> for example, mine is 0.3.19
122 2011-03-24 02:12:09 <luke-jr> MagicalTux: how about those footnote letters?
123 2011-03-24 02:12:46 <devrandom> slush - don't see how it's related either...
124 2011-03-24 02:15:36 <nanotube> MagicalTux: the wiki is registered-user-only for editing, right? :)
125 2011-03-24 02:17:25 <devrandom> slush - maybe triple-check that all your instances have the sendmany patch
126 2011-03-24 02:17:52 <slush> I quadruple-checked it already ;)
127 2011-03-24 02:18:13 <slush> I'll pull new version tomorrow, so then I'll be absolutely-hyper-super-mega-sure
128 2011-03-24 02:18:34 <Impala> ;;bc,gen 160000
129 2011-03-24 02:18:35 <gribble> The expected generation output, at 160000 Khps, given current difficulty of 76193.9710474 , is 2.11214271526 BTC per day and 0.0880059464691 BTC per hour.
130 2011-03-24 02:18:57 <devrandom> slush - and you are also sure that they are directly connected to the bitcoin instance that generated the sendmany tx?
131 2011-03-24 02:19:09 <devrandom> sorry if I'm being obvious
132 2011-03-24 02:20:25 <slush> yes
133 2011-03-24 02:20:43 <slush> no problem, I'm happy that somebody else it thinking about possible problems
134 2011-03-24 02:22:14 <devrandom> slush - you can grep for the tx in debug.log
135 2011-03-24 02:22:32 <devrandom> just the first 10 chars
136 2011-03-24 02:22:52 <devrandom> grep abcdef1234 ~/.bitcoing/debug.log
137 2011-03-24 02:23:00 <slush> ok, I'll do that tomorrow
138 2011-03-24 02:23:03 <slush> I really need to sleep
139 2011-03-24 02:23:18 <devrandom> later
140 2011-03-24 02:29:00 <noagendamarket> https://bitcoinbonus.com/referral/2f6269a9 you can get .10 there :)
141 2011-03-24 02:35:09 <Impala> ;;bc,gen 120000
142 2011-03-24 02:35:10 <gribble> The expected generation output, at 120000 Khps, given current difficulty of 76193.9710474 , is 1.58410703644 BTC per day and 0.0660044598518 BTC per hour.
143 2011-03-24 02:36:36 <doublec> soon your website will be able to earn money by mining bitcoins: "Along with the pure graphics technology, Khronos has also planned a new, general-purpose computing equivalent known as WebCL. The compute language would let a browser use JavaScript to trigger parallel computing using the graphics chip, giving many of the features of OpenCL to a web browser."
144 2011-03-24 02:39:21 <noagendamarket> hmm
145 2011-03-24 02:41:12 <Impala> ;;bc,gen 135000
146 2011-03-24 02:41:13 <gribble> The expected generation output, at 135000 Khps, given current difficulty of 76193.9710474 , is 1.782120416 BTC per day and 0.0742550173333 BTC per hour.
147 2011-03-24 02:41:31 <Impala> ;;bc,gen 144000
148 2011-03-24 02:41:32 <gribble> The expected generation output, at 144000 Khps, given current difficulty of 76193.9710474 , is 1.90092844373 BTC per day and 0.0792053518222 BTC per hour.
149 2011-03-24 02:50:06 <AmpEater> ;;bs,stats
150 2011-03-24 02:50:07 <gribble> Error: "bs,stats" is not a valid command.
151 2011-03-24 02:50:14 <AmpEater> ;;bc,stats
152 2011-03-24 02:50:16 <gribble> Current Blocks: 114777 | Current Difficulty: 76193.9710474 | Next Difficulty At Block: 114911 | Next Difficulty In: 134 blocks | Next Difficulty In About: 23 hours, 53 minutes, and 48 seconds | Next Difficulty Estimate: 68602.07903395
153 2011-03-24 02:50:44 <AmpEater> ;;bc,gend 5000000 68600
154 2011-03-24 02:50:45 <gribble> The expected generation output, at 5000000 Khps, given the supplied difficulty of 68600, is 73.3111064566 BTC per day and 3.05462943569 BTC per hour.
155 2011-03-24 02:58:11 <Kiba> hey guys
156 2011-03-24 02:58:25 <AmpEater> howdy
157 2011-03-24 02:58:27 <Validus> sup kiba
158 2011-03-24 02:58:46 <AmpEater> was somebody working on an iphone app? who do i need to prod?
159 2011-03-24 03:00:46 <Kiba> I don't think bitcoin and iphone likes each other
160 2011-03-24 03:03:41 <AmpEater> cause of apple restricting certain apps?
161 2011-03-24 03:33:04 <CIA-96> bitcoin: phantomcircuit <phantomcircuit@covertinferno.org> sqlalchemy * rbd8d0d17e275 bitcoin-alt/ (4 files in 3 dirs): Bug fixes and changed primary key
162 2011-03-24 03:55:17 <Mango-chan> ;;bc,stats
163 2011-03-24 03:55:19 <gribble> Current Blocks: 114785 | Current Difficulty: 76193.9710474 | Next Difficulty At Block: 114911 | Next Difficulty In: 126 blocks | Next Difficulty In About: 22 hours, 19 minutes, and 48 seconds | Next Difficulty Estimate: 68693.14908113
164 2011-03-24 03:56:54 <AmpEater> difficulty keeps sneaking up
165 2011-03-24 04:01:15 <Diablo-D3> https://github.com/blog/821-mention-somebody-they-re-notified
166 2011-03-24 04:49:52 <da2ce7> how hard is bitcoin.it getting hammered?
167 2011-03-24 04:50:42 <dissipate> da2ce7, pretty hard. some hits from whitehouse.gov
168 2011-03-24 04:50:55 <da2ce7> lol
169 2011-03-24 04:51:21 <da2ce7> is it still holding up ok?
170 2011-03-24 04:52:11 <dissipate> looks like it is
171 2011-03-24 04:52:40 <dissipate> i still don't understand why bitcoin.org itself is not up on a more robust host
172 2011-03-24 04:52:59 <da2ce7> who set up the re-direct?
173 2011-03-24 04:53:30 <dissipate> i have no idea to be honest
174 2011-03-24 04:56:02 <luke-jr> Sirius
175 2011-03-24 04:56:07 <CIA-96> bitcoin: Luke Dashjr <luke-jr+git@utopios.org> * raac9e3e8938a spesmilo/settings.py: woops, bugfix :)
176 2011-03-24 05:04:50 <Blitzboom> slush: how come your pool isnt paying me although the reward is higher than the threshold?
177 2011-03-24 05:05:00 <Blitzboom> confirmed reward of course
178 2011-03-24 07:22:30 <slush> Blitzboom: read forum, I'm sending it manually, with the delay
179 2011-03-24 07:22:40 <slush> Blitzboom: I wake up right now, so I'll send next batch soon :)
180 2011-03-24 07:28:42 <Blitzboom> oh, thats done manually now?
181 2011-03-24 07:28:50 <Blitzboom> ok
182 2011-03-24 07:28:50 <slush> yes, for some time
183 2011-03-24 07:29:10 <Blitzboom> due to sendmany i guess?
184 2011-03-24 07:29:27 <Blitzboom> nvm, ill just look it up on the forums
185 2011-03-24 07:29:41 <slush> yep
186 2011-03-24 08:01:16 <genjix> nanotube: hey
187 2011-03-24 08:14:43 <CIA-96> bitcoinj: hearn@google.com * r37 /trunk/ (11 files in 2 dirs): (log message trimmed)
188 2011-03-24 08:14:44 <CIA-96> bitcoinj: NetworkParameters to make that easier.
189 2011-03-24 08:14:45 <CIA-96> bitcoinj: - Track the best chain using total work done. Inform the wallet
190 2011-03-24 08:26:28 <CIA-96> bitcoinj: hearn@google.com * r38 /trunk/ (50 files in 6 dirs): Refresh JavaDocs
191 2011-03-24 08:29:23 <finnomenon> ;rate 122 mhash
192 2011-03-24 08:30:53 <lfm> ;;bc,calc 122000
193 2011-03-24 08:30:54 <gribble> The average time to generate a block at 122000 Khps, given current difficulty of 76193.9710474 , is 4 weeks, 3 days, 1 hour, 6 minutes, and 22 seconds
194 2011-03-24 08:31:21 <rli> ;;bc,stats
195 2011-03-24 08:31:23 <gribble> Current Blocks: 114814 | Current Difficulty: 76193.9710474 | Next Difficulty At Block: 114911 | Next Difficulty In: 97 blocks | Next Difficulty In About: 17 hours, 6 minutes, and 35 seconds | Next Difficulty Estimate: 68849.51764158
196 2011-03-24 08:31:26 <lfm> ;;bc,gen 122000
197 2011-03-24 08:31:27 <gribble> The expected generation output, at 122000 Khps, given current difficulty of 76193.9710474 , is 1.61050882038 BTC per day and 0.0671045341827 BTC per hour.
198 2011-03-24 08:31:31 <genjix> hmm i ask a problem in #economics and people here don't get simple math
199 2011-03-24 08:32:08 <lfm> peopel there?
200 2011-03-24 08:32:51 <ArtForz> hrrrmz
201 2011-03-24 08:32:54 <genjix> there
202 2011-03-24 08:33:11 <genjix> and they didn't know that floating point gives rounding errors
203 2011-03-24 08:33:41 <ArtForz> the more I look at it, the more I think Reorganize putting tx into mem pool without checking inputs is a bug
204 2011-03-24 08:33:52 <lfm> genjix: well study of economics is a soft science. I wouldnt expect them to understand math
205 2011-03-24 08:34:15 <genjix> really? whenever i read econ on wikipedia, it seems heavy on math
206 2011-03-24 08:34:29 <genjix> the models
207 2011-03-24 08:34:31 <ArtForz> well, at least a misfeature
208 2011-03-24 08:34:39 <lfm> its more like psycology or socialogy than science
209 2011-03-24 08:34:58 <genjix> ok
210 2011-03-24 08:35:11 <genjix> psychology is nice, but neurology is making it irrelevant :)
211 2011-03-24 08:35:53 <lfm> sometimes they try to take on the trppings of math to seem reliable but they dont really understand it
212 2011-03-24 08:35:56 <TD_> ArtForz: well, it seems deliberate
213 2011-03-24 08:36:23 <ArtForz> yes
214 2011-03-24 08:36:23 <TD_> ArtForz: if it did it'd hit the throttling checks
215 2011-03-24 08:36:25 <genjix> lfm: yeah thats why im confused why #economics people were bad at math :p
216 2011-03-24 08:36:38 <ArtForz> err, so dont have it do those
217 2011-03-24 08:36:56 <ArtForz> but at least check that tx inouts still refer to possibly valid tx
218 2011-03-24 08:37:01 <lfm> genjix: they like to plot random curves and then fit equations to them
219 2011-03-24 08:37:11 <genjix> ic
220 2011-03-24 08:37:34 <ArtForz> what happens on a > 120 block reorg when the now-shorter branch contains tx that use coinbases from that branch?
221 2011-03-24 08:38:34 <ArtForz> that tx is *invalid* in the new branch, gets caught by miner connectinputs
222 2011-03-24 08:38:38 <lfm> genjix: stuff like the price of bitcoins makes a cute plot but its not really math. you can sometimes make some sort of equation fit the data after the fact but it predictive value is very smal
223 2011-03-24 08:38:39 <ArtForz> yet reorg will happily put it in mem pool ...
224 2011-03-24 08:38:54 <TD_> yes, but when a new block is created the inputs will be checked again
225 2011-03-24 08:39:30 <ArtForz> yes, but why even put it in mem pool then?
226 2011-03-24 08:39:42 <genjix> lfm: right the whole correlation/causation thing
227 2011-03-24 08:39:46 <jgarzik> a block full of sendmany transactions: http://blockexplorer.com/b/114812
228 2011-03-24 08:39:56 <genjix> like someone found a connection between difficulty and price
229 2011-03-24 08:40:42 <TD_> ArtForz: i thought that's why you can't spend coinbases that did not mature yet
230 2011-03-24 08:40:49 <TD_> exactly because after a re-org they would become invalid
231 2011-03-24 08:40:52 <ArtForz> yes
232 2011-03-24 08:41:00 <ArtForz> I said on a > 120 block reorg
233 2011-03-24 08:41:09 <TD_> oh, sorry
234 2011-03-24 08:41:32 <lfm> wow! 0.19 fees, that might be a record
235 2011-03-24 08:41:39 <ArtForz> and in that case we put possibly invalid tx in mem pool and rely on miner ConnectInputs to sort em out
236 2011-03-24 08:41:52 <TD_> i guess the 120 block figure was picked on the assumption that it will "never" happen
237 2011-03-24 08:42:08 <ArtForz> I'm trying to reduce the checks miner CreateNewBlock has to do
238 2011-03-24 08:42:36 <TD> is this because your own miner is struggling or to help the guy who was using his desktop to mine?
239 2011-03-24 08:42:38 <ArtForz> and thats the only place except for client mode where a tx can make it into mem pool without input/sig/... checking
240 2011-03-24 08:42:43 <TD> i'm kind of surprised it's coming up as a bottleneck already
241 2011-03-24 08:42:52 <ArtForz> TD: slush also has problems
242 2011-03-24 08:43:38 <ArtForz> tcatm did benches yesterday, with 1500 tx in mem pool, current CreateNewBlock takes 1.7 seconds on his box
243 2011-03-24 08:44:06 <ArtForz> caching nValueIn for tx inputs and losing the prev tx read in first loop, 0.6 sec
244 2011-03-24 08:44:10 <TD> so the penny flooding is exhausting IOP capacity?
245 2011-03-24 08:44:16 <ArtForz> pretty much
246 2011-03-24 08:44:37 <TD> the entire block chain and index could be held in RAM today though
247 2011-03-24 08:44:40 <ArtForz> current code reads vin.prevtx for every mempool tx. twice.
248 2011-03-24 08:44:49 <ArtForz> from disk, that is
249 2011-03-24 08:45:01 <TD> given that this code is complicated, fragile and has no unit tests at all, i'd be tempted to try buying my way out of that one
250 2011-03-24 08:45:15 <ArtForz> and it does fun things like doing the ECDSA sig verify for every tx
251 2011-03-24 08:45:36 <ArtForz> which is completely unneccesary
252 2011-03-24 08:45:57 <ArtForz> a tx in mem pool came in either via a normal way, then it was run though connectinputs, which already checked the sig
253 2011-03-24 08:46:16 <ArtForz> or it came from a now-shorter-branch on chain reorg, that means the tx already was in a block we accepted
254 2011-03-24 08:46:22 <ArtForz> == sig has to be valid
255 2011-03-24 08:47:02 <ArtForz> so we check the ECDSA sig for every input of every tx in mem pool once a minute. for no reason at all.
256 2011-03-24 08:47:04 <TD> that sounds reasonable
257 2011-03-24 08:47:18 <lfm> if chain reorg then we might reject stuff we had accepted?
258 2011-03-24 08:47:55 <ArtForz> well, if we now reject it because it referes to a now-missing tx, then we wont ever get to the "check if sig is ok" part
259 2011-03-24 08:48:11 <ArtForz> lfm: in theory, yes
260 2011-03-24 08:48:21 <lfm> ok i spoze
261 2011-03-24 08:48:32 <genjix> is fan out always 2+?
262 2011-03-24 08:48:43 <ArtForz> same thing if it's invalid because after reorg it's a double.-spend
263 2011-03-24 08:48:43 <genjix> like if i send all of my 1 BTC
264 2011-03-24 08:48:45 <TD> lfm: a re-org changes the history of the bitcoin economy, in effect. so anything can happen. in practice 99% of the time, nothing happens
265 2011-03-24 08:49:30 <ArtForz> so I guess if(! fMiner) the ecdsa check in connectinputs
266 2011-03-24 08:49:36 <lfm> td ya almost always just a redundant hash discovery
267 2011-03-24 08:49:39 <ArtForz> it's a hack though
268 2011-03-24 08:50:22 <ArtForz> the proper way would be to make sure no invalid tx or tx with missing inputs can enter mem pool at all
269 2011-03-24 08:51:07 <ArtForz> then we could lose a vast majority of connectinputs checks in CreateNewBlock
270 2011-03-24 08:51:15 <TD> if the bottleneck is the ecdsa, a sig cache in key.h might be the least invasive and easiest to verify change
271 2011-03-24 08:51:26 <lfm> or flush the mem pool if you change forks
272 2011-03-24 08:51:33 <TD> if it's the disk seek capacity then yeah, that way sounds better
273 2011-03-24 08:51:53 <ArtForz> in my tests it was mostly I/O bound
274 2011-03-24 08:52:12 <TD> it'd be easy to break in future though as the mem pool is just a hash map. like if somebody adds an rpc to insert some arbitrary tx into the mem pool at some point and does not realize they invalidated some imporatnt assumptions
275 2011-03-24 08:52:33 <ArtForz> imo one clean way would be to walk mem pool after reorg and drop anything thats now invalid, and move anything thats now orphaned to mapOrphanCache
276 2011-03-24 08:53:00 <ArtForz> well, then they'll be mining possibly invalid blocks. aka "don't do that"
277 2011-03-24 08:54:12 <lfm> since forks are relativly rare its ok to do extra work for them
278 2011-03-24 08:55:03 <ArtForz> I'm still trying to figure out a few parts, because I'd *really* like to not have to read prevtx for every input of every tx in CreateNewBlock
279 2011-03-24 08:55:33 <ArtForz> tcatm tested createnewblock without connectinputs and the same 1500 tx mempool, 0.18 s
280 2011-03-24 08:56:29 <ArtForz> so if we can move those checks to where tx enter mem pool, thats an oprde rof magnitude speedup for CreateNewBlock ...
281 2011-03-24 08:58:01 <ArtForz> we only have to check things when we put the tx in mem pool and when a block arrives
282 2011-03-24 08:58:02 <lfm> wgen you first look up the txinputs save some stuff like the height of the input and the value so you can easily tell if it should be re-evaluated?
283 2011-03-24 08:58:50 <ArtForz> well, thats the thing, the tx the input refers to can't change
284 2011-03-24 08:59:03 <ArtForz> it *can* vanish
285 2011-03-24 08:59:13 <ArtForz> mainly when it was a doublespend
286 2011-03-24 08:59:55 <ArtForz> which falls under "check mem pool tx when a block arrives"
287 2011-03-24 08:59:57 <lfm> but if you know the height of the input you can tell if its part of the reorg easier I was thinking
288 2011-03-24 09:00:35 <ArtForz> I'm currently just checking if we can do it like that
289 2011-03-24 09:01:09 <ArtForz> basically tighten to "mem pool can't ever contain tx that refer to nonexisting prevtx and/or have invalid sig/... that would fail connectinputs"
290 2011-03-24 09:02:31 <sipa> make sure there is only one function that does adding to the mem pool, add a comment to it "you must use this function to modify mem pool", and add a comment to the mem pool variable that mentions this invariant
291 2011-03-24 09:02:33 <lfm> a regorg would still change the result of that test, if the txin is generated in a reorged block
292 2011-03-24 09:02:40 <sipa> shouldn't be a problem, i guess
293 2011-03-24 09:02:48 <ArtForz> yes
294 2011-03-24 09:03:30 <ArtForz> processblock/reorg has to make sure the contract is kept
295 2011-03-24 09:04:30 <ArtForz> really doesn't look that hard at first glance, the problem is this stuff is so convoluted and spread around, making sure that all paths are covered is a nightmare
296 2011-03-24 09:04:42 <sipa> ArtForz: is this because it limits the rate at which getwork() is called?
297 2011-03-24 09:04:42 <slush> jgarzik: the block with sendmany was pool payout from previous day
298 2011-03-24 09:04:49 <slush> and the record in fees was around 0.99 btc
299 2011-03-24 09:04:55 <slush> that was because I paid fees for every single transaction before sendmany was implemented
300 2011-03-24 09:05:13 <ArtForz> sipa: well, that, and it causes huge lag spikes
301 2011-03-24 09:05:28 <lfm> Max fee: 4.32000000 2010-08-09 20:08:34
302 2011-03-24 09:05:42 <lfm> so not a record
303 2011-03-24 09:05:44 <slush> ok, it was probably testing :)
304 2011-03-24 09:05:46 <ArtForz> with 1500k tx I saw peaks of 10k IOPS whenever createnewblock did it's thing ...
305 2011-03-24 09:06:14 <slush> or why should anybody pay fees in 2010?
306 2011-03-24 09:06:38 <lfm> slush ya some test or odd situation
307 2011-03-24 09:07:44 <ArtForz> it just sounds wrong to do all that work once a minute for no reason other than "because we possibly put invalid tx in mem pool in some corner cases"
308 2011-03-24 09:08:55 <lfm> for sure
309 2011-03-24 09:10:58 <lfm> can we put some arbitrary limit on the mem pool size and just start discarding (free) txn? let them be re-isued later
310 2011-03-24 09:11:09 <ArtForz> yes
311 2011-03-24 09:11:17 <ArtForz> thats kinda what -limitfreerelay does
312 2011-03-24 09:11:26 <lfm> kk
313 2011-03-24 09:11:33 <ArtForz> it just drops em on the floor if they come in too fast
314 2011-03-24 09:12:04 <lfm> kinda like the dgram/ip protocol
315 2011-03-24 09:12:17 <ArtForz> my local patch here calcs dPriority for all tx in mempool and drops the loewst-scoring ones whenever it gets "too big"
316 2011-03-24 09:13:30 <lfm> k . but i see that youd still like to reduce the cpu load for the mem pool
317 2011-03-24 09:13:37 <ArtForz> so i'd have to add checks to make sure the "no tx referring to input that isnt in mem pool or a main chain block" invariant holds
318 2011-03-24 09:14:26 <ArtForz> well, considering CreateNewBlock already does the dPriority dance once a minute, doing it to lose the lowest-scoring 1k or so TX whenever mem pool gets > 5k or so shouldnt be much of a problem imo
319 2011-03-24 09:14:45 <lfm> furtheur youd need to check them in a dependancy order it seems
320 2011-03-24 09:14:46 <ArtForz> 5k transactions, not 5kB, obviously
321 2011-03-24 09:14:50 <ArtForz> yes
322 2011-03-24 09:15:13 <ArtForz> we also have to do that in createnewblock ...
323 2011-03-24 09:15:23 <lfm> y aok
324 2011-03-24 09:18:41 <ArtForz> yeah
325 2011-03-24 09:18:51 <ArtForz> only way a tx in mem pool can become invalid is when a new block arrives
326 2011-03-24 09:19:45 <lfm> ok ya a double spend or a reorg
327 2011-03-24 09:20:37 <ArtForz> either a normal chain-extender (mem tx is a doublespend), or on re-org (mem tx is a doublespend or has a input that now refers to a nonexistant coinbase)
328 2011-03-24 09:20:53 <ArtForz> and ofc tx that use those as inputs
329 2011-03-24 09:21:04 <sipa> the current code can't deal with that at all, right?
330 2011-03-24 09:21:12 <ArtForz> well, the current code just doesnt care
331 2011-03-24 09:21:25 <ArtForz> it leaves the tx there and lets CreateNewBlock sort it out
332 2011-03-24 09:21:37 <lfm> refers to or depnds on a no longer existant coinbase, agree
333 2011-03-24 09:22:03 <sipa> i've had corrupted wallets (with tx's that were double spends), and iirc new transactions still used those as inputs
334 2011-03-24 09:22:46 <lfm> sipa did rescn fix that?
335 2011-03-24 09:22:52 <lfm> -rescan
336 2011-03-24 09:23:12 <sipa> maybe i didn't try that, but it shouldn't be necessary
337 2011-03-24 09:23:21 <ArtForz> erm, yes, it should
338 2011-03-24 09:23:28 <ArtForz> well... actually...
339 2011-03-24 09:23:59 <lfm> shouldn't be necessary if there were never any bugs in the software, true
340 2011-03-24 09:24:05 <sipa> if i have a tx in my wallet, and a new block is received which makes my wallettx invalid, that wallettx should be discarder or marked invalid or somethng
341 2011-03-24 09:24:17 <ArtForz> adding something to auto-detect that wallet and blkindex disagree should be pretty easy
342 2011-03-24 09:24:25 <ArtForz> it can happen pretty easily
343 2011-03-24 09:24:36 <ArtForz> by copying wallets around
344 2011-03-24 09:24:52 <sipa> yes, and certainly when exporting/importing private keys
345 2011-03-24 09:25:13 <ArtForz> copy wallet, spend coins, spend gets in chain and blk/blkindex, copy back old wallet
346 2011-03-24 09:25:33 <sipa> yup
347 2011-03-24 09:25:41 <lfm> sipa should almost do -rescan every time you import a key perhaps?
348 2011-03-24 09:25:54 <sipa> lfm: of course, i do that
349 2011-03-24 09:25:58 <sipa> but that's not enough
350 2011-03-24 09:26:13 <sipa> client A has a wallet
351 2011-03-24 09:26:16 <sipa> but is offline
352 2011-03-24 09:26:29 <sipa> wallet is copied to B, who does a transaction with it
353 2011-03-24 09:26:40 <sipa> wallet A becomes online before a new block is generated
354 2011-03-24 09:27:02 <sipa> tries to spend as well -> tx will never be accepted, and A wonders why
355 2011-03-24 09:27:03 <lfm> oh ok so you're trying to share a blk chain database with several wallets?
356 2011-03-24 09:27:20 <sipa> no i'm trying to share a private key between different clients
357 2011-03-24 09:27:27 <sipa> they may have separate block chain db's
358 2011-03-24 09:27:29 <lfm> so some wallets dont see some block chain updates
359 2011-03-24 09:27:52 <ArtForz> well, handling the current case of "copied wallet" seems rather simple to fix
360 2011-03-24 09:28:05 <ArtForz> keep best block hash in wallet
361 2011-03-24 09:28:21 <Blitzboom> ;;bc,stats
362 2011-03-24 09:28:23 <gribble> Current Blocks: 114819 | Current Difficulty: 76193.9710474 | Next Difficulty At Block: 114911 | Next Difficulty In: 92 blocks | Next Difficulty In About: 16 hours, 13 minutes, and 40 seconds | Next Difficulty Estimate: 68847.31032492
363 2011-03-24 09:28:25 <ArtForz> if on startup wallet best block and txindex best block disagree, rescan
364 2011-03-24 09:28:48 <sipa> even that is not enough
365 2011-03-24 09:28:52 <ArtForz> why?
366 2011-03-24 09:28:58 <sipa> see scenario above
367 2011-03-24 09:29:13 <ArtForz> aka "don't do that"
368 2011-03-24 09:29:13 <sipa> A's wallet is never overwritten
369 2011-03-24 09:29:46 <lfm> so wallet making a double spend never figures out the sin
370 2011-03-24 09:29:49 <ArtForz> why is A sending the private key of a tx to B without marking that tx spent?
371 2011-03-24 09:30:05 <sipa> ?
372 2011-03-24 09:30:34 <sipa> it could just be someone copying a wallet.dat file around
373 2011-03-24 09:30:47 <lfm> ya, dont do that
374 2011-03-24 09:31:05 <sipa> my point is: even if it's a dont-do-that, i think it's quite possible to make the software robust in that case
375 2011-03-24 09:31:25 <ArtForz> well, thats not a normal case, and afaict impossible with current client
376 2011-03-24 09:31:34 <lfm> sipa possible to -rescan every half hour, but not practical
377 2011-03-24 09:31:44 <ArtForz> while "copied older wallet.dat + newer blkindex" is pretty easy to trigger
378 2011-03-24 09:32:24 <sipa> the only missing part, i believe, is that if the block chain conflicts with a wallettx, that wallettx must be marked inactive
379 2011-03-24 09:32:52 <ArtForz> well, or "uncreated"
380 2011-03-24 09:33:09 <sipa> yes, but people using the gui won't like their tx to disappear
381 2011-03-24 09:33:10 <lfm> sipa I think -rescan would find out the txn is spent and not re-issue the double spend
382 2011-03-24 09:33:29 <sipa> lfm: i doubt that, rescan doesn't do anything that isn't done when just receiving the block
383 2011-03-24 09:33:58 <lfm> sipa easy enuf to test
384 2011-03-24 09:34:21 <sipa> well i've had that problem
385 2011-03-24 09:34:28 <ArtForz> do we currently handle that at all?
386 2011-03-24 09:34:34 <sipa> i don't think so
387 2011-03-24 09:35:08 <ArtForz> aka "A creates tx while offline, B creates double-spend of same TX and gets it into chain, A comes online and now has what everyone considers the double-spend in his wallet"
388 2011-03-24 09:35:25 <sipa> yup, that case
389 2011-03-24 09:35:50 <lfm> ya 1 does A figure out his sin and 2 what should he do then
390 2011-03-24 09:36:13 <sipa> it's easy... A could notice it as soon as a block is received
391 2011-03-24 09:36:18 <ArtForz> 1. yes. 2. currently he does nothing, wallet still contains the invalid tx, accepttotmemorypool will drop it though
392 2011-03-24 09:37:05 <ArtForz> so he has a invalid tx in wallet that cant ever go anywhere
393 2011-03-24 09:38:03 <lfm> sender of A or receiver of A?
394 2011-03-24 09:38:07 <ArtForz> as the "colliding" tx is already in chain, his tx can't *ever* get into a block
395 2011-03-24 09:38:18 <sipa> indeed, and A will keep retrying
396 2011-03-24 09:38:24 <ArtForz> actually he won't
397 2011-03-24 09:38:35 <ArtForz> as his own AcceptToMemoryPool will drop that tx on the ground
398 2011-03-24 09:38:48 <sipa> hmm ok
399 2011-03-24 09:39:08 <JFK911> ;;bc,stats
400 2011-03-24 09:39:10 <gribble> Current Blocks: 114821 | Current Difficulty: 76193.9710474 | Next Difficulty At Block: 114911 | Next Difficulty In: 90 blocks | Next Difficulty In About: 15 hours, 54 minutes, and 0 seconds | Next Difficulty Estimate: 68857.24436463
401 2011-03-24 09:39:24 <lfm> so the A inputs never get marked spent in A's wallet?
402 2011-03-24 09:39:39 <ArtForz> lfm: kinda
403 2011-03-24 09:39:41 <sipa> BlueMatt: by the way, i tested it, and the remaining part of a partially-spent tx is visible in the transaction list in an old client, but not in the balance... the problem is resolved when going back to the new client
404 2011-03-24 09:40:07 <ArtForz> they do get marked as spent I think, when he sees the block
405 2011-03-24 09:40:08 <BlueMatt> sipa: so it works as expected?
406 2011-03-24 09:40:14 <ArtForz> but the now-invalid tx still sits around
407 2011-03-24 09:40:57 <ArtForz> problem is if his and the colliding only shared some inputs
408 2011-03-24 09:41:05 <ArtForz> = he has now spent coins that arent really spent
409 2011-03-24 09:41:20 <sipa> BlueMatt: i've done some transactions creating a partial-spent tx, went back to old client, did some tx's there (obviously, disregarding the partial tx), went back to patched version, and spent everything (including the output of a tx in "old mode", and the partial tx)
410 2011-03-24 09:41:25 <sipa> BlueMatt: so, yes
411 2011-03-24 09:41:45 <lfm> and possibly truly unspent coins that are tied up in an impossible txn
412 2011-03-24 09:41:48 <ArtForz> yep
413 2011-03-24 09:41:51 <ArtForz> thats what I mean
414 2011-03-24 09:42:03 <m0mchil> hi all
415 2011-03-24 09:42:10 <lfm> yuk
416 2011-03-24 09:42:23 <sipa> BlueMatt: however, i think a disclaimer somewhere is necessary... we're just discussing a case of a corrupt wallet that's quite possible to have when importing and exporting keys
417 2011-03-24 09:42:45 <lfm> or even just copying wallets
418 2011-03-24 09:42:50 <ArtForz> A has outputs 1,2,3, B gets A's wallet, spends 2+3, while offline, A sends 1,2,3 to C, comes online, Bs tx is in block, ... A still has all 3 marked as spent and a impossible tx in his wallet
419 2011-03-24 09:42:52 <sipa> actually, just copying wallet.dat files is enough to cause it
420 2011-03-24 09:42:55 <sipa> yeah, what lfm said
421 2011-03-24 09:43:33 <sipa> but copying wallet.dat files is a known don't-do-that case, while if there is an rpc for exporting and importing wallets, some people will consider it a safe feature
422 2011-03-24 09:44:07 <ArtForz> imo the proper way to handle a tx in a block colliding with a wallet tx is to "uncreate" that wallet tx and accept the tx in block as gospel
423 2011-03-24 09:44:28 <ArtForz> sucks for A, but imo thats the only way to handle it that makes sense
424 2011-03-24 09:44:33 <sipa> agree
425 2011-03-24 09:44:51 <lfm> well backupwallet makes a new copy and people assume the backups are also then usable. kinda a mess
426 2011-03-24 09:48:11 <lfm> part of the problem is I guess expecting the gui txn record to act like an accounting ledger
427 2011-03-24 09:48:32 <lfm> txns arnt spozed to dissapear
428 2011-03-24 09:49:26 <sipa> add a boolean to a tx "overruled"
429 2011-03-24 09:49:44 <sipa> that for all intents and purposes marks it as non-existing
430 2011-03-24 09:49:45 <lfm> create a dummy txn voiding txn
431 2011-03-24 09:49:48 <sipa> except for the gui
432 2011-03-24 09:50:51 <m0mchil> ArtForz, any idea why CreateNewBlock initially is (relatively) fast, even with 1000+ TX? Then gradually worsening?
433 2011-03-24 09:51:02 <lfm> or like grey it out when its voided
434 2011-03-24 09:51:09 <sipa> lfm: yes, something like that
435 2011-03-24 09:51:13 <ArtForz> m0mchil: not 100% sure, I don't see that here
436 2011-03-24 09:51:42 <ArtForz> seems to be pretty consistently slow here
437 2011-03-24 09:52:46 <m0mchil> during last night I saw it gradually declining, from below 1000 ms to eventually above 3000, about same number of TX
438 2011-03-24 09:53:16 <ArtForz> hmmm
439 2011-03-24 09:53:34 <ArtForz> I guess it could be effects from I/O caches
440 2011-03-24 09:53:51 <ArtForz> or we're leaking memory somewhere
441 2011-03-24 09:53:58 <RBecker> ;;bc,blocks
442 2011-03-24 09:53:59 <gribble> 114823
443 2011-03-24 09:54:01 <lfm> memory fragmentation?
444 2011-03-24 09:54:13 <ArtForz> mem frag causing a 3x slowdown?
445 2011-03-24 09:54:18 <ArtForz> well, I guess it's possible
446 2011-03-24 09:54:27 <m0mchil> there was some increase in memory too, but maxed out at some point
447 2011-03-24 09:55:23 <ArtForz> btw, easiest way to make createnewblock REALLY slow: have a fragmented blk0001.dat and < 50MB mem free for caching
448 2011-03-24 09:55:40 <xelister> MEM fragmentation?!
449 2011-03-24 09:55:57 <ArtForz> xelister: yes, I kinda doubt it though
450 2011-03-24 09:56:56 <m0mchil> also, I see the second loop -> while (!mapPriority.empty()) <- much slower
451 2011-03-24 09:57:14 <sipa> hey, 1994 called, they want their 16+16 bit segmented address space back
452 2011-03-24 09:57:16 <xelister> well first question about mem fragmentation should be, why you run servers in DOS and windows 3.11/98
453 2011-03-24 09:57:18 <ArtForz> slower than what?
454 2011-03-24 09:57:27 <tcatm> m0mchil: Probably because of ConnectInputs()
455 2011-03-24 09:57:32 <ArtForz> yea
456 2011-03-24 09:57:49 <m0mchil> than the first one, iterating mapPriority
457 2011-03-24 09:58:02 <ArtForz> connectinputs read prev tx for every input from disk and does ECDSA sig verification
458 2011-03-24 09:58:17 <ArtForz> first loop "only" read prev tx for every input from disk
459 2011-03-24 09:58:18 <m0mchil> that explains a lot
460 2011-03-24 09:58:47 <lfm> xelister: do you still use malloc and free? Even hidden in your objects? then your memory can be fragmented
461 2011-03-24 09:58:55 <ArtForz> actually we can lose the ECDSA when we have fMiner set completely
462 2011-03-24 09:59:06 <xelister> lfm: in what? when coding C++, new/delete as usuall.
463 2011-03-24 09:59:09 <m0mchil> what is fMiner?
464 2011-03-24 09:59:27 <tcatm> couldn't we replace that ConnectInputs() with GetDepthInMainChain() to check whether the tx is valid?
465 2011-03-24 09:59:34 <ArtForz> no
466 2011-03-24 10:00:15 <ArtForz> input can refer to a easriler tx in the block we're currently creating
467 2011-03-24 10:00:45 <ArtForz> and thanks to chain reorg, tx referring to nonexistent input tx can get into mem pool (!)
468 2011-03-24 10:03:28 <tcatm> Can we re-check every TX in mempool after reorg?
469 2011-03-24 10:03:44 <ArtForz> thats what I'm planning to do
470 2011-03-24 10:03:48 <lfm> yes, you should id think
471 2011-03-24 10:07:22 <ArtForz> and then theres stupid fClientMode
472 2011-03-24 10:08:17 <tcatm> can a node with fClientMode set mine blocks?
473 2011-03-24 10:08:35 <TD> no
474 2011-03-24 10:08:37 <ArtForz> no clue, never really looked at those code paths
475 2011-03-24 10:08:45 <TD> the definition of client mode is that it cannot mine because it does not verify transactions at all
476 2011-03-24 10:09:32 <tcatm> So it doesn't need the tx mempool at all.
477 2011-03-24 10:09:47 <TD> correct
478 2011-03-24 10:09:48 <xelister> Satoshi should had write more comments in some places imo.. ;)
479 2011-03-24 10:10:02 <TD> bitcoin wasn't really written with other people improving it in mind ....
480 2011-03-24 10:11:48 <jeremias> is Satoshi still actively involved with the bitcoin community
481 2011-03-24 10:12:04 <{t_t}> no
482 2011-03-24 10:12:21 <Aciid> {t_t}: the funk???
483 2011-03-24 10:14:07 <tcatm> It might be a good idea to use an alternative client based on bitcoinj or one of the python-libs for a ClientMode node.
484 2011-03-24 10:14:10 <{t_t}> the... funk?
485 2011-03-24 10:14:12 <{t_t}> @ Aciid
486 2011-03-24 10:14:42 <jeremias> http://www.google.com/trends?q=bitcoin
487 2011-03-24 10:14:51 <jeremias> hmm ,interesting to see how that chart will evolve
488 2011-03-24 10:15:06 <Blitzboom> http://www.google.com/trends?q=bitcoin&ctab=0&geo=all&date=mtd&sort=0
489 2011-03-24 10:15:14 <Blitzboom> more recent
490 2011-03-24 10:16:00 <Aciid> {t_t}: your nickname
491 2011-03-24 10:16:06 <{t_t}> :)
492 2011-03-24 10:16:15 <Aciid> why change
493 2011-03-24 10:16:23 <{t_t}> for fun
494 2011-03-24 10:16:35 <{t_t}> i like to be anon sometimes
495 2011-03-24 10:16:39 <Aciid> ok
496 2011-03-24 10:17:00 <{t_t}> less about who i am, more about what i say :p
497 2011-03-24 10:21:03 <ArtForz> argh, I'm not really comfortable messing with this stuff, WAY too easy to horribly break things
498 2011-03-24 10:21:27 <ArtForz> especially the "who updates what when" on reorg
499 2011-03-24 10:24:29 <TD> tcatm: i'm not sure
500 2011-03-24 10:24:44 <TD> ArtForz: yeah that's what i concluded too. i'd suggest taking the brute force approach for now
501 2011-03-24 10:24:56 <TD> ArtForz: either multi-thread CreateNewBlock, or just host the entire block chain/index in RAM
502 2011-03-24 10:25:53 <ArtForz> well, losing the read in the first loop is trivial
503 2011-03-24 10:25:58 <ArtForz> well, mostly...
504 2011-03-24 10:25:59 <TD> sure
505 2011-03-24 10:26:02 <TD> also satoshi *is* still around
506 2011-03-24 10:26:08 <TD> he responds to emails from gavin and me at least
507 2011-03-24 10:26:16 <TD> if you send him a patch he may well review it for you
508 2011-03-24 10:26:22 <{t_t}> oh cool
509 2011-03-24 10:26:23 <TD> so that can increase confidence
510 2011-03-24 10:26:44 <TD> tcatm: i'm trying to ensure bitcoinj will be an easier codebase to understand, but obviously it won't help slush or ArtForz
511 2011-03-24 10:26:49 <ArtForz> might score a tx too low after reorg, need to add special-case code for that
512 2011-03-24 10:27:57 <BlueMatt> what was this earlier about corrupted wallets
513 2011-03-24 10:29:17 <{t_t}> TD: thanks. please concentrate on making it client only :)
514 2011-03-24 10:29:28 <{t_t}> we have tons of miners, but need more clients
515 2011-03-24 10:29:41 <eps1> if you copy a wallet and then make transaction, the copy of the wallet is no longer valid
516 2011-03-24 10:29:48 <TD> well, the strength of the network depends on its size, to some extent.
517 2011-03-24 10:29:50 <{t_t}> eps1: not neccessarily.
518 2011-03-24 10:29:51 <eps1> at least that is my understanding
519 2011-03-24 10:30:19 <TD> for casual end users, client-mode impls work better. for merchants, enthusiasts and miners there's no replacement for satoshis code
520 2011-03-24 10:30:52 <{t_t}> eps1: it depends on wheher you have new keys or not... otherwise just run -rescan. however i recommend backup after every transaction.
521 2011-03-24 10:31:02 <eps1> the client really needs to be able to ensure that a valid backup is made whenever the possibility of the old one being invalid arises
522 2011-03-24 10:31:03 <{t_t}> sometimes new keys are generated.
523 2011-03-24 10:31:27 <{t_t}> eps1: http://bitcoin.cz.cc/
524 2011-03-24 10:32:46 <eps1> heh, telling me to put my bitcoins where my mouth is? :)
525 2011-03-24 10:33:49 <{t_t}> yer
526 2011-03-24 10:34:11 <doublec> how is it decided when the bounty is claimed in bitcoin.cz.cc?
527 2011-03-24 10:34:18 <doublec> does the original submitter decide?
528 2011-03-24 10:34:23 <doublec> and who gets the money?
529 2011-03-24 10:34:57 <eps1> i might have a look, it can't be that difficult to create a config file option that tells you where to backup to and have the client copy the wallet periodically
530 2011-03-24 10:35:06 <doublec> the 'how it works' isn't very clear
531 2011-03-24 10:38:02 <{t_t}> doublec: ill add something to help
532 2011-03-24 10:38:55 <doublec> thanks, I like the idea
533 2011-03-24 10:41:58 <ArtForz> ugh
534 2011-03-24 10:42:31 <ArtForz> another "WHY?!?" moment
535 2011-03-24 10:42:51 <ArtForz> for every input of every tx, CreateNewBlock does int nConf = txindex.GetDepthInMainChain();
536 2011-03-24 10:43:21 <sipa> ... which is linear?
537 2011-03-24 10:43:25 <ArtForz> yes
538 2011-03-24 10:43:29 <{t_t}> i dont see the problem here.
539 2011-03-24 10:43:33 <ArtForz> it also reads a complete block from disk
540 2011-03-24 10:43:43 <sipa> you could cache it
541 2011-03-24 10:43:48 <sipa> in the block
542 2011-03-24 10:44:38 <ArtForz> you don't say...
543 2011-03-24 10:45:15 <{t_t}> ah ok
544 2011-03-24 10:45:53 <ArtForz> so, once a minute for every input of every cached tx we 1. read the prev tx from disk 2. read the block containing that prev tx from disk 3. read the prev tx from disk again 4. do a lot of other stuff including a ECDSA sig verify ...
545 2011-03-24 10:46:16 <ArtForz> yes, can't see how that could cause issues with a few 1000 tx in mem pool
546 2011-03-24 10:49:26 <doublec> {t_t}: oops, http://bitcoin.cz.cc/?page=propose&id=%3Cscript%3Ealert%28%22foo%22%29%3C/script%3E%27%20or%20pid=%2728
547 2011-03-24 10:49:50 <{t_t}> ok that should not happen... i thought i fixed that
548 2011-03-24 10:51:03 <{t_t}> ok thanks doublec :)
549 2011-03-24 10:51:09 <doublec> no worries :)
550 2011-03-24 10:51:36 <{t_t}> k fix'd
551 2011-03-24 10:51:40 <{t_t}> and added FAQ too
552 2011-03-24 10:51:56 <doublec> cool, thanks
553 2011-03-24 10:52:14 <{t_t}> wait, found another one :p
554 2011-03-24 10:54:53 <ArtForz> so even if twe thread CreateNewBlock, we still block pretty much everything while it's running
555 2011-03-24 10:56:15 <slush> ArtForz: How can I be sure that blkindex is full in memory?
556 2011-03-24 10:56:42 <ArtForz> pfff... good question, you probably can't
557 2011-03-24 10:56:52 <slush> ArtForz: Because it might be next one trouble which I have - I see the slowdowns as m0mchil described, too
558 2011-03-24 10:57:46 <ArtForz> does it go back down after a new block arrives?
559 2011-03-24 10:57:53 <ArtForz> or does it stay slow?
560 2011-03-24 10:58:09 <slush> I don't remember, now the problem does not appear as I have no txes in mempool
561 2011-03-24 10:59:00 <doublec> {t_t}: yep, looks fixed
562 2011-03-24 11:01:15 <{t_t}> doublec: i think so :) http://gitorious.org/btfeature/btfeature/commit/57bece8ba37710dd0a55a3a3ae59a0ff5b86064b
563 2011-03-24 11:02:35 <grondilu> New auction for a gold coin!! http://www.biddingpond.com/item.php?id=410
564 2011-03-24 11:02:37 <{t_t}> saluton grondilu
565 2011-03-24 11:03:11 <grondilu> cxu vi estas genjix?
566 2011-03-24 11:03:21 <{t_t}> jes
567 2011-03-24 11:03:27 <grondilu> lol
568 2011-03-24 11:04:05 <CIA-96> bitcoin: genjix <fake@lol.u> * r3da063aee822 intersango/www/index.php: fixed XSS bug.
569 2011-03-24 11:04:06 <{t_t}> cxu vi rigardis mian retpagxon por donacoj por estigi de bitmono?
570 2011-03-24 11:04:07 <CIA-96> bitcoin: genjix <fake@lol.u> * r522e026eed20 intersango/util.php: enough money check should pass when you have == number of funds.
571 2011-03-24 11:04:08 <CIA-96> bitcoin: genjix <fake@lol.u> * reffeda79978a intersango/login.php: re-enabled OpenID logins.
572 2011-03-24 11:04:09 <CIA-96> bitcoin: genjix <fake@lol.u> * r77f1c12453b7 intersango/ (deposit.php help.php): added new emmail
573 2011-03-24 11:05:22 <{t_t}> grondilu: iru http://bitcoin.cz.cc kaj proponu ideojn por bitmono :p
574 2011-03-24 11:08:50 <grondilu> {t_t}: hum, mi esperas, ke tiuj iloj ne estos ene la bitmono programo.
575 2011-03-24 11:09:27 <grondilu> mi vere kredas en la "KISS" filozofo
576 2011-03-24 11:20:40 <{t_t}> grondilu: tial vi ne bezonas fresxigi vian bitmon-softvaron :)
577 2011-03-24 11:20:50 <{t_t}> cxar gxi funkcias bone
578 2011-03-24 11:21:04 <{t_t}> tamen aliaj volas pli da funkcioj
579 2011-03-24 11:21:59 <BlueMatt> sipa, ArtForz: re: wallet copying, would that not be fairly easy to check for when a client receives new blocks, someone want to implement that?
580 2011-03-24 11:22:45 <grondilu> kompreneble, sed mi ne multe zorgas pri aliaj uloj, kiuj deziras tiajn funkciojn :)
581 2011-03-24 11:23:10 <{t_t}> BlueMatt: or bitcoin should have script hooks
582 2011-03-24 11:23:32 <grondilu> such scripts exist already
583 2011-03-24 11:23:53 <{t_t}> well i wrote https://github.com/genjix/sekureco but nobody uses it.
584 2011-03-24 11:24:12 <{t_t}> yet people complain about wallet backup... ergo it needs to go in the client.
585 2011-03-24 11:24:28 <grondilu> no
586 2011-03-24 11:24:35 <grondilu> just let them complain
587 2011-03-24 11:24:49 <ArtForz> we already keep best chain hash in txdb
588 2011-03-24 11:25:13 <ArtForz> so... also keep it in wallet, if those don't match on startup, rescan
589 2011-03-24 11:25:17 <BlueMatt> {t_t}: the problem is when someone else spends on your wallet (ie if you copied your wallet)
590 2011-03-24 11:25:45 <ArtForz> that should at least fix the "copying back wallet after backup+spend" case
591 2011-03-24 11:25:53 <{t_t}> BlueMatt: well im working on crypto for that, so that should be ok.
592 2011-03-24 11:26:37 <{t_t}> just got to open this exchange this week :p
593 2011-03-24 11:26:57 <{t_t}> takes a lot of effort to do the testing + security checks needed...
594 2011-03-24 11:30:34 <jrabbit> ;;bc;blocks
595 2011-03-24 11:30:36 <gribble> Error: "bc;blocks" is not a valid command.
596 2011-03-24 11:30:39 <jrabbit> >:(
597 2011-03-24 11:38:21 <BlueMatt> ;;bc,blocks
598 2011-03-24 11:38:22 <gribble> 114831
599 2011-03-24 11:39:36 <tcatm> ArtForz: automated wallet rescan has been suggested by satoshi: https://github.com/bitcoin/bitcoin/issues#issue/99
600 2011-03-24 11:43:55 <ArtForz> whats wrong with just storing hashbestchain in wallet ?
601 2011-03-24 11:46:03 <tcatm> iirc CBlockLocator already knows how to find the block within the chain.
602 2011-03-24 11:46:18 <ArtForz> yes, but why are we looking for it?
603 2011-03-24 11:47:15 <ArtForz> CBlock::SetBestChain does TxDB.WriteHashBestChain when a new block comes along
604 2011-03-24 11:47:39 <ArtForz> = TxDB.hashbestchain is the block hash of the last block TxDB saw
605 2011-03-24 11:47:58 <ArtForz> do the exact same thing with WalletDB
606 2011-03-24 11:50:35 <ArtForz> modify the rescan handing in init.cpp so it triggers rescan if wallet and txdb bestchainindex don't match
607 2011-03-24 11:50:42 <ArtForz> err bestchainhash
608 2011-03-24 11:50:50 <ArtForz> err hashbestchain
609 2011-03-24 11:50:53 <tcatm> I think with a CBlockLocator we could find the starting point from which to rescan.
610 2011-03-24 11:51:02 <ArtForz> well, we currently rescan the whole thing
611 2011-03-24 11:51:35 <ArtForz> why are we doing performance optimization for something that only happens once after you restore a wallet backup?
612 2011-03-24 11:55:08 <eps1> ;;bc,stats
613 2011-03-24 11:55:10 <gribble> Current Blocks: 114833 | Current Difficulty: 76193.9710474 | Next Difficulty At Block: 114911 | Next Difficulty In: 78 blocks | Next Difficulty In About: 13 hours, 45 minutes, and 30 seconds | Next Difficulty Estimate: 68848.41396556
614 2011-03-24 11:56:08 <eps1> mystery miner only has ~13 hours to fuck things up
615 2011-03-24 12:01:27 <tcatm> ArtForz: Maybe we should ask Satoshi why he'd use CBlockLocator.
616 2011-03-24 12:07:14 <TD> tcatm: you mean what does the object exist for ?
617 2011-03-24 12:09:20 <tcatm> TD: no, why he suggested it here: https://github.com/bitcoin/bitcoin/issues#issue/99
618 2011-03-24 12:09:43 <{t_t}> joepie91: http://boards.4chan.org/b/res/318003955
619 2011-03-24 12:10:36 <TD> for performance
620 2011-03-24 12:10:53 <TD> btw if you write a patch that forces a chain split let me know. i am getting to a point where i will need the same thing
621 2011-03-24 12:11:32 <tcatm> Just run two clients that share the same chain but aren't connected.
622 2011-03-24 12:12:28 <tcatm> Or look for a past chainsplit in blk0001.dat and replay the chain slowly, sending the shorter chain first
623 2011-03-24 12:13:15 <{t_t}> is the protocol being changed?
624 2011-03-24 12:13:16 <TD> yeah that's true, it can be done entirely by manipulating a small testnet
625 2011-03-24 12:16:28 <tcatm> there are two blocks at 111871
626 2011-03-24 12:18:46 <tcatm> after 19500 there is a larger split (3 blocks)
627 2011-03-24 12:20:54 <kiba> hey
628 2011-03-24 12:48:32 <{t_t}> Blitzboom: is this yours? http://www.reddit.com/r/technology/comments/g9sdr/bitcoins_a_decentralized_and_anonymous_currency/
629 2011-03-24 12:48:46 <{t_t}> from yesterday i remember you asking for bumps
630 2011-03-24 12:48:54 <Blitzboom> nope, not mine
631 2011-03-24 12:49:05 <{t_t}> "297 up votes 111 down votes"
632 2011-03-24 12:49:12 <Blitzboom> haha. so controverse
633 2011-03-24 12:49:15 <{t_t}> 1/4 people don't like bitcoin? whyy
634 2011-03-24 12:50:03 <Blitzboom> (n??????)n
635 2011-03-24 12:50:22 <{t_t}> hahah! so good
636 2011-03-24 12:50:27 <{t_t}> wow
637 2011-03-24 12:50:37 <Blitzboom> what, the comments?
638 2011-03-24 12:50:42 <{t_t}> no your smiley
639 2011-03-24 12:50:48 <Blitzboom> also: #bitcoin-discussion
640 2011-03-24 12:50:48 <{t_t}> going "whyyyyy"
641 2011-03-24 12:50:54 <Blitzboom> yeah. i like that meme
642 2011-03-24 12:55:21 <da2ce7> hey t_t, haven't seen you before, are you a member of the bitcoin.org smf?
643 2011-03-24 12:55:47 <{t_t}> genjix
644 2011-03-24 12:56:00 <da2ce7> ah ok, why the differnt name?
645 2011-03-24 12:56:51 <{t_t}> cause a bit of chaos :)
646 2011-03-24 12:58:38 <NakedBitcoin> :)
647 2011-03-24 12:59:14 <lfm> so tt is short fro troll
648 2011-03-24 12:59:38 <NakedBitcoin> Oh.. didn't know.
649 2011-03-24 13:00:59 <NakedBitcoin> is the best character for BTC.
650 2011-03-24 13:01:06 <NakedBitcoin> it really suits.
651 2011-03-24 13:01:12 <sipa> why?
652 2011-03-24 13:01:25 <NakedBitcoin> means 'currency'
653 2011-03-24 13:01:34 <sipa> ah, nice
654 2011-03-24 13:01:39 <Blitzboom> haha
655 2011-03-24 13:01:52 <NakedBitcoin> lookes like a person, and has 'B' 'T' 'C' in it,
656 2011-03-24 13:01:57 <luke-jr> wtf?
657 2011-03-24 13:02:08 <sipa> with some imagination
658 2011-03-24 13:02:49 <NakedBitcoin> lol
659 2011-03-24 13:04:37 <NakedBitcoin> t_t you know chinees, what do you think?
660 2011-03-24 13:04:51 <NakedBitcoin> *Chinese
661 2011-03-24 13:05:48 <{t_t}> NakedBitcoin: i know Chinese?
662 2011-03-24 13:05:55 <{t_t}> that's news to me
663 2011-03-24 13:06:12 <{t_t}> looks like a house
664 2011-03-24 13:07:04 <Blitzboom> looks like a helicopter to me &
665 2011-03-24 13:07:20 <Blitzboom> but it depends on the font
666 2011-03-24 13:09:53 <joepie91> {t_t} what was it
667 2011-03-24 13:10:04 <joepie91> I just got woken up
668 2011-03-24 13:11:12 <sipa> ;;bc,stats
669 2011-03-24 13:11:15 <gribble> Current Blocks: 114847 | Current Difficulty: 76193.9710474 | Next Difficulty At Block: 114911 | Next Difficulty In: 64 blocks | Next Difficulty In About: 11 hours, 7 minutes, and 44 seconds | Next Difficulty Estimate: 69105.41850362
670 2011-03-24 13:16:43 <NakedBitcoin> ooh the diff is only dropping by 700...
671 2011-03-24 13:17:25 <AmpEater> ;;bc,stats
672 2011-03-24 13:17:27 <gribble> Current Blocks: 114847 | Current Difficulty: 76193.9710474 | Next Difficulty At Block: 114911 | Next Difficulty In: 64 blocks | Next Difficulty In About: 11 hours, 7 minutes, and 44 seconds | Next Difficulty Estimate: 69105.41850362
673 2011-03-24 13:20:33 <nanotube> what's up, {t_t} ?
674 2011-03-24 13:32:26 <BurtyB> woo 11hrs
675 2011-03-24 13:54:49 <fartspace> Can anyone tell me why the bitcoin faucet requires people to have a google account?
676 2011-03-24 13:55:49 <JFK911> yes but i'm offended by flatulence so i won't
677 2011-03-24 13:55:50 <fartspace> That's my first dumb question for the day, and hopefully the last.
678 2011-03-24 13:56:53 <cenuij> fartspace: to easily stop mongo's from spam requesting more btc
679 2011-03-24 13:58:07 <fartspace> next question, (which isn't easily found on the faucet FAQ), can someone recommend a bitcoin seller that will accept liberty reserve? I haven't been able to find one yet
680 2011-03-24 13:58:51 <fartspace> doesn't have to be an official exchanger... anyone here want to just do a one off for some LR is fine...
681 2011-03-24 13:59:39 <luke-jr> MtGox
682 2011-03-24 14:00:11 <fartspace> i read their site, and thought you need to pay USD by wire... thought it was like a forex site to be honest... i'll check again, thanks
683 2011-03-24 14:01:04 <sipa> it is an exchanger for LRUSD/BTC
684 2011-03-24 14:02:08 <CIA-96> bitcoin: Luke Dashjr <luke-jr+git@utopios.org> * r5a560cd01547 spesmilo/cashier.py: Bugfix, to handle confirmed last-tx properly
685 2011-03-24 14:10:10 <xelister> luke-jr has also bitcoin write access?
686 2011-03-24 14:10:31 <xelister> god protect us, he will make EVERYTHING in tonal and embbed tonal font in bitcoin.exe :}
687 2011-03-24 14:10:54 <luke-jr> xelister: that's on spesmilo
688 2011-03-24 14:11:02 <xelister> :)
689 2011-03-24 14:11:09 <luke-jr> and no, I don't want anything tonal in bitcoind
690 2011-03-24 14:11:15 <luke-jr> and have no interest in touching the wx GUI
691 2011-03-24 14:11:31 <luke-jr> but yes, spesmilo has almost full tonal support
692 2011-03-24 14:11:40 <luke-jr> the only thing missing is the Tonal calendar for date/time
693 2011-03-24 14:12:05 <luke-jr> but what's taken more time, is working around the ugly JSON-RPC crap
694 2011-03-24 14:12:19 <luke-jr> http://gitorious.org/bitcoin/spesmilo/blobs/master/cashier.py#line255
695 2011-03-24 14:14:44 <luke-jr> (it also supports Decimal ofc)
696 2011-03-24 14:15:50 <EvanR-work> everything luke-jr creates has 'now supports decimal' on the side. ironic?
697 2011-03-24 14:16:06 <luke-jr> EvanR-work: I didn't even say that
698 2011-03-24 14:24:19 <fartspace> if a block is created every 10 mins approx, does that mean that's how long it should take at most for an unconfirmed transaction to be confirmed?
699 2011-03-24 14:24:28 <sipa> yes
700 2011-03-24 14:24:38 <sipa> well, it depends on how many confirmations you want
701 2011-03-24 14:25:08 <fartspace> cheers, gotcha
702 2011-03-24 14:30:00 <fartspace> i noticed after I received a transaction that my address automatically changed... does 1 bitcoin address only ever receive 1 transaction?
703 2011-03-24 14:30:25 <sipa> no, but the client will generate a new one frequently
704 2011-03-24 14:30:30 <sipa> there is hardly any cost
705 2011-03-24 14:30:56 <fartspace> so, but can i still use the old one?
706 2011-03-24 14:31:16 <fartspace> obviously people publish their addresses on static web sites...
707 2011-03-24 14:31:29 <sipa> yes
708 2011-03-24 14:31:31 <lfm> fartspace: sometimes there is a blacklog of the free transactions that may delay ordinary transactions
709 2011-03-24 14:32:32 <fartspace> free as in, no trans fee was offered? i.e. 'ordinary' in this case means it comes with a transaction fee?
710 2011-03-24 14:33:03 <lfm> fartspace: naw ordinary are free too. txn with fee are special
711 2011-03-24 14:33:20 <fartspace> sorry for the newb q's... i've read a few faqs but feel free to point me to one if these q's are too basic
712 2011-03-24 14:34:17 <luke-jr> fartspace: not quite. "confirmed" usually means 6 confirmations
713 2011-03-24 14:34:31 <fartspace> so... it's been 19 minutes since my transaction, but it's still unconfirmed... does the 'approx 10 minutes' often vary wildly?
714 2011-03-24 14:34:42 <fartspace> oh
715 2011-03-24 14:34:59 <luke-jr> fartspace: including a fee, will give your tx priority over free ones
716 2011-03-24 14:35:14 <luke-jr> fartspace: note that while you can publish an address, you can't tell who sent money to it
717 2011-03-24 14:35:22 <luke-jr> so anything commercial requires a unique address per customer
718 2011-03-24 14:35:58 <fartspace> luke, if that's true, then why does the "Send Coins" dialog include a Message field?
719 2011-03-24 14:36:05 <lfm> fartspace: yes the 10 min can vary widley but you can see the block number changing at the bottom edge of the window if you are using the gui
720 2011-03-24 14:36:42 <fartspace> (using the normal bitcoin.org client on windows)
721 2011-03-24 14:37:05 <lfm> the message field is for ann obsolete mode where you send direct to an ip address number instead of a bitcoin address
722 2011-03-24 14:37:51 <fartspace> so 'From' is obsolete too?
723 2011-03-24 14:38:01 <lfm> pretty much ya
724 2011-03-24 14:39:03 <lfm> you can still use it but only in special cases where you know the ip address and you arnt worried that the security may be compromized
725 2011-03-24 14:40:17 <fartspace> okay very good to know, thanks.
726 2011-03-24 14:41:00 <xelister> "GeForce GTX 590 and Radeon HD 5990 Face Off" thoes slashdoters 'redactors' need to watch typos before hitting submit.
727 2011-03-24 14:41:41 <Diablo-D3> heh
728 2011-03-24 14:41:42 <Diablo-D3> dude
729 2011-03-24 14:41:44 <Diablo-D3> we all do it
730 2011-03-24 14:41:47 <fartspace> haha ironic considering 'thoes'
731 2011-03-24 14:41:52 <Diablo-D3> we've been typing 5 so long 6 is hard to do
732 2011-03-24 14:42:07 <xelister> nah its easy
733 2011-03-24 14:42:13 <xelister> 5=pure awesomness, 6=gamers shit ;)
734 2011-03-24 14:43:12 <xelister> http://i.imgur.com/8Ts4M.jpg heh
735 2011-03-24 14:44:19 <Diablo-D3> wait
736 2011-03-24 14:44:20 <Diablo-D3> what?
737 2011-03-24 14:44:25 <Diablo-D3> the STORY title has a typo?
738 2011-03-24 14:44:28 <Diablo-D3> holy fucking shit
739 2011-03-24 14:45:20 <fartspace> Can someone point me in the right direction for how to accept btc on a commercial php-driven website? I'd like to automate the "here's a unique address to send the money to" part. Thanks heaps.
740 2011-03-24 14:46:05 <luke-jr> fartspace: it does?
741 2011-03-24 14:46:17 <fartspace> what does?
742 2011-03-24 14:46:36 <luke-jr> [11:35:58] <fartspace> luke, if that's true, then why does the "Send Coins" dialog include a Message field?
743 2011-03-24 14:46:54 <fartspace> yeah, it does
744 2011-03-24 14:46:56 <luke-jr> fartspace: JSON-RPC should make a new address trivial
745 2011-03-24 14:47:08 <luke-jr> fartspace: if you want a better client: http://gitorious.org/bitcoin/spesmilo
746 2011-03-24 14:47:27 <fartspace> okay great, thanks
747 2011-03-24 14:48:15 <fartspace> i have experience in LR and AlertPay apis among others, and hoping to code something similar for accepting btc in php.
748 2011-03-24 14:48:21 <lfm> fartspace: mybiycoin.com has a "pay" button steup you might want to check out
749 2011-03-24 14:48:26 <{t_t}> hey joepie91
750 2011-03-24 14:48:39 <joepie91> hai
751 2011-03-24 14:48:40 <joepie91> but brb
752 2011-03-24 14:48:42 <joepie91> gotta fix some shit
753 2011-03-24 14:48:49 <{t_t}> joepie91: people on 4chan were asking about anonnews
754 2011-03-24 14:48:53 <joepie91> yup
755 2011-03-24 14:48:55 <joepie91> it's down :/
756 2011-03-24 14:48:58 <joepie91> getting 7gbps
757 2011-03-24 14:49:01 <fartspace> cheers, will check out mybitcoin.com
758 2011-03-24 14:49:04 <luke-jr> fartspace: https://en.bitcoin.it/wiki/API_reference_(JSON-RPC)#PHP
759 2011-03-24 14:49:05 <{t_t}> is it the domain registrar being cunts?
760 2011-03-24 14:49:07 <joepie91> nope
761 2011-03-24 14:49:08 <joepie91> 7gbps ddos
762 2011-03-24 14:49:09 <luke-jr> fartspace: don't take it literally, but a good starting-point
763 2011-03-24 14:49:11 <{t_t}> kk
764 2011-03-24 14:49:16 <luke-jr> fartspace: you probably don't need the GMP crap
765 2011-03-24 14:49:18 <joepie91> currently trying to get into contact with the guy who claims to be responsible
766 2011-03-24 14:49:40 <fartspace> awesome, thanks... starting points is all i'm after at the moment, just found BTC 3 days ago and it's all i can think about
767 2011-03-24 14:49:56 <{t_t}> fartspace: https://en.bitcoin.it/wiki/PHP_developer_intro
768 2011-03-24 14:50:17 <{t_t}> you do need GMP
769 2011-03-24 14:50:21 <EvanR-work> fartspace: welcome to the pyramid
770 2011-03-24 14:50:31 <fartspace> stupid me dismissed the .it stuff previously because i assumed it would be written in italian
771 2011-03-24 14:50:54 <xelister> fartspace: lol. but yea, the .it address imo sucks a bit
772 2011-03-24 14:50:59 <luke-jr> {t_t}: doubt it
773 2011-03-24 14:51:01 <EvanR-work> you turned me into a vagina?
774 2011-03-24 14:51:11 <xelister> mummyfies
775 2011-03-24 14:51:20 <EvanR-work> lol
776 2011-03-24 14:51:41 <luke-jr> nope, don't need GMP
777 2011-03-24 14:51:50 <luke-jr> at least not on x86_32
778 2011-03-24 14:52:21 <fartspace> okay how about i skim gmp, after i find out what gmp stands for, then maybe in a few days i'll come back and let you know if i need gmp, heh
779 2011-03-24 14:52:43 <{t_t}> fartspace: can you program?
780 2011-03-24 14:52:46 <luke-jr> fartspace: amount = round(crapfromrpc*1e8);
781 2011-03-24 14:52:56 <luke-jr> that'll work fine, if you even need to deal with amounts
782 2011-03-24 14:53:08 <luke-jr> if you just want an address, and verify payment manually, none of this matters
783 2011-03-24 14:53:10 <fartspace> php yeah, cryptography is a little out of my depth, hat goes off to anyone working on this stuff
784 2011-03-24 14:53:12 <{t_t}> no that's a retarded hack.
785 2011-03-24 14:53:24 <{t_t}> fartspace: google "php gmp" click first link
786 2011-03-24 14:53:28 <luke-jr> {t_t}: your hack is more retarded
787 2011-03-24 14:53:36 <{t_t}> unless you begun programming yesterday then it's not hard.
788 2011-03-24 14:53:57 <{t_t}> luke-jr: umm... i've written 6 sites for bitcoin? you've written 0 in php
789 2011-03-24 14:54:00 <EvanR-work> keep the useful data separate from the presentational strings
790 2011-03-24 14:54:18 <luke-jr> I can run simple tests
791 2011-03-24 14:54:26 <fartspace> okay ... maybe 97-ish? yeah confident coder, but still floored by the crypto concepts that people come up with...
792 2011-03-24 14:54:37 <luke-jr> php <<<'<?php echo round( .3499999999999999*1e8) . "\n";'
793 2011-03-24 14:54:54 <EvanR-work> good luck debugging anything with php
794 2011-03-24 14:54:56 <luke-jr> works up to 21 mil no problem too
795 2011-03-24 14:54:57 <{t_t}> nice hack
796 2011-03-24 14:54:59 <EvanR-work> it lies
797 2011-03-24 14:55:16 <EvanR-work> good luck getting arithmetic to behave in php, its incomprehensible
798 2011-03-24 14:55:44 <ArtForz> "whoops"
799 2011-03-24 14:55:46 <ArtForz> http://www.youtube.com/watch?v=sRo-1VFMcbc
800 2011-03-24 14:56:48 <{t_t}> not very exciting
801 2011-03-24 14:57:06 <xelister> php sucks cocks for such aritmetics
802 2011-03-24 14:57:37 <{t_t}> xelister: that's why you use GMP
803 2011-03-24 14:57:43 <{t_t}> gmp rules
804 2011-03-24 14:58:04 <{t_t}> xelister: http://php.net/manual/en/ref.gmp.php
805 2011-03-24 14:59:43 <fartspace> thanks for all the links everyone... going to go learn for a while...
806 2011-03-24 15:04:44 <alban__> hi all
807 2011-03-24 15:04:59 <alban__> I keep getting Problems communicating with bitcoin RPC
808 2011-03-24 15:05:21 <alban__> i forwarded port 8333 to my machine, but it didn't seem to help
809 2011-03-24 15:05:26 <alban__> any idea ?
810 2011-03-24 15:05:29 <ArtForz> oi @ mtgox
811 2011-03-24 15:06:15 <Blitzboom> rally mode
812 2011-03-24 15:06:20 <Blitzboom> see this huge buy order
813 2011-03-24 15:06:25 <ArtForz> yea
814 2011-03-24 15:06:30 <ArtForz> ~5k @ 0.88
815 2011-03-24 15:06:37 <lfm> alban__: every getwork or just every so often?
816 2011-03-24 15:06:39 <Blitzboom> hmm, its gone now
817 2011-03-24 15:06:51 <Blitzboom> maybe setting it up new
818 2011-03-24 15:06:57 <alban__> lfm: seems all the time
819 2011-03-24 15:07:18 <lfm> alban__: check user and password args
820 2011-03-24 15:07:50 <alban__> lfm: so a start I'm mining solo, do I need a login/password ?
821 2011-03-24 15:08:14 <lfm> you useing the builtin miner?
822 2011-03-24 15:08:34 <alban__> lfm: i'm a bit confused about this login/password thing, do I need to register somewhere ?
823 2011-03-24 15:08:59 <alban__> lfm: using poclbm-gui but same with poclbm without gui
824 2011-03-24 15:09:12 <lfm> if you are solo you still need user password, try the ./bitcoind help commands first
825 2011-03-24 15:10:17 <lfm> alban__: you dont "register" user pass, just edit bitcoin.config
826 2011-03-24 15:11:27 <alban__> lfm: ok so i just created a login/password with the gui for localhost, then used it and restarted mining, but same
827 2011-03-24 15:12:12 <tcatm> ArtForz: another thought concerning CreateNewBlock(): ConnectInputs() will return false for a lot of those spamtx. Now that we cache nValueIn couldn't we filter most of those tx and only call ConnectInputs() if the tx has a chance of being included into the block?
828 2011-03-24 15:12:23 <lfm> what gui?
829 2011-03-24 15:12:56 <alban__> lfm: poclbm-gui
830 2011-03-24 15:12:56 <ArtForz> tcatm: really? *why* is connectinputs returning false?
831 2011-03-24 15:13:03 <ArtForz> it... shouldn't
832 2011-03-24 15:13:13 <lfm> you still need to edit bitcoin.config
833 2011-03-24 15:13:24 <alban__> lfm: ah. where is it ?
834 2011-03-24 15:13:28 <tcatm> ArtForz: it checks the fee
835 2011-03-24 15:13:40 <ArtForz> oh, right
836 2011-03-24 15:14:21 <lfm> alban__: in some data directory, depends what os you are using
837 2011-03-24 15:14:39 <alban__> lfm: windows 7
838 2011-03-24 15:15:06 <ArtForz> tcatm: nice idea
839 2011-03-24 15:15:36 <ArtForz> btw, I've improved the input value stuff a bit so it doesn't blow up on chain reorg
840 2011-03-24 15:15:52 <ArtForz> chain reorg happily puts tx into mempool without checking them
841 2011-03-24 15:17:06 <tcatm> nice
842 2011-03-24 15:17:09 <ArtForz> so if I run across a input value -1 tx, I do the old-style "look up input tx in mem pool or blocks" and set it from createnewblock
843 2011-03-24 15:17:54 <tcatm> I'm still not sure where the implicit "only include one tx of a unconfirmed tx chain" happens.
844 2011-03-24 15:18:10 <ArtForz> I think the proper fix is to change reorg so it doesnt leave tx in mempool that didnt get a connectinputs treatment
845 2011-03-24 15:18:21 <sipa> alban__: are you running bitcoin with the -server flag?
846 2011-03-24 15:18:59 <alban__> sipa: actually I'm just running the miner thing. Do i need something else ?
847 2011-03-24 15:19:30 <ArtForz> first loop leaves all tx that depend only on 0/unconf with 0 dPriority
848 2011-03-24 15:19:31 <lfm> alban__: ya you still need the main bitcoin client to solo mine
849 2011-03-24 15:19:45 <alban__> lfm: ahh i see
850 2011-03-24 15:19:48 <sipa> alban__: you either need to run bitcoind, or bitcoin gui with the -server flag
851 2011-03-24 15:20:03 <sipa> the miner doesn't speak the bitcoin protocol, it gets pieces of work from a real bitcoin client
852 2011-03-24 15:20:07 <alban__> hehe sorry I'm pretty new to all this
853 2011-03-24 15:20:21 <ArtForz> second loop processes tx in prio order
854 2011-03-24 15:20:36 <ArtForz> so when theres more than 4kB worth of prio > 0 tx...
855 2011-03-24 15:20:50 <ArtForz> fAllowFree = (nBlockSize + nTxSize < 4000 || CTransaction::AllowFree(dPriority))
856 2011-03-24 15:21:01 <ArtForz> allowfree is false for 0 prio
857 2011-03-24 15:21:10 <tcatm> ah okay, got a recent diff for the nValueIn cache code?
858 2011-03-24 15:21:39 <ArtForz> actually... hey, wait a sec
859 2011-03-24 15:21:57 <ArtForz> we already know the only way tx can get into cache without connectinputs is reorg
860 2011-03-24 15:22:19 <ArtForz> so... do the "look up nvaluein for added unchecked" stuff... in reorg
861 2011-03-24 15:22:44 <ArtForz> as imo thats the proper place for it
862 2011-03-24 15:25:26 <tcatm> yep. actually, can't we call ConnectInputs() again during reorg?
863 2011-03-24 15:25:36 <ArtForz> I think so
864 2011-03-24 15:25:36 <jgarzik> yes
865 2011-03-24 15:25:53 <ArtForz> well, we have to watch out for dependency chains
866 2011-03-24 15:33:14 <alban__> ahh ok i finally got it
867 2011-03-24 15:33:18 <alban__> thanks everybody
868 2011-03-24 15:36:48 <tcatm> Just added some printfs: from 1122 unconfirmed tx only 14 are included in the next block. getwork took 902ms