bitcoin is too useful to die
bitcoin is too useful to die
Replies
Without a network effect as a moat it could easily be replaced. Without a globally stateful L1 there is no on-chain network effect. All it takes is someone to spec out a properly stateful UTXO machine...
At what point is there a sufficient network effect to serve as a sufficient moat?
I find perceptions of network effect interesting. People seem to have very different constructs. For instance, Jon Matonis worked at nChain, worked w/ "Satoshi" & yet...
https://twitter.com/jonmatonis/status/994472382973792257?s=20
At what point is there a sufficient network effect to serve as a sufficient moat?
I find perceptions of network effect interesting. People seem to have very different constructs. For instance, Jon Matonis worked at nChain, worked w/ "Satoshi" & yet...
https://twitter.com/jonmatonis/status/994472382973792257?s=20
My claim is that the BSV protocol fundamentally cannot establish the same kind of network effect as Ethereum because of critical limitations of Bitcoin’s L1. Cries of “but it’s also turing complete now that scripting is fixed” are missing the point.
It has to do with what “on-chain” means and how state is managed. The key entities of BSV want to herd everyone towards using indexers and compute oracles and insist “look, it can do everything ETH can”.
The wild thing is that UTXO *could* support the same kind of statefulness and composability without sacrificing parallel validation characteristics. But the protocol devs are blind to it because they are convinced Bitcoin L1 is general enough.
App level devs like the sCrypt author or @205 are closer to seeing what I’m trying to say than anyone from nchain or planaria corp.
Is there a good article or synopsis that reflects your thought/position well (in more detail) that you can share? Recognize it's hard to put a lot of narrative in the twetch character limitations...
I’m working on it :]
The challenge is as much about narrative crafting as it is about technical writing. I’ll definitely be broadcasting it to BSV devs when it is ready.
Shhhhh.... ;) gonna release something cool soon
can you specify what it is you claim can't be done? BCH hardcoded OP_DSV and then it turned out you could achieve the same outcome with original script.
suspicious of inferring "bitcoin will fail" from "i can't get my idea to work" .
BSV’s solution to DSV is part of the OP_PUSH_TX technique family which is limited in a few “minor” ways and one “major” way, particularly related to unique identifiers (in L1). Take a look at the scrypt guy’s “almost-no-backtracking” L1 tokens (cont)
(cont) https://powping.com/posts/a8323f5a627b1e26ba6d5493b6c61fdb238c0c439017ee265e4fc307d021cfb6
Then look at user @joe’s response in that thread.
All of nchain’s techniques for globally stateful L1 apps make use of compute oracles or as I call them “CSW oracles”, have a look at Run or SuperAsset for case studies.
Btw I didn’t say I thought it will fail, I said it doesn’t create an L1 network effect
As a last note I am open to being proven wrong, in particular I think there could be some way to use a tree structure to encode “backtrack” transactions into the solution provided by xhliu, making it practical at scale even if theoretically constrained.
But to be clear, this is layers of hacks on hacks on hacks, it is absolutely using tricks to work around limitations which could be easily addressed with a very minor architectural improvement with zero drawbacks.
One more side note, if you’re looking at BCH ops then look at GROUP, not DSV. Despite what coingeek has published, OP_PUSH_TX does not enable the same generality, for the reason the commenter @joe responded in that thread by scrypt guy
1. i hope you figure out some merkle magic to track back! what did @xhilu say?
2. GROUP was not forked in though, OP_DSV was. ugly politics surrounded all that.
3. re "zero drawbacks": there is an enormous legal/PR advantage to being able to say that, strictly speaking, BSV is bitcoin (it follows the original protocol). start pushing changes and you lose that . . .
1. He made a thinking face but so far we haven't come up with anything yet. 2 is good to know, although the flip side to the benefits of a finalized protocol is how frustrating it is that BSV's original L1 appears to be "so close yet so far".
For completeness, the other most promising solution is to simply make a generalized unique ID tree that is enforced by miners (although many in the BSV camp would have to reconcile that with their position that all soft forks are "malware").
have you seen this doc?
https://bitcoinfiles.org/t/5fc99c0580b1e23b3ec8859b10dcdec3b2dbe684707e78cd953aef10a37a2a3d
posting it in case it is useful to you.