Pages:
Author

Topic: SatoshiDice - rolled back transactions (Read 2827 times)

legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
November 07, 2012, 04:17:59 PM
#21
I still don't understand why there are blocks with 10-20 transactions when there are 500+ transactions with fees waiting to be included. Why the hell pools don't include them?
Because larger blocks increase propagation time, increasing the risk that the pool's block ends up orphaned, decreasing the overall pay for the miners on average.  No one wants to be part of a pool with a large orphan block rate.

If I was running a pool, I probably wouldn't include transactions without a fee at all.  Any increase in propagation time is less potential payout for my mining minions.
Some pools don't include paid transactions coz they think they aren't paid enough
(even though the transactions are paid according to the standard client rules)
Some pools don't include free transactions.
Some solo miners don't include any transactions.

The simple thing to do is vote with your mining power.
Don't mine at a pool that is bad for BTC transaction confirms.

Luke-Jr at Eligius did this for 5 months since June (max 32 transactions per block) coz their pool is crap and gets more orphans than the other pools ... the fix was to cut down the number of transactions processed to way less than every major pool ... clearly performance and good software is not of interest to Eligius
People mining there should not. It is directly bad for BTC transaction confirms.
And since without transactions, BTC has no value at all, Eligius is bad for BTC.

Eloipool software (used by Eligius) in it's new GetBlockTemplate implementation sends out LP's with no transactions since the GetBlockTemplate makes LP's unmanageable due to the massive amount of data sent with GetBlockTemplate work (way more than even the old GetWork, often hundreds of times more)
legendary
Activity: 1400
Merit: 1005
October 26, 2012, 05:40:27 PM
#20
I still don't understand why there are blocks with 10-20 transactions when there are 500+ transactions with fees waiting to be included. Why the hell pools don't include them?
Because larger blocks increase propagation time, increasing the risk that the pool's block ends up orphaned, decreasing the overall pay for the miners on average.  No one wants to be part of a pool with a large orphan block rate.

If I was running a pool, I probably wouldn't include transactions without a fee at all.  Any increase in propagation time is less potential payout for my mining minions.
hero member
Activity: 756
Merit: 522
October 26, 2012, 05:34:36 PM
#19
I still don't understand why there are blocks with 10-20 transactions when there are 500+ transactions with fees waiting to be included. Why the hell pools don't include them?

At some point there was a large-ish miner who accepted no transactions whatsoever. Fact is miners aren't required to accept transactions, and since the fees are tiny at the moment as compared to block reward this may happen.
legendary
Activity: 2142
Merit: 1010
Newbie
October 26, 2012, 07:34:05 AM
#18
I still don't understand why there are blocks with 10-20 transactions when there are 500+ transactions with fees waiting to be included. Why the hell pools don't include them?
hero member
Activity: 910
Merit: 1005
October 26, 2012, 07:18:25 AM
#17
Ok I've add a new job called PushStuckMyWalletTransactions() which will re-broadcast all My Wallet transactions older than 3 hours every hour. Hopefully this should be enough to keep all our transactions in miners memory pools. I've also increased the expiry time of transactions to 48 hours, since transactions generally seem to be taking longer to confirm nowadays.

Previous this job was called PushMyWalletTransactionsWithPoorPropagation() which would re-broadcast transactions which are not being accepted fully by nodes. However the problem isn't that the transactions aren't been accepted, it's that are being dropped at a later date.
legendary
Activity: 2142
Merit: 1010
Newbie
October 26, 2012, 06:37:26 AM
#16
If SatoshiDICE received the transaction then it was broadcast correctly. Blockchain.info will remove transactions after 24 hours unconfirmed. The problem is with the bitcoin network / miners have trouble with large chains of unconfirmed transactions. Since the memory pool of bitcoind miners is limited sometimes if an unconfirmed chain reaches a certain size the transactions at the beginning maybe pushed out of the memory pool. Meaning the rest cannot confirm.

I can improve this our side by preventing long chains of transactions from being spent. However a better fix would be for the big mining pools to significantly increase their memory pool size (and never drop large transactions).

Thx for the explanation. Good news are that it's not an issue in Bitcoin design but just in its implementation.
hero member
Activity: 910
Merit: 1005
October 26, 2012, 06:23:53 AM
#15
If SatoshiDICE received the transaction then it was broadcast correctly. Blockchain.info will remove transactions after 24 hours unconfirmed. The problem is with the bitcoin network / miners have trouble with large chains of unconfirmed transactions. Since the memory pool of bitcoind miners is limited sometimes if an unconfirmed chain reaches a certain size the transactions at the beginning maybe pushed out of the memory pool. Meaning the rest cannot confirm.

I can improve this our side by preventing long chains of transactions from being spent. However a better fix would be for the big mining pools to significantly increase their memory pool size (and never drop large transactions).
hero member
Activity: 756
Merit: 522
October 25, 2012, 10:31:13 PM
#14
No.  Your transaction would still be "out there" with miners actively working to include it in a transaction somewhere.  Eventually, unless there was malicious action on your part, the tea vendor would receive their money.

It was shown in the blockchain.info interface. Now it isn't. Something went wrong.

This is mildly concerning. As he points out, valid transactions from orphaned blocks do make it into the main chain.
legendary
Activity: 2142
Merit: 1010
Newbie
October 25, 2012, 04:37:35 PM
#13
No.  Your transaction would still be "out there" with miners actively working to include it in a transaction somewhere.  Eventually, unless there was malicious action on your part, the tea vendor would receive their money.

It was shown in the blockchain.info interface. Now it isn't. Something went wrong.
legendary
Activity: 2142
Merit: 1010
Newbie
October 25, 2012, 04:36:20 PM
#12
Probably the result of a blockchain reorg AKA orphan block(s).

Heh. And now imagine that I bought a cup of tea for that 0.125 BTC from a retailer who accepts unconfirmed transactions. Free tea Smiley
How is that different from the official client and orphaned blocks?

Do u mean it's by Bitcoin design?
Those coins weren't double-spent ones and my transaction had miner fee. The transaction wasn't included in any block, so orphaned blocks are not the issue. There is some other problem and if I had a lot of money in bitcoins I would start to worry about it right now, coz if the network can "forget" transactions then some things must be tuned better, much better if we wish Bitcoin to be adopted by serious businessmen.
legendary
Activity: 1400
Merit: 1005
October 25, 2012, 04:28:40 PM
#11
Probably the result of a blockchain reorg AKA orphan block(s).

Heh. And now imagine that I bought a cup of tea for that 0.125 BTC from a retailer who accepts unconfirmed transactions. Free tea Smiley
No.  Your transaction would still be "out there" with miners actively working to include it in a transaction somewhere.  Eventually, unless there was malicious action on your part, the tea vendor would receive their money.
hero member
Activity: 560
Merit: 500
I am the one who knocks
October 25, 2012, 04:25:46 PM
#10
Probably the result of a blockchain reorg AKA orphan block(s).

Heh. And now imagine that I bought a cup of tea for that 0.125 BTC from a retailer who accepts unconfirmed transactions. Free tea Smiley
How is that different from the official client and orphaned blocks?
legendary
Activity: 2142
Merit: 1010
Newbie
October 25, 2012, 03:18:09 PM
#9
Probably the result of a blockchain reorg AKA orphan block(s).

Heh. And now imagine that I bought a cup of tea for that 0.125 BTC from a retailer who accepts unconfirmed transactions. Free tea Smiley
legendary
Activity: 1400
Merit: 1005
October 25, 2012, 02:23:11 PM
#8
Probably the result of a blockchain reorg AKA orphan block(s).
legendary
Activity: 2142
Merit: 1010
Newbie
October 25, 2012, 02:20:02 PM
#7
I've caught a rolled back transaction - http://satoshidice.com/full.php?tx=6624703b6ad91c9975be23e534205b7380c9df5c3be083bbc33af013b5649dd5

Here is copy of the page in case it will disappear:

Quote
Transaction 6624703b6ad91c9975be23e534205b7380c9df5c3be083bbc33af013b5649dd5

6624703b6ad91c9975be23e534205b7380c9df5c3be083bbc33af013b5649dd5:0

Processed time: 2012-10-25 07:01:27
Key date: 2012-10-25
Bet: lessthan 32000
Bet TX: 6624703b6ad91c9975be23e534205b7380c9df5c3be083bbc33af013b5649dd5
Payment TX: f2a86c49dc2e406423a48eef17a285c50b5454dd40b904706ad3c56b014ce790
Payment TX Status: UNKNOWN
Bet Amount: 0.12500000
Outcome: WIN
Payment: 0.24998100
Address: 1D8qR2YeM3fWX9iaLKZv4EdUc8FSGb3cWM
Lucky number: 27679
Validation

Secret hashes

Download and verify hash.keys

For more details on the secret keys see secrets

Using correct secret key

Verify that the secret used hashes to the hash listed for for 2012-10-25 in hash.keys
sha256(hidden) -> 91297cce277e5273a9395be10d089dabecfe9e0492d6a0315658bff0905ab9d4

Secret and Transaction Hash

Verify that the hmac sha512 with secret and transaction_id hash to the bet hash
hmac_sha512(hidden,6624703b6ad91c9975be23e534205b7380c9df5c3be083bbc33af013b5649dd5) -> 6c1f3fd44b82f767134501c93ab425a998f06c71707bcd204ba04755b6975ee3 hmac512

Lucky Number

Verify that the first bytes of the bet hash above is the lucky number
6c1f3fd44b82f767134501c93ab425a998f06c71707bcd204ba04755b6975ee3 -> 6c1f -> 27679

Looks like the problem is with BLOCKCHAIN.INFO. And it wasn't a double-spent coins, coz the rolledback transaction was the 1st bet from a freshly created webwallet.
legendary
Activity: 2142
Merit: 1010
Newbie
October 24, 2012, 02:54:44 PM
#6
You know you're going to be losing money in the long run with satoshidice, right?

I know. Also I know that "the long run" is something like 1000000 bets, so I'm safe if I'm going to play only 1000 ones.
newbie
Activity: 41
Merit: 0
October 24, 2012, 02:16:09 PM
#5
You know you're going to be losing money in the long run with satoshidice, right?
legendary
Activity: 2142
Merit: 1010
Newbie
October 24, 2012, 01:15:57 PM
#4
good luck winning them back Smiley

Thx. It was easy - 4 BTC on "Less Than 32000" Smiley
hero member
Activity: 826
Merit: 500
October 24, 2012, 10:39:41 AM
#3
good luck winning them back Smiley
legendary
Activity: 2142
Merit: 1010
Newbie
October 24, 2012, 08:06:18 AM
#2
I'm terribly sorry. It was my fault.
I forgot to switch the bot off and while I was having dinner it awoke after won coins had been confirmed and lost those 3.2 BTC.
F*ing Artificial Intelligence  Grin
Pages:
Jump to: