Thanks for the pointers, it's running fine now, and has a slight speedup (10%) over stock on my Athlon.

I think this doesn't hit true Ponzi-scheme usefulness because you don't get down-network treatment: if you want people signing everyone up like mad, you have to give them some of their future downline's earnings, perhaps 1/3^N where N is number of levels below.

p.s. I signed up, and if you like this idea, make me your sponsor so that I get in early on the pyramid side of the scheme... http://fxnet.co.cc/?ref=30

By definition the pool will work through its 'bad luck' faster, since it has more chances to.

That is, if 10% of the current computers generating bitcoin pooled, then on average right now they would generate a block every 100 minutes or so. Therefore you would get (50 BTC / pool size) every 100 minutes once the blocks had started to mature. If it's really unlucky and gets a block after 200 minutes, then obviously, everyone would wait. Regardless, BTC would start piling into your account -- at no faster rate than they would otherwise -- in small increments, and relatively soon.

You could make it more addictive by playing a little sound or animation when someone in the pool generated a block, and even more so when you generate one.

I'm assuming the comment about 1 BTC missing is a joke, but if not, the pool could designate a little bit to the pool server as compensation. I would think 1 BTC would be too much, though.

I was also thinking you could incent the winner by doubling their share: a nice psychological trick that shouldn't actually impact block generation or distribution of BTC over the long haul.

Awesome, will advise tomorrow, after some sleep. : )

My Core i5 laptop (Ubuntu) doubled in speed. Actually, it didn't double in speed. It stayed the same speed, but only uses half the CPU now. I can't get it to go back to full CPU usage. That said, my laptop is a lot cooler when generating blocks now. I'll post back if I see it successfully go up to 100% usage.

Thanks! Unfortunately, this didn't work for me. (AMD on Windows 7/64 bit)

 First, it wanted MSVCR100.dll. I installed that to WINDOWS\SYSTEM32.

Then, it crashed with an error something like 0x0000007b or so.

Recommendations?

Thanks, this is a great way to do this -- I'll look forward to hearing more about how it develops.

In answer to those who don't get "why?" -- go play farmville, or any other social networking game. Humans are wired to like slightly inconsistent, but frequent rewards.

When you could generate your first block in a day or so, the system created its own 'rewardiness' for people. This helped it become sticky.

This stickiness does not happen right now, unless you have a pretty hot computer or get lucky -- it's quite possible that someone could go weeks without generating a block. This is a real and present problem with adoption, and one that a pooling system would help solve without changing satoshi's desired 10 minutes-per-block pacing.

I was wondering today about how to get a pool of mining together: that is, users who wish to could all go in together on mining the next block. The actual block signer signs over the block to the group. Splitting could happen any number of ways.

This would really help new users who want to generate some BTC, a key problem for adoption right now. And, it would encourage slow-computer users to participate in block generation, something that is not very motivating right now for many.

Obviously, there's the 'cheater' problem: a user has no incentive to share once he/she has generated the block. I can't figure out how to solve that without a client that is patched.

Does anybody else have technical suggestions about accomplishing this? Even patched clients present some interesting problems: one thought I had is that you could include all the transactions to the group inside your block, but that would of course require you had 50+ BTC to start with, or the transactions would be invalid.

Of course, the client can just stay mum about generation until it's matured, then send it off, and you'd only know once you got your portion.

Thoughts?

Adding Bitcoin to Maemo wouldn't exactly increase Bitcoins reach.. But Android or iphone would!

My comment is that putting conditions in the EFF is rather silly:

If people want to donate, let them donate; they can send the money to a trusted party / wallet-on-a-VM, and we can send it over to the EFF if they want it. The EFF's goodwill and press is worth more than them running a node or two.

And, by the way, I think it's a good idea to turn the EFF on to Bitcoin. I would suggest that it might be a good job for someone with business development experience, a phone call and conversation might work wonders.

My core i5 doubled in speed. My Core 2 Duo is the same speed.

I have been thinking about mobile-to-mobile bitcoin transfers a bit, and wanted to share some initial thoughts for feedback.

I've been ordering possibilities in my head from "STRONG" to "WEAK" as far as usefulness and security.

Strongest would be bitcoin client on the phone. This is currently doable for an android phone, but Satoshi doesn't want client forks, and you'd have to reimplement in Java. I rate as not a good plan right now.

Next: Secure connection to your wallet, listening on the net through some sort of secure connection to the RPC interface. This is a relatively nice solution, and would be even better if the mainline client added a "listen on port YYYY, using secret ZZZZZ for authentication". Incidentally, this would allow a bunch of nice programmatic solutions to a whole range of possible things to do with Bitcoin.

Something I'm terming "WEAK": Passing over the private key to a given address to a user. Now, I know what you're thinking: double spending, yadda yadda.

On the other hand, it would be nice to sync up a bunch of 1BTC addresses to your phone, and when you wanted to send some money to someone, you could just BUMP or otherwise beam them the public keys. They would verify, IMMEDIATELY transfer the BTC in those accounts out, and you'd all be good to go once they're sure there are no double spending collisions in the network. Of course, don't trust those accounts again.

What seems appealing about this is I've got the spending down to "only one side needs direct access to a full client."

Suggestions for getting it down to "neither side needs direct access to a full client," or some sort of reasonable cloud-oriented proxy server that doesn't require way too much trust from the user?

If, you know, they trusted mybitcoins.com.

I just want to add my voice to those recommending strongly that the client have an "Accounts" Tab showing an Address and amount stored in each Account.

This would be a natural place to add backup functionality and provisos and warnings.

Well, speed is always desirable for a purchaser and deliverer of X item, please refer to Escrow discussions here among others for some reference: being sure that the transfer is 'real' takes time, and for the two parties in a transaction, they almost always want that assurance immediately.

The hosting person could just as easily take BTC as dollars, so I don't think that's the point, really.

Regarding "Screwing with the network" Yes, it would be annoying for everyone to have to wait 40 minutes per block for 8 weeks if someone had burned through 2016 blocks quite quickly previously.

Since BTC aren't economically viable to generate on US server farms right now, this is likely just an 'attack' vector, not a 'money-making' vector, at least without the added payments for speeding things up.

A simple solution to this would be to store your wallet.dat on an encrypted partition that goes to an S3-based storage system, like Dropbox. They'll keep versions for you on update.

This would make a nice opt-in service that could be sold in the native client as a way to help fund research, by the way. The data storage needs are incredibly small.

I was thinking today about the cost of speeding up the time to get, say 5 blocks generated if one was impatient for a purchase to be confirmed.

So, I rented a server at voxel.net, which claims to cost one third what amazon does, and I ran bitcoin for a bit to see what it could do there, per core.

Results: about 1000 kh/s per core. (Note, I expected double or triple based on their marketing. Some tuning could probably be done here.)

Incidentally, this implies cost per minted BTC of (at current difficulty of 354): $.1/hr for roughly 17.5 days = $42 per 50 BC = $.84 per BTC. Ouch!

But, let's imagine I want to double up the speed of the network to get my transaction going quickly. I would then need approximately 2.5 million kh/s, or about 2,500 servers. This would get me roughly one block per 10 minutes. Combined with the rest of the network, we'd be double-timing blocks, or getting one out every five minutes. Of course, I'd only need to do this for about 25 minutes to get my five blocks.

So, 2,500 servers * .42 hours = 1,041 hours * $.10 = $104.10. Less the current value of the 250 BTC at $.06  = -$15: Net cost is $90 to get the transaction sped up.

If you wanted the confirmation in 10 minutes, you'd need four blocks plus the network's blocks, so you'd need roughly 10,000 servers, but of course, they'd take less time:

10,000 server * 1/6 hour = 1,666 hours = $166 - $15 = $151.

Someone less lazy than me could put this into a closed-form equation, with a confidence interval, rate and number of blocks specified, I'm sure.

I find this really interesting: right now someone could profitably offer a 'turbo' button for roughly double these numbers, so about $200 to $300 per 5-block generation. This would also not massively impact difficulty the next block cycle as it only ran briefly.

Thoughts or comments?

This is a nice system, but it slows commerce down significantly, as sellers need cash as well as goods.

On the other hand, no escrow at all is clearly slowing bitcoin down, so I'm thumbs up on the idea in general. I'm working on a few bitcoin things, and escrow has been on my mind.. I'll keep you guys posted.

I haven't made tomato jam, but I just looked at some recipes, and will definitely be making some as tomato season winds down. Yumm.