Mime-Version: 1.0
References: <CANLPe+OZ33vcZheOyo2RdrvWzQvj3RzZc6sHTafGwbqEG2G4pA@mail.gmail.com>
 <0642a5e59464779569f9d0aab452ee27@willtech.com.au>
 <96471a093e3c3d9862c3d47ebe731df6@willtech.com.au>
 <CANLPe+Nc6ehatESSuS5jFXU-wammBSOe5GRjn45n8BAr90TPOg@mail.gmail.com>
 <a54b2632d9b20f9330cf129706f5c886@willtech.com.au>
 <CAGpPWDYGheCFZS67agC=wVvrrC2VNunQs-LqCa=V34bAQYBosg@mail.gmail.com>
In-Reply-To: <CAGpPWDYGheCFZS67agC=wVvrrC2VNunQs-LqCa=V34bAQYBosg@mail.gmail.com>
From: Casey Rodarmor <casey@rodarmor.com>
Date: Thu, 24 Feb 2022 13:03:54 -0800
Message-ID: <CANLPe+OA1ddkfRYLsA25GZkw9=+AMni99Nsz31-PUHdEB--R+g@mail.gmail.com>
To: Billy Tetrud <billy.tetrud@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000008ecd8105d8c9eb5e"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Draft-BIP: Ordinal Numbers
Precedence: list

--0000000000008ecd8105d8c9eb5e
Content-Type: text/plain; charset="UTF-8"

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

--0000000000008ecd8105d8c9eb5e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<html><head></head><body><div><div><div>&gt; One thought I had was: what ha=
ppens 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 tha=
t to ordinals by having fraction ordinals like 1.1 or 4.85. Could be an int=
eresting thought to add to the proposal.<br></div><div><br></div><div>I thi=
nk it&#39;s probably premature to make a concrete proposal, since any propo=
sal made now might be inapplicable to the actual form that a precision incr=
ease takes.<br></div><div><br></div><div>&gt; What you mean by &quot;the sa=
me transaction id&quot; 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&#39;s ordinals to outputs in the transaction the UTX=
O is spent in. Is that what you mean by this sentence? If so, I&#39;d sugge=
st rewording.<br></div><div><br></div><div>There are two pairs of old trans=
actions with duplicate IDs, from blocks 91812 and 91842, and 91722 91880. (=
It&#39;s no longer possible to create transactions with duplicate IDs, sinc=
e the BIP 34 soft fork that required the height be included in coinbase tra=
nsaction inputs, making them have guaranteed unique IDs.)<br></div><div><br=
></div><div>This section of the spec defines what ordinal ranges such dupli=
cate transactions contain. It tries to match the behavior of Bitcoin Core, =
which considers the second transaction with a given ID to render unspendabl=
e current UTXOs created by a transaction with the same ID.<br></div><div><b=
r></div><div>I&#39;ll add some detail to this part of the BIP, and talk abo=
ut why this rule is needed.</div></div><div></div></div></body></html>

--0000000000008ecd8105d8c9eb5e--