Nice write-up! However, I don’t like the idea to change the upgrade schedule to accommodate late proposals.
I’d like to add this bit I realized about SLP, from risk point of view:
Now consider SLP consensus failure which can result in a total loss of funds. What impact on the image would there be if SLP had a catastrophic failure and loss of funds? I’d argue that moving the risk of having tokens from consensus to userland actually increased the risk for the whole ecosystem, and you give up levers of control because it’s permissionless so it can alone grow and blow up eventually, affecting BCH image in that. That risk never goes away because every new wallet/middleware software introduces it independently of what everyone else is doing.
If there was a competitive miner validated token solution from the beginning, then nobody would have bothered with SLP. If popularity of the current SLP solution increases, the risk only grows with time because it’ll be more funds at risk, more different software out there so both probability and severity increases with popularity. It can’t be simply fixed because it’s not a software issue, it’s an architecture issue, which is not really new and has been known from the start. SLP middleware can serve faulty data to a 100% compliant wallet, and the wallet will have a choice: trust it and risk catasthrophic failure, or do the DAG walk itself but then that doesn’t scale. So the choice is between security and scalability. Only a miner validated solution gives you both.
To reiterate, in the risk VS benefits framework can we agree that these premises hold?
As SLP adoption grows it increases both risks & benefits
With miner validated, post-activation risk remains fixed or close to fixed, while the benefits increase with adoption
Ok to be fair here I’m arguing for any kind of miner validated tokens, or even Script validated tokens which are also miner validated but it’s another layer so there’s some distinction. Still, a consensus failure in interpreting some opcode or sequence of operations would similarly result in a fork like Group tokens would, would it not? I don’t see how this risk of a fork is different when comparing a native vs Script token implementation. If we had all the primitives to build Script tokens now, then you could say there’s no new risk with Script tokens. But if enabling Script tokens requires a consensus change, then it also introduces this risk of consensus failure.
Quoting myself from: https://read.cash/@bitcoincashautist/some-comments-on-bch-network-discussion-on-group-tokenization-afae5ea3