📅 Original date posted:2015-09-19 📝 Original message:I disagree with the ...

Jorge Timón [ARCHIVE] /

npub1fx9…l2d8

2023-06-07 17:40:08

in reply to nevent1q…7u4m

📅 Original date posted:2015-09-19
📝 Original message:I disagree with the importance of this concern and old soft/hardforks will
replace this activation mechanism with height, so that's an argument in
favor of using the height from the start. This is "being discussed" in a
thread branched from bip99's discussion.
Anyway, is this proposing to use the block time or the median block time?
For some hardforks/softforks the block time complicates the implementation
(ie in acceptToMemoryPool) as discussed in the mentioned thread.
On Sep 19, 2015 1:24 AM, "Rusty Russell" <rusty at rustcorp.com.au> wrote:

> Jorge Timón via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
> writes:
> > I agree on using height vs time. Rusty, what do you mean by being easier
> > for bip writers? How is writing "block x" any harder than writing "date
> y".
>
> Three years from drafting is reasonable. How many blocks is that? Hmm,
> better make it 6 years of blocks just in case we have a hash race.
>
> Deployment speed is measured in months, not blocks. It's hard enough to
> guess without adding another variable.
>
> Cheers,
> Rusty.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150919/f7220d48/attachment-0001.html>;

Author Public Key

npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8

Show more details

Published at

2023-06-07 17:40:08

Kind type

1 Short Text Note

Event JSON

{ "id": "56bb00669814cfb9d607afe812e5f0b935c84055a493f9e1d2f08c02d67f6c97", "pubkey": "498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84", "created_at": 1686159608, "kind": 1, "tags": [ [ "e", "97970fd647e1ad99b763fefc14ff6c3da92992c59a8d85f2e5fe9ba87f5c9fb9", "", "root" ], [ "e", "14c37f5c9a4f3db2e03af1b52e71888ee406e0af3b51f14cafb38d8273edabab", "", "reply" ], [ "p", "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425" ] ], "content": "📅 Original date posted:2015-09-19\n📝 Original message:I disagree with the importance of this concern and old soft/hardforks will\nreplace this activation mechanism with height, so that's an argument in\nfavor of using the height from the start. This is \"being discussed\" in a\nthread branched from bip99's discussion.\nAnyway, is this proposing to use the block time or the median block time?\nFor some hardforks/softforks the block time complicates the implementation\n(ie in acceptToMemoryPool) as discussed in the mentioned thread.\nOn Sep 19, 2015 1:24 AM, \"Rusty Russell\" \u003crusty at rustcorp.com.au\u003e wrote:\n\n\u003e Jorge Timón via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e writes:\n\u003e \u003e I agree on using height vs time. Rusty, what do you mean by being easier\n\u003e \u003e for bip writers? How is writing \"block x\" any harder than writing \"date\n\u003e y\".\n\u003e\n\u003e Three years from drafting is reasonable. How many blocks is that? Hmm,\n\u003e better make it 6 years of blocks just in case we have a hash race.\n\u003e\n\u003e Deployment speed is measured in months, not blocks. It's hard enough to\n\u003e guess without adding another variable.\n\u003e\n\u003e Cheers,\n\u003e Rusty.\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150919/f7220d48/attachment-0001.html\u003e", "sig": "9b9f8febd4e1db1c3e9a1fd3953982b6c2dbb01f2fb1eb531bc32ebb896ee9fba43ea6293793c5a310b167cdbac81e4aefd22c9e4dfbcca658d7e16896840a63" }