2/ As I've observed over a decade of #Linux development and another decade in #blockchain, crypto and infosec folks often hyper focus on security to the point where people are turned off from the product, or simply stop waiting for a promised future and move on.
3/ #Bitcoin's lodestone is that it's difficult to build on, and it's developers are focusing on features unlikely to have a visible impact on most existing or future holders. Fancy, well engineered plumbing which does not really change user outcomes.
4/ The #Bitcoin crowd is gearing up to celebrate a feature which will be activated in November 2021, yet not fully integrated or absorbed into developer libraries or user-facing software for months or years after that.
5/ "Never let the MENSA people run the world."
For all the BTC wizards in the room, they miss basics that every community college MBA knows by heart:
- Time to market matters.
- Build things that people use.
- Look at what people do and don't use in what you built.
6/ #Bitcoin development expends an enormous amount of energy on tiny, incremental, esoteric technical features that are often entirely speculative as to whether they will actually reach production in end user-facing wallet deployment.
7/ Most of the practical world has moved on. Stablecoins, new crypto projects, new permissionless financial products happen elsewhere. Even bitcoiners turn to #Ethereum#DeFi, to create interest bearing #Bitcoin products.
8/ Like HTTPS everywhere, economic #privacy should be a fundamental default in Bitcoin.
Devs are pro-privacy, sure, but that's not translating into consumer facing privacy.
See also: well meaning anti-nuke environmentalists prolonged fossil fuel use and pollution for decades.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
2/ Beta testers will be able to test our first product - ETH, WBTC and USDC "Holding Pools"
Holding Pools are yield aggregating vaults, similar to other projects, with a focus on longevity, and a professional, simple, clean experience.
This is a familiar DeFi primitive.
3/ Holding Pools at Vesper are scored with liquidity quality scores internally, resulting in a "conservative" or "aggressive" summary label. Conservative yield sources, such as @compoundfinance, @AaveAave and @MakerDAO are "seasoned", with time-in-market, real-money tested.
1/ Yesterday: My L1 chain has better, faster tech than #Bitcoin or #Ethereum. It is not compatible with existing software or tooling, but will nevertheless overcome network effect and momentum to become the next Ethereum. Invest in my Ethereum killer.
2/ Today: My L2 rollup chain has better, faster tech than #Bitcoin or #Ethereum. It is not compatible with existing software or tooling, but will nevertheless overcome network effect and momentum to become... Invest in my...
3/ Investors routinely underestimate the value of iterative evolution - trial-and-error over time - sunk into software, tooling, auditing software libraries & the 1,000 other elements of a software ecosystem.
Smart competitors build on top of that, rather than starting from zero
2/ #Ethereum bot ecosystems often unintentionally evolve to single-bot-wins situations, where it is pointless & costly to run a bot that consistently comes in "2nd place"
3/ Bot 1 consistently wins liquidation auctions. It becomes unprofitable for others to play the game, resulting in a single player game. If the player (Bot 1) leaves or malfunctions, no other bots step up and take its place, due to incentives & deteriorated ecosystem.
Finally spent some time studying #Ethereum Merkle Patricia Tree github.com/ethereum/wiki/… 1. It is an elegant data structure for Eth, creating a cryptographically stable merkle root, no matter the data insertion order. 2. Oh boy, it really punishes your hard drive storage.
In my past life at Red Hat, I wrote the ATA (aka IDE) drivers for Linux, so I know a bit about data storage and hard drives.
Here is why Eth is so punishing on data storage, and why SSDs/NVMe are a field requirement for Eth:
Like Bitcoin, Eth has poor cache locality:
* Huge db, which means each Next Page is less likely to be in page/disk cache.
* Keys are hashes, which means each Next Query Key is uniformly random, and therefore equally unlikely to be “close” to any recent past query.