Matt Corallo [ARCHIVE] on Nostr: 📅 Original date posted:2021-09-10 📝 Original message:Fwiw, your email client is ...
📅 Original date posted:2021-09-10
📝 Original message:Fwiw, your email client is broken and does not properly quote in the plaintext copy. I believe this
is a known gmail bug, but I'd recommend avoiding gmail's web interface for list posting :).
On 9/10/21 12:00, Michael Folkson wrote:
>> Huh? Why would the goal be to match mainnet? The goal, as I understand it, is to allow software to
> use SigNet without modification *to make testing simpler* - keep the
> header format the same to let
> SPV clients function without (significant) modification, etc. The
> point of the whole thing is to
> make testing as easy as possible, why would we do otherwise.
>
> I guess Kalle (and AJ) can answer this question better than me but my
> understanding is that the motivation for Signet was that testnet
> deviated erratically from mainnet behavior (e.g. long delays before
> any blocks were mined followed by a multitude of blocks mined in a
> short period of time) which meant it wasn't conducive to normal
> testing of applications. Why would you want a mainnet like chain? To
> check if your application works on a mainnet like chain without
> risking any actual value before moving to mainnet. The same purpose as
> testnet but more reliably resembling mainnet behavior. You are well
> within your rights to demand more than that but my preference would be
> to push some of those demands to custom signets rather than the
> default Signet.
Huh? You haven't made an argument here as to why such a chain is easier to test with, only that we
should "match mainnet". Testing on mainnet sucks, 99% of the time testing on mainnet involves no
reorgs, which *doesn't* match in-the-field reality of mainnet, with occasional reorgs. Matching
mainnet's behavior is, in fact, a terrible way to test if your application will run fine on mainnet.
My point is that the goal should be making it easier to test. I'm not entirely sure why there's
debate here. I *regularly* have lunch late because I'm waiting for blocks either on mainnet or
testnet3, and would quite like to avoid that in the future. It takes *forever* to test things on
mainnet and testnet3, matching their behavior would mean its equally impossible to test things on
mainnet and testnet3, why is that something we should stirve for?
> Testing out proposed soft forks in advance of them being considered
> for activation would already be introducing a dimension of complexity
> that is going to be hard to manage [0]. I'm generally of the view that
> if you are going to introduce a complexity dimension, keep the other
> dimensions as vanilla as possible. Otherwise you are battling
> complexity in multiple different dimensions and it becomes hard or
> impossible to maintain it and meet your initial objectives.
Yep! Great reason to not have any probabilistic nonsense or try to match mainnet or something on
signet, just make it deterministic, reorg once a block or twice an our or whatever and call it a day!
Matt
Published at
2023-06-07 22:58:53Event JSON
{
"id": "0a013d55f8ad15215feaeb4a6e48fde36552248e8074949d7fb1197a1b3967ac",
"pubkey": "cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba",
"created_at": 1686178733,
"kind": 1,
"tags": [
[
"e",
"82e0f12d7f35467c29cd59e777250289c4cb4554dc58ceaaad44bec4613bd98c",
"",
"root"
],
[
"e",
"958d2d803a2ef7ffb10003de8db95a4f79693d07efe93c1e28eaafa96d8ebf87",
"",
"reply"
],
[
"p",
"7c4981f0d3c5eec97631de273b25b6435f0f33e0fa6cce270ddd3f3b8797d26a"
]
],
"content": "📅 Original date posted:2021-09-10\n📝 Original message:Fwiw, your email client is broken and does not properly quote in the plaintext copy. I believe this \nis a known gmail bug, but I'd recommend avoiding gmail's web interface for list posting :).\n\nOn 9/10/21 12:00, Michael Folkson wrote:\n\u003e\u003e Huh? Why would the goal be to match mainnet? The goal, as I understand it, is to allow software to\n\u003e use SigNet without modification *to make testing simpler* - keep the\n\u003e header format the same to let\n\u003e SPV clients function without (significant) modification, etc. The\n\u003e point of the whole thing is to\n\u003e make testing as easy as possible, why would we do otherwise.\n\u003e \n\u003e I guess Kalle (and AJ) can answer this question better than me but my\n\u003e understanding is that the motivation for Signet was that testnet\n\u003e deviated erratically from mainnet behavior (e.g. long delays before\n\u003e any blocks were mined followed by a multitude of blocks mined in a\n\u003e short period of time) which meant it wasn't conducive to normal\n\u003e testing of applications. Why would you want a mainnet like chain? To\n\u003e check if your application works on a mainnet like chain without\n\u003e risking any actual value before moving to mainnet. The same purpose as\n\u003e testnet but more reliably resembling mainnet behavior. You are well\n\u003e within your rights to demand more than that but my preference would be\n\u003e to push some of those demands to custom signets rather than the\n\u003e default Signet.\n\nHuh? You haven't made an argument here as to why such a chain is easier to test with, only that we \nshould \"match mainnet\". Testing on mainnet sucks, 99% of the time testing on mainnet involves no \nreorgs, which *doesn't* match in-the-field reality of mainnet, with occasional reorgs. Matching \nmainnet's behavior is, in fact, a terrible way to test if your application will run fine on mainnet.\n\nMy point is that the goal should be making it easier to test. I'm not entirely sure why there's \ndebate here. I *regularly* have lunch late because I'm waiting for blocks either on mainnet or \ntestnet3, and would quite like to avoid that in the future. It takes *forever* to test things on \nmainnet and testnet3, matching their behavior would mean its equally impossible to test things on \nmainnet and testnet3, why is that something we should stirve for?\n\n\n\u003e Testing out proposed soft forks in advance of them being considered\n\u003e for activation would already be introducing a dimension of complexity\n\u003e that is going to be hard to manage [0]. I'm generally of the view that\n\u003e if you are going to introduce a complexity dimension, keep the other\n\u003e dimensions as vanilla as possible. Otherwise you are battling\n\u003e complexity in multiple different dimensions and it becomes hard or\n\u003e impossible to maintain it and meet your initial objectives.\n\nYep! Great reason to not have any probabilistic nonsense or try to match mainnet or something on \nsignet, just make it deterministic, reorg once a block or twice an our or whatever and call it a day!\n\nMatt",
"sig": "86831154ecca310a0c6c31b43111dec80460d4570fbd4ac882c0745e13a2ffa653ba2c322c7edcbeaa0f3e43711841caf02d1a914ae7400d6334c0c5ccc7e352"
}