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 Thu, May 09, 2013 at 02:07:23PM +0200, Adam Back wrote:
> I have to say I do not think you want to have it be random as to who gets
> paid (by having conflicting double spends floating around with different
> payee & change addresses all from the same sending address.)
Indeed. That's the point
I have to say I do not think you want to have it be random as to who gets
paid (by having conflicting double spends floating around with different
payee & change addresses all from the same sending address.)
About current defacto no replacement: it is the best bitcoin currently has,
and it has v
On Thu, May 09, 2013 at 01:19:13PM +0200, Adam Back wrote:
> In this thread discussing this idea
>
> https://bitcointalk.org/index.php?topic=179612.0
>
> it is suggested that the approach risks making 0-confirm double-spends
> easier.
The patch makes the concept of a 0-confirm double-spend obso
In this thread discussing this idea
https://bitcointalk.org/index.php?topic=179612.0
it is suggested that the approach risks making 0-confirm double-spends
easier.
I dont see why this should be. Cant part of the validation of accepting a
fee revision be that every aspct of the revision except
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
After some consultation with affected sites by myself and Peter we have decided
to release an initial replace-by-fee implementation and setup a server using
those rules on testnet. This implementation does not include recursive fee
evaluation, and is
8 matches
Mail list logo
