1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
|
Return-Path: <casey@rodarmor.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id A5EADC0011
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 24 Feb 2022 21:03:58 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 8143940AA7
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 24 Feb 2022 21:03:58 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=rodarmor.com
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id S_aZSJQWEmgc
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 24 Feb 2022 21:03:57 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com
[IPv6:2a00:1450:4864:20::52b])
by smtp2.osuosl.org (Postfix) with ESMTPS id 7065C40A3B
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 24 Feb 2022 21:03:57 +0000 (UTC)
Received: by mail-ed1-x52b.google.com with SMTP id cm8so4663077edb.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 24 Feb 2022 13:03:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rodarmor.com; s=google;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=MkEOWfje1h7F8iQTDoVnldc8q+qiY+q7Y9O+/NRPPLM=;
b=Iyq9FrgHz3C9igcJCbIodZnJhajEJAX+Ty+NMZ9Pl3TtxPban5adlcdAd0Dc3lNXeo
1RlVjqJmCRlTUjkv2MqpAlH8yzg2eZGgWcjYgiq3sywMfrhj5hRLgIFzEa7ALFId+4As
GnsStx2DL18+PrNl0k0bZGEdK8HI2EVTmY9VFrlWKsQBoLsMscoZvMRkZGlwhUK0X2eF
nlf62FcsQIqsauq/Hxp3fH2Z/bcbnoCD93wjHoNyywC/Es/yta1z6O3heQ3OSLBG9cBT
gbEObSLG06PCmHFSM0wMnvil+cuHiVMf5WBfoGFbCXtDdE6RrQI9SKjZq/6ViWCIxQcM
i2LA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=MkEOWfje1h7F8iQTDoVnldc8q+qiY+q7Y9O+/NRPPLM=;
b=BKD0XtMNI4DNPEnL345DgcFjZu79OTZ7HW47hS9BcCXWtelP3nEAaFK5schHFsRD2w
XOVtSiJBsU0U/nGwaFj2pfDF51jCqJ3bvPdQbY0xMuUBx7jdI/9i8M1DwjEH3HhbDZ9N
eQW8A+ptNh42cERegIsUhgckeVGUOv5DEysuwIHTLHqGEYEw/TF2R4tcQdvWfpxoHkWa
e5JFt8wqTzoOhbQBBhHsBUkDR8p84+49+zpBHJc32RMMpaYxk4oHsIlBIGdYSpIPHY1f
Cts2UgpN8lEP9VsBfl4pMy1195d+0Jfn16mmu70L8n6DoBeANL1R3gFPzlS1L4u+kr6O
gfjA==
X-Gm-Message-State: AOAM532lLsKRN1P/hPEZ4tMrksjei6AAsRKgG0uWMM3XyzALE3WjIZHq
29NJVElupyJDjCaDjaBDMASJMfCHbNZpdehyMbMogg==
X-Google-Smtp-Source: ABdhPJyPoKWh2YB6xEQOv6VBf8Lt/gWZr1n3WfD2SxSpUZWcTXhxqEVZ2COR6kxFh4C1eI2InEIrrSTH5pHxz+KkTDk=
X-Received: by 2002:a05:6402:2922:b0:40f:7241:74d4 with SMTP id
ee34-20020a056402292200b0040f724174d4mr4185728edb.43.1645736635577; Thu, 24
Feb 2022 13:03:55 -0800 (PST)
Received: from 649336022844 named unknown by gmailapi.google.com with
HTTPREST; Thu, 24 Feb 2022 13:03:54 -0800
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>
X-Superhuman-ID: l01h366y.a8ecbf78-301a-4a2b-89bb-77456d504f66
In-Reply-To: <CAGpPWDYGheCFZS67agC=wVvrrC2VNunQs-LqCa=V34bAQYBosg@mail.gmail.com>
From: Casey Rodarmor <casey@rodarmor.com>
X-Mailer: Superhuman Web (2022-02-23T23:06:01Z)
X-Superhuman-Draft-ID: draft008043cb911c53b2
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"
X-Mailman-Approved-At: Thu, 24 Feb 2022 21:11:40 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Draft-BIP: Ordinal Numbers
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Feb 2022 21:03:58 -0000
--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>> 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'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>> What you mean by "the sa=
me 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 UTX=
O is spent in. Is that what you mean by this sentence? If so, I'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'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'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--
|
