|
Just letting everyone know I've put a cuda and opencl capable GPU on biddingpond. It's not a high end card, but it will do about 6x what my overclocked quad core can put out.
|
|
|
|
I just need a way to know if the addresses on the wallet are covered by the last backup, and if there are still leftover addresses in the wallet, without depending on running counts and persistent data not stored in bitcoin directly.
Keys in the keypool store when they're generated (and the oldest are always used first). Asking "what's the oldest key in the key pool" seems reasonable, and I think it would give you what you want-- you could compare that timestamp to the timestamp of your last backup to see if you're covered. Although if you're going to periodically check to see what the oldest timestamp is (or you're going to periodically check to see if bitcoin has written a new timestamped backup file or periodically check WHATEVER) then it seems simpler to me to just periodically always call backupwallet. Disk space and bandwidth is cheap these days... Yes, I will keep calling backupwallet regularly regardless, but how often do I do it? That's the answer this whole thing will be able to provide, as it's not a static thing. I can then check every minute but backup every day, unless I hit a peak usage and have to put an intermediate backup. And if these happen a few times in a row, I'll adjust the auto backup time frame. |
|
|
|
Backup every 30 sendtoaddress or generatenewaddress and you'll be fine-- you should always have at least 3 backup copies of all your keys.
You obviously understand that from the software perspective, the two approaches are different, right? Having a fixed trigger to backup is very easy and can be completely stateless, but backup every X whatevers means keeping a running count, harder to get redundant work with redundant data, etc. If you're running a very busy service so backing up every 30 is too often, then run with -keypool=1000 and backup at least every 300 sends/generates.
I worry about bitcoin accumulating too many features and not doing any of them very well. I suppose it wouldn't hurt to add an option so it automatically creates timestamped wallet backups... but should it erase old backups? (if it doesn't, I KNOW people will forget to erase them and will be upset when their disk fills up with wallet backups and they're left to figure out how to clean up the resulting mess). Should it encrypt them? What should it do if an automatic time-stamped wallet backup fails? When encrypted wallets are implemented, what should happen to old backups if the wallet encryption key is changed?
That's why I like simple, the kiss approach, within limits. The perfect approach for me would be manual triggering of key pool refilling, because that way the backup agent makes sure that there are enough keys from the last backup and, failing that, generates a new (variable size based on the average needed in the past) batch. This is very simple on the bitcoind side and very powerful for me. I just need a way to know if the addresses on the wallet are covered by the last backup, and if there are still leftover addresses in the wallet, without depending on running counts and persistent data not stored in bitcoin directly. |
|
|
|
RE: how many free keys are in the pool:
By default, there are at least 100 free keys in the pool, always.
When a key is taken out, if the number of free keys drops below 100 (or the -keypool= number) another is generated.
Keys are put back if they're unused-- for example, a key is needed for every miner hashing thread, so if you're on a 4-core machine and turn on coin generation and then turn it back off you'll wind up with 104 keys in the free pool.
But for most people most of the time there will be exactly 100 free keys.
So, 100 transactions from now and I'm in the same exact backup problem. It just moves the safety zone into the future "backup now and you'll be safe for X time" X being really small in a very busy service. Is it possible to have hysteresis in the pool? once it reaches 20 it generates the other 80, or something or the kind? That and getfreekeys on the rpc side and I can make sure I don't need to do backups for every transaction, I don't need to do backups based on time and I'm 100% safe. Or I can do time based pooled backup and be 99% safe. Even better, hysteresis as described and after every time the server generates new keys for the pool, it does a wallet backup with time signature. My backup job can simply detect new files as save them, a simple rsync would do the job in a guaranteed safe way. |
|
|
|
Cool, i'm in again this time  Would be nice on your site to have a little chiffred example of what is a pick 3, pick 5, etc, and how are gain redistributed. Something like the first post of this tread, but don't know if the mentionned values are still up to date (didn't read all the posts) It is all a question of time... values have changed through time, but every time they changed a post was made, and for now you'll just have to parse the whole thread  But I'm confused; bitpicks are winner takes all, as explained in the instructions page. You mean the lottery draws, right? |
|
|
|
No opinions whatsoever? Then it's settled, only for block 86000 instead. Let me put this clearly: The draw for block 86000 will be paying the full pot to whatever prizes are awarded. No first prize rollover on this one.Also note that The next draw, for block 86500, will get primed with the side pot, at 408.11, but that one will be running under the common rules of first prize rollover.This, assuming the never tested in production rollover prevention and side pot priming code is working as it should  |
|
|
|
Do they allow you to send money between accounts or only do currency exchange?
That was my thought exactly. I sent them an email: It's not possible to select a specific user to trade with, as the exchange process is anonymous and allows for partial matching etc. We don't intend at the moment to change this. We are, however, working on allowing direct CurrencyFair account to CurrencyFair account transfers (pretty much exactly as you describe), and plan on introducing this in the near future.
|
|
|
|
I think we should not allow withrawal of $ at MtGox until after Adding Funds is also possible again. Only one-sided allowance will bring this small and still vulnerable system out of balance. No-one forces you to trade while the system is "out of balance", so I don't see why you want to stop people from withdrawing their $ from MtGox. If you're not going to trade, it doesn't make any difference to you whether or not other people have their $ in MtGox. That's true, but also true is the fact that if I needed to get my cash out, quickly, my only option right now was to buy overinflated coins and sell them elsewhere... I'm guessing S3052 has some of those coins to sell |
|
|
|
I think we should not allow withrawal of $ at MtGox until after Adding Funds is also possible again. Only one-sided allowance will bring this small and still vulnerable system out of balance.
We should allow withdrawal and adding of funds in parallel.
You mean unbalanced like it is now? Or was it a coincidence that the price increase of BTC on mtgox neatly matched the moment withdrawal became impossible in any other way except for bitcoins? How's that for an unbalanced system, pretty young and so vulnerable? |
|
|
|
Kiba: It isn't an issue of time. It is that I haven't found a good alternative. Here are the only choices I have so far:
ACH (only works in the US)
LibertyReserve: (ok except expensive to transfer in and out)
Okpay: (Even more expensive than LR but possibly more funding and withdrawing options)
Ones that wont work:
AlertPay, Amazon: (still has chargebacks and mtgox isn't in their Acceptable Use Policy AUP)
liqpay: (I can't get the SMS from the 4 phones I tried)
Moneybookers: (violates their AUP)
click2pay: (No US sign-ups)
ikobo: No API
and more ...
How about you open a side PP account to allow withdrawal, but not funding? I mean, I'm not going to be buying any bitcoins anytime soon on mtgox, as obviously the no withdrawal situation is getting the price sky high, and I have a couple dollars there I could use somewhere else. So you don't get the money locked out you could accept PMs from people wanting to withdraw and you'd fund the account just enough for that? I mean, not having a way to move US$ in and out of mtgox is a pain, but having the $ help hostage is, well, a bigger pain (I'm not in the mood for cursing right now ). And if people want to trade in mtgox while you search hi and lo for the ultimate payment processor (tm) they can buy a few coins personally on the forum or on biddingpond (funny how noone did that yet, "I have $100 to sell, bidding starts and 500 BTC" sorta thing), move that to mtgox and trade away. |
|
|
|
I would happily bid, but all my US$ are on mtgox |
|
|
|
Dear betting friends, The last draw had no winners, second time that happens. And the side pot is larger than the average pot now so, time for a guaranteed jackpot? What this means is: - All the prizes, including 1st prize, are merged down if they have no winners, nothing gets moved to the next draw. - Side pot is emptied and added to the pot of the next draw. You guys up for it? I was thinking the running draw would be a jackpot (that's for block 85500), but can also do for 86000 if you want time to collect all the bitcoins you can get to bet |
|
|
|
|
This really, I mean *really* looks great, thanks for sharing! Now, if they'd allow direct transfer to another registered user account, using the same currency, mtgox would have a great payment processor for people around the world in all currencies to transfer money in and out using bank accounts (i.e. zero chargeback)
|
|
|
|
That's what keeps exchanges from thriving, I guess. Buying and selling stuff with bitcoins is, at most, tax fraud *if* it does not get reported to the IRS. Same as buying and selling using US$ for what that's worth. But exchanging money in an untraceable way for bitcoins, and then back, is kind of a big bright shiny red arrow pointing at the exchange service. I, myself, believe there's no such thing as "money laundering", only money that taxes weren't collected upon, but that's not the point. What can I, if opening a small exchange, do to prevent being mistaken for a money launderer and still keep the anonymous part of the deal? I mean, tax-wise, I'm more than happy to report as profit all the local currency profit I make, and even report on the size of my bitcoin stash (though as a non regulated commodity, there's no way to accurately correlate their value to local currency). But how can I keep away from liability, if the service I charge for is used for doing unlawful stuff and I don't report on the color of underwear of everyone trading on my exchange? Sorry for stealing the thread, feel free to tell me off |
|
|
|
3 And on the 8th day Satoshi decreed that there shall be 21 million coins of bit, and it was so.
I was surprised I never noticed this paragraph until I re-read the passage recently. More seriously, should we say again that the actual amount of bitcoins doesn't matter, as long as it is both constant and divisable enough ? It's really just a unit of measure. In a ton of sand, there are 1000 of kilograms, one billion grams, and still, it's all the same amount of sand. I don't think I fancy the comparison used. Bitcoins and sand, sounds like negative connotation... Let me try and fix that: It's really just a unit of measure. In a ton of cash, there are 1000 kilograms of hard currency, a shitload of dough, and still, it's all the same amount of cash. |
|
|
|
I don't usually step into these discussions where I don't have anything of value to add, except to make smart ass remarks and take a shot at sarcasm, but c'mon guys, what's with this call to violence? You begin to sound just like the government: we can't outsmart them or we simply don't bother to try at all, so what else can we do? Oh, right, BOMB THEM. I'm not here to judge, nor do I have the moral to do it, but just my 2 bitcents here, can we not create a honeypot scenario and scam the scammers? I know there's a test network So here's what I propose: - Lets come up with a legit looking exchange - Get some bogus volume going - Get the money stolen by the scammers on our pockets, along with the credit card details so we can give it back - Log ips, try to get into their machines, etc I can code something up, if there's people up for the design part. Also, we need to find a way to keep legit users at bay. Ah, yes, and there's no telling if mtgox and johnyrich didn't do that already... hehe |
|
|
|
done!
Good for you! What was it you did again? |
|
|
|
|
You got everything correct, but left out the part where everyone else is a little richer after that (except for you). Bitcoins are very divisible and thus the 21M is just the number of coins, but put 8 decimal places on top of that and the "unit of currency" is a lot larger.
|
|
|
|
I can get a bitcoind service going in no time: - You get one bitcoin server with a wallet - The wallet gets backup up every... hour? Or I can be smart and backup when new inbound addresses exist. - You get to use it in an rpc port (not the default) probably only responding to specific IP addresses - You can request physical backups sent to you periodically - The bitcoind gets updated with security patches - Includes (at least) getblock / listtransactions / rpcport patches, can include others by request But you'll need to run your service against a specific port to talk to bitcoin, and you have to trust me Is there interest in this? How much would you pay for it, knowing physical backups will be paid separately? |
|
|
|
|
Show Posts
