This approach is fairly manual, requires the command line, and requires a patched version of Bitcoin Core.
Note: For this guide, code lines prefixed with $ means that the command is typed in the terminal. Lines without $ are output of the commands.
I am not liable for any coins that may be lost through this method. The software mentioned may have bugs. Use at your own risk.
Options contracts can be implemented as trust-minimized smart contracts using Bitcoin script. These contracts don't require oracles feeding the price into the blockchain or any other trusted third party. Recipients will only trust miners to mine (and not reverse) transactions paying a reasonable feerate, securing their payouts.
The underlier of these derivatives can be any digital asset available on a blockchain that can do HLTCs.
The buyer of an American-style call binary option pays a premium (eg: 0.1 BTC) for <seller secret> wich gives the right to buy Q units (quantity) of the underlying asset (100 LTC) at a specified strike price (0.016 BTC per LTC) at any time until the expiration date.
Counting on-chain transactions alone to illustrate pretty much anything is wrong. One should take into account at least TX batching.
A possibly better way is to calculate based on new UTXOs created excluding the change outputs.
Doing rough calculations, we assume the worst case of every TX having a change output, so the results are the most pessimistic version and actual numbers are better.
| Month | TXs | UTXOs created | Net UTXOs [1] | Naive TPS [2] | Actual TPS [3] |
|---|
| # I have 3 btrfs subvolume /root, /home, /nix-store and these are used as the name suggest | |
| # Now, when i create new nixos configuration i can make a snapshot of root and home, before i switch to a new config. | |
| CURRENT_GENERATION=`readlink /nix/var/nix/profiles/system | cut -d'-' -f2`; echo Determined current generation: $CURRENT_GENERATION | |
| sudo mkdir -p /btrfs | |
| # the / is not mounted in my btrfs filesystem by default, because my filesystem root is the /root subvolume | |
| sudo mount /dev/mapper/NixOS /btrfs | |
| sudo btrfs subvolume snapshot /btrfs/root /btrfs/root-$CURRENT_GENERATION-snapshot | |
| # I also make a snapshot of home, because i use gnome or KDE, which contains a lots of config and cache, which can broke by a rollback. | |
| sudo btrfs subvolume snapshot /btrfs/home /btrfs/home-$CURRENT_GENERATION-snapshot |
| #!/usr/bin/env python | |
| import os | |
| import grp | |
| import sys | |
| import stat | |
| import time | |
| import hmac | |
| import boto3 | |
| import tempfile |
|
You'll probably be working with a single smartcard, so you'll want only one primary key ( |
The algorithm takes as input a target which represents a number of blocks within which you would like your transaction to be included in the blockchain. It returns a fee rate that you should use on your transaction in order to achieve this.
The algorithm is conceptually very simple and does not attempt to have any predictive power over future conditions. It only looks at some recent history of transactions and returns the lowest fee rate such that in that recent history a very high fraction of transactions with that fee rate were confirmed in the block chain in less than the target number of blocks.
Transactions can occur with a nearly continuous range of fee rates and so in order to avoid tracking every historical transaction independently, they are grouped into fee rate "buckets". A fee rate bucket represents a range of fee rates within which the algorithm treats all transactions as having approximately the same fee rate and the answer th
(Update, this has been moved to https://github.com/AdamISZ/CoinSwapCS/tree/master/docs as part of that project)
These notes refer to the setup described in table and diagram form here.
The original design is explained in the original CoinSwap post. The reason for attempting to come up with a modification is seen in the diagram line E:
