Written for fairly adept technical users, preferably of Debian GNU/Linux, not for absolute beginners.
You'll probably be working with a single smartcard, so you'll want only one primary key ( |
You'll probably be working with a single smartcard, so you'll want only one primary key ( |
#!/usr/bin/env python | |
import os | |
import grp | |
import sys | |
import stat | |
import time | |
import hmac | |
import boto3 | |
import tempfile |
# 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 |
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] |
---|
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.
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.
Described here is a variant of what has previously been published under the name "P2EP" or Pay-to-endpoint, in which A pays B but B contributes utxos, i.e. it's a coinjoin-payment.
I'm using the term "payjoin" here to refer to using that idea, but not including a URI/endpoint specific to B, and not allowing (as a merchant would) arbitrary payments, which opens up certain problems around snooping attackers (more on this below). So payjoin just means "A pays B but B actively participates and passes across utxos as extra inputs".
I'll defer a more features-focused and non-tech friendly description of what this means to a later blogpost.
# bitcoin-cli wrapper for running c-lightning with a pruned Bitcoin node | |
# (EXPERIMENTAL). It forwards all requests to bitcoind. If a getblock request fails, | |
# blockstream.info is queried instead. If your prune setting is high enough (2 weeks | |
# = 2016?) using this wrapper SHOULDN'T have security implications because the | |
# important blocks are still queried through your own bitcoind. | |
# Tested with c-lightning 0.6.2. Set the --bitcoin-cli=PATH option in c-lightning to | |
# the path of this file to use it. | |
BCLI=bitcoin-cli | |
getblock() { |