2023 Feb 24
Pretty fun video going over a bunch of tooling built in rust. Mentioned sccache which for a second I thought could be the solution to slow test compilation in rust but I realize I think it’s actually for caching compilation of libraries that’s shared between code.
- Also this guy No Boilerplate runs Asahi linux 🤔…maybe I should actually try it out.
Went to a talk by Benedikt Bunz that was happening at my school. He talked about Bulletproofs. So what I understood, a SNARK is a zero knowledge proof with a very small proof, however they require a trusted setup. A STARK doesn’t require a trusted setup, but is apparently very big. Bulletproofs are small and don’t require a trusted setup! The main example of usage of these is the make it possible to have private transactions on blockchains while still knowing that people can only spend amounts they actually have (i.e. range proof → amount to spend is greater than zero, less than some huge number). It was pretty interesting. I couldn’t explain all the technical details, but he talked about using homomorphic property of commitments (being able to essentially add them together and do batch verification) to do rollups, smth smth you could compress large amounts of data with commitments while still being able to maintain inner product argument. Don’t know much details of all these but was cool.
The talk was generally about solving problems with blockchains currently. He also talked about how to use verifiable delay functions (VDF, e.g. hash chains) to do leader section to replace the “wasteful” proof of work. I’ll note here that proof of work has another important function beyond leader selection, i.e. requiring a costly action outside the system in order to produce histories, but the construction was pretty interesting. Main idea I got was you are able to have a group of people choose a random number that none of them can predict without trusting each other. They do this by all choosing some random numbers, then taking the hash of all of them, and then running a VDF on that hash. Pretty cool to get the basic idea of leader selection in proof of stake type systems.
Interesting to note that proof of work is not a VDF. In VDFs, you can actually verify this must have taken exactly this amount of time (this amount of hashes) to compute, whereas proof of work it takes an unpredictable amount of hashes.
These days I’m thinking about how proof of stake could maybe work in practice, especially overtime overtime as a blockchain becomes more decentralized, even though the trust model is different. But I don’t know it’s kinda like why leave room for error. Though from my understanding proof of work is more sound, and the relationship to energy is in my opinion a huge plus.
AstroVim. Vim out of the box. Cool, but eh not for me.
Fuzzers are smart! I realize now there’s much more to fuzzing than just random inputs. In hindsight it’s pretty obvious it would take a really long time to find helpful inputs if you were going off of pure randomness. Instead fuzzers will have some preset inputs, and you can even seed or template inputs, and they will mutate this initial set based off of code coverage (if it has access to the source code) and how each input performs. Should look more into this one day.
ThePrimeagen on github copilot. Agree. Even more helpful, he recommends not using it as a junior developer. I feel like I could probably use it somewhat effectively, but this just further confirmed my gut feeling to just not use it until I’m much more prolific.
Realized that the fact that I would be able to backup my Phoenix wallet must mean that ACINQ must store some sort of (all of the) state for my lightning node. I realize that backing up your lightning node state is fundamental to self-custodial lightning—if you lose your phone you should not lose your funds. But also I guess you don’t have to back up everything, you could only backup the latest commitment transactions and force close if you lose your phone. Not a great option though. Hello VSS!
Notes from Citadel Dispatch ep 90 with Steve Lee:
Stratum v2 is already in production on Braiins pool (3% of hashrate). Importantly though an independent implementation is being funded which will make adoption easier, and also generally good for the protocol to not have a single implementation by a for profit company.
Pavlenex is apparently one of the best examples of a non-developer contributing in a major way to Bitcoin open-source projects, e.g. BTCPay and StratumV2!
People are really excited about fedimint, and although it’s sort of custodial, it federates trust, and has its use case. It helps scale bitcoin and interoperates with lightning. Haven’t taken the time to really understand it, but smth smth federated trust, smth smth chaumian e-cash. Gotta look into it soon.
WalletScrutiny. Project to verify reproducible builds for wallets. Totally agree with the idea. Apparently it’s been sort of controversial just because there are a million wallets and very few people working on the project, and it’s easy to get on wallet developers nerves just from the nature of the project. Lots of nuance that isn’t totally accounted for yet in the project.
Compact block filters are great, the main reason people use esplora/electrum for block source is because of bandwidth on mobile.
The ideal is where there’s a large market for LSPs, and there are many to many relationships between wallets and LSPs.
There’s bitcoin park in Nashville..?
Programming Bitcoin from Jimmy Song was a great 2-day workshop to give people a foundation. People are working on a Programming Lightning.
Notes from Stephen Livera ep 461 with Matt Corallo:
Most people in economies where their money has failed actually use stablecoins much more often than Bitcoin. Community needs to do some soul searching on what Bitcoin provides people in excess of stablecoins. Stablecoins are centralized, but for 99% of use cases where people just need exposure to some more stable asset, they’re fine.
Fee sniping and fee smoothing. I never heard of this until now, but fee sniping is when in the future when transaction fees make up the majority of miner’s earnings, miner’s may be incentivized to do much longer reorgs for a single high transaction fee. Fee smoothing would just mean that the fees from a block payout over the next several blocks to disincentivize this.