Topic: Simplicity - A new advanced programming Language for Bitcoin (Read 580 times)

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.

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.

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.

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.

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

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.

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.

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.

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.

We should immediately reject anything blockstream proposes due to their conflict of interest selling sidechains, a market created by throttling L1 capacity of bitcoin.

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

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..

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!

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.

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.

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! :-)

A very interesting piece on LongHash about Simplicity, BlockStream proposed Programming Language for Bitcoin:

How to Make Advanced Smart Contracts Possible on Bitcoin



Bitcoin programming is something that has always been included in Bitcoin protocol


Here lies the difference with Bitcoin Script and also Miniscript, a higher level "interface" language to program using native Bitcoin Script: Simplicity is an evolution of Bitcoin protocol, requiring a soft fork to be implemented.

This opens what could be an interesting idea of making Bitcoin Protocol progress:


No necessity of a hard fork to implement Schnorr, that would be implementable via soft fork. Of course it doesn't mean that if something is technically feasible, it is the best way to do that, as we must take into account also a wide array of argumentation in each way to progress.

No need to hold your breath for this to happen on Bitcoin protocol, even if some real world deployment can happen sooner than you might expect:


The Longhash article point a lot on the "make Bitcoin a smart contract platform like Ethereum". I personally don't like Bitcoin to be considered in the same league of Ethereum. And someone called Grubles, who works at Blockstream, agrees with me:


So, while we have been hearing about simplicity in the past few years, we might be close to its implementation in the coming months, even if in a "walled garden" of a Bitcoin federated sidechain. This would be a little bit of real world testing, smoothing and consensus building around this technology to be later safely implemented in Bitcoin Mainnet.


Learn more on Simplicity:

Webinar by Adam Back, BlockStream CEO.
Simplicity: Next-Gen Smart Contracting Webinar | April 8th 2020 | Dr. Adam Back

Blockstream on Medium:
Simplicity: Jets Release A new developer preview of Simplicity introducing jets to streamline contract development