Pages:
Author

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

sr. member
Activity: 1036
Merit: 350

One problem with timestamping a transaction *when its broadcasted* is that it won't be cryptographically protected by the signature. Therefore, it can be changed by anyone during transit and yet the tx still verifies correctly.

you timestamp it and then sign it. then the timestamp is part of the signature. that tells you when the transaction was created. then once it is broadcasted, it is timestamped again and then signed again by the network. that's one idea.

Quote
Besides, I could broadcast a tx multiple times in quick succession, would the timestamp of the broadcast be updated or a new one added to the end of the array. Would that really be necessary, keeping track of a timestamp that could be modified/updated infinitely, when the tx can only be signed/created once and thus can be used as the timestamp?
i think transactions with an earlier timestamp might get put into a block first. before later transactions. when you can timestamp things you can put them in the order they occurred. now obviously bitcoin can't do that but if something could then ordering things by when they occurred would eliminate the need for blocks. maybe?
legendary
Activity: 1568
Merit: 6660
bitcoincleanup.com / bitmixlist.org
Quote
Why not? What mechanism exists in an automatic clock that can possibly dictate how I sign a bitcoin transaction?
No mechanism does. You have to layer that additional functionality on top of the atomic clock or alongside it. now I'm not going to sit here and say that solution is easy or I know what it is fully. but i do have an idea on it.

One problem with timestamping a transaction *when its broadcasted* is that it won't be cryptographically protected by the signature. Therefore, it can be changed by anyone during transit and yet the tx still verifies correctly.

Besides, I could broadcast a tx multiple times in quick succession, would the timestamp of the broadcast be updated or a new one added to the end of the array. Would that really be necessary, keeping track of a timestamp that could be modified/updated infinitely, when the tx can only be signed/created once and thus can be used as the timestamp?
sr. member
Activity: 1036
Merit: 350

If you have a solution to this problem, then you should post it...
Well I didn't say I had a solution but I had some ideas but I came across one that I think could work. It's called Cosmic Time Synchronization.

You can read about it if you're interested.



sr. member
Activity: 333
Merit: 506
Quote
Not at all. There is no point arguing for a change if that change serves no good purpose.
I could probably come up with many examples but how about this one. You could reduce energy consumption in proof of work and it would remain as secure as it is now. And as decentralized as it is now.
Without any details of how you would implement this, you cannot make any of these claims. I could just as easily say that timestamps will increase energy consumption and be less secure.

If you have a solution to this problem, then you should post it...
Quote
Why not? What mechanism exists in an automatic clock that can possibly dictate how I sign a bitcoin transaction?
No mechanism does. You have to layer that additional functionality on top of the atomic clock or alongside it. now I'm not going to sit here and say that solution is easy or I know what it is fully. but i do have an idea on it.
sr. member
Activity: 1036
Merit: 350
An atomic clock is not some kind of magical device that can prevent fraud. All it does is very accurately measure time. There is no mechanism in an atomic clock which prevents me from signing a bitcoin transaction with a different time than what it currently displays.
that is certainly correct.


Quote
Why not? What mechanism exists in an automatic clock that can possibly dictate how I sign a bitcoin transaction?
No mechanism does. You have to layer that additional functionality on top of the atomic clock or alongside it. now I'm not going to sit here and say that solution is easy or I know what it is fully. but i do have an idea on it.

Quote
Not at all. There is no point arguing for a change if that change serves no good purpose.
I could probably come up with many examples but how about this one. You could reduce energy consumption in proof of work and it would remain as secure as it is now. And as decentralized as it is now.


Quote
Running a node is trivially easy. Just download, install, and run. Far easier than trying to fork the entire protocol for some change which isn't needed and wouldn't work.
ok.
legendary
Activity: 2268
Merit: 18587
An atomic clock is not some kind of magical device that can prevent fraud. All it does is very accurately measure time. There is no mechanism in an atomic clock which prevents me from signing a bitcoin transaction with a different time than what it currently displays.

an atomic clock is not going to let you backdate a transaction. it can only timestamp something with the current time.
Why not? What mechanism exists in an automatic clock that can possibly dictate how I sign a bitcoin transaction?

separate topic
Not at all. There is no point arguing for a change if that change serves no good purpose.

why would i want to be tasked with that chore when a better solution exists?
Running a node is trivially easy. Just download, install, and run. Far easier than trying to fork the entire protocol for some change which isn't needed and wouldn't work.
sr. member
Activity: 1036
Merit: 350
I could timestamp my transaction yesterday or last year and you have no way of proving when I actually signed it. Syncing up atomic clocks solves nothing, since I can still sign a transaction a year ago and not broadcast it,

yeah and that's not a problem. the atomic clock timestamps your transaction, you then sign it and it sits there for a year or however long you wish. then someday you broadcast it. not a problem. we know when it was timestamped and signed.

Quote
or sign a transaction today but backdate it to a year ago, and you are powerless to know the difference.

an atomic clock is not going to let you backdate a transaction. it can only timestamp something with the current time.

Quote
If you want transactions timestamped when they are broadcast then you need to figure out:
  • One or more very good reasons why this would be worth the trade off of making transactions slower and more expensive and the whole blockchain less efficient (The quantum computing point is moot as I explained earlier in this thread)
separate topic

Quote
  • How you are going to trustlessly verify the timestamps are not fake
an atomic clock can only timestamp something with the current time. and it's very accurate. precise. no wiggle room.

Quote
  • How to convince the majority of the network of the two above points
all atomic clocks will be in sync so if your's isnt then it would be detectable.

Quote
In reality, if you want timestamps in the way you want them, then just run your own node and keep a local database of when you first see every transaction.
why would i want to be tasked with that chore when a better solution exists?
legendary
Activity: 2268
Merit: 18587
who's gonna believe that though. you could make up any time you wanted.
Which is exactly my point. Nothing in your proposal stops anyone from making up any time they want between when the UTXOs they spend were created and when other nodes see the transaction. I could timestamp my transaction yesterday or last year and you have no way of proving when I actually signed it. Syncing up atomic clocks solves nothing, since I can still sign a transaction a year ago and not broadcast it, or sign a transaction today but backdate it to a year ago, and you are powerless to know the difference.

If you want transactions timestamped when they are broadcast then you need to figure out:
  • One or more very good reasons why this would be worth the trade off of making transactions slower and more expensive and the whole blockchain less efficient (The quantum computing point is moot as I explained earlier in this thread)
  • How you are going to trustlessly verify the timestamps are not fake
  • How to convince the majority of the network of the two above points

In reality, if you want timestamps in the way you want them, then just run your own node and keep a local database of when you first see every transaction.
sr. member
Activity: 1036
Merit: 350
there's 2 different cases.

case 1: you try and backdate a transaction. that should be detected and stopped.
case 2: you sign a transaction ahead of time with a valid timestamp. that should be detected and allowed.
How would you propose to police how I sign transactions, when I very well could be signing them on a permanently airgapped device with no connection to the network?
well if you don't have an atomic clock then you shouldn't be allowed to timestamp your own transactions. simple as that. but if you do have one then it needs to be such that it produces valid timestamps that other atomic clocks could agree on. simple as that. although maybe it's a bit more than just atomic clocks. maybe there's some extra secret sauce in there.

so if you're a cheapo, then you don't get to timestamp diddly squat. you can rely on someone else to timestamp your transaction for you when you get around to broadcasting it to the network.

atomic clocks cost money. so not everyone might have them.


Quote
You could do that right now, if you want. Just include an OP_RETURN output in your transaction which can include some arbitrary data, and make that arbitrary data a timestamp.
who's gonna believe that though. you could make up any time you wanted.
legendary
Activity: 2268
Merit: 18587
there's 2 different cases.

case 1: you try and backdate a transaction. that should be detected and stopped.
case 2: you sign a transaction ahead of time with a valid timestamp. that should be detected and allowed.
How would you propose to police how I sign transactions, when I very well could be signing them on a permanently airgapped device with no connection to the network?

you're all worried about how the timestamp can just be changed at will. well, it can't. the timestamp would first of all be part of the signature. so it can't be changed once you sign it.
You could do that right now, if you want. Just include an OP_RETURN output in your transaction which can include some arbitrary data, and make that arbitrary data a timestamp.
sr. member
Activity: 333
Merit: 506
Quote
If QC has broken the ability to sign, then how does any of this resolve that miners could change any of the data before it reaches you?
the original transaction creator still has their signed timestamped transaction which could be used to verify it happened "first" if need be.
So?
They can say it but no one would have to believe them.

If SHA was broken, then a signed transaction would be worthless because others could produce signed transactions too. Anyone could say they were first.

Quote
If QC has not broken the ability to sign, then why would you need timestamps anyways?
there are many reasons why having an accurate timestamp on something is useful. like if you want to know when a transaction was created. having a secondary timestamp of when it was first seen by the network might be nice too...
Ok, but if you leave them out like bitcoin does, you have a more fungible and private token, instead of being open to shenanigans from any actors.

edit:
Satoshi was trying to solve this exact problem. From the white paper:
"To  accomplish   this   without   a   trusted   party,   transactions   must   be publicly announced [1], and we need a system for participants to agree on a single history of the order in which they were received. The payee needs proof that at the time of each transaction, the majority of nodes agreed it was the first received."
sr. member
Activity: 1036
Merit: 350
Then everyone will begin to see that your timestamp is probably invalid.
But it isn't invalid? I can sign a transaction whenever I want and broadcast it whenever I want. If you decide my timestamp is invalid, then you are restricting my ability to spend my own coins. You are also invalidating any transactions which are signed in advance but not broadcast, which would completely break things like Lightning, timelocked transactions, and more.

there's 2 different cases.

case 1: you try and backdate a transaction. that should be detected and stopped.
case 2: you sign a transaction ahead of time with a valid timestamp. that should be detected and allowed.



But you don't know that you are updating it to a "correct" one. Who is to say what's correct anyway? I could have signed an inheritance transaction a year ago, and then you decide "Nah, that's not good enough, we're changing it."


yeah, after thinking more about it, i don't think we want to change the timestamp. the timestamp is either deemed valid or deemed invalid. if valid, it can be processed. if invalid, it will be rejected. simple as that.



Quote

Then what is the point of the timestamp at all when it can be arbitrarily changed like this? It's completely meaningless.

see my comment above.

you're all worried about how the timestamp can just be changed at will. well, it can't. the timestamp would first of all be part of the signature. so it can't be changed once you sign it. but then you have to take care of ensuring that when you actually signed the transaction is the time you put on the timestamp. two things. if those 2 things are done then it's not "completely meaningless"

Quote
If QC has broken the ability to sign, then how does any of this resolve that miners could change any of the data before it reaches you?
the original transaction creator still has their signed timestamped transaction which could be used to verify it happened "first" if need be.
Quote
If QC has not broken the ability to sign, then why would you need timestamps anyways?
there are many reasons why having an accurate timestamp on something is useful. like if you want to know when a transaction was created. having a secondary timestamp of when it was first seen by the network might be nice too...
legendary
Activity: 2268
Merit: 18587
Then everyone will begin to see that your timestamp is probably invalid.
But it isn't invalid? I can sign a transaction whenever I want and broadcast it whenever I want. If you decide my timestamp is invalid, then you are restricting my ability to spend my own coins. You are also invalidating any transactions which are signed in advance but not broadcast, which would completely break things like Lightning, timelocked transactions, and more.

It could be either. Which would you prefer? To me, I think it would be ok to timestamps it as "now", ie, update your timestamp to the correct one and fix you trying to game the system.
But you don't know that you are updating it to a "correct" one. Who is to say what's correct anyway? I could have signed an inheritance transaction a year ago, and then you decide "Nah, that's not good enough, we're changing it."

the timestamp would change, older timestamp should become an outlier if it's not in sync with atomic clock time.
Then what is the point of the timestamp at all when it can be arbitrarily changed like this? It's completely meaningless.
sr. member
Activity: 333
Merit: 506
Quote
If the above isn't satisfactory, how can you ensure that a transaction, the moment that it's signed, can't have a faked timestamp?
you could make the timestamp be part of the signature. if the network consensus was that the timestamp was invalid then it could make your transaction become invalid.

Are we assuming that quantum computing has broken the ability to sign here or not? If QC has broken the ability to sign, then how does any of this resolve that miners could change any of the data before it reaches you? If QC has not broken the ability to sign, then why would you need timestamps anyways?
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
Quote
    Why should unconfirmed transactions be timestamped?
So we can know when the majority of nodes first saw the transaction. That means "when" it got presented to the network.
Why should we know such thing?

Quote
    If there's a reason, can it work if it's your node who checks the timestamps locally?
if i'm running an honest atomic clock then i could probably trust the timestamp I put on a transaction sure.
What do you mean you'd trust the timestamp of each transaction? Don't you want to know when it got presented to the network? Run your own node and timestamp every transaction to a local SQL.

Quote
    If the above isn't satisfactory, how can you ensure that a transaction, the moment that it's signed, can't have a faked timestamp?
you could make the timestamp be part of the signature. if the network consensus was that the timestamp was invalid then it could make your transaction become invalid.
You mean part of the transaction data. I don't understand when a "transaction timestamp" should be considered invalid. Explain that part. In bitcoin, you can't broadcast a block whose time that was mined on exceeds 2 hours ahead of the median-past time of the last 11 blocks.
sr. member
Activity: 1036
Merit: 350

Still don't see how this is going to work. So I broadcast a transaction with a timestamp of last week. As it spreads to other nodes, they all timestamp it right now, with a spread of a minute or so. What then?
Then everyone will begin to see that your timestamp is probably invalid.

Quote
My transaction is deemed in valid because of my timestamp? Or my timestamp is ignored as an outlier and the transaction is timestamped as now?
It could be either. Which would you prefer? To me, I think it would be ok to timestamps it as "now", ie, update your timestamp to the correct one and fix you trying to game the system.

Quote
What if I spin up a new node? It receives a transaction which has been sitting unconfirmed for a few days and timestamps it as now. That will then move the median. Does the timestamp change? What if the older timestamp becomes an outlier because the median moves?
Not sure I understand what you're getting at with that question. But the way you described it sounds exactly like it is supposed to work. the timestamp would change, older timestamp should become an outlier if it's not in sync with atomic clock time.

Quote
What's to stop me running dozens of nodes and all accepting the same timestamp from last year to force current nodes to be the outliers?
Well, good luck with that. It would take alot more than "dozens" of dishonest nodes to affect the statistical median I mentioned earlier. Your efforts would be in vain.

Quote
    Why should unconfirmed transactions be timestamped?
So we can know when the majority of nodes first saw the transaction. That means "when" it got presented to the network.

Quote
    If there's a reason, can it work if it's your node who checks the timestamps locally?
if i'm running an honest atomic clock then i could probably trust the timestamp I put on a transaction sure.

Quote
If the above isn't satisfactory, how can you ensure that a transaction, the moment that it's signed, can't have a faked timestamp?
you could make the timestamp be part of the signature. if the network consensus was that the timestamp was invalid then it could make your transaction become invalid.

Quote
For instance, what if a miner chooses to include his transaction that has a faked timestamp, without letting it propagate? Is the transaction invalid for some nodes?
not only that but the entire block he mined would be invalid so he wouldn't get any reward. doesn't seem like a logical thing to try and do.
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
Transactions are already timestamped when they are included in a block, by virtue of the block being timestamped.
Exactly. I don't find a point to this discussion as they're essentially already timestamped in a decentralized manner.

Larry, you haven't convinced me for the followings:

  • Why should unconfirmed transactions be timestamped?
  • If there's a reason, can it work if it's your node who checks the timestamps locally?
  • If the above isn't satisfactory, how can you ensure that a transaction, the moment that it's signed, can't have a faked timestamp? For instance, what if a miner chooses to include his transaction that has a faked timestamp, without letting it propagate? Is the transaction invalid for some nodes?
legendary
Activity: 2268
Merit: 18587
he chances of any 2 miners receiving the same transaction at the same exact time would be small. As in not likely to happen. So there will be one miner that has the lowest timestamp. That's who you go with. Its a bit more statistical in nature than that but just think take the median timestamp of the interquartile range of all timestamps. This would prevent miners from easily being able to game the system by changing the timestamp to something lower just so they could "win".
Still don't see how this is going to work. So I broadcast a transaction with a timestamp of last week. As it spreads to other nodes, they all timestamp it right now, with a spread of a minute or so. What then? My transaction is deemed in valid because of my timestamp? Or my timestamp is ignored as an outlier and the transaction is timestamped as now?

What if I spin up a new node? It receives a transaction which has been sitting unconfirmed for a few days and timestamps it as now. That will then move the median. Does the timestamp change? What if the older timestamp becomes an outlier because the median moves?

What's to stop me running dozens of nodes and all accepting the same timestamp from last year to force current nodes to be the outliers?
sr. member
Activity: 333
Merit: 506
So a miner runs an atomic clock. It has a frequency of 9 gigahertz or something like that. The chances of any 2 miners receiving the same transaction at the same exact time would be small. As in not likely to happen. So there will be one miner that has the lowest timestamp. That's who you go with. Its a bit more statistical in nature than that but just think take the median timestamp of the interquartile range of all timestamps. This would prevent miners from easily being able to game the system by changing the timestamp to something lower just so they could "win".

How would you verify that the miner wasn't gaming the system? Can't they just write any timestamp, or the lowest timestamp?
sr. member
Activity: 1036
Merit: 350
"The best cesium fountain atomic clocks are now predicted to be off by less than one second in more than 50 million years."
The issue isn't with clocks drifting out of sync with each other over a period of years; the issue is with a malicious user deliberately timestamping a transaction with an incorrect timestamp. Given that there is no requirement for a transaction to be broadcast as soon as it is signed, any timestamp between when the input UTXOs were created and when the transaction was first seen by any given node can be considered valid, and the node has no way of proving otherwise.

Quote
Only if you can detect the cheating, and you have not yet proposed how you would stop me timestamping a transaction last year and then broadcasting it today.
So a miner runs an atomic clock. It has a frequency of 9 gigahertz or something like that. The chances of any 2 miners receiving the same transaction at the same exact time would be small. As in not likely to happen. So there will be one miner that has the lowest timestamp. That's who you go with. Its a bit more statistical in nature than that but just think take the median timestamp of the interquartile range of all timestamps. This would prevent miners from easily being able to game the system by changing the timestamp to something lower just so they could "win".
Pages:
Jump to: