See this PR https://github.com/bitcoin/bitcoin/pull/23624 for a new rawmempooltx publisher publishing only mempool transactions.

That's an interesting thought...
In theory, somebody controlling the feerate recommendations could collude with multiple miners and share the additional fee revenue. Thousands of transactions paying a higher feerate would affect other feerate estimators, for example, Bitcoin Core's estimator as well. This would increase the potential revenue even more.   

I finally came around to finish the Blockchaincom wallet write-up.

The Blockchaincom wallets follow the feerate recommendations of the Blockchaincom API closely (or over/underpay by a fixed percentage due to bugs in the wallets). This allows to identify a majority of the Blockchaincom transactions by combining the fingerprint and the feerate recommendation. I still believe the reported network share of one-third of all transactions is reasonably accurate.

The full article is here:

Following the Blockchain.com feerate recommendations - Wallet fingerprinting nearly a third of all Bitcoin transactions - https://b10c.me/mempool-observations/3-blockchaincom-recommendations/

Feedback, ideas, and potential future topics to add to my already long list are welcome. However, I'll be busy with other things in the coming weeks.

Interestingly, currently 4% of all transactions are one input - one output P2PKH transactions just above the low and high estimates. https://mempool.observer/monitor/?filter=RT00JmM9MCZkPTImYj0wJmE9MCZ2aT0xJms9MiZnaT0xJnY9MiZuPTImZz0yJnI9MCZzPTAmdD0wJnE9MCZtPTAmcD0wJm89MCZ6PTAmUj0wJmZpPTEmZj0y

https://i.imgur.com/WeHKgVw.png

Wonder what those are...

 

Had that on my todo list and moved it up a bit yesterday. However, I don't think their claim of '30% of all transactions' is to far off.

Both their low and high feerate estimatimates as well as what properties their online wallet transactions could and certainly don't have is known. For example:

• Only spending P2PKH outputs (thus not spending SegWit nor multisig)
• Not signaling explicit RBF
• Not setting a locktime
• BIP-69 compliant (IIRC parts of their wallet are on GitHub, don't have the link handy right now)
• Not more than two outputs are created (one payment and maybe one change output)

Applying these filters on my site currently draws 33.50% of the 30.000 loaded transactions. A majority of these follow either the low or high feerate estimates. Obviously, there are outliners. https://mempool.observer/monitor/?filter=RT00JmM9MCZkPTImYj0wJmE9MCZ2aT0xJms9MiZnaT0yJnY9MiZuPTImZz0wJnI9MCZzPTAmdD0wJnE9MCZtPTAmcD0wJm89MCZ6PTAmUj0w

I might start writing this up over the weekend, if I have the time.

BitMEX does not pay the transaction fees. I guess that's part of the reason they still use their tech from 2014 for withdrawals. Quoting from my article:




I thought about creating a service similar to what you describe. Reasons I didn't are that exchanges/other services often don't pay the transaction fees themselves, I don't have enough exchange-security experience to not mess anything up (at least I'm not confident and insured enough) and I'd be (at least partially) competing with the Bitcoin Optech guys.

I've published a new Mempool Observation today.

It's about the daily withdrawal broadcast of BitMEX. They broadcast multiple megabytes in around two minutes every day.

This has an effect on the whole network: The feerate estimator's estimates, and, as a reaction, the observed average feerate spikes. The minimum feerate for block inclusion is higher for a few hours and the time-to-confirmation sees an increase.

All because their users deposit directly into 3-of-4 P2SH multisig (redeem scripts with four uncompressed public keys, it's 2020...). That's more than 500 bytes per input. I discuss a few ways of reducing the transaction count and size. Most promising seems to use Schnoor + Taproot combined with output batching. With that it could even be possible for them to keep their '3BMex' vanity addresses by iterating a leaf of the merkle tree that's used as tweak until they get a Bech32 vanity they like. (Not saying that's a good idea: the privacy and fungibility benefits from Taproot would be gone.)

Full article is here:

The daily BitMEX broadcast at 13:08 UTC - Using a fingerprint to reason about a footprint - https://b10c.me/mempool-observations/2-bitmex-broadcast-13-utc/

Planning to write up my observations on seasonality next but haven't started yet. Seasonality seems to overlap with what gmaxwell mentioned in one of this issues (https://github.com/0xB10C/memo/issues/66).

Thanks gmaxwell! I enjoyed reading your ideas. I can't promise that they'll end up as interactive charts somewhere. However, I already had plans to write about some of these, which would at least include a static plot.

I've recently started to write up some of my observations I had on my Bitcoin Transaction Monitor project (https://mempool.observer/monitor).
I write about activity on the network I find interesting and worth sharing.

The first one is about fees-sniping and why transactions are time-locked to the current block height.
I expected something like this when plotting transactions by their arrival time and locktime:

https://b10c.me/data/mo/mo1-locktime-stairs/expected-pattern.png

However, it turned out that some of the transactions I observed were even time-locked to the next block.
These should have normally not been relayed to me.

The full write up can be found here:

The stair-pattern in time-locked Bitcoin transactions - The off-by-one-error that covered another off-by-one-error up - https://b10c.me/mempool-observations/1-locktime-stairs/

Will post more here if there is interest.