# Bitpost documentation

This documentation is aimed towards a slightly technical crowd that has a basic understanding of how bitcoin works. If you already knew a few terms shown below, you will probably be able to follow our tutorials.

# Introduction

# Problem/Motivation

Since bitcoin was launched in 2009 until about 2016, transactions could be confirmed at virtually no cost. Bitcoin's blockchain could easily record every broadcasted transaction in the following block, which occurs on average every 10 minutes and can contain about 3000 transactions. As bitcoin's popularity grew, this five transaction-per-second limit meant users had to outbid each other if they wanted their transaction confirmed in the next block. Transactions were no longer free, and their cost could vary three orders of magnitude depending on demand. Many fee estimators appeared for different priorities and confidence levels. Choosing a too low fee can have very negative consequences: the transaction can be stuck for days. Due to this fact, there is a general tendency for users to overpay the fee. Some users known how to increase the fee with replace-by-fee (RBF) or child-pays-for-parent (CPFP), but this is a tedious activity that takes time and can't be done if the user is busy.

# Solution

Our service automates and optimizes the whole process of choosing a transaction fee. Instead of setting a fixed fee and letting the time for confirmation be determined, we set the time for confirmation and optimize the fee. This setup is a much more natural workflow that is already adopted in traditional banking. To do this, each time your wallet wants to send bitcoin, it relays several pre-signed transactions that opt-in for RBF and are essentially the same except for the fee. With these, we can adjust the fee without taking any custody. Our quick start tutorial shows you how you can easily do this.

# Glossary

# Relevant bitcoin terminology

  • Feerate: the fee of a transaction relative to its virtual size, usually expressed in satoshis per virtual byte and less often in BTC/kB.
  • Effective feerate: the feerate of a transaction as seen by miners - with the possible effects of accelerating child transactions or decelerating parent transactions.
  • Mempool package: a group of pending transactions that depend on one another, awaiting confirmation.
  • Pre-signed transaction (PST): a complete signed transaction that can be broadcasted to the bitcoin network.
  • Replace-by-fee (RBF): this technique allows the replacement of a pending transaction by another with a higher fee. In the vast majority of wallets, bitcoin transactions are not replaceable by default; the user needs to opt-in to use this feature.
  • Child-pays-for-parent (CPFP): a technique used to increase the effective feerate of a transaction by creating and broadcasting a child transaction that pays a higher feerate than the parent.
  • Coin selection: the selection of unspent transaction outputs (UTXOs) that will fund a bitcoin transaction. There are many methods to accomplish this task, with their advantages and disadvantages.

# Bitpost-specific terminology

  • Broadcast group: each set of mutually exclusive pre-signed transactions that you sent to us.
  • Request: short for fee-adjustment request, which is the primary service provided by our application: it dynamically adjusts your transaction fee by a mix of RBF and CPFP techniques without taking custody of your funds. Don't confuse with an HTTP request.
  • Request group: a group of fee-adjustment requests that depend on one another. Typically these groups don't have more than five requests.
  • Wallet token: an optional identification token, generally created by a user, to later access information about his request(s).
  • Target: the deadline for the first confirmation. If you want a transaction to be confirmed 8 hours from now, the target is (now + 8 hours). Some fee estimators also use this term.
  • RBF coin selection: similar to coin selection, but it refers to the selection of pending (or to-be broadcasted) UTXOs that opt-in for RBF. Each selected UTXO is represented by a set, to take into account possible RBF replacements or past broadcasts.

# Disclaimer

The code we publish - be it in this documentation, in github or in the published packages/modules - is meant for demo purposes only. Please don't copy-paste or import this code into a production environment without proper review.

Quick start →