Well, it's the right word. If you're going to do a hardfork by changing
the timestamp definition, you're already doing a hardfork. At that
point, you've already crossed the Rubicon and might as well put in any
other necessary changes (e.g. to transaction locking), because it will
be as much of
Good Afternoon,
I am certain that as soon as we identify solutions they should be
implemented. Basic life skills assert that procrastination is always a
form of failure, where we could have realised and accomplished further
yet we waited and in our present state could not ascertain what was
Hi yanmaani
On Sun, Oct 17, 2021 at 5:28 PM yanmaani--- via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> What, no. The `k` value is calculated implicitly, because there's only
> one value of it that could ever be valid - if `k` is 1 too small, we're
> 70 years too far back, and
What, no. The `k` value is calculated implicitly, because there's only
one value of it that could ever be valid - if `k` is 1 too small, we're
70 years too far back, and then the block will violate median of last
11. If `k` is 1 too large, we're 70 years too far in the future, then
the block
There is a hard fork wishlist:
https://en.bitcoin.it/wiki/Hardfork_Wishlist
Note last update is somewhat old.
Cheers.
On Sat, Oct 16, 2021 at 12:49 AM James Lu via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Making Bitcoin function after 2038 is by definition a hard fork
>
>
Hi, BIP 42 is a code base consensus soft fork that at the time of
activation does not really manifest as a fork because nobody is running any
code not already applying it. Can a similar thing be done in 17 years? (I
haven't really made sense of this year 2038 problem, I don't know or
understand
yes but ... just for the sake of argument ... if a change such as this
wraparound interpretation is made anytime in the next 5 years it'll be over
a *decade after that *before any wrapped-around timestamp is legitimately
mined ... and by then nobody will be running incompatible (decade old) node
> What happens if a series of blocks has a timestamp of 0x at the
> appropriate time?
The chain will halt for all old clients, because there is no 32-bit value
greater than 0x.
> 1. Is not violated, since "not lower than" means "greater than or equal to"
No, because it has to
Good morning yanmaani,
> It's well-known. Nobody really cares, because it's so far off. Not
> possible to do by softfork, no.
I think it is possible by softfork if we try hard enough?
> 1. The block timestamp may not be lower than the median of the last 11
> blocks'
>
> 2. The block
Your solution seems to solve the problem of chain halting, but there are more
issues. For example: if you have some time modulo 2^32, then you no longer know
if timestamp zero is related to 1970 or 2106 or some higher year. Your "k"
value representing in fact the most significant 32 bits of
It's well-known. Nobody really cares, because it's so far off. Not
possible to do by softfork, no. It is possible to do by something that
becomes a hardfork in 80 years, though, which is probably good enough.
I proposed a solution, but nobody was really interested. Let's see if
anyone bites
Making Bitcoin function after 2038 is by definition a hard fork
I feel if we do HF, we should bundle other HF changes with it...
On Wed, Oct 13, 2021 at 5:19 PM vjudeu via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> It seems that Bitcoin Core will stop working in 2038 because
It seems that Bitcoin Core will stop working in 2038 because of assertion
checking if the current time is non-negative. Also, the whole chain will halt
after reaching median time 0x in 2106. More information:
https://bitcointalk.org/index.php?topic=5365359.0
I wonder if that kind of
13 matches
Mail list logo
