[bitcoin-dev] Draft-BIP: Ordinal Numbers

[Casey Rodarmor via bitcoin-dev]

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

---


  BIP: ?
  Layer: Applications
  Title: Ordinal Numbers
  Author: Casey Rodarmor 
  Comments-Summary: No comments yet.
  Comments-URI: https://github.com/casey/ord/discussions/126
  Status: Draft
  Type: Informational
  Created: 2022-02-02
  License: PD


== 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 

[bitcoin-dev] BIP-119 CTV Meeting #4 Notes

[Jeremy Rubin via bitcoin-dev]

Today's meeting was a bit of a different format than usual, the prime focus
was on getting CTV Signet up and running and testing out some contracts.

In terms of discussion, there was some talk about what the goals of a
signet should be, but no conclusions were really reached. It is very good a
signet exists, but it's unclear how much people will be interested in
Signet with CTV v.s. if it had a lot of other forks to play with. Further,
other fork ideas are a lot greener w.r.t. infrastructure available.

In the tutorial section, we walked through the guide posted on the list.
There were a myriad of difficulties with local environments and brittle
bash scripts provided for the tutorial, as well a confusion around using
old versions of sapio-cli (spoiler: it's alpha software, need to always be
on the latest).

Despite difficulties, multiple participants finished the tutorial during
the session, some of their transactions can be seen below:

https://explorer.ctvsignet.com/tx/62292138c2f55713c3c161bd7ab36c7212362b648cf3f054315853a081f5808e
https://explorer.ctvsignet.com/tx/5ff08dcc8eb17979a22be471db1d9f0eb8dc49b4dd015fb08bac34be1ed03a10

In future weeks the tutorials will continue & more contracts can be tried
out. This tutorial was also focused on using the CLI, which is harder,
whereas future tutorials will use the GUI as well but won't be as prime for
understanding all the "moving parts".

Best,

Jeremy

--
@JeremyRubin 
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP-119 CTV Meeting #4 Draft Agenda for Tuesday February 22nd at 12:00 PT

[Jeremy Rubin via bitcoin-dev]

Hi Devs,

As promised, a Sapio Tutorial. In this tutorial we'll walk through how to
use the Sapio CLI to generate contracts and play with them on the network.
We'll use a congestion control tree because it's very simple! We will walk
through this step-by-step during the meeting today.

-1. Install JQ (json manipulating tool) if you don't have it / other things
needed to run a bitcoin node.
0. Set up a node as described above.  You'll likely want settings like this
in your bitcoin.conf too:
[signet]
# generate this yourself

rpcauth=generateme:fromtherpcauth.pyfile
txindex=1
signetchallenge=512102946e8ba8eca597194e7ed90377d9bbebc5d17a9609ab3e35e706612ee882759351ae

rpcport=18332
rpcworkqueue=1000
fallbackfee=0.0002

Get coins https://faucet.ctvsignet.com/ / DM me

1. Follow the install instructions on
https://learn.sapio-lang.org/ch01-01-installation.html You can skip the the
sapio-studio part / pod part and just do the Local Quickstart up until
"Instantiate a contract from the plugin". You'll also want to run *cargo
build --release* from the root directory to build the sapio-cli.


2. Open up the site https://rjsf-team.github.io/react-jsonschema-form/
3. Run *sapio-cli contract api --file
plugin-example/target/wasm32-unknown-unknown/debug/sapio_wasm_plugin_example.wasm*
4. Copy the resulting JSON into the RJSF site
5. Fill out the form as you wish. You should see a JSON like
{
"context": {
"amount": 3,
"network": "Signet",
"effects": {
"effects": {}
}
},
"arguments": {
"TreePay": {
"fee_sats_per_tx": 1000,
"participants": [
{
"address": "tb1pwqchwp3zur2ewuqsvg0mcl34pmcyxzqn9x8vn0p5a4hzckmujqpqp2dlma",
"amount": 1
},
{
"address": "tb1pwqchwp3zur2ewuqsvg0mcl34pmcyxzqn9x8vn0p5a4hzckmujqpqp2dlma",
"amount": 1
}
],
"radix": 2
}
}
}

You may have to delete some extra fields (that site is a little buggy).

Optionally, just modify the JSON above directly.

6. Copy the JSON and paste it into a file ARGS.json
7. Find your sapio-cli config file (mine is at
~/.config/sapio-cli/config.json). Modify it to look like (enter your
rpcauth credentials):
{
 "main": null,
 "testnet": null,
 "signet": {
   "active": true,
   "api_node": {
 "url": "http://0.0.0.0:18332;,
 "auth": {
   "UserPass": [
 "YOUR RPC NAME",
 "YOUR PASSWORD HERE"
   ]
 }
   },
   "emulator_nodes": {
 "enabled": false,
 "emulators": [],
 "threshold": 1
   },
   "plugin_map": {}
 },
 "regtest": null
}

8. Create a contract template:
*cat ARGS.json| ./target/release/sapio-cli contract create  --file
plugin-example/target/wasm32-unknown-unknown/debug/sapio_wasm_plugin_example.wasm
 | jq > UNBOUND.json*
9. Get a proposed funding & binding of the template to that utxo:

*cat UNBOUND.json| ./target/release/sapio-cli contract bind | jq >
BOUND.json*
10. Finalize the funding tx:

*cat BOUND.json | jq ".program[\"funding\"].txs[0].linked_psbt.psbt" |
xargs echo | xargs -I% ./bitcoin-cli -signet utxoupdatepsbt % |  xargs -I%
./bitcoin-cli -signet walletprocesspsbt % | jq ".psbt" | xargs -I%
./bitcoin-cli -signet finalizepsbt % | jq ".hex"*

11. Review the hex transaction/make sure you want this contract... and then
send to network:



*./bitcoin-cli -signet sendrawtransaction
0201015e69106b2eb00d668d945101ed3c0102cf35aba738ee6520fc2603bd60a872ea00feff02e8c5eb0b2200203d00d88fd664cbfaf8a1296d3f717625595d2980976bbf4feeb10ab090180ccdcb3faefd02002251208f7e5e50ce7f65debe036a90641a7e4d719d65d621426fd6589e5ec1c5969e200140a348a8711cb389bdb3cc0b1050961e588bb42cb5eb429dd0a415b7b9c712748fa4d5dfe2bb9c4dc48b31a7e3d1a66d9104bbb5936698f8ef8a92ac27a6506635*


12. Send the other transactions:

*cat BOUND.json| jq .program | jq ".[].txs[0].linked_psbt.psbt" | xargs -I%
./target/release/sapio-cli psbt finalize --psbt %  | xargs -I%
./bitcoin-cli -signet sendrawtransaction %*



Now what?

- Maybe load up the Sapio Studio and try it through the GUI?
- Modify the congestion control tree code and recompile it?
- How big of a tree can you make (I did about 6000 last night)?
- Try out other contracts?
--
@JeremyRubin 


On Mon, Feb 21, 2022 at 7:36 PM Jeremy Rubin 
wrote:

> Hi All,
>
> Apologies for the late posting of the agenda. The 4th CTV meeting will be
> held tomorrow at 12:00 PT in ##ctv-bip-review in Libera.chat.
>
> Tomorrow the conversation will be slightly more tutorial focused. If you
> have time in advance of the meeting, it might be good to do some of this in
> advance.
>
> 1) Discussion: What is the goal of Signet? (20 minutes)
> - Do we have a "decision function" of observations from a test network?
> - What applications should be prototyped/fleshed out?
> - What level of fleshed out matters?
> - Should we add other experiments in the mix on this net, like
> APO/Sponsors?
> - Should we get e.g. lightning working on this signet?
> 2) Connecting to CTV Signet Tutorial (10 mins)
>
> We'll make sure everyone who wants to be on it is on 

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[Billy Tetrud via bitcoin-dev]

> look at how lightning ate up fees to keep bitcoin stable, we can't
"scale" too quickly either

I strongly disagree with this. We should be scaling Bitcoin as fast as we
can. There is no reason to delay scaling for the purposes of keeping fees
high. If we need fees to be higher, we can lower the block size or increase
the default minimum relay fee rate.

Also, the idea that use of the LN is there primary cause of recent low fees
is highly dubious.

> the various new uses for on-chain transactions mentioned as a use-case
arguably harms all existing users by competing for scarce blockchain space

Reminds me of that old saying, "nobody goes there anymore, it's too
crowded". ; )


On Mon, Feb 21, 2022, 03:54 Prayank via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Goog morning ZmnSCPxj,
>
> Context: https://bitcointalk.org/index.php?topic=48.msg329#msg329
>
> Maybe I should have rephrased it and quote Satoshi. I agree I should not
> speak for others and it was not my intention in the email.
>
> > If Satoshi refuses to participate in Bitcoin development today, who
> cares what his opinion is?
>
> I care about the opinions especially if consensus rules are not changed
> and remain same as far as subsidy is concerned.
>
> > Satoshi is dead, long live Bitcoin.
>
> I object to such assumptions about the founder of Bitcoin. Satoshi is more
> than a pseudonym and will stay alive forever.
>
> --
> Prayank
>
> A3B1 E430 2298 178F
>
>
>
> Feb 21, 2022, 14:32 by zmnsc...@protonmail.com:
>
> Good morning Prayank,
>
> (offlist)
>
> Satoshi
>
>
> I object to the invocation of Satoshi here, and in general.
> If Satoshi wants to participate in Bitcoin development today, he can speak
> for himself.
> If Satoshi refuses to participate in Bitcoin development today, who cares
> what his opinion is?
> Satoshi is dead, long live Bitcoin.
>
>
> Aside from that, I am otherwise thinking about the various arguments being
> presented.
>
>
> Regards,
> ZmnSCPxj
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev