Topic: btc hash rate (Read 986 times)

It will work if you use the transaction ID only as the client seed and have a separate server seed. This is the approach that SatoshiDice uses.

1. Generate a server seed
2. Compute the (SHA256) hash of the server seed and make that hash visible to users.
3. User places a bet by sending a transaction, fetch its transaction ID.
4. Generate a hash from the combination of server seed and tx ID. This hash will determine the outcome of the bet.
5. At the end of the day (which is what SatoshiDice does, but you can have other time intervals), reveal the server seed and generate a fresh one.

The user can verify with the hash of the server seed that you didn't change it. The tx ID component means that there is an element of the bet that is out of your control, so the user can be assured that he won't be cheated this way. And by combining the tx ID with the server seed, you prevent the user from being able to keep generating transactions until he gets one with a winning tx ID, because he can't determine in advance what a winning ID would be without knowing the server seed. Of course, the process with which all the computations are performed in the steps above should be publicly available, so that when the server seed is revealed at the end of the day, users can verify that all their bets had the correct outcome.

There are variations to this theme, but this is the general process behind provably fair betting.

It is not workable. Just stop.

this game is more like the satoshidice, player send btc to our address to bet , and the result will be depending on this transation code.

hi gmaxwell, im not the programmer:P but our team do has two excellent ones:) We have two btc betting sites already(sites are in my signiture) but they are focusing in chinese customers.  and now the point is that if our ideas is good to be continued? Our third site is going to be focusing in all customers around the world if this idea is workable.

Being created by people who are not yet qualified to write software in this space. You're likely to go broke if you create custom transaction processing software at your current level of expertise, if not due to transaction grinding than due to something else. When you build some kind of automatic transacting system you're effectively building a cryptographic protocol, small details can result in complete insecurity.

Many thanks for your quick reply. We are now working on a betting game based on the btc transation code. As you know, every hash has number 0 to 9 and letter a, b,c,d,e,f. We consider a as number 10, b as 11, c as 12, d as 13, e as 14 and f as 15, then we have 0 to 15, totally 16 number, if player bet the first hash number is below 8, and the result comes out is b/w 0 and 7, then they will have 2 time of what they bet back.

As u mentioned,  'If a person wants to create a transaction hash that starts with (or ends with) a particular set of characters, then they can generate a transaction without broadcasting it and see if it starts (or ends) the way they want it to.  If it doesn't, then they can discard the transaction, and create a new slightly different transaction to see if it starts (or ends) the way they want it to.  They can repeat this process until they get a transaction ID that they like, and broadcast that transaction to the network.'
is that means our game is very risky coz player can get the transaction ID that they like...?

There may be, but you will need to be more specific.

The above description said that you can keep trying hashes until you get ones that are in some way similar to some target, but that only goes so far. It is infeasible for example to ever create an entire hash that exactly matches a target.

The only way to "predict" hashes is by bruteforce, trying all possible combinations till you reach your desired hash. To predict the 4 you described, may not be possible. I have no idea how SHA256 works, but if it uses the whole data and hashes it once to get the 4, then you will require the whole data in advance to get said 4.

Avoid what happening?

Generally "provably fair" systems require 2 pieces.

The game provider generates a list of random information before the game starts.  They keep this list private and secret.  They then calculate the SHA256 hash of each of the elements in the list, and publish the list of SHA256 hashes.  As long as the random information is large enough, it is impossible for anyone to figure out what the elements are from the published hashes.

Then the transaction ID from the player's transaction is combined with an element from the secret information (for example with concatenation), and a hash is calculated from the combined user transaction AND game provider secret.  The value of the resulting hash is the information that is used to determine the outcome of the game.

Since the player doesn't know what the secret information is, they can't know if their transactionID will win until after they submit the transaction to the network.  Since the game provider doesn't know what the player's transactionID will be, they can't know if the player will win until after the player submits the transaction to the network.

Then after the results of the game are determined, the game provider can publish the secret value that they used.  This way everyone can calculate the SHA256 hash of that secret and compare to the previously published list of SHA256 values.  That way the game provider can prove that they generated the "random" secret BEFORE the player submitted their transaction.

We are working on a game based on the hash prediction, what u explained that means we have to abandon this project... could we have any other way to avoid this being happening?

If you know the contents of the transaction (and you don't have the transaction hash), then you can calculate the entire transaction hash.

If you have the transaction hash (and you don't have any of the contents of the transaction), then you can not calculate any of the contents of the transaction.

Until you have all the contents of a transaction and calculate the hash, it is impossible to predict what any of the numbers of the hash will be.

If a person wants to create a transaction hash that starts with (or ends with) a particular set of characters, then they can generate a transaction without broadcasting it and see if it starts (or ends) the way they want it to.  If it doesn't, then they can discard the transaction, and create a new slightly different transaction to see if it starts (or ends) the way they want it to.  They can repeat this process until they get a transaction ID that they like, and broadcast that transaction to the network.

Here i have one  questions, as i have been told, every btc transation code (hash) is random and uncalculatable.

For example, transation  467c33cc084ce12cfafbb59f45ba5b414dfe7d061bbe121093bb5e3dc16f2e44, will it be possible for us to calculation the first code '4' or any other codes before we send this transation?

We are working on a BTC project right now and your answer in details would be much appreciated and important to us.