Instance Logo

social.otsuka.systems

Profile for cameron

Header for cameron: Seattle skyline at sunset with the Space Needle and Mount Rainier in the background.
Avatar for cameron: Profile picture of Cameron Otsuka.
Display name
cameron
Username
@cameron@otsuka.systems
Role
admin

About cameron

Bio

head of data/analytics @ build asset management

not financial advice, boosts/favorites ≠ endorsements, views my own

Stats

Joined
Posts
48
Followed by
5
Following
289

Recent posts

It is both infuriating and funny to see so many "engineering" sites/blogs include RSS feeds that are inaccessible to any feed reader because Cloudflare blocks them.

This could be a big privacy win for #Bitcoin ers using multi-institutional custody models. And I'd imagine key agents would like to limit the extra information they glean to focus solely on signing activity.

 Chain code delegation is now a BIP draft: it enables collaborative custodians to continue to help you with key management and recovery without losing privacy. https://x.com/jurvistan/status/1981396354032422982

The us-east-1 postmortem shows how hard it is to spot race conditions when building at the component level. When you see the forest for the trees, these stick out like sore thumbs.

 The race condition involves an unlikely interaction between two of the DNS Enactors. The normal way things work a DNS Enactor picks up the latest plan and begins working through the service endpoints to apply this plan. This process typically completes rapidly and does an effective job of keeping DNS state freshly updated. Before it begins to apply a new plan, the DNS Enactor makes a one-time check that its plan is newer than the previously applied plan. As the DNS Enactor makes its way through the list of endpoints, it is possible to encounter delays as it attempts a transaction and is blocked by another DNS Enactor updating the same endpoint. In these cases, the DNS Enactor will retry each endpoint until the plan is successfully applied to all endpoints. Right before this event started, one DNS Enactor experienced unusually high delays needing to retry its update on several of the DNS endpoints. As it was slowly working through the endpoints, several other things were also happening. First, the DNS Planner continued to run and produced many newer generations of plans. Second, one of the other DNS Enactors then began applying one of the newer plans and rapidly progressed through all of the endpoints. The timing of these events triggered the latent race condition. When the second Enactor (applying the newest plan) completed its endpoint updates, it then invoked the plan clean-up process, which identifies plans that are significantly older than the one it just applied and deletes them. At the same time that this clean-up process was invoked, the first Enactor (which had been unusually delayed) applied its much older plan to the regional DDB endpoint, overwriting the newer plan. The check that was made at the start of the plan application process, which ensures that the plan is newer than the previously applied plan, was stale by this time due to the unusually high delays in Enactor processing. Therefore, this did not prevent the older plan from overwriting the newer plan. The second Enactor’s clean-up process then deleted this older plan because it was many generations older than the plan it had just applied. As this plan was deleted, all IP addresses for the regional endpoint were immediately removed. Additionally, because the active plan was deleted, the system was left in an inconsistent state that prevented subsequent plan updates from being applied by any DNS Enactors. This situation ultimately required manual operator intervention to correct.