Topic: (LINK) BitVM: Compute Anything on Bitcoin (Read 834 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)