Short and sweet; Linux has recently added support for 64bit timestamps to the kernel. Since the resolution of nTime is limited to 4 bytes - or as a standard unix timestamp (pre-patch) if you prefer; wouldn't bitcoin be susceptible to the year 2038 bug?
-
barrystyle commented at 6:13 PM on February 19, 2020: none
- barrystyle added the label good first issue on Feb 19, 2020
-
brakmic commented at 6:19 PM on February 19, 2020: contributor
This doesn't look like a good "good first issue", imo. There is a certain template that should be used. Maybe better let experienced devs formulate them.
-
barrystyle commented at 6:21 PM on February 19, 2020: none
If you are having trouble understanding what i've written, happy to explain further.
-
brakmic commented at 6:23 PM on February 19, 2020: contributor
What you have formulated is, imo, not a good first issue but rather a question. Also, you did not follow the guides of this project, because you did not use the template Bitcoin devs use.
However, I don't want to (mis)use this for any philosophical discussions and will leave it for Core Devs to decide.
Regards,
-
kristapsk commented at 6:30 PM on February 19, 2020: contributor
You can't just simply change timestamp format used for Bitcoin blocks, that will be a consensus change and cause a hardfork. Such changes aren't decided in Bitcoin Core repo, must have broader discussion and follow BIP (Bitcoin Improement Proposal) process.
-
barrystyle commented at 6:34 PM on February 19, 2020: none
Just wanted to open a dialogue gentlemen.. the issue isn't going to go away.
On that note, you'd probably integrate a timestamp into the block's coinbase transaction and deprecate the existing variable.
- barrystyle closed this on Feb 19, 2020
- fanquake removed the label good first issue on Feb 19, 2020
- MarcoFalke locked this on Feb 15, 2022
Contributors