kaggie
|
|
April 25, 2022, 07:31:24 AM Last edit: April 25, 2022, 09:29:49 AM by kaggie |
|
Well it's almost like you're setting it up to fail when you say "trustless timestamping" because in your mind that's something that is impossible. Here's an idea though. it may not be so practical currently but someday it could be.
Correct. The limitation imposed by the speed of light may make rapid Byzantine fault tolerance impossible. Miners would have atomic clocks. required to have them. the point being :
"The best cesium fountain atomic clocks are now predicted to be off by less than one second in more than 50 million years."
so miners wouldn't need to "sync up" to each other to agree on the time very often. they could perform local computations.
Now consider the 'stamping' portion of 'time-stamping', especially when separate entities have an incentive to lie about being first.
|
|
|
|
o_e_l_e_o
In memoriam
Legendary
Offline
Activity: 2268
Merit: 18588
|
|
April 25, 2022, 07:40:43 AM Last edit: April 26, 2022, 04:26:04 AM by o_e_l_e_o |
|
"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.
|
|
|
|
larry_vw_1955
|
|
April 26, 2022, 05:16:33 AM |
|
Correct. The limitation imposed by the speed of light may make rapid Byzantine fault tolerance impossible.
Speed of light has nothing to do with it though. Miners wouldn't need to consult one another about what time it was. They would already know. Now consider the 'stamping' portion of 'time-stamping', especially when separate entities have an incentive to lie about being first.
well we all know what happens to cheaters right? they get punished. if you designed a punishment for cheating then that could probably take care of that. just like if i said, here is a magical tool that breaks sha256 the problem is if the bitcoin network detects you are using it, then it will not only not give you the block reward but delete some of your pending block rewards. or balance. how are they going to cheat then? would they want to risk it? 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.
If you want timestamps on every transaction the first thing you have to figure out is at what point does a transaction get timestamped. Then you can go from there. But until you figure that out, you don't have a well defined problem.
|
|
|
|
o_e_l_e_o
In memoriam
Legendary
Offline
Activity: 2268
Merit: 18588
|
|
April 26, 2022, 12:47:08 PM |
|
if you designed a punishment for cheating then that could probably take care of that. 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. If you want timestamps on every transaction the first thing you have to figure out is at what point does a transaction get timestamped. Transactions are already timestamped when they are included in a block, by virtue of the block being timestamped. If you want to change this to timestamping unconfirmed transactions when they are first seen, then the first thing you need to figure out is why you want to do that. I see no benefits.
|
|
|
|
larry_vw_1955
|
|
April 27, 2022, 03:09:51 AM |
|
"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. 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".
|
|
|
|
kaggie
|
|
April 27, 2022, 07:54:22 AM Last edit: April 27, 2022, 11:27:10 PM by kaggie |
|
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?
|
|
|
|
o_e_l_e_o
In memoriam
Legendary
Offline
Activity: 2268
Merit: 18588
|
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?
|
|
|
|
BlackHatCoiner
Legendary
Offline
Activity: 1568
Merit: 7654
Protocols over bureaucrats
|
|
April 27, 2022, 08:39:36 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?
|
. .BLACKJACK ♠ FUN. | | | ███▄██████ ██████████████▀ ████████████ █████████████████ ████████████████▄▄ ░█████████████▀░▀▀ ██████████████████ ░██████████████ █████████████████▄ ░██████████████▀ ████████████ ███████████████░██ ██████████ | | CRYPTO CASINO & SPORTS BETTING | | │ | | │ | ▄▄███████▄▄ ▄███████████████▄ ███████████████████ █████████████████████ ███████████████████████ █████████████████████████ █████████████████████████ █████████████████████████ ███████████████████████ █████████████████████ ███████████████████ ▀███████████████▀ ███████████████████ | | .
|
|
|
|
larry_vw_1955
|
|
April 28, 2022, 01:48:52 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. 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. 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. 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. 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. 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. 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. 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
Offline
Activity: 1568
Merit: 7654
Protocols over bureaucrats
|
|
April 28, 2022, 06:00:22 AM |
|
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? 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. 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.
|
. .BLACKJACK ♠ FUN. | | | ███▄██████ ██████████████▀ ████████████ █████████████████ ████████████████▄▄ ░█████████████▀░▀▀ ██████████████████ ░██████████████ █████████████████▄ ░██████████████▀ ████████████ ███████████████░██ ██████████ | | CRYPTO CASINO & SPORTS BETTING | | │ | | │ | ▄▄███████▄▄ ▄███████████████▄ ███████████████████ █████████████████████ ███████████████████████ █████████████████████████ █████████████████████████ █████████████████████████ ███████████████████████ █████████████████████ ███████████████████ ▀███████████████▀ ███████████████████ | | .
|
|
|
|
kaggie
|
|
April 28, 2022, 06:45:59 AM |
|
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?
|
|
|
|
o_e_l_e_o
In memoriam
Legendary
Offline
Activity: 2268
Merit: 18588
|
|
April 28, 2022, 08:01:05 AM |
|
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.
|
|
|
|
larry_vw_1955
|
|
April 29, 2022, 02:49:51 AM |
|
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. 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" 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. 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...
|
|
|
|
kaggie
|
|
April 29, 2022, 03:43:56 AM Last edit: April 29, 2022, 06:58:29 PM by kaggie |
|
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. 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."
|
|
|
|
o_e_l_e_o
In memoriam
Legendary
Offline
Activity: 2268
Merit: 18588
|
|
April 30, 2022, 07:21:15 AM |
|
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.
|
|
|
|
larry_vw_1955
|
|
May 01, 2022, 01:30:31 AM |
|
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. 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
In memoriam
Legendary
Offline
Activity: 2268
Merit: 18588
|
|
May 01, 2022, 08:10:16 AM |
|
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
|
|
May 03, 2022, 02:01:04 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. 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. 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 - 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. - 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. 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
In memoriam
Legendary
Offline
Activity: 2268
Merit: 18588
|
|
May 03, 2022, 07: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. 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.
|
|
|
|
larry_vw_1955
|
|
May 05, 2022, 01:15:01 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. 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. 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. 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.
|
|
|
|
|