Bitcoin address: bc1p5vtmpp6j4sawj6a6jtwqwfy38pw8lnskd9wdcwkqfuak0p4grd5s9sa8uu
SHOWING: First 60
#75,595,955htmlb137://Pizzaninja_0001#74,410,881text
#73,051,035html
#73,050,971html
#72,654,601html
#71,074,431html
#68,897,216html
#67,807,337html
#67,370,691html
#66,933,558html
#66,850,536html
#66,829,277htmlleordinals.btc#64,500,894text#64,454,640#64,404,399Runestone, oh Runestone, where art thou grace?
Lost in the crypto space, a wild goose chase.
"We'll all be rich!" they cried with glee,
Yet here we stand, empty-handed, can't you see?#64,195,646textDelaystone is coming... or not?#64,120,259textAre you ready for the drop?#64,097,537textAre you ready to get stoned?#64,097,536text
#63,605,507htmltransfer100.core#62,869,827brc-20
#59,222,588htmlIntroducing Runestone
Symbol: ᛤ
Mission: Create a fair, open source, transparent, volunteer, and decentralized initiative to reward people who participated in the first year of the Ordinals Protocol.
Snapshot: Block height 826,600
Discord: https://discord.gg/runestone
7f11d10ffbf9529266c7cc893312ee932442d5b6576b4aaf946a83d717eec61bi0#57,350,882text
#56,275,725html
#35,302,524html# BitVM: Compute Anything on Bitcoin
### Robin Linus
##### [email protected]
### October 9, 2023
> ### Abstract
> BitVM is a computing paradigm to express Turing-complete Bitcoin contracts. This requires no changes to the network’s consensus rules. Rather than executing com- putations on Bitcoin, they are merely verified, similarly to optimistic rollups. A prover makes a claim that a given function evaluates for some particular inputs to some specific output. If that claim is false, then the verifier can perform a succinct fraud proof and punish the prover. Using this mechanism, any computable function can be verified on Bitcoin.
Committing to a large program in a Taproot address requires significant amounts of off-chain computation and communication, however the resulting on-chain foot- print is minimal. As long as both parties collaborate, they can perform arbitrarily complex, stateful off-chain computation, without leaving any trace in the chain. On-chain execution is required only in case of a dispute.
## 1 Introduction
By design, the smart contract capabilities of Bitcoin are reduced to basic operations, such as signatures, timelocks, and hashlocks. The BitVM creates a novel design space for more expressive Bitcoin contracts and also off-chain computation. Potential applications include games like Chess, Go, or Poker, and particularly, verification of validity proofs in Bitcoin contracts. Additionally, it might be possible to bridge BTC to foreign chains, build a prediction market, or emulate novel opcodes.
The main drawback of the model proposed here is that it is limited to the two-party setting with a prover and a verifier. Another limitation is that, for both the prover and the verifier, significant amounts of off-chain computation and communication is required to execute programs. However, these issues seem likely to be solved by further research. In this work, we focus solely on the key components of the two-party BitVM.
## 2 Architecture
Similar to Optimistic Rollups[1] and the MATT proposal (Merkelize All The Things)[2], our system is based on fraud proofs and a challenge-response protocol. However, BitVM requires no changes to Bitcoin’s consensus rules. The underlying primitives are relatively simple. It’s mostly based on hashlocks, timelocks, and large Taproot trees.
The prover commits to the program literally bit-by-bit, however verifying all of that on-chain would be too computationally expensive, so the verifier performs a sequence of carefully crafted challenges to succinctly disprove a false claim of the prover. Prover and verifier jointly pre-sign a sequence of challenge-and-response transactions, which they can later use to resolve any dispute.
The model is designed to simply illustrate that this approach allows for universal com- putations on Bitcoin. For practical applications we should consider more efficient models.
The protocol is simple: Firstly, prover and verifier compile the program into a huge binary circuit. The prover commits to that circuit in a Taproot address which has a leaf script for every logic gate in the circuit. Additionally, they pre-sign a sequence of transactions, enabling a challenge-response game between the prover and the verifier. Now they have exchanged all of the required data, so they can make their on-chain deposits to the resulting Taproot address.
This activates the contract and they can start exchanging off-chain data to trigger state changes in the circuit. If the prover makes any incorrect claim, the verifier can take their deposit. This guarantees attackers always lose their deposits.
## 3 Bit Value Commitment
The bit value commitment is the most elementary component of the system. It allows the prover to set the value of a particular bit to either “0” or “1”. Especially, it allows the prover to set the value of a variable across different Scripts and UTXOs. This is key, as it extends the execution runtime of Bitcoin’s VM by splitting it across multiple transactions.
The commitment contains two hashes, hash0 and hash1. At some later point, the prover sets the bit’s value either to “0” by revealing preimage0, the preimage of hash0 – or the prover sets the bit’s value to “1” by revealing preimage1, the preimage of hash1. If, at some point, they reveal both preimages preimage0 and preimage1, then the verifier can use them as a fraud proof, and take the prover’s deposit. That is called equivocation. Being able to punish equivocation is what makes the commitment binding – it is an “incentive-based commitment”.
Combining bit value commitments with timelocks allows the verifier to force the prover to decide the value of a particular bit within some given time frame.
*Figure 1: A concrete implementation for a 1-bit commitment. To unlock this script, the prover has to reveal either the preimage of hash0 or of hash1. In this example execution, the prover reveals hash1, and sets the bit’s value to “1”. We can have copies of this commitment to enforce a specific value across different scripts.*
For simplicity, from here on, we assume there’s an opcode OP BITCOMMITMENT, which is shorthand for the script above. The opcode consumes two hashes and a preimage of one of the hashes. It puts a bit value on the stack, according to which hash is matched by the preimage.
## 4 Logic Gate Commitment
Any computable function can be represented as a Boolean circuit. The NAND gate is a universal logic gate, so any Boolean function can be composed from them. To keep our model simple, we show that our method works for simple NAND gates. Additionally, we show how to compose gates arbitrarily. Together this demonstrates BitVM can express any circuit.
The implementation of a NAND gate commitment is simple. It contains two bit commit- ments representing the two inputs and a third bit commitment representing the output. The Script computes the NAND value of the two inputs to ensure that it matches the committed output bit.
*Figure 2: Logic gate commitment for a NAND operation. Executing this script requires to reveal values for the bit commitments A, B, and C, such that A NAND B = C holds.*
(Here, we assume for simplicity, that an opcode for OP NAND exists. Actually it does not exist, however, it can be easily implemented using OP BOOLAND and OP NOT.)
## 5 Binary Circuit Commitment
In the previous section we defined NAND gate commitments. We can express any circuit by composing gate commitments. Every step of the execution is committed to in a Tapleaf. They’re are all combined into the same Taproot address, such that the prover could execute any gate in the circuit. Executing a gate requires the prover to open the corresponding gate commitment and set values for its inputs and output bits.
The Taptree might become huge and have a billion Tapleaf Scripts, but its on-chain footprint is minimal.
*Figure 3: A random example circuit which has 8 different NAND gates, and 4 inputs A,B,C, and D. Using billions of gates would allow us to define basically any function.*
*Figure 4: For each gate, the prover’s Taproot address contains a leaf script with a cor- responding gate commitment. This allows the prover to set the values of the circuit’s inputs, (here, A,B,C, and D), at any point later in time.*
## 6 Challenges and Responses
Committing to a circuit is not enough. To disprove an incorrect claim, the verifier has to be able to challenge the prover’s statement. This is possible by them pre-signing a sequence of transactions during setup. The transactions are linked like challenge → response → challenge → response → . . .. If one of the parties stops engaging then, after some timeout, the other party wins the challenge and can take both deposits. As long as both parties are cooperative, they can jointly settle any contract with a 2-of-2 signature. The following mechanism is required only in case of fraud.
*Figure 5: A pre-signed sequence of transactions to perform multiple rounds of challenge- and-response. This sequence is generated during setup.
Vicky chooses a challenge by opening one of the hashlocks in her Tapscript leaves. This unlocks for Paul a specific Tapscript and forces him to execute it. The script forces Paul to reveal the gate commitment challenged by Vicky. Any inconsistent claim can be disproven quickly by repeating this procedure for a few rounds of queries.*
If the prover stops collaborating with the verifier off-chain, the verifier needs a way to force his hand on-chain. The verifier does this by unlocking a hashlock: each of the NAND Tapleaves in the prover’s UTXO can only be spent if the prover knows a preimage held by the verifier. Therefore, the prover can prove that a given Tapleaf executes correctly by revealing its inputs and outputs, but only if the verifier “unlocks” it for him by revealing the preimage to the hash that guards that Tapleaf. Applying binary search, the verifier can quickly identify the prover’s error after just a few rounds of challenge-and-response.
*Figure 6: After each response, Vicky can punish equivocation. If Paul ever reveals two conflicting values for a variable, then Vicky immediately wins the challenge and is allowed to take his deposit. Vicky proves Paul’s equivocation by revealing for any of his bit commitments both of the preimages.*
## 7 Inputs and Outputs
The prover can set inputs by revealing the corresponding bit commitments. Ideally, they reveal the commitments off-chain to minimize their on-chain footprint. In the non- cooperative case the verifier can force the prover to reveal their inputs on-chain.
It is possible to process large amounts of data by exchanging it upfront, but encrypted. This way the prover can reveal the decryption key at a later point in time.
Multi-party inputs are also possible. Gates can have bit commitments from both parties.
## 8 Limitations and Outlook
It is inefficient to express functions in simple NAND circuits. Programs can be expressed more efficiently by using more high-level opcodes. E.g., Bitcoin script supports adding 32-bit numbers, so we need no binary circuit for that. We could also have larger bit commitments, e.g. it is possible to commit to 32 bits in a single hash. Additionally, scripts can be up to about 4 MB in size. Thus, we can implement substantially more than a single NAND instruction per leaf script.
The model proposed here is limited to two parties. However, it might be possible to have two-way channels, and chain them to form a network similar to Lightning. Exploring the two-party setting might yield interesting possibilities for generalization. For example, we can explore a 1-to-n star topology for the network. Another research question is if we can apply our model to the n-of-n setting and create more sophisticated channel factories. Furthermore, we could combine our system with different off-chain protocols, e.g., the Lightning Network or rollups.
Other directions of research include cross-application memory, how to make statements about arbitrary data inscribed into the chain, or off-chain programmable circuits, i.e. an off-chain VM. It also might be possible to apply more sophisticated sampling techniques, similar to STARKs, to check a circuit in a single round.
The next major milestone is to complete a design and an implementation of a concrete BitVM and also of Tree++, a high-level language to write and debug Bitcoin contracts.
## 9 Conclusion
Bitcoin is Turing-complete in the sense that encoding fraud proofs in large Taptrees allows to verify the execution of any program. A major constraint of the model outlined here is that it is limited to the two-party setting. Hopefully, this can be generalized in further works.
## Acknowledgments
Special thanks to Super Testnet and Sam Parker, who always kept refusing to believe that Bitcoin would not be Turing-complete.
## References
[1] Ethereum Research. Optimistic rollups. https://ethereum.org/en/developers/ docs/scaling/optimistic-rollups/, 2022.
[2] Salvatore Ingala. Merkleize all the things. https://lists.linuxfoundation.org/ pipermail/bitcoin-dev/2022-November/021182.html, 2022.
Sponsor BitVM developers: `bc1qf5g6z0py2t3t49gupeqrlewga0qz2etalu4xf9`#35,222,444text
#35,152,046html
#35,056,145html
#34,290,746htmlA Love Letter to Inscription Numbers
The creator of the Ordinals Protocol, Casey Rodarmor, just introduced a proposal that would effectively eliminate inscription numbers. This change would retroactively index previously invalid inscriptions, destabilizing all positive inscription numbers.
But this isn't just about altering the numbers on our JPEGs. The broader concern here is setting a precedent that it is okay to rewrite past events, which undermines the very essence of immutability, a fundamental tenet for all successful crypto-economic protocols.
Nearly every meta-protocol built on top of Ordinals (BRC-20, ORC-20, .sats, .bitmap, <100K, any first-is-first collection, etc.) relies on an assumption that the historical ordering of indexed events would not change. Given that Casey stated this was the case multiple times and that immutability is a core tenant of nearly every crypto protocol this was a very logical assumption to make.
For better or worse, Casey designed the Ordinals Protocol to maintain an exact record of the order of inscriptions that are indexed and now after over $500M in volume and $50M in transaction fees he is proposing that we change that record.
While I recognize Casey's dilemma around inscription numbers making the next upgrade more challenging, this would be akin to Vitalik proposing that blocks from six months ago need to be reordered so that the Ethereum development process can be simplified. This is simply something that you do not do. Though Casey may not have anticipated that people would begin to use inscriptions like blocks in a blockchain this was a completely valid way of using the protocol. In fact, it is a testament to the permissionless nature of the Ordinals Protocol. If anybody would understand that, it would be the creator of an NFT protocol on Bitcoin.
Casey is correct that from a technical perspective, it is far cleaner to fluidly choose what should have been indexed retroactively. This would remove complexity from the development process and make consensus around upgrades much easier. Casey brings the perspective of someone who has spent more time thinking about this protocol than anyone alive and he is undoubtedly correct when looking at it through a technical lens. My goal in writing this is to try to convey that there are other perspectives from the people who might not be as technical but who also deeply love this protocol and choose to prioritize the experience of using it over the code that powers it.
Stability and predictability are paramount for investors who are trying to store value. They anticipate protocol upgrades to shape the future without distorting the past. Balancing this with a perfect technical solution might be challenging, however, nine months and half a billion dollars in, we've committed to this course. If continuing the concept of cursed inscriptions is the major hurdle, they can be excluded, and alternative solutions can organically emerge that will leave their value unaffected and possibly improved.
Lastly, I would be remiss to not mention my deep affection for the actual inscription numbers themselves despite believing that this conversation is about something much bigger.
As a collector I value the simplicity of being able to look at a human-readable inscription number and having its historical provenance intuitively communicated to me. Nothing so elegantly captures the moment in time that an inscription was created than its number. I can’t tell yall how many times I have had collectors inform me how cool they think this quirk in the protocol is!
I 🧡 Inscription Numbers
-Leonidas#33,394,181text
#22,236,871html