Topic: Writeups of my Mempool Observations (Read 684 times)
This would have taken you a lot of time and efforts to gather all such details and then comprehend and then organized it. The website has also done up nicely and also like the information which is put up and also how it is presented.
As said in your article the ability to deduct the wallet used for a specific transaction is a data leak. However I also think that if a third of the transactions is using the same Blockchain.com feerate API also centralization is an issue. As user of this wallet you have to trust the estimated fee to be correct. If Blokchain.com or a third party would manipulate the outcome of this API than almost a third of all on-chain transactions could be tampered with.
I don't think it's *that* concerning. If they set the feerate to zero the txn won't confirm.. but they could also just take their service down.If they set the feerate very high-- well in most cases they could just substitute the JS/app or guess the user's usually-weak password and simply take their coins directly.
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.
Not by much: only to the extent that they increased the fee of transactions that weren't making it into blocks.E.g. Say you add 1MW/block of transactions paying 0.001 BTC / WU in fees -- this would have the same effect on Core's estimator as if you added 1MW/block of txn paying 0.1 BTC/ WU in fees. All that matters is that they were high enough to push things out... it's the feerate of the things that were actually delayed (and which were later confirmed) which drive the estimator.
It appears to me that they already bid pretty high too, enough that increasing their high fee would have no effect on what bitcoin-qt pays, and increasing their low fee would do no more than switching their users all from low to high would.
If Blokchain.com or a third party would manipulate the outcome of this API than almost a third of all on-chain transactions could be tampered with.
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.
As said in your article the ability to deduct the wallet used for a specific transaction is a data leak. However I also think that if a third of the transactions is using the same Blockchain.com feerate API also centralization is an issue. As user of this wallet you have to trust the estimated fee to be correct. If Blokchain.com or a third party would manipulate the outcome of this API than almost a third of all on-chain transactions could be tampered with. 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.
Thanks for sharing. Enjoyed this very thorough write-up 
Keep up the good work
Keep up the good work
Thanks for sharing..nice collection of articles on your website! Most were over my newbie head still, but I enjoyed your timeline https://b10c.me/projects/bitcoin-dev-history/
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.
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.
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)
Maybe also "full length signatures" -- not doing the nonce grinding to reduce the signature size the bitcoin core does? Though that won't filter much except on txn that have many inputs and BIP-69 will probably already eliminate bitcoin core for those.
If there are two outputs, at least one of them will be P2PKH.
One other thing to consider is that there is likely a lot of fee sensitive variance in transaction origins. I wouldn't be too surprised if e.g. exchanges stopped aggregating behaviour during high fee periods, increasing the share of transactions from end user wallets, particularly ones that were more fee-blind. Working off mempool data is a little limiting for that reason.
Interestingly, currently 4% of all transactions with the above properties are one input - one output P2PKH transactions just above the low and high estimates. https://mempool.observer/monitor/?filter=RT00JmM9MCZkPTImYj0wJmE9MCZ2aT0xJms9MiZnaT0xJnY9MiZuPTImZz0yJnI9MCZzPTAmdD0wJnE9MCZtPTAmcD0wJm89MCZ6PTAmUj0wJmZpPTEmZj0y
Wonder what those are...
Wonder what those are...
Those are probably HODLed coins being moved. Are the transactions from Legacy addresses to Segwit addresses? Or have the coins not been moved for years, then moved? That's an indicator of SODL. Hahaha.
Interestingly, currently 4% of all transactions with the above properties 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...
https://i.imgur.com/WeHKgVw.png
Wonder what those are...
Here is some likely nonsense which could use a bit of debunking, if someone feels like doing some analysis: https://www.reddit.com/r/Bitcoin/comments/gngglt/blockchaincom_says_they_account_for_a_third_of/
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
https://i.imgur.com/byosQpq.png
I might start writing this up over the weekend, if I have the time.
Here is some likely nonsense which could use a bit of debunking, if someone feels like doing some analysis: https://www.reddit.com/r/Bitcoin/comments/gngglt/blockchaincom_says_they_account_for_a_third_of/
I thought about creating a service similar to what you describe. Reasons I didn't are that [...] I'd be (at least partially) competing with the Bitcoin Optech guys.
Please, please, please don't hesitate to compete with us! Although Optech is technically a for-profit company, we operate like a non-profit, have only modest revenue, and almost all of us are contributing for free (or through salaries paid for by other organizations, like Chaincode or Square Crypto). We occasionally write about fee management because we think it's important, but there's plenty of other important things we could be doing with our time (both as individuals and as a team).
Early on, we made a decision to focus on producing educational material and holding workshops rather than offering direct consulting---so you (or anyone else) working directly with companies to optimize their spending would be a complimentary service, not a competitive one.
I would assume they're motivated to cut down on their own tx fees.
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 could imagine the same thing existing for bitcoin-- but the security considerations would probably make it a harder sell.
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.
One challenge with that kind of argument is that their tx fees are probably a rounding error relative to the overall cashflow of their operation, probably making it a low-to-no-priority for them.
This is true more often than not in Bitcoin's history, however I heard Coinbase left a sizable part of their revenue to miners in 2017 over their simplistic withdrawal strategy, when 1000 sat/B fees were "common". That was the result of the price runoff from the previous halving *hint*. Better be prepared now, just my 2 cents.
Quote
and the company who got costs reduced in an area that wasn't their focus.
A bit contradictory when one of the main benefit of Bitcoin is bypassing 3rd party custodians. One thing is for sure, the lack of fee pressure will suppress this side of R&D.
I would assume they're motivated to cut down on their own tx fees.
One challenge with that kind of argument is that their tx fees are probably a rounding error relative to the overall cashflow of their operation, probably making it a low-to-no-priority for them.In the bygone days when long distance service actually cost companies a lot of money (at least in absolute terms, if not relative to their operation) there were companies that would come in and go through your bills and optimize your service (e.g. by switching carriers, installing dedicated lines to offices you constantly called, getting contracts for special rates to certain locations or bulk discounts, recommending usage changes-- etc.) in exchange for 50% of the savings for the next year. If they save nothing, you pay nothing.
It was a good business for both the contractor who could make a boatload off their specialized expertise and the company who got costs reduced in an area that wasn't their focus.
I could imagine the same thing existing for bitcoin-- but the security considerations would probably make it a harder sell.
I don't believe that delaying announcing transactions they just constructed would provide any value to the network. It's better to have them out there and provide people with more complete information about them.
I would assume they're motivated to cut down on their own tx fees. I'm not going to expect any market actors to act for the network's benefit at the behest of their own.
Granted they could still bloat the mempool in a single batch broadcast with low fees and RBF later where necessary. Delays aren't the only way to cut down on fees.
Most certainly the optimal solution would lay at some intersection of batching and broadcast delays. Broadcast delays would take them 5 minutes to implement. Batching? Who knows.
I don't believe that delaying announcing transactions they just constructed would provide any value to the network. It's better to have them out there and provide people with more complete information about them.Generally the big barrier to deploying batching is delaying the payment (and learning its txid) in the first place.
I'm guessing that's part of the vanity prefix and not something they're willing to let go unless offered a better solution.
There is no requirement to use uncompressed keys to use vanity addresses-- in fact, vanity addresses can be generated slightly faster with compressed keys.If their prefix is just '3BMex' that's pretty short and easily found in any case.
I was saying this more in the context of "we already have them, why bother?". Of course compressing the keys would make more sense, but how motivated would they be to at least gradually replace their current "fleet" of addresses (which obviously isn't trivial to generate)? I'm guessing there is some form of key ceremony they're not so willing to either modify nor run through (I assume they're not generating these keys deterministically). It would be significantly easier with a script merklerisation scheme where you can separate the vanity search from the public key generation.
I'm trying to play devil's advocate here.
Quote
These things are not mutually exclusive, batching into a modest number of outputs per txn could halve the load they place on the network-- and that's true regardless of when they emit the transactions. (doubly so if someone created a two-sided version of the branch and bound search in Bitcoin core that can often result in changeless transactions when run with large wallets)
Most certainly the optimal solution would lay at some intersection of batching and broadcast delays. Broadcast delays would take them 5 minutes to implement. Batching? Who knows.
I'm guessing that's part of the vanity prefix and not something they're willing to let go unless offered a better solution.
There is no requirement to use uncompressed keys to use vanity addresses-- in fact, vanity addresses can be generated slightly faster with compressed keys.If their prefix is just '3BMex' that's pretty short and easily found in any case.
However, an even more block space-efficient alternative would be to use a non-multisig wallet for user deposits, which are periodically consolidated into a multisig wallet.
Meh. I'm not sure that's great advice. With the normal way that Bitcoin us used, you don't have any idea how much a user will deposit. So, sure, it would be reasonable to send *small* deposits to a less secure wallet, and preferentially use those payments... but then you might also have a user depositing 2000 BTC in one go and then have those funds stolen from the hot system before your sweep moves them.Jump to: