path: root/37/c8c7ff54cd9ec1a8abdeff0d048b33bfca1479

Return-Path: <fresheneesz@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 95054C007A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 25 Feb 2022 05:00:16 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 7D81940270
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 25 Feb 2022 05:00:16 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001,
 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=gmail.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 vUAzOY-uDGE8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 25 Feb 2022 05:00:15 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com
 [IPv6:2a00:1450:4864:20::52d])
 by smtp2.osuosl.org (Postfix) with ESMTPS id DB6F9400F4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 25 Feb 2022 05:00:14 +0000 (UTC)
Received: by mail-ed1-x52d.google.com with SMTP id x5so5774255edd.11
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 24 Feb 2022 21:00:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=Xxk7QauXPGUjGSFPjBboUL7AvogXqCqsTUW9ccKwftI=;
 b=XTWjAKtkc/8CNOzpcqIEkNOSbtqfyZeP2Y/my8EijwNcuyA+HV9FMvo6Ov0e/+luhP
 00gdVLARkh9EOUMDRqoI2HYbtFndfZ7p2UzydLuZ/KMrsEOTJvOi0JaDhH7uRyDdStSd
 TR9WWQcpfSOsN2C+k02yu7649Yvm9fJ/4INXlcIDrXctmaAbB1pqDBy7HhIbbYBemvUN
 dwQlHa43v8nC+XliEymva0FpN0Rrz+hSfNOSeAZeTDIO+x6Wi+3ieC0mF3icZVOwpxCu
 FSa4Ba0Jcd2TF6tfgxC+F5qdvg+GDOKzhVc1E7R4P2FO/YNqsZbAIrNzUC0MdeMjoTvN
 jjuQ==
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=Xxk7QauXPGUjGSFPjBboUL7AvogXqCqsTUW9ccKwftI=;
 b=kX9hbGgPS4tSkTK4I+roGnOjOvyg2hnNiXGugrnGrFndRrJs9fdOaWXA7qYYLGy8Tt
 WgN8PanfmnbDFzdcnTX6Nwcs6CUJsMTccL+733q+tmKMI2xsWtpkaYBWFaXkJmDWsHKs
 VDLaOmVu4+9y/Bi3G2nDyGMFQsWt1Zn3PZk6Q+7cYgx/dLxG/EO1HBFKcRy7QRMlW82h
 arieqIplFTVF2gwA6/SWgOeVV0QW+vqgp+oZv1bNEOOKR//RnLVYvskHcwXD00DGBcYC
 0R8BxyabPwI8rv2pGJuwOptn0av7u+zB5gNOdvfkts7T1BuKLDpvGWj+ZUli0hGVvCyv
 XyKQ==
X-Gm-Message-State: AOAM53321Lrl1hsxczQchiTlBZd9V3wtB8HLU1mvpkjTf238y0vzNaPa
 ubhI4AVLyQZWBAd/fSXMPd1//2myUa4bqy/VcN5u7puh
X-Google-Smtp-Source: ABdhPJxS83R/xkFtDwKrGrdmY+e+RVbzcHFyJLrBiUQquIG4XMeFg8pZSLJRnlyTgehtjnhP7ZBASuadnvSrW19vxfo=
X-Received: by 2002:aa7:c793:0:b0:408:4a69:90b4 with SMTP id
 n19-20020aa7c793000000b004084a6990b4mr5277552eds.58.1645765212882; Thu, 24
 Feb 2022 21:00:12 -0800 (PST)
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>
 <CANLPe+OA1ddkfRYLsA25GZkw9=+AMni99Nsz31-PUHdEB--R+g@mail.gmail.com>
In-Reply-To: <CANLPe+OA1ddkfRYLsA25GZkw9=+AMni99Nsz31-PUHdEB--R+g@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Thu, 24 Feb 2022 22:59:56 -0600
Message-ID: <CAGpPWDbquYT4gm_eKTrtsHsCNRf2fU0gvHOz--jRVhVgUzFHYQ@mail.gmail.com>
To: Casey Rodarmor <casey@rodarmor.com>
Content-Type: multipart/alternative; boundary="000000000000e5c93e05d8d09218"
X-Mailman-Approved-At: Fri, 25 Feb 2022 08:47:56 +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: Fri, 25 Feb 2022 05:00:16 -0000

--000000000000e5c93e05d8d09218
Content-Type: text/plain; charset="UTF-8"

>  what if/when we introduce some Monero-like system and hide coin amounts?

I really don't see a world where bitcoin goes that route. Hiding coin
amounts would make it impossible to audit the blockchain and verify that
there hasn't been inflation and the emission schedule is on schedule. It
would inherently remove unconditional soundness from bitcoin and replace it
with computational soundness. Even if bitcoin did adopt it, it would keep
backwards compatibility with old style addresses which could continue to
use ordinals.

On Thu, Feb 24, 2022 at 3:03 PM Casey Rodarmor <casey@rodarmor.com> wrote:

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

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

<div dir=3D"ltr">&gt;=C2=A0

what if/when we introduce some Monero-like system and hide coin amounts?=C2=
=A0<div><br></div><div>I really don&#39;t see a world where bitcoin goes th=
at route. Hiding coin amounts would make it impossible to audit the blockch=
ain and verify that there hasn&#39;t been inflation and the emission schedu=
le is on schedule. It would inherently remove unconditional soundness from =
bitcoin and replace it with computational soundness. Even if bitcoin did ad=
opt it, it would keep backwards compatibility with old style addresses whic=
h could continue to use ordinals.=C2=A0</div></div><br><div class=3D"gmail_=
quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Feb 24, 2022 at 3:03 P=
M Casey Rodarmor &lt;<a href=3D"mailto:casey@rodarmor.com" target=3D"_blank=
">casey@rodarmor.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex"><div><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></div>
</blockquote></div>

--000000000000e5c93e05d8d09218--