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

Agreed.  

I think it's fair enough to question though.
With any hashing function, you lose information and risk an increased number of collisions. If you hash twice, you risk more collisions from what I understand. This is a risk - but we agree that this is an acceptable risk so that we can sign transactions, as long as we start off with enough random information.

The risk that Satoshi really played with here though is the long term building of a currency based off of this.
I mean, fair enough, if you want to use methods like this for your one off encrypted projects, your personal project, your messenger services, or even your large corporations. Most of these are personal and don't require long term security that a currency needs - which has to be resilient to both change and attacks. Most of these don't involve multi-billion dollar risks if it's broken, or have the ability to adapt over time to changing technology. Bitcoin needs to be set as a protocol and have long term resilience unless you want to force everyone to transact their entire life savings frequently (which you don't). I think it was a risk for Satoshi to have played with the double hash due to this need for longevity, although that risk was clearly much less by the larger risk of a single hash. (Risks everywhere? The benefit of hindsight..) That the double hash has worked for 20 years generally (edit: I guess longer, actually!) and 13 years in bitcoin is a credit to it, but, man, the difference between a few years isn't that much for something hoped to last decades or longer. The longevity of the double hash was still an unknown, even if it was better in theory. There are several other things that have been broken and fixed over time in bitcoin that I'm surprised as a novice at how resilient the double hash has been.

I was responding more to why it wasn't discussed in the early forum. You had varying degrees of understanding. The first few forum members still seemed to be wrapping their head about the basics without going into detail about much more complicated topics. The very few people who had been working with Satoshi pre-forum and later more serious developers like Andresen had probably already thought about it or looked things like that up quickly. So I agree with you, they didn't need to discuss it. I also think things may not always have been openly discussed when they present possible flaws, because you have groups that want to patch before exploitation or to use those exploits for their own greed - the double hash might have been caught up into a phenomenon like that even if it never had that weakness. So there are several reasons why it wasn't discussed.

The nonce is only 4 bytes, meaning a total of 4.3 billion possibilities. Miners can exhaust this search space in under a second. They need to be able to change other things in the block in addition to the nonce. The timestamp is one such option for them, alongside extraNonce, which transactions they include, and the order of those transactions.

Blockchain.com is not a reputable company. I would not even use their products, let alone attach any degree of authority to them.

But this becomes trivial to fake, since a signed transaction can be not broadcasted for any length of time. I could easy sign and broadcast a transaction with a timestamp of 5 years ago to gain beneficial tax treatment. As far as most governments are concerned, the transaction occurs when it was confirmed. Usually the time between a transaction being broadcast and being confirmed is a few hours at most, so irrelevant from a tax point of view.

Or just that length extension attacks and protection against them using double hashing was already a well know thing that nobody bothered asking about it! For example in chapter 6.3.1 of the book Practical Cryptography published in 2003 (Bitcoin was released in 2008) it explains that a countermeasure against such attacks is to compute SHA-X(SHA-X(m)) where X is 1, 256, 384 or 512.
HMACSHA functions also use the same principle to solve the length extension attacks which is a problem in MACs not so much in simple hashes.

Oooo.
You hit the nail on the head there.
I'm going to guess that it wasn't discussed when Satoshi was around for two reasons: 1) It was implicit. Satoshi didn't explain a lot of what he did unless questioned on it. Length extension attack would have been an obvious vector if he had played with it. Besides, questioning all potential flaws publicly in a developing system might cause people to try to break it before you can secure it, when you prefer to keep testing its resilience privately. 2) Either the users were still developing and didn't have enough understanding of the code and mathematics to question it, or understood your reason as the reason. There was nothing to question for the last group.

Thus, it never came up.

Even if a transaction had a timestamp, you could fake that, too. There is nothing that could ensure that a block's and transaction's timestamps are accurate. Remember that it can take days for a transaction to be included in a block, it can take minutes for a block to propagate, and node times are not synchronized.

I doubt it, especially if internal use refer to small-medium or non-profit company.


It's valid example, although the scale between developing smart contract and complex application/OS is very different.


Adding timestamp to transaction require soft/hard fork, so you need to convince Bitcoin community instead. Although it's different case if it's opt-in where you simply utilize OP_RETURN.

It's meant to establish the difficulty. As said, there's a range they're allowed to manipulate, which doesn't affect the adjustment by a lot. You cannot avoid this limit; otherwise they'll perpetually sacrifice computational power for blocks that aren't complied with your rules.

The nonce is just a number used once by miners on their way to find a valid block hash. Check: Nonce.

Yes, but that has a point only in trust-based systems. In Bitcoin, that works asynchronously, you can't know when blockchain dot com's node received the transaction or when you did. When it gets confirmed, your running node will immediately receive it, but one who's syncing won't have it yet. If the signer can set the timestamp, which doesn't make sense, you can't know if it's faked.

well i see what you mean but it is still counterintuitive to see it happening. is that what the timestamp was really meant for is something that miners could manipulate for their own purposes? i thought thats what the nonce was for.



I don't know. I just thought they were.

Well i can think of alot of reason why a timestamp on a transaction is helpful. Every transaction in e-commerce uses timestamps. Without an accurate timestamp on your transaction how do you properly convince a tax authority exactly when a transaction occurred? You can't. All you can do is point to the block timestamp but what if that's not the same as when you actually submitted the transaction and it affects you negatively? Did you ever buy anything from amazon and not see a timestamp on your transaction?

Well whoever that was didn't have e-commerce in mind.


But you can stuff anything you want to in OP_RETURN. Including fake timestamp.

well it's a nice feature to be able to see when a transaction was done. maybe they should add that to the protocol. everything should have a timestamp i would think. or some way of deciding the ordering of objects in time. even down to the transaction level. if blockchain.com can do it why can't bitcoin?