There's this cool article on LongHash talking about Simplicity, the programming language BlockStream is working on for Bitcoin.
It’s all about enabling advanced smart contracts on Bitcoin.
Programming has always been part of Bitcoin's protocol, but here’s where it gets interesting: Simplicity is an upgrade over Bitcoin Script and Miniscript, which is just a higher-level interface to use Bitcoin Script. For Simplicity to roll out, a soft fork is needed, which could change the game for Bitcoin’s progress.
This means we might have a smoother path for upgrades, like Schnorr signatures, that could also be done via soft fork. But just because something can be done technically doesn’t mean it’s the best option. There’s a lot to think about when it comes to improving the protocol.
Don’t hold your breath waiting for this on Bitcoin's main network, but some practical applications might show up sooner than expected. The article emphasizes making Bitcoin a smart contract platform like Ethereum, which I personally think is a stretch. Grubles from Blockstream seems to share my thoughts on that.
So, even though we've been hearing about Simplicity for a while, we might see it launched soon, perhaps in a controlled environment like a Bitcoin federated sidechain. This could serve as a trial run, helping everyone get comfortable with the tech before it’s rolled out on the main Bitcoin network.
Thanks! Very interesting indeed
It's a detail not affecting the overall value of your post, but -just for the sake of pleasant forum interactions- I *think* to have read in the past that Schnorr will be introduced by a soft-fork playing with segwit version (BIP 141: "[...] If the version byte is 1 to 16, no further interpretation of the witness program or witness stack happens, and there is no size restriction for the witness stack. These versions are reserved for future extensions. [...]")... the same way the article imagines Simplicity introduction...
So I guess Longhash author wasn't thinking about "hard-fork VS soft-fork" improvement, instead "one soft-fork per-feature VS Simplicity single soft-fork potentially enabling many features"
Bye! :-)
you are right about addition of Schnorr and it being through a soft-fork but if a new SigHashType (eg. SIGHASH_NOINPUT) were to be added to the protocol i don't think we can find a way to introduce it as a soft-fork anymore.
Not so. It just has to be done by added a new script version or turning a no-op into a checksig operator. P2SH and segwit both did the relevant change-- segwit even effectively added new sighash types in the sense that its sighashes are computed very differently.
I think speculation about simplicity in bitcoin is extremely premature. But I do think simplicity is a much better direction for underlying systems for smart contract than other development we've seen. The first step in advancing this science is having a understanding of the landscape, the next step is building an initial system that answers that understanding in a compelling way... and I think the work on simplicity is doing that, but it's still early work.
A soft-fork is still a consensus change-- you've got to get other people to agree to run it. The point the article was making was that with a sufficiently powerful script you could deploy new behaviour without changing the consensus rules. This wouldn't always be ideal or even useful, because it will generally be much more expensive (fee and resource usage wise) to write a feature yourself compared to consensus support.
E.g. taproot wouldn't make sense done this way, because a big part of the point of it is how efficient it is!
One interesting thing about the architecture of simplicity is that it gives an straight-forward path to promoting an expensive "custom" script to direct consensus support. Nodes can be taught to replace chunks of simplicity code with native code, and because their behaviour can be proven identical these optimizations are not consensus changes. Then there are ways that the costing can be updated to discount the cost of the optimized operations-- essentially have the cost structure for those calls continually re-softforked in on a rolling basis.
So at least conceivably the progression for some custom use could be initial one-off usage at high fee and node resource costs, then optimizing the nodes without changing consensus, and then finally a very narrow consensus to how weights are calculated to change reflect the true cost of the operator now that everyone has been optimized for it.
I was browsing the Blockstream Website, and I found an article about Simplicity.
Nothing really exciting, just another overview of the Simplicity language by Christian Lewe
From Miniscript to Simplicity
I had lost a little bit of track of this project.
I will try to catch up!
I just stumbled across this and thought to myself: why are they still talking about implementing Taproot?
Then I realized it's a 2 years old topic.
As in: Turing completeness? I don't know about that..
Simplicity has numerous potentials, one is the ability to implement vaults on the blockchain, which allows for a devaulting withdrawal interval before a coin gets to its destination, within this period a user can decide to cancel or approve a transaction. This will help reduce the fear of losing private keys to an attacker. As it'll buy enough time for the user to move funds to another wallet, or terminate any transaction altered by the attacker.
With the use of Jet" simplicity will be easily implemented into real life and won't be speculation anymore, and if multiple of them gets implemented, jets can run a simplicity program without the blockchain, but in rare cases, as the blockchain can't easily get out ruled. In addition, the Jets can reduce the bitcoin script size to smaller bytes.
Roconnor-blockstream on a GitHub discussion when a question was raised about this PR also added that simplicity will help make the bitcoin script low in size thereby making it concise.
However, the project is still in progress, but the proposal has good qualities that'll reshape the bitcoin script and add other features that could make the blockchain simple and user-friendly.
https://medium.com/blockstream/simplicity-jets-release-803db10fd589
We should immediately reject anything blockstream proposes due to their conflict of interest selling sidechains, a market created by throttling L1 capacity of bitcoin.
I don't think so. A company can do something you don't like, while still doing other good stuff.
Who do you believe is throttling L1 capacity of Bitcoin? Because if anything, L1 capacity was increased with SegWit. There's just so much data that can fit into a block; which is why different L2 technologies started emerging a few years ago. But it's not the other way round.
That is by decision, not any inherent property of the network. Initially bitcoin had no blocksize limit, which was consistent with the whitepaper. One was later stealth softforked in due to fear of spam attacks. In hindsight spam attacks are a non-issue and can be controlled by min tx fee.
Bitcoin was 1mb in 2010. Moores law shows that capacity doubles every 2 years. So for us in 2022, 64mb is equivalent to 1mb in 2009.
Oh. You're a big-blocker. In 2022. That's fun. Why don't you just go and use BCH, then, and bother writing in a Bitcoin forum? You may find some people to talk about BCH in the Altcoin section, if that's your thing. For anyone else here, big blocks are just an old topic from 2016-2017 that's been discussed to death. I doubt anyone's getting into this argument again in 2022.
And if you really want to discuss anything about Big Block, please do this outside this thread, which I am aldready struggling keeping at par with the incensed subject.
1) That applies to hardware transistors only, not software.
2) The thermodynamic limits that Moore's Law CPUs like the Core 2 have encountered is the reason why you're not using a ~ 1 Terahertz CPU in 2022 and why Bitcoin network is not using 64MB blocks.
@filliponne is Simplicity dormant? I don't see anyone discussing it at all
Huh I could have sworn it was just yesterday that there was a 12 hour backlog on our blockchain with 70mb of transactions waiting to be verified. Lightning isn't solving it, its been 7 years.
Their sidechain (Liquid network) may be unattractive for most people and it's federated (rather than decentralized), but it doesn't mean everything they do is evil or harmful towards Bitcoin. Even though i prefer Minsc which is also easy to use/understand without soft-fork.
This is gross simplified approach towards choosing block size. There are so many things you need to consider such as,
1. Hardware and internet connection price across country is different.
2. Not everyone upgrade their hardware/internet every year.
3. Some expert predict Moore's law hit it's limit soon due to various reason such as physical limitation of silicon-based CPU.
And why hard-forking to big blocks isn't considered a conflict of interest on its own? Because that's the other solution (not on scaling, just on temporary increase in on-chain transactions per second).
You're gravely mistaken. It's getting stronger by the years. It's just that demand is as well. To put it this way: if there wasn't lightning, be sure that the backlog would be worse.
I'm reupping this long-forgotten thread to reprise some news from Blockstream: Simplicity is not dead.
Simplicity Arrives on Liquid Testnet[/url
They also announced Simfony.
That is nice to hear. Even if the timeline is quite uncertain and long-term, luckily, I might add it.