Pages:

Author

Topic: Help a newbie; why is hashing not done once but twice during Bitcoin transaction - page 6. (Read 1615 times)

o_e_l_e_o

legendary

Activity: 2268

Merit: 18587

Quote from: larry_vw_1955 on April 13, 2022, 06:04:57 AM

Yeah on that particular block explorer, but not on blockchain.com. If you look at blockchain.com, you can see that block 91880 has the same timestamp as block 91722 for the coinbase transaction.

That's a fault of blockchain.com and has nothing to do with the bitcoin protocol. Blockchain.com assigns a timestamp to each transaction based on when they first saw that transaction in their mempool, which is why the duplicate second transaction has the same timestamp as the first transaction. The internal workings of blockchain.com are irrelevant to how the network treats these transactions.

Quote from: larry_vw_1955 on April 13, 2022, 06:04:57 AM

I think that would be the expectation of the general public who only has a passing knowledge of bitcoin from watching cnn. Their bank never has bugs that affect their account balance or if they do they get fixed so that no one loses any money...

I mean, people have literally gone to jail because of bugs in their bank accounts giving them money they shouldn't have received.

Quote from: larry_vw_1955 on April 13, 2022, 06:04:57 AM

Blockchain.com timestamps each transaction inside each block. Not every transaction has the same timestamp.

As above, this is when blockchain.com's node first learns of that transaction. This is not related to bitcoin at a protocol level.

Quote from: larry_vw_1955 on April 13, 2022, 06:04:57 AM

i would think by now with computer software and technology development being what it is, automated systems have taken over finding and fixing bugs.

You have some very unrealistic views on how software is developed.

larry_vw_1955

sr. member

Activity: 1036

Merit: 350

Quote from: o_e_l_e_o on April 12, 2022, 04:06:01 AM

Quote from: larry_vw_1955 on April 11, 2022, 10:08:44 PM

that's not what happened. what happened is, the first coinbase transaction was logged on to the blockchain but not the 2nd one. so that's how it happened.

They are both logged quite clearly.
Block 91722: https://mempool.space/block/00000000000271a2dc26e7667f8419f2e15416dc6955e5a6c6cdf3f2574dd08e
Block 91880: https://mempool.space/block/00000000000743f190a18c5577a3c2d2a1f610ae9601ac046a38084ccb7cd721
You can see the identical transaction twice, once in each block.

Yeah on that particular block explorer, but not on blockchain.com. If you look at blockchain.com, you can see that block 91880 has the same timestamp as block 91722 for the coinbase transaction.

Quote from: larry_vw_1955 on April 12, 2022, 02:53:13 AM

maybe in your view that's how it worked but by looking at the two coinbase transaction time stamps they go by the first one.

Transactions don't have timestamps. Blocks do.

Blockchain.com timestamps each transaction inside each block. Not every transaction has the same timestamp.

Quote

If the miner had been quick enough in the first case, then they could have indeed spent the 50 BTC from the first transaction before the second one came along. But they didn't. And since the 50 BTC from the first transaction didn't move, when they made a second transaction with an identical identifier, then the first 50 BTC output was effectively overwritten by the second one with the same identifier.

Blockchain.com retained the timestamp of the first coinbase transaction on the 2nd coinbase transaction. Now you might wonder how can a coinbase transaction be timestamped as 2010-11-14 03:37 when the block it is located in is timestamped 2010-11-14 19:36. Normally that could never happen the only way it can happen is if a previous utxo txid happened to match it so it used that one instead. Without going into the code though we can't really know for sure what happened,

Quote

i would think by now with computer software and technology development being what it is, automated systems have taken over finding and fixing bugs. if they would use that on bitcoin, it might help. maybe it's more complicated than that but i think it's a reasonable goal. what would be so hard about programming a system to find bugs like this duplicate transaction id?

pooya87

legendary

Activity: 3472

Merit: 10611

It is not just impossible because the bug was fixed but also because an additional check was added to the consensus critical code that would reject such blocks.
In simple terms even if by a miracle that happens once every million years you produce a SHA256 collision (in any tx not just the coinbase tx), and the other output with the same hash and index (the UTXO) was not spent yet, the block will be rejected as invalid.
https://github.com/bitcoin/bitcoin/blob/747cdf1d652d8587e9f2e3d4436c3ecdbf56d0a5/src/validation.cpp#L2133-L2140

o_e_l_e_o

legendary

Activity: 2268

Merit: 18587

Quote from: Lucius on April 12, 2022, 09:26:22 AM

If it were possible to reproduce something similar, perhaps it might occur to someone to reduce the max supply a little more - or is it technically impossible to do so after a fix?

It is impossible to reproduce the same bug again, as this is prevented by both BIP30 and BIP34. Are there other bugs out there we are unaware of which could permanently remove some bitcoin from the supply? Most likely.

In addition to that, any miner can choose to remove coins from the supply any time they find a block by not claiming the full block reward they are permitted to claim. This has happened many times in the past, usually for small sums of a few thousand sats or a few mBTC, but occasionally for much larger sums. Block 501,726, for example, permanently destroyed 12.5 BTC by falling to claim anything in the coinbase transaction.

Lucius

legendary

Activity: 3234

Merit: 5637

Blackjack.fun-Free Raffle-Join&Win $50🎲

Very interesting topic, so even though I'm not technically savvy to discuss at this level, how much have I realized what happened in the past shouldn't happen anymore? What interests me is whether it is theoretically possible for such events to happen again, because if I understood correctly these two coinbase transactions with identical IDs actually annulled each other and we have 100 BTC less.

If it were possible to reproduce something similar, perhaps it might occur to someone to reduce the max supply a little more - or is it technically impossible to do so after a fix?

pooya87

legendary

Activity: 3472

Merit: 10611

Quote from: larry_vw_1955 on April 12, 2022, 02:53:13 AM

what do you mean it first had to be detected? with all the intellectually powerful people in bitcoin, you would think that one would be a gimme. and they would have saw it coming a mile a way but i guess not. an inflation bug is one thing but something like this. satoshi should have realized that could happen. suprised it didn't happen to him as many blocks as he mined!

If you some day develop a software you realize how easy it is to have all kinds of bugs, from simple silly ones to big fundamental bugs.

Quote from: o_e_l_e_o on April 12, 2022, 04:06:01 AM

Quote from: larry_vw_1955 on April 12, 2022, 02:53:13 AM

maybe in your view that's how it worked but by looking at the two coinbase transaction time stamps they go by the first one.

Transactions don't have timestamps. Blocks do.

Coinbase transactions have something that would resemble that. They need to mature before they can be spent (100 block deep).

As far as I can tell from the code, the UTXO will be replaced by the new one so the block height of the coinbase tx has to also be updated which would make it unspendable until another 100 blocks are mined.
I'm not confident in my understanding of C++ though.

o_e_l_e_o

legendary

Activity: 2268

Merit: 18587

Quote from: larry_vw_1955 on April 11, 2022, 10:08:44 PM

that's not what happened. what happened is, the first coinbase transaction was logged on to the blockchain but not the 2nd one. so that's how it happened.

Quote from: larry_vw_1955 on April 12, 2022, 02:53:13 AM

You expect the bitcoin protocol and software to never have any bugs whatsoever? That's a completely unreasonable expectation.

Quote from: larry_vw_1955 on April 12, 2022, 02:53:13 AM

maybe in your view that's how it worked but by looking at the two coinbase transaction time stamps they go by the first one.

Transactions don't have timestamps. Blocks do.

Quote from: larry_vw_1955 on April 12, 2022, 02:53:13 AM

if you don't believe that then how do you expain the scenario of if the miner spent his 50 btc before the 2nd coinbase transaction came along?

larry_vw_1955

sr. member

Activity: 1036

Merit: 350

Quote from: pooya87 on April 12, 2022, 12:52:49 AM

Quote from: larry_vw_1955 on April 11, 2022, 10:08:44 PM

and no one said anything about it or noticed it was possible?

It first had to be detected. When it did, BIP30 was created.

Quote

Nothing is being overwritten in the blockchain.

Looking at the time stamp of the coinbase transaction proves that. Nothing got overwritten.

Quote

The blockchain is immutable and can not change. What happens is that the first transaction's output was placed in UTXO set after it was created, then the second one came along and replaced it in the UTXO set.

how exactly does that happen?

Quote

So if the second one is spent, it will be removed from the set and the first one that was already replaced no longer exists in the UTXO set to be spent.

maybe in your view that's how it worked but by looking at the two coinbase transaction time stamps they go by the first one. so it's like the 2nd coinbase transaction never existed. if you don't believe that then how do you expain the scenario of if the miner spent his 50 btc before the 2nd coinbase transaction came along? you can't. unless you agree that the 2nd coinbase transaction was just ignored when it saw that a transaction id already existed with the same id. you can't go back and alter the blockchain so...

pooya87

legendary

Activity: 3472

Merit: 10611

Quote from: larry_vw_1955 on April 11, 2022, 10:08:44 PM

and no one said anything about it or noticed it was possible?

It first had to be detected. When it did, BIP30 was created.

Quote

that's not what happened. what happened is, the first coinbase transaction was logged on to the blockchain but not the 2nd one. so that's how it happened.

if a transaction got overwritten then what the miner could have done is spend his 50btc and then get another 50btc reward when his first coinbase transaction got overwritten. not what happened though. there was no 2nd coinbase transaction and you can't see it anywhere.

Nothing is being overwritten in the blockchain. The blockchain is immutable and can not change. What happens is that the first transaction's output was placed in UTXO set after it was created, then the second one came along and replaced it in the UTXO set. So if the second one is spent, it will be removed from the set and the first one that was already replaced no longer exists in the UTXO set to be spent.

odolvlobo

legendary

Activity: 4354

Merit: 3260

Quote from: NdaMk on April 10, 2022, 09:16:32 AM

Thank you all for your contributions.
The other unanswered question is that if an hexadecimal string is inputted to the hash function due to forgetfulness will it accept it? and will there be a difference to the result since the function requires the string in bytes?

It depends on the tool used for hashing. Binary and hex are just different representations and the tool may or may not convert the input to the desired representation.

There are many possibilities. For example, the tool may detect a hex string and convert it to binary data before hashing, or it may expect binary data and hash the string regardless of what it contains, or it may expect a hex string and be unable to hash binary data because it would be invalid hex.

larry_vw_1955

sr. member

Activity: 1036

Merit: 350

Quote from: pooya87 on April 11, 2022, 01:55:04 AM

This is NOT a collision, these are same EXACT transactions that produce the same EXACT hash.

thats strange.

Quote

It used to be possible because coinbase script didn't have to include the block height so 2 coinbase transactions would have same inputs and everything else (version, locktime, intput/output count, output) could be also similar hence producing the same exact transaction with same exact hash.

and no one said anything about it or noticed it was possible?

Quote

But now after BIP34 activation, all coinbase transactions must contain the block height which makes it impossible to produce same hash since finding a SHA256 collision is impossible.

so they squashed another bug. hopefully there's no more of those...

Quote

They've overwritten a transaction, not the blockchain. Both transactions are still easily visible on the blockchain.

LoyceV

legendary

Activity: 3290

Merit: 16489

Thick-Skinned Gang Leader and Golden Feather 2021

Quote from: PX-Z on April 09, 2022, 03:10:08 PM

Bitcoin already has +700 millions transactions^[1] since then yet there's no single case of the same txid happened (someone correct me if im wrong).

Let's put this to the test: I took Bitcoin block data (665 GB): inputs, outputs and transactions, and extracted all txids from all "outputs" blocks. This gave 724,446,069 transactions (data up to April 9, 2022). As expected, there were only 2 duplicates:

Code:

d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599
e3bf3d07d4b0375638d5f1db5255fe07ba2c4cb067cd81b84ee974b6585fb468

I wanted to post this yesterday, but processing the data took longer.

o_e_l_e_o

legendary

Activity: 2268

Merit: 18587

Quote from: larry_vw_1955 on April 11, 2022, 12:51:41 AM

from just looking at the blockchain how would you know which miner got the 50btc reward since the coinbase transaction is dated by the first transaction not the second. but one thing is for sure, someone lost 50btc.

Considering either one of the pairs of transactions being discussed, there are not two miners - it is the same miner mining both blocks and costing themselves 50 BTC. The transactions are identical in both cases, and they pay the same 50 BTC to the same address.

Quote from: larry_vw_1955 on April 11, 2022, 12:51:41 AM

overwriting the blockchain is a very serious bug.

They've overwritten a transaction, not the blockchain. Both transactions are still easily visible on the blockchain.

As discussed above, this was a bug in how transactions were created which has been long fixed, and has nothing to do with SHA256 being broken.

LoyceV

legendary

Activity: 3290

Merit: 16489

Thick-Skinned Gang Leader and Golden Feather 2021

Quote from: larry_vw_1955 on April 11, 2022, 12:51:41 AM

people always say there is no known collision with sha256 but i guess they are keeping this matter secret so as not to alarm anyone.
not one but 2 collisions. sha256 is broken for sure if it's already happened twice.

I took a sha256sum of the above text:
34da38ff7f462890cc5b6b950db52dc97c8d80f7364075fdec91077f34c3ea50
Wait, let me do it again:
34da38ff7f462890cc5b6b950db52dc97c8d80f7364075fdec91077f34c3ea50
It's the same Cheesy

That doesn't mean sha256sum is broken, it means it does exactly what it's supposed to do. If you can get the same hash from a different input, then you can call it broken.

pooya87

legendary

Activity: 3472

Merit: 10611

Quote from: larry_vw_1955 on April 11, 2022, 12:51:41 AM

This is NOT a collision, these are same EXACT transactions that produce the same EXACT hash.

It used to be possible because coinbase script didn't have to include the block height so 2 coinbase transactions would have same inputs and everything else (version, locktime, intput/output count, output) could be also similar hence producing the same exact transaction with same exact hash.
But now after BIP34 activation, all coinbase transactions must contain the block height which makes it impossible to produce same hash since finding a SHA256 collision is impossible.

larry_vw_1955

sr. member

Activity: 1036

Merit: 350

Quote from: o_e_l_e_o on April 10, 2022, 02:11:47 PM

When you create a bitcoin transaction, you reference the UTXOs you want to use as inputs based on the transaction ID of the transaction which created those UTXOs. Considering one of the pairs listed above, then since those transactions have identical transaction IDs, then there is no way for you to reference them separately. The second transaction therefore effectively overwrote the first one. As far as the blockchain is concerned, there is only one output of 50 BTC in each case. So given that it has happened twice, 100 BTC has been destroyed permanently.

i don't know about that. from just looking at the blockchain how would you know which miner got the 50btc reward since the coinbase transaction is dated by the first transaction not the second. but one thing is for sure, someone lost 50btc. overwriting the blockchain is a very serious bug. too bad 2 people had to pay the price for that. one of the miners got deleted out of existence in each pair of transactions. i'm sure they wondered what the heck just happened. very serious bug!

BlackHatCoiner

legendary

Activity: 1512

Merit: 7340

Farewell, Leo

Quote from: NdaMk on April 09, 2022, 06:04:51 PM

What happens when one forgets to change the strings in hexadecimal to its respective bytes, will the result still be the same

No.

The hash of a string is different than the hash of the bytes of the string. As you said, hash function takes the input in binary format. If you hash the hex "abcdef", you'll get:

Code:

Hex: abcdef
Bin: 101010111100110111101111
SHA256: 995da3cf545787d65f9ced52674e92ee8171c87c7a4008aa4349ec47d21609a7

Respectively, to hash the string "abcdef" you'll have to convert it first to binary.

Code:

UTF-8: abcdef
Hex: 616263646566
Bin: 011000010110001001100011011001000110010101100110
SHA256: bef57ec7f53a6d40beb640a780a639c83bc29ac8a9816f1fc6c5c6dcd93c4721

o_e_l_e_o

legendary

Activity: 2268

Merit: 18587

Quote from: hosseinimr93 on April 10, 2022, 08:08:45 AM

Quote from: LoyceV on April 10, 2022, 07:44:54 AM

Does this mean the 50 Bitcoin created by the second transaction basically don't exist?

Both blocks are valid and both transactions exist in the blockchain.
The blocks number 91842 and 91880 were considered as exceptions and bitcoins generated in them should be spendable.

The combination of these two duplicate transactions has effectively removed 100 BTC from the supply permanently.

When you create a bitcoin transaction, you reference the UTXOs you want to use as inputs based on the transaction ID of the transaction which created those UTXOs. Considering one of the pairs listed above, then since those transactions have identical transaction IDs, then there is no way for you to reference them separately. The second transaction therefore effectively overwrote the first one. As far as the blockchain is concerned, there is only one output of 50 BTC in each case. So given that it has happened twice, 100 BTC has been destroyed permanently.

NdaMk

full member

Activity: 303

Merit: 136

Defend Bitcoin and its PoW: bitcoincleanup.com

hosseinimr93

legendary

Activity: 2380

Merit: 5213

Quote from: LoyceV on April 10, 2022, 07:44:54 AM

Does this mean the 50 Bitcoin created by the second transaction basically don't exist?

Both blocks are valid and both transactions exist in the blockchain.
The blocks number 91842 and 91880 were considered as exceptions and bitcoins generated in them should be spendable.

Visit the link below for more information.
Apply BIP30 checks to all blocks except the two historic violations.