20
Bitcoin transactions have a transaction id (txid) formed as a hash over the data involved in the transaction. That suggests that it is a unique identifier for a transaction.
However, the tx-id of a transaction is only unique once the exact data in the transaction has been finalized by being incorporated into the blockchain (and confirmed). Until then, there ...
7
This is a known bug in the early days of bitcoin.
Was fixed by BIP-30 https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki
There is a discussion here: https://bitcointalk.org/index.php?topic=216938
And yes, 50+50 bitcoins are missed forever.
In fact, there are much more missed bitcoins. For example, 2500 bitcoins were gone to nowhere
in block ...
6
Yes. The transaction ID is SHA256(SHA256(transaction)) as described here and thus always has a length of 256 bits (32 bytes).
6
Inside transaction inputs, you have to refer to previous transactions using the txid. Allowing a wtxid there would be (1) a hard fork and (2) defeating the purpose, as it'd make transactions malleable again.
The wtxid is only used to compute the Witness merkle root, which is committed to in the coinbase.
6
Transactions can have multiple outputs. What you show are two outputs created by the same transaction.
The output positions are enumerated with the vout field. As the first one is vout = 0, the two that you show are the third and fourth output.
5
Is there a quick and dirty way to detect all transactions whose tx-id can be found in more than one transaction since the genesis block?
There are multiple ways to read your question.
Are there cases where the same transaction has been included into the blockchain multiple times?
Yes. There is one recorded instance of the same coinbase appearing twice. The ...
5
No. After transaction A is included into the chain, transaction B is invalid, and will not be mined. If it does show up in a mined block, the entire block is invalid.
It wasn't always like this. Initially, if a transaction had the same txid as a previous transaction, it would overwrite the first one. Then, if that block was reorganized out of the chain, the ...
5
This is the new issue, the one that's causing all the trouble. You basically have two choices:
Don't spend any of your own outputs until you're quite confident they're fully confirmed. For example, you could wait for three confirmations.
Be prepared to deal with this problem by monitoring your outstanding transaction chains and re-issuing any orphaned ...
5
The txid of a segwit transaction is computed by first dropping all the witnesses, and encoding it in legacy notation, and then computing the double-SHA256 hash of it.
This is the only possible way, as anything else wouldn't be compatible with old clients (which is required by it being a softfork).
4
Transaction ID usually refers to the 2xSHA256 hash of the transaction serialized as it would have been transferred in the network. This is also the ID as peers refer to them when broadcasting through the network.
Notice that due to transaction malleability a transaction may have multiple IDs.
4
If the signature was not part of the transaction protected by the hash, then you could have two different transactions, one valid and one invalid, with the same transaction ID. The primary purpose of the transaction ID is to permit agreement on whether a transaction is valid or not. So excluding the signatures from the hash would make transaction IDs ...
4
TXIDs have two forms; the form used internally for outpoints and merkle leaves (internal byte order), and the form used in RPC calls and block explorers (RPC byte order). These are often called, respectivey, little-endian byte order and big-endian byte order (although those descriptions aren't quite accurate).
Here's python code from the Bitcoin.org ...
4
The underlying motivation behind transaction fees is to compensate for resource utilisation as there is always an inherent cost when validating transactions (Electricity - CPU usage) and relaying transactions (Internet Bandwidth). Another reason why there's transaction fees is also to deter spam.
By purposefully sending a signed message (with no fees) to ...
4
Is data that hashed as txid includes witness?
No, the txid is the hash of just [nVersion][txins][txouts][nLockTime] which is the same as a serialized non-witness transaction. That means the signature is not included in the transaction hash, removing the potential for TXID malleability due to mauling the signature. Only WTXID contains the witness, marker and ...
4
The only right way of of doing this is generating a new address for every expected payment, and then waiting until you've received that amount on that address.
3
Some wallets have a function called something live "View on block explorer". For Electrum, you can see it if you right-click a transaction.
This will take you to a website on which you find your transaction ID. I drew a red ellipse around it so you know which number it is.
If your wallet doesn't have that functionality or you don't find it, simply copy the ...
3
Transaction order in the block
Currently, there are only two requirements for the order of transactions:
The coinbase transaction is always first.
Intra block dependencies must preceed, i.e. if Transaction A and Transaction B are both in the same block, and Transaction B spends outputs of Transaction A, A must be listed before B.
It is likely that in ...
3
The coinbase transaction contains a single input, which has txid set to 0000000000000000000000000000000000000000000000000000000000000000 and vout set to 0xFFFFFFFF.
3
In the console do listunspent
that will show you all the UTXO in your wallet including the txids.
You can type help to get a list of commands,
then help <command> to get details about each command
3
You've forgotten to convert from internal byte order (used in transactions to specify outpoints,) to output byte order (displayed to users.) Reverse the bytes after the second hash.
See also: How do I calculate the txid of this raw transaction?
The transaction you've included in your question and the transaction on the blockchain are slightly different. ...
3
Transactions do not have comments attached to them. Any comments are local to a person's wallet only. They are not broadcast to the network nor are they actually attached to a transaction. So you cannot find the message or comment that a person assigned to a transaction in their wallet.
3
Why didn't Bitcoin implement segwit in the first place?
The reason Bitcoin didn't initially have SegWit is up to interpretation, I would say that it simply was not thought of prior to transaction malleability. Although that is not its only goal. Segregated Witness was an idea proposed in BIP 141 as a soft-fork, meaning it did not require an entire network ...
3
The transaction ID is calculated by prepending the bytes 0x54, 0x58, 0x4e, 0x00 to the signed transaction and then taking the SHA512Half of this input.
Example for a signed transaction, bytes are represented as hex strings:
txBlob = "...
2
Just to expand on Jannes's answer: before including a transaction in a block, a miner does effectively check that all inputs to this transaction are already in this block or some previous block, as well as all inputs to those transactions, and so on recursively back to where the coins were created. In fact, every full node on the network performs this same ...
2
They don't have to be on the same block, but as they do depend on each other the BobD->Bob transaction can only be mined if Alice->BobD is already in the same or an earlier block. If not, the entire block would be invalid and noone would accept it.
Note that smart miners would add up the fees for both transactions and on the basis of that decide whether to ...
2
The transaction ID is the SHA256d(signedTransaction) = SHA256(SHA256(signedTransaction)). Sha256d is SHA256 applied two times.
Example:
Let us consider the transaction with ID 844c00ca065bc26eb61bfee203df2f7bcbc72a6bb77697a32d2a98dad5941109. The hex encoding of this transaction is:
...
2
Actually, nobody else can create a valid signature for your transaction inputs, as they do not possess the private keys to do so.
When a transaction is malleated by a third party, it is not re-signed, merely it's signature is changed. ECDSA signatures are malleable, in that taking the negative of number S (modulo the curve order) does not invalidate them. ...
2
decoderawtransaction in 0.14.2 has some issues with decoding segwit transactions. Sometimes it will decode segwit transactions as non-segwit. These should mostly be fixed in Bitcoin Core 0.15.0.
2
The TXID, the transaction ID, is a hash of the serialized (non-witness) transaction whose UTXO is being spent. It gets created at the same time as the transaction does
Only top voted, non community-wiki answers of a minimum length are eligible