"What kinds of things can you tell the computer you want?" she asked excitedly, her cheeks beginning to flush.

He thought for a moment, and began stroking her hair gently. "All kinds of things. There's a language called Prolog you can use to ask about logical relationships. In SQL you can ask questions about huge quantities of data. With a program like bison you can declaratively describe a language, letting bison generate a program that recognizes it."

"Oh," she said breathlessly, leaning her head on his shoulder, "so I don't have to worry about choosing an algorithm--the computer will pick one for me?"

He began caressing her breasts.

She took his silence as an affirmation. "That's so cool that it just does it--it must be really smart to pick the right algorithm!" she enthused.

"Well..." he trailed off, still fondling her breasts.

"What?" She asked, nervously.

"Um..." he said, "it's not quite like that." His hands stopped moving.

She sensed he was backpedaling. "Well?" she demanded.

He laughed awkwardly. "Heh... You see, most declarative programming systems only know about one algori--"

"It must be a great algorithm!" She interrupted, with renewed intellectual arousal. "What is it?"

He hesitated for as long as he could... "Brute force search," he said, guiltily.

"What the fuck!?!?" She yelled, straightening and yanking his hands from her chest.

"Wait, baby, it's not so bad!" He begged.

"I'm listening." She said, staring him straight in the eyes.

"Well, if you're careful and you program in an idiomatic way, you ca--"

A venomous glare silenced him mid-sentence. She stood suddenly, grabbing his hat from the night stand and moving towards the open window.

"My Stetson!" He shrieked, jumping to his feet, the spurs on his cowboy boots jangling feebly. "But baby, didn't that parser generator thing sound cool?" He pleaded.

She stopped. "Well... yeah, that was pretty neat..." she begrudgingly acknowledged, softening.

"And that doesn't use a brute force algorithm. It builds an automaton for you, an LR parser," he said.

She smiled to herself, seeming to relent momentarily. He could see that she was touched by the idea of a program that could understand other programs.

"See, declarative programming isn't all bad..." he cajoled, slowly walking towards her, palms outstretched.

She started, as if waking from a dream. She looked at him. "But what about in the case of an ambiguous grammar, for which an LR parser won't suffice?"

"Don't worry," he said, smiling, "bison can use a technique called generalized LR parsing, which allows it to follow all possible parses simultaneously, eventually finding a successful parse."

She thought for a moment. "But if we're following all possible paths simultaneously and discarding the ones which don't lead to successful parses, isn't that just brute force search?!?" She asked, her voice ringing with betrayal.

Her words were damning. Nothing he could say would placate her. He stood in embarrassed silence, eyeing his cowboy hat anxiously.

She turned away from him, her emotions a mixture of pity and rage. He moved towards her, reaching for her hands, but it was too late. She had already hurled his hat from the window, as hard as she could. They watched silently as it flew into the night, lofted through the cool air as if by the breath of angels.

RASMUSSEN: Can you say your name and age for the recorder?

CSEMEGI: Hans Csemegi. 62.

RASMUSSEN: That's an unusual name.

CSEMEGI: Yes, it is, my parent were immigrants to Germany, and they wanted to give me a German sounding name.

RASMUSSEN: And where were they from?

CSEMEGI: Hungary.

RASMUSSEN: Can you tell me a little bit about your life before the war?

CSEMEGI: In many ways I had a very normal childhood. My father was an immigrant, but he was a natural with machines, so he found work easily. We lived very comfortably, all things considered. My mother's cousin and her family came to Germany around the same time, so I knew how other immigrants lived.

RASMUSSEN: Did you speak German growing up?

CSEMEGI: Yes, and Hungarian with my parents.

RASMUSSEN: When did you find out you were a Jew?

CSEMEGI: Not until I was seventeen. My parents kept it from me. But I found a box of letters in my mother's closet one day. I found out that my grandfather was actually a kosher butcher, imagine that...

RASMUSSEN: How did you feel when you found out?

CSEMEGI: I felt disgusted. I was a German, you know. I read the papers, I saw the newsreels, and I knew that Jews were the lowest of the low. I couldn't believe that I was one of them. I also knew right away that this was the worst thing that could happen to me. Kristallnacht was only a month away, and already the writing was on the wall.

RASMUSSEN: How were you sent to the camps?

CSEMEGI: One day they just found out. It was my father, someone had gotten suspicious where he worked, because he didn't look at all German. For that matter, I didn't look at all German, but I was so German in my manner that nobody gave me a second look. But he still had an accent. He was foreign. Our whole family; me, my sister, my mother, and my father; were told to report for processing one morning, and we were stuffed into trains to the camps that very afternoon.

RASMUSSEN: What happened to your family?

CSEMEGI: My father was killed before he even got onto the train. He was always a stubborn man. They divided the men and the women up, and my sister and my mother went to a different line. He started arguing with a soldier, and I think he put his hand on his soldier in anger, or something. And the soldier shot him. He was right to argue, I never saw my mother or my sister again.

RASMUSSEN: <coughing> Sorry.

CSEMEGI: After that I knew. I KNEW. That I was going to die like my father. I remember watching him fall, and I knew that one day soon I was going to hit the ground like he had, a corpse on the cobblestones. Eventually I was loaded onto a train. It was full of people, packed in like cordwood. I was screaming out, until I got tired. It was hot and wretched. Eventually we got to the camp, but some didn't even survive the train ride.

RASMUSSEN: And how was the camp?

CSEMEGI: At first it wasn't so bad. It was a prison, but the officer who was in charge of our division had just been reassigned. He had had sex with a female prisoner, another Jew, and it had gotten out. It was a scandal. So for weeks nobody was in charge, and we just sat around. It was terrible, but mostly because it was so boring. Eventually though they found someone to put in charge of us. His name was Göring, and everyone was afraid of him, even the other Nazis. He put us to work.

RASMUSSEN: What kind of work?

CSEMEGI: Carrying stones.

RASMUSSEN: Carrying stones?

CSEMEGI: Yes.

RASMUSSEN: Just that? Did you build anything?

CSEMEGI: No. Or... I don't know, we didn't, but some other prisoners might have. We just carried stones up a hill. I don't know what happened to them afterward. It was horrible. I didn't know what hell was like, before then. We only got a little soup and bread to eat, and even then only sometimes. We would have been starving to death anyway, but we starved more quickly because we were carrying stones for fourteen hours a day. We were so delicate, like baby birds that had fallen from the nest, and we just started to die.

RASMUSSEN: Did you think you were going to die there?

CSEMEGI: I was convinced. After I saw my father die, I knew my life was over. After two weeks of carrying stones, I thought it was just a matter of time before I fell down in the work line, never to get up again. But then the music started.

RASMUSSEN: Music?

CSEMEGI: Yes, music. I didn't know what to think. Every night when I lay down, I would hear music.

RASMUSSEN: Like, just in your ears? Could anybody else hear it?

CSEMEGI: No, only me.

RASMUSSEN: What kind of music was it?

CSEMEGI: It was, I don't know, songs, all different. No two nights were the same. Sometimes it was singing, sometimes it was from an orchestra, sometimes it was like beeps and blips, but musical. They have music like that these days, but I never heard it back then. I always called it technology music. But anyway... some nights it wasn't music at all, some times it was just noise, like static, or hissing, or just a strange alien drone. I didn't like that so much. The orchestral music was my favorite. I had always loved classical music, you see.

RASMUSSEN: How long would it go on?

CSEMEGI: At least a few hours. I didn't sleep much. But, I didn't sleep much even before the music started. I was so hungry, all the time. I used to just lie there at least half the night, feeling my body eat itself. I felt like I had already died, like a ghost. But with the music I was just in a trance, listening...

RASMUSSEN: Did you tell anyone else?

CSEMEGI: No. I was afraid that it would stop if I told anyone. The music brought color back to the world, and I knew I would die if it stopped.

RASMUSSEN: The music helped?

CSEMEGI: Yes. Every night, when it stopped for the night, I would dream about it. I would fall asleep right away, and just dream of the music. And then the next day, I would think about it, and about the night, when it would come again. Everyone else thought I was crazy.

RASMUSSEN: Why did they think you were crazy?

CSEMEGI: I didn't talk to anyone, I hardly took my eyes off the ground. Everyone else thought that I was one of the ones had died inside, and that soon I would die outside too. But I had this life in me, from the music.

RASMUSSEN: Where did you think the music came from?

CSEMEGI: I thought it was God. Singing to me.

RASMUSSEN: God?

CSEMEGI: Yes. Who else could it have been?

RASMUSSEN: Why was it only you that heard it?

CSEMEGI: I don't know why he didn't sing to the others.

RASMUSSEN: <INDISTINCT>

CSEMEGI: No. But, I wish he did. So many more would have survived.

RASMUSSEN: What do you do now?

CSEMEGI: Nothing, I'm retired.

RASMUSSEN: But after the war?

CSEMEGI: I moved to Denmark, to Apenrade, where they still speak German. Germany had betrayed me, you see. I worked as a stonemason. I was never clever with machines, like my father.

RASMUSSEN: Did you ever marry?

CSEMEGI: No. I was too busy with music. I had a record player. It was the first thing I bought after I found work. I didn't even have sheets on my bed, but I bought a record player. I wanted to have music. For years I would listen to records all night.

RASMUSSEN: Do you still listen to music?

CSEMEGI: Always. Less when my son came, since I couldn't afford a nanny, and had to take care of him.

RASMUSSEN: Your son?

CSEMEGI: Yes. I made love to a woman whose house I was working on. Just once, but she became pregnant, and didn't want him. I couldn't let her give him up, so I took him. She didn't want to have anything to do with us.

RASMUSSEN: So you raised him?

CSEMEGI: Yes. And he doesn't like music at all. <laughs> He would cry when I played my records. I hated him for that. But then I found out about headphones, and it was okay. Eventually, they even started making little tape players, that you could take with you. That was wonderful. I could work all day, listening to music.

<tape ends>

In fact, most programming paradigms simply amount to different ways to transform a linear source file into a program with nonlinear behavior.

Some examples:

• gotos that unconditionally jump to another point in the program
• an abort instruction that stops the program at some point other than the end
• a macro facility that substitutes one instruction for one or more other instructions
• a source file concatenation facility that concatenates multiple source files
• an include directive that is substituted for the contents of a source file
• structured repetition and selection, a la for, while, if, and switch
• subroutines and functions
• array oriented programming that replace explicit repetition with implicit repetition
• first class functions which delegation of behavior to the caller
• object oriented programming with dynamic dispatch, which allow the runtime type of an object to determine which instructions to execute
• aspect oriented programming, pattern matching against the structure of the call stack to execute instructions when functions are called or return
• event driven programming, executing instructions in response to external events
• declarative programming, which essentially delegates execution of one program to another

Although each company has a different business model, they and the equity they issue are largely structurally homogeneous. They hold their monies in banks, pay for their expenses with wire transfers and cheques, follow prescribed rules of accounting, and issue stock that operates according to well understood rules. This is not to say that said practices are good or bad. They are simply a known factor.

Cryptocurrencies and tokens, however, are structurally heterogeneous. They have different codebases, modes of operation, levels of complexity, and security models. Although broadly lumped into the same category, they can, by the nature of these differences, have almost nothing in common.

Investing in one is like buying stock in a company with novel business models, banking practices, and accounting methods, and furthermore whose stock is issued under a bespoke scheme and follows unique trading rules.

Accordingly, a much, much greater level of care is required when making such investments. If any one of these novel mechanisms fail, your investment may go up in billowing smoke and flames overnight.

This is not to say that you should completely avoid cryptocurrencies and tokens, just, you know, do your homework.

VXX is a dangerous chimeric creature; it is structured like a bond, trades like a stock, follows VIX futures and decays like an option. Handle with care.

And, currently being algo traded by a program written in Excel VBA.

Strange times indeed.

The Lightning Network has the potential to greatly improve cryptocurrency exchanges.

x:   exchange node
a:   third party node
b:   third party node
<->: payment channel

   BTC     LTC
a <---> x <---> b

   BTC     LTC
a ----> x ----> b
  0.606   1.000

   BTC     LTC
a <---- x <---- b
  0.400   1.010

Maybe it was miasmatic vapors rising up from beneath South of Market streets. Maybe it was the widening gyre opening up under the world. Maybe it was nothing at all. I don't know.

It felt like the world had ended, but I was still there. And the lights of the city glimmered through the window, so, it was still there too.

I rose, dressed, and walked out the front door, into the hallway. For air, I guess. And movement. Try to walk it off.

I walked over immaculately carpeted floors and beside newly painted walls, past the elevator landing, and through the door with the emergency exit sign. I started down the unfinished throat of the building, through which it gasps for air. Down metal stairs. Past primer-painted walls.

I felt like the thirty flights would do me good, maybe shake loose the static fuzz that buzzed in my head.

My mind wandered. The fugue of interrupted sleep gave way to visions of a gossamer fabric, stretching off over the earth in all directions, a network of networks, with nodes like points of light shot through it, streams of data passing between them.

The stairs ended abruptly. I had passed the ground floor. The door ahead of me was marked B5. I tried the handle. It was unlocked. I opened it and walked through.

It was dark. Dim light streamed through from above. I imagined that it was from the lobby, shining from the light fixtures above the marble front desk, through the pile carpet, between cracks in the floor, and down into this subterranean space.

It was huge. A deep hollow between wide supporting columns of concrete. The air was cool and still, down here in the guts of the building.

The floor was covered with moist brown soil. It was carefully raked, and before me stretched neat rows of… something. Of dark shapes.

I walked forward and hunched over, squinting, trying to resolve out the shapes in the darkness.

They were rows of fat black mushrooms. The size of a man's fist. Oozing a sticky red treacle down their stems.

They smelled sweet. I imagined overripe mangos, cleft open to reveal insides not of fruit but of charred animal flesh.

Crouching on my heels, the odor washed over me. Memories that weren't mine came to me unbidden. From deep in my blood.

I saw my great uncle, who, according to whispers within the family was once a zionist terrorist known as the Lion of Bethlehem. He was in his youth, not the old man that I knew from pictures. A pale-faced and red-haired Ashkenazi, he had a knife in his hand, but it cut the dark skin of an arab neck. The knife was a shechita blade. Even though human meat is not kosher, no matter how it is cut.

I saw a swede with green eyes like mine, butchering a snapphane in some muddy Scanian town square. It was a brutal show, to scare other rebels into submission.

I saw a welsh bowman in a field wreathed with fog, nocking an arrow after the one before it had flown straight through an Anglo-Norman's chest. He squinted down the shaft, aiming to take a second life.

More violence committed by men in my line glinted before my eyes, further and further back. The last was a glimpse of a spry homo sapian bringing a huge rock down on a neanderthal's skull, braining him. I started, and focused on the mushrooms in front of me.

I pawed at one, its sap like venous fluid, thick and red, sticking to my fingers.

It looked and smelled disgusting, but I wanted to eat it.

I started to bring my fingers to my mouth, to lick them clean. But there was a thump, off in the distance, past pairs of huge columns of concrete that shot into the darkness and the rows of mushrooms at their feet.

A shadow detached from the far wall and moved in my direction. Fear took me. The stench of the mushrooms was suddenly revolting. I stumbled backwards, wiping my hand on my jeans. I rushed towards door and the stairs beyond, up to the surface, back to the light.

After a few goodbyes and handshakes, everyone headed off in different directions, for different destinations.

The meeting had felt momentous to me, a marker of strange and interesting times to come. I headed to the U-Bahn, alone.

What

On boot and restart, Grin nodes pick a random 256-bit node id which is broadcast to their peers.

Upon receiving a block, a new epoch begins if block_height % 10 == 0. The epoch id is the 256-bit blake2b hash of the block hash of the block that started the epoch. (I.E. the double blake2b hash of the block header.)

At the start of each epoch, every node:

• Calculates the relay weight of itself and all peers using the formula: relay_weight = peer_id xor epoch_id. Relay weight is interpreted as a 256 bit unsigned integer.

• Selects the node among itself and all peers with the highest relay weight as the relay target.

• Determines that it is in stem mode if the relay target is a peer, and in fluff mode if the relay target is itself.

Then, for every stem transaction received:

• If it is in stem mode, it immediately relays it to its relay target.

• If it is in fluff mode, it aggregates transactions until its next patience timer expires, then broadcast them.

Why

"Heavy" peers will naturally be chosen for relay targets, creating agreed-upon stem paths and fluff sinks, and leading to more opportunities for transaction aggregation.

Notes

• In a well-connected network, one node may be the sink for all transactions during a given epoch, and thus see all unaggregated transactions during the epoch. It may thus be desirable to stick to random mode selection as in Dandelion++, so as to break up stem paths with randomly selected fluff sinks.

• If block hashes are used directly as the epoch ID, peers could select peer IDs with a large number of leading 1s, thus biasing relay target selection towards themselves. Thus, we take the double blake2b hash of the block header as the epoch ID.

• Since the epoch ID is known by all, a node could pick node IDs that had high relay weight during that epoch. To provent this, if a node connects to a new peer it should use a randomly assigned peer ID for the current epoch.

• Should this modification be called Kademlion, or Objective-Dandelion?

• Thanks to Antioch Peverell for the clear description of Dandelion++ whose language I shamelessly copied.

• There is a diverse and colorful cast of characters to choose from that all provide an appropriate scope and difficulty level, such as:

• tree: Print a graphical representation tree in visual form

• strings: Extract plaintext strings from binary files

• wc: Count the lines, characters, and bytes in a file

• ls: List the contents of a directory

• nc: Read and write bytes to network sockets

• cal: Print a cute text calendar

• cat: Copy streams to stdout

• cut: Extract delimited fields from linewise text records

• sort: Sort lines

• uniq: Print only unique lines

• The existing implementation provided by your system serves as a specification, giving you an idea of how the tool works and whether or not your implementation has the same behavior.

• The core functionality of these utilities is very simple, allowing a learner to quickly build something useful. And, many have additional features, allowing a learner to add and build if they wish. ls is simple, but ls -l is quite the project!

• Many creative additions are possible, like colorful output, expressive configuration, and fun and useful new features.

• IO and error handling are often front-and-center when writing these utilities, which provides a great chance to get used to explicit error handling.

• structopt makes argument parsing a breeze. And, by leveraging the type system and custom-derive, it provides a nice example of a situation where Rust has enormous advantages over other languages, allowing you to do more with less code.

• Rust binaries are fast to load and run, so performance is on par with native C implementations, and often much better than implementations in slower languages.

• Rust binaries are self-contained, so packaging and distribution is manageable, so you can share your work with the world.

• It's fun to use utilities that you wrote in your day-to-day workflow!

• There are lots of fabulous examples of utilities in the rust ecosystem, like ripgrep, fd, bat, exa, and hexyl. (Damn, David Peter is a beast.)

• If you're teaching others, a simple utility like strings makes for a great demonstration of the basics of the language.

I think whether you start with the book or a project like this depends on the learner.

I much prefer to jump in and struggle mightily, so I started with a project like this (what eventually became just), but I think a lot of people might prefer to start with the book, or at least parts of the book.

Popcorn Time-style video streaming apps seem to be vulnerable to legal action by rightsholders.

For example, the popcorntime.sh domain was recently suspended, and the operator of a site which merely provided information about how to obtain and use Popcorn Time was sentenced to prison.

Although given that Popcorn Time's servers do not themselves host infringing content this may seem a bit unfair, it is simply the reality of the world we live in.

It is interesting to note, however, that although web browsers can be used in exactly the same way as Popcorn Time, namely searching for and viewing copyrighted movies, the developers of web browsers have thus far not faced successful legal challenges.

I believe that there are two major factors that differentiate Popcorn Time from web browsers, and contribute to Popcorn Time's legal vulnerability:

1. Upon opening a web browser, the user must supply the URL of the site they wish to visit. Compare this to Popcorn Time, where upon opening the application for the first time, the user is immediately presented with a selection of unlicensed Hollywood movies to download.

   This difference greatly weakens Popcorn Time's claims against contributory copyright infringement. The developers of Popcorn Time cannot credibly claim to be ignorant to the types of movies that their users are downloading, whereas a web browser developer can credibly claim that the choice of website to visit is always left to the end user.

2. Web browsers have substantial non-infringing uses. "Substantial non-infringing use" is jargon for a legal test used in the United States which protects the creator or purveyor of a piece of technology from liability for its use in infringement by users if that technology has "substantial non-infringing uses". For the canonical example, see Sony Corp. of America v. Universal City Studios, Inc..

Whereas a web browser provider can rightly claim that there are many websites, and it's possible an infringing one might slip in, there would be no way of knowing, the popcorn time developers cannot claim the same. There is a single, fixed Popcorn Time backend, run by the Popcorn Time team, serving the same search results to every user.

Fortunately, even given the above, I believe that Popcorn Time could implement a small number of strategic changes that would allow it to withstand future legal aggression:

• Add a URL bar, like a web browser's, to the top of the current GUI.
• Make the URL bar empty when opening the app for the first time, and display no default search results to the user.
• When the user enters a URL, use the existing Popcorn Time API protocol to contact the backend at that URL, and begin displaying search results from that backend to the user.
• If the app is closed and re-opened, keep the URL bar and the search results populated from the last run of the app.

These changes would be simple, have a minimal impact on the current (quite excellent!) user experience, and leverage interaction flows, i.e. a URL bar, that users already understand.

Additionally, the Popcorn Time team should create an official default search backend which focuses exclusively on free, non-infringing, user-created content.

These steps would, I believe, nicely protect the developers and distributors of Popcorn Time from further legal challenges:

• Popcorn Time, when first opened, would display no search results by default, and would require the user to direct the app with the URL of a site that they would like to visit. This would avoid the current situation where a litigator sitting in front of a judge can open the Popcorn Time application, and it will by immediately display a choice selection of infringing content, which makes for a terrible first impression.

• Users of the Popcorn Time application could use it to access both infringing and non-infringing content, providing a nice argument that the application does in fact have substantial non-infringing uses.

• Infringement via the application would be entirely at the direction of the end-user, and not directly assisted by the default search results provided by the developers.

• Developers wouldn't be running a search back end with infringing content, which is the only component of the current Popcorn Time system that stores problematic metadata about infringing content.

• I suspect that the official free-content focused search backend would be successful and useful in its own right.

• Since the search backend could now be switched by end users, a very large number of third-party backends would likely appear, serving content that might not be otherwise available from the current Popcorn Time backend.

In short, Popcorn Time should become a browser, and then all those lawyers and their handlers can go pound sand.

TL;DR

Why

• Messaging is a subset of social media.
• Users are tired of the wild proliferation of messaging apps.
• Social networks are all different, making them hard targets for standardization; messaging apps are all the same, making them easy targets for standardization and interoperability.
• Messaging is easier to scale.

How

• Build on the matrix protocol.
• Extend email.
• Or maybe both.

Update: I no longer believe Matrix is fit for use.

Why

messaging is a subset of social media

Messaging is a key feature of all social media platforms; decentralizing messaging is a prerequisite to decentralizing social media. And, even though it is a subset of social media, it still captures many of social media's central challenges: spam, moderation, and, most importantly, identity.

users are tired of the wild proliferation of messaging apps

The average user is more negatively impacted by the proliferation of messaging apps than they are by the proliferation of social networks.

I have heard many people express irritation that they must use an inordinate number of messaging apps to communicate.

I haven't heard the same complaints regarding the proliferation of social media platforms. My best as to why this is the case is that the need to communicate one-on-one with an individual has no substitute. If I'm meeting Bob for lunch, being able to message anyone but Bob is completely useless. So, I must use whichever app Bob uses, or get Bob to use whatever app I use, and, if we don't have a common messaging app, one of us will need to install a new one, furthering the proliferation problem.

social network distinctiveness

It's tempting to think that decentralizing social media should be begin with the features that we most readily associate with social media platforms, like posts, news feeds, and liking. However, the implementations of these features differ, and different social media platforms provide very different experiences.

This makes these features of social media a hard target for standardization. However, the messaging features of these platforms are all nearly identical, making messaging an easy target for standardization.

The goal is to decentralize social media as a whole, not just messaging, but messaging can be used as an initial step, with further extensions tackling the various individual features of social media platforms.

messaging is easier to scale

At the upper end, tens of millions of users may engage with an individual tweet, whereas group messages are limited to no more than fifty users. This makes messaging a more attractive initial target for decentralization, since it avoids needing to hit massive scale on day one.

a clear target

So, to summarize all the above, decentralized messaging has an obvious target feature set to aim for, a strong benefit to end users that will drive adoption, puts off hard scaling challenges, and can be extended in the future to all the features we associate with social media.

How

I see two promising and complementary paths to decentralized messaging: building on the new and shiny Matrix protocol, and gradually extending email.

The Matrix protocol has the huge advantage of being modern. It already supports many, if not most, of the features of modern messaging apps.

Email, on the other hand, is ancient, weird, and has no support for modern luxuries like end-to-end encryption or user-presence notifications. However, email is extremely widely adopted, and a broadly supported and popular "Email 2.0" might receive a great deal of support.

Although it would be a challenging process to navigate, email could be extended with features until it reaches parity with modern messaging apps, and further extended to support the features of existing social media networks. These extensions can be added in backwards compatible ways that allow mail agents to negotiate upgrades, falling back to plain email when extensions are not available.

These extensions could include:

• delivery receipts
• optional read receipts
• user presence information
• binary serialization for efficiency and extensibility
• end-to-end encryption
• WebRTC signalling for negotiating VOIP and video chat
• signed introduction tokens to reduce spam
• a standard extension mechanism

A hybrid approach might be to design an email-to-matrix protocol upgrade negotiation mechanism, allowing legacy email addresses to seamlessly upgrade to a modern messaging protocol.

Whatever the approach, building a decentralized messaging protocol and integrating it into twitter would serve as an excellent foot in the door for decentralizing the entire social media landscape.

Intermodal is a new command-line BitTorrent metainfo¹ utility for Linux, Windows, and macOS. The binary is called imdl.

It can create, display, and verify .torrent files, as well as generate magnet links.

It has lots of features and niceties, is easy to install and run, and is hopefully just the beginning of an ambitious project to make decentralized content sharing better.

Features include:

• Attractive progress bars that display hashing throughput.
• Automatic piece length picker that uses the size of the torrent to pick a good piece length.
• Ignores junk files, like .DS_Store, by default.
• Detailed error messages.
• Warnings for common issues, like non power-of-two piece lengths.
• Support for all commonly used metadata fields, like info.source and info.private.
• File inclusion and exclusion with --glob PATTERN and --glob !PATTERN.
• Torrent verification with imdl torrent verify.
• Torrent display with imdl torrent show.

You can install the latest version of imdl to ~/bin with:

curl --proto '=https' --tlsv1.2 -sSf https://imdl.io/install.sh | bash

Development is hosted on GitHub, where you can find the code, the issue tracker, and more installation options.

Give it a try and let me know what you think!

I'm eager to hear what works, what doesn't, and what features you'd like to see added. I'll be working on novel functionality—more on that below—and I'd love to hear your critical feedback and ideas.

You can get in touch by open an issue, joining the discord server, or sending me an email.

Happy sharing!

¹ A BitTorrent .torrent file, also known as a metainfo file, contains information that allows peers to locate and retrieve the contents of a torrent. Creating and publishing this metainfo is required to make the contents of a torrent available to peers.

Mentioning BitTorrent always carries the risk of prompting discussions of the unauthorized sharing of copyrighted or censored content. Intermodal is not intended to facilitate such unauthorized sharing. Discussion of unauthorized sharing is not permitted in any project space, including GitHub and Discord.

What happened to your personal library?

Rows of LPs, shelves of VHS tapes, binders of CDs and DVDs, or maybe hard drives stuffed to overflowing.

It used to be common to maintain a personal content library, but in the last decade, most of us stopped. We ditched the tedium of tagging and sorting for Netflix, Spotify, and YouTube.

Whenever I think about this I feel a wistful longing for the past. And I don't think it's just nostalgia.

Modern content channels are usually designed around a feed and automatic recommendations, and don't make a strong distinction between things that are in your library and everything else. This makes it too easy to consume content compulsively and replaces active search and curation with guzzling down what's on tap, biasing you away from what you like and towards what everyone else likes.

Beyond that, once-accessible items often disappear due to obscure legal and contractual machinations out of one's control.

Worse still, content that is below an invisible popularity threshold is hard to find, not available, or doesn't appear in recommendation streams. One of my favorite tracks from my old music library was a song from a collection of music by people on Usenet called "It's Six AM and Gary's Refrigerator Plays a Raga". Definitely not available on Spotify.

And, if you make something yourself, you can't just put it into your own library, or send it to a friend so they can throw it in theirs.

This is profoundly saddening.

Why did we stop curating our own libraries?

Centralized apps have replaced decentralized content networks due to ease of use, user experience, and incentives.

These factors have pushed people away from BitTorrent, store-bought CDs mixtapes, and personal libraries, and towards apps like Spotify and Netflix.

Ease of Use

For all their flaws, centralized apps are incredibly easy to use. Just open a browser tab and press play.

To get content into your own library and play it, you need to use a number of applications in concert: a web browser to search, another app to download, a file browser to organize, and finally a player to listen or watch. A chore, even for technically adept users, and impossible for the non-technical majority.

Features

Centralized apps maintain large, proprietary databases of metadata, so features like search, recommendation, and preview work flawlessly.

Most desirable features are only as good as the metadata they're built on, so if you're curating a personal library, you have to curate the metadata along with it.

This is the primary reason I gave up on my personal music library: I spent endless amounts of time making sure that metadata was uniform and correct, and although I found some great tools to help, it still felt like a part-time job.

Incentives

Centralized apps usually have built-in monetization mechanisms. If you like content you find through decentralized channels and want to support the creator or publisher, there is no easy means to do so.

Because of this, first-party releases on decentralized content networks are rare, and resources are instead lavished on centralized apps.

Where do we go from here?

The feature-gap between centralized apps and decentralized content networks is vast.

Fortunately, there is a simple way to close that gap:

Developing standards for structured, machine-readable metadata in a simple, universal format.

Existing content does contain metadata. However, this metadata is limited to specific content types, for example MP3 tags; or modes of transport, for example BitTorrent.

By developing a standard for metadata manifests that can accompany any kind of content, across all modes of transportation, many desirable features become more reliable and dramatically easier to implement:

• Newly downloaded releases can be integrated into a library automatically, applying the user's preferred scheme for naming, sorting, and tagging.

• Content from a user's library can easily be exported for sharing in a format that's appropriate for transport, for example as a torrent, Usenet NZB file, or .zip archive.

• By identifying the location and format of content, releases can be transcoded for mobile devices and web browsers, either in advance or on the fly, and made available to all a user's devices without manual intervention.

• Rich search indices can be built from collections of content, without needing to resort to complex and error-prone heuristics.

• Immutable identifiers, for example ISBN numbers, allow metadata to be automatically updated from external sources.

• Creators and publishers can include a Bitcoin tipping address in releases, so end users can reward them directly.

• Digital signatures over and alongside metadata manifests can allow authenticity of releases to be verified, allow publishers to sign new updates to old releases, and form the basis of a decentralized, privacy-preserving reputation system.

These features have the potential to not just bring the decentralized content ecosystem to parity with centralized services, but to surpass them.

Intermodal

The project for developing these metadata standards, as well as tools and apps to make these standards useful, is called "Intermodal".

Seamless intermodal transportation, enabled by containerization, has led to enormous efficiency gains in the transport of physical goods.

Before the invention of the humble 40' shipping container, and the intermodal transportation network that it enabled, the majority of the world's goods were transported as so-called bulk break cargo.

Bulk break cargo is packed in bags, barrels, boxes, crates, and drums of varying sizes. Loading such cargo onto a truck, cargo ship, or train took labor and time, and was a major source of friction and cost in the shipping of goods from place to place.

The invention and standardization of intermodal containers, the 20' and 40' shipping containers of today, changed all that. Cargo could now be packed into uniformly sized containers of known strength and weight, of a size suitable for transportation by train, truck, or ship. This standardization made the once back-breaking work of moving cargo through multiple transportation modes easy and fast. What once required teams of stout men could now be done with cranes and other equipment.

In many ways, when it comes to decentralized digital content, we are very much living in an era of bulk break cargo. Painstaking effort is required to prepare content for transportation across different modes, e.g. BitTorrent, the web, or Usenet; and it is either impossible or takes complex heuristics to answer simple questions, like what is a piece of content, anyways?

By standardizing metadata, we can make more efficient the conveyance of digital content across different modes of transportation, and build rich services on top of that content.

Thus, "Intermodal".

imdl

I've been thinking about how to move the decentralized content ecosystem forward for a long time, and until recently I've been stuck on the question of what, exactly, to build first.

I've decided to start with a BitTorrent metainfo (that is to say, .torrent file) creator. The first version is full of features and niceties, and is ready for users today.

The binary is called imdl, and development is hosted on GitHub.

BitTorrent is widely used, and a torrent creator is much simpler than a torrent client, tracker, or index, making it a good place to start.

Although imdl does not today have any groundbreaking new features, and no functionality for creating metadata manifests, it is a natural place to start adding such features.

imdl is written in Rust. Rust is fast, correct, and makes it easy to distribute self-contained binaries to users. Additionally, Rust can be compiled to WebAssembly, so bits of imdl might eventually be adapted to run in the browser.

Over time, imdl will be extended with all manner of useful features, so torrent-creation functionality lives under the torrent subcommand: imdl torrent create, imdl torrent verify, imdl torrent show, and so on.

I owe a huge debt of gratitude to the many existing open-source torrent creators, which have been a font of inspiration and good ideas. As part of the process of developing this first release of imdl, I combed through them for useful and requested features, and implemented all of them.

What's next?

First and foremost, I want imdl to be a useful torrent creator today. If you find any bugs, or have feature requests, don't hesitate to open an issue or hop on the discord!

Contributions of code, documentation, clean up, tests, ideas, and discussion are all welcome!

Many features, such as integrity checking, signing, timestamping, and release metadata are gated on the basic design and implementation of the manifest, so that will be the next major area of work.

Your feedback on the design and implementation of the manifest would be very valuable.

Additionally, there are a bunch of more concrete good first issues on GitHub, some large, some small:

• Setting up code coverage on CI.
• Adding web seeds to torrents..
• Adding another kind of web seeds to torrents.
• Supporting the addition of arbitrary keys to created torrents.
• Adding a config file containing profiles to use for torrent file creation.
• Adding support for generating file padding.
• Adding a whole new subcommand to edit existing .torrent files.
• Fixing a no-doubt silly bug causing tests to leave behind .torrent files in /tmp.
• Adding file selections to magnet links.
• Creating .torrent files from magnet links.
• Verifying multiple .torrent files at a time.
• Showing nonstandard fields in imdl torrent show.
• Adding a --quiet flag to imdl torrent create.
• Showing corrupted piece information during verification.
• Supporting BitTorrent V2 torrents.

And finally…

Thank you so much for reading this rather long-winded blog post!

imdl, modest though it may be, is a love letter to the Internet, to sharing, and to BitTorrent. I hope you find it useful, and it becomes even more useful in the future.

Which, all things considered, is probably better than nothing.

But don't suck democracy's dick and expect good decisions, wise governance, and functional laws to shoot out of it.

• Making Shmurah Matzah
• Bonded warehouse

The similarity is striking.

In a matzoh factory, batches of matzot are prepared within 18 minute time periods, after which all implements used to prepare the matzot are meticulously cleaned. This is because, in order to be halachically correct, matzot must not undergo fermentation, and 18 minutes is the time after which fermentation is presumed to have occurred.

In a bonded warehouse, goods may,

under supervision by the customs authority, be manipulated by cleaning, sorting, repacking, or otherwise changing their condition by processes that do not amount to manufacturing.

In both spaces, strict rules limit activities to arbitrary thresholds.

Water and flour may be mixed, but must be baked within 18 minutes, otherwise fermentation will be deemed to have occurred.

Goods may be cleaned, sorted, and repacked, but not more, otherwise manufacturing will be deemed to have occurred.

Both spaces exist to satisfy rules ostensibly handed down by higher powers, namely God and The State.

Hopefully such cursed spaces can be contained within their current boundaries, and further superstitious contamination can be avoided.

If you're interested in hacking on just, I'd love to help!

Just is fun to work on, for a few reasons:

• It's a language! Languages are just inherantly fun, since they're an intersection of design, aesthetics, UX, and engineering. Just has all sorts of the bits that you'd expect:

  • A nice, character at-a-time parser

  • A somewhat disgusting recursive descent parser

  • An abstract syntax tree

  • Bunches of static error checking and name resolution

  • Pretty error messages

• It has a ton of users! It's really fun to implement features, and then see them get used in real justfiles written by real random internet people

• It has a ton of tests! The copious amount of both unit and integration tests often save me from shipping bugs, and make refactoring and feature work much easier.

• There is always more work to do! Just users ask for crazy things all the time. Sometimes someone will create an issue, and I'll think to myself, "WTF this person is crazy for wanting that.", and then eventually I'll start to accept the idea that it's a good feature, and then I'll finally implement it and everyone will be hapy.

Check out the good first issues and hit me up on the discord!

The Muslims claim Mohammed was the last of the prophets, and that after his death God stopped advising earthly religions. But sometimes modern faiths will make a decision so inspired that it could only have come from divine revelation. This is how I feel about the Amish belief that health insurance companies are evil, and that good Christians must have no traffic with them.

The post is about the advantages of the Amish health care system, which seems to have much lower costs and equal effectiveness when compared to conventional American health insurance centered health care.

The post is gripping (well, at least if you're interested in why American health care is so expensive), so I recommend reading it. But briefly, the Amish seem to have much lower costs with the same quality of care due to:

• Bargaining collectively.
• Getting a discount because they have a reputation for paying their bills on time.
• Not going to the doctor for little things.
• Not suing doctors, and thus not getting excessive medical care because a doctor is trying to avoid a malpractice lawsuit.
• Aid and cost sharing being run as nonprofits.
• Keeping administrative expenses low.
• Not taking risks with their health.
• Avoiding excessive spending, because costs are shared by the community.

I wonder if much of this could be replicated with, not an insurance plan, but, something else… an "uninsurance plan":

• The uninsurance company would not directly or indirectly cover any medical expenses. This would make it very cheap.

• The uninsurance company would bargain collectively on behalf of its members.

• Uninsurance members that did not pay their medical bills in a timely fashion would be kicked from the plan and be ineligible to rejoin.

• Uninsurance members would be forbidden from suing for medical malpractice except in cases of gross negligence. (Unsure about this one, since it seems to open up members to abuse, but if it's a net benefit, why not?)

• Provide members with a health savings account. Health savings accounts are tax-advantaged savings accounts that allow members to pay for qualifying medical expenses from the account. Although the Amish don't have HSAs, giving members access to an HSA should be cheap, and so shouldn't increase the cost of uninsurance. Additionally, since it is the member's own money, it doesn't introduce any perverse incentives.

• Give members access to the negotiated price lists up-front, to allow and encourage them to comparison shop. This might be tough, because health care providers keep these prices secret, so they can play hard ball with insurance companies that they negotiate with. But, being able to see what you're going to pay for something is a prerequisite to trying to save money and shop around, so this would be ideal.

• The uninsurance company would be run as a nonprofit, or public benefit company.

• Since the uninsurance plan is not insurance, it would be uncomplicated to supplement it with an additional insurance, cost-sharing, or risk pooling, scheme to cover unexpected costs, similar to Amish Hospital Aid. This additional scheme would not be run by or affiliated with the uninsurance plan, in order to avoid increasing costs for non-participants.

I suspect that such a plan would be very cheap, to make a number up, perhaps no more than $10 per month. If it were only $10 per month, and members got an HSA, they might want to join just for that. And, if they got insurance-negotiated rates when paying out-of-pocket while being uninsured, the would almost certainly be willing to pay for it.

Such an uninsurance plan would encourage consumers to plan ahead, shop around, and save for medical expenses in their HSA, maybe giving them health care approaching that of the Pennsylvania Dutch.

Lexical path cleaning simplifies paths by removing ., .., and double separators: //, without querying the filesystem. It is inspired by Go's Clean function, and differs from the Go version by not removing . if that is the only path component left.

I implemented this for a command line utility I'm working on, but split it off so others could use it.

There are a few reasons I prefer lexical path cleaning to fs::canonicalize:

• If the input is a relative path, the output will be a relative path. This means that if the input is a path the user typed, and the output path is displayed in an error message, the message is more likely to make sense to the user, since it will more obviously relate to the input path.

• It simplifies some-file/.. to . without any fuss, even if some-file is not a directory.

• It never returns an error, because it makes no system calls.

There are some reasons you might prefer fs::canonicalize:

• fs::canonicalize respects symlinks.

• fs::canonicalize always returns an absolute path. (Although you can do std::env::current_dir().join(path).lexiclean() if you want an absolute path.)

Are there any other reasons to prefer one over the other? I'd love to hear them!

It is very lightly tested! If you intend to use it, I encourage you to submit additional tests containing paths you might encounter, if you think the existing tests don't cover them. In particular, I haven't thought about all the exotic prefixes that Windows paths might be adorned with, so there might be bugs there.

I don't expect to modify the crate or add features to it beyond what I need for my own purposes, so if there are additional features you want, please consider opening a PR! Of course, if you find a bug, I will happily fix it.

• BGP has well known security flaws that cause real problems. It is very common that misconfigured or malicious route advertisements cause outages or redirect traffic to an attacker. (C.f. BGP hijacking against Bitcoin miners.)

  Some kind of PKI system which let AS operators associate one or more public keys with their AS, and handled transfers of IP space between ASs, would allow BGP updates to be signed by the AS owner's key and totally eliminate this class of vulnerability.

  Additionally, it would allow ASs to end-to-end encrypt and authenticate BGP communications. BGP updates aren't exactly sensitive, but why not, ya know?

• There are around 60,000 ASs in existence, so a modest 7 tx/second message rate would be enough to process an update to each one 10 times every day. If the purpose of the network were just to handle public key updates, likely only a small fraction of this would be needed for routine and emergency key updates.

  There are 837,482 IP prefixes, so these could be turned over once every 1.5 days or so. IP blocks move relatively infrequently, like AS keys would, so this is probably

• AS operators are usually well funded, and have ready access to compute, network, rackspace, and skilled humans. If running some kind of box with not-totally-crazy resource and maintenance requirements marginally increased their security, they would all do it.

• AS operators have a high degree of control over their network peering relationships, and many large networks have direct physical connections to multiple other ASs. This mitigates the risk of partitioning and starvation attacks somewhat.

• There is a high degree of cooperation, goodwill, and existing relationships between AS operators. This makes me wonder if schemes that I usually see as not fit for use in cryptocurrency contexts, like Ripple-style consensus systems, might actually work in the AS context. Ripple has no credible mechanism to deal with consensus failure if network operators disagree on the state of the network, and there are many incentives that might cause Ripple network operators to disagree on network state. However, in the AS context, there is little reason for network operators to disagree, and they are highly motivated to such disagreements out of band.

• Maybe no global consensus mechanism is necessary, and some kind of simple PKI would be good enough! However, it would be very nice if the current network consensus could be summed up in a small amount of data , such that it would be easy and low-bandwidth to discover if you were out of sync with the network, or being partitioned in the case of single-homed networks.

In this post, I'll explain how I organize the codebase of just, a command runner that I wrote.

just was the first large program I wrote in Rust, and its organization has gone through many iterations, as I discovered what worked for me and what didn't.

There are some things that could use improvement, and many of the choices I made are somewhat strange, so definitely don't consider the whole project a normative example of how to write rust.

Overview

Users mostly interact with just by running the main binary from the command line.

However, the crate actually consists of an executable target, in src/main.rs, and a library in src/lib.rs. The main function in main.rs is a thin wrapper that calls the run function in src/run.rs.

The reason that just is split into a executable target and a library target is because there is a fuzz tester in fuzz, and a regression testing framework at janus, and both of these use testing functions exposed by the library.

Submodule Organization

I prefer to keep my module tree flat, so you'll notice that all my source files are directly under src. I find that this makes it easy to remember what's where, since I don't need to remember what subdirectory each source file is in.

I use a fuzzy file searcher, fzf, to switch between files, so having a ton of files in my src directory doesn't bother me. If I used a tree-based file viewer in my editor, I might prefer to group modules into directories by topic.

Common Use Statements

I prefer to group all my use statements together in a single file called src/common.rs.

Then, at the top of every other file, I include them all with use crate::common::*;.

I think this is somewhat uncommon, and most people prefer to put use statements at the top of every file, with just those things used in that particular file.

Both approaches are totally reasonable. I find that grouping use statements into a single file saves a lot of duplication at the top of every file, and makes it easy to start a new file, since you can just write use crate::common::*; and have everything you need in scope.

This does require that I pick unique names for everything that I want to put in common.rs, but I haven't found that to be particularly burdensome.

Submodule Names and Contents

Most modules contain a single definition, either a function, trait, struct, or enum, that is used in the rest of the codebase. These modules are all named after the public definition, and that definition is exported in common.rs, so use crate::common::*; will bring that definition into scope, without needing to qualify it with the module name.

As an example, just's lexer is called Lexer, and is in src/lexer.rs.

In common.rs, it is exported with pub(crate) use lexer::Lexer;.

Since modules are always named after their sole export, it's pretty easy to figure out where something comes just from the name. Since Lexer is a type from just, and not a dependency, that means that it's probably defined in lexer.rs.

A few modules, like src/keyword.rs, contain more than one thing. For modules like that, common.rs just exports the module itself, with pub(crate) use crate::keyword;, and the module name is used when referring to the definitions inside keyword, like keyword::EXPORT.

If a name is from a dependency, then you can see where it comes from in common.rs.

Error Handling

For testing purposes, I like to use error enums, instead of Box<dyn Error, or equivalent. I find that this makes it easy to write tests that look for specific errors. Also, just has detailed error messages, and this lets me separate error message formatting from error value generation.

There are two main kinds of errors, CompilationError, in src/compilation_error.rs, and RuntimeError, in runtime_error.rs.

As you can guess, CompilationError is for problems related to compilation, e.g. lexing, parsing, and analyzing a justfile, and RuntimeError is for problems that occur when running a justfile, e.g. I/O errors and command execution errors.

I currently don't use any of the many error handling helper crates, but in other projects I use snafu, and if I were to rewrite just, I would definitely use snafu.

Clippy

I use clippy, the animate paperclip/rust linter, to automatically check the codebase for issues.

Clippy has many lints that are either pedantic, or which restrict things that are totally reasonable in many contexts. I like a lot of these, but I didn't want to go through all of them and decide which lints to enable, so I turned on all the lints, even the annoying ones, and then just disable lints that I don't like as I encounter them.

You can see this at the top of src/lib.rs.

How does it work?

just does a lot of stuff! This makes it hard to give a concise overview of how everything works, but I'll do my best!

Run

The run function is pretty short, so definitely check it out. It's in src/run.rs. It does some setup, like initializing Windows terminal color support and logging, then parses the command line arguments.

Configuration

Just calls parsed command line arguments a Config. The command line arguments are parsed with the venerable clap, and then stored in a Config struct, which is passed around the rest of the program.

Everything related to setting up the clap parser, and parsing the command line arguments is in src/config.rs.

Subcommand Running

just has a few distinct modes it can run in, e.g. actually running a recipe in a justfile, listing the recipes in a justfile, or evaluating the variables in a justfile. These are called subcommands, and you can see the different subcommands in the Subcommand enum in src/subcommand.rs.

Once a config is parsed, the function run_subcommand in config.rs handles executing the correct subcommand.

For the rest of this post, I'll cover Subcommand::Run, which is the subcommand which is responsible for actually running a justfile.

Compilation

The justfile source is read and the compiler is invoked in the run_subcommand function in config.rs. The Compiler is defined in src/compiler.rs, and has a single short method that calls the lexer, the parser, and the analyzer.

There's no particular reason for having a Compiler struct, since it doesn't have any fields, so it's really just for organization. I would be totally fine with having a module src/compile.rs, and just exporting a single compile function from that module.

Lexing

The first step of compilation is to split the source text into tokens, which is done by the Lexer in src/lexer.rs. The lexer looks a lot like a recursive descent parser. It has a bunch of different methods, and those methods call each other to produce the different tokens.

The entry-point to the lexer is Lexer::lex.

Lexer is relatively well-commented, so please take a look if you're interested!

Tokens

The lexer produces a Vec of Tokens. The Token type is in src/token.rs. Each Token contains a TokenKind, defined in src/token_kind.rs. A Token contains a reference to the soruce program, as well as information about the offset, length, line, and column of the token. A TokenKind tells you what kind of token it actually is.

Parsing

The Tokens produced by the Lexer are passed to a Parser, defined in src/parser.rs, and the main entry point is Parser::parse.

The parser is a recursive descent parser that walks over the tokens, figuring out what kind of construct it's parsing as it goes.

Modules

The output of the parser is a Module, defined in src/module.rs. A Module represents a successful parse, but has not been fully validated. Just does a lot of static analysis, like resolving names, inter-recipe dependencies, and inter-variable dependencies, so not every Module is valid.

You can think of a Module as being like an AST, that still hasn't been statically analyzed for correctness. Inside a Module are Items (src/item.rs), which contain the different source constructs, like Alias, Assignment, UnresolvedRecipe, and Set.

Analysis

The next phase of compilation is analysis, performed by the Analyzer, defined in src/analyzer.rs.

The Analyzer makes sure that all references to recipes and variables can be resolved, and that there are no circular dependencies.

Justfile

The output of the Analyzer is a Justfile, defined in src/justfile.rs.

A Justfile represents a parsed and analyzed justfile. It contains all the recipes, variables, and expressions, all resolved and ready to run. It is the totus porcus, as it were.

Running

A justfile is run with Justfile::run, which takes a Config, a Search with information about where the justfile is and where the working directory is, variable overrides passed on the command line, and a list of arguments.

The arguments are parsed into recipes and arguments to those recipes, and finally those recipes are run with Justfile::run_recipe, which actually executes each recipe, and all dependencies.

Testing

just takes files, parses commands out of those files, and then runs them. I am acutely aware of how this might go wrong, and would feel real bad if just somehow got confused and ran a command that nuked someone's hard drive.

Because of this, I go pretty crazy with testing. There are four kinds of tests: unit tests, integration tests, fuzz testing, and ecosystem-wide regression testing.

Unit Testing

Unit tests are spread around the codebase, in submodules named tests. Each tests submodule contains tests for whatever's in the containing module.

I'm not strict about covering everything with unit tests, but I do cover everything with integration tests. If something doesn't seem to be tested in a unit test, it's probably tested in an integration test.

Integration Testing

Integration tests are in the tests subdirectory, roughly organized by topic. The vast majority are in tests/integration.rs, which test a full run of the just binary, supplying standard input, args, and a justfile, and checking that standard output, standard error, and the exit code are correct.

Fuzz Testing

Fuzz testing was contributed to just by @RadicalZephyr, and is located in the fuzz directory. It generates random strings and feeds them to the parser. (NOT THE RUNNER, DEFINITELY NOT THE RUNNER.) If the parser succeeds or returns an error, that's a successful run. If the fuzzer is able to trigger a panic, then it's found a bug that needs to be fixed.

Regression Testing

Since a lot of people have written a lot of justfiles, I want to make sure I don't break them when I update just.

To do this, I wrote a tool called janus. Janus is inspired by Rust's crater.

Janus downloads all the justfiles that it can find on GitHub, and then compares how two versions of just compiles those justfiles. The two versions of just are usually the latest release, and a new version with a big, scary change.

Janus compiles all justfiles with both versions, and then compares the result. Ideally, every valid justfiles parses into the same Justfile with both versions, and every justfile with an error produces the same error.

Wrapping Up

That's everything I can think of! Ultimately, much of how you organize your Rust programs comes down to personal preference, so just start mashing the keyboard, see what works, and iterate on whatever doesn't.

glhf!

It is easily the most gruesome thing I have ever written.

Some things of notes:

• I had to write my own function to sort lists.

• I had to write my own function to split strings.

• AppleScript has records, which are like dictionaries, except they do not support dynamic properties. Consider that. You can do {foo: 1} to create something that is morally equivalent to {"foo": 1}. But what do you do if you want to use a property name that's in a variable?

  In AppleScript, you cannot. You can only wail and gnash your teeth.

  This lack of dynamic property access meant that I couldn't use records at all in my script, for which I suffered greatly.

• There are vast numbers of predefined symbols with names that invariably conflict with your own variables and functions. Somehow, AppleScript appears to implement reverse lexical scoping, and these predefined symbols override your own.

• On a Mac, there are a large number of characters that are easy to type with the option key. So, of course, !=, >=, and <= can be written as ≠, ≥, and ≤, and

• The inscrutable raw property accessor is written with «class NAME». Yes, those are double chevrons.

• There is a line continuation character, but it is ¬. (Option + L on a Mac keyboard.)

• Property access, bar.foo, can be written as foo of bar or bar's foo. Except in some contexts, where only foo of bar is accepted. I have run into these contexts many times, but I am still unable to predict them.

• There are wholly optional keywords that can be used but do nothing. You can use the word the in front of any expression, which does nothing. set the x to the 1 is exactly the same as set x to 1.

• There are multiple ways to do almost everything. For example, you can define a function with to function(…) or on function(…).

The language's smatterings of levity are, sadly, quickly overwhelmed by how dysfunction it is.

Here are actual snippets of actual code that I actually had to write:

set AppleScript's text item delimiters to d

set l to s's every text item

set i_track to (item i of l)'s track number

to trash_file(l)
  do shell script "mv " & ¬
    quoted form of POSIX path of (l as string) & ¬
    " " ¬
    & quoted form of POSIX path of (path to trash as string)
end

to cancel(m)
  display dialog m
  error number -128
end

set i to my split(f, ".")'s first item as number

if n's length ≠ o's length

if p's visible and ¬
   p's special kind = none and ¬
   not p's genius and ¬
   not p's smart and ¬
   index of last track of p < 1500
  set normal to normal & {p}
end

set old_plays to old's «class pPlC»

delete (some track of library playlist 1 whose database ID is old_dbid)

repeat with i from 1 to count of n
  set old to item i of o
  set new to item i of n
  set oldid to old's persistent ID

  repeat with j from 1 to count of normal
    set p to item j of normal
    set ts to tracks of p
    repeat with k from 1 to count of ts
      set t to item k of ts
      if t's persistent ID = oldid
        delete t
        duplicate new to p
      end
    end
  end
end

This script should run instantly, but takes more than a minute when 10 tracks are selected. This is because of the above triply nested repeat loop, which loops over all the tracks I want to merge, all the playlists in my music library, and all the tracks in those playlists. I had to do it this way because I don't have any form of random access or dictionaries.

Even though the script is pretty simple, it still fails nondeterministically. I am unable to determine what could make such a simple script fail, and nondeterministically at that.

If hell has a programming language, it is definitely AppleScript.

Economists, of course, are wringing their hands and mumbling about Vickrey auctions. What Sony should do, they mutter, is to hold a daily auction for PS5s, and let the market decide the price.

The economists are, of course, quite right. If Sony auctioned off PS5s there would be no lines, no scalpers, and no uncertainty. You could put in a bid at the price that you wanted to pay, and then simply wait until demand had died down for your bid to be filled. As a bonus, Sony would make more money for producing something that people wanted to buy, and more capital to ramp up production.

Unfortunately, the economists don't get their say here, because of their arch enemy, non-economists. Non-economists, or, normal people, as they are otherwise known, as far as I can tell, don't understand that there is such a thing as an inescapable trade-off. They want everyone to get a PS5, everyone to pay MSRP for it, there to be no scalpers, nobody to ever make a profit from demand exceeding supply, and all things to be fair, based on confused and self-contradictory conceptions of unfairness.

So, companies can't hold auctions for scarce goods, and have to set an MSRP, produce whatever they can, and hope for the best.

I wonder though, if there might be some way for a company to hold an auction for their products, but in a way that would be perceived as fair.

Here is one possible setup for such an auction, using Sony as the example company, and the PS5 as the example product:

• Sony sets the MSRP of the PS5, $499.

• Sony produces PS5s, and every day holds an auction for that day's production. Losing bids roll over to the next day's auction.

• Every time a PS5 is sold for more than the MSRP, the difference is added to a reserve pool.

• Every time a PS5 sells for less than the MSRP, that difference is subtracted from the reserve pool.

• Auctions continue whenever the reserve pool has a positive balance, or demand is higher than supply.

Essentially, any time someone pays over MSRP for a PS5, they ensure that eventually, someone will get a PS5 for less than MSRP. If someone rich or impatient buys a PS5 for $1000, two less impatient people can eventually buy PS5s for $250.

I think, perhaps, this would be perceived as fair. But, with real people, you never know.

The best way is always to stop when you are going good and when you know what will happen next. If you do that every day when you are writing a novel you will never be stuck. That is the most valuable thing I can tell you so try to remember it.

Reformulated for programmers and equally valuable:

The best way is aways to stop when you are going good and you have just written a failing test. If you do that every day when you are writing a program you will never be stuck. That is the most valuable thing I can tell you so try to remember it.

If you start programming for the day, a failing test to fix will get you right back on track.

Instead of having to muster willpower to get started and brainpower to figure out what you were doing and what to do next, you can mindlessly do whatever it is that will fix the test.

After that, you'll be much more likely to be in the flow of things, and be able to keep going in good spirits.

Most of what happens there isn't surprising to me, with the exception of pricing for online sexual services, which is much higher than I would have expected.

As an example, take private, one-on-one cam shows. Browsing reddit.com/r/sexsells, the going rate seems to be between $2.50 and $5.00 per minute, or $150 to $300 per hour.

This is mysterious to me.

Looking at ads on eros.com, offline prostitutes seem to charge $300 an hour. This isn't the amount advertised for a one hour session, but the marginal difference in price between a one hour and two hour session, and thus a reasonable estimate of the hourly rate, when preparation and travel are factored out.

Given that private cam shows are legal, can be done at home, and require minimal equipment; while offline prostitution is physically dangerous, illegal, unpleasant¹, and highly taboo, it seems strange that they are priced roughly the same.

A priori, I would have expected a price difference of 10× or more, like $300 per hour offline and $30 per hour on cam.

Another interesting point is that girls often charge for things that are free or cheap, like saying the customer's name, or teledildonics.

These are certainly things that customers are willing to pay for, but in a competitive market, sellers that didn't offer them for free would lose business to others that did.

So, what's going on? Who knows, but here are a theories, in order of most to least dubious:

• Maybe men are so irrational when they're horny that all of microeconomics immediately goes out the window?

  Price theory, supply and demand, competition, production theory, all obliterated by the inability of men to just, like, fucking think for one god-damned second, and try to get a better deal.

  I think this is appealing, but probably not true. Most of the time, if you think that supply and demand don't matter in some market you're just wrong.

• Customer service overhead. Communicating and handling logistics with customers might take a lot of time. Also, if men only want short cam shows, then the overhead of doing multiple 10 minute shows might be substantial.

  This would be plausible, except discounts for longer cam shows are small to non-existent. If scheduling, logistics, and costume changes contributed a great deal of overhead, I'd expect steep discounts for longer shows.

• Perhaps there's a supply shortage, because there aren't enough attractive women to satisfy demand?

  I don't think this is it either. From what I can tell, men are extremely varied in their tastes, and there's demand for every age, body type, and race. Demand is softer² in some places than others, but it doesn't drop off a cliff anywhere.

  Also, if this were the case, I would suspect that less desirable women would undercut more desirable women with budget services, but I haven't observed this.

• It also could be that the women on reddit.com/r/sexsells are simply at the very top of the game. They might be the most sophisticated, online, and educated, and so the prices there just aren't representative of the rest of the market.

  I would need to do more research, but this doesn't seem very likely, since I think their prices are inline with those found elsewhere.

• Another possibility is that I'm underestimating the social costs of online sex work. It is very hard to prevent someone you know from finding your onlyfans, the sex work taboo is strong, and the possible perpetual loss of privacy is real.

  I think this is definitely a factor. However, there are lots of ways to avoid getting outed, and many women seem to successfully do online sex work anonymously, for example by wearing masks, and they charge the same high prices for their services.

• The fact that online sex workers receive most of their income via digital payment services probably has a number of nontrivial impacts.

  Digital payment services leave a paper trail and are a potential target for audits, might force online sex workers to pay taxes on their earnings when offline sex workers don't.

  Also, such services are fabulously prudish, and sex workers are deplatformed regularly.

  This all stems from extreme anti-competitive regulation in the underlying finance, banking, and payments industries. There is little competition, a high cost of entry, and ubiquitous fear of association with anything "icky".

  This seems like it's definitely a factor, and I think we can actually quantify its impact: Sex workers often list Bitcoin as their preferred payment method, and offering a 20% discount for paying in BTC isn't uncommon.

  So, perhaps digital payments being involved accounts for 20% of the high prices.

  (Of course, as an unironic ancap, I find all this regulatory interference deeply distasteful. As great Murray Rothbard once said³: "If the state has no right to the sweat of a man's brow, it surely has no right to the sweat of an e-thot's ass.")

• Custom sexual services might have an extremely high opportunity cost. An obvious alternative to one-to-one activity like private camming, texting, and making custom videos is one-to-many activities like making content for OnlyFans, marketing on social media, and camming for multiple users.

  This is a really one compelling for me. Posting content to a heavily trafficked subreddit to drive users to an OnlyFans page potentially offers a huge return on time and effort.

  Top creators on OnlyFans can earn $100,000 per month, so camming with a single man might not make economic sense in comparison.

  An additional clue that this is a significant factor is that creators often charge customers $15 or $25 dollars to say their name in a video. Initally this confused me, but I realize now that it's because it makes it harder to repurpose the video for OnlyFans and resale, indicating that minimizing opportunity cost is a very real concern.

None of these theories feel like they explain everything, but in combination they likely explain a lot.

Predictions

I have some predictions about the online sex industry in general, and since they might be of interest I'll include them here.

• I think that OnlyFans will let creators broadcast cam shows from the platform. Existing cam sites charge usurious fees, up to 85% of what performers earn. Since OnlyFans has already undercut the rest of the industry with its modest 20% fee, I look forward to existing cam sites competing on price or being obliterated.

• As the taboo around online sex work continues to fade, a supply glut will lead to a price crash. Being an OnlyFans creator will be only slightly more risque then being an instagram thot, attracting a huge number of new creators.

  Eventually, this will impact the price of both of content on OnlyFans, as well as the cost of more personal sexual services, as creators who are finding it difficult to succeed in efficient but competitive markets for one-to-many content turn to less lucrative but less competitive one-to-one services.

• A service, again possibly OnlyFans, will become popular for custom sexual content creators, but only if logistics, communication, and payment is a significant source of friction.

¹ I am basing this entirely on the number of times I've seen prostitutes on Reddit entreat their customers to please wash their assholes before visiting them.

² Lmaaaaaaao.

³ Murray Rothbard did not say this.

After searching a bit, I found this video, which shows the same person with different hair lengths, with the hair uniformly short over the whole head.

I think it's quite interesting that a random YouTuber may have created a best-in-the-world reference, even if it's for something as mundane as haircut lengths.

Yes, it is optimal. No, it won't work in real life.

The state, of course, ignores this. Its reach exceeds its grasp, and we are left with fragile, sub-optimal, poorly implemented plans that are, without exaggeration, worse than a free-for-all, and much worse than market allocation.

The state makes the same mistake in all spheres, because it makes no distinction between designing policy and implementing policy.

The opposite of this is design for manufacturing, where designers of a product modify a design with manufacturing constraints in mind, even if it makes the design worse on some axes. The final outcome, of course, is substantially better.

The product is subject to fewer delays, costs less, and can be made in higher quantities.

However, we cannot expect the state to grasp this simple wisdom, for it is utterly bereft of the incentive to do so.

Unfortunately, you couldn't talk to each other. I thought about it a lot, so trust me on this. You would have a thought, and then that thought would trigger whatever process causes you to speak, but then at the exact same time you said something, the other you would say something, and you would both say "No, please go ahead." but at the exact same time. You would probably both laugh and get a little red, but then you would feel silly for getting embarrassed in front of yourself.

And then, even though you couldn't communicate, you would have the most amazing experience together. You would walk towards the center of the room, your space shoes tapping out the same tempo on the white floor, stopping just a couple feet apart. Maybe you would take your space gloves and space helmet off so you could give each other Eskimo kisses and exchange the perfect high-five.

Then you would think for a minute, "Should I?" and you would both nod and sort of start to circle around each other. And then you would walk away from each other and leave through the other door, into the other half of the universe. You would get into her spaceship, with her mix CD in the CD player, and it would be the same as the mix CD in the spaceship that you had left behind (it would even start playing right where yours had stopped) and you would fly home.

Sometimes, at night, you might feel a little creepy about it. You would think about how you were sleeping in somebody else's bed, in somebody else's whole world. But that would only last for a second, and then you would think about how she was sleeping in your bed, and how nice the time you spent together was, and you would soon snuggle under the covers and fall asleep.

Bitcoin hurts the ability of the state…

…to print money by forcing it to compete with a highly liquid deflationary asset.

…to collect taxes by providing individuals with the means to store wealth and transfer funds while avoiding regulated entities with mandatory reporting requirements.

…to issue debt, because the creditworthiness of the state is backstopped by its ability to print money and collect taxes.

I have been expecting for quite some time that USG would take decisive action against Bitcoin, and have been gobsmacked, on an ongoing basis, that this action has not come.

If I were a statist, I would be shouting from the rooftops that Bitcoin must be stopped. Or, more likely, I would be whispering into some politician's ear: It is what you fear it could be.

But I am not. So I am gleeful.

I originally became interested in blind mints while thinking about Lightning Network wallet usability issues. When Lightning works, it is fantastic, but keeping a node running and managing a wallet present a number of challenges, such as channel unavailability due to force closes, the unpredictability of the on-chain fee environment, the complexity of channel backup, and the involved and often subtle need to manage liquidity.

All of these problems are tractable for a skilled node operator, but may not be soluble in the context of self-hosted wallets operated by non-technical users, hereafter normies. If this is the case, then normies may have no choice but to use hosted Lightning wallets, compromising their privacy and exposing them to custodial risk.

Chaumian mints, also known as Chaumian banks, or blind mints, offer a compelling solution to these problems, particularly when operation is federated. Chaumian mints, through the use of blind signatures, have extremely appealing privacy properties. The mint operators do not know the number of users, their identities, account balances, or transaction histories. Additionally, mint transactions are cheap and can be performed at unlimited scale.

Mint implementations, typified by eCash, have hitherto been centralized, and thus, like all centralized, custodial services, expose users to custodial risk in the form of operator absquatulation and mismanagement. To fix this, mint operation can be federated, with all operations performed by a quorum of nodes controlled by different parties.

Despite these interesting properties, Chaumian mints have largely been forgotten. This post gives an excellent overview of the phenomenon. I believe that Chaumian mints are currently severely underrated in general, and in particular deserve consideration as a potential avenue for improving custodial Lightning Network wallets.

Compared to a naïve hosted Lightning Network wallet, a service operated as a federated Chaumian mint offers excellent privacy, usability, security, and scaling.

Privacy: Privacy leaks from a Lightning mint come in two forms, internal and external, when a mint operator or an outside actor, respectively, observes sensitive information.

Blind signatures protect against internal privacy leaks, making them a strict improvement in that respect over custodial Lightning wallets.

When compared to a single-user Lightning network wallet, Lightning mints also protect against external privacy leaks. If the activity of a single-user Lightning Network wallet can be observed, which is possible but non-trivial, all such activity is preemptively that of the owner of the wallet. However, similar to a standard custodial Lightning Network wallet, any observable Lightning Network activity of a Lightning mint is the aggregate activity of its users, who thus form an anonymity set. If the number of users, and thus the anonymity set size, is large, external privacy leaks are also prevented.

Usability: Compared to a self-managed Lightning Network wallet, and similar to a standard custodial Lightning Network wallet, Lightning mint wallets offer superior usability. A user need not be concerned with the details of node operation or channel management, and can deposit to and withdraw from their account with standard Lightning Network invoices.

Security: The security of a Lightning mint is weaker than that of a self-hosted wallet. A quorum of federation members can abscond with funds. However, compared to a standard custodial Lightning Network wallet, security is greatly improved. Additionally, federation members might be located in different jurisdictions, making the mint robust to regulatory interference. Furthermore, members might be entities with online reputations, such as anonymous Bitcoin Twitter users with an established history of productive shitposting, providing further assurances against mismanagement and fraud.

Scaling: Mint operations are extremely lightweight, similar to Lightning Network transactions, so scaling properties are similar to the Lightning Network itself. Additionally, users need not manage their own channels, so a well-capitalized federation can open channels efficiently, lowering the per-transaction channel management overhead.

Interoperability and market dynamics: Additionally, my hope is that such systems will be developed with a standardized protocol for communication between wallet interfaces and mint backends. This would allow users to use different backends with the same local wallet interface, encouraging competition in the market.

For more discussion of Chaumian mints and their applicability to Bitcoin, see fedimint.org. Elsirion, the author, is also at work on MiniMint, a federated Chaumian mint with Bitcoin and eventually Lightning Network support.

To close with a bit of speculation, I believe that Chaumian mints were never of particular interest or importance because they were limited to interoperating with the fiat currencies of the time. With the ascendance of Bitcoin, mints now have access to a powerful, decentralized, and uncensorable currency , made economical and fast by the Lightning Network.

I believe this layering of Chaumian mints on top of Bitcoin and the Lightning Network will, in the fullness of time, be demonstrated to be enormously powerful, and make Chaumian mints themselves worthy of renewed study and consideration.

It is a complex and interesting topic! Here is my probably-inaccurate summary:

The four stages of wound healing are hemostasis, inflammation, proliferation, and maturation.

Hemostasis is the body's immediate reaction to and stabilization of the wound. Blood clots and stops flowing from the wound. Or doesn't, in which case hemostasis is the first and last stage of wound healing.

Inflammation comes next, which includes processes that prevent infection and initiate healing. Injured blood vessels leak transudate (water, salt, and protein) white blood cells head to the wound, tissue turns red and swells, and bacteria and dead cells are removed from the wound.

Proliferation is the phase where the bulk of tissue reconstruction and healing takes place. Lost tissue grows back, and the wound closes. In the final phase of proliferation, epithelial cells regrow and cover the wound.

Maturation, also called remodeling, is the finalization and cleanup phase. The plumbers, electricians, and carpenters leave the building site, and all the loose ends are tied up. Temporary cells die off via apoptosis, and the new tissue reorganizes and strengthens.

The appropriate dressing depends on the characteristics of the wound, and so, as you might imagine, there exists a rich terminology for wound description.

A sloughy wound is with a layer of infected gunk, usually yellow, You've probably noticed this when you've had an infected scrape. Slough is dead tissue that must be removed for the wound to heal, and a sloughy wound should be covered with a moist dressing that allows the slough to liquefy. I gather that mechanical debridement of slough, e.g. the use of wet-to-dry dressings, although still widely used, is no longer a standard of care.

A necrotic wound has some amount of dead skin or flesh covering or surrounding the wound, usually of a ghastly black color. If necrotic tissue is badly infected, it should be surgically removed. However, since this is invasive and destructive, the preferred alternative for the removal of non-infected necrotic tissue is the use of a moist, occlusive dressing promoting autolytic debridement, the natural separation of viable and non-viable tissue.

A granulating wound wound in the process of healing. It has a nice bright, healthy red color, and should be covered in a moist occlusive dressing and left to heal.

An epithelial wound is in the final stages of healing, with new skin growing over and covering the wound.

Interesting tidbit, if a wound is deep, it should be packed with some kind of dressing, to prevent premature wound closure before the wound void fills in with new tissue.

For my own rather boring although mildly sloughy wounds, I went with hydrocolloid dressings. Hydrocolloid dressings are occlusive dressings which create a moist environment for wound healing. As they transition from sloughy wounds to granulating wounds, I might switch to just using a film dressing, which are more flexible, comfortable, and durable.

After all this, I'm a little bummed that I don't have much weirder, graver, more complicated wounds that would demand more complex and interesting care. 😂

If you want an HTTP server to listen on port 80 and serve some directory full of files, you tell the service to bind to port 80 and pass it the path of the files to serve:

$ http-server --port 80 --files /srv/www
Serving `/srv/www` via HTTP on port 80.

This is backwards. Let's call this kind of configuration "internal configuration", because it's configuration that happens inside programs.

Instead, processes should declare a namespace of resources that they consume or produce:

$ mount http-server /http
Mounted `http-server` instance at `/http`.
$ tree /http
/http
  /socket
    /listen
  /imports
    /files

After mounting, resources would be mapped as you see fit, from outside the process, without having to stop or reconfigure the service:

$ listen 80 /http/socket/listen
Connections to port 80 are being forwarded to socket `/http/socket/listen`.
$ export /srv/www /http/imports/files
Filesystem `/srv/www` exported to `/http/imports/files`.

Let's call this "external configuration", because it's configuration that happens outside programs.

External configuration has a number of benefits:

• Uniformity. Consistent configuration. Configure using system tools, not binary-specific flags and configuration files. System tools can be featureful, well documented, and universal.

• Security. Processes have no permissions that they aren't specifically granted. Processes cannot "ask" for permissions.

• Dynamic reconfiguration. Processes can be reconfigured on the fly.

• Faster development. Internal configuration requires developers of each program to supply options for binding ports, consuming filesystem trees, exporting filesystem trees, and dynamic reconfiguration. With external configuration, developers export resources, and configuration and consumption of those resources is handled externally.

This mail is inspired by Chia's coin IDs. Chia coin IDs consist of:

sha256(parent id, sha256(scriptpubkey), amount)

One consequence of this is that outputs in Chia have a dedicated textual ID. This seems beneficial, separate from any larger technical consequences, and made me wonder if we couldn't replicate that in Bitcoin.

Outputs, a.k.a. outpoints, are commonly represented as TXID:INDEX. For example, the first output of transaction c7dd35a4f81977feac0d235d0e77265cacd362bfc2f0246e384a80d3b0a53a9b is represented as c7dd35a4f81977feac0d235d0e77265cacd362bfc2f0246e384a80d3b0a53a9b:0.

I find this representation unsatisfying:

• It places outpoints hierarchically beneath transactions, even though after a transaction is confirmed, the outpoint is relatively independent.
• It can't be double-clicked to be easily copied.
• It isn't popular or widely used. I tried using it in searches in a few block explorers[0], and none of them support it, even though they do support direct searches by transaction ID, block hash, and block height.

I propose a dedicated representation of outputs using Bech32m. Bech32m is especially legible, due to its human-readable part, and is compact, and easy to type and verify. Although having error correction doesn't seem absolutely necessary, it doesn't seem like a downside. The representation uses "coin" as the human-readable part, with the payload being the transaction ID, followed by the 4 byte index.

For example:

c7dd35a4f81977feac0d235d0e77265cacd362bfc2f0246e384a80d3b0a53a9b:A0

Becomes:

coin1clwntf8cr9mlatqdydwsuaextjkdxc4lctczgm3cf2qd8v9982dsqqqqqqqenjt7

Anacdotally, I find that many non-expert users I talk to think and talk about Bitcoin as if it were an account-based system, and tend to think in terms of transactions. I wonder if having coin IDs, in the form I propose or in some other form, would help remedy this, similar to how transaction ids, block hashes, and addresses help reify those concepts. The particulars of the representation are of secondary importance.

Best regards,
Casey Rodarmor

[0] blockstream.info, blockchain.com, mempool.space, blockcypher.com, and blockchair.com

The Terrestrial Dividend consists of a tax and a dividend. Revenue is generated with a tax on the unimproved value of land and distributed as a cash dividend to all citizens.

Why?

If You're in Favor of Wealth Redistribution

If you are in favor of wealth redistribution, you should want to raise as much money as possible, as fairly as possible, and get as much as possible into the hands of those who need it.

The Terrestrial Dividend accomplishes all of these goals.

If You are Against Wealth Redistribution

If you are not in favor of wealth redistribution, you should want revenue generation to be as efficient as possible, and to minimize the negative economic impact of distribution. Additionally, you should want wealth redistribution to be done in such a way that if it is harmful, incentives align to reduce it.

The Terrestrial Dividend accomplishes all of these goals.

The Terrestrial Tax

The Terrestrial Tax is economically efficient. The supply of land is fixed, so a tax on the unimproved value of land does not prevent the production of more land. A tax on widgets, on the other hand, reduces the incentive to produce widgets.

The Terrestrial Tax is progressive. Land is owned by the wealthy, so the wealthy would pay a much greater share of the tax. Due to the fixed supply of land, the tax cannot be passed on to tenants.

The Terrestrial Tax respects privacy. The government does not need to know who owns what land, or what they are doing with it. The tax can be collected with anonymous payments, and only in the case of non-payment must the government involve itself.

The Terrestrial Tax cannot be avoided. It is impossible to hide land or disguise use of land.

The Terrestrial Tax encourages productive economic activity. Since the tax is levied on the unimproved value of land, under-utilized land is a liability, and will be brought into productive use or sold, not held as a speculative asset.

The Terrestrial Tax is simple. Income, sales, value-added, and corporate taxes require enormously complex and err-prone reporting. The details of these taxes are the source of endless political litigation. Under the Terrestrial Tax, the only complexity is in fairly valuing the unimproved value of land, clearly an easier task.

The Terrestrial Tax is legible. The negative effects of a too-low or too-high tax rate can be observed and the rate corrected.

The Terrestrial Dividend

The Terrestrial Dividend is beneficial. Cash is more useful in all circumstances than in-kind payments of the same value. The people who need help will get the most benefit possible.

The Terrestrial Dividend is fair. All citizens receive equal-sized cash payments. There is no need to exclude certain recipients, since the wealthy will already pay more tax than they receive as dividend.

The Terrestrial Dividend is efficient. Cash payments avoid the overhead of defining the details of and administering in-kind benefits.

The Terrestrial Dividend is what people want. People prefer cash over in-kind benefits of the same value.

The Terrestrial Dividend is unobtrusive. It is not means tested, nor does it require an application. The poor are the least equipped to fill out applications and submit documentation of income, so this ensures that even the very worst off have the best chance of receiving benefits.

The Terrestrial Dividend is legible. The negative effects of a too-low or too-high dividend can be observed and the amount corrected.

Together

The Terrestrial Tax and Dividend are good policies on their own, but even better together due to aligning incentives.

If you want to increase the amount of the dividend, you should want to increase the value of all land, so that the dividend can be increased.

If you want to reduce the amount of the tax, you should want to increase the value of all land, so the tax rate can be reduced without reducing the divided.

Under the Terrestrial Dividend, everyone should care about reducing government overhead and waste, because it comes out of their own pockets.

Also, everyone should care about removing bad policies and implementing good ones, because they increase the value of all land and make everyone better off.

Tax the land, pay the people.

Hi Maalika,

My name is Casey Rodarmor, and I am a former Google SRE and SWE.

I am writing you today because you may be one of the few people that can deliver us from the multi-messenger hell that the human race finds itself in today. Everyone needs to use six or more messaging apps, and everyone hates it.

However, there is an easy way out of this. Email is a federated, decentralized, standards-based messaging platform that everyone already uses. The only reason people use other messaging protocols is because those messaging protocols have features that email doesn't have.

Here is the path to email world domination. It is very simple:

Add the features that email is missing, one by one, in a backwards compatible way.

These features include:

• Chat messages with low UI overhead and no subject line
• Group chats
• Read receipts
• Voice calling
• Video calling
• Typing indicators
• Message requests
• Stickers
• Better rich text support
• End-to-end encryption
• Faster message delivery
• Pay money for guaranteed delivery

These features can all be implemented in backwards compatible ways that gracefully degrade when they aren't supported.

These features should be designed and implemented in an open process, involving the internet community, public RFCs, and implementations by multiple clients and service providers.

This is a major undertaking, but the benefit is huge, both for Google, Gmail, and the internet community.

Every single non-email protocol will fall by the wayside, and we can return to a simpler, more productive, and more secure world, one where everyone just uses email to communicate, an open, standards-based, internet native protocol.

This could be, without exaggeration, the most important work of your life.

Do you have time to discuss this with me? I have no agenda, just someone who thinks that this is possible, and ultimately very achievable.

With best regards, Casey Rodarmor

Return email to its rightful place as the one true messaging protocol. It's this or use a dozen messaging apps for the rest of your life, there is no other realistic option.

How?

Add the features that make people use other messaging protocols to email.

Which features?

Contacts

Description: Chat, mobile notifications, read receipts, and other features, should not be available to arbitrary addresses. User approves addresses who can use these features.

Implementation: Add-to-contacts UI in client.

Degredation: N/A.

Chat

Description: Dedicated chat UI. No subject line. Return to send.

Implementation: Add dedicated chat UI to client. Messages sent from chat UI have header chat: true. Messages received with chat: true are shown in chat UI. Only chat from contacts appear in chat UI. Chat from non-contacts appears in message request UI.

Degradation: Message desplayed in inbox UI.

Mobile Notifications

Description: Some messages trigger mobile notification. User configurable.

Implementation: Mobile app has notification category for mail from contacts with header urgent: true.

Degradation: No mobile notification.

Read Receipts and Typing Indicators

Description: See read receipts and typing indicators on sent mail.

Implementation: Add receipt-endpoint: <URL> header to outgoing mail. Display read receipts and typing indicators sent to own receipt-endpoint. Only send read receipts and typing indicators to contacts.

Degredation: No read receipts or typing indicators.

Voice Calling

Description: Initiate voice calls from within client.

Implementation: Query MX server for voice call endpoint. Display voice call button next to conversations where MX server supports voice calls.

Degredation: No voice call button displayed when not supported.

Video Calling

Same as voice calling.

Message Requests

Description: Email from arbitrary senders should go into a message request folder, instead of in the inbox, to prevent phishing attacks, and encourage users to whitelist contacts which enables richer features.

Implementation: Email from senders who are not contacts goes into message request folder. Message request folder is distinct from spam folder.

Degredation: Email appears in main inbox.

Emoji

Description: Mail consisting of a small number of emoji is displayed in a larger font.

Implementation: Display mail consisting of a small number of emoji in a larger font.

Degredation: Emoji appear smol and sad.

Stickers

Description: Users can send "stickers" which are scaled appropriately.

Implementation: Display mail consisting of a single image scaled to UI.

Degredation: Images appear at fixed size.

Improved Rich Text Support

Description: Allow rich formatting without breaking plain text readers or using arbitrary HTML.

Implementation: Messages can indicate that they are formatted as markdown. Format messages for graphical clients and display with added line-breaks for plain text readers.

Degredation: Messages appear as plain text markdown, which is highly readable.

End-to-end Encryption

Description: Messages between users are end-to-end encrypted to avoid being read by third parties.

Implementation: Query MX server for public key of receipient, encrypt mail for recipient with pubkey.

Degredation: Messages are not encrypted. This is strict improvement to not encrypting any email. Once email E2EE is widespread enough, refuse to send mail to recipients that don't support it.

Prevent Replies Leaking Information

Description: Including messages in replies bloats messages, can accidentally leak information, and has is not necessary due to threaded clients.

Implementation: Don't include original message in reply by default. User may use dedicated quote reply UI to include quotes of original message.

Degredation: None.

Faster Message Delivery

Description: Deliver email instantly without any delay.

Implementation: Define mapping of email symantics over HTTP/3 as email/2, providing persistant connections and an efficient binary encoding. Query MX server email/2 support and use it if available, using persistant connections and binary encoding for instant message delivery.

Degredation: Messages are delivered at normal speed.

Disappearing Messages

Description: Messages can be configured to dissappear after some amount of time.

Implementation: Query if recipient MX server supports disappearing messages. If so, let sender set amount of time before messages disappear. Enforced by recipient, not sender, since sender enforcement is impossible.

Degredation: Option to turn on disappearing messages is not available when not supported by recipient.

Group Chats

Description: It should be possible to easily add and remove addresses from group chats.

Implementation: Email already supports group emails, but configuring adding and removing addresses from group chats is difficult. Query MX server for group chat support endpoint. Dedicated API for creating and updating group chats, referenced by ID. Group chat emails are associated with ID, instead of just being arbitrary lists of addresses, allowing any participant, if they have the permissions, to add and remove members from chat.

Degredation: Group chats are received as ordinary multi-address emails.

• Sign-up: Pick a domain. This is your username. Register domain through service. Can be transferred out at any time. $10 a year is nothing.
• Profile: Hosted at domain.tld.
• Messaging: Email at whatever@domain.tld. User can use whatever email app they want.
• Social Graph: Contacts via CardDAV.
• Authentication: Done with Oath.
• Permission System: Entirely done with contacts. First pass filtering is done with spam filter. Email from non-contacts goes to message requests folder. Contacts can be marked using CardDAV groups and fields as "friends", which enables bypassing spam filter and seeing private items.
• Feed: RSS at https://username.com/feed.xml. Private items require authentication. Include email address in RSS metadata, and comment via email.

This post, which I'll try to keep up-to-date, if I remember, documents the projects which I wish some talented go-getter would take on, and in which I would invest money in if given the opportunity.

If you are one of these aforementioned go-getters, email me!

• Email-based messaging: The only reason we use anything but email to communicate is because email is missing features that could easily be added. Deliver us from multi-messaging app hell!

• RSS-based social networking: RSS could easily serve as the basis for standards-based social networking, and would be useful even without taking a significant market share.

• Bitcoin-based NFTs: NFTs are getting lots of creative people both excited and paid. Let them suckle at mama Bitcoin's sweet and bountiful bosem instead of Ethereum's shrivled, insecure, bitter, centralized tit. This can't be done on the Bitcoin L1, so should be pursued as an L2. The key here is figuring out how to avoid needing a new token.

• Bitcoin-based smart contracts: Much like the NFT item above. Let the degens feast at the Bitcoin board, not at the Ethereum kiddy table. Must avoid needing a new token. The best path forward is to fork Liquid, add smart contract functionality to Elements, and run it as Bitcoin-pegged federation.

• Self-hosted block game: There should be a Minecraft-like game that can be programmed and modded from within the game.

• Large: The number of functionaries should be large enough to ensure geographic, jurisdictional, and administrative distribution.

• Reputable members: Functionaries should be chosen who would suffer a reputational loss in the case of poor performance.

• Threshold multisig: A M-of-N multisig. M should be at least ⌊N/2+1⌋, to reduce the chance of equivocation.

• Deterministic, functionaries: Discretion is unpredictable and morally hazardous. The semantics enforced by the functionaries should be deterministic and predictable, not discretionary. Semantics should never change, and if they must, changes should be announced long enough in advance to make exit practical.

• Bitcoin-pegged: If the currency of the sidechain isn't bitcoin, users of the sidechain cannot meaningfully exit. Ability to exit incentives the functionaries to be good stewards of the sidechain.

• Replicated state machine: The state of all functionaries should be the same, and it should be able to recreate and run ones own copy of the state machine.

• Sidechain: Functionaries should publish a sequence of block headers where each block header includes the hash of the current state, as well as the hash of the previous state. Previous states should also be made available by functionaries, in order to make the system auditable.

• As-compatible-as-possible-with-mainchain semantics: The ability of users to exit should be maximized, and making the semantics of the sidechain as close as possible to those of the mainchain maximizes the ability to exit, by allowing users to destroy atomically destroy assets on the sidechain in exchange for mainchain assets which mimic the properties of the atomically destroyed assets.

• Probably more reliable and secure than most alternative chains: Alternative chains suffer from many issues. Proof-of-work suffer from a large global pool of potential hashrate that can attack. Proof-of-stake chains suffer from byzantine consensus mechanisms of ever increasing complexity which must operate in a fully adversarial environment, and have economics which allow and incentivize centralization. A multisig chain operates with a far simpler and more understandable security model: the functionaries periodically agree on a new set of transactions, run the transactions on the old state to produce the new state, and sign and publish the result. Such a system should be more reliable, predictable, and secure.

  And not only that, if the functionaries are chosen carefully, such that there is a huge number of them, perhaps greater than 50, and they are all reputable entities, they should be both incentivized to run the chain properly, and with limited latitude for malicious behavior.

Prehistory

• Lots of interesting stuff here that nobody talks about
• Digital Monetary Trust: Private, anonymous, digital bank
• eGold
• Liberty Trust

2009 - Bitcoin

• Bitcoin launches and is the only cryptocurrency for a while

2011 - Early Altcoins

• Pure clones of bitcoin with a few parameters tweaked
• Changed supply, difficulty adjustment, PoW algorithm
• Big lesson was that Bitcoin gets all these things mostly right, no strong advantage to changing them
• A few projects tried to do something different and interesting, e.g., namecoin
• I would actually include Ethereum in this latter category, however Ethereum has problems

2017 - ICO Boom

• In the early altcoin period, launching a coin was relatively hard, because you had to deploy software to computer and get other people to run it
• With Ethereum, you could just write an ERC20 contract and deploy it to Ethereum, so technical bar was very low
• Ethereum normalized tokens, premines, and presales, so community couldn't fundamentally reject zero-value cash grabs

2020 - DeFi and NFTs

• DeFi is basically repackaging of ponzi scheme economics
• Huge NFT bubble as people overestimate what NFTs can do and what they'll become

Crypto Psychological Archetypes

• Grifters: Incentivized to lie, hype, and overestimate what their projects can do
• Astronauts: Underestimate technical complexity, assume all problems can be solved
  • Vitalik is an astronaut par excellence. People in this group underestimate need for security, simplicity, aligned incentives
  • Probably enthusiastic about complex large-scale social and economic interventions. Remind me of fringe political and economic theorists
  • Worst example is economic space agency
• The hoi polloi:
  • Unit bias (Bitcoin is too expensive!)
  • FOMB: fear that they missed the boat with bitcoin, must find new boat no matter how shitty
  • Zero technical understanding, ingest radical bullshit from grifters and astronauts alike
  • Think bitcoin is a prototype. No, bitcoin is like the internet, has problems but better to just deal with them

What's wrong with…?

Ethereum

• Solidity has terrible semantics
• Terrible and insecure code, even in major projects, nobody actually audits contracts
• Scaling comedy: State channels, plasma, plasma cash, sharding, roll ups. No good scaling story. Everything they're pursuing comes with massive costs.
• Massive premime. Fine during PoW, leads to massive centralization post PoS transition
• Security comedy: Solidity is phenomenally bad, everything big gets hacked, see rekt.news
• Optimism has no fraud proofs yet has $X TVL
• Community tolerates tokenization, so everything gets tokenized. Their lighting competitor got tokenized. This is serious karmic rot that infects everything.

DeFi

• Almost all ponzi economics
• No value creation
• No underlying economic activity, all finance
• Can't create credit, can only do collateralized lending, so can't serve most useful credit creation function
• Insanely complex and insecure

Stable Coins

• Actually often pretty high utility. People who want digital dollars can't access them
• Algorithmic stablecoins are doomed
• Best case scenario is digital, private, fully-collateralized bank on crypto rails

Solana

• Wildly centralized
• Insanely complex
• Terrible incentives: Couldn't resist big blockers in same way bitcoin did
• Insane costs to running a full node

NFTs

• Most contracts are fully centralized
• Contents are fully centralized, just point to some server somewhere
• Nobody audits, so each is a special snowflake complexity
• Massive overestimate of how useful NFTs are or what they'll become
• Nothing actually wrong with making digital baubles and selling them

Cardano

• Had a plane ride next to highly technical Cardano guy, very nice, very smart
• Fully just following incentives
• Technicals are terrible

Proof of Stake

• Stake ratchet: Strong centralization pressure
• Merges token holders and miners, in bitcoin these are separate groups who keep each other in check

Monero

• Relatively non-awful. Fair launch, community driven.
• Hard forks mean developers have a lot of power
• Has on-chain privacy, but transactions are 8x larger than bitcoin, so 1/8 transaction throughput
• Lighting is the way for privacy. Use lightning network to mix your coins. Make big channel with tainted coins, pay someone for inbound liquidity w/lightning, slosh your coins over to channel w/inbound liquidity, close back to BTC.

Grin

• Fair launch privacy coin with interesting tech
• Absolutely dead in the water because no VC marketing budget

zcash

• Centralized, blocks just give money to core devs.
• Moon math led to inflation bug. Probably not exploited, but no way to know.

Urbit

• Urbit's okay
• Some technical problems that make me worried
• Noble effort to decentralize social media

Ordinals don't require a separate token, another blockchain, or any changes to Bitcoin. They work right now.

Ordinals can be represented in a few ways:

With raw notation, like so 1905530482684727°. The number is the ordinal number, and the "°" is the Romance language ordinal symbol.

With decimal notation, like so 738848.482684727°. The first number is the block height, and the second is the index of the ordinal within the block.

With degree notation, like so 0°108848′992″482684727‴. We'll get to that in a moment.

A block explorer is available at ordinals.com. You can explore recent blocks, and look up ordinals by number, decimal, degree, or name.

Arbitrary assets, such as NFTs, security tokens, accounts, or stablecoins can be attached to Ordinals.

Ordinals is an open-source project, developed on GitHub. The project consists of a BIP describing the ordinal scheme, an index that communicates with a Bitcoin Core node to track the location of all ordinals, a wallet that allows making ordinal-aware transactions, a block explorer for interactive exploration of the blockchain, and functionality for minting ordinal NFTs.

Rarity

Since ordinals can be tracked and transferred, people will naturally want to collect them. Ordinal theorists can decide for themselves which sats are rare and desirable, but I wanted to provide some hints.

Bitcoin has periodic events, some frequent, some more uncommon, and these naturally lend themselves to a system of rarity. These periodic events are:

• Blocks: A new block is mined approximately every 10 minutes, from now until the end of time.
• Difficulty adjustments: Every 2016 blocks, or approximately every two weeks, the Bitcoin network responds to changes in hashrate by adjusting the difficulty target which blocks must meet in order to be accepted.
• Halvings: Every 210,000 blocks, or roughly every four years, the amount of new sats created in every block is cut in half.
• Cycles: Every six halvings, something magical happens: the halving and the difficulty adjustment coincide. This is called a conjunction, and the time period between conjunctions a cycle. A conjunction occurs roughly every 24 years. The first conjunction should happen some time in 2032.

This gives us the following rarity levels:

• common: Any sat that is not the first sat of its block
• uncommon: The first sat of each block
• rare: The first sat of each difficulty adjustment period
• epic: The first sat of each halving epoch
• legendary: The first sat of each cycle
• mythic: The first sat of the genesis block

Which brings us to degree notation, which unambiguously represents an ordinal in a way that makes rarity easy to see at a glance:

A°B′C″D‴
│ │ │ ╰─ Index of sat in the block
│ │ ╰─── Index of block in difficulty adjustment period
│ ╰───── Index of block in halving epoch
╰─────── Cycle, numbered starting from 0

Ordinal theorists often use the terms "hour", "minute", "second", and "third" for A, B, C, and D, respectively.

Now for some examples. This ordinal is common:

1°1′1″1‴
│ │ │ ╰─ Not first sat in block
│ │ ╰─── Not first block in difficutly adjustment period
│ ╰───── Not first block in halving epoch
╰─────── Second cycle

This ordinal is uncommon:

1°1′1″0‴
│ │ │ ╰─ First sat in block
│ │ ╰─── Not first block in difficutly adjustment period
│ ╰───── Not first block in halving epoch
╰─────── Second cycle

This ordinal is rare:

1°1′0″0‴
│ │ │ ╰─ First sat in block
│ │ ╰─── First block in difficulty adjustment period
│ ╰───── Not the first block in halving epoch
╰─────── Second cycle

This ordinal is epic:

1°0′1″0‴
│ │ │ ╰─ First sat in block
│ │ ╰─── Not first block in difficulty adjustment period
│ ╰───── First block in halving epoch
╰─────── Second cycle

This ordinal is legendary:

1°0′0″0‴
│ │ │ ╰─ First sat in block
│ │ ╰─── First block in difficulty adjustment period
│ ╰───── First block in halving epoch
╰─────── Second cycle

And this ordinal is mythic:

0°0′0″0‴
│ │ │ ╰─ First sat in block
│ │ ╰─── First block in difficulty adjustment period
│ ╰───── First block in halving epoch
╰─────── First cycle

If the block offset is zero, it may be omitted. This is the uncommon ordinal from above:

1°1′1″
│ │ ╰─ Not first block in difficutly adjustment period
│ ╰─── Not first block in halving epoch
╰───── Second cycle

Supply

Total Supply

• common: 2.1 quadrillion
• uncommon: 6,929,999
• rare: 3437
• epic: 32
• legendary: 5
• mythic: 1

Current Supply

• common: 1.9 quadrillion
• uncommon: 745,855
• rare: 369
• epic: 3
• legendary: 0
• mythic: 1

At the moment, even uncommon ordinals are quite rare. As of this writing, 745,855 uncommon ordinals have been mined - one per 25.6 bitcoin in circulation.

Names

Each ordinal has a name, consisting of the letters A through Z, that get shorter the larger the ordinal is. They could start short and get longer, but then all the good, short names would be trapped in the unspendable genesis block.

As an example, 1905530482684727°'s name is "iaiufjszmoba". The name of the last ordinal to be mined is "a". Every combination of 10 characters or less is out there, or will be out there, some day.

Exotics

Ordinals may be prized for reasons other than their name or rarity. This might be due to a quality of the number itself, like having an integer square or cube root. Or it might be due to a connection to a historical event, such as ordinals from block 477,120, the block in which SegWit activated, or ordinal 2099999997689999°, the last ordinal that will ever be mined.

Such ordinals are termed "exotic". Which ordinals are exotic and what makes them so is subjective. Ordinal theorists are are encouraged to seek out exotics based on criteria of their own devising.

Archaeology

A lively community of archaeologists devoted to cataloging and collecting early NFTs has sprung up. Here's a great summary of historical NFTs by Chainleft.

A commonly accepted cut-off for early NFTs is March 19th, 2018, the date the first ERC-721 contract, SU SQUARES, was deployed on Ethereum.

Whether or not ordinals are of interest to NFT archaeologists is an open question! In one sense, ordinals were created in early 2022, when I finalized the Ordinals specification. In this sense, they are not of historical interest.

In another sense though, ordinals were in fact created by Satoshi Nakamoto in 2009 when he mined the Bitcoin genesis block. In this sense, ordinals, and especially early ordinals, are certainly of historical interest.

I personally favor the latter view. This is not least because the ordinals were independently discovered on at least two separate occasions, long before the era of modern NFTs began.

On August 21st, 2012, Charlie Lee posted a proposal to add proof-of-stake to Bitcoin to the Bitocin Talk forum. This wasn't an asset scheme, but did use the ordinal algorithm, and was implemented but never deployed.

On October 8th, 2012, jl2012 posted a scheme to the the same forum which uses decimal notation and has all the important properties of ordinals. The scheme was discussed but never implemented.

These independent inventions of ordinals indicate in some way that ordinals were discovered, or rediscovered, and not invented. The ordinals are an inevitability of the mathematics of Bitcoin, stemming not from their modern documentation, but from their ancient genesis. They are the culmination of a sequence of events set in motion with the mining of the first block, so many years ago.

Ordinal-aware Bitcoin transactions are rather tricky, and must attend to a number of considerations:

• Rare ordinals shouldn't accidentally be lost to the recipient or the fee.
• The ordinal being sent should be aligned to the beginning of the output going to the recipient.
• Additional postage should be added so that the ordinal can be sent onward without needing to merge in additional UTXOs.
• Excess sats should be stripped from the recipient's output.
• Inputs and outputs must be aligned so that the ordinal being sent actual makes it to the recipient.

This requires a great deal of stressful fiddling with transaction input and output size and order, and a great deal of checks for edge cases. You can see all the gory details in the transaction builder.

All that fiddling has paid off, and today we made three transactions on signet:

• This transaction is simple send of mvzwjdjcofe. The first output is change, added to ensure that mvzwjdjcofe is the first ordinal in the output sent to the recipient:

  ord wallet send mvzwjdjcofe tb1qaykcryeds0kmz3azv5tn46dyt3wu5l5qc3djz0

• This transaction sends ordinal nphhwymyrjx to tb1qew25cz5603xqzkw66m5yq9ruflkkpgjyprcdc5:

  ord wallet send nphhwymyrjx tb1qew25cz5603xqzkw66m5yq9ruflkkpgjyprcdc5

  nphhwymyrjx is first in the input, so no alignment output is needed to make it first in the recipient's output.

  However, the input is quite large, so an additional output is added that brings the size of the recipient's output down to 10,000 sats. We could reduce the size of recipient's output to the dust limit, however in that case, UTXOs would need to be merged in to pay for fees when sending the ordinal onwards.

• This transaction sends ordinal 139761296637063 to tb1q02yk08hkp9pkyhwdsdfd0ra437tjcdnrjs0sxv:

  ord wallet send 139761296637063 tb1q02yk08hkp9pkyhwdsdfd0ra437tjcdnrjs0sxv

  There's a lot going on here! Let's break down the inputs and outputs:

  Inputs:

  1. Contains 139761296637063 at offset 7,500.
  2. Needed to pay for all outputs

  Outputs:

  1. Change containing 7,500 sats to make 139761296637063 the first ordinal of the recipient's output.
  2. The recipient's output containing 139761296637063 at offset 0. Worth 10,000, so that the recipient can forward 139761296637063 without needing to merge in additional UTXOs.
  3. Change containing 16,006 sats, to reduce the recipient's output to 10,000 sats.

ord wallet send will hopefully be much easier to use compared to using bitcoin-cli to manually construct ordinal-aware transactions. Give it a shot and let us know what you think!

Good incentives encourage governments to do useful things. Whereas constraints prevent them from doing harmful things, or cause governments to cease to exist if the do harmful things, or at least limit the harm that they can do.

• Cool, cyberpunk branding and design, so people pay attention to it and want to use it. I suggest "The Bitcoin Chaos Network" or "Bitcoin Chaos", for short. Black and white branding with no Bitcoin orange in sight.

• Trading coins for money is encouraged.

• Proof-of-work mining identical to mainnet. No testnet fast difficulty adjustment.

• Development policy of including anything that has a reasonable chance of being merged into core.

One of Bitcoin's core features is that coins have real-world value. A testnet with coins that have no value doesn't reproduce dynamics essential to Bitcoin, and doesn't encourage real-world use.

ord is an ordinal number wallet and the index that serves ordinals.com.

This release of ord is by no means complete, but it now supports making ordinal-aware transactions on mainnet using the ord wallet send command thanks to @raphjaph, and boasts much faster indexing thanks to @callmeier.

ord wallet send

The ord wallet commands interact with an existing Bitcoin Core wallet using Core's RPC interface, and this release features a new send subcommand that constructs an ordinal-aware transaction to send a particular ORDINAL to a recipient's ADDRESS:

ord wallet send ORDINAL ADDRESS

We write extensive tests alongside every feature, but bugs can always slip through, and the project as a whole is still immature, so restrictions apply when using ord wallet send with Mainnet wallets.

ord wallet send will refuse to interact with a Mainnet wallet with a name other than ord, which does not start with ord-, to encourage users to explicitly mark wallets as being intended for use with ord.

Using bitcoin-cli wallet commands with an ord wallet risks spending your rarest and most exotic sats, and using ord wallet commands with your main wallet risks doxing your main stash if you assocaite a spicy ordinal with your identity.

Index Optimization

ord must build and maintain an index that maps transaction outputs to ordinal ranges. ord 0.1.0 now exploits the fact that many UTXOs are spent soon after they're created, and uses an in-memory cache to avoid huge numbers of database insertions and retrievals. ord uses the redb database, which is already quite fast, but using an in-memory cache avoids reads from and writes to redb's B-tree, which are more expensive than the in-memory cache's hashmap.

Backwards Compatibility

ord is still alpha-quality software, so breaking changes are inevitable, but starting with version 0.1.0, we'll indicate when breaking changes are included in a release by bumping the minor version number (0.x.0).

Try it out!

Check out ord 0.1.0 and let us know what you think! ord is CC-0-licensed open-source software developed on GitHub.

Inscriptions

Inscriptions are digital artifacts native to the Bitcoin blockchain. They are created by inscribing sats with content using ord, and can be viewed with the ordinals explorer. They do not require a separate token, a side chain, or changing Bitcoin.

Inscriptions are created by including content, like an image, text, SVG, or HTML, in an inscription transaction. The content is included in the transaction witness, which normally contains signatures and other data proving that a transaction is authorized.

Along with the content, the inscription transaction contains a content type, also known as a MIME type, identifying the type of content to be inscribed.

When mined, the inscription is made on the first sat of the first output of the transaction, permanently and inexorably marking it, distinguishing it from its fellows. It is no longer just a sat, it is an intertwined component of the long and confusing tale that is human art and culture.

Using ordinal theory, the unspent output containing an inscribed sat can be found, and its movements and ownership tracked across time and transactions, allowing inscriptions to traded, gifted, bought, and sold.

This allows inscriptions quite native to Bitcoin. They can be sent to normal bitcoin addresses, in normal bitcoin transactions, and benefit from timelocks, multisig, and all the rest of Bitcoin's infrastructure. To avoid losing them, a wallet that holds inscriptions must perform sat control, the sizing and alignment of transaction inputs and outputs that controls the destination of individual sats, but aside from that, transactions that transfer inscriptions are quite mundane.

Digital Artifacts

Inscriptions are digital artifacts, and digital artifacts are NFTs, but not all NFTs are digital artifacts. Digital artifacts are NFTs held to a higher standard, closer to their ideal. For an NFT to be a digital artifact, it must be decentralized, immutable, on-chain, and unrestricted. The vast majority of NFTs are not digital artifacts. Their content is stored off-chain and can be lost, they are on centralized chains, and they have back-door admin keys. What's worse, because they are smart contracts, they must be audited on a case-by-case basis to determine their properties.

Inscriptions are unplagued by such flaws. Inscriptions are immutable and on-chain, on the oldest, most decentralized, most secure blockchain in the world. They are not smart contracts, and do not need to be examined individually to determine their properties. They are true digital artifacts.

ord 0.4.0

ord is an open-source binary written in Rust, and developed on GitHub. It implements an ordinal wallet, which can create and transfer inscriptions, and a block explorer. There are public mainnet, signet, and testnet instances.

ord is experimental software, and comes with no warranty or guarantees. ord 0.4.0, the latest release, has been tested carefully, and can now be used to make inscriptions on mainnet, and that those inscriptions will not break due to a future protocol change.

Three mechanisms exist to introduce opt-in changes to the protocol, without breaking existing inscriptions: Versioning, optional fields, and mandatory fields.

Inscriptions can contain a version field. The inscription parser will ignore inscriptions with an unrecognized version. This allows introducing fundamental changes to inscriptions, without disrupting existing inscriptions.

Additionally, fields can be marked as optional or mandatory, which determines how an inscription parser treats an unrecognized field. Unrecognized optional fields are ignored but the inscription is normally, while unrecognized mandatory fields render the whole inscription invalid.

Individual features that can be safely ignored if unsupported can be introduced as optional fields, while features that must be supported in order in order to understand an inscription can be introduced as mandatory fields.

Inscriptions are not finished, but this flexibility gives us confidence that future improvements can be made opt-in and non-disruptive.

Let markets and bazaars where rare sats and inscriptions are traded grow and flourish, and may their wares never crack or vanish.

What's missing?

Inscriptions have many unique benefits and features, but they have not yet reached feature parity with other NFT implementations.

Two key features are missing: provenance and decentralized markets.

Provenance is the ability to determine the author of an inscription, or its membership in a set of inscriptions all created by the same person. We have a design that accomplishes this, and its implementation is tracked in issue #783. A transaction creating a new inscription, X, may include an existing inscription, P, in its inputs, which is returned back to the owner in its outputs. Since only the owner of P could have made this transaction, this identifies P as the parent of X. This mechanism is flexible, and can be used to identify an inscription as being created by an individual, or to identify an inscription as being a member of a larger collection. Furthermore, this mechanism is recursive. You can create in inscription that represents your identity, and use that inscription as the parent of an inscription that itself is used as the parent inscription for a collection.

For inscriptions be valuable, there must be venues where they can be bought and sold. We have a sketch for decentralized and trustless offers to buy and sell using partially-signed transactions, and its implementation is tracked in issue #802. The owner of an inscription may offer it for sale by publishing a transaction that includes it as an input, and containing an output that pays to them the sale price. Any third party can take such a transaction, add their own input of at least the sale price, add an output sending the inscription to themselves, and finalize it by broadcasting it to be mined. Offers to buy are similar.

What's next?

Inscriptions have been designed to be native to the web. Inscriptions are byte strings, identified with a content type, and so can be displayed in a browser. HTML, CSS, JavaScript, SVG, MP3, PNG, and JPEG, are supported by the ordinals explorer.

Inscription content is sandboxed so that it cannot make outgoing web requests. However, in the future, this sandboxing will be relaxed to allow inscriptions to use the content of other inscriptions. This will allow for the development of an a modular, on-chain ecosystem of remixing and composition. This is tracked in issue #1082.

Inscriptions are unnamed and untitled, but we hope to give artificers the ability to give their inscriptions globally unique, human-readable names. This is tracked in issue #794.

The future of inscriptions is bright. We hope not only to reach feature parity with other NFT implementations, but to surpass them.

When inscription numbers were originally added to ord, the Ordinals wallet and explorer that powers ordinals.com, they were intended to be stable and never change.

However, now that we have more experience with the protocol, that seems less tenable and has undesirable consequences, as maintaining stable inscription numbers is a challenge in the face of changes to the inscription protocol.

Consider a simple case, an update that allows multiple inscriptions to be created in a single transaction.

The inscription numbers assigned by an implementation that recognizes multiple inscriptions in a single transaction would differ from those assigned by an implementation that does not.

The former implementation would see T1, creating two new inscriptions, and T2, creating a single new inscription, and assign inscription numbers N, N+1, and N+2, the latter implementation would assign inscription number N to the first and only inscription it recognized in T1, and N+1 to the inscription in T2.

There are many such updates that we would like to make or have made which would introduce discrepancies like these, including:

• Multiple inscriptions per transaction
• Inscriptions in reveal inputs other than the first
• Inscriptions with new even fields
• Multiple inscriptions on the same sat

We've been able to make these changes and keep inscription numbers stable using what I've now come to think of as a regrettable hack: cursed inscriptions. Whenever ord indexes an inscription which would not be recognized by an earlier version, it assigns a negative inscription number. This keeps old inscription numbers stable, while still recognizing new inscriptions.

Cursed inscriptions and negative inscriptions numbers have a number of downsides:

• An inscription number now does not tell you anything about the order in which the inscription was made.
• The logic required to keep track of which inscriptions are cursed is a source of bugs and complexity.
• "Blessing" cursed inscription types, i.e., collectively deciding that after a certain block height, certain cursed inscription types will no longer be assigned negative numbers, and be assigned positive numbers instead, requires coordination.
• Cursed inscription numbers are permanently unstable, so a substantial number of inscription numbers are already unstable, even under the status quo.

In light of the above, I propose that we make inscription numbers permanently unstable, and bless all cursed inscriptions, both retroactively and on an ongoing basis. Cursed inscription numbers would be folded into the main sequence, and, going forward, inscription numbers should not be used in URLs, which is already the case for ord, and inscription numbers would be de-emphasized on /inscription pages.

This would substantially simplify the ord codebase, make it easier to produce an implementation that assigns the same sequence numbers, and make future protocol changes easier.

When comparing existing fungible token protocols, there are a few important ways in which they differ:

• Complexity: How complex is the protocol? Is it easy to implement? Is it easy to adopt?
• User experience: Are there any implementation details which have a negative effect on the user experience? In particular, protocols that rely on off-chain data have a lighter on-chain footprint, but introduce a great deal of complexity, and require users to either run their own servers, or discover and interact with existing servers.
• State model: Protocols that are UTXO-based fit more naturally into Bitcoin and promote UTXO set minimization by avoiding the creation of "junk" UTXOs.
• Native token: Protocols with a native token which is required for protocol operations are cumbersome, extractive, and naturally less widely adopted.

Comparing existing fungible token protocols for Bitcoin:

• BRC-20: Not UTXO-based and rather complex, since it requires use of ordinal theory for some operations.
• RGB: Very complicated, relies on off-chain data, has been in development for a long time with no adoption.
• Counterparty: Has a native token required for some operations, not UTXO-based.
• Omni Layer: Has a native token required for some operations, not UTXO-based.
• Taproot Assets: Somewhat complicated, relies on off-chain data.

What would a simple, UTXO-based fungible token protocol with a good user experience for Bitcoin look like? Here's one, called "runes", because it sounds cool.

Overview

Rune balances are held by UTXOs. A UTXO can contain any amount of any number of runes.

A transaction contains a protocol message if it contains an output whose script pubkey contains an OP_RETURN followed by a data push of the ASCII uppercase letter R. The protocol message is all data pushes after the first.

Runes input to a transaction with an invalid protocol message are burned. This allows for future upgrades that change how runes are assigned or created from creating situations where old clients erroneously assign rune balances.

Integers are encoded as prefix varints, where the number of leading ones in a varint determines its length in bytes.

Transfer

The first data push in a protocol message is decoded as a sequence integers.

These integers are interpreted as a sequence of (ID, OUTPUT, AMOUNT) tuples. If the number of decoded integers is not a multiple of three, the protocol message message is invalid.

• ID is the numeric ID of the run to assign
• OUTPUT is the index of the output to assign it to
• AMOUNT is the amount of the run to assign

ID is encoded as a delta. This allows multiple assignments of the same rune to avoid repeating the full rune ID. For example, the tuples:

[(100, 1, 20), (0, 2 10), (20, 1, 5)]

Make the following assignments:

• ID 100, output 1, 20 runes
• ID 100, output 2, 10 runes
• ID 120, output 1, 5 runes

The AMOUNT 0 is shorthand for "all remaining runes".

After processing all tuple assignments, any unassigned runes are assigned to the first non-OP_RETURN output, if any.

Excess assignments are ignored.

Runes may be burned by assigning them to the OP_RETURN output containing the protocol message.

Issuance

If the protocol message has a second data push, it is an issuance transaction. The second data push is decoded as two integers, SYMBOL, DECIMALS. If additional integers remain, the protocol message is invalid.

An issuance transaction may create any amount, up to 2^128 - 1 of the issued rune, using the ID 0 in assignment tuples.

SYMBOL is a base 26-encoded human readable symbol, similar to that used in ordinal number sat names. The only valid characters are A through Z.

DECIMALS is the number of digits after the decimal point that should be used when displaying the issued rune.

If SYMBOL has not already been assigned, it is assigned to the issued rune, and the issued rune receives the next available numeric rune ID, starting at one.

If SYMBOL has already been assigned, or is BITCOIN, BTC, or XBT, then no new rune is created. Issuance transaction assignments using the 0 rune ID are ignored, but other assignments are still processed.

Notes

When displaying UTXO balances, the native bitcoin balance of a UTXO can be displayed with rune ID zero and the symbol BITCOIN, BTC, or XBT.

No attempt is made to avoid symbol squatting, to keep the protocol simple. One possible, but still simple, technique to avoid symbols squatting would be to only allow assignment of symbols above a certain length, with that length decreasing over time, before eventually reaching zero and allowing all symbols. This would avoid short, desirable symbols being assigned in the early days of the protocol, and encourage competition for desirable symbols later on, when such competition might be meaningful.

Hand Wringing

Should such a thing exist? I don't know. It's about as simple as possible, does not rely on off-chain data, does not have a native token, and fits nicely into Bitcoin's native UTXO model. Such a scheme might draw users from other schemes with worse on-chain footprints, and bring developer and user mindshare to Bitcoin, encouraging them to adopt Bitcoin itself.

On the other hand, the world of fungible tokens is a near totally irredeemable pit of deceit and avarice, so it might be a wash.

For this and other reasons, the ord developers recommit to the stability and predictability of inscription numbers, and will not pursue renumbering.

As someone who people in the ordinals community mysteriously pay a lot of attention to, I see myself as having two distinct roles with regards to proposals such as the great renumbering.

One is to have and propose things that I think are good ideas. This will continue, and I don't see any particular reason to self-censor. In other words, the unfettered blog posts will continue. The community needs to understand that these are proposals only, and that I have had and will continue to have wacky ideas.

The other role is as one of the people who helps make decisions about what to implement in ord, the ordinals reference implementation. Raph, as lead maintainer, has the final say, but he hasn't stopped listening to my wacky ideas, so I still have some influence. Those decisions must be made with respect to the userbase of ord and the greater ordinals community.

When I first decided to propose renumbering, I knew that it had to meet a very high bar. Changes to ord and to ordinals must be Pareto improvements, changes to the status quo that leave everyone better off, or extremely close to it. Changes cannot create winners and losers, even if the benefit to the winners might be greater than the harm to the losers.

After reading discussion on GitHub and Twitter, lurking in many a Twitter space, and discussing it with many people, it's clear that the great renumbering does not meet that very high bar, and is better off consigned to the dustbin of history.

A couple of the arguments that I personally found most persuasive:

• Any public discussion will consist only of the most engaged users. Many less engaged users simply won't be aware that a discussion is taking place, or might not participate, regardless of their views. These voices simply won't be heard. This includes people who aren't terminally online, many people who don't speak English as their native language, and people who just don't particularly like arguing online. This means that the bias must be strong towards the status quo,

• A programmer's job, fundamentally, is to drag his (or her!) balls through miles of broken glass if it benefits the user. Unless the status quo is so complex and unmentionable that it is untenable, disruptive changes must be avoided. As a spirited GitHub commenter put it, "Code and protocols get messy as they age. That's reality. Purity is for virgins."

What does this mean, practically?

• ord will commit to the stability of positive inscription numbers. Negative, or cursed, inscription numbers are subject to change at any time, if new cursed inscriptions are recognized.

• At some as-of-yet unannounced block height in the future, new inscriptions which would previously have been cursed will be blessed, and will receive positive inscription numbers as part of the main sequence of inscription numbers. Hopefully, this kind of community wide coordination is not a common occurrence, but it may happen again from time to time, if it is advantageous to recognize new kinds of inscriptions which previously would have been invalid.

• The commitment to the stability of inscription numbers does not preclude the fixing of bona fide bugs. If there is a legitimate bug, and the only reasonable way to fix it proves disruptive to inscription numbers, we will fix it.

Inscriptions are both a technical artifact and an artistic technology. Technical considerations must contend on equal footing with aesthetic considerations.

Inscription numbers are here to stay.

However, I do not consider myself an ideological Bitcoin maximalist, with the primary reason being that ideology often does not survive contact with reality.

This is the unenviable position that ideological Bitcoin maximalism, and the insipid culture accompanying it, finds itself in at the present moment: an uncomfortable contact with a reality with which it does not comport.

Ideological Bitcoin maximalism has a lot of good things going for it. It is because of those things that this blog post was written. This post contains advice for ideological Bitcoin maximalists, advice which will hopefully help them stop scoring own goals and committing unforced errors. In other words, how they can stop being losers.

Let me start by saying that this post is not written to defend ordinals and inscriptions. They do not need defending. The cat is out the bag, and nobody can put it back in.

Now, for the advice.

My first piece of advice is that whining about inscriptions makes you, and Bitcoin, look weak. Simultaneously believing that Bitcoin is unstoppable internet money and thinking that a bunch of retards publishing JPEGs on-chain is any kind of problem is a contradiction. We both know the truth that, push come to shove, the former is true and the latter is false. Bitcoin is unstoppable internet money, and the JPEGs are a non-issue. But, by espousing both beliefs, you weaken any argument you might make that Bitcoin can resist the state.

For all the whining on Twitter, nobody has been able to make so much as a dent in ordinals and inscriptions. So, given that, and given that we have important work to do in destroying fiat, maybe you should stop whining about something you can't change, and adjust to the new, and possibly uncomfortable reality that NFTs have come to Bitcoin? This will no doubt not be the last time that people start doing unpleasant things on Bitcoin, so it would be a good exercise to start accepting it now. You can then refocus your efforts on more important things, like spreading Satoshi's good word and helping as many people as possible learn how to use Bitcoin.

Also, strategically, all press is good press, and complaining about inscriptions just makes more people learn about them, and makes the inscribers extra keen to nakadashi JPEGs into the blockchain, just to make you look like idiots. If normies like doing something, then you're not going to make any friends, or make any headway on anything, by scolding them for doing it.

If you still insist on complaining about inscriptions, at least take a moment to learn about them, so you can ditch your worst and least compelling arguments. These include:

• Anyone can right-click save the JPEGs. Literally every degenerate buying inscriptions knows this. Literally every single one. Nobody is buying inscriptions based on the delusion that they are buying access. Accepting this and updating your worldview will bring it closer to reality, and less likely to be destroyed by it.

• Inscriptions aren't real, they're just a collective hallucination. I've been saying basically exactly this since day one, that ordinals and inscriptions are an opt-in lens with which to view Bitcoin. Behaving as if this is some kind of damning revelation makes you look like a moron. Additionally, it shows that you misunderstand one of the most fundamental things about humans, civilization, and culture: Everything important is just social conventions. Bitcoin is, in fact, just a social convention. Or, put another way, it's not the software or data that matter, it's the social conventions around it. Inscriptions are no different.

• You can just store the data off-chain. People value on-chain data. It makes inscriptions scarce, and dramatically improves reliability and user-safety. Every other NFT ecosystem uses off-chain data, and uninformed users delegate trust to whoever happens to be pinning the files on IPFS, and they might stop at any time. On-chain data is a vast improvement in trustlessness, which, I am told, is highly valued by ideological maxis.

• Inscriptions are illegitimate. There's an obvious difference between things that are illegitimate, like state violence, and things that you just think are stupid. Arguing that something is illegitimate because you don't like it or don't see the purpose of it makes you look like a retard.

• Inscriptions are a state attack. Somehow, you see NFTs and shitcoins on other chains, understand that they exist because of enthusiasm, demand, grift, and degeneracy, don't think that these things are a state attack on Ethereum, and somehow turn around and think that they're a state attack on Bitcoin?

Attempting to censor inscriptions is exactly identical to attempting censoring other kinds of transactions. Any machinery you build or public support you muster will immediately lend support to censorship on Bitcoin in general. Fortunately, processing transactions that someone views as illegitimate is exactly the thing Bitcoin was built for, so you will ultimately fail, but we would all be better of if you didn't try to convince people that censoring Bitcoin transactions was something they should bother trying. You've already managed to confuse Ocean Mining into thinking that it's possible and a good idea, and although they'll eventually bend the knee even further than they already have, it would be nice if we just got another mining pool, instead of having it needlessly gimped right out of the gate.

So, what should you do about inscriptions?

Just ignore them. More valuable use-cases will price out the majority of inscriptions. There will always be some high-value inscriptions, but they don't compete seriously with hard money and uncensorable transactions. Bitcoin's destiny is high fees. Embrace it.

We have much bigger fish to fry, and if you're interested in doing more than just pearl clutching and engagement farming, we can all get to frying them.

However, these assets still suffer from a lack of decentralized trading venues.

Assets on other chains are commonly traded using automatic market makers, or AMMs. AMMs pool assets and use simple formulae to dynamically price swaps between assets.

They are efficient from an on-chain transaction cost perspective, but they are still on-chain, requiring additional transaction overhead compared to that required for the swaps themselves.

They also produce inefficient prices, since AMM prices can only change as a result of on-chain activities: deposits, withdrawals, and executions, which are costly.

Bitcoin lacks the Turing-complete smart contracts necessary for implementing AMMs. Fortunately, there is an alternative which is more efficient, both from a transaction cost and pricing perspective.

The idea behind light pools is simple. Users who wish to offer swaps between Bitcoin-native assets, like rare sats, inscriptions, or runes, run nodes which quote prices for swaps.

These quotes are signed messages, gossiped between other light pool nodes. Quotes must include BIP-322 signatures of the UTXOs that contains the asset offered in trade. Requiring signed quotes eliminates spam, since quotes can be rate-limited on a per-UTXO basis. Additionally, when UTXOs are spent, corresponding offers can be dropped.

When a market taker wants to accept the quote of a market maker, they use the information in the quote to construct a PSBT which includes their signatures, and broadcast it to the network. These messages can also be gossiped by the network, and rate-limited based on the taker's UTXOs. The maker receives this message, possibly asyncronously, countersigns, and broadcasts it to the Bitcoin network to be mined.

These PSBTs and transactions are not vulnerable to mempool sniping, since signatures commit to all inputs and outputs.

Light pools require more implementation work than an AMM. Someone will need to write an implementation of the gossip network, quote message format, and PSBT construction and finalization. However, these are all done with a little bit of elbow grease, and don't require tilting at the quixotic open-research-problem windmills that plague much of cryptocurrency. (And Bitcoin, to be fair.)

The user experience of light pools should be quite good. Users can run their own node to accumulate an order book, or rely on a third party. Prices can update in real time, between blocks, without any on-chain activity.

Little work has been done on decentralized asset trading on Bitcoin, simply because the market cap of Bitcoin-native assets was small. With rare sats, inscriptions, and soon runes, the table is set and the time is ripe, and light pools seem like a promising avenue to explore.

Ordinals is a few things. Ordinals proper is made up of ordinal numbers, the numbering and tracking of satoshis, designed ultimately as vehicles for NFTs; inscriptions, the NFTs which ride on the backs of ordinals; runes, the degenerate black sheep of the protocol family; and ord, the open-source computer program which implements ordinals, inscriptions, and runes.

Along the way there have been a two ordinals-related entities that I've been involved with. The first was Ordinals Corporation, a short-lived startup founded when ordinals, the protocol, started taking off, which was dissolved nearly as soon as it was created, and did exactly nothing. The second is the non-profit Open Ordinals Institute, a going concern, which accepts donations, pays for the ordinals.com servers, and funds open-source contributors to ord.

I first learned about NFTs back when they were taking off on Ethereum in 2017. I wasn't initially very interested in them, but I did talk a bit with my friend Parker Day, a photographer, about turning some of her portraits into NFTs, although we didn't wind up pursuing it.

NFTs came on my radar again in mid-2021, when Fidenza by Tyler Hobbs was released. I had made generative art in the past, but there was never a market for it, and suddenly beautiful generative NFTs were selling for real money. I experimented with NFTs on Ethereum, but was turned off, to put it mildly, by the reality of NFTs on Ethereum. The tooling was terrible, the ERC-721 standard meant that each NFT had different semantics, and the content was all stored off-chain.

This, combined with my existing dislike of Ethereum, made me decide to try to figure out how to make NFTs on Bitcoin which didn't suffer from the issues inherent to existing NFTs on Ethereum and earlier standards for NFTs on Bitcoin.

I started noodling. From the start, I wanted the protocol to be UTXO-based, and to use Bitcoin's native cryptography and script for transactions. Anything else would have been much more complex, much less featureful, and would not have fit in nicely with the rest of the ecosystem. However, UTXOs are ephemeral. The pop into existence when created by a transaction, and pop just as suddenly out of existence when spent.

I had the idea for "atoms", one of which would be created in every block, and which would subsequently hop from coin to coin with each transaction. I made the first to commit to the repo, then called bitcoin-atoms, on 2021-12-12.

My friend Liam Scalzulli, who I had worked on other open-source projects with, started working on the project with me, making his first commit to the repo on 2022-1-28.

I had some very helpful conversations about atoms with mconst, Eric Sirion, Rijndael, and Jeremy Rubin, and eventually came up with ordinals, the numbering and tracking of individual satoshis, as an alternative to atoms. On 2022-1-5 I renamed the bitcoin-atoms repo to ord. On 2022-2-22 I posted a draft of the ordinals BIP to the bitcoin-dev mailing list, and on 2022-3-9 I bought ordinals.com, ordinals.net, and ordinals.org. The .net and .org were free, but the .com was for sale for $2000. Easily the best money I've ever spent!

I came up with an off-chain NFT scheme, where the creator of an NFT would sign a message assigning a piece of content to an ordinal without needing to make a Bitcoin transaction, and gave a workshop at BTC++ in Austin 2022-6-8, where participants got paper wallets loaded with sats and issued their own NFTs.

Around this time Raph started working on the project, and made his first commit on 2022-9-6. You can see the major contributors to the project over time, including Liam and Raph, on GitHub.

The off-chain NFT scheme had a lot of issues. Users would need to send NFTs out-of-band, and it would be impossible to run a public server with all NFTs, since there were no rate or content size limits.

I started trying to figure out where I could stuff content into the Bitcoin blockchain. Bitcoin script, in the form of scriptpubkeys or scriptsigs, were the obvious choice. Most script types were limited in size, ether by consensus or standardness, but taproot scripts had no limit, so they became the vehicle. Funnily enough, these script-based NFTs were originally called "runes", but we switched to "inscriptions" and it stuck.

We did a lot of work on the wallet, and on 2022-12-14 I made the first mainnet inscription, followed quickly thereafter by the second mainnet inscription by Rijndael.

The ord wallet inscribe command was initially disabled on mainnet, and on 2023-1-9 we enabled it, and on 2023-1-20 I tweeted that inscriptions were ready for mainnet.

That same day I opened the now infamous PR requesting a BIP number for ordinals, which languishes open to this day.

There was a trickle of inscriptions, then more, and then a rush, filling every block. It was clear: Ordinals had gone nuclear.

With the protocol a wild success, I started having vague ideas about a startup, unrelated to the protocol, because that seemed like that's was what one does in those circumstances. On 2023-2-3 I incorporated Ordinals Corporation, co-founded by myself, Ordinally, Erin, and Rocktoshi. Ordinals Corporation never had a clear line of business, issued any shares, held any assets, or undertook any business activities. It was dissolved less than three months later on 2023-4-30. May it rest in peace.

The next few months were an insane rush of attention and chaos, and ultimately extremely personally stressful. I took a hiatus from everything, although in reality I hadn't been particularly productive even before making it official. Things eventually started to get back to normal, and in August I started working on ord again.

On 2023-8-1, the Open Ordinals Institute was incorporated, a much more unambitious entity whose sole purpose was to accept donations, pay for the ordinals.com servers, and fund open source contributors to ord, which it continues to do to this day.

x := "\n"

foo:
  printf '{{x}}' > bar

Let's find out where that 0x0A byte comes from.

just is written in Rust, and the just parser has a function called cook_string, which transforms a just string token containing escape sequences into a UTF-8 string.

The code is here here.

With some irrelevant details elided, it looks like this:

for c in text.chars() {
  match state {
    …
    State::Backslash => {
      match c {
        'n' => cooked.push('\n'),
        …
      }
      …
    }
    …
  }
}

So just asks rustc to insert the result of evaluating the Rust '\n' character escape. Let's take a look at how rustc handles '\n'.

rustc's escape code handling is in the lexer, in a function called scan_escape, which is here.

With some details removed:

let res: char = match chars.next().ok_or(EscapeError::LoneSlash)? {
    …
    'n' => '\n',
    …
};

rustc is written in Rust and compiles itself, so somehow rustc is delegating to rustc to figure out what '\n' means, which seems odd, to say the least, and we still haven't seen the naked 0x0A byte we're looking for.

rustc wasn't always written in Rust though. Before it was self-hosted, early versions were written in OCaml.

GitHub has old versions of the OCaml version of rustc, which handled character escapes in the lexer here.

and char_escape = parse
  …
  | 'n' { end_char (Char.code '\n') lexbuf }
  …

So rustc asks the OCaml compiler to insert the result of evaluating the OCaml character escape '\n'. Which is totally reasonable, but still not a 0x0A in sight.

Going one step deeper, let's look the OCaml lexer here.

And finally, some clarity:

let char_for_backslash = function
    'n' -> '\010'
  …

When the OCaml compiler sees \n, it inserts the result of evaluating the OCaml character escape \010, which is a decimal character escape, and since 0x0A is 10, we finally have our byte value.

So when have a \n character escape in your justfile, the just binary contains a 0x0A byte in some form, which it will then write to your final string.

That 0x0A byte was put there by rustc, which contained it's own 0x0A byte somewhere in the binary, which was stuffed there by its rustc progenitor.

rustc is currently at version 1.81.0, so this has happened at least 81 times since rustc 1.0 was first released, and probably many more times than that before 1.0, with rustcs furtively smuggling 0x0A bytes from one to the other, all the way back to when it was written in OCaml, when finally the first 0x0A byte was stuffed into a rustc binary by the OCaml compiler, which evaluated it from a decimal character escape '\010'.

This post was inspired by another post about exactly the same thing. I couldn't find it when I looked for it, so I wrote this. All credit to the original author for noticing how interesting this rabbit hole is.

I have a mental model for why this might be the case.

The load on a muscle under tension is spread out over the cross section of the muscle, perpendicular to the direction of the load.

When a muscle is shortened, it bunches, spreading out the load over a larger cross section.

When a muscle is lengthened, it stretches, concentrating the load over a smaller cross section.

Imagine two Muscles in your body, one shortened, one lengthened, lifting a 100 pound Load from the floor.

The shortened muscle is on the left, and the lengthened muscle is on the right:

MM    M
MM    M
|     M
L     M
      |
      L

In this very unrealistic diagram, the cross section of the shortened muscle is two M "units" and the cross section of the lengthened muscle is one M "unit", so the shortened units of muscle each experience 50 pounds of load, and the lengthened units of muscle each experience the full 100 pound load.

If mechanical tension on muscles is the most significant cause of hypertrophy, then we want to concentrate it by stretching the muscle, as opposed to spreading it out by bunching the muscle.

I have no idea if this model is actually true, but it makes sense to me!

I tried to respond to all topical comments and criticisms, which was made slightly challenging by the fact that the thread was nearly completely unmoderated.

I received some basic feedback on formatting and style from the BIP editors, but no feedback relating to why or why not the pull request might be merged. Occasionally, the scope of the BIPs repository was mentioned, but never what that scope actually was, and how it might relate to the pull request.

The pull request was finally closed by Bryan Bishop, seemingly unilaterally, with the comment "I am rejecting this proposal to merge Ordinals into the BIP repository and will not be assigning a number." It was also locked, which is, as far as I can tell, totally unprecedented for an extensively discussed and revised pull request.

I started writing this blog post without actually having a clear idea of why, exactly, I was writing it, but I think, in the end, the best reason I can give is that the whole process was incredibly frustrating, and venting about frustrating things feels good.

In the spirit of improving the BIPs process, I wanted to provide what is hopefully actionable feedback for the BIP editors from the perspective of a BIP author:

• BIP editors should provide specific feedback as to why a pull request isn't being merged. Even if it is eventually closed, it is far preferable to know why and to be able to understand and respond. It is deeply unsatisfying as a contributor to have to ask in private for feedback, or hope that an editor will explain their thinking in a Twitter thread.

• BIP editors should moderate PR threads. Hundreds of duplicative and off-topic comments make following discussion challenging. Additionally, without moderation it is impossible for a BIP author to know which pieces of third-party feedback are substantive and should be addressed, and which can be ignored.

• Create a process for resolving disputes. I suggest that if the BIP editors cannot come to an agreement to merge or close a PR after three months, it should be closed and the author should be invited to re-submit it after a year.

• The BIP editors should, whenever questions of the scope of the BIPs repo come up with respect to a particular BIP, explain what they believe the scope of the repo is, and how it relates to the BIP in question. Whenever there is enough clarity and agreement, the scope of the repo should be codified in writing in a process BIP. If BIPs which were previously accepted are later decided to be out-of-scope going forward, this should be clearly documented, since accepted BIPs are otherwise a reasonable way for an outsider to determine the scope of the BIPs process.

• The BIP editors should not act unilaterally in closing a controversial PR. Unilateral action by a BIP editor does not clarify the scope of the repository, is clearly undesirable in principle, and makes such action more likely in the future.

If BIP editors adhered to the above, it's still entirely possible that the ordinals BIP would have been closed. However, I would have gotten feedback on why, had the opportunity to respond, and the process would have served to help clarify the scope of the BIPs repository.