SatoshiDICE.com - The World's Most Popular Bitcoin Game

[dooglus]

PyWallet errors on wallets that have been opened in Bitcoin-qt v 0.6+

Not for me it doesn't.

Maybe you need a newer PyWallet.

[Gladamas]

PyWallet errors on wallets that have been opened in Bitcoin-qt v 0.6+

Not for me it doesn't.

Maybe you need a newer PyWallet.

No, pywallet won't work with Bitcoin-qt 0.6+, nor will it work with encrypted wallets.

[fireduck]

I realize satoshidice is sometimes slow... but for the past few days I always had to wait at least five minutes before I even know if I won or not. Often times it's even longer.

Is this just me? Or that happens to others too?

Sorry, that was a database change I made.  I make it use transactions in a more conservative way which ended up being a good bit slower so it was having trouble keeping up with people's bets.  It should be much better now.  I really need to track some metrics of bet to result time so that this sort of issue is more obvious to us.

[dooglus]

PyWallet errors on wallets that have been opened in Bitcoin-qt v 0.6+

Not for me it doesn't.

Maybe you need a newer PyWallet.

No, pywallet won't work with Bitcoin-qt 0.6+, nor will it work with encrypted wallets.

Are you sure?  I used it just a few days ago, and I've not had anything older than bitcoin-qt 0.6 for a long time.

Maybe I didn't encrypt the wallet I used it with, but I created it using bitcoin-qt 0.6+.

[dlasher]

Sorry, that was a database change I made.  I make it use transactions in a more conservative way which ended up being a good bit slower so it was having trouble keeping up with people's bets.  It should be much better now.  I really need to track some metrics of bet to result time so that this sort of issue is more obvious to us.

Yes. Please.

[geebus]

PyWallet errors on wallets that have been opened in Bitcoin-qt v 0.6+

Not for me it doesn't.

Maybe you need a newer PyWallet.

No, pywallet won't work with Bitcoin-qt 0.6+, nor will it work with encrypted wallets.

Are you sure?  I used it just a few days ago, and I've not had anything older than bitcoin-qt 0.6 for a long time.

Maybe I didn't encrypt the wallet I used it with, but I created it using bitcoin-qt 0.6+.

Yeah, I tried it last night and it just throws a bunch of errors on my 0.6+ wallet, but worked fine on a 0.5.x wallet.

[dooglus]

Yeah, I tried it last night and it just throws a bunch of errors on my 0.6+ wallet, but worked fine on a 0.5.x wallet.

I just tried it on my encrypted 0.6.2 wallet.  The web interface tells me "deleted 1 transaction" and if I try again, "delete 0 transactions", but when I load the wallet up into the client, the transaction is still showing.  Possibly because it's already confirmed though.  I'll try with an unconfirmed transaction...

[time passes]

Yes, it works with bitcoin 0.6.2 and an encrypted wallet.

I made a transaction in my wallet, then quit bitcoin-qt and ran:

Code:

python pywallet.py --web

in a terminal, then visited http://localhost:8989/ in my web browser, scrolled down to where it says:
  Delete a key from your wallet:
copy/pasted the new unconfirmed transaction ID into the 'key' field, and clicked 'delete'.

It told me: "tx:[...] has been successfully deleted from /home/.../.bitcoin/wallet.dat, resulting in 1 deleted item".

I would guess that maybe you have some problems with your 0.6+ wallet, and so exporting and re-importing the keys is probably the best thing to do anyway.

Then when I ran bitcoin-qt again, the transaction was no longer showing at all.  It's still on blockchain.info as an unconfirmed transaction, and I'm sure it will eventually confirm, at which point I will see it in my wallet again.

[geebus]

I would guess that maybe you have some problems with your 0.6+ wallet, and so exporting and re-importing the keys is probably the best thing to do anyway.

Then when I ran bitcoin-qt again, the transaction was no longer showing at all.  It's still on blockchain.info as an unconfirmed transaction, and I'm sure it will eventually confirm, at which point I will see it in my wallet again.

My issue is that these transactions do not exist in the blockchain and were generated during a split. The transactions that are showing on blockchain.info do not appear in my wallet... weird issue. I imagine that rebuilding a new wallet from the private keys should fix it though, since it re-verifies every transaction for every private key imported.

[dooglus]

My issue is that these transactions do not exist in the blockchain and were generated during a split. The transactions that are showing on blockchain.info do not appear in my wallet... weird issue. I imagine that rebuilding a new wallet from the private keys should fix it though, since it re-verifies every transaction for every private key imported.

I just realised - you're importing the keys and rescanning the whole blockchain for each one aren't you.  No wonder it's taking so long.

If you want to speed it up, and are comfortable building bitcoin-qt from source, comment out these two lines in src/rpcdump.cpp then rebuild:

Code:

        pwalletMain->ScanForWalletTransactions(pindexGenesisBlock, true);
        pwalletMain->ReacceptWalletTransactions();

Then you'll be able to import all your private keys very quickly, like less than a second each.  Then run a single 'bitcoin-qt -rescan' at the end and you're done.

There's no need to rescan the wallet separately for every key you import, but that's what bitcoin-qt does.

[Stephen Gornick]

My bitcoind runs 24/7, and has 4 specific other nodes that I run, which it connects to... T

I think that's your problem right there.  

When you shut down the client, it forgets about these invalid and unconfirmed transactions sent long, long ago from SatoshiDICE but since forgotten on by everyone else since they never confirmed.  But then when you start your client back up, it learns of these again from these other four (polluted) nodes of yours.

Why not try a normal startup to the outside world, or with -connect= to a well connected node.

[Raoul Duke]

Just to confirm what dooglus said. pywallet does indeed works with wallets from the 0.6.2 Satoshi client.
I tested it 2 days ago to delete all transactions from my wallet and do a rescan to take a doubt I was having and it indeed worked.

[dlasher]

bets ground to a halt again.. right around 10-11am EST... 

[fireduck]

bets ground to a halt again.. right around 10-11am EST... 

Over 21,000 bets already today.  Everything seems to be flowing fine now except for about 600 unknowns which I am working on clearing up now.  They should be gone in the next 4 hours or so.

[dlasher]

Over 21,000 bets already today.  Everything seems to be flowing fine now except for about 600 unknowns which I am working on clearing up now.  They should be gone in the next 4 hours or so.

Would be useful to have some sort of "average bet delay in seconds" near the top of the main page...

[fireduck]

Would be useful to have some sort of "average bet delay in seconds" near the top of the main page...

Agreed.  I'll work on that. 

[ErebusBat]

Sorry, that was a database change I made.  I make it use transactions in a more conservative way which ended up being a good bit slower so it was having trouble keeping up with people's bets.  It should be much better now.  I really need to track some metrics of bet to result time so that this sort of issue is more obvious to us.

Have you seen graphite?
http://graphite.wikidot.com/

This page has a REALLY good example of how to see if your deploys messed anything up:
http://codeascraft.etsy.com/2010/12/08/track-every-release/

[dlasher]

lots and lots of unconfirmed... something -stopped- about 5:30 EST.

Block had a lot of transactions in it, then... little:

http://www.blockchain.info/block-index/236637/000000000000066930aefb95e7ff55034ceabb569a7e5aca1257fa3920933f84

[fireduck]

lots and lots of unconfirmed... something -stopped- about 5:30 EST.

Block had a lot of transactions in it, then... little:

http://www.blockchain.info/block-index/236637/000000000000066930aefb95e7ff55034ceabb569a7e5aca1257fa3920933f84

Right now we have about 4500 unconfirmed.  I have yet to figure out any coherent way of predicting when the miners will pick these up.

[titeuf_87]

Sorry, that was a database change I made.  I make it use transactions in a more conservative way which ended up being a good bit slower so it was having trouble keeping up with people's bets.  It should be much better now.  I really need to track some metrics of bet to result time so that this sort of issue is more obvious to us.

It seems to be better now, I had three bets reply right away.

But some bets just seems to get stuck.

Take the following for instance fb6553405beb57ba270df9814adcfc63b94e6a5be5546b2e519255b0ed557fc8
Look at both the bet tx and the payment tx: it took around 20 minutes.

Now I have another bet which satoshidice hasn't picked up yet: ff6a2dedc9fd31194806ba8aec7236d32cd4666a5b77fcdc7e01d38bb3cb3b72
That one shows up on blockchain.info, but not on the satoshidice website. on the home page when I look at processing status I see that that the last processing pass is from 22:52 with age 4 (that is the number of tx left to process?)

I hope you manage to resolve those problems too 

[fireduck]

It seems to be better now, I had three bets reply right away.

But some bets just seems to get stuck.

Take the following for instance fb6553405beb57ba270df9814adcfc63b94e6a5be5546b2e519255b0ed557fc8
Look at both the bet tx and the payment tx: it took around 20 minutes.

Now I have another bet which satoshidice hasn't picked up yet: ff6a2dedc9fd31194806ba8aec7236d32cd4666a5b77fcdc7e01d38bb3cb3b72
That one shows up on blockchain.info, but not on the satoshidice website. on the home page when I look at processing status I see that that the last processing pass is from 22:52 with age 4 (that is the number of tx left to process?)

I hope you manage to resolve those problems too 

The problem you are having is that Satoshidice ignores any transaction with a fee of less than 0.0005 until it is confirmed.  Based on my experience that many of these never confirm and we would rather not tie up outputs on them if they are doomed.

For example, blockchain.info shows that last one as "Estimated: Never": http://blockchain.info/tx-index/8969893/ff6a2dedc9fd31194806ba8aec7236d32cd4666a5b77fcdc7e01d38bb3cb3b72