Not possible by design (unless you accept exponential script sizes)
Post by twetch#2782
Again I wish to reiterate that the more BSV protocol devs keep saying "BSV can do everything ETH can" the more crushing the disappointment will be for creative devs like OP
What the chain says
- Block
- 658 159
- Time
- 2020-10-23T19:26:48Z
- Signer
- 1486QpNpWYjokSfc3DxChCQG6gS2cTvVpL
- App
- twetch
- Type
- post
- Content type
- text/plain
- Name in tx
- twetch#2782
Fields the transaction did not carry are omitted. Open the payload to see the bytes as stored.
Signed by
1486QpNpWYjokSfc3DxChCQG6gS2cTvVpL VerifiedReplies (20)
Haha. How much do you want to bet?
I'll bet 10 BSV, just don't show me something that grows like O(k^n) script size, or uses compute oracles to string transactions together
Can you please clarify what is k and n in the example above?
Also, can you please define 'compute oracles'? Just want to make sure we are on the same page.
k is something like 'number of distinct opcodes', but I'll accept k=2 as well. n is script length you are trying to evaluate. Compute oracles will be defined in a paper I'm currently writing, which btw covers your SuperAsset design as well
I have something neat brewing though :]
The real fundamental limitation of bitcoin L1 has to do with state management, not loops/jumps etc
I look forward to it!
Can you characterize or quantify the "limitations" as it pertains to state management?
Each day that passes, I'm realizing there are less obstacles to what I thought was impossible before.
This will also be covered in coming paper but for now have a look at xhliu's "tokens without backtracking (almost)" and then @702's comment in this thread: https://powping.com/posts/a8323f5a627b1e26ba6d5493b6c61fdb238c0c439017ee265e4fc307d021cfb6
Another great post by xhliu, in this case imagine how you would implement the EVM's CALL op for distinct "contracts" deployed without a priori knowledge of each other: https://xiaohuiliu.medium.com/how-to-scale-ethereum-today-9bbaece3fb2e
🤔