blockchain Transaction not found

[marmaduke80]

heya can someone help me please,

just tried making a transfer from my cex.io account to my wallet on my smartphone.

blockchain Transaction not found

https://blockchain.info/tx/7818e0660aeaaeb0da3fe383ab7ca784625f2050e057201b9f04d204622c7c3b

and receiving address

https://blockchain.info/address/19mS5rGcYQMysfPKqBNB6Mp6DcwaMAGinR

any idea's?

thanks

[1715003050]

1715003050

[1715003050]

1715003050

[spin]

blockchain.info is down at the moment also.

[spin]

Here it is: http://blockr.io/tx/info/7818e0660aeaaeb0da3fe383ab7ca784625f2050e057201b9f04d204622c7c3b
1 confirm.

[Vortuarackne]

BlockChain.info is terrible, their nodes seem to take an AGE to update.

[binaryFate]

I believe they also have some types of rules to not show transaction with unconfirmed inputs. There are additional criteria because many transactions with unconfirmed inputs are displayed but not all.

I'm an operator of luckyb.it, and payouts there typically have an unconfirmed input (the players' bets) and sometimes they don't show on BC before confirmation.
It's annoying because people tend to take blockchain.info as ground truth, but if you have a wallet like bitcoin-qt you can "see" an incomming transaction instantly while it will remain hidden on blockchain.info until confirmation, which shows it's really something on BC.i and not network propagation problems.

[DannyHamilton]

I believe they also have some types of rules to not show transaction with unconfirmed inputs. There are additional criteria because many transactions with unconfirmed inputs are displayed but not all.

I'm an operator of luckyb.it, and payouts there typically have an unconfirmed input (the players' bets) and sometimes they don't show on BC before confirmation.
It's annoying because people tend to take blockchain.info as ground truth, but if you have a wallet like bitcoin-qt you can "see" an incomming transaction instantly while it will remain hidden on blockchain.info until confirmation, which shows it's really something on BC.i and not network propagation problems.

Transaction Malleability makes it a VERY BAD idea to be using unconfirmed inputs in your transactions.  There is a very real possibility that the transaction ID of the player's bet will NEVER confirm (if a malleated version of it is confirmed instead).  How do you handle this situation?  Do you use any part of the player's transaction ID in determining whether the player wins?

[binaryFate]

Transaction Malleability makes it a VERY BAD idea to be using unconfirmed inputs in your transactions.  There is a very real possibility that the transaction ID of the player's bet will NEVER confirm (if a malleated version of it is confirmed instead). How do you handle this situation? 

That is the point of doing it that way (same for satoshidice btw), if the bet never confirms, the payout neither. Which is exactly what you want as a game operator, (from the operator point of view the malleability issue is the same as with "classic" double-spends).

Do you use any part of the player's transaction ID in determining whether the player wins?

Yes we use part of player transaction ID to determine outcomes (same as satoshidice again), that is partly what makes the game provably fair. But unlike MtGox situation where malicious entities had an interest to "malleate" a transaction as soon as they got it no matter what was the tx ID, in our case there is no point in doing so before knowing that outcome of your bet, which takes a reasonable time because you must wait for our game to (i) receive the bet through bitcoin network, (ii) process it and shows the outcome to you (and we have influence on this as long as it doesn't penalize the player gaming experience).

Note that we could use input other than the tx id that are resilient to malleability (like tx ids of transaction inputs), but the possibility of "classic" double-spend remains, so I personally don't think it's worth the trouble. It's also much easier for people to grasp how the game works if you use the tx id that everybody can see easily on blockchain. If a game is suppose to be provably fair but nobody understand shit as to how exactly it works (not naming any here  ) it's bad.

Anyway I agree it is a sensible issue, and I discourage people from setting up similar games without knowing precisely what they do!

[DannyHamilton]

Transaction Malleability makes it a VERY BAD idea to be using unconfirmed inputs in your transactions.  There is a very real possibility that the transaction ID of the player's bet will NEVER confirm (if a malleated version of it is confirmed instead). How do you handle this situation?  

That is the point of doing it that way (same for satoshidice btw), if the bet never confirms, the payout neither. Which is exactly what you want as a game operator, (from the operator point of view the malleability issue is the same as with "classic" double-spends).

Do you use any part of the player's transaction ID in determining whether the player wins?

Yes we use part of player transaction ID to determine outcomes (same as satoshidice again), that is partly what makes the game provably fair. But unlike MtGox situation where malicious entities had an interest to "malleate" a transaction as soon as they got it no matter what was the tx ID, in our case there is no point in doing so before knowing that outcome of your bet, which takes a reasonable time because you must wait for our game to (i) receive the bet through bitcoin network, (ii) process it and shows the outcome to you (and we have influence on this as long as it doesn't penalize the player gaming experience).

Note that we could use input other than the tx id that are resilient to malleability (like tx ids of transaction inputs), but the possibility of "classic" double-spend remains, so I personally don't think it's worth the trouble. It's also much easier for people to grasp how the game works if you use the tx id that everybody can see easily on blockchain. If a game is suppose to be provably fair but nobody understand shit as to how exactly it works (not naming any here   ) it's bad.

Anyway I agree it is a sensible issue, and I discourage people from setting up similar games without knowing precisely what they do!

I'm curious.

If:

• a player sends a transaction with the transactionID that they can see
• their transaction is a "winner", and you send the winning transaction back to the player
• somone else malleates the transactionID
• the malleated transaction is a "loser"
• the malleated transaction ends up being the one confirmed

Do you re-issue the "winnings" for the player (since the actual transaction ID that he sent was a winner)?

If not, then how can the game be "provably fair"?  Couldn't you malleate the transactionIDs on some of the winning transactions that you receive to boost your profits?

It might be easy to understand, but it isn't "provably fair".  Wouldn't it be better to actually be "provably fair" even if the user doesn't understand how it works than to lie and claim to be "provably fair" when you actually aren't?

[spin]

I'm curious.

If:

• a player sends a transaction with the transactionID that they can see
• their transaction is a "winner", and you send the winning transaction back to the player
• somone else malleates the transactionID
• the malleated transaction is a "loser"
• the malleated transaction ends up being the one confirmed

Do you re-issue the "winnings" for the player (since the actual transaction ID that he sent was a winner)?

If not, then how can the game be "provably fair"?  Couldn't you malleate the transactionIDs on some of the winning transactions that you receive to boost your profits?

It might be easy to understand, but it isn't "provably fair".  Wouldn't it be better to actually be "provably fair" even if the user doesn't understand how it works than to lie and claim to be "provably fair" when you actually aren't?

lol was wondering the same thing reading his description.

[cp1]

What if the user sends a bet, it's a loser, and so they send another mutated bet, giving them another chance to win with the same coins.

[DannyHamilton]

What if the user sends a bet, it's a loser, and so they send another mutated bet, giving them another chance to win with the same coins.

If the user waits that long, then it is likely that none of their peers will relay the second transaction (since it attempts to double-spend the same inputs).

However, they pre-generate two copies of a transaction (each with a different transaction ID) and then simultaneously broadcast one copy to luckyb.it and the other copy to a transaction tracking site (such as blockchain.info).  This would give them 2 simultaneous attempts to win.  Then if luckyb.it, indicates that they are a loser, they could contact luckyb.it support and claim that the transaction ID at blockchain.info is their real transaction and that luckyb.it processed a malleated version.

So, if luckb.it does re-issue winnings, they open themselves to Transaction Malleability abuse from users, and if they don't re-issue winnings, then they can't claim to be "provably fair" since they could be abusing Transaction Malleability themselves.

The only solution is to use a transactionID that is not malleable for computing winning bets (such as NTXID).  This is more complex for the user to understand, but at least it is honest and "provably fair", which is much better than the dishonest and not "provably fair" solution that they have right now.

[binaryFate]

The whole "provably fair" concept of luckyb.it and all other similar on-chain games that I know is that it is according to *the data in the bitcoin blockchain*. In a way that you can parse the whole blockchain and check that all payouts are indeed corrects (in our case it's based on the path followed by coins falling through the games, for dice-stuff it's just a lucky number).
This is on the level of "settled" things, written in stone in the blockchain.

Then there is the "instantaneous" level, innerant to games based on unconfirmed transactions.
You make a very good point Dany! Malleability can indeed be exploited in the other direction too (games to players). The games themselves could try to malleate transactions that essentially they don't want to see happening (ie, if the player wins and the game is not happy).

It would be shooting themselves in the foot as the player knows the txid he sent (later that tx would never confirmed and the malleate one would, to the surprise of the player), and can check the day after (knowing the secret key then) that his transaction that got malleated by "someone" was indeed a win. So after few reports it would be extremely bad for the game reputation. Note that nobody else could "attack" the reputation of a game by malleating transactions because they would essentially malleate as many winning as loosing transactions. But I admit that all this has nothing to do with provably fair, it's just stupid business-wise.

Our own game (luckyb.it) is too small at the moment to lead the change towards malleability-resilient random inputs, or at least there is no urgency to do so. If/when needed we will moove to that. Currently checking a bet just requires you to find info you can get on blockchain.info, switching to a more complex situation, 99% of players couldn't effectively check or even understand anything, which is ok if you have a strong reputation but might be hard at the beginning.

Anyway, I am very curious actually why the famous satoshidice (or their players) don't seem concerned with that (the amounts played there are a whole different story wrt ours).