rot13maxi

use rand_chacha::ChaCha20Rng;
use schnorr_fun::fun::{KeyPair, Scalar};
use schnorr_fun::{Message, nonce, Schnorr};
use schnorr_fun::adaptor::Adaptor;
use schnorr_fun::fun::marker::Public;
use schnorr_fun::musig::MuSig;
use sha2::Sha256;

fn main() {
    // Little proof of concept. Doesn't actually do real transactions, but you get the idea.

rot13maxi

Result: 12
Circuit Code:
40 24
2 8 8
1 8
2 1 0 8 48 ADD
2 1 48 0 49 ADD
2 1 49 0 40 ADD
2 1 0 8 50 ADD
2 1 50 48 50 ADD

rot13maxi

import { Transaction } from '@scure/btc-signer';
import { Buffer } from 'buffer'; // You may need to import the appropriate library for Buffer
import { sha256 } from '@noble/hashes/sha256';


function ser_compact_size(l: number): Buffer {
  let r: Buffer = Buffer.from('');
  if (l < 253) {
    r = Buffer.from([l]);
  } else if (l < 0x10000) {

rot13maxi

herberger tax with cat + tapscript

operations:

- set price
- pay tax
- auction or seize if taxes not paid
- anyone-can-buy at current price

rot13maxi

<think>
Okay, so I need to summarize this paper titled "ColliderVM: Stateful Computation on Bitcoin". Let me start by reading through the provided content
carefully. The authors are Victor Kolobov, Avihu Levy, and Moni Naor. They're from StarkWare and the Weizmann Institute.

First, the abstract mentions that Bitcoin's scripting language can't handle stateful computations without upgrades like BIP-347 (OP_CAT). Existing
approaches like BitVM use fraud proofs but have capital inefficiencies. The authors propose ColliderVM to eliminate those issues by using hash
collisions instead of signatures for storage.

Looking into the introduction, they explain the limitations of Bitcoin Script: opcode limits, stack size restrictions, and lack of native stateful
computation. Stateful computation requires data persistence (storing data across transactions) and logic persistence (keeping the same code across