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
tbh if i was the dude managing Hyperliquid's 4 validators (or those fucking ghetto ass binaries on gh) I would be shitting my pants right now.
Hyperliquid dudes dont seem worried at all though so im sure its fine. 🫠
lol @ all you retards who think the risk is USG forcing Hyperliquid to freeze AAAAAAAAAAHHAHAHHHAHAHAHAHAHAHHAHHAHAHHAHAHHAHAHAHAHHAHAHHAHAHHAHAHAHHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHHAHAHAHAHHAHAHAHAHAHAAHAHHAHAHAHHAHAHAHHAHAHAHA
Yall, DPRK doesn't trade. DPRK tests.🤦♀️
my offer from 2 weeks ago still stands @HyperliquidX
i'm still happy to do it async or via a call. i can even give you one of my super nice happy colleagues if you don't like me.
but a massive amt of harm will come to people if you don't harden your ass asap.
At some point prior to July 2024 the actual hackers landed a backdoor onto something that gave them some access to the WazirX multisig signers and/or their signatures.
We don't know what or who was compromised and it doesn't really matter.
Initial toehold was likely gained by tricking someone at WazirX or Liminal into installing malware -> escalated from there.
This access allowed the hackers to intercept/insert invisible, malicious payloads for signing in a way where none of the 3+ signers were able to notice.
With the recent sophisticated hacks fresh on everyone's mind, there's been a lot of talk about ✨fancy stacks and setups.✨
Yes, you should evaluate how—and with what—you sign txns.
But building a custom UI for your LAN Qubes OS AWS KMS everyday is not really the answer 😅
Background on the referenced hacks (feel free to skip):
1. Funds were stolen from each org's multisig.
2. Keys themselves were not compromised.
3. In Radiant and WazirX and maybe DMM, the keys backing the multisig were actually only on hardware wallets + actually controlled by distinct parties.
DMM Bitcoin - $305m in May
The least amt is known about DMM, including whether keys were cold vs hot. Early theories said address poisoning. It def wasn't that. Attached is rampant speculation (likely all wrong)
See also: x.com/mononautical/s…
Also, note, any organization that can implement / enforce EDR, etc. should do so. Full stop. End of conversation.
However, the crypto industry generally considers this a non-starter for all sorts of philosophical + practical reasons.
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)