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

Consensus
#1

Not to promote the idea, but to understand: is anyone able to summarize the reasons that we cannot directly inject slp into consensus so that all existing software and systems work as-is, just minus the need to validate against an external source?

I think it is important to have a convincing answer to this question because from the outside, if there really is demand for consensus tokens, then this sounds like the most straightforward and least disruptive thing to do, even if the implementation is ugly.

Just random examples:

  • Op returns can be pruned (is this unsolvable for consensus-SLP?)
  • Have to take a snapshot at upgrade and make it forever a part of consensus :grimacing:
  • …

It’s arguable that any top-level token system is going to be similarly ugly in the larger sense that now instead of just tracking BCH, all nodes are tracking some arbitrary set of tokens as well. I don’t understand scaling to be an issue vs. any other simple token solution. I don’t understand “ugly” to be a super compelling reason if it is safe.

1 Like
CHIP 2021-02 Unforgeable Groups for Bitcoin Cash
#2

I shopped this question privately a bit but didn’t get any reasons that it doesn’t work. Not looking for flame wars - under the assumption that explicitly tracking tokens at the node level is a good idea, I’m looking for steel man arguments on why this does not work.

#3

i do not think it is possible for an SPV node to keep track of SLP consensus without downloading and verifying all transactions (or at least all transactions that pertain to the SLP tokens it is tracking)

SPV nodes only downloads headers, then do merkle tree magic to get information about the transactions relevant to it. if we add SLP into consensus would not the SPV node now need to download all transactions to build the SLP utxo which more or less makes the SPV node a full node?

or i guess the SPV node would only need to do it for the tokens it sees but everytime it gets a token from a new SLP it isnt tracking it would need to go back and download the information… something like this

I am not completely confident in this answer. Would like some input from others

2 Likes
#4

I think most of us are in the far left of the Dunning-Kruger curve on this, making it look easier because we have no clue what is actually involved :slight_smile:

Questions that need answering:

  1. what state does the full node actually need to remember?
  2. are states per utxo or per transaction.
  3. the network has a lot of state today, all those SLP transactions made already, how do you handle that? With your goal of 100% compatible you need to make nodes re-parse the history or something. Any better solutions?
  4. do you want full nodes to start serving SLP metadata? (chain-name etc).
  5. much like the UTXO deletes an entry that is spent (making it impossible to find a transaction by txid), can the SLP enabled full node delete info about past SLP transactions / outputs that are spent?
  6. probably more, I don’t really understand SLP well.

So, basically someone needs to do the legwork and figure out what the implications are of this idea. I hope these questions can push us a little in that direction.

2 Likes
#5

Not sure I understand the proposal. Do you intend to keep the SLP data in OP_RETURN rather than implement GROUP tokens?

#6

To be clear, I’m not proposing anything and this has nothing to do with the GROUP proposal. I’m looking for reasons that this idea definitely would not work.

The condition that all existing software and systems would be compatible rules out moving the SLP information out of op return.

2 Likes
#7

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? Seems much bigger to add SLP to consensus than having SLP wallets incrementally upgrade to an SPV-compatible “SLPv2” (and leaving nodes/consensus out of it).

Now that it’s been a few years, we can look back pretty easily – is there anything that has been done with SLP that can’t be done with equal security using an incentive-based token scheme like Tokeda?

The Tokeda strategy supports SPV and other light client modes without requiring any consensus changes. If I understand, that would be the only value in consensus-validated SLP. (Unless we are also forbidding all other uses of OP_RETURN <SLP 0x00>? Then contracts could validate based on prefix, and we’re comparing apples-to-apples with Group.)

I’m afraid I wasn’t paying attention to the token discussion in 2018 – does anyone have any links or background info on why SLP didn’t end up looking more like Tokeda?

This video has some interesting discussion, but I haven’t found any public discussion after it:

(I have no idea how much baggage this question might unearth, so sorry in advance.)

#8

While I was researching Group tokens I discovered this and it references that same document.

Although much of Tokeda is completely unspecified, it seems to propose a system where token holders control a UTXO that should only be spent to the issuer, who has the opportunity to apply arbitrary policy before forwarding the spend to its actual destination. It is therefore an authority-based, SPV capable system. However it ineptly deploys the power of authority-based systems resulting in problems easily solved by other authority systems.

By placing its UTXO on the blockchain, and requiring 2 transactions per transfer, it compares very unfavorably with respect to scalability with many other token proposals, including the permissionless Group tokenization. Authority-based tokens should be able to do much better in their ability to shard the UTXO. For example authority-based extension block systems such as FSHblocks (talk, spec) can move all token transfers completely off-chain – out of history AND UTXO. The only on-chain transfers required are those that are actually moving BCH value between the BCH blockchain and the extension block.

Tokeda’s two transaction “referred transfer” model likely severely limits token interaction with BCH, scripts, and other tokens. Every protocol (for example, onchain betting or probabilistic payments) will likely need to be explicitly programmed into and overseen by the issuing agent. Additionally, by storing user balances in a user-controlled UTXO, it cannot implement many features common to authority based approaches, like recalling tokens.

Given its lack of interactivity with BCH and authority-based architecture, there seems to be no reason whatsoever for Tokeda’s implementation on a blockchain.

3 Likes
#9

Simply said, SLP is what we have. SLP is used. It would be irresponsible to go Microsoft and say its deprecated because we liked this other shiny thing better. SLP deserves better than that.

The question OP write deserves to receive an answer, as to research alternative token systems assumes the answer is those alternatives cost less to the ecosystem (than a miner validated SLP). I dislike assuming things like that.

2 Likes
#10

what would be the benefit of adding SLP to consensus over switching tokens to something like Tokeda

To formulate what Tom said a bit differently:

SLP has a big network effect in terms of tokens on BCH, and the benefit of integrating SLP into consensus (not that I’m advocating it) would be to improve reliability (and perhaps validation performance) of SLP token transactions, something that the introduction of another token scheme does not help with.

2 Likes
#11

I view anything that is based on OP_RETURN for long term storage of state as experimental and, if successful, intended to ultimately be integrated into the core protocol in a standard utxo mechanism. I view the mission of SLP and GROUP tokens as having the ability to denominate utxos in currency/tokens other than BCH.

SLP provided a test platform to try it out. I think they’ve succeeded in demonstrating the utility and value of their use case. Their nonfunctional goals clearly were not considered for this to work at any significant scale as demonstrated by how everything falls over the moment any real tx volume occurs especially with NFTs.

Making SLP core to BCH invites a ton of technical debt and threatens the credibility of BCH as a technology. It should now be done right and SLP implementations will undoubtedly provide a migration path to the core protocol so they don’t have to maintain all this broken supporting software. SLPDB has already been declared “unsupported”.

I think it’s time for SLP to declare victory and we all move forward to a correct implementation of alternative currency/tokens on BCH. This solution should not depend on OP_RETURN for long-term state storage.

2 Likes
#12

In line with the other comments, it’s not a question about the value of the idea and not about alternatives. The scope of the question is intentionally narrow. Basically why would it be infeasible?

2 Likes
#13

This discussion is focused on steel manning the idea that SLP to consensus is a very bad idea (or failing to do so).

  • Regarding OP_RETURNs, it could be setup such that those specific outputs become required/part of consensus.
  • Regarding infrastructure reliability: that’s mostly irrelevant to the question because the presumption is that if individual outputs are part of consensus, then processing them becomes simple. At least roughly as simple as other token schemes. Put another way, take any token scheme and put it outside consensus, and you would have the same difficulties that SLP has.
  • Regarding supporting software: they can just remove the parts requiring validation (which is the unreliable part) and leave everything else. Maintaining an existing ecosystem has clear value and should never be underestimated.

If I try to extract the point that I consider validly against SLP to consensus, it is:

  • Abusing op return long term is technical debt and makes BCH look incompetent.

Is that fair?

3 Likes
#14

Please let’s drop the discussion of Tokeda. It is outside the scope of this topic.

2 Likes
#15

Allow me to pile on if I may and attempt to justify it’s relevance - I suspect a core justification for taking SLP forward is that “much has already been built for it”. The realization that it’s (the infrastructure not the concept of SLP which I regard has having succeeded) junk and will have to be redone regardless kinda takes a lot of the air out of any justification for keeping it in the first place.

Completely fair and concise.

2 Likes
#16

Thanks. FWIW I disagree with the blanket classification of junk. I think it’s important to separate apps and infrastructure. Applications such as coinflex, juungle, zapit, and probably others that would be able to continue with no changes, and no risk to their network effect is valuable regardless of judgement on the quality of their software. Judgements on the infrastructure become mostly irrelevant because it’s only needed due to the fact that it’s not part of consensus. The implementation in consensus would be significantly different from anything now.

Or did I miss your point?

#17

The implementation in consensus would be significantly different from anything now.

This isn’t clear at all from the question.

When saying ‘inject SLP into consensus’, I take it to mean the literal, specified SLP protocol. Unless I am misunderstanding what you meant above.

1 Like
#18

Hmmm…

Let me sum up some of the important points in this topic:

  • SLP has proven to be useful and working despite its problems and inefficiencies
  • SLP ecosystem has brought value to Bitcoin Cash and increased its network effect significantly
  • Therefore, it would be unfair to “throw SLP under the bus” and treat it as a second rate player
  • But we also do not want any kind of ugly, dirty solution complexity-wise, as in we do not want to break the protocol to make SLP better
  • Therefore, we would generally agree it is wise like to make SLP more efficient in the quickest, most robust & clean way
  • We also know, that theoretically OP_GROUP tokens will (in the future) be more efficient, clean and professional solution that makes it easy to create, store and move tokens on BCH network with the least friction

My conclusion is that what we need some kind of middle ground solution between these two.

So I have an idea: What if we could somehow transparently and automatically convert all current SLP tokens to OP_GROUP tokens en masse and grant (airdrop) Group tokens containing all the necessary data from corresponding SLP tokens to the same owners?

With this we would achieve the seemingly “impossible” as in making SLP better, SPV-capable without overloading the complexity of the protocol and we would also improve + bootstrap Group tokens at the same time.

(I am guessing this will probably turn out to be completely unfeasible and/or impractical, but just wanted to add my $0.02c to this discussion)

2 Likes
#19

Ah, but I believe this shows a circular reasoning here.

If you care about products that use some SLP-supporting middleware, but you accept that you can replace the middleware, then we just realized there is a 3-layer stack.

The bottom layer is OP_RETURNs / BCH.
The second layer is middleware (which is overy complex and unmaintained).
The app-layer which we value the most.

So, the question if we want to keep the bottom layer while admitting that the middle layer isn’t really all that relevant to keep, that leads me to believe that you CAN replace SLP as long as the API between the middle-ware layer and the app-layer can be kept the same.

2 Likes
#20

I intend to say that the implementation and the specification are different things. The way to implement the specification if slp utxos become part of consensus is different than when it is entirely decoupled. For example, after it enters consensus, I assume there would be no such thing as an invalid SLP transaction. It would either be valid and happens or invalid and tx rejected (up to some bar of what is considered “attempting” an SLP transaction).