Verifying that I control the following Nostr public key: npub1jfgursu7y5k06jnsttum5gc3qa84h0lrc3v7hfqw5vchvr0de8jqf7jn8g
# General | |
**Smart contract** | |
A smart contract is a bitcoin address which, if you send money to it, has this property: only you can recover the money in that address, with an important exception. The exception is: if someone executes a script chosen by you, the script executor may take a fee (set by you). Also, the script may specify an arbitrary address where some or all of the money in the smart contract should go after the script is executed. Alternatively, if the script doesn't specify such an address, any remaining money stays in the smart contract address until it's all consumed by fees or until you recover whatever is left. | |
# Basic tools | |
**Hashlock** | |
A lock which prevents a user from withdrawing funds from an address unless they know a password called a hashlock key |
The following "tapleaf circuit" is a BitVM implementation of this bristol circuit: | |
https://homes.esat.kuleuven.be/~nsmart/MPC/zero_equal.txt | |
The bristol circuit takes 64 bits of input and proves they are all zeros. Mine does the same. | |
More specifically, mine allows Vicky, the verifier, to penalize Paul, the prover, if he provides | |
64 bits and any of them *are not* zeros. | |
More info here: https://github.com/supertestnet/tapleaf-circuits/ |
49 66 | |
3 1 8 8 | |
2 1 8 | |
2 1 0 8 17 AND | |
2 1 0 8 18 XOR | |
2 1 18 16 19 AND | |
2 1 18 16 20 XOR | |
2 1 17 19 21 LOR | |
2 1 21 7 22 AND |
https://mutinynet.com/tx/5e2be1456d1917338729449e60913781fe12b008b5b32cd76eacb953f66bd636 | |
```html | |
<!DOCTYPE html> | |
<html> | |
<head> | |
<meta charset="UTF-8"> | |
<meta name="viewport" content="width=device-width, user-scalable=no"> | |
<script src="https://cdn.jsdelivr.net/gh/6502/sha256@main/sha256.js"></script> | |
<script src="https://unpkg.com/@cmdcode/tapscript@1.4.0"></script> |
I have an independent bitvm sidechain model that works without a federation. Instead, there is a "bridge operator" who assists with depositing money to the sidechain as well as with the "happy path" of withdrawing from the sidechain. In my version, you can withdraw even if the bridge operator ceases operations, because there is also a "sad path" that does not require his ongoing cooperation
the main idea is that when you want to deposit money onto the sidechain you should get a "withdrawal contract" from the bridge operator
the withdrawal contract is done in bitvm and it basically says, if you (the withdrawer) can provide a proof of a valid withdrawal request from the sidechain, the prover has up to X blocks to supply proof that he sent you your money on bitcoin
if he does not supply that proof, you may slash him and take the funds that way
Burrow is a proposal for a federated coinpool on top of hedgehog channels. The coinpool can have a bunch of cool properties:
-
a single-honest-party assumption, so the federation can't rug any user unless the keyholders in the federation are all scoundrels
-
users can onboard into the pool without an on-chain transaction (e.g. maybe you send in coins via lightning, or maybe another user gives you your first coins from within the pool)
-
every onboarded user gets their own wallet interface with their own personal balance and Send/Receive buttons