So @blocknative has been looking closely at EIP-1559 vs legacy txs since this question & one thing I learned from the discussions absolutely blew my brain up:
Since EIP-1559 there are often a large number of transactions sitting in the tx pool EVEN WHEN BLOCKS ARE NEARLY EMPTY.
Say whaaaa?! That must be a bug, right? Or are miners just mining empty blocks for shits and giggles? It’s not always the case, right?
No. No. Wrong.
This is actually…er…the design.
Big brains may see it already but if you have a brain like mine, I’ll walk you thru it. 😁
Note:
- Type 2 = EIP-1559 transactions
- Type 0 = legacy, gas price transactions
- Effective Fee = aka effective tip (see attached). how much the miner will get from the tx. how txs are sorted in a node’s tx pool. presumably the order txs are included in.
The data @blocknative pulled today shows that Type 2 transactions were included in a block ~40% faster than Type 0 transactions.
HOWEVER, Type 0’s had a 23.5% *higher* Effective Fee than Type 2’s.
Whoa.
This is even more startling because the @blocknative data from last week showed Type 2’s being included 24% faster than Type 0’s even though Type 2’s only had a 6% higher effective fee.
Does this mean miners are more willing to include Type 2 transactions than Type 0? 🤷♀️
Does it mean using a Type 2 transaction has an effect on the time it takes for you to be included? 🤷♀️
One difference between now and before the hard fork is the “time til inclusion” datapoint means something slightly different.
Before, every transaction had the ability to be included in a block. Price competition was what prevented/delayed inclusion.
Now, only transactions that have an effective price > 0 can be included.
In other words, if your tx’s max fee/gas price is less than the current base fee, it CANNOT be included in a block.
The price competition applies to transactions that *can* be included [1]
[1] sort of…
One reason Type 2’s may be included faster is because the wallets and code and humans pricing a Type 2 tx do so with consideration of the base fee (e.g. using a max fee that is 2x the current base fee.)
Type 0’s pricing strategy may be more like “~current base fee”
Example:
Current base fee = 40, increases to 42 while you’re sending.
Type 2: max=80, priority=1 -> effective price=1
Type 0: gas price=40 -> max=40, priority=40 -> 0/CANNOT BE INCLUDED
[1] “sort of” bc even when base fee returns to 40, Type 0 still has effective fee=0
This is glaringly obvious to some brain-types but I took a minute to really grok this. It makes sense, it’s just a battle realizing “priority=40” means absolutely nothing here…and that *ALL* underpriced txs have an effective price of “0” the moment they become not-underpriced 🤯
The discrepancies in time til inclusion across types may be simply bc we are comparing apples to oranges.
Or there could be something else. I don’t think the fact Type 0s may happen to be less likely to be able to be included fully explains the discrepancy.
Chime in big brains.
So back to the beginning:
Since EIP-1559 there are often a large number of transactions sitting in the tx pool EVEN WHEN BLOCKS ARE NEARLY EMPTY.
Do you see why now?
Because they can’t be included in the block because the current base fee is higher than their max fee! They are underpriced. Duh!
It’s by design.
Again, it makes total sense and yet is still weird af, imho. This next bit really boggled my brain though.😊
Imagine you have a pile of transactions in the tx pool that all have a max fee/gas price of 1-10 gwei. NO new txs are being sent. Just pretend.
Block 1: 100% full of 10 gwei txs
Base fee📈to 11
Block 2: There's no 11 gwei txs, therefore block is empty.
Base fee📉to 10 gwei.
Block 3: There's no 10 gwei txs. The block is empty.
Base fee📉to 9 gwei.
Block 4: Block gets 100% filled with 9 gwei txs.
Base fee📈to 10 gwei.
Block 5: There are no 10 gwei txs. Block empty.
Base fee📉to 9 gwei.
Block 6: There are no 9 gwei txs. Block empty.
Base fee📉to 8 gwei.
Block 7: Block gets 100% filled with 8 gwei txs.
Base fee📈to 9 gwei.
Block 8: There are no 9 gwei txs. Block empty.
Base fee📉to 8 gwei.
Block 9: There are no 8 gwei txs. Block empty.
Base fee📉to 7 gwei.
See the pattern?
Every time the base fee moves down a step, it shoots back up. Then it must move back down two steps in order to clear out the next-lowest step.
Before EIP-1559, three blocks would clear out three “steps”
After, three blocks clear out one “step”
Obvs, reality is WAY messier. Fees being used have huge amts of decimals and blocks can be 78.23% or 15.23% full.
But it means that, at times, the base fee can shoot up rapidly but fall more slowly and more stutter-y. Esp. bc in reality, people are always sending new TXs.
Another thing this imaginary example shows is that if you send using 2x the base fee (Type 2 txs), you can (and will) be included in any of the above imaginary example blocks.
If you send using the current base fee (some Type 0 txs), you can’t be included in all of them.
Put another way, a new TX entering the pool that uses current base fee as the gas price results in the TX competing for space with TXs already in the pool.
While 2x base-fee TX’s have moments where they are included bc they are one of the only txs that isn’t underpriced.
NOTE: the last few tweets are looking at how things play out in one of many multi-block scenarios…specifically a completely imaginary multi-block scenario. Do not change how you transact based on this lol i am not painting a full story.
One general takeaway from all this is that while the onchain/inpool data today is showing discrepancies between Type 0 & Type 2 txs, I suspect the discrepancies have less to do with the actual transaction type and more to do with how each transaction type happens to be crafted.
Namely, Type 0’s (most often) use estimate api’s which don’t directly know the current base fee. While Type 2’s (most often) pad the current base fee.
So, will using a Type 2 tx will get you mined faster than a Type 0?
Data says yes.
I say it prob depends on how you price it.
Which means it’s prob “yes” for average joe switching to EIP-1559 wallet from a legacy wallet.
But, again, prob not just bc it’s a Type 2.
Also you prob aren’t average joe if you made it to the end of this thread 😉
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Crypto folks (hopefully) already know that Lazarus is one of the most prevalent threat actors targeting this industry.
They rekt more people, companies, protocols than anyone else.
But it's good to know exactly how they get in. Bc another smart contract audit won't save you.
For example, one long-time fave method:
- Contact employee via social/messaging app
- Direct them to a Github for a job offer, "skills test," or to help with a bug
- Rekt individual's device
- Gain entry to company's AWS
- Rekt company (and their users)
When it comes to financial crime, money laundering, etc. everyone goes thru a phase of thinking that the solution is knowing the identity of the account holder.
"if only we knew who moved these assets! then we would be able to catch them and stop crime!"
N O .
Literally NO.
It doesn't work at any scale. It's never worked at any scale. It never will work at any scale.
AML laws and all the related shit don't stop crime or money laundering. And it never has.
And it's really important to note that the implementation is NOT the issue.
The laws are *designed* to detect and block people from accessing the financial system.
And they do exactly that. Really well. So well in fact that like 1/4th of the world's population doesn't have a basic ass bank account.
On Fri June 2nd, thousands of Atomic Wallet users had their wallets drained across basically every chain.
Each theft involved 1-3 new addies. Initially we were only able to link thefts on-chain if they sent gas to multiple addresses.
(green guys are what we put alerts on first)
The lack of consolidation means the majority of addresses collected so far came direct from users sharing their info w/ folks like @zachxbt or w/ Atomic, @elliptic, @SlowMist, etc.
We have no idea how complete our lists are currently, or how long the long tail will be.