Jorge Tim贸n [ARCHIVE] on Nostr: 馃搮 Original date posted:2015-07-23 馃摑 Original message:Peter Todd, as discussed ...
馃搮 Original date posted:2015-07-23
馃摑 Original message:Peter Todd, as discussed on IRC, I'm not opposed to median time, which
has many of the properties nheight has, I'm just opposed to just using
nTime which is what all "hardfork proposals" I've seen so far
(including this one) do.
On Wed, Jul 22, 2015 at 12:05 AM, Ross Nicoll <jrn at jrn.me.uk> wrote:
> On 21/07/2015 10:26, Jorge Tim贸n wrote:
>>
>> I still disagree. Using height instead of time may make the
>> implementation more complex by requiring some additional preparations
>> but using height is in fact a simpler design. Why relay on clocks that
>> we know will differ in different computers and places when we have a
>> universal tick with every block?
>
> Not so much that the implementation is difficult, as it requires context to
> validate a block size, rather than being able to validate it without
> requiring the preceeding blocks. Yes, time on different machines may vary,
> but block time is safe to use for this, because it's a straight-forward test
> of "if block time is acceptable and block time is after <date> then maximum
> block size allowed is n MB otherwise m MB".
No, the height is in the current block after bip34, no context required.
In any case, you already have the nHeight in most functions that would
require it (for example, main::ConnectBlock).
The median time actually needs a context (the last 10 headers), but
it's not hard to calculate and pass around either.
But simply using nTime is not a good idea. Leaving aside time zones,
einstein and all that it introduces edge cases and weird incentives
for no good reason.
If the goal is to make it "human-schedule-friendly", median time
should be good enough.
If we're going to make miners 95% confirm after the date/height, I
still prefer the height, but as said median time seems a reasonable
compromise.
Can we move the "height/medianTime/nTime" and "is it good to confirm
that the change is uncontroversial to miners by requiring 95% to
activate the consensus change, like we do with uncontroversial
softforks?" discussions to the thread with my bip draft (
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008936.html
) on precisely this subject?
I have requested a bip number.
Let's please have an uncontroversial hardfork to set a precedent.
Hopefully that way we may decouple some parts of the blocksize
discussion.
馃摑 Original message:Peter Todd, as discussed on IRC, I'm not opposed to median time, which
has many of the properties nheight has, I'm just opposed to just using
nTime which is what all "hardfork proposals" I've seen so far
(including this one) do.
On Wed, Jul 22, 2015 at 12:05 AM, Ross Nicoll <jrn at jrn.me.uk> wrote:
> On 21/07/2015 10:26, Jorge Tim贸n wrote:
>>
>> I still disagree. Using height instead of time may make the
>> implementation more complex by requiring some additional preparations
>> but using height is in fact a simpler design. Why relay on clocks that
>> we know will differ in different computers and places when we have a
>> universal tick with every block?
>
> Not so much that the implementation is difficult, as it requires context to
> validate a block size, rather than being able to validate it without
> requiring the preceeding blocks. Yes, time on different machines may vary,
> but block time is safe to use for this, because it's a straight-forward test
> of "if block time is acceptable and block time is after <date> then maximum
> block size allowed is n MB otherwise m MB".
No, the height is in the current block after bip34, no context required.
In any case, you already have the nHeight in most functions that would
require it (for example, main::ConnectBlock).
The median time actually needs a context (the last 10 headers), but
it's not hard to calculate and pass around either.
But simply using nTime is not a good idea. Leaving aside time zones,
einstein and all that it introduces edge cases and weird incentives
for no good reason.
If the goal is to make it "human-schedule-friendly", median time
should be good enough.
If we're going to make miners 95% confirm after the date/height, I
still prefer the height, but as said median time seems a reasonable
compromise.
Can we move the "height/medianTime/nTime" and "is it good to confirm
that the change is uncontroversial to miners by requiring 95% to
activate the consensus change, like we do with uncontroversial
softforks?" discussions to the thread with my bip draft (
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008936.html
) on precisely this subject?
I have requested a bip number.
Let's please have an uncontroversial hardfork to set a precedent.
Hopefully that way we may decouple some parts of the blocksize
discussion.