Casey Rodarmor [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2013-12-04 to 2023-02-03
💬 Posted a total of 10 messages
📚 Participated in the following categories: bitcoin-dev, Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 13:02:43

- reply

📅 Original date posted:2021-06-29
📝 Original message:
Good afternoon ZmnSCPxj,
Thank you for your thoughtful reply! I agree with many of your points.
One thing I wanted to say regarding the forces that act on banks:
> It is helpful to remember that banks have, historically, been federations: they are typically implemented as corporations, which are basically a bunch of people pooling their money and skill together to start a business.
> Thus, I argue that banks already *are* federations that take custody of your money and manage it for you.
>
> To my mind, any system that is a federation that takes custody of user money *will* face the same social, political, and economic forces that the legacy banking system faced in the past.
I actually think that banks operating on top of bitcoin may be subject
to different forces. A major factor in the misbehavior of legacy banks
has been lack of competition due to artificial barriers to entry due
to regulation. I think in the absence of regulation, with competitors
being able to enter the market at little cost, and without needing a
license, we would see much less bad behavior from banks. I don't think
that, aside from regulation, there is anything inherent to the
business of banking that makes banks behave badly. If federated
chaumian banks that interface exclusively with the Bitcoin and
Lightning networks are able to evade regulators, the market for such
banking services will hopefully see healthy competition between
participants. This would be enhanced by the fact that such banks would
be able to serve a global audience, and not be closely tied to a
country, national currency, legacy settlement network, or region.
> In addition, ti seems to me that the node management problem can be solved in software, by something similar in purpose to CLBOSS.
I think projects like CLBOSS are great, but I share elsirion's
pessimism that LN node UX not be a fully soluble problem, no matter
how good management software gets. Users will be choosing between
services like Wallet of Satoshi, which are completely seamless, and it
might not be possible for management software to fully abstract over
things like high fees, uptime requirements, and unexpected fund
unavailability due to channel closure.
Best regards,
Casey

2023-06-09 13:02:41

- reply

📅 Original date posted:2021-06-27
📝 Original message:
Dear Lightning Devs,
Chaumian mints, or blind mints, are a potentially interesting way to make
hosted lightning wallets more private and secure, and I recently wrote a blog
post on the topic that I wanted to share with the list:
https://rodarmor.com/blog/lightning-mints/
It is also reproduced below for convenience.
Self-hosted Lightning wallets present distinct usability challenges not present
in on-chain wallets, such as channel and liquidity management, which may make
hosted wallets a popular option. Given that, I think the problem of making
these wallets more private and secure deserves attention, and blind mints may
provide nice solutions to these problems.
Another site of interest is fedimint.org, which has some additional information
on blind mints in the context of Bitcoin and Lightning.
Best regards,
Casey Rodarmor
---
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[0], 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[1], 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[2] 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 an 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, federations 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 the same local wallet interface, encouraging competition in
the market.
For more discussion of Chaumian mints and their applicability to Bitcoin, see
fedimint.org[3]. 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 of 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.
[0] https://en.wikipedia.org/wiki/Blind_signature
[1] https://en.wikipedia.org/wiki/Ecash
[2] https://opaque.link/post/digitalmoneydbc/
[3] https://fedimint.org

2023-06-09 12:40:18

- reply

2023-06-09 12:40:17

- reply

2023-06-07 23:19:12

- reply

📅 Original date posted:2023-02-03
🗒️ Summary of this message: Discussion on moving inscriptions off-chain for NFTs. Concerns include user protection, salience, and scarcity, as well as technical considerations.
📝 Original message:Good evening list,
Apologies for posting! I've tried to keep discussion of ordinals and
inscriptions off-list, because I consider it to be of little relevance to
general Bitcoin development. Also, apologies for the HTML mail, but I don't
have my email client configured correctly. And finally, also apologies if
this breaks the thread, I was subscribed but not receiving mail, so I can't
respond to the original message.
AJ Towns writes:
I think, however, that you can move inscriptions entirely off-chain. I
wrote a little on this idea on twitter already [1], but after a bit more
thought, I think pushing things even further off-chain would be plausible.
Actually, my initial sketch for Ordinal NFTs worked in a similar fashion,
with off-chain messages pointing to an ordinal, which could be tracked by
following the chain of custody of that particular sat. I gave a workshop
last year where I handed out paper wallets to participants with a private
key that controlled some sats, which could both be assigned NFTs and used
to sign messages as a form of provenance:
https://www.youtube.com/watch?v=j5V33kV3iqo
Ultimately, I decided against this design, and Peter provided an excellent
explanation of some of the trade-offs of such a design in his mail, but to
at least partially recap and explain my own thinking:
NFT collectors have a strong revealed preference for on-chain content. The
content of high-value NFTs is often stored partially or completely on
chain, even if details of the NFT protocol involved actually prevents that
content from being what you see when you view the NFT on a website or
marketplace.
User protection when off-chain content is involved is fraught. Users are
not equipped, due to lack of technical knowledge, easily available,
user-friendly tools, and education, to protect themselves when they buy a
collectable whose content is stored off-chain. When a user buys an NFT with
off-chain content, they now have the primary economic incentive to preserve
that content, so that their NFT retains value and can be enjoyed or sold.
Many existing NFT marketplaces that sell off-chain content do not explain
this to users, or give users tools that the average, non-technical person
can understand or use, which enables them to protect themselves. Even if
they did give users these tools, there are tricky considerations involved.
IPFS functions much like BitTorrent, so even if users were provided with an
IPFS application that could persist their off-chain NFT content
automatically, they might reveal their IP address, which would then be
linked to ownership of their NFT, which would have privacy and safety
considerations.
Another issue is salience and scarcity, as has been mentioned. Off-chain
content is unbounded, and thus less scarce. Usually, we design for
efficiency, volume, and scale. For NFT designs, which are intended to be
collectable, this is in some ways counterproductive.
The above issues also make the specification and implementation of NFTs
with off-chain content much more difficult. Ordinals is a project largely
written by a single developer, me, with the assistance of two part time
interns. It is very intentionally the simplest thing that could possibly
work, much like Bitcoin itself. Sometimes I refer to it as "cave-man
technology". If I was designing an off-chain NFT protocol, I would likely
have had to raise money and recruit a large team, which I have not done, or
be at risk of never launching anything at all.
I would absolutely love for the ordinals protocol, that is, the numbering
and transfer of individual satoshis, be used as the basis for alternative,
off-chain NFT and colored coin schemes, with proper consideration given to
the issues above.
However, I would request that, to avoid confusion, these alternative
schemes never be called inscriptions.
I'm a dev, not a cop, but fine distinctions are hard to properly explain
and understand. Inscriptions, that is, the NFT protocol which embeds
content in transaction witnesses, has a particular set of trade-offs and
guarantees. I want users to know that if they buy or value something they
or others call an "inscription", they can rely on those trade-offs and
guarantees. Another NFT protocol named "inscriptions" would make this very
difficult.
Additionally, I think the term "inscription" which has a connotation of
permanence, and of an indelible association with a particular satoshi, is
inappropriate for an off-chain NFT protocol.
Sorry to belabor this point! Inscriptions have already proven very popular
for a nascent protocol, beyond my expectations, and the terminology and
naming is still new, so it's a critical phase in terms of understanding and
education.
If others are interested in developing ordinals further, a great first step
would be to provide review and feedback on the BIP PR:
https://github.com/bitcoin/bips/pull/1408
I have never written a BIP, so style and content feedback is especially
welcome.
Inscriptions themselves have no BIP, although at least one alternative
implementation of the inscription parser has been written:
https://ordinals.com/content/6f46a2a830a90e406245b188631cd15ffea31b8be146255ec39d4d46bbe15663i0
I hope to write a BIP for inscriptions as the implementation and protocol
mature.
In general, although I do love the ordinals protocol, it has many
downsides, which I hope people will consider when considering it for
alternative colored coin schemes. These include the fact that divisibility
is limited, both by the use of real sats and the dust limit, that cardinal
satoshis must be used to pay fees, the general insanity of ordinal-aware
transaction construction[0], and difficult in lifting ordinals onto an L2.
I consider ordinals ideal for art projects like inscriptions and
ordinal-theory-powered satoshi numismatics, where aesthetic and technical
considerations are nearly equally important.
Please feel free to contact me privately by email, or on the ordinals
project GitHub[1] if you'd like to respond! My intention with this message
is not to spark debate, since I consider it mostly off-topic for this list.
Best regards,
Casey Rodarmor
[0]
https://github.com/casey/ord/blob/master/src/subcommand/wallet/transaction_builder.rs
[1] https://github.com/casey/ord
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230202/f969f9f8/attachment-0001.html>

2023-06-07 23:04:51

- reply

📅 Original date posted:2022-02-24
📝 Original message:> When we talk about future improvements, there could be even bigger
problem with ordinal numbers: what if/when we introduce some Monero-like
system and hide coin amounts? (for example by using zero satoshi, because
we have to use something that will be backward-compatible). Zero is quite
interesting amount, because it means "skip amount checking for old
clients". That can be used in many ways to introduce many protocols (and
also to add fractional satoshis on-chain, because 0.4 satoshis could be
represented as zero), so if that amounts will be simply ignored, then I
wonder how it would be possible to connect some future protocol based on
that with ordinal numbers.
Ordinal numbers are inherently public, so it seems reasonable that they
don't work with transactions that are private or have obfuscated values.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220224/fad28767/attachment.html>

2023-06-07 23:04:49

- reply

📅 Original date posted:2022-02-24
📝 Original message:> One thought I had was: what happens if/when it comes to pass that we
increase payment precision by going sub-satoshi on chain? It seems like it
would be fairly simple to extend that to ordinals by having fraction
ordinals like 1.1 or 4.85. Could be an interesting thought to add to the
proposal.
I think it's probably premature to make a concrete proposal, since any
proposal made now might be inapplicable to the actual form that a precision
increase takes.
> What you mean by "the same transaction id" here is unclear. I was
interpreting the proposal to mean that UTXOs are all assigned a set of
ordinals, and when that UTXO is spent, it transfers it's ordinals to
outputs in the transaction the UTXO is spent in. Is that what you mean by
this sentence? If so, I'd suggest rewording.
There are two pairs of old transactions with duplicate IDs, from blocks
91812 and 91842, and 91722 91880. (It's no longer possible to create
transactions with duplicate IDs, since the BIP 34 soft fork that required
the height be included in coinbase transaction inputs, making them have
guaranteed unique IDs.)
This section of the spec defines what ordinal ranges such duplicate
transactions contain. It tries to match the behavior of Bitcoin Core, which
considers the second transaction with a given ID to render unspendable
current UTXOs created by a transaction with the same ID.
I'll add some detail to this part of the BIP, and talk about why this rule
is needed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220224/efa3472c/attachment.html>

2023-06-07 23:04:48

- reply

📅 Original date posted:2022-02-23
📝 Original message:The least reasonable thing I could expect is some claimed former holder of
some ordianls turning up to challenge me that it was their stolen Bitcoin
was some of what I received.
I think it's unlikely that this would come to pass. A previous owner of an
ordinal wouldn't have any particular reason to expect that they should own
it after they transfer it. Similar to how noting a dollar bill's serial
number doesn't give you a claim to it after you spend it. From the BIP:
Since any ordinal can be sent to any address at any time, ordinals that
are transferred, even those with some public history, should be considered
to be fungible with other satoshis with no such history.
<https://github.com/casey/ord/blob/master/bip.mediawiki#backward-compatibility>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220223/cb083aa3/attachment.html>

2023-06-07 23:04:47

- reply

📅 Original date posted:2022-02-24
📝 Original message:What about zero satoshis?
A zero satoshi input or output carries no ordinals, so an ordinal index can
ignore them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220224/fabae806/attachment.html>

2023-06-07 23:04:47

- reply

📅 Original date posted:2022-02-23
📝 Original message:Well done, your bip looks well presented for discussion.
Thank you!
You say to number each satoshi created? For a 50 BTC block reward that is
> 5,000,000,000 ordinal numbers, and when some BTC is transferred to another
> UTXO how do you determine which ordinal numbers, say if I create a
> transaction to pay-to another UTXO.
>
It uses a first-in-first out algorithm, so the first ordinal number of the
first input becomes the first ordinal number of the first output.
The system sounds expensive eventually to cope with approximately
> 2,100,000,000,000,000 ordinals.
>
A full index is expensive, but it doesn't have to track 2.1 individual
entries, it only has to track contiguous ordinal ranges, which scales with
the number of outputs–all outputs, not just unspent outputs–since an output
might split an ordinal range.
If I understand ordinals 0 to 5,000,000,000 as assigned to the first
> Bitcoin created from mining block-reward. Say if I send some Bitcoin to
> another UTXO then first-in-first-out algorithm splits those up to assign 1
> to 100,000,000 to the 1 BTC that I sent, and 100,000,001 to 5,000,000,000
> are assigned to the change plus if any fee?-DA.
>
That's correct, assuming that the 1 BTC output is first, and the 4 BTC
output is second. Although it's actually 0 to 99,999,999 that go to the
first output, and 100,000,000 to 499,999,999 that are assigned to the
second output, less any fees.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220223/4ff3cf7a/attachment-0001.html>

2023-06-07 23:04:45

- reply

📅 Original date posted:2022-02-22
📝 Original message:Good afternoon list,
I've been working on a scheme of stable public identifiers that can be
used for a variety of purposes.
The scheme is extremely simple and does not require protocol-level
changes, but since different applications and wallets might use such
identifiers, standardizing and publishing the scheme as a BIP seems
warranted. The draft-BIP is hosted on GitHub, as well as reproduced
below:
https://github.com/casey/ord/blob/master/bip.mediawiki
Briefly, newly mined satoshis are sequentially numbered in the order in
which they are mined. These numbers are called "ordinal numbers" or
"ordinals". When satoshis are spent in a transaction, the input satoshi
ordinal numbers are assigned to output satoshis using a simple
first-in-first-out algorithm.
At any time, the output that contains an ordinal can be determined, and
the public key associated with that output can be used to sign
challenges or perform actions related to the ordinal that it contains.
Such identifiers could be used for a variety of purposes, such as user
accounts, PKI roots, or to issue stablecoins or NFTs. The scheme
composes nicely with other Bitcoin applications, such as the Lightning
Network or state chains.
I'm also working on an command-line tool that builds an index of ordinal
ranges to answer queries about the whereabouts of a particular ordinal,
or the ordinals contained in a particular output:
https://github.com/casey/ord/
The index is well tested but needs to be optimized before it can index
the main chain in a reasonable amount of time and space. It's written in
Rust, by myself and Liam Scalzulli.
I'm eager for feedback, both here, and on GitHub:
https://github.com/casey/ord/discussions/126
Best regards,
Casey Rodarmor
PS After finishing the current draft, I discovered that a variation of
this scheme was independently proposed a little under a decade ago by
jl2012 on BitcoinTalk:
https://bitcointalk.org/index.php?topic=117224.0
---
<pre>
BIP: ?
Layer: Applications
Title: Ordinal Numbers
Author: Casey Rodarmor <casey at rodarmor.com>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/casey/ord/discussions/126
Status: Draft
Type: Informational
Created: 2022-02-02
License: PD
</pre>
== Introduction ==
=== Abstract ===
This document defines a scheme for numbering and tracking satoshis
across transactions. These numbers, "ordinal numbers" in the language of
this document, can be used as a useful primitive for a diverse range of
applications, including NFTs, reputation systems, and Lightning
Network-compatible stablecoins.
=== Copyright ===
This work is placed in the public domain.
=== Motivation ===
Bitcoin has no notion of a stable, public account or identity. Addresses
are single-use, and wallet accounts, while permanent, are not publicly
visible. Additionally, the use of addresses or public keys as
identifiers precludes private key rotation or transfer of ownership.
Many applications, some of which are detailed in this document, require
stable, public identifiers tracking identity or ownership. This proposal
is motivated by the desire to provide such a system of identifiers.
== Description ==
=== Design ===
Every satoshi is serially numbered, starting at 0, in the order in which
it is mined. These numbers are termed "ordinal numbers", or "ordinals",
as they are ordinal numbers in the mathematical sense. The word
"ordinal" is nicely unambiguous, as it is not used elsewhere in the
Bitcoin protocol[0].
The ordinal numbers of transaction inputs are transferred to outputs in
first-in-first-out order, according to the size and order of the
transactions inputs and outputs.
If a transaction is mined with the same transaction ID as outputs
currently in the UTXO set, following the behavior of Bitcoin Core, the
new transaction outputs displace the older UTXO set entries, destroying
the ordinals contained in any unspent outputs of the first transaction.
For the purposes of the assignment algorithm, the coinbase transaction
is considered to have an implicit input equal in size to the subsidy,
followed by an input for every fee-paying transaction in the block, in
the order that those transactions appear in the block. The implicit
subsidy input carries the block's newly created ordinals. The implicit
fee inputs carry the ordinals that were paid as fees in the block's
transactions.
Underpaying the subsidy does not change the ordinal numbers of satoshis
mined in subsequent blocks. Ordinals depend only on how many satoshis
could have been mined, not how many actually were.
At any given time, the output in which an ordinal resides can be
identified. The public key associated with this output can be used to
sign messages, such as ownership challenges, concerning to the ordinals
it contains. The specification of a standardized message format for such
purposes is deferred to a later BIP.
Ordinal aware software should not mix outputs containing meaningful
ordinals with outputs used for other purposes to avoid inadvertent loss
of valuable ordinals, or privacy leaks allowing links between funds. For
this reason, ordinal aware software using BIP-32 hierarchical
deterministic key generation should use a key derivation path specific
to ordinals.
The suggested key derivation path is `m/44'/7303780'/0'/0`. This
suggested derivation path has not been standardized and may change in
the future[1].
=== Specification ===
Ordinals are created and assigned with the following algorithm:
# subsidy of block at given height
def subsidy(height):
return 50 * 100_000_000 >> int(height / 210_000)
# first ordinal of subsidy of block at given height
def first_ordinal(height):
start = 0
for height in range(height):
start += subsidy(height)
return start
# assign ordinals in given block
def assign_ordinals(block):
first = first_ordinal(block.height)
last = first + subsidy(block.height)
coinbase_ordinals = list(range(first, last))
for transaction in block.transactions[1:]:
ordinals = []
for input in transaction.inputs:
ordinals.extend(input.ordinals)
for output in transaction.outputs:
output.ordinals = ordinals[:output.value]
del ordinals[:output.value]
coinbase_ordinals.extend(ordinals)
for output in block.transaction[0].outputs:
output.ordinals = coinbase_ordinals[:output.value]
del coinbase_ordinals[:output.value]
=== Terminology and Notation ===
Ordinals may be written as the ordinal number followed by the
Romance-language ordinal indicator °, for example 13°.
A satpoint may be used to indicate the location of an ordinal within an
output. A satpoint consists of an outpoint, i.e., a transaction ID and
output index, with the addition of the offset of the ordinal within that
output. For example, if the ordinal in question is at offset 6 in the
first output of a transaction can be written as:
680df1e4d43016571e504b0b142ee43c5c0b83398a97bdcfd94ea6f287322d22:0:6
A slot may be used to indicate the output of an ordinal without
referring to a transaction ID, by substituting the block height and
transaction index within the block for the transaction ID. It is written
as a dotted quad. For example, the ordinal at offset 100 in the output
at offset 1, in the coinbase transaction of block 83 can be written as:
83.0.1.100
Satoshis with ordinals that are not valuable or notable can be referred
to as cardinal, as their identity does not matter, only the amount. A
cardinal output is one whose ordinals are unimportant for the purpose at
hand, for example an output used only to provide padding to avoid
creating a transaction with an output below the dust limit.
== Discussion ==
=== Rationale ===
Ordinal numbers are designed to be orthogonal to other aspects of the
Bitcoin protocol, and can thus be used in conjunction with other
layer-one techniques and applications, even ones that were not designed
with ordinal numbers in mind.
Ordinal satoshis can be secured using current and future script types.
They can be held by single-signature wallets, multi-signature wallets,
time-locked, and height-locked in all the usual ways.
This orthogonality also allows them to be used with layer-two
applications. A stablecoin issuer can promise to allow redemption of
specific ranges of ordinals for $1 United States dollar each. Lightning
Network nodes can then be used to create a USD-denominated Lightning
Network, using existing software with very modest modifications.
By assigning ordinal numbers to all satoshis without need for an
explicit creation step, the anonymity set of ordinal number users is
maximized.
Since an ordinal number has an output that contains it, and an output
has a public key that controls it, the owner of an ordinal can respond
to challenges by signing messages using the public key associated with
the controlling UTXO. Additionally, an ordinal can change hands, or its
private key can be rotated without a change of ownership, by
transferring it to a new output.
Ordinals require no changes to blocks, transactions, or network
protocols, and can thus be immediately adopted, or ignored, without
impacting existing users.
Ordinals do not have an explicit on-chain footprint. However, a valid
objection is that adoption of ordinals will increase demand for outputs,
and thus increase the size of the UTXO set that full nodes must track.
See the objections section below.
The ordinal number scheme is extremely simple. The specification above
is 15 lines of code.
Ordinals are fairly assigned. They are not premined, and are assigned
proportionally to existing bitcoin holders.
Ordinals are as granular as possible, as bitcoin is not capable of
tracking ownership of sub-satoshi values.
=== Transfer and the Dust Limit ===
Any ordinal transfer can be accomplished in a single transaction, but
the resulting transaction may contain outputs below the dust limit, and
thus be non-standard and difficult to get included in a block. Consider
a scenario where Alice owns an output containing the range of ordinals
[0,10], the current dust limit is 5 satoshis, and Alice wishes to send
send ordinals 4° and 6° to Bob, but retain ordinal 5°. Alice could
construct a transaction with three outputs of size 5, 1, and 5,
containing ordinals [0,4], 5, and [6,10]. The second output is under the
dust limit, and so such a transaction would be non-standard.
This transfer, and indeed any transfer, can be accomplished by breaking
the transfer into multiple transactions, with each transaction
performing one or more splits and merging in padding outputs as needed.
To wit, Alice could perform the desired transfer in two transactions.
The first transaction would send ordinals [0,4] to Bob, and return as
change ordinals [5,10] to Alice. The second transaction would take as
inputs an output of at least 4 satoshis, the change input, and an
additional input of at least one satoshi; and create an output of size 5
to Bob's address, and the remainder as a change output. Both
transactions avoid creating any non-standard outputs, but still
accomplish the same desired transfer of ordinals.
=== Objections ===
- Privacy: Ordinal numbers are public and thus reduce user privacy.
The applications using ordinal numbers required them to be public, and
reduce the privacy of only those users that decide to use them.
Fungibility: Ordinal numbers reduce the fungibility of Bitcoin, as
ordinals received in a transaction may carry with them some public
history.
As anyone can send anyone else any ordinals, any reasonable person
will assume that a new owner of a particular ordinal cannot be
understood to be the old owner, or have any particular relationship
with the old owner.
- Congestion: Adoption of ordinal numbers will increase the demand for
transactions, and drive up fees.
Since Bitcoin requires the development of a robust fee market, this is
a strong positive of the proposal.
- UTXO set bloat: Adoption of ordinal numbers will increase the demand
for entries in the UTXO set, and thus increase the size of the UTXO
set, which all full nodes are required to track.
The dust limit, which makes outputs with small values difficult to
create, should encourage users to create non-dust outputs, and to
clean them up once they no longer have use for the ordinals that they
contain.
=== Security ===
The public key associated with an ordinal may change. This requires
actively following the blockchain to keep up with key changes, and
requires care compared to a system where public keys are static.
However, a system with static public keys suffers from an inability for
keys to be rotated or accounts to change hands.
Ordinal-aware software must avoid destroying ordinals by unintentionally
relinquishing them in a transaction, either to a non-controlled output
or by using them as fees.
=== Privacy considerations ===
Ordinals are opt-in, and should not impact the privacy of existing
users.
Ordinals are themselves public, however, this is required by the fact
that many of the applications that they are intended to enable require
public identifiers.
Ordinal aware software should never mix satoshis which might have some
publicly visible data associated with their ordinals with satoshis
intended for use in payments or savings, since this would associate that
publicly visible data with the users otherwise pseudonymous wallet
outputs.
=== Fungibility considerations ===
Since any ordinal can be sent to any address at any time, ordinals that
are transferred, even those with some public history, should be
considered to be fungible with other satoshis with no such history.
=== Backward compatibility ===
Ordinal numbers are fully backwards compatible and require no changes to
the bitcoin network.
=== Compatibility with Existing and Envisaged Applications ===
Ordinals are compatible with many current and planned applications.
==== Covenants ====
Since ordinals are borne by outputs, they can be encumbered by
covenants. BIP-119* specifies OP_CTV, which constraints outputs by
pre-committing to a spending transaction template. This template commits
to the number, value, and order of spending transaction outputs, which
allows constraining how specific ordinals are spent in future
transactions.
https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki
==== The Lightning Network ====
The Lightning Network cannot be used to selectively transfer individual
non-fungible ordinals, however it can be used to transfer arbitrary
amounts of fungible ordinals. Channels can be created with inputs whose
ordinals are all colored coins of the same type, for example colored
coins honored for redemption by a stablecoin issuer. These channels can
be used to conduct instant, low-fee USD-denominated off-chain payments,
and would require only modest changes to existing Lightning Network
nodes.
On channel close, fees would have to be paid by child-pays-for-parent,
to avoid paying stablecoin ordinals as fees.
==== Opendimes and Casascius coins ====
Physical transfer of ordinals can be facilitated by loading them onto
bitcoin bearer artifacts, such as Opendimes and Casascius coins.
==== RGB ====
RGB is a proposed scheme for using sequences of single-use seals to
define state transitions of off-chain, client-side-validated state
machines, for example smart contract platforms. Such chains of
single-use seals could be addressed by an ordinal contained in the
output that starts the chain of single-use seals.
https://rgb-org.github.io/
==== State Chains ====
The state chain proposal facilitates off-chain transfer of whole
outputs, which could contain ordinals with specific meanings, for
example stable coins or NFTs, allowing off-chain transfer of such
digital assets.
https://github.com/RubenSomsen/rubensomsen.github.io/blob/master/img/statechains.pdf
== Applications ==
=== Accounts and Authentication ===
Ordinal numbers can serve as the basis for account and authentication
schemes. The account issuer associates a newly created account with an
ordinal number in an output controlled by the account owner. The account
owner can then log in and take actions related to the account by signing
messages with the private key associated with the public key associated
with the output that contains the account ordinal. This key is only
known to the account owner, preventing unauthorized access.
By transferring the ordinal to a new output, the owner can rotate their
private key, or transfer the account to a new owner. Transferring an
ordinal requires creating a transaction signed by the current outputs
private key, preventing unauthorized transfer of accounts.
=== Colored Coins ===
Ordinals can be used as the basis for colored coin schemes. Unlike other
colored coin schemes which use additional outputs or require
manipulation of other parts of a transaction, ordinal-based colored coin
schemes can take advantage of the full range of available script types,
and other base-layer bitcoin features.
=== The DNS ===
The DNS root of trust could be defined not as a specific set of public
keys, but as a specific set of ordinals, which would allow for easy key
rotation and updates to the set.
=== Name Services ===
A scheme, not described in this document, could be used to assign names
to ordinals based on their number. These names could then be used as
account names. Many such names would be gibberish, but many would be
human readable. A scheme which enumerated strings of the ASCII
characters `a` through `z` would assign as names all length-10 and
shorter permutations of these characters.
=== NFTs ===
An artist can issue an NFT by signing a message containing a hash of a
work of art that they have created, along with the number of a
particular ordinal. The owner of that ordinal is the owner of that NFT,
allowing ownership to be proven, and the NFT to be bought and sold, and
otherwise change hands.
Such NFTs could be used for art, in-game assets, membership systems, or
any other kind of digital asset.
The signed message, which may contain arbitrary attributes and metadata,
is not sensitive and can be widely disseminated and replicated, to
ensure it is not lost.
Scarcity of such NFTs can be guaranteed by including in the NFT messages
the total number of NFTs to be issued. If this promise is violated, the
set of issued NFTs serves as an easy-to-verify fraud proof that the
issuance limit was exceeded.
A judicious NFT issuer will create a new private key to sign a new set
of NFTs and destroy it afterwards, to ensure the limited nature of the
NFT set. Multi-party-computation can be used to provide additional
assurances that overissuance cannot occur.
=== PKI ===
Instead of individual public keys serving as roots of trust for PKI
systems, individual ordinals could be used, allowing for key rotation.
=== Rare Sats ===
Ordinal numbers are unique, which might encourage collectors and
speculators to collect particular ordinals. Examples of potentially
collectable ordinals include:
* The first ordinal in a block, difficulty adjustment period, or halving
epoch.
* Ordinals consisting only of a single repeating digit.
* Ordinals with a large number of 8s, commonly held to be a lucky digit.
* Low ordinals mined early in bitcoin's history.
* Ordinals that were part of unusual blocks or transactions.
=== Reputation Systems ===
Ordinal numbers can serve as the basis for persistent reputation
systems, for example one of Lightning Network node operators. Unlike the
current system of associating reputation with public keys, an
ordinal-based reputation system allows for key rotation and reputation
transfer.
=== Stablecoins ===
A stablecoin issuer could promise to allow redemption of a range of
ordinals for one United States dollar each, minus the price of one
satoshi times the number of satoshis so redeemed. Such ordinals could be
transacted on-chain and on a slightly modified Lightning Network, as
well as other layers.
=== Voting and DAOs ===
A DAO or other organization may decide to allocate voting rights
proportionally to ownership of a predetermined range of ordinals. Voting
rights can thus be made transferable, and voting may be conducted by
signing messages using public keys associated with the outputs holding
vote-bearing ordinals.
== Reference implementation ==
This document, along with an implementation of an ordinal index that
tracks the position of ordinals in the main chain, is available on
GitHub: https://github.com/casey/ord
== References ==
A variation of this scheme was independently invented a decade ago by
jl2012 on BitcoinTalk: https://bitcointalk.org/index.php?topic=117224.0
For other colored coin proposals see the Bitcoin Wiki entry:
https://en.bitcoin.it/wiki/Colored_Coins
For aliases, an implementation of short on-chain identifiers, see BIP
15.
[0] With the exception of being word #1405 in the BIP-39 Portuguese word
list. Me perdoe!
[1] 7303780 is the decimal representation of the ASCII string 'ord'.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220222/04d7630c/attachment-0001.html>

2023-06-07 15:10:16

- reply

📅 Original date posted:2013-12-04
📝 Original message:On Tue, Dec 3, 2013 at 11:59 AM, Dâniel Fraga <fragabr at gmail.com> wrote:
>
> Today, when a user uses bitcoin-qt client, it can make a backup
> of wallet.dat easily through menu, but when he/she needs to restore
> this backup, he/she must copy the file to the correct folder and
> execute "bitcoin-qt -rescan".
>
I actually think this is part of a larger and somewhat subtle UX problem
with bitcoin-qt – and, to be totally fair, a whole bunch of other wallet
programs.
I think the issue is that bitcoin-qt should have a document-oriented
approach to wallets. It should make you select a location to store your
wallet, just like a word processor, when you create a new wallet. It could
open the most recent wallet when you run the program, or allow you to open
a wallet by double-clicking it directly in the OS.
I think this would solve this particular issue nicely, just double click
the wallet file. Also, the menu item can just be labeled "Open Wallet". It
might also prevent those kind of heartbreaking posts which read something
like, "I just wiped my hard drive and reinstalled bitcoin-qt, where are my
coins?" People don't have the expectation that if they get Word on a new PC
that their documents will somehow magically be available, I think in part
because Word forces you to deal with the documents and the save location
yourself.
I know that this would bring with it a host of other considerations: Can
multiple wallets be open at the same time? What happens if a wallet file is
moved while it's open? What happens when there are two versions of the same
wallet? Will users understand that they need to backup their wallets
periodically?
But, I think it would be a big enough usability win that it should be
considered. Also, if at the same time bitcoin-qt were to adopt BIP 32 style
deterministically derived private keys from a single seed, a bunch of the
issues above would also go away: There are never two versions of the same
wallet, since they're the same seed, and periodic backups are unnecessary.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131203/e19d2db8/attachment.html>