đź“… Original date posted:2021-09-15
đź“ť Original message:> On Sep 13, 2021, at 21:56, Anthony Towns <aj at erisian.com.au> wrote:
> I'm not sure that's really the question you want answered?
Of course it is? I’d like to understand the initial thinking and design analysis that went into this decision. That seems like an important question to ask when seeking changes in an existing system :).
> Mostly
> it's just "this is how mainnet works" plus "these are the smallest
> changes to have blocks be chosen by a signature, rather than entirely
> by PoW competition".
>
> For integration testing across many services, I think a ten-minute-average
> between blocks still makes sense -- protocols relying on CSV/CLTV to
> ensure there's a delay they can use to recover funds, if they specify
> that in blocks (as lightning's to_self_delay does), then significant
> surges of blocks will cause uninteresting bugs.
Hmm, why would blocks coming quicker lead to a bug? I certainly hope no one has a bug if their block time is faster than per ten minutes. I presume here, you mean something like “if the node can’t keep up with the block rate”, but I certainly hope the benchmark for may isn’t 10 minutes, or really even one.
> It would be easy enough to change things to target an average of 2 or
> 5 minutes, I suppose, but then you'd probably need to propogate that
> logic back into your apps that would otherwise think 144 blocks is around
> about a day.
Why? One useful thing for testing is compressing real time. More broadly, the only issues that I’ve heard around block times in testnet3 are the inconsistency and, rarely software failing to keep up at all.
> We could switch back to doing blocks exactly every 10 minutes, rather
> than a poisson-ish distribution in the range of 1min to 60min, but that
> doesn't seem like that huge a win, and makes it hard to test that things
> behave properly when blocks arrive in bursts.
Hmm, I suppose? If you want to test that the upper bound doesn’t need to be 100 minutes, though, it could be 10.
> Best of luck to you then? Nobody's trying to sell you on a subscription
> plan to using signet.
lol, yes, I’m aware of that, nor did I mean to imply that anything has to be targeted at a specific person’s requirements. Rather, my point here is that I’m really confused as to who the target user *is*, because we should be building products with target users in mind, even if those targets are often “me” for open source projects.
Matt Corallo [ARCHIVE] /
npub1e4…jxmcu
2023-06-07 22:58:51
in reply to nevent1q…zat5
Author Public Key
npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcuPublished at
2023-06-07 22:58:51Event JSON
{
"id": "0109dabf2db916011a8be43d93474a479cd9f2d28724a3cbc6dbe490d2ea33ec",
"pubkey": "cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba",
"created_at": 1686178731,
"kind": 1,
"tags": [
[
"e",
"82e0f12d7f35467c29cd59e777250289c4cb4554dc58ceaaad44bec4613bd98c",
"",
"root"
],
[
"e",
"7a923ab83c8bd28a00cb2c75b118081b563394e4f74eab25dc232523a34a2ae8",
"",
"reply"
],
[
"p",
"f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab"
]
],
"content": "📅 Original date posted:2021-09-15\n📝 Original message:\u003e On Sep 13, 2021, at 21:56, Anthony Towns \u003caj at erisian.com.au\u003e wrote:\n\u003e I'm not sure that's really the question you want answered?\n\nOf course it is? I’d like to understand the initial thinking and design analysis that went into this decision. That seems like an important question to ask when seeking changes in an existing system :).\n\n\u003e Mostly\n\u003e it's just \"this is how mainnet works\" plus \"these are the smallest\n\u003e changes to have blocks be chosen by a signature, rather than entirely\n\u003e by PoW competition\".\n\u003e \n\u003e For integration testing across many services, I think a ten-minute-average\n\u003e between blocks still makes sense -- protocols relying on CSV/CLTV to\n\u003e ensure there's a delay they can use to recover funds, if they specify\n\u003e that in blocks (as lightning's to_self_delay does), then significant\n\u003e surges of blocks will cause uninteresting bugs. \n\nHmm, why would blocks coming quicker lead to a bug? I certainly hope no one has a bug if their block time is faster than per ten minutes. I presume here, you mean something like “if the node can’t keep up with the block rate”, but I certainly hope the benchmark for may isn’t 10 minutes, or really even one.\n\n\u003e It would be easy enough to change things to target an average of 2 or\n\u003e 5 minutes, I suppose, but then you'd probably need to propogate that\n\u003e logic back into your apps that would otherwise think 144 blocks is around\n\u003e about a day.\n\nWhy? One useful thing for testing is compressing real time. More broadly, the only issues that I’ve heard around block times in testnet3 are the inconsistency and, rarely software failing to keep up at all.\n\n\u003e We could switch back to doing blocks exactly every 10 minutes, rather\n\u003e than a poisson-ish distribution in the range of 1min to 60min, but that\n\u003e doesn't seem like that huge a win, and makes it hard to test that things\n\u003e behave properly when blocks arrive in bursts.\n\nHmm, I suppose? If you want to test that the upper bound doesn’t need to be 100 minutes, though, it could be 10.\n\n\u003e Best of luck to you then? Nobody's trying to sell you on a subscription\n\u003e plan to using signet.\n\n\nlol, yes, I’m aware of that, nor did I mean to imply that anything has to be targeted at a specific person’s requirements. Rather, my point here is that I’m really confused as to who the target user *is*, because we should be building products with target users in mind, even if those targets are often “me” for open source projects.",
"sig": "3b99ed79b51f00375049e622dc1cc9653ead1092070a313d42dcb1631981b535c04731ad34094f3e9dbc2c0cdb1ba06cc3d4313b25213473a0f498a74354ba33"
}