Help a newbie; why is hashing not done once but twice during Bitcoin transaction - page 2.

larry_vw_1955

sr. member

Activity: 1190

Merit: 469

Quote from: NotATether on May 11, 2022, 02:49:02 AM

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?

NotATether

legendary

Activity: 1568

Merit: 6660

bitcoincleanup.com / bitmixlist.org

Quote from: larry_vw_1955 on May 04, 2022, 08:15:01 PM

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?

larry_vw_1955

sr. member

Activity: 1190

Merit: 469

Quote from: kaggie on May 05, 2022, 01:44:57 AM

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.

kaggie

sr. member

Activity: 333

Merit: 506

Quote from: larry_vw_1955 on May 04, 2022, 08:15:01 PM

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 from: larry_vw_1955 on May 04, 2022, 08:15:01 PM

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.

larry_vw_1955

sr. member

Activity: 1190

Merit: 469

Quote from: o_e_l_e_o on May 03, 2022, 02:55:11 AM

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.

o_e_l_e_o

legendary

Activity: 2268

Merit: 18711

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.

Quote from: larry_vw_1955 on May 02, 2022, 09:01:04 PM

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?

Quote from: larry_vw_1955 on May 02, 2022, 09:01:04 PM

separate topic

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

Quote from: larry_vw_1955 on May 02, 2022, 09:01:04 PM

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.

larry_vw_1955

sr. member

Activity: 1190

Merit: 469

Quote from: o_e_l_e_o on May 01, 2022, 03:10:16 AM

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?

o_e_l_e_o

legendary

Activity: 2268

Merit: 18711

Quote from: larry_vw_1955 on April 30, 2022, 08:30:31 PM

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.

larry_vw_1955

sr. member

Activity: 1190

Merit: 469

Quote from: o_e_l_e_o on April 30, 2022, 02:21:15 AM

Quote from: larry_vw_1955 on April 28, 2022, 09:49:51 PM

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.

o_e_l_e_o

legendary

Activity: 2268

Merit: 18711

Quote from: larry_vw_1955 on April 28, 2022, 09:49:51 PM

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?

Quote from: larry_vw_1955 on April 28, 2022, 09:49:51 PM

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.

kaggie

sr. member

Activity: 333

Merit: 506

Quote from: larry_vw_1955 on April 28, 2022, 09:49:51 PM

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 from: larry_vw_1955 on April 28, 2022, 09:49:51 PM

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."

larry_vw_1955

sr. member

Activity: 1190

Merit: 469

Quote from: o_e_l_e_o on April 28, 2022, 03:01:05 AM

Quote from: larry_vw_1955 on April 27, 2022, 08:48:52 PM

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.

Quote from: larry_vw_1955 on April 27, 2022, 08:48:52 PM

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...

o_e_l_e_o

legendary

Activity: 2268

Merit: 18711

Quote from: larry_vw_1955 on April 27, 2022, 08:48:52 PM

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.

Quote from: larry_vw_1955 on April 27, 2022, 08:48:52 PM

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."

Quote from: larry_vw_1955 on April 27, 2022, 08:48:52 PM

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.

kaggie

sr. member

Activity: 333

Merit: 506

Quote from: larry_vw_1955 on April 27, 2022, 08:48:52 PM

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?

BlackHatCoiner

legendary

Activity: 1512

Merit: 7340

Farewell, Leo

Quote from: larry_vw_1955 on April 27, 2022, 08:48:52 PM

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 from: larry_vw_1955 on April 27, 2022, 08:48:52 PM

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 from: larry_vw_1955 on April 27, 2022, 08:48:52 PM

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.

larry_vw_1955

sr. member

Activity: 1190

Merit: 469

Quote from: o_e_l_e_o on April 27, 2022, 03:15:35 AM

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.

BlackHatCoiner

legendary

Activity: 1512

Merit: 7340

Farewell, Leo

Quote from: o_e_l_e_o on April 26, 2022, 07:47:08 AM

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?

o_e_l_e_o

legendary

Activity: 2268

Merit: 18711

Quote from: larry_vw_1955 on April 26, 2022, 10:09:51 PM

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?

kaggie

sr. member

Activity: 333

Merit: 506

Quote from: larry_vw_1955 on April 26, 2022, 10:09:51 PM

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?

larry_vw_1955

sr. member

Activity: 1190

Merit: 469

Quote from: o_e_l_e_o on April 25, 2022, 02:40:43 AM

Quote from: larry_vw_1955 on April 24, 2022, 08:19:58 PM

"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".

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