+1.  The people I try to explain Bitcoin to have the same initial objection -- "but anyone can create coins."  It's only after I explain how the block chain works with respect to "generation" and fees that they understand.

Neither would any more blocks, and the network would either have to be redesigned or revitalized somehow, or collapse.

Are you sure that the screeching is not coming from the UPS?  As in, an alarm?  My roommate in college had a UPS, and due to the bad power quality in the building, it would trip the alarm whenever he started gaming.

Ah, yes.  My mistake.


As mentioned, disk storage capacity is measured one way by OSes and another by manufacturers.  So it might not be false, but it's not really true either.  More like contested.    The rest of the list does seem to lean towards decimal powers though.  Shame.

That link doesn't really prove anything though.  Of course manufacturers use powers of 1000 -- they can claim that their hard drive is 300GB when it is, in fact, only 279GB as measured by pretty much every operating system.  Also, AFAICT, the article is just plain wrong when it comes to RAM modules; if the amount of RAM on a chip were not a power of 2, it just plain wouldn't work.  Such statements can only be made by people who don't know how memory is addressed.

So, sorry, but I'm still not convinced. 

I agree.  I for one am just using my gaming card and don't really have the budget to buy anything new just for mining.

It does, via mysql_stmt_prepare(), mysql_stmt_bind_param(), and mysql_stmt_execute().  The basic steps are: prepare the query (this is where the query itself is parsed), bind the parameters you take in the query, then execute the query.  This illustrates that the user-supplied data is sent to the server after the query structure is known, thereby preventing all forms of SQL injection.  (But not ensuring data integrity, of course.)

Thanks. 

The current revision does not, but this is going to be implemented pretty soon.  Obviously it will only work on pools that support LP themselves; it will just proxy the LP request.

I agree.  But I don't have the desire to hack on every client out there to implement something like this.  Further, this approach also gives me other benefits like the ability to manage miners remotely, retarget their pool assignment without restarting them, etc.

If someone implements a consistent multi-pool interface in all the mining clients, I would probably deprecate this project.  But in the meantime it fills the gap and also gives you some other nifty features that client-side multi-pool support alone wouldn't.

LP is only "broken" in that I have not yet implemented it.  There's no technical reason it can't be done, I've just been focused on other aspects of the proxy.

A similar BDP proxy could be implemented alongside the existing HTTP-based proxy, with minimal database schema changes.  Once that is done, you could theoretically run HTTP-only miners against a BDP pool efficiently, by having the HTTP proxy get work from the local BDP hub process.

To a degree, yes.  I run my proxy on my LAN, so network failure is extremely unlikely.  A software bug is the only thing I can think of that would cause a problem (other than the whole box going down, at which point I lose DNS too), and with (... checking DB ...) 82,000 getwork requests processed in the last 2.5 days, my confidence in the proxy code is very high at this point.

Just to be clear, I take no liability for any forks of the project. 

If you are referring to, for example, PHP's magic_quotes options then -- NO.  Those kind of options should never, ever be trusted.  They are not locale-aware (and therefore still vulnerable to injection attacks in some circumstances) and can corrupt your data if you're not careful.

Additionally, this would be the wrong place to perform such sanitation.  You should sanitize and escape values before they are used in whatever context you are using them.  For example, magic_quotes will protect against some (yes, some, not all!) SQL injection attacks.  But it will not stop XSS or the like.  SQL-escape user data before it enters the DB, not before it enters the entire script.  HTML-escape user data before you render it to a browser.  Etc.

A better option would be to use parametrized queries, which are by definition invulnerable to SQL injection attacks if the DB itself supports them, since the parameters are sent after the query has already been parsed.

Edit 2011-05-04: The software has been released! (View post)

----------

Hey all, I'm trying to gauge interest for this.

I've been hacking for about a week and a half on a mining proxy written in PHP using MySQL for the data store.  I've been running my own miners against it with no problems for the last week.  The basic idea is that you can run multiple miners against multiple pools (same or different, it doesn't matter) and miners can fail-over to other pools if something happens to its preferred pool.

Additionally, using the web interface, you can manage pool assignments from any physical location; your miners won't notice that anything has changed when you switch them between pools.  The information on the dashboard can also be used to help determine when a miner goes AWOL.

Here's the more detailed list of how it all works:

• Multiple pools can be defined.  Pools can be globally enabled/disabled for all workers.
• Multiple workers can be defined, each with their own credentials to be used against the proxy itself.
• Each worker can associate with as many pools as you have defined, and can have its own credentials to be used with that pool.  (In other words, you can have worker A and worker B both working slush's pool, but each using their own worker accounts.)
• Worker-pool associations can be individually enabled/disabled without affecting other workers, or other pools associated with the worker.
• Worker-pool associations can be ranked by priority.  The highest priority association will be used -- unless that pool is down or not responding, then the next-highest will be tried.
• All getwork requests are partially logged in the database, and all work submissions are logged as well.  This includes which worker sent the request, which pool ultimately handled the request, and (in the case of work submissions) whether the share was accepted or not.

All this is manageable from a web-based control panel.  Right now the project is not terribly polished -- not well enough for a release anyway -- but the core seems to be working great.  If there is any interest in such a project, I will probably release it under the AGPL.

I'm interested in the views and perspectives of my fellow miners as to whether this project would have any value to the wider community.

Mandatory screenshot:

I appear to be missing payments for some blocks too, and have been in contact with the admins about it.  Unfortunately I don't log very much, so I don't have a lot of useful info to give them other than "my historical balance on your site is larger than my payout to date" but I suspect that it may have been the same block(s) that we didn't get paid for.

1.2 billion SHA-256 block transformations per second, yeah.  I'm still unclear if 1Mhash is 1000 or 1024 trials.  In terms of storage, OSes measure kB/MB etc. as powers of 1024 (which is in turn 2^10) since converting can be done by simply shifting bits.  So I tend to lean that way, but I've never really checked to see which convention is used in the BTC mining world.

Pretty sure it's complete trials, not individual hashes.  A more accurate term might be nonces checked per second.

"-f 120" works for me.  Once, while mining and gaming, my video card crapped out completely and the monitors turned off.  I had to hard reboot.  This may simply be instability on my end, but it's something to be aware of -- don't push your hardware too hard.

That's exactly what I said in my first reply.  I was summarizing. 

Perhaps.  "98245 hours per MH/s" to me says that if you had 2MH/sec you would need 2*98245 hours to generate 50BTC.  (Of course, you would need 98245/2.)

A better way to express it using similar grammatical structure would have been "50 BTC per MH/s every 98,245 hours".  The "per" was in the wrong place.

No.  The fees come from the person who sent the transaction, and they are already-existing coins.

For example, if you send 1BTC to someone and include a 0.01BTC fee, 1.01BTC will be spent.  1BTC goes to the recipient, and 0.01BTC goes to whoever solves the block your transaction is in.  (So if you solve the block yourself, you get your fee back. )

"X hours per MH/s" is the wrong way to measure average block generation time.  The average time per block is inversely proportional to your hashrate.  Your post suggests the opposite, which is incorrect.

No need to excuse anyone; everyone starts a noob.

For further reading on this subject:
https://en.bitcoin.it/wiki/Target
https://en.bitcoin.it/wiki/Difficulty

If it's not clear from the articles, the difficulty is a function of the target; the target adjusts about every two weeks, and this changes the difficulty.