Shooting Gallery: Inject SLP into consensus, 100% compatibility with current ecosystem

Consensus
#24

Thanks! These are definitely along the lines of thought that we need to explore more.

1. (long term inefficiency) and 2. (long term complexity) are IMO the biggest points I have seen. For better or worse, the short term cost of supporting apps to switch over to something else has almost 100% chance of being less than the long term cost to the whole network.

2. (long term complexity) is IMO generally a point against all token schemes, including SLP-consensus, that effectively turn BCH into a chain of chains system and may dilute other critical efforts such as scaling.

1 Like
#25

Are you absolutely sure?

Aren’t Group Tokens what “In consensus” means? They are mineable by normal miners, SPV-processable and require network-wide consensus change after all.

I mean I could totally be wrong because I am not an active developer so I may be misunderstanding, but AFAIK converting SLP tokens into GROUP tokens would be exactly that: “Injecting SLP into consensus”, but done in a different way.

So, if we consider that “injecting SLP into consensus” may mean something entirely different, this could change the reach of your question and the outcome of this entire discussion.

#26

I think you misunderstood the goal of this specific topic. Where you are looking for solutions to a technical problem, we are instead trying to find out what the wider (ecosystem wide, actually) effects are of keeping the current solution and just making it validated.

As I wrote above, the devs coming up with some new solution will seem to many as us moving on to the next shiny thing. And that is honestly something we should consider because they would be right.

As a great author wrote, its easy to write the start of a novel, you can start all these great new ideas and threads. But the more threads you start, the harder it is to end the novel in a coherent way that ties them all together.

1 Like
#27

You are probably right here, I always try to widen the view and explore all possibilities which perhaps causes me to break out of context.

I did not mean to intrude and break your discussion, this is just how my brain is wired.

Perhaps I should create another topic.

#28

There’s an undertone to these concerns as if we fear success. This may require a discussion of its own. Do we even want consensus tokens? I disagree that consensus tokens could put BCH at scaling risk and believe that NOT having them is an existential risk for BCH - the risk of becoming irrelevant in the grand scheme of things. Sure, we can link BCH to tokens and smart contracts through side-chains like Moeing, but if we’re doing cash then why shouldn’t we enable tokens to be brought back in to BCH chain when they’re to be used as cash. Complex smart contracts can be left out to side-chains etc. but BCH chain is perfect for cash-like uses. Bitcoin: a peer-to-peer electronic cash system.

1 Like
#29

My comment was directed towards the non-functional aspects or infrastructure of the SLP software - not its features. I am a proponent of and have commercially adopted SLP. I support its capabilities being moved into the core protocol but not its implementation.

You just restated my very case using different words. I was pre-empting an argument that we should make SLP part of the core protocol because “we already have so much software” when, in fact, because of it’s poor situation in the non-functional realm, it would have to likely be abandoned and re-written anyway.

#30

Sorry that’s not what I am saying. I am talking about using SLP spec directly, as-is. But I think we agree it would be some pretty gnarly technical debt to make that happen. Still, it would be better if we can find specific qualitative or quantitative descriptions of that debt and that’s what I am looking for here.

1 Like
#31

Here’s one: enforcing the SLP OP_RETURN pattern with consensus would break the assumption that any random byte pattern is allowed after the OP_RETURN. Imagine someone else storing document hashes as OP_RETURN . What are the odds that some hash happens to match some SLP pattern and then it triggers SLP consensus checking which then fails the TX which should be perfectly valid from the document hasher’s point of view.

Maybe nobody is using it like that so this would be purely theoretical, but how to fix this problem if we would consider it to be a worthy problem?

Either all OP_RETURN users would have to add logic to avoid conflict with SLP consensus logic, like adding some non-conflicting prefix: OP_RETURN <prefix> <random data>

or SLP would have to use another opcode. An opcode that would behave the same like OP_RETURN but which would also trigger the SLP consensus logic, like OP_RSLP. This would require SLP users to change how they process TX-es so with this small change we already break out of “as-is”.

So, someone would have to change something down the line, and we could only choose who it would be – OP_RETURN users or SLP users. As you said, gnarly.

3 Likes
CHIP 2021-02 Unforgeable Groups for Bitcoin Cash
#32

Not sure if this is a reason against SLP-in-consensus, just asking in the same spirit: what would be the benefit of adding SLP to consensus over switching tokens to something like Tokeda ?

TLDR; Tokeda is so completely broken and poorly specified its just fantasy land. We should not drag it in until major flaws are addressed and significant gaps are filled in.

#33

It also breaks the principle that the spendability of a coin is determined by combining the unlocking script of the input with the locking script of the output: suddenly you also have to check not only another part of the child transaction, but even another otherwise unrelated output of the parent transaction. A separate OP_RETURN output is just not a logical place to store this data, and the use of this data has no straightforward interaction with the locking/unlocking scripts.

5 Likes
#34

Specific and great point!

#35

Another nice and specific point. I have thought about this one also - what exactly would be the line at which a transaction gets hard-identified as an SLP-attempt. Perhaps it is the prefix alone. It could be more sophisticated than that but I could not find a way for it not to be a heuristic.

1 Like
#36

The part of the scope that it violates is “100% compatibility with current ecosystem” which I tried to specify in slightly more detail in the description. If my SLP app today wouldn’t work 99% as-is on the consensus version of this idea, then it is out of scope.

#37

Thanks for the info, my reply was unwarranted then. I will start a new topic.

#38

I completely agree here. The big point for me here is that changing the middleware without consideration of the current app-layer, as you described - adds significant cost to projects already using SLP.

This is easy to disregard if you are just focused on drawing board projects that may be possible after SLP v2 (or whatever else) reaches consensus and launches next year after May 2022, or you don’t consider the fact that businesses have to spend/hire dev time to write new code whenever the backend requirements change significantly.

Imagine having to get Tether to reimplement the whole thing again on a new system, completely changing the APIs and libraries. Imagine not supporting SLP v1 and just deprecating it without a migration plan.

What would that say to businesses and users who have already invested money and time in SLP? Disregarding this is easy if you are excited by the new shiny thing, and there is no cost to you to drop legacy support for existing users.

The key certainly is to not affect the app-layer at all, and ideally almost zero cost to current SLP projects, and not do this by breaking all the wallets that currently rely on SLP v1 middleware. A community-supported migration plan is a must.

It is also unreasonable to drop support for SLP v1, simply because something is coming in May 2022, which frankly to businesses is very far away right now. Unless you want them to incentivize them to leave in the meantime.

(There is also a small small chance that no superior token solution will reach production or get adopted, let’s say smartbch is filled with problems, in that case you still want current SLP to fall back on, as many challenges and issues it does have at the moment, it is still a solution for token issuers. Therefore, it makes zero sense to me why advocates of successor proposals constantly want SLP v1 support to be dropped/deprecated immedietely.)

I think I should also state the pragmatic reality, we all know to be true here - that BCH devs are not exactly teeming with extra time to rewrite their software from ground up.

#39

Nobody is proposing this AFAIK. SLP v1 is free to exist as long as it wants, and people are starting to think about migration strategies. It’s important to highlight that nothing is forced. Nobody needs to rewrite anything before they’re ready. Consensus layer is just an enabler, it provides building blocks – you don’t have to use the new ones if you already have something built with old ones. However, we’re hoping people will want to use those new ones, and bring more utility to BCH with their future solutions.

Make the new building blocks so good, that even those who have already built something with old ones will be tempted to make use of new ones – because they want it and not because they’re forced. The sooner that new building blocks become a certainty, the sooner people down the line can start drawing up solutions using those blocks.

It would be a waste of time to have to wait for activation to be certain and start building. Things can be done in parallel if there’s good coordination and agreement.

There are better solutions than SLP, but on other blockchains. If they didn’t leave for those till’ now, that tells me they want to stick with BCH and so they certainly won’t leave because they’re getting some new building blocks, which will be optional to use.

3 Likes
#40

Great to hear! Just single point:

I’ve actually heard plenty of influential people on BCH say continuing to maintain SLP v1 is a waste of time. They want to feel vindicated that they were right about SLP when xyz on-chain solution didn’t go through back in the day, they also don’t run any business that will be impacted by the lack of a token solution in the meantime.

I don’t want to name those people, but they know who they are, and if they are reading - I hope they follow my logic and not deprecate and refuse to support SLP v1

And if they are so “disgusted” by the state of current SLP, they should be reminded - nothing is perfect. Current SLP is a product of its time when Amaury was anti-tokens, it’s the best stop-gap we have right now, it works fine most of the time and we need it to tide over to the next phase of BCH.

Edit: The businesses have already suffered and many left last year over IFP. BCH loyalty is not eternal. If there is no community consensus on a path forward (new building blocks like you say), they will leave.

3 Likes
#41

I don’t foresee such an eventuality being very likely as there’s nothing for the core protocol to do to continue “supporting” SLP since it strictly depends on the OP_RETURN capability. That said, if a token capability for the core protocol does look like it’s gaining traction, having a viable path for migration to (and possibly from) the new protocol would certainly be a positive attribute of such a proposal and I suspect quite doable. But, even then, I don’t think adoption of such a capability would have any direct technical impact preventing SLP from continuing to work precisely as it does now should people want that.

1 Like
#42

You are correct that there is nothing that prevents the spec existing on Op_Return.

However, the app-layer relies on functioning middleware and wallet support. Their decisions are definitely having an impact on SLP v1 right now. You may have already noticed somethings simply don’t work, aren’t added or are not supported anymore.

The SLP Foundation can only provide monetary incentives for middleware to be maintained, but if middle layer products (nodes, wallets and APIS) take the view that it is pointless, then we can easily arrive at a point where infra for SLP v1 becomes more and more unusable, and finally a customer service nightmare for businesses reliant on it (Sideshift, Coinflex, USDT, and so on).

If your argument is they can just build their own indexers and so on…then that goes back to the whole “adding cost” argument to businesses that currently add value to the ecosystem.

Not saying it’s that bad yet. My messages are to convince anyone reading, it’s worth supporting because it makes sense to support Legacy before a new system is launched into mainnet, migration plan and all.

1 Like
#43

You guys please move to a separate location. This has moved out of scope for the topic.