Topic: (LINK) BitVM: Compute Anything on Bitcoin (Read 797 times)

In your opinion, how far are we to release any product based on BitVM?
I am not impatient, but I think a sensible approach is to have a timeframe. Are we several years away from a release, I guess. Is that correct?
What is the direction of research nowadays?

lasst week, Stanford university professor Dan Boneh introduced Winternitz signatures. these are more compact Lamport signatures and can reduce transaction fees for BitVM by more than 50%.
here is the following link: https://github.com/BitVM/bitvm-js/blob/main/run/examples/winternitz.js

there is now another tool with which you can now also write Bitcoin programs in assembly
you can find a 15 minute yt-video under the following link: BitVM 8 bit CPU: Write Bitcoin programs in Assembly

and here is another help for the whole thing: https://magical-frangipane-149aba.netlify.app/compiler

there is now a new 'tool' called sCrypt which can be used to write smart contracts for BitVM
if you want to find out more, i suggest you visit these two websites:

https://gist.github.com/msinkec/5827d5285a18de8930324f67b880841e

https://scrypt.io/

Because compression can be done in a no-fork way. And it was mentioned many times on bitcointalk.

Paul Sztorc about transaction compression: https://www.truthcoin.info/blog/small-txns/
Some topic about compression, with my responses: https://bitcointalksearch.org/topic/ecdsa-signature-aggregation-for-the-same-address-is-there-a-soft-way-5326218

See? Everything is backward-compatible. Even better: no additional opcode is introduced, and the way you compress things, can be changed, improved, or simply upgraded at will, without changing data in historical blocks and transactions.

It'd be just trade-off between TX size with CPU cycle to compress/decompress the data though which also add additional technical complexity. And IMO we should just let full node software perform compression when the data is stored or transmitted between nodes. Average Bitcoin TX also only have few hundred bytes in size which is tricky to compress.

You're missing a crucial detail. As Robin has said elsewhere:

"this uses no bisection at all. it just dumps the entire hash function into a single "jet leaf". this is the dumb version of implementing it. we'll optimize that later. and focus on completing the bisection over the VM's state transitions first, as that's what gives scalability"

It will be MUCH smaller with bisection, where the only witness data is the root of a Merkle tree whose leaves are all the gates of the hash computation and whose script allows for anyone who notices a wrong computation result to enter into a challenge/response back and forth that will let them slash the funds of the prover.

This huge tx was just made to demonstrate the CAPABILITY of BitVM to perform arbitrary computation (such as SHA3). It was not meant to demonstrate any efficiency. That will come in due course.

You are correct. Even with a super low fee, this logic gate implementation is just too damn large. Particularly the witness data.

I have never seen anything like it before, so it's going to need a lot more work on compressing the size of the bytes before it can have any practical use.

(And speaking of which, why don't we have an opcode for LZMA compression, such as OP_COMPRESS or something?)

Am i reading that right ? Even with a fee of 2.2 sat/vB that contract would cost 21 $ ? Or did i miss something ?

today the first mainnet transaction ^[1] was broadcasted in which a Blake3 hash lock was implemented in the Bitcoin script.
you can find the source code for the opcode 'Blake3' under the following github link: https://github.com/BitVM/BitVM/blob/main/opcodes/examples/blake3.js
Blake3 was implemented because it allows the BitVM to check merkle inclusion proofs.

[1]: https://blockstream.info/tx/d8a091a7f5ffa4993681b3df688968fd274bc76897b8b3953309ffad6055f4b0?expand

Perhaps at this stage, which we can call "beta", it will be easier to test with just 32 bits. Then, if everything really works well in 32, it will be easier to switch to 256.
This is just a guess, it could be completely wrong.

There is a better question: why focus on 32-bit integers at all, while OP_CHECKSIG can handle 256-bit ones? (note that if you use Schnorr signatures, then you can directly add s-values, and use point addition on r-values, just by combining two or more signatures into a single one)

there is now the first bitvm tutorial for writing circuits with python. you can view the almost 10 minute yt-video under the following link:
BitVM Intro: Create Logic Gates and Circuits in Python

OK, so I checked the demo, and quite frankly, I am glad that he chose to do this with testnet.

I imagine if this was done using mainnet and live bitcoins, the site would've been ransacked by hackers by now.


Honestly though, what's the point of implementing addition and subtraction of (un)signed integers when that is already supported by Bitcoin Script?

I found the comparison very interesting, thank you for the explanation.
We just hope that this does not overload the network, as we must look for solutions that speed up the network. The ideal would be to get this working on layer 2.

Thanks for keeping this updated cygan. I'm reading but... I don't get it. Still interesting if that makes sense =)


I understand that. But in a real life escrow, the funds are held by a person as well. In a simple purchase (forum's main use of escrow), the escrower validates receipt by buyer with real-life input before releasing. He handles dispute as well. I don't think we take that away. But in BitVM's example, are also real-life inputs, but funds timelocked under no-one's custody. And released if time expires with no disputes.

It doesn't remove the role of escrower, it simply automates some parts I imagine, and reduces risk for escrower. Escrow publishes smart contract. Buyer activates it. Smart contract seals the deal, locks the funds. In case escrower dies or goes rogue, funds will always be released to seller after timelock expiry, escrow fee also automatically paid out.


It's like Excel claiming they can automate functions, but guys like me find it too complicated. But you could build form/formula templates where you enter what you need being done, and it does its job. Or just like the Ordinal inscription example I mentioned above. As soon as a simple tool was created for dumb use, the market flooded with BRC20s (for better or worse, the point is, the tool brought the idea to practical and easy use).

So BitVM, just like RSK 6 years ago, claiming smart contracts is nice to hear, but until absolute non-techies like me have a tool to use, it won't make sense.

the developer @mononautical has 'launched' a BitVM high-level instruction he calls 'jet leaf'.
instead of hundreds of individual binary logic gates in separate tapleaves, this transaction (on the testnet) executes a taproot leaf script that implements a BitVM circuit component to add two 31-bit unsigned integers. this makes this component bundle the entire operation into a single large 'jet leaf'


https://mempool.space/signet/tx/be9fc1759fea33534fabac244a8fb002d18d9261316f3433deab6b5d720a4f30

A proof of concept for BitVM implementation is now available. Although it's not an overly complex implementation but it demonstrates 3 functions to show that compute with BitVM is possible. The current version is built in Javascript but we should expect more tooling and other useful applications if the development is active.



Repo: https://github.com/supertestnet/tapleaf-circuits/
Demo: https://supertestnet.github.io/tapleaf-circuits/

Seems that btc is tur(n)ing complete(ly)

I agree. I understand the idea and objective of this BitVM, but what is its real use for Bitcoin users' daily lives?

Honestly, it seems more noise than anything else to me. This is not to say that it is not good for new proposals to appear to do different things. But, I've read a lot of information about the purpose of BitVM and I can't see what the use of it is.

OK. They will say it is to make smart contracts, like other networks do. But why have to do it on the Bitcoin network?

i have 4 interesting slides for you, which take up this new topic and maybe show it to us with an example in a visual way to understand it better:



https://twitter.com/BTCillustrated

i also don't want to keep this tweet from @BobBodily from you. in this tweet he does a first update in which he describes some very interesting things - but see and read for yourself:


https://twitter.com/BobBodily/status/1711942512603181145

Affirmative. I was only elaborating on the potential benefits if it was actually implemented.

Since BitVM is akin to a limited version of the EVM and also the restrictions with scripting, It would be a long ride to launch but it's just intriguing to know it is possible to do compute on bitcoin even if it's just theoretically now.

Well, the foundation is there, but as has already been mentioned in this thread, this in its current form is prohibitively slow.

This development is akin to the years when research papers discovered the modern capabilities of AI, but there was no infrastructure to take advantage of that at the time, so it was largely an academic thing, like today with the BitVM whitepaper.

Because we have decentralized money but have very few ways to usebit aside from the standard sending and receiving of UXTOs. If we can get compute on chsin, native applications can be built directly on bitcoin without needing to needing to wrap/unwrap bitcoin just because you want to take part in a decentralized lending protocol on an EVM chain for example.

Imo, this is huge for Bitcoin. It was impossible before now.

The problem with escrow is that it needs "some input" from real life. If I buy a collectible coin, the only way for the escrow to know for sure the seller sent it, is by personally verifying it. I don't think this can be automated in case there's a dispute.

Thanks for the "simple explain" links for people like me.

My recurring questioning goes down this line though: I enjoy reading these developments but am far more interested in simple tools that make use of these kinds of tech easy to use without technical knowhow. I'm not a fan on inscriptions but the way ordinalswallet and others made it easy for dumbos to inscribe is an example of a useful tool making use of a tech for dummies.

I've been waiting/looking for yonks for the simplest use case of smart contracts on Bitcoin I can think of: escrow. After a decade on this forum, we're still using human trust for the simplest escrows.

Why not make a simple escrow tool following the concept of Peggy's timelocked bet in the explanation linked by fillippone? I'm not smart enough to know it's doable but if Peggy's condition can be verified by Bitcoin's network, couldn't it also, with the right coding, prove conditions for many of the things we use on this forum for escrow? Or must it only rely on computable outcomes?

An explanation of how BitVM works:
https://bitcoinmagazine.com/technical/the-big-deal-with-bitvm-arbitrary-computation-now-possible-on-bitcoin-without-a-fork

Another one there:
https://stacker.news/items/279945/r/02b7622c79

Before we become interested in any open-source/Bitcoin project, we have to check how easily the developer is able to explain the concept, otherwise we become more careful or suspicious. If it can't be explained clearly & simply to the understanding of most Bitcoin users, it's a sign they don't really want it to be public/opensource & it could end up centralized/private, if it's not already is... Or they really don't understand what they are talking about...so we need to be really careful with projects the developers don't clearly/simply explain.


Smart-contract, Sidechains, VMs etc, can exist together, independent of the Bitcoin Mainchain without compromising on any of the Bitcoin principles... *Not compromising* makes it part of the Bitcoin Network. Most important of all is that it can be light weight, easy-to-run & easy-to-understand by any user....

There are a few summary articles already out there for the less technical like myself:

• The Big Deal With BitVM: Arbitrary Computation Now Possible on Bitcoin Without a Fork and LightningNetwork
• BitVM: Ushering in a New Era of Bitcoin Computations
• A simple explanation of BitVM

Ping me if you see any other valuable resource.

I only skimmed it, but i find this part is interesting.


Billion sounds impossible and after re-reading BIP 342 there are 3 resource limit regarding Taproot,


In particular, it looks like sigops and stack limit would be main limitation about complexity of script/smart contract.

Well we already saw headless chickens people rush to create a token layer (BRC20) on top of Bitcoin using experimental pieces of software and design practices that were not even reviewed properly, so I guess you can expect people to do just about anything with these "bitcoin smart contracts" once they gain traction.

Having said that though, there's already a lot of deployments of contracts onto Ethereum and people are not just going to drop their bags and switch, especially if they already have a good business.

Does Ethereum have a future if this pans out?

First NFTs (Ordinals) and now Turing-complete smart contracts... it seems BTC can do everything ETH can, but with a much stronger network.

This basically unlocks smart contracts.

However, as noted in the paper, it is very inefficient to express everything in logic gates. A single gate, which would be expected to be used along with thousands or millions of other gates to work an instruction (depending on how small your transistors are), takes so many opcodes to calculate. I am not sure what the solution to this would be in terms of implementing higher-level instructions - at the very least, ASM instructions like the ones used in the Etherum virtual machine.

What sort of useful things can you do with Turing completeness?  They mention games like Chess, Poker, and Go.  I know of a crude version Bitcoin chess that already exists - https://www.youtube.com/watch?v=FHwgr8gzzT0

Purely for academic interest so far, as the proposed model relies on off-chain computations between two sides  one of which is a  prover while the other - a verifier. Extension of the  proposed model   to the parallel computation  with multiple parties involved would be the  challenging task. Do we really need such contracts in the existing  well functioning  mainnet? I don't think so. If academics wanna practice in the testnet, why not. Testnet will endure their jackboot.

We wasted many years as this concept was mentioned for the first time about 8 years ago . Probably i will get attacked but pointing facts isn't a bad thing  https://youtu.be/LdvQTwjVmrE?t=1004
Pay attention to the part that Szabo says : " I have not heard that opinion before . I've never heard anyone call the bitcoin script turing complete , i don't believe that's accurate "

Why do we need to compute any thing on chain? I mean if there is something useful for a simple end user, sure but why do we need to have smart contracts on chain?

this is probably the most exciting discovery in the history of Bitcoin scripting. it seems to knock down virtually every door, giving us access to agreements, sidechains, and powers similar to liquid or evm, all at once, with no forks required.
you can read the whole whitepaper from Robin Linus in the link below


https://bitvm.org/bitvm.pdf

A preview:

BitVM is a computing paradigim to express Turing-complete bitcoin contracts.
This requires no changes to the network's consenus rules. Rather than executing computations on Bitcoin, they are merely verified.....

Discussion and full paper here
https://stacker.news/items/278962/r/02b7622c79

Some Pictures of the paper
https://image.nostr.build/cbf26ea78c1fa9c29a99ebdd043badc71a8c6abe3797f908d91b617add80b101.jpg