People use bots, and "night" is relative, so I don't think the effect you're describing is strong.
|
|
|
Hi Monoquark,
I see your point, guess I simply don't understand the protocol then. I was sure that you get a "cryptographic target key" and then you try all options starting from 0 to the maximum bit field size (which is?).
Also you mention something about solo mining, I'm currently using Bitcoin client and I see it do 4208 khash/s. I don't know if it uses my GPU, I have AMD Radeon HD 6800 how can I verify I'm using the GPU?
You're not using the GPU. Don't use bitcoind's generate coins option. Instead, join a pool and run a GPU miner like poclbm.
|
|
|
I installed the mod. You can ignore boards on your profile.
Great, thanks.
|
|
|
The client only generates new private keys when you create a new receiving address. If you don't do that, the backup can be as old as you want, I believe.
That's incorrect. The client also automatically creates new addresses when you sent money (to send the "change" back to you). It also automatically generates an address when receiving payment to the currently selected address (or something like that). Thank you all for the information. For the general public, the client is indeed not the tool to use. At least not in its current form. They would have to use online accounts at web services sites who offer payment processing and will still charge a %ge on every transaction.
Currently several such services exist which are free, eg instawallet.org and mybitcoin.com.
|
|
|
I'm so happy for you! Have the best of luck for this new phase of your life. I'm glad I was able to motivate you a little. Obviously you have more important things on your mind right now. Now you can also work on bringing little Bitcoiners to the world .
|
|
|
The critical data stored in the wallet.dat is your private keys (one for each receiving address generated). These are private and not shared with the network (if they were then anyone would be able to claim ownership of your coins), so there's no way to "synchronize them with the network". If you lose the keys to your coins they're lost forever (or at least until the current level of ECDSA is broken).
If the client is offline then it's not generating new keys, so there's no risk. You don't need to put it online once a week. For that matter, if there's no client running with a wallet file, there's no need to update its backups. (So you can create a wallet, put some coins on it, copy it to a flash drive, bury it and never run a client with this wallet. When you dig it up some years later, assuming the flash media persists, running a client with this file will allow you to retrieve the coins.)
|
|
|
The wallet.dat needs to be up-to-date, with some leeway. To make a long story short, if more than 100 new addresses were created since the backup, you are at risk of losing your entire savings. A weekly update should be good.
Those who do not know how to do backups (most of the population) will be advised to use an eWallet service.
|
|
|
Can you add functionality to create and delete monitors to the website?
|
|
|
this post is a joke
I know. But even as a joke it's not original.
|
|
|
You're not the first to have come up with such a theory.
It's only a matter of time until mining moves to special-purpose chips. So ATI's total profit from the whole thing is limited.
|
|
|
Wonderful idea.
Maybe we should also make it impossible to send twice to the same extended address. (But to maintain the ability to send two separate transactions of the same amount to the same real address, maybe the extended address should also contain some random stuff).
|
|
|
Ok, balancecurrent is really expensive in terms of performance and RPC is timing out with this long a round. I am trying to figure a faster way to do this.
Assuming the problem is summing over all the shares of the worker, note that shares older than the last 10,000 or so will have negligible score, so you can just find out the ID of the last share and use "where ID > X-10000" or similar. Great, that's a big help. Yeah, it's the big table scan that's bogging it down. Edit: balance updated to only scan last 10,000 shares. Note that the final round payment calculation still scans all shares. There's still room for improvement in the final calculation. At the current r, shares older than 17,000 will have score less than double-precision granularity, so they won't have any effect anyway. Hmm, you mean no material affect? Round 4 payment calc: select max(score) from share = 646.164449020304 shares = select count(*) from share where score is null = 281610 maxid = select max(id) from share 828713 totscore = select sum(exp(score-max))+exp(score-os) from share = 436.318039783311 payment calc select exp(score-totscore) from share order by id values: 5.43924628175081e-284 5.45174116086077e-284 5.46426474284596e-284 5.47681709364117e-284 ... So they're very small, enough so that we could ignore them but they don't underflow the double precision type. I was talking about granularity (precision), not minimal representable number. If you add 1 + 1e-17 you'll get back 1, because double has only 52 bits of precision, or roughly 16 decimal digits. So scores less than this will have no effect on the final numerical score.
|
|
|
search for BitBills.
Offline... The site, yes, but there's the forum thread.
|
|
|
Miner borrows bitcoins in advance, sells them at today's profitable price, and then pays them back with newly generated BTC.
How will this help? If the price crashes and mining becomes unprofitable, he will just stop mining and buy the bitcoins he owes.
|
|
|
Bitcoin is first and foremost a currency. The fact that it also has built-in most of the features of banks and payment processors is good, but it doesn't mean that a world with Bitcoin as the global currency will not have those. They will probably still exist, store and transfer value denominated in bitcoins, and use their centralization advantage to allow scalability. The minority who insist on using raw Bitcoin will be able to do so. Also, since those services will need to compete with raw Bitcoin, their fees will probably be lower than they are now.
Also, I have some ideas for a semi-p2p trust-based payment-processing network that can be built on top of any currency, which may be a better solution than centralized services. I think it will be a good match for Bitcoin and allow it to scale.
|
|
|
I believe it would be possible to create a secure physical bitcoin currency using QR codes. Here is how I believe this could be done:
First people would print their own bitcoin denominations that have a special QR code that initially corresponds to their bitcoin address. People can print bills in any denomination they choose. A system would have to be set up that allows for the transference of the encoded qr data once a transaction has been verified. People will access the QR code through a special bitcoin mobile app that will verify a transfer. Both parties must access this app and the qr code on the bill to confirm the transaction, hence no stealing.
What are people's thoughts on this and has it already been done, and if not, why not? Lets do it!
Things like this have been discussed. It's just a matter of coding that app and letting people print as they wish. You may also wish to search for BitBills.
|
|
|
I sow some pepole running 5 cards... What psu they using ?
Probably more than one. For 2X5870 X-Series 650W should be enough. For 2X5970, 850W.
|
|
|
I think you need to use --sign rather than --decrypt.
|
|
|
Seasonic's X series is good.
|
|
|
be paid with PayPal.
Doesn't paypal have a high risk of charge backs and account freezes? They've been getting a lot of bad press lately for withholding funds, and placing the burden of fraud on the seller. Chargebacks - yes, that's why you should be trading with someone trusted. Freezes - also yes, but as long as you don't specify that the payment is for bitcoins, I don't think they really have a way to know (I mean, maybe they can if they try hard enough. I do use my real name here on the forum...) Anyway, you may also want to take a look at https://www.bitcoin2cc.com/ .
|
|
|
|