Stay up to date on all things crypto and blockchain

> a vault is a two phase transaction A vault transaction can be made in a single-phase if you have the ability to lock spend-paths after a period of time. Does simplicity have that ability? > 848 bytes and the second phase was 474 bytes Interesting. So an upper bound would be around 1300 bytes. Large but still manageable. Thanks for the info!

The short answer is no, because Simplicity (as we currently envision it) is limited to scripting. You can't use Simplicity to implement confidential transactions, or Monero-style ring signatures, or zcash-style blinded UTXO lookups. The long answer, as it applies to script functionality, is more nuanced: We would never need a fork to *enable* new script functionality. But it's likely that anything really novel, if implemented in pure Simplicity, would be too expensive to use without a (soft) fork to replace pure-Simplicity components with optimized C ones. For example, you could in principle implement a STARK verifier in Simplicity, and then your blockchain has support for zero-knowledge proofs. But it would be prohibitively expensive to verify a STARK in pure Simplicity; you really need to be using optimized C code. What's nice about Simplicity though, is that it's easy to stage stuff like this: * Initially you can write a STARK verifier in Simplicity, and even if it's obscenely expensive, you can produce a proof-of-concept and do tests with it, and even do a regtest/signet/testnet deployment. * You can then argue that various compenents (e.g. field arithmetic, specific hashes, Merkle tree lookups, etc) of your STARK ought to be replaced by optimized implementations. This would be a fork - but what's nice is that you have a real usecase to point to, and the proposed fork can be general in application but limited in scope (just a few hashes say) while still getting you a ton of benefit. * Now that your STARKs are at a manageable cost, you could deploy in real life, and later propose another fork to jet out the entire STARK, not just the individual components. This would be a much more extreme fork but you'll have real-world usage to point to, which you can use to argue for safety and value.

> What exactly is proven to be correct? Even if it’s proven that the implementation of an algorithm is correct, the algorithm itself might still have issues. mathematical constraints, generic invariants across all possible executions etc. equivalence to simpler mathematical definitions. now if someone implements an insecure signature algorithm, that is caveat emptor. but you could do something insecure via misuse of bitcoin-script today also, just in simpler ways. the use of a signature or new operation presents risk only to users of it, who opt-in to that. > Then I’d argue that it’s apparently already possible to write provably correct algorithms in C, so that’s one less reason to bake in Simplicity into the base layer. The C code generated by Simplicity could be used instead. it could but bear in mind most simple/efficient things can just be implemented inline at the risk of the coin owner or an application for a given usecase - without the need for the soft-fork upgrade and the ~2year time-frame that takes. Take as an example elltoo lightning, which is more efficient and has better reclaim semantics than current lightning - it needs sighashnoinput. In simplicity that's a simple inline use of some basic Jets and a tiny amount of glue code. I'm not sure if we'll see sighashnoinput available until 2022. That holds back permissionless innovation and the speed of protocol development.