Pages:
Author

Topic: Writeups of my Mempool Observations - page 2. (Read 687 times)

legendary
Activity: 3766
Merit: 1364
Armory Developer
May 05, 2020, 02:47:41 AM
#5
redeem scripts with four uncompressed public keys, it's 2020...

I'm guessing that's part of the vanity prefix and not something they're willing to let go unless offered a better solution.

Quote
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.)

Clearly you do not care about privacy and fungibility when you are using a vanity prefix. Merklerizing their script candidates is indeed the proper solution.

Quote
combined with output batching

That's debatable. Obviously they sign all their withdrawals in a single daily trip to the cold storage, and we can infer they then broadcast the whole lot in one go. If the idea is to reduce impact on fee estimation and confirmation time, a trickle of transaction throughout the day would achieve this better than batching outputs, which is a bandaid to blasting the mempool with all your withdrawals in one giant broadcast.
newbie
Activity: 9
Merit: 165
May 04, 2020, 04:10:53 PM
#4
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).
newbie
Activity: 9
Merit: 165
May 04, 2020, 03:42:48 PM
#3
Nice article! but you messed up: your site called on users to request things--- so I went and opened a half dozen issues. Smiley

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.
staff
Activity: 4284
Merit: 8808
May 04, 2020, 05:56:39 AM
#2
Nice article! but you messed up: your site called on users to request things--- so I went and opened a half dozen issues. Smiley
newbie
Activity: 9
Merit: 165
May 03, 2020, 09:26:54 AM
#1
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.
Pages:
Jump to: