[Q] How/where TXID is created

[tadzio]

Question regarding HASH called TXID (as of gettransaction().txid).
Can this be influenced by the sender - the one that (as I understand) creates and signs the transaction.

I'll try to explain:

I ask sender to send me 0.1BTC.
Say I bet with him that when his TXID has say 'H' as third character in TXID he wins 100 BTC.
Can sender somehow influence this HASH - by modifying transaction content(?) - to win the bet?
And if so, is something in trans content that could be used instead of TXID that the sender can not influence?

[amaclin]

Can sender somehow influence this HASH - by modifying transaction content(?) - to win the bet?

Yes.
I can prove it.
You send me 0.0003 btc
I will send back 0.0001 btc and transaction hash will start with "123" (for example)

[dserrano5]

Can sender somehow influence this HASH - by modifying transaction content(?) - to win the bet?

He could generate a raw transaction and sign it multiple times (as this yields a different, yet valid, signature) until the hash of the signed transaction matched the required constraints.

[spin]

One can change the txid (hash) of someone else's tx.  This is called "transaction malleability".  You can read about it here: https://en.bitcoin.it/wiki/Transaction_Malleability

Additionally you say the sender is creating the tx?  He has even more freedom to do this.  He could play around with the inputs etc on the transaction until he finds a tx with a hash that meets the requirements to win the bet from his side.  

Of course you could then take the same tx and change it to meet your requirements

EDIT: In short don't bet on tx hashes.

[andytoshi]

He could generate a raw transaction and sign it multiple times (as this yields a different, yet valid, signature) until the hash of the signed transaction matched the required constraints.

I'm not sure if this is what you're saying, but with programs that use a randomized signing algorithm (Bitcoin Core is one), if you sign a tx multiple time it'll have a new txid each time. There is no need to tweak the transaction.

And as spin observes, even without any private keys you can tweak the transaction in a couple of ways, which is unfortunate but a fact of life when designing Bitcoin protocols.

[dserrano5]

He could generate a raw transaction and sign it multiple times (as this yields a different, yet valid, signature) until the hash of the signed transaction matched the required constraints.

I'm not sure if this is what you're saying, but with programs that use a randomized signing algorithm (Bitcoin Core is one), if you sign a tx multiple time it'll have a new txid each time. There is no need to tweak the transaction.protocols.

Yes, exactly.

[tadzio]

Thanks for all the answers/explanation.

Any idea regarding last sentence/question from first post?

[amaclin]

And if so, is something in trans content that could be used instead of TXID that the sender can not influence?

No.

My suggestions:
1) Do not create just another casino or betting system.
2) Check how this is solved by existing systems. They use list of secret nonces and public hashes of them

[DannyHamilton]

Thanks for all the answers/explanation.

Any idea regarding last sentence/question from first post?

The sender is in full control of the transaction.  They get to see everything about the transaction before they ever transmit it.  They can always look at a transaction and decide not to send it if the thing you are using to determine a "win" doesn't exist in the transaction.

Instead, you could have some secret piece of information that you don't tell anybody.  When you receive the transaction, you could combine it with the secret information.  Then you can see if the combination of the secret information and something from the transaction result in a "win".  This is sometimes handled by generating a hash of the combined TXID and SECRET, and checking to see if the resulting value is less than some target value.  The lower the target value, the more difficult the odds of being successful.  This allows you to adjust the odds of "winning" by adjusting the target value. After a while, such as the end of the contest, or end of the hour, day, or week, you could reveal the SECRET so that everybody could check and see for them selves that you aren't lying and they actually did "win" or "lose".

The problem with this solution is that, since the secret value isn't known to anybody else, you could generate multiple secret values and check the result of each one until you find a combination that gives you results that you like.  Then you could use that secret.  To prove that you haven't cheated in this way, you can generate a hash of the SECRET and release the hash at the beginning of the contest (before the transactions are sent).  Then when you later release the actual secret, everyone can calculate the hash of it to verify that it matches the hash that you released before the contest.

[tadzio]

Thanks for all the answers/explanation.

Any idea regarding last sentence/question from first post?

[..]  To prove that you haven't cheated in this way, you can generate a hash of the SECRET and release the hash at the beginning of the contest (before the transactions are sent).  Then when you later release the actual secret, everyone can calculate the hash of it to verify that it matches the hash that you released before the contest.

Yes, this makes sense but seems little too complicated for average user...?
I was hoping there is something generated in the block-chain - connected to this transaction - that could be easily verified by every user...

[amaclin]

I was hoping there is something generated in the block-chain - connected to this transaction - that could be easily verified by every user...

you can take a sha256 ( txid | blockid ) where | stands for concatenation
but "bad" miner (pool owner) can play against you

Yes, this makes sense but seems little too complicated for average user...?

who cares about it?

[dabura667]

you can take a sha256 ( txid | blockid ) where | stands for concatenation
but "bad" miner (pool owner) can play against you

Actually, if you concatenate the whole blockid of the block containing the tx, that would require the miner to brute force multiple solutions to the block until he found one that mixed with the txid to generate the desired solution.

Even finding one solution to a block takes YEARS for a single person, but if you are looking for a value that has a low enough probability, even GHash.io wouldn't be able to brute force it.

Even if they COULD (which they can't) all you have to do is say "and you are required to send the unconfirmed tx within 5 minutes from now." then there's not enough time for GHash to solve enough blocks to make the hash ot (txid | blockid) match a certain value, unless it was something like "if the first bit is 1" or some high probability thing...

[amaclin]

Actually, if you concatenate the whole blockid of the block containing the tx, that would require the miner to brute force multiple solutions to the block until he found one that mixed with the txid to generate the desired solution.

This kind of attack is well known.
The pool owner creates transaction for 50/50 bet and does not broadcast it to a network but places in in his block template.
If the block is found by everyone else - nothing happens. No bet, no lose, no win. Nothing.
If the block is found by a miner of this pool there are two possibilities for an owner: if his transaction wins - he broadcasts the block as usual
if his bet loses - he withholds block. Miners lose their profits, but not an pool owner.

Sorry for my English

[dabura667]

Actually, if you concatenate the whole blockid of the block containing the tx, that would require the miner to brute force multiple solutions to the block until he found one that mixed with the txid to generate the desired solution.

This kind of attack is well known.
The pool owner creates transaction for 50/50 bet and does not broadcast it to a network but places in in his block template.
If the block is found by everyone else - nothing happens. No bet, no lose, no win. Nothing.
If the block is found by a miner of this pool there are two possibilities for an owner: if his transaction wins - he broadcasts the block as usual
if his bet loses - he withholds block. Miners lose their profits, but not an pool owner.

Sorry for my English

Yeah, for a 50/50 bet.

In the OP situation, he was saying to bet 0.1 BTC to get a return of 100 BTC... we can assume that the requirement will be more than 50/50... more like 1 in 1000 or somewhere close.

Pool operator waiting for 1000 block solutions will DEFINITELY raise flags with his miners LONG before he finds a winning combination.