Bitcoin Forum

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)

Step 2)

Step 3+4) (double sha256)

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

Understand a bit. So.. can I say that no one can predict what the hash is going to be?

Noone can! There are many bitcoin casino whose bet results depend upon the transaction hash! If they could be predicted, those casinos would loose a lot of Bitcoins :)

Not predict, but a certain hash might be forced similar to how mining is brute forcing a certain hash.

-> https://bitcointalk.org/index.php?topic=460944.0

I think you guys may be confusing some things like block hash with transaction hash. A block hash cannot be predicted, a transaction hash entirely can.
One can simply assemble the transaction in their wallet and not submit it to the network to know its hash, use one of the available tools and libraries, or calculate it manually. It CANNOT however be forced, in that you cannot take a desired hash outcome and produce a valid transaction from it or make two different data transactions have the same hash. Brute forcing it to produce any valid transaction is not computationally possible. Betting sites use either the block hash, or a combination of the block hash and transaction hash, but never just the transaction hash...

*edit* to clarify, some sites might use the transaction hash, but in combination with other values that make a prediction based on the tx hash impossible. That being said there have been betting sites in the past to make large security mistakes and im sure at least one might have used just a tx identifier at some point...

 But they say the trasnsaction id of your bet transfer! Isn't that transaction hash?  ???

I don't know what site you mean but the transaction id is also the hash. The example I mentioned above links to the genesis block transaction https://blockchain.info/tx/4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b (https://blockchain.info/tx/4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b)

Blocks have a different hashing algorithm https://en.bitcoin.it/wiki/Block_hashing_algorithm (https://en.bitcoin.it/wiki/Block_hashing_algorithm). Block hashes cannot be predicted as mentioned, transaction hashes can be created outside of the bitcoin network.

Wana bet? I predice the next bitcoin block has a hash lower than the current target value.
Mining is nothing but brute forcing the hash until it meets the requirements. Maybe brute forcing is the wrong word in this sense, but its the same with a transaction. You alter the transaction and check the hash until you have the hash you want. There are many ways to alter the TX even if you use the same inputs (see the link on TX malleability), there are even more ways if you have a big set of inputs you could use. If you are saying @altcoinex that this is not "forcing" the hash to be a certain value than please give me a better word for it.

Both blocks and transactions are hashed with SHA256. What different algorithm are you refering to?

I wonder when will I be an expert and I understand these technical things :o
Bitcoin is way too complicated!
Satoshi is a real genius! Genius than Einstien!

Btw this question mayn't belong here but shorena can those powerful bitcoin miners be used to mine altcoins?

Predicting what it will be less than is not predicting it, it is knowing the network rules... Predicting is to know what hash It would be, or any reasonable assumption about that hash OTHER Than those assumeable by network and protocol enforced rules. If I tell you a TX hash, you can have all the inputs in the world, change every value possible within the protocol, and your not going to come up with a TX that matches that hash. It is not 'Forcing' the hash, because you are just changing the hash to another, not forcing it to any specific one. This would be an unacceptable weakness in bitcoin if it were possible. If your playing an online casino game, that persay takes the tx hex, converts it to a number, and turns that into a shuffle pattern for cards, or a dice number outcome, then you could modify the tx until you got one that would produce that result, as where N is the amount of possible game outcomes every N tx's would average 1 of N matching your goal -- which is why betting sites dont use JUST the tx hash.  That example would be 'forcing an outcome' in the game, but you are not forcing a specific hash -- just exploiting how the buggy game is utilizing the hash.

To be correct, both blocks and transactions are double hashed with SHA256. Calling them different algorithms is a bit of a far stretch, but they are created with very different inputs.

Granted that is impossible unless I would be immortal and had the time and resources to try all possible combinations. Creating new inputs etc.


Thanks I understand the issue now. I did not have in mind that I would have to match every bit of the hash.

And all the transactions in a block are hashed together into a merkle tree of hashes.  Whereas a transaction hash is merely sha256 of the transaction bytes, the block hash is a much more complicated procedure.  So I think it's fair to say these are seperate procedures.

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 (https://bitcointalk.org/index.php?topic=1043480.0). Anyone can suggest me a way to do it? Whereas, no one can predict the result.

No, sorry if I mislead you in that regard. It is possible to change the TX hash, but its impossible (in terms of a human livespan and resources) to change it to something specific. Its "possible" as its "possible" creating a private key that has already been created by someone else or that all air molecules in your room spontaneously move into the corner and you die.

Even though only 9 digits of the hash count, the transaction is not created by the participants, but by a third party.

Since you mentioned complexity and Einstein, the following Einstein quote is mandatory:
Everything should be made as simple as possible, but not simpler (http://books.google.co.in/books?id=ca7lAAAAQBAJ&pg=PA103)

In hindsight, some things in Bitcoin could have been made more simple; for instance, the way how transaction signing is performed (which, BTW, leads to the current transaction malleability problem). This shows that, even though Satoshi can be called a genius, not even he is perfect.

If you want to become an expert, it doesn't hurt to be a programmer. If you have no programming experience, I think Python is a nice language to start with: it's relatively friendly to beginners, and it has everything experts want (except, arguably, speed, but often that's not critical). Then, you might want to check out my implementation of Bitcoin transaction algorithms in Python (https://github.com/cornwarecjp/amiko-pay/blob/master/python-prototype/amiko/utils/bitcointransaction.py). Calculation of the transaction hash ( = transaction ID) is a single line of code in the getTransactionID method.

Well I don't get the underlined thing :
Everything should be made as simple as possible, but not simpler

Yes, I do have a 0.1% experience in QBASIC like I know WHILE..WEND, FOR NEXT.. Goto , INPUT, PRINT etc etc :P
 We've gone way off the topic can you please PM me to remove my confusion? Thanks!

Hmm.. Thanks for clearing my doubt. To determine winning ticket #1, I use A-ads transaction ID - yes, that's from third party. To determine winning ticket #2, I use transaction from my wallet to winning ticket #1 wallet. So.. it is not from third party.

Anyway, I'm feeling better as you said:

The other thing you could do if you are worried about someone predicting your lottery draw would be to use some nonce from /dev/urandom or something like that and add it to the end of the transaction you were hashing.

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.


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 (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.

Onto the problems with your current design model:

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.

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.

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.  

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