How is the transaction hash determined?

[altcoinex]

Please be sure you think this all the way through before you actually get this going. There is alot of room for error and exploit.

Okay, so from what I understand.. It is possible to predict the TX Hash. However, that is only possible if we have lot of time and resource. Am I on the right track? I'm just trying to find a way to select a winning number for my free lottery game - here. Anyone can suggest me a way to do it? Whereas, no one can predict the result.

This is incorrect (regarding only possible with time and resource), depending on the circumstance. If you know the data in the transaction, then it is possible to know the TX Hash. If you create the transaction, you can know the TXHash before it is sent to the network. Please see http://bitcoin.stackexchange.com/questions/2859/how-are-transaction-hashes-calculated. So:

- You cannot create a transaction to have a specific desired hash..
- You can EASILY without almost any resource, instantly know what TXHash any transaction will have, that you know the contents/specifics of.
- While you cant make a tx have a specific hash, you could make it's hash persay end with a specific character like '3' if you wanted, by changing small values that wouldn't change the tx load otherwise until you find a hash that qualifies, and this as well could be done near-instantly with minimal resource.

[1714561462]

1714561462

[1714561462]

1714561462

[1714561462]

1714561462

[1714561462]

1714561462

[1714561462]

1714561462

[altcoinex]

Onto the problems with your current design model:

How do we determine the winning tickets?

It is very hard to predict a transaction hash and that's why we choose to use transaction hash to determine the winner.

The winning ticket #1 is determined by A-ads transaction hash (which is public on their website). The winning ticket #2 is determined by the transaction we send to winning ticket #1. The winning ticket #3 is determined by the transaction we send to winning ticket #2. And.. this continue until we reach winning ticket #5.

As I hope you have learned by now, it is not hard to predict a transaction hash -- assuming you know the contents of it. This will only work if you are sure the transaction is out of control of anyone involved with your lottery, which as far as I can see you have no way of restricting. Your game should have no central place that can game the system, in this case, A-ads is. While it's not likely they would modify their transactions to exploit your game, just the fact that it is possible -- and that your games users do not know your not working on conjuncture with A-ads to rig the system, makes it an unacceptable point of failure/risk. Online gambling should be provably, confirmably fair/random with no point of reliance or trust on anyone.

Much more so the case, you are generating the transactions for all tickets following, so you have the ability to repeatedly create transactions with the same input/output set changing other variables until you produce a hash with a result favorable to you, or those in the game you want to win, and only submit those transactions. This would again be another unacceptable point of centralized influence in the outcome, that will shy away users and is against the fundamental of decentralization being that no party should even have the POTENTIAL to influence the outcome, so no trust is necessary.

[altcoinex]

The solution, in my opinion, as suggested earlier in the thread is to use block hashes, not transaction hashes.

First, is there any reason not to use block hash instead of tx?

While a block hash, much like a transaction hash can be calculated by anyone knowing the data in it, they have some key differences:

   - The block hash has to meet or beat the difficulty requirement. So just knowing the hash isn't good enough, you have to know it and it has to meet the requirement. There is a ultra strong competitive financially driven race to solve the next block(each currently worth at least ~5800$US, not something they are likely to want to risk in order to get what your site distributes in just a 10 minute window), so there is no time for anyone to discard valid solution hash's to try to produce a different hash that would be more favorable in a third party game -- the odds are too great someone else would solve the block before they find a second solution, let alone iterate through enough solutions to have a favorable hash that meets difficulty.

Beyond that, to know a transaction is actually real, you would have to use transactions that are included in blocks, as opposed to just submitted to a node you control. So other than if your using 0conf transactions, a block hash will be available to you anytime the transaction hash would.

The only problem I could see, is if you had a need to pay out more frequently than bitcoin's average block time(10 minutes). Realistically, what are the odds your site is making enough revenue to NEED to do payouts more than every 10 minutes... Chances are doing so would likely just be wasting the money being generated with transaction fees. It would make much more sense to do larger payouts less often, so there probably isn't any time orientated reason not to use blocks in this case.

[Cryddit]

There are plenty of ways to arrange a provably honest gambling game that don't involve block or transaction hashes, and can be done as often as you like instead of just when blocks come out.  Here's a simple one.

Let's say Alice and Bob are doing a gambling game where they need a series of random numbers (die rolls, card draws, whatever) that are provably predictable to neither and provably chosen by neither.

Bob picks a random number R_Bob (say, 256 bits from his /dev/random output) and Alice picks R_Alice.

Bob hashes R_Bob to get R_B(0), hashes R_B(0) to get R_B(1), hashes R_B(1) to get R_B(2), etc.....  Likewise Alice hashes R_Alice to get R_A(0), hashes R_A(0) to get R_A(1), hashes R_A(1) to get R_A(2), etc.

Now Bob tells Alice R_B(999) and Alice tells Bob R_A(999), and they can start play with N=999.

Each time they need a random number, they subtract 1 from N and reveal the corresponding R_A(N) and R_B(N).  Bob can check that R_A(N+1) is the hash of R_A(N), and Alice can check that R_B(N+1) is the hash of R_B(N), so each knows that the other is providing the next number in their sequence and not one they just picked for a chosen result.  Alice is sure that Bob didn't know R_A(N) until she revealed it, and Bob is sure that Alice didn't know R_B(N) until he revealed it.

And the random number they need, for the card draw or the die roll or whatever, is just R_A(N) XOR R_B(N) (restricted to whatever range the game allows it to have, like 0.. 54 for a card draw or 0.. 6 for a die roll). Each can be sure the random number was unknown to the other until both numbers are revealed, and each can be sure it isn't chosen by the other.  

And if N ever becomes equal to zero, they just pick a new R_Alice and R_Bob, exchange a new R_A(999) and R_B(999), and continue the game.  

[BlueInCoin]

I would like to know how transaction hash is determined.

For example, https://blockchain.info/tx/278090c755aa016483ab3a9e6bffe1d2dfbf5b53edb7099b9946bc9dfe59f217. How does the network generate the underlined text? I searched Google but there is no answer - there was one in 2012. The explanation is way too complicated for me to understand.

I'm doing this on top of my head with a little help from the web, so may have some mistake, but these are the steps:

1. Transactions are encoded as (some data bytes):
- a 32 bit 'nVersion'
- a list of input transactions, vin
- a list of output transactions, vout
- a 32 bit 'nLockTime'

2. string all those together end to end  (some data bytes as a string or block of text)
3. Taking the sha256 hash of this
4. Taking the sha256 hash of this (again)

You can combine step 3 and 4, sha256(sha256(input)).  You do not have to know all the details of sha256 but you should learn the principles of hashing.

Then you have the transaction hash. Bitcoin uses the endian encoding, bytewise reversed.
Example with Genesis block:

Step 1)

Code:

    nVersion: 01000000
    inputs
        count: 01
        1st input:
            prevout_hash: 0000000000000000000000000000000000000000000000000000000000000000
            prevout_n: ffffffff
            scriptSig: 4d:04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73
            sequence: ffffffff
    outputs
        count: 01
        1st output:
            value: 00f2052a01000000 (hex(50*10^8) is 0000012a05f200, and bitcoin puts the bytes in reverse order)
            scriptPubKey: 43:4104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac
    nLockTime: 00000000

Step 2)

Code:

01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff4d04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000

Step 3+4) (double sha256)

Code:

4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b

Have a look at pybitcoin tools https://github.com/vbuterin/pybitcointools, you can easily create transaction hashes with that.

So, these is the formula. I thought it was random number