• Tartas1995@discuss.tchncs.de
    link
    fedilink
    arrow-up
    1
    arrow-down
    2
    ·
    edit-2
    6 hours ago

    I was excited for Bitcoin but the more I learned and the more the public used it, the more I hated it.

    EDIT: FOLLOWING PARAGRAPH IS A BADLY PHRASE EXPLANATION, PLEASE READ MY COMMENT BELOW TO UNDERSTAND MY POINT

    Bitcoins timestamp only supports dates up to 2106 because they decided on an UNSIGNED value. You don’t need negative values… You know when the network starts, that is 0. Without network, no Bitcoin.

    That is how bad it is engineered.

    And we are not even talking proof of work or whatever. Crypto is a scam because the creators made it very obvious that they didn’t really care about the project and the community is just gambling.

    • beegnyoshi@lemmy.zip
      link
      fedilink
      arrow-up
      3
      ·
      6 hours ago

      I don’t get why using an unsigned value is bad in this context. Like you’ve said yourself, why would you add support for dates that happened before the creation of the network?

      • Tartas1995@discuss.tchncs.de
        link
        fedilink
        arrow-up
        2
        ·
        6 hours ago

        Sorry my phrasing was bad and made it confusing. Let me explain it in detail.

        They correctly choose a unsigned int for the time but they based it on Unix time, and Unix time is signed. So they choose a system that would require an conversion from Unix time to Bitcoin time (or the other way around) anyway. But you don’t need to be able to have a timestamp for 1970, which their timestamp system supports, because instead of counting from 2008 (the invention of Bitcoin) they count from 1970. Wasting 38 years and as you know Unix time is hitting a limit in 2038, 68 years after its start, Bitcoin time is unsigned and so it gets to 2106. 2106-1970= 136 years. And they are wasting 38 years!!! Why? You need a conversion between both after 2038 anyway. And if they really care for cheap conversion, a signed 64bit value would be much better, because after 2038, that will probably be the standard. So they chose to waste 38 years for compatibility which will break after 2038, instead of choosing compatibility after 2038 for 292 billion years.

        And if size was the reason and 64bit timestamps would have been too big, just start counting from 2008 (or better 2009 when the network started) and get all those juicy 136 years instead of 98 years.

        It is stupid.

        • nitrolife@rekabu.ru
          link
          fedilink
          arrow-up
          1
          ·
          2 hours ago

          or they can simply inherit the UNIXTIME library, in which 0 has shifted from 1970 to 2038, and add one additional “time epoch” flag. Think about what’s easier - create your own time library or inherit from unixtime?