If you do just foo, the following justfile
will write a single byte 0x0A to a file named bar:
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.
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.
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 own0x0A
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.
There have been words on Twitter, so I thought it would be useful to write down
how ordinals came to be.
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.
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.
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.
Bitcoin has inscriptions and will soon have runes, protocols for bitcoin-native
digital artifacts and tokens.
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.
If you ask me my views, they will be nearly indistinguishable from those of,
for lack of a better term, ideological Bitcoin maximalists. I loathe the state,
have no particular respect for authority, and believe that Bitcoin is the path
away from the debauched debasement of our lives and civilization that fiat
currency has wrought.
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.
When a dev tells you that something is weird and hard and they have to change
behavior that users rely on, the correct response is somewhere between "Cool
story, bro." and "Wah, wah, wah, are the bits being mean to you?". Developers
serve users, not the other way around.
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.
I'm not sure creating a new fungible token protocol for Bitcoin is a good idea.
Fungible tokens are 99.9% scams and memes. However, they don't appear to be
going away any time soon, similar to the way in which casinos don't appear to
be going away any time soon. Creating a good fungible token protocol for
Bitcoin might bring significant transaction fee revenue, developer mindshare,
and users to Bitcoin. Additionally, if this protocol had a small on-chain
footprint and encouraged responsible UTXO management, it might serve as harm
reduction compared to existing protocols. At least one of which, BRC-20, is
already quite popular, and has the undesirable consequence of UTXO
proliferation.
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.
Inscription numbers are numbers assigned to inscriptions in the order in which
they are created, starting at zero for the genesis
inscription.
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.
ord version 0.4.0 has been
released. Inscriptions are finally ready for Bitcoin mainnet.
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.
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.
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.
I've been thinking about competitive governance, trying to dissect what,
exactly, its desirable properties might be, and how to achive them. It strikes
me that there are two separate desriable properties that governments have under
competition, which, for lack of a better word, I'll call incentives and
constraints.
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.
Raph and I have been working hard on
ord, the
ordinal block explorer and wallet, and
have just finished the initial version of the ord wallet send ORDINAL ADDRESS
command, which makes a transaction sending ORDINAL to ADDRESS.
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:
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:
There's a lot going on here! Let's break down the inputs and outputs:
Inputs:
Contains 139761296637063 at offset 7,500.
Needed to pay for all outputs
Outputs:
Change containing 7,500 sats to make 139761296637063 the first ordinal
of the recipient's output.
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.
Change containing 16,006 sats, to reduce the recipient's output to 10,000
sats.
I've been working on a numbering scheme for satoshis that allows tracking and transferring individual sats. These numbers are called ordinals, and constitute a numeric namespace for Bitcoin. Satoshis are numbered in the order in which they're mined, and transferred from transaction inputs to transaction outputs in first-in-first-out order. More details are available in the BIP.
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.
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.
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 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.
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.
A large reputable member threshold multisig operating as functionaries for a Bitcoin-pegged deterministic replicated state machine sidechain with as-compatible-as-possible-with-mainchain semantics is probably more reliable and secure that most alternative chains.
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.
There are a lot of things that I wish would happen, but don't have the time to
actually do myself. I complain about such things all the time to basically
anyone who will listen. Such efforts are all well and good, and sometimes
actually pay off, but additionally, I'd like to materially support people who
might actually do these things.
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.
Expanding on this tweet: You could launch a super fancy social networking site with all the features that everyone expects, but built entirely on existing open standards:
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.
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.
A letter to Maalika Manoharan, Product Manager, Gmail. Sent via LinkedIn Inmail, which is palpably ironic.
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.
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.
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.
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
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.
Got some minor cuts and scrapes while doing water sports (not the fetish kind
you perv), was curious about the optimal way to dress them, which lead to
reading at least a dozen papers and articles on wound care and dressing
selection.
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. 😂
Federated blind mints have attractive privacy, scaling, and security properties
that are highly complementary to those of Bitcoin and the Lightning Network.
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.
Bitcoin will greatly reduce the power of the state, which rests entirely on its capacity for violence. This capacity is maintained by paying and equipping people to commit violence on its behalf, and it acquires the resources to do so by printing money, collecting taxes, and issuing debt.
I don't do as much deep thinking as I used to. When I was a kid, I remember imagining what it would be like if the universe was symmetrical, mirrored right down the middle. I imagined a white room, floating in space, right on the plane that separates the two halves of the universe. If you parked your spaceship outside and opened the door, you would see yourself in front of you, opening the same door. It would be the you from the other side of the universe.
Thought of a hilarious idea for a manga and eventually anime when it inevitably gets super popular.
It takes place in Japan, but only because that seems like the only appropriate setting for an anime.
The story is about a twenty-something bachelor. He wants a dog, so he adopts a beautiful female malamute from a shelter.
However! When he gets home, he realizes that the dog has the most beautiful human-looking vagina he has ever seen. Like, all-time-top-voted-post-on-r/godpussy tier. Of course, since it's an anime, you only ever see it pixelated.
Then, basically the entire show revolves around him trying to resist the temptation to fuck his dog, and situations that make it hard to resist temptation. His catchphrase is "Inu ni makemasen!" / "I won't lose to the dog!"
Like, for example, in one episode he leaves out a jar of strawberry jam, and the dog gets into it, and then when the dog is done eating the jam, it pulls its snout out of the jar, and there's strawberry jam on its mouth in the exact shape of sexy lipstick. This of course sends him into a fit of desire, and he has to like, I dunno, take a cold bath, or watch sumo wrestling or something to resist.
In the final episode, he's taking the dog for a walk in a dog park, and he sees another dog running around, and notices that it has a huge, beautiful human penis. (Pixelated, natch.) He then look over and sees its owner, who's a beautiful woman his age. They lock eyes and instantly fall in love.
I can't decide if it's a happy ending, where he gets this great girl and the two dogs with beautiful junk get each other. Or if it's a darker ending, where he has sex with the woman for the first time and her pussy is absolutely ruined, and he realizes that she hasn't resisted temptation and has been getting railed on the reg by her dog and its huge human cock. Or afterwards he asks her how it was, and she says "It was okay…" in a super wistful voice, and then looks over at her dog, while the color drains from his face as he realizes the truth.
I'm not sure whether it should be called Wanko Manko, which means "Dog Pussy" in Japanese but rhymes, or Venus in Fur, as a play on Venus in Furs by Leopold von Sacher-Masoch.
For some reason I'm fascinated by the debris in this vacuum product photo. If
you look closely, you can see that it's several specific kinds of debris.
Uncooked grains of rice, sunflower seeds, maybe coffee beans, and clumps of
hair. I'm imagining some intern getting just the right debris ready for the
photo.
The complex priority system that the state is using in many countries to roll out the covid vaccine is reminiscent of this plane boarding algorithm:
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.
I was trying to find an image reference for what different clipper guard lengths look like. Every single reference I found had different models with different hairstyles, or used illustrations instead of photographs.
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.
As an unrepentant degenerate and fan of microeconomics, it should come as no
surprise that I find the online sexual economy endlessly fascinating.
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,
unpleasant1, 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.
In an October 1935 article in Esquire. Hemingway offers this advice to a young writer:
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.
The PS5 was released about a week ago, and, predictably, it is impossible to
get one. All retailers, online and IRL, are sold out. Of course, consoles are
available on Ebay at ruinous prices, so at least the scalpers are doing well.
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.
One of the things that I personally struggled with when learning Rust was how
to organize large programs with multiple modules.
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.
I feel like BGP would be a great place to experiment with PKI systems, possibly
with some additional global consensus mechanism.
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.
GIMME THAT BIG BISCUIT SHREDDED WHEAT BOM BOM BOM THAT BIG BISCUIT SHREDDED WHEAT
I just published a simple crate that performs lexical path cleaning: lexiclean.
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.
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.
USG was always this this incompetent, this inefficient, this craven, this
self-serving. It just needed external stresses requiring a competent response
to reveal the extent of its functional bankruptcy.
All democracy gives you is this: People convince themselves that the best way to get what they want is by voting, lobbying, and running for office, and not with AK-47s in the streets.
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.
Intermodal is a new command-line BitTorrent metainfo1 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:
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.
Twitter is funding a team to decentralize social media. I think they should start with messaging.
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.
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.
Computering is a party. The stack is best visualized as a bunch of Jenga
blocks on the floor, and the heap as a bunch of balloons floating
around bumping into each other on the ceiling. The fact that the stack
usually grows downwards in memory is a travesty.
I saw a janitor sweeping dirt from the fronds of his enormous push broom with a normal-sized broom.
I've often been asked for suggestions for an appropriate first project in Rust, and I think that writing a version of a unix utility is a great choice, for a bunch of reasons!
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
I woke up last night after only a few hours of sleep, sweaty and disoriented.
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.
The Lightning Network has the potential to greatly improve cryptocurrency exchanges.
Lighting Network payment channels could be established between users and exchanges to speed the transfer of funds.
This would be a huge boon, moving many on-chain deposit and withdrawal transactions off-chain, but is possibly only the beginning.
Since Lightning Network payments can span different blockchains, an exchange could use a cross-chain Lightning node to expose its internal order book to external entities.
IOTA is a cryptocurrency targeting the internet of things. It purports to be scalable, decentralized, and feeless. Unfortunately it is none of those things.
In this article I attempt to summarize the numerous technical, social, and ethical problems surrounding the IOTA project, The IOTA Foundation, and the IOTA developers.
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.
Investing in cryptocurrencies is not the same as buying simple equity in a company.
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.
Programs first crawled from the murky oceans as simple lists of instructions that executed in sequence. From these humble beginnings they have since evolved an astonishing number of ways of delinearizing.
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
This is pretty nuts. I was poking around in the storage area of my house, and I found a huge cardboard box filled with letters and audio cassettes and dust. Everything was Danish, German, and English, but mostly Danish. The name Max Rasmussen was everywhere, so I think it was all his stuff. I had to get a tape player at best buy to play the tapes, but surprisingly, they all played fine. One of them was an interview, in English, between Max and a man named Hans. I listened to it a few times, and I don't even know what to say. It's transcribed below.
"Well," he began, moving closer to her, "declarative programming is when you tell the computer what you want, and then the computer figures out how to get it. Pretty sweet, huh?"
"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?"
