@CryptoStorm3 @ChartsBtc Each transaction offers miners a small amount of bitcoins to incentivize confirmation. Blocks are limited to 4M weight units, so miners cannot include everything that is waiting. Naturally, they choose the transactions that pay the highest fee per weight unit to maximize revenue.
@CryptoStorm3 @ChartsBtc Since a block is limited in size, and the block interval self-regulates to be roughly constant, the throughput of transaction data is limited.
OTOH, the amount of transactions that get submitted to the network is flexible.
@CryptoStorm3 @ChartsBtc Especially, when the price makes big swings, people get excited and want to participate in the market. As a precept in Bitcoin is to be your own bank and control your funds directly, a lot of people do not keep funds on their exchange accounts but in their own wallets.
@CryptoStorm3 @ChartsBtc This means that market moving news and price swings often prompt the creation of more transactions than usual. Once the transaction creation rate exceeds the throughput limit, the queued transactions grow quicker than the transactions get confirmed.
@CryptoStorm3 @ChartsBtc Each node keeps their own view of the queued transactions in the so-called memory pool (or mempool). The website that I provided screenshots of (jochen-hoenicke.de/queue/#0,24h) publishes statistics of the node JoHoe runs.
@CryptoStorm3 @ChartsBtc In the past few days, transaction creation has been exceeding transaction confirmation and the queue had accumulated about 56 blocks worth of transactions. As users have varying urgency to see transactions confirmed, they bid accordingly for inclusion of their transactions.
@CryptoStorm3 @ChartsBtc The colors in the graph represent different feerates. The feerate of a transaction is the ratio of fee per data amount. The higher the feerate, the more money a miner will make by including the transaction in their block.
@CryptoStorm3 @ChartsBtc The blue bands in the bottom represent low-urgency transactions. The users may for example just be consolidating dust or have other reasons to prefer low cost over quick confirmation.
@CryptoStorm3 @ChartsBtc The green bands in the middle consist of transactions that want to get some priority, but are unwilling to pay a premium to get confirmed as quickly as possible. These are probably users aiming to see transactions confirmed in a day or two.
@CryptoStorm3 @ChartsBtc The yellow (and red) bands at the top are users vying for express confirmations. They choose their bids to get confirmations within the next hour. These transactions could for example facilitate business deals or attempt to enter a market as quickly as possible.
@CryptoStorm3 @ChartsBtc While the transaction creation exceeds block capacity, the mempool grows more quickly than it shrinks. New transactions attempt to skip to the front of the line to make yet a higher bid and especially get added to the top. This pushes up the feerates.
@CryptoStorm3 @ChartsBtc Eventually, the transaction creation slows down, and the transaction creation drops below blockspace production. The mempool starts clearing from highest feerate to lowest feerate.
@CryptoStorm3 @ChartsBtc However, during a market frenzy, the demand for blockspace may exceed production for an extended period and bridge such demand slumps. For example in May after the third halving, more than 50 blocks worth of transactions amassed in the 1-2 sat/vB band (the lowest blue)…
@CryptoStorm3 @ChartsBtc … when the transaction queue did not clear for over two weeks.
@CryptoStorm3 @ChartsBtc This is by no means the worst we have seen. In winter 2017, around the time that the Bitcoin price reached its latest all time high, the transaction queue never fully cleared between Oct 26th 2017 and February 22nd 2018.

• • •

Missing some Tweet in this thread? You can try to force a refresh

Keep Current with 𝙼𝚞𝚛𝚌𝚑 🥕

𝙼𝚞𝚛𝚌𝚑 🥕 Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!


Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @murchandamus

22 Oct
Mempool depth is still on the rise with all fee bands growing.
If we were headed into a major fee event, the #btc ecosystem would be much better prepared than in 2017. Native segwit is on the verge of wide adoption, opt-in RBF is right there for anyone that wants thrifty quick confirmations, LN maturity is coming along nicely, which…
… could at least serve as a valve for some smaller payments even when Wumbo seems a bit daunting still.

If you aren't working on all of these, you might want to consider to.
Read 7 tweets
23 Mar 19
@giacomozucco @CarstenBKK @BlueDelta0 @StopAndDecrypt Alright, so our threat model is a widespread effort to change the protocol rules with support of a majority hashing attack. Presumably this is incompatible with existing network rules as enforced by fully validating nodes, but compatible with thin clients.
@giacomozucco @CarstenBKK @BlueDelta0 @StopAndDecrypt a) A vast majority of FN oppose this protocol change. Attackers are banned by their peers, blocks don't propagate, most thin clients never see the blocks. Affected scrutinizing thin client discovers changed rules when first valid block is found, if it has at least 1 honest peer.
@giacomozucco @CarstenBKK @BlueDelta0 @StopAndDecrypt b) Significant count of FN support protocol change. FN topology decouples, some Scrutinizing Thin Clients (STC) are eclipsed by attack. STC will at the latest fully validate the first block that includes any transaction that concerns them. 1) Discovers invalid block if rule...
Read 10 tweets
22 Mar 19
@giacomozucco @CarstenBKK @BlueDelta0 @StopAndDecrypt Maybe I'm missing something, but current thin client implementations either rely on a trusted server or connect to multiple nodes. So, you'd not only need to be served a fake block, but also get verification by other nodes to follow it. That means you need to be sybilled.
@giacomozucco @CarstenBKK @BlueDelta0 @StopAndDecrypt BIP157 done right would first gather multiple filter fingerprints and compare them, then download the full filter if they agree. If they disagree, the would need to be back-off validation procedures. I don't see why such a validation couldn't include parsing the full block.
@giacomozucco @CarstenBKK @BlueDelta0 @StopAndDecrypt Obviously, a thin client doesn't have the full UTXO set, but many other rules could be checked on a single block. This would significantly reduce the attack surface and susceptibility to accepting chain tips with protocol changes.
Read 5 tweets
12 Jun 18
A Hash-Timelocked-Contract is a conditional payment on a LN channel with two possible outcomes: Either the recipient provides the pre-image corresponding to the Lightning invoice that is being paid and takes the funds, or after the lock times out, the sender takes back the funds.
Ah submarine swap is an on-chain payment that purchases a LN payment: The sender locks funds into a conditional script, where either the swap provider can spend the funds by providing a pre-image, thus proving to have paid the LN invoice, or sender can take it back themselves.
One of the exciting things is that submarine swaps can be created on most cryptocurrencies, even ones that are not compatible with LN directly. This way you can for example offer to pay some forkcoin to get a LN invoice on the Bitcoin LN paid by ANY swap provider trustlessly.
Read 5 tweets

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!