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

I don't see how this solves the problem. You broadcast your transaction first to the timestamp network, and have to wait for it to be confirmed for it to receive a timestamp, and then broadcast it a second time to the bitcoin network. There is still a time delay between broadcast and confirmation, except it is on the timestamped network instead of the bitcoin network. Plus then there is a further delay while you broadcast the transaction a second time and wait for confirmation.

And who is running this second chain? What is their incentive to do so? Do I have to pay double the fees for my transaction?

Long before we reach the stage where transactions are vulnerable to quantum computers solving the ECDSA in the ~10 minutes it takes for the transaction to confirm, we will have forked to a quantum resistant algorithm, otherwise every coin in a reused address (which number several million) would have long been stolen.

Off the top of my head, these two things would break 1) the ability for miners to choose whether to mine higher fee transactions over smaller fee transactions and 2) the replace-by-fee ability of users.

If you could come up with a perfect timestamp server solution, you could create a new kind of cryptocurrency rather than relying on bitcoin and its derivatives. Not being able to trust the perfect timing of any event is at the heart of bitcoin. I currently doubt that a perfect-timestamped currency is possible while being trustless.

But yes, you could have transactions timestamped and saved now in the blockchain like in the OP_RETURN field without core protocol changes. I maintain my previous position about whether you could ever trust those timestamps. You would also need to come up with a trustless timestamp server, otherwise this would break. I don't agree that all things need perfect timing -- look at "Activity" on this forum. It updates every ten minutes. This prevents all sorts of flaws (like ddos) that would occur if it updated immediately, but ten minutes is still fast enough to be useful.

But I was thinking you could have a separate blockchain that served as a timestamp server. When/if someone on bitcoin wanted to timestamp their transaction they have to submit it to to the timeserver first to get it timestamped. Then they can submit the timestamped transaction to the bitcoin network. Bitcoin network verifies that the transaction is valid according to normal consensus rules AND it verifies the timestamp is valid by consulting the timestamp server.

And then lets say a quantum computer was trying to look at pending transactions in the mempool to try and find public keys to crack. It would not be able to do anything with the mempool transactions which contained valid timestamps. Such transactions would be impossible to replace as they would stay in the mempool until confirmed.

a few small modifications on the bitcoin side but not alot. And the use of the timestamp server would of course be optional.

Miners very commonly use the extraNonce field to reset the nonce, which suffers from the exact same problem. With the coinbase transaction being the first in the block, it is the left most node at the bottom level of the Merkle tree, so all the hashes running up that left side need to be redone. Even in a block with up to 4,096 transactions, that's only 12 hashes. Swapping the order of two transactions, while not commonly used, would be the exact same number of hashes if you swapped transactions next to each other.

Changing the order of transactions in a block could be computationaly "expensive" for miners, because you need to recompute the merkle tree hashes to some amount, depending on the position of the changed transactions in the merkle tree, where the merkle tree hash contributes to the block header. Miners very likely choose the least expensive way to reset the nonce for further needed hash crunching.


In the timestamp discussion one should also keep in mind what user/miner supplied data you can trust. Bitcoin is trustless by design, it doesn't make sense to expect data from users or nodes like transaction timestamps whoes trust level is unknown or nonexistant. It's a good and wise decission to leave out details which you can't trust or where it complicates things to unknown extend to make the data trustworthy. Keep it simple...

The irony is that adding a timestamp on first transaction would make your knowledge of transaction timestamps LESS reliable by slowing down propagation to all nodes.

I guarantee that if a timestamp was added on first node that there would be services that popped up to delay transactions. You could try to sign a transaction with something from a dedicated time server, but even then, there's nothing that would stop a transaction from being signed very early but sent later.

You have to run your own node to capture this information as accurately as possible. You might even get a group of nodes to coordinate to timestamp things better. (What's the difference? ::shrug:: )

But changing anything about the block allows you to reset the nonce (and effectively also the timestamp, giving you another 2+ hours to work through). There is the entire extraNonce field that miners can change, but also even something a simple as changing the order of the transactions they include (never mind including different transactions), will let you reset the nonce. In a block with 1000 transactions, there are 1000! different ways to order them, which is something in the order of 2⁸⁵²⁹ possibilities, far in excess of anything that will ever be needed. In reality, most miners use the extraNonce field and don't bother adjusting the timestamp at all.

Which makes it trivial to fake. "Oh hey, I saw this transaction two weeks ago but my node has been offline since then."

You are now adding additional size to every transaction, thereby increasing fees, decreasing block space, and increase transaction time, as well as adding additional verification requirements for every transaction at every node, which will again slow things down, delay propagation, increase stale blocks, and so on. There are a lot of downsides to doing this. There would need to be a very good reason or major benefit to such a feature.

Maybe but maybe Satoshi wasn't sure how many megahash some hardware might eventually get up to. Thus, it might burn through nonces and timestamps much faster than "real time". So it might need to go out to 2 hours in the future to get a valid hash, if the difficulty was high enough.

no particular analytics but i just thought it's nice if the network can agree on when a transaction was first seen and put that as the timestamp of the transaction inside the block.

Just the node that first received the transaction once it had been submitted to the network. Is all I was thinking. Whether it takes 1 minute or 1 week to get mined is another story but there could be a second timestamp for that perhaps. And that's it.

Yeah I don't know about that. They would need a consensus mechanism to agree on something like that.

There would have to be some type of cryptographic protocol to validate timestamps.

not sure if there are. maybe solana but i'm not sure.

it is impressive.

So you're saying it is impossible to make "when a transaction was first seen" be a well defined concept in a decentralized network such as bitcoin that uses proof of work. without a major overhaul i think i would have to agree.

Because, again, the timestamp does not determine order. It needs to be roughly accurate to allow difficulty retargeting, that's all. If you enforce a limit of 1 second, then you are going to end up with a huge number of rejected blocks due to network latency, syncing issues, verification time, etc.

And if the whole network depends on that one website, then bitcoin is now centralized and can be shutdown by a single person taking that site offline.

Then run your own node and keep a database of whenever you first see every transaction and every block. Your timings will be unique when compared to every other node. It doesn't make sense to take about when a transaction was first seen in a decentralized network, since every node will see it at a different time.

That would add terrible centralization to the Bitcoin protocol! Satoshi's implementation of "2 hours" has worked fine so far, and given the fact that some miners use a different time stamp: it is needed! By basing the time on previous blocks, it becomes a more or less decentralized average of the time used by other miners. All miners can know for sure from the previous blocks that their time is correct to be accepted. If only a one second difference would be allowed, you'll get the situation in which some miners think it's okay, while others reject the block.

Part of this may be historical in that Satoshi didn't know whether computers would be connected continuously to start. But another part is this:

Enforced timestamps from those transacting, nodes, and miners would require extra space in the blockchain on all transactions. Those timestamps may not be trustworthy. And privacy would disappear due to all sorts of fingerprinting. Is it safe to assume that you would want it for analytics of some sort?

Also, how many nodes' timestamps should you include? Just the first one, or all that a transaction reaches before being mined? How do you put those in the blockchain so that people can access them? How can a node know whether it had reached another computer first? What if a malicious node started to modify these after the previous node? If it was enforced to timestamp on first node entry, this would enable targeting of specific nodes through spam transactions, and possibly allow methods to target processor speed, location, user hours, and more. It just seems like bad mojo and would enable identifying people, and would further enable the targeting of those individuals.

I'm sure there are ways, but whether those would be peer to peer currencies or people would be willing to invest in them is another matter. I'd bet that there are blockchains that do this.

As Loyce points out below just now, enforcing this would be another problem. Imagine if your DNS or ISP forces you to use a different time stamp server unbeknownst to you, thereby kicking you off from processing transactions. If bitcoin increases globally, that would be a major vector to stop users from being able to mine because they couldn't be within a stringent time stamp protocol. Sure, we have time services like this now, and it's unlikely that such a service would go down within the next 50 years, but what if it did? What if the country that offers a time service ends up being sanctioned, and everything else goes down because of it?
-
e: Like what oleo below wrote: If you really want it, you could keep of when all transactions are submitted now. Just capture and timestamp everything in the mempool. For more accuracy, you will have to run enough nodes that can capture transmitted transactions from all other nodes in time, and then timestamp and store when these transactions occur.
e2: Also, there is already a timestamp of whenever transactions occur, just not within a fast temporal resolution, but still an impressive feat for a continuous 13 year period that anyone can verify.

Yeah I can see the reason for allowing the timestamp to increment by 1 second. But it shouldn't be allowed to go up by 2 hours into the future. that wouldn't make any sense why that would be necessary.

well there's always a cost for convenience. in this case, for having an online bitcoin wallet you expose yourself to that type of issue. not sure what to tell someone that would put alot of money into an online wallet like that.

Even now? to be fair, alot of bitcoin wallets never supported segwit to begin with and many of them took a long time to add that support in. probably some of them still only support legacy addresses. Vendors were slow to adopt changes to bitcoin. I think that's a recurring theme.

ok but what about this then: https://timegov.boulder.nist.gov/
why do you think services like that exist? so that computers can coordinate their clock and agree on an official time.

Why would you not want one? One of the most basic things you can ask about something is when it happened. When did it get submitted. When did it get confirmed. Maybe I want to know all of that.

Need a way to ensure compliance. There has to be a way to force everyones clock to be in agreement. But no one seems to have any idea.

Why would you want a timestamp? You can't trust it completely. What happens if a node decides to change its computers time to a few minutes in the future or past to argue that its transactions came first, or never happened in time? Using a timestamp beyond the locktime already there only creates confusion.

There's already locktime if a transaction wants to include that.
The various miners agree on an average time and accept only blocks within a limit of that time.


It's best to leave a timestamp out for when a transaction first hits a node as it would lead to an inaccurate understanding, possibly cause fingerprinting, and then cause gaming of the system if ever used for anything important. The whole point of bitcoin is that it solves the byzantine problem, which is that you can't trust what any single node is saying about something as silly as a timestamp. You might even begin to reject transactions that are submitted to certain nodes that had latency issues that day, which would be unstable for users.

Let's say you use a timestamp for anything important. How would you game it?
Even if all computers had exactly the right time, corrected for network/speed of communication differences. You could submit the same transaction at two different nodes with vastly different latency, like in different parts of the world. Now what are you going to do with the timestamp? If you argue one came before the other, perhaps to cause a lawsuit about ownership, then you could never prove that fully, and you've now confused a non-technical jury.  

Because it doesn't need to be any bigger. Every time you change anything about the block, then you change the block header and reset the nonce field. Why have a 32 byte nonce when you could only search a tiny fraction of it before incrementing the timestamp by 1 second and starting again? It's just more unnecessary bloat.

I mean, not just issues, but critical vulnerabilities such as reusing k values and resulting in people losing their coins. Their block explorer also took literally years to start recognizing segwit addresses, and again spent years incorrectly reporting fees in sats per raw byte, when the network had long moved on. They are insecure and outdated.

Bitcoin measures things based on a cryptographic order. This cannot be spoofed, cannot be faked, cannot go out of sync. Timestamps are not accurate in a distributed database.

And if you trade on a centralized exchange then you'll get that. It's still irrelevant for the network, though.

Then whats the purpose of the nonce in the first place if it's not sufficient in size to be able to generate a hash lower than the difficulty? Don't you think that if bitcoin was designed properly, it could fulfill that role without having to spill over and start modifying things whose purpose has nothing to do with the nonce.

Well that's a naive question given the framework of bitcoin. It's like asking "suppose I give you a transaction but suppose there is no blockchain to looks things up, how do you know it's valid? you could have just made it up".


time is a fundamental quantity of physics. it is natural to measure things using time. but yeah bitcoin cant do that. i agree.

blocks serve as a rough timestamp for transactions but that's all. if you want to know anymore than that, you can't. but it seems like timestamps are not so irrelevant. for example say you are a daytrader trading in the stock market. your trades are timestamped down to the millisecond i bet. so if there is any discrepancies, they can research the transaction. without knowing when it occured exactly they can't understand what happened. and then there is the possibility for fraud.

It sounds like I wasn't too far off with disagreements already here.

The assumption comes from the reduction from the range of bitcoin addresses where the space of 2^256 bitcoin keys available  hash into 2^160ish addresses, increasing collision chances - though not enough to care. (If we mapped a space of 2^256 keys to a space of 2^256 addresses, then it's better called encrypting and not hashing.) MD5 is the other counter-example where hashing causes flaws, but I guess we should leave bad hashes out of this discussion!

Point taken though, I had not thought of key strengthening by adding computational steps against rainbow table/dictionary attacks by stringing multiple hashes together, particularly ones that cause hash lengthening. I found this useful article on it: https://stackoverflow.com/questions/348109/is-double-hashing-a-password-less-secure-than-just-hashing-it-once/17396367#17396367

Multiple hashing would add security against a dictionary, but not against all brute-force. A brute-forced preimage only depends on the last hash step when there is no key lengthening (or if its input has a larger/equal range than the outputs). If the last step breaks then, it doesn't matter what hashes were done before in a brute-force attack.

This article was useful to me:
https://bitcoin.stackexchange.com/questions/9202/why-does-bitcoin-use-two-hash-functions-sha-256-and-ripemd-160-to-create-an-ad

This person suggests that the double hash prevents length extension, although the next person vehemently disagrees that the double hash benefits at all!
https://bitcoin.stackexchange.com/a/9203

Most e-commerce would give you digital receipt including when the payment received/confirmed. Besides, as @odolvlobo said it wouldn't accurate anyway. There's also scenario where you make signed transaction in advance and broadcast when it's needed.


True, but your option is quite limited when the community don't wish for such feature.

"The network" is not a single entity. It is a collection of nodes. Let's say I put a timestamp on a transaction and broadcast it to you. How can you trust my timestamp? How do you know I didn't just timestamp it 10 minutes in the past? It is trivial to fake.

If a feature has no applications, then it is not worth the extra bloat it will bring.

Why? Transactions are confirmed in blocks, and blocks are ordered right back to the genesis block. Timestamps are irrelevant.

More hashes are calculated so it's reasonable to make this conclusion, but it's actually the opposite when it comes to the effort. It doesn't matter if you've hashed the transaction a million times; only the last hash is the one that's taken into the database. But, those who'll try to find collision will have to go through the previous hashes, which means more effort for the same result.

So, I'd say the more the hashes, the more the odds to find a collision for a random hash, but the less the incentive to do so.

Essentially, it does. The timestamp server is the ledger and users rely on proof of work instead of the signer or in any authority.

As said, there's no way to ensure the time during the submission without introducing trust.

Can't you just let the network put a timestamp on it? It seem like such a simple thing to know what time each transaction occurred at least accurate to the second. But then you run into the problem of how do you put a timestamp on to a transaction, at exactly what point do you stamp it? I guess when it is first submitted to the network, first seen. The block timestamp would be the secondary timestamp to let you how long it took from submission to confirmation.

Right. People doesn't always realize why they need a particular feature until they can see some of the applications of it. But I think we could agree that if every transaction had a meaningul timestamp, that would make bitcoin more powerful.


that's correct. it essentially doubles the risk of a collision.