| function isFritzBox(){ | |
| return new Promise(resolve =>{ | |
| let img = document.createElement('img'); | |
| img.onload = _ => resolve(true); | |
| img.onerror = _ => resolve(false); | |
| img.src = 'http://fritz.box/favicon.ico'; | |
| }); | |
| } |
A decaying MultiSig that requires no bitcoin script other than regular MultiSigs.
A 3-of-3 that decays into a 2-of-3 at block height x.
Alice, Bob, and Carol create a 3-of-3 regular MultiSig output.
Alice signs the output with nLocktime = x and SIGHASH_NONE.
She sends this partially signed TX to Bob and Carol.
| // SPDX-License-Identifier: GPL-3.0 | |
| pragma solidity ^0.5.10; | |
| import "https://github.com/summa-tx/bitcoin-spv/blob/master/solidity/contracts/ViewBTC.sol"; | |
| import "https://github.com/summa-tx/bitcoin-spv/blob/master/solidity/contracts/ViewSPV.sol"; | |
| contract Peg { | |
| // | |
| // Security Parameters |
For a threshold point over n points we can assign "weights" or "number of votes per key":
(T₁,w₁), (T₂,w₂), ...,(Tₙ,wₙ).
Instead of using each Tᵢ only once, we also use the keys Tᵢ+H(Tᵢ|1)G, Tᵢ+H(Tᵢ|2)G, ..., Tᵢ+H(Tᵢ|wᵢ)G during the creation of the threshold point. So, if Alice learns Tᵢ she learns the key for all of its votes.
Let's define the total number of votes as N = sum{wᵢ}. Now, we can choose any threshold t < N by enumerating all sums of subsets of size t. We can apply the OR operator to these sums to condense the threshold condition into a single point.
We expect an oracle will publish some number 𝑁 by signing each of its n bits.
Given a constant c, we want to express the spending condition 𝑁 ≥ c in a single adaptor point.
The key idea is to construct an OR operator for adaptor points. This is possible with verifiable encryption. An OR operator allows to condense complex spending conditions into a single point. This prevents the combinatorical explosions that usually occure when using multi-oracles. An OR operator makes spending conditions easily composable. In theory, it even enables arbitrary computations.
We define B₁ to Bₙ to represent the adaptor points for oracle signatures of those bits of 𝑁 that are equal to 1:
TL;DR: We can enhance Bitcoin's scripting capabilities with client-side validation protocols. However, off-chain protocols like RGB or Taro do require some on-chain data.
Suppose we're given a client-side validation scheme for tokens on Bitcoin such as Omni, RGB, or Taro.
We want to express a simple spending condition that we cannot express in Bitcoin Script alone. For example, a hashed timelock contract that uses SHA3 instead of SHA2. So we want to express:
<hash> within a week.
Charge Dollar bills with Bitcoins to create inflation-resitant cash. This idea originated in an old post on Bitcoin Talk. Here's a detailed writeup.
Now the note is worth 1 USD + 5000 sats.
A simple 2-of-3 seed splitting scheme for BIP39 seed phrases by Ruben Somsen.
backup_1 = word_1 xor word_13
backup_2 = word_2 xor word_14
| // | |
| // SIMD Operation for Bitwise Rotations of Seven UInt32 Values in Parallel | |
| // | |
| %builtins bitwise | |
| from starkware.cairo.common.bitwise import BitwiseBuiltin | |
| // How many bitwise steps do we want to rotate? | |
| // 2**t expresses a rotation of t bits to the right. |