236 |
237 | OP_SWAP
238 |
239 |
240 | OP_ROT
241 | OP_IF
242 | OP_EQUALVERIFY
243 | 24
244 | OP_CHECKSEQUENCEVERIFY
245 | OP_ENDIF
246 | OP_HASH256
247 |
248 |
249 | OP_ROT
250 | OP_IF
251 | OP_EQUALVERIFY
252 | 18
253 | OP_CHECKSEQUENCEVERIFY
254 | OP_ENDIF
255 | OP_HASH256
256 |
257 |
258 | OP_ROT
259 | OP_IF
260 | OP_EQUALVERIFY
261 | 12
262 | OP_CHECKSEQUENCEVERIFY
263 | OP_ENDIF
264 | OP_HASH256
265 |
266 |
267 | OP_ROT
268 | OP_IF
269 | OP_EQUALVERIFY
270 | 6
271 | OP_CHECKSEQUENCEVERIFY
272 | OP_ENDIF
273 | ```
274 |
275 |
276 | ## References
277 | - [Reddit discussion of the possible uses OP_CHECKSEQUENCEVERIFY](https://www.reddit.com/r/Bitcoin/comments/4p4klg/bitcoin_core_project_the_csv_soft_fork_has/d4i01he/)
278 |
279 |
280 |
281 |
282 |
--------------------------------------------------------------------------------
/proof-of-work.md:
--------------------------------------------------------------------------------
1 | # Proof of Work in Bitcoin Script
2 |
3 | ## Signature Length
4 | The length of the signature can be used as a proof of work committed to the output. Here's a write up of [the ideas of Maxwell and others](https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-November/000344.html) regarding single show signatures.
5 |
6 | `OP_SIZE 57 OP_LESSTHANOREQUAL OP_VERIFY OP_CHECKSIGVERIFY`
7 |
8 | `Using that value reveals the secret key p: p = (2s - h)/r (mod O(g)).`
9 |
10 | The same mechanism can be used to verify a proof of work in script.
11 |
12 | ### Limitations
13 | - The PoW is in ECDSA
14 | - The difficulty granularity is byte size steps
15 |
16 | ## Hash Preimage Challenges
17 | An interactive PoW puzzle is possible with hash pre-images.
18 | A challenger gives a puzzle commitment to a prover. The prover has to bruteforce which hash sequence led to the commitment. We use the mechanism from "7-bit Integer commitments" an reverse it. The challenger commits to A preimage and hash commitment. The prover needs to bruteforce all possible hashs to find the path from preimage to commitment. The prove of knowledge of the puzzle solution is the integer.
19 | [Here is an example transaction.](https://blockstream.info/nojs/tx/a3803be4f3da166096b4408ffe36a07750f31bb2b58bd660f8f1a0c59a99dda6)
20 |
21 |
22 | ### Features
23 | - The difficulty granularity is bit size
24 |
25 | ### Limitations
26 | - Trusted challenger is required
27 | - challenger can cheat by providing an unsolvable puzzle.
28 | - yet, prover can proof challenger cheated by bruteforcing all possible
29 | - A ZKP might help to prove that a solution exists.
30 | - opcodes grows linear with difficulty
31 | - maximum difficulty is 30 bits ~ 5 bytes
32 |
33 |
34 | ## PoW in Private Key
35 | The challenger creates a N-bit commitment with two hash functions. The secret is a private key. N is the Difficulty. He funds the corresponding address. He publishes the address and the pre image.
36 |
37 | Alice challenges Bob for a proof of work.
38 | We use two distinct hash functions `H1` and `H0`.
39 |
40 | 1. Alice chooses a commitment `C` randomly. `C` is about 32 bytes.
41 | 2. Alice chooses a random bit string `x` of length `N`. For example `x = 110101`.
42 | 3. Alice derives a secret key `X`. In our example `C = H1(H1(H0(H1(H0(H1( x ))))))`.
43 | 4. Alice derives the corresponding public key and broadcasts a funding transaction.
44 | 5. Bob starts the race as soon as he learns `C`.
45 |
46 | ### Features
47 | - The granularity of the difficulty is bit size
48 | - No opcodes. Fully off-chain.
49 | - Actually no hash chain is required. It is just a relict from previous ideas. Simply use a nonce as in bitcoin's PoW. Verification time is constant in `N`.
50 | - Any proof of work algorithm can be used.
51 | - ASIC resistance is possible if the algorithm changes drastically for every new challenge.
52 |
53 | ### Limitations
54 | - Trusted dealer is required. He can cheat by providing an unsolvable puzzle.
55 |
56 | ### Zero Knowledge proof
57 | We can staple a zero-knowledge proof to the puzzle to prove a solution exist.
58 | Using [Bulletproofs](https://web.stanford.edu/~buenz/pubs/bulletproofs.pdf) a "SHA256 preimage proof is 1.4 KB and takes 750 ms to verify." and it is trustless.
59 |
60 |
61 | ## Multiple Hash functions
62 | To increase the number of bits in our schemes we can use multiple hash functions in varying orders. This helps to add entropy to committed values with low entropy.
63 |
64 | ```
65 | OP_RIPEMD160
66 | OP_SHA1
67 | OP_SHA256
68 | OP_HASH160
69 | OP_HASH256
70 | ```
71 |
72 |
73 |
74 |
75 | # Proof of Work in Bitcoin Script 2
76 |
77 |
78 | The following script allows everyone to spend; the shorter your signature the earlier you can spend.
79 | ```
80 | OP_SIZE
81 | OP_CHECKSEQUENCEVERIFY OP_DROP
82 |
83 | OP_CHECKSIGVERIFY
84 | ```
85 |
86 | The point `R = 1/2 G` has the smallest known `x` coordinate -- `x = 0x3b78ce563f89a0ed9414f5aa28ad0d96d6795f9c63`. If the public key is chosen `P = 1 G` then the ECDSA signature becomes `s=2(H(m)+x)`. So, the smaller `H(m)` the smaller `s` (as long as it is bigger than `x ~ 2^165`). Thus, the above output is spendable by the miner mining the lowest TX hash. Also [see the discussion here](https://gist.github.com/RobinLinus/95de641ed1e3d9fde83bdcf5ac289ce9)
87 |
88 |
89 | # Related Work
90 |
91 | - [proof of work via ecdsa signature length (by VzxPLnHqr)](https://github.com/VzxPLnHqr/sig-pow)
92 |
--------------------------------------------------------------------------------
/rock-paper-scissors.md:
--------------------------------------------------------------------------------
1 | # Rock Paper Scissors
2 |
3 | Both Alice and Bob make pre-image length commitments as described in [betcoins](betcoins.md).
4 |
5 |
6 | For compact code we use some group theory.
7 |
8 |
9 | ## Solution 1: Additive Group mod 3
10 |
11 | ```
12 | btcdeb "[
13 |
14 | OP_DUP
15 | OP_HASH160
16 | 74f36c5e0c6ad544a3279502ae7c9bce698012b1
17 | OP_EQUALVERIFY
18 |
19 | OP_SIZE
20 | OP_NIP
21 |
22 | OP_DUP
23 | 16
24 | 19
25 | OP_WITHIN
26 | OP_VERIFY
27 |
28 | 15
29 | OP_SUB
30 |
31 | OP_SWAP
32 |
33 | OP_DUP
34 | OP_HASH160
35 | 80ad9c03fd4f8d1eebfadc515df7956ddf3c3dc7
36 | OP_EQUALVERIFY
37 |
38 | OP_SIZE
39 | OP_NIP
40 |
41 | OP_DUP
42 | 16
43 | 19
44 | OP_WITHIN
45 | OP_VERIFY
46 |
47 | 15
48 | OP_SUB
49 |
50 |
51 | OP_2DUP
52 | OP_EQUAL
53 | OP_IF
54 | OP_2DROP
55 | cccccccc
56 | OP_ELSE
57 |
58 | OP_1ADD
59 |
60 | OP_DUP
61 | 2
62 | OP_GREATERTHAN
63 | OP_IF
64 | OP_DROP
65 | 1
66 | OP_ENDIF
67 |
68 | OP_EQUAL
69 | OP_IF
70 | aaaaaaaa
71 | OP_ELSE
72 | bbbbbbbb
73 | OP_ENDIF
74 |
75 | OP_ENDIF
76 |
77 | OP_DROP
78 | OP_TRUE
79 |
80 | # ]" bbbbbbb0bbbbbbb0bbbbbbb0bbbbbbb0bbbb aaaaaaa0aaaaaaa0aaaaaaa0aaaaaaa0aaaa
81 |
82 | ```
83 |
84 | ## Solution 2: Multiplicative Group mod 7
85 | We want a multiplicative group of three elements.
86 | The finite field to the prime 7 has the subgroup `{1,2,4}`. `2` is a generator of this subgroup.
87 | Both Alice and Bob commit to an element of that group; `A` and `B` respectively.
88 | We check if Alice is Bob's "successor" by multiplying her value with the generator `2`.
89 | Three cases:
90 | - `A == B`: That's a tie.
91 | - `A*2 == B`: Alice Won
92 | - `A == B*2`: Bob Won
93 |
94 |
95 | ```
96 | OP_DUP
97 | OP_HASH160
98 | < Alice's Commitment >
99 | OP_EQUALVERIFY
100 |
101 | OP_SIZE
102 | OP_NIP
103 |
104 | OP_DUP
105 | 16
106 | 20
107 | OP_WITHIN
108 | OP_VERIFY
109 |
110 | 15
111 | OP_SUB
112 |
113 | OP_DUP
114 | 3
115 | OP_NUMNOTEQUAL
116 | OP_VERIFY
117 |
118 | OP_SWAP
119 |
120 | OP_DUP
121 | OP_HASH160
122 | < Bob's Commitment >
123 | OP_EQUALVERIFY
124 |
125 | OP_SIZE
126 | OP_NIP
127 |
128 | OP_DUP
129 | 16
130 | 20
131 | OP_WITHIN
132 | OP_VERIFY
133 |
134 | 15
135 | OP_SUB
136 |
137 | OP_DUP
138 | 3
139 | OP_NUMNOTEQUAL
140 | OP_VERIFY
141 |
142 |
143 | OP_2DUP
144 | OP_EQUAL
145 | OP_IF
146 | OP_2DROP
147 | < Case Tie >
148 | OP_ELSE
149 |
150 | OP_DUP
151 | OP_ADD
152 |
153 | OP_DUP
154 | 7
155 | OP_GREATERTHAN
156 | OP_IF
157 | OP_DROP
158 | 1
159 | OP_ENDIF
160 |
161 | OP_EQUAL
162 | OP_IF
163 | < Case Alice Wins >
164 | OP_ELSE
165 | < Case Bob Wins >
166 | OP_ENDIF
167 |
168 | OP_ENDIF
169 | ```
170 |
171 |
172 | Here is [an example transaction](https://blockstream.info/nojs/tx/4586f390acbf9c34157f6331ad70dbb8d476edb65d86aa17e6c481a79c97c91c?expand)
173 |
174 | ### Limitations
175 | - Unnecessarily complex: We used the multiplicative group with three elements. That group is isomorphic to the additive group `{0,1,2}`. In that group the algorithm is much simpler. It uses only addition and less opcodes.
176 |
177 |
178 |
179 |
180 |
181 |
182 |
--------------------------------------------------------------------------------
/schnorr-magic.md:
--------------------------------------------------------------------------------
1 | # Schnorr Magic
2 |
3 | - [MuSig2 Simple Two-Round Schnorr Multi-Signatures](https://eprint.iacr.org/2020/1261.pdf)
4 | - [FROST: Flexible Round-Optimized Schnorr Threshold Signatures](https://eprint.iacr.org/2020/852.pdf)
5 | - [ROAST](https://eprint.iacr.org/2022/550)
6 | - [Scriptless Scripts](https://github.com/ElementsProject/scriptless-scripts)
7 | - [Discrete Log Contracts](https://adiabat.github.io/dlc.pdf)
8 | - [Scriptless Lotteries on Bitcoin from Oblivious Transfer](https://telaviv2019.scalingbitcoin.org/files/scriptless-lotteries-on-bitcoin-from-oblivious-transfer.pdf)
9 |
--------------------------------------------------------------------------------
/script-editor/index.html:
--------------------------------------------------------------------------------
1 |
6 |
20 |
123 |
186 |
220 |
221 |
282 |
314 |
330 |
--------------------------------------------------------------------------------
/script-editor/readme.md:
--------------------------------------------------------------------------------
1 | # Examples
2 |
3 | -[composed opcodes (hacky)](https://coins.github.io/bitcoin-scripts/script-editor/#JHsgISEobGliID0gd2luZG93KT8nJzonJ30KCiR7IGxpYi5PUF9NVUwyID0gYE9QX0RVUCBPUF9BRERgfQokeyBsaWIuT1BfTVVMNCA9IGAke09QX01VTDJ9ICR7T1BfTVVMMn0gYH0KJHsgbGliLk9QX01VTDggPSBgJHtPUF9NVUw0fSAke09QX01VTDJ9IGB9CiR7IGxpYi5PUF9NVUwxNiA9IGAke09QX01VTDh9ICR7T1BfTVVMMn0gYH0KJHsgbGliLk9QX01VTDMyID0gYCR7T1BfTVVMMTZ9ICR7T1BfTVVMMn0gYH0K)
4 |
--------------------------------------------------------------------------------
/split-into-bits.md:
--------------------------------------------------------------------------------
1 | # Split Into Bits
2 |
3 | Algorithms to split a stack item into a string of bits.
4 |
5 | ## Lookup Table
6 |
7 | Here, we use a lookup table to circumvent the `OP_IF, OP_ELSE, OP_ENDIF` branches. This idea can get further optimized and can act as a basis to implement bitwise operations such as XOR.
8 |
9 | ```js
10 | `
11 | // Lookup table
12 | ${ 2**1 }
13 | 0
14 | ${ 2**2 }
15 | 0
16 | ${ 2**3 }
17 | 0
18 | ${ 2**4 }
19 | 0
20 | ${ 2**5 }
21 | 0
22 | ${ 2**6 }
23 | 0
24 | ${ 2**7 }
25 | 0
26 |
27 | // The input value
28 | // We use a bit string only for debugging
29 | // It's a single item on the stack
30 | ${ 0b01100001 }
31 |
32 | DUP
33 | ${ 2**7 }
34 | GREATERTHANOREQUAL
35 | 1ADD
36 | ROLL
37 | SUB
38 | SWAP
39 | TOALTSTACK
40 |
41 | DUP
42 | ${ 2**6 }
43 | GREATERTHANOREQUAL
44 | 1ADD
45 | ROLL
46 | SUB
47 | SWAP
48 | TOALTSTACK
49 |
50 | DUP
51 | ${ 2**5 }
52 | GREATERTHANOREQUAL
53 | 1ADD
54 | ROLL
55 | SUB
56 | SWAP
57 | TOALTSTACK
58 |
59 | DUP
60 | ${ 2**4 }
61 | GREATERTHANOREQUAL
62 | 1ADD
63 | ROLL
64 | SUB
65 | SWAP
66 | TOALTSTACK
67 |
68 | DUP
69 | ${ 2**3 }
70 | GREATERTHANOREQUAL
71 | 1ADD
72 | ROLL
73 | SUB
74 | SWAP
75 | TOALTSTACK
76 |
77 | DUP
78 | ${ 2**2 }
79 | GREATERTHANOREQUAL
80 | 1ADD
81 | ROLL
82 | SUB
83 | SWAP
84 | TOALTSTACK
85 |
86 | DUP
87 | ${ 2**1 }
88 | GREATERTHANOREQUAL
89 | 1ADD
90 | ROLL
91 | SUB
92 | SWAP
93 | TOALTSTACK
94 |
95 | FROMALTSTACK
96 | FROMALTSTACK
97 | FROMALTSTACK
98 | FROMALTSTACK
99 | FROMALTSTACK
100 | FROMALTSTACK
101 | FROMALTSTACK
102 |
103 | `
104 | ```
105 |
106 | #### Generic n-bit Template
107 |
108 | ```js
109 | const N = 30; // The bit length
110 |
111 | [
112 |
113 | // Push the lookup table onto the stack
114 | loop( N - 1, i => `
115 | ${ 2 ** (i + 1) }
116 | 0
117 | `),
118 |
119 | // The input value
120 | // We use a bit string for debugging
121 | // It's a single item on the stack
122 | 0b0001000000000001,
123 |
124 | // The loop
125 | loop( N - 1, i => `
126 | DUP
127 | ${ 2 ** (N - 1 - i) }
128 | GREATERTHANOREQUAL
129 | 1ADD
130 | ROLL
131 | SUB
132 | SWAP
133 | TOALTSTACK
134 | `),
135 |
136 | // Read the result from the altstack
137 | loop( N - 1, _ => `FROMALTSTACK` ),
138 |
139 | ]
140 | ```
141 |
142 |
143 | ## Nullify Leading Bits
144 |
145 | ```js
146 | const N = 16; // The bit length
147 | const T = 8; // Number of leading bits to nullify
148 |
149 | [
150 |
151 | // Push the lookup table onto the stack
152 | loop( T, i => `
153 | ${ 2 ** (N - T + i) }
154 | 0
155 | `),
156 |
157 | // The input value
158 | // We use a bit string for debugging
159 | // It's a single item on the stack
160 | 0b1010110011111111,
161 |
162 | // The loop
163 | loop( T, i => `
164 | DUP
165 | ${ 2 ** (N - 1 - i) }
166 | GREATERTHANOREQUAL
167 | 1ADD
168 | ROLL
169 | SUB
170 | NIP
171 | `),
172 |
173 | ]
174 | ```
175 |
176 | ### Reusing the Lookup Table
177 |
178 | ```js
179 | const N = 16; // The bit length
180 | const T = 8; // Number of leading bits to nullify
181 |
182 | // The loop
183 | const nullify_T_bits = loop( T, i => `
184 | DUP
185 | ${ 2 ** (N - 1 - i) }
186 | GREATERTHANOREQUAL
187 | ${ i * 2 + 1 }
188 | ADD
189 | PICK
190 | SUB
191 | `);
192 |
193 | // The loop which also drops the lookup table
194 | const nullify_T_bits_drop = loop( T, i => `
195 | DUP
196 | ${ 2 ** (N - 1 - i) }
197 | GREATERTHANOREQUAL
198 | 1ADD
199 | ROLL
200 | SUB
201 | NIP
202 | `);
203 |
204 |
205 | [
206 |
207 | // Push the lookup table onto the stack
208 | loop( T, i => `
209 | ${ 2 ** (N - T + i) }
210 | 0
211 | `),
212 |
213 | // First input
214 | 0b1010110011111110,
215 | nullify_T_bits,
216 | 'TOALTSTACK',
217 |
218 | // Second input
219 | 0b1010110011111100,
220 | nullify_T_bits,
221 | 'TOALTSTACK',
222 |
223 | // Third input
224 | 0b1010110011111000,
225 | nullify_T_bits,
226 | 'TOALTSTACK',
227 |
228 | // Fourth input
229 | 0b1010110011110000,
230 | nullify_T_bits_drop,
231 |
232 | 'FROMALTSTACK',
233 | 'FROMALTSTACK',
234 | 'FROMALTSTACK',
235 |
236 | ]
237 | ```
238 |
239 |
240 | ### Nullifying Trailing Bits
241 |
242 | ```js
243 | const N = 8; // The bit length
244 | const T = N - 6; // Number of trailing bits to nullify
245 |
246 | // The loop
247 | const nullify_T_bits = [
248 | 'DUP',
249 | loop( T, i => `
250 | DUP
251 | ${ 2 ** (N - 1 - i) }
252 | GREATERTHANOREQUAL
253 | ${ i * 2 + 2 }
254 | ADD
255 | PICK
256 | SUB
257 | `),
258 | 'SUB'
259 | ];
260 |
261 | // The loop which also drops the lookup table
262 | const nullify_T_bits_drop = [
263 | 'DUP',
264 | loop( T, i => `
265 | DUP
266 | ${ 2 ** (N - 1 - i) }
267 | GREATERTHANOREQUAL
268 | 2
269 | ADD
270 | ROLL
271 | SUB
272 | NIP
273 | `),
274 | 'SUB'
275 | ];
276 |
277 |
278 | [
279 |
280 | // Push the lookup table onto the stack
281 | loop( T, i => `
282 | ${ 2 ** (N - T + i) }
283 | 0
284 | `),
285 |
286 | // First input
287 | 0b11111110,
288 | nullify_T_bits,
289 | 'TOALTSTACK',
290 |
291 | // Second input
292 | 0b11111100,
293 | nullify_T_bits,
294 | 'TOALTSTACK',
295 |
296 | // Third input
297 | 0b11111000,
298 | nullify_T_bits,
299 | 'TOALTSTACK',
300 |
301 | // last input
302 | 0b11110000,
303 | nullify_T_bits_drop,
304 |
305 | 'FROMALTSTACK',
306 | 'FROMALTSTACK',
307 | 'FROMALTSTACK',
308 |
309 | ]
310 | ```
311 |
--------------------------------------------------------------------------------
/tic-tac-toe.md:
--------------------------------------------------------------------------------
1 | # Tic Tac Toe in a Schnorr Signature
2 |
3 | A sketch of some ideas to implement the game [Tic Tac Toe](https://en.wikipedia.org/wiki/Tic-tac-toe) in Bitcoin. This model requires only a single onchain transaction containing a single Schnorr signature.
4 | Scriptless scripts and the replace-by-fee mechanism are used to implement the full game logic.
5 |
6 | Before the game starts the tree of possible moves is scaffolded out. There are 26830 different games. Every possible move is represented by a transaction with a 2-of-2 MuSig splitting the key among both players.
7 | All of these transactions compete to spend the same output. If any transaction hits the chain it gives the bitcoins to the current player (or refunds both players in case of a draw). There are no further scripts.
8 | In the non-cooperative case older transactions are replaced by newer transactions via the replace-by-fee mechanism.
9 |
10 |
11 |
12 | Before the game starts, each player traverses the tree of game states and signs every possible move of their opponent. The player subtracts his signature by his signature of the parent transaction that leads to this particular game state.
13 | These so-called *adapter signatures* form a tree which is exchanged upfront. This ensures a player can execute a transaction exactly if the opponent executed the preceding move, that lead to that particular game situation. The set of transactions that a player can complete at a point in time represents the set of valid moves they can choose from.
14 |
15 | Note that the index of a move is actually represented by the nonce of the signature. The message is always simply one of three possibilities: "Player A takes the money", "Player B takes the money", or "Both players are refunded."
16 |
17 | The game starts once the scaffold is complete. The two players take turns revealing signatures to each other.
18 | - In the cooperative case the players send the signatures to each other privately.
19 | - In this case only a single transaction has to be broadcasted to the bitcoin network.
20 | - In the non-cooperative case players take turns replacing each others' transactions with the replace-by-fee mechanism (RBF).
21 | - There are at most 9 rounds in Tic Tac Toe.
22 | - An honest player can always update to the most recent state without going through intermediate states.
23 | - The fee of a newer transaction is always at least 1 sat/byte higher than in the preceding round.
24 |
25 | Only one last transaction hits the chain and spends the output.
26 |
27 |
28 | ## Shortcomings
29 | - The game must end before an intermediate game state hits the chain.
30 | - Using RBF as consensus mechanism is risky. This update mechanism depends on the mempool of bitcoin miners. We assume no player cooperates with a miner.
31 | - The players have to sign and exchange the whole game tree upfront, which is about 25000 signatures per game.
32 |
33 |
--------------------------------------------------------------------------------
/tictactoe.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/coins/bitcoin-scripts/016f919c82f9e47f7eba4029eddce714ef261fee/tictactoe.png
--------------------------------------------------------------------------------
/token_auction.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/coins/bitcoin-scripts/016f919c82f9e47f7eba4029eddce714ef261fee/token_auction.png
--------------------------------------------------------------------------------
/weighted-multi-sig.md:
--------------------------------------------------------------------------------
1 | # Weighted Multi-Signature
2 |
3 | We can express a weighted n-of-m voting by duplicating keys and signatures.
4 |
5 |
6 | ## Regular Multi-Sig
7 | Regular 3-of-5 example:
8 | ```
9 | 3
10 |
11 |
12 |
13 |
14 |
15 | 5
16 | OP_CHECKMULTISIG
17 | ```
18 | Redeem example:
19 | ```
20 |
21 | ```
22 |
23 | ## Weighted Multi-Sig 3-of-5
24 | Weighted 3-of-5 with `pub_key_1` having up to two votes:
25 | ```
26 | OP_IF
27 | OP_DUP
28 | OP_ENDIF
29 |
30 | 3
31 |
32 | OP_DUP
33 |
34 |
35 |
36 | 5
37 | OP_CHECKMULTISIG
38 | ```
39 |
40 | Redeem example:
41 | ```
42 | 0
43 | ```
44 |
45 | or
46 | ```
47 | 1
48 | ```
49 |
50 |
51 | ## Weighted Multi-Sig 4-of-7
52 | Weighted 4-of-7 with `pub_key_1` having exactly three votes:
53 |
54 | ```
55 | OP_DUP
56 | OP_DUP
57 |
58 | 4
59 |
60 | OP_DUP
61 | OP_DUP
62 |
63 |
64 |
65 | 7
66 | OP_CHECKMULTISIG
67 | ```
68 |
69 | Redeem example:
70 | ```
71 |
72 | ```
73 |
74 | or
75 | ```
76 |
77 | ```
78 |
79 |
80 | # Improved Weighted MultiSig
81 |
82 | Every person of the weighted MultiSig can have an explicit weight. This scripts checks that the sum of the participants is greater than the threshold.
83 |
84 | ```
85 | IF
86 |
87 | CHECKSIGVERIFY
88 |
89 | ELSE
90 | 0
91 | ENDIF
92 | TOALTSTACK
93 |
94 | IF
95 |
96 | CHECKSIGVERIFY
97 |
98 | ELSE
99 | 0
100 | ENDIF
101 | TOALTSTACK
102 |
103 | IF
104 |
105 | CHECKSIGVERIFY
106 |
107 | ELSE
108 | 0
109 | ENDIF
110 | TOALTSTACK
111 |
112 | ...
113 |
114 |
115 |
116 | FROMALTSTACK
117 | FROMALTSTACK
118 | FROMALTSTACK
119 |
120 | ...
121 |
122 | ADD
123 | ADD
124 | ADD
125 |
126 | GREATEREQUAL
127 | VERIFY
128 |
129 | ```
130 |
--------------------------------------------------------------------------------