On Thu, May 9, 2013 at 11:40 AM, Mike Hearn wrote:
> 2038 issues only apply to use of signed timestamps, I thought we treat
> this field as unsigned? Is it really a big deal?
Not a big deal at all, no.
--
Jeff Garzik
exMULTI, Inc.
jgar...@exmulti.com
2038 issues only apply to use of signed timestamps, I thought we treat
this field as unsigned? Is it really a big deal?
On Thu, May 9, 2013 at 1:12 PM, Pieter Wuille wrote:
> On Wed, May 08, 2013 at 10:42:44PM -0400, Peter Todd wrote:
>> Ah, shoot, I just realized we both got missed Pieter's poin
On Wed, May 08, 2013 at 10:42:44PM -0400, Peter Todd wrote:
> Ah, shoot, I just realized we both got missed Pieter's point entirely:
> he means to change the meaning of the header timestamp to be relative
> time passed since the last block...
No, though that's also a possibility, but a backward-in
On Thu, May 09, 2013 at 02:33:11AM +, John Dillon wrote:
> On Thu, May 9, 2013 at 1:57 AM, Peter Todd wrote:
> > Remember that interpreting the timestamp on a block for the purposes of
> > timestamping is a lot more subtle than it appears at first.
>
> I actually just meant how Pieter Wuille
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Thu, May 9, 2013 at 1:57 AM, Peter Todd wrote:
> Remember that interpreting the timestamp on a block for the purposes of
> timestamping is a lot more subtle than it appears at first.
I actually just meant how Pieter Wuille was talking about a bl
On Thu, May 09, 2013 at 01:27:33AM +, John Dillon wrote:
> > There's also no need: 32 bits is plenty of precision. Hell, even 16 bits
> > would
> > do (assuming there's never more than a 65535s (about 18 hours) gap between
> > two
> > blocks). Just assume the "full" 64-bit time is the smalles
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Thu, May 9, 2013 at 1:13 AM, Pieter Wuille wrote:
> On Wed, May 08, 2013 at 09:08:34PM -0400, Jeff Garzik wrote:
>> Guffaw :) The year 2038 is so far in the future that it is not really
>> relevant, from that angle.
>
> "Meh". I think it's highl
On Wed, May 08, 2013 at 09:08:34PM -0400, Jeff Garzik wrote:
> On Wed, May 8, 2013 at 9:00 PM, John Dillon
> wrote:
> > Perhaps Satoshi did this delibrately, knowing that at some point a hard-fork
> > would be a good idea, so that we all would have a good excuse to do one?
>
> Guffaw :) The year
On Wed, May 8, 2013 at 9:00 PM, John Dillon
wrote:
> Perhaps Satoshi did this delibrately, knowing that at some point a hard-fork
> would be a good idea, so that we all would have a good excuse to do one?
Guffaw :) The year 2038 is so far in the future that it is not really
relevant, from that a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Wed, May 8, 2013 at 11:44 PM, Peter Todd wrote:
> Who knows?
>
> Satoshi used 32-bits and those fields can't be changed now without every
> single Bitcoin user changing all at once. (a "hard-fork" change)
>
> We'll probably need to do one of thos
On Thu, May 09, 2013 at 09:39:10AM +1000, Addy Yeow wrote:
> Hi list,
>
> Can someone explain why do we have 32-bit and 64-bit timestamp fields
> instead of all being 64-bit?
>
> https://en.bitcoin.it/wiki/Protocol_specification
Who knows?
Satoshi used 32-bits and those fields can't be changed
On Wed, May 8, 2013 at 7:39 PM, Addy Yeow wrote:
> Hi list,
>
> Can someone explain why do we have 32-bit and 64-bit timestamp fields
> instead of all being 64-bit?
>
> https://en.bitcoin.it/wiki/Protocol_specification
Hysterical raisins.
--
Jeff Garzik
exMULTI, Inc.
jgar...@exmulti.com
--
Hi list,
Can someone explain why do we have 32-bit and 64-bit timestamp fields
instead of all being 64-bit?
https://en.bitcoin.it/wiki/Protocol_specification
Cheers,
Addy
--
Learn Graph Databases - Download FREE O'Reill
13 matches
Mail list logo
