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
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
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
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
Rune balances are held by UTXOs. A UTXO can contain any amount of any number of
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.
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
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
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.
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.
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
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
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
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 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.
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
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 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
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
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.
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
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.
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.
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
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
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.
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
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
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
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
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
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
This transaction sends ordinal 139761296637063 to
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.
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:
│ │ │ ╰─ 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:
│ │ │ ╰─ Not first sat in block
│ │ ╰─── Not first block in difficutly adjustment period
│ ╰───── Not first block in halving epoch
╰─────── Second cycle
This ordinal is uncommon:
│ │ │ ╰─ First sat in block
│ │ ╰─── Not first block in difficutly adjustment period
│ ╰───── Not first block in halving epoch
╰─────── Second cycle
This ordinal is rare:
│ │ │ ╰─ First sat in block
│ │ ╰─── First block in difficulty adjustment period
│ ╰───── Not the first block in halving epoch
╰─────── Second cycle
This ordinal is epic:
│ │ │ ╰─ First sat in block
│ │ ╰─── Not first block in difficulty adjustment period
│ ╰───── First block in halving epoch
╰─────── Second cycle
This ordinal is legendary:
│ │ │ ╰─ First sat in block
│ │ ╰─── First block in difficulty adjustment period
│ ╰───── First block in halving epoch
╰─────── Second cycle
And this ordinal is mythic:
│ │ │ ╰─ 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:
│ │ ╰─ Not first block in difficutly adjustment period
│ ╰─── Not first block in halving epoch
╰───── Second cycle
common: 2.1 quadrillion
common: 1.9 quadrillion
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.
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.
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…?
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.
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
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
Terrible incentives: Couldn't resist big blockers in same way bitcoin did
Insane costs to running a full node
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
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
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.
Fair launch privacy coin with interesting tech
Absolutely dead in the water because no VC marketing budget
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-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 firstname.lastname@example.org. 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.
Add the features that make people use other messaging protocols to email.
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.
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.
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.
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.
Same as voice calling.
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.
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.
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.
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.
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.
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.
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.
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
Better rich text support
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.
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.
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
I find this representation unsatisfying:
It places outpoints hierarchically beneath transactions, even
though after a transaction is confirmed, the outpoint is relatively
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, 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.
 blockstream.info, blockchain.com, mempool.space, blockcypher.com, and
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
$ 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
$ mount http-server /http
Mounted `http-server` instance at `/http`.
$ tree /http
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
It is a complex and interesting topic! Here is my probably-inaccurate summary:
The four stages of wound healing are hemostasis, inflammation, proliferation,
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
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
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
Compared to a naïve hosted Lightning Network wallet, a service operated as a
federated Chaumian mint offers excellent privacy, usability, security, and
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
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
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
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
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
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
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
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
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
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
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:
Getting a discount because they have a reputation for paying their bills on
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
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.
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.
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.
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?"