path: root/95/d463c0d40354c2582ed99159f48a189d959419

Return-Path: <fresheneesz@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 3AC1FC0011
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 24 Feb 2022 15:56:21 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 25BF560746
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 24 Feb 2022 15:56:21 +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: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id JpIyfp64HeV7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 24 Feb 2022 15:56:17 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [IPv6:2a00:1450:4864:20::630])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 55DAE607FE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 24 Feb 2022 15:56:17 +0000 (UTC)
Received: by mail-ej1-x630.google.com with SMTP id a8so5296216ejc.8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 24 Feb 2022 07:56:17 -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=ie0CGd96jBldoVfXFc9wseJTIhBFo4cR9e/DxNcIZ80=;
 b=G8i329ZTKkLLWSeVXiDR5vwDN0D4lxn+i8i2xd2JaBWFVsclM/62kr0C6N0xrw0Ftx
 X4HM4w+Y73fxHVBl6Dm88oTjLkYC8Zs7BwSz+++Gz6KWoy/BPgc7pe8z1hSygj8dwadL
 qHqvPCGzxfy2bX6EFADOJvol8oQSojruZYNN2+wHbtLVVmIfREUvr1HXw7VN9HdDVlOf
 rVEu3rvtZcoKMP4Sj4lPYC2ibx2jzdUHU0ruFDunHyhP30AXyyDxIvwImigG7CLgjByu
 sADRwqnRo9Td6V4sY9qEgrz6sxZlCLrytz88sptn7DSg9JfGLSBGd31mr2WD/hicyb83
 2HfQ==
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=ie0CGd96jBldoVfXFc9wseJTIhBFo4cR9e/DxNcIZ80=;
 b=ip6oAFrn+nulVxuqszEoVWipRQZ/1c9JlwuLn5kZ7Fp51jG0Kkt3FvEMWRVK6aFqbQ
 QRKw6dApYeyHj+tqFwdfGdEUBite+b7tAn0vt93GcnThMNbdl7luGThsnO9xM5PT1+Ig
 2F8B0dLuiUHn3bbDYSgnKBV1PAJtVR2MtJvhbJJG8sNXIirGiL5Y8KiU6VaLxs5S2OnE
 2/zS6yc8viOhM9Gv7kLB5B7hjbn3cPLAIBlEWjbh2WPuh28fy9yLEUHnfim/nCJGsntb
 OCNHMqGRAiZ+0uGf79RQaHrD5NlbseERWYt5rE9zUmNOEjhpeBXcBs2OMSrLnP/U2IS6
 GxYw==
X-Gm-Message-State: AOAM532V8BgOgKhTT+l8frisUMw4jQzufw4EU2KBIR92BMRIXivxMWTd
 s3YGv17/osvY35AQbEnZEwf5AUMUYXkw/GjZxqI=
X-Google-Smtp-Source: ABdhPJx6FJOGjm1Gf8qxzk3t/GL/1OEO8aLQjNLZOv5g4MDC9KfMc9TNYOwzs3ZYllpgi28uf2hE8c8qYIqipCVqX/w=
X-Received: by 2002:a17:906:130a:b0:6b7:5e48:350a with SMTP id
 w10-20020a170906130a00b006b75e48350amr2770869ejb.184.1645718175296; Thu, 24
 Feb 2022 07:56:15 -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>
In-Reply-To: <a54b2632d9b20f9330cf129706f5c886@willtech.com.au>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Thu, 24 Feb 2022 09:55:57 -0600
Message-ID: <CAGpPWDYGheCFZS67agC=wVvrrC2VNunQs-LqCa=V34bAQYBosg@mail.gmail.com>
To: damian@willtech.com.au, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000003d321205d8c59fea"
X-Mailman-Approved-At: Thu, 24 Feb 2022 16:05:24 +0000
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 15:56:21 -0000

--0000000000003d321205d8c59fea
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I think the proposal is interesting in that it could be an interesting way
to solve the dust problem. While most solutions to dust focus on reducing
how much are created and encouraging consolidating utxos to avoid them
becoming dust, this proposal could utilize dust for valuable purposes. Why
use valuable Bitcoin for NFTs or colored coins when dust can be split into
it's unit satoshis and used with no loss of utility?

Simple and elegant. I like it. If we're giving ACKs: ACK. Tho TBH I don't
see any reason NACK this - seems like this doesn't affect consensus,
doesn't affect relay, doesn't affect anything except people that run this
algorithm on the blockchain. If people want to do something like this,
people are going to do it whether or not the bitcoin community wants them
to. A standard would be good rather than everyone doing their own thing.

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.

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

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.

@Damian
> If I receive some Bitcoin I cannot know if some or any of those have been
at any point in the past been stolen, I assume the transaction is honest,
and in all likelihood it is likely that it is.

This isn't true at all. Some bitcoins are indeed known to be stolen and
even blacklisted by some companies/governments. I don't see how ordinals
changes anything related to this.

@vjudeu
> What about zero satoshis?

Those could be used for NFTs but not something like colored coins. It would
be a strict subset of ability, tho its an interesting idea in its own
right.




On Thu, Feb 24, 2022, 02:15 damian--- via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Not all people who have been stolen from believe that they have lost the
> right and title to what has been stolen and in many cases they have not.
> I do not excuse Bitcoin that it is impossible to have any individual
> Bitcoin identified but also I do not care, if I receive Bitcoin honestly
> I do not care what their history was. What if they were taken from a
> brothel? It is not a matter for an ordinal to determine if a satoshi is
> fungible. It is truth in effect that each satoshi is newly created to
> the new UTXO and the old satoshi destroyed. -DA.
>
>   On 2022-02-23 18:31, Casey Rodarmor wrote:
> >> =E2=80=8BThe least reasonable thing I could expect is some claimed for=
mer
> >> 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:
> >
> >> =E2=80=8BSince 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. [1]
> >
> >
> >
> > Links:
> > ------
> > [1]
> >
> https://github.com/casey/ord/blob/master/bip.mediawiki#backward-compatibi=
lity
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div dir=3D"auto"><div dir=3D"auto">I think the proposal i=
s interesting in that it could be an interesting way to solve the dust prob=
lem. While most solutions to dust focus on reducing how much are created an=
d encouraging consolidating utxos to avoid them becoming dust, this proposa=
l could utilize dust for valuable purposes. Why use valuable Bitcoin for NF=
Ts or colored coins when dust can be split into it&#39;s unit satoshis and =
used with no loss of utility?</div><div dir=3D"auto"><br></div><div dir=3D"=
auto">Simple and elegant. I like it. If we&#39;re giving ACKs: ACK. Tho TBH=
 I don&#39;t see any reason NACK this - seems like this doesn&#39;t affect =
consensus, doesn&#39;t affect relay, doesn&#39;t affect anything except peo=
ple that run this algorithm on the blockchain. If people want to do somethi=
ng like this, people are going to do it whether or not the bitcoin communit=
y wants them to. A standard would be good rather than everyone doing their =
own thing.</div><div dir=3D"auto"><br></div><div>One thought I had was: wha=
t happens if/when it comes to pass that we increase payment precision by go=
ing 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.</div><div dir=3D"auto"><br></d=
iv>&gt;=C2=A0If a transaction is mined with the same transaction ID as outp=
uts=20
currently in the UTXO set, following the behavior of Bitcoin Core, the=20
new transaction outputs displace the older UTXO set entries, destroying=20
the ordinals contained in any unspent outputs of the first transaction.
<div dir=3D"auto"><br></div><div dir=3D"auto">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.</div><div dir=3D"auto"><br></div><div>@Damian=C2=A0<br>&gt; I=
f I receive some Bitcoin I cannot know if some or any of those have been at=
 any point in the past been stolen, I assume the transaction is honest, and=
 in all likelihood it is likely that it is.</div></div><div dir=3D"auto"><b=
r></div><div>This isn&#39;t true at all. Some bitcoins are indeed known to =
be stolen and even blacklisted by some companies/governments. I don&#39;t s=
ee how ordinals changes anything related to this.</div><div><br></div><div>=
@vjudeu</div><div>&gt; What about zero satoshis?</div><div><br></div><div>T=
hose could be used for NFTs but not something like colored coins. It would =
be a strict subset of ability, tho its an interesting idea in its own right=
.=C2=A0</div><div><br></div><div><br></div><div><br></div></div><br><div cl=
ass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Feb 24, 2=
022, 02:15 damian--- via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@list=
s.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.=
org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x">Not all people who have been stolen from believe that they have lost the=
 <br>
right and title to what has been stolen and in many cases they have not. <b=
r>
I do not excuse Bitcoin that it is impossible to have any individual <br>
Bitcoin identified but also I do not care, if I receive Bitcoin honestly <b=
r>
I do not care what their history was. What if they were taken from a <br>
brothel? It is not a matter for an ordinal to determine if a satoshi is <br=
>
fungible. It is truth in effect that each satoshi is newly created to <br>
the new UTXO and the old satoshi destroyed. -DA.<br>
<br>
=C2=A0 On 2022-02-23 18:31, Casey Rodarmor wrote:<br>
&gt;&gt; =E2=80=8BThe least reasonable thing I could expect is some claimed=
 former<br>
&gt;&gt; holder of some ordianls turning up to challenge me that it was the=
ir<br>
&gt;&gt; stolen Bitcoin was some of what I received.<br>
&gt; <br>
&gt; I think it&#39;s unlikely that this would come to pass. A previous own=
er<br>
&gt; of an ordinal wouldn&#39;t have any particular reason to expect that t=
hey<br>
&gt; should own it after they transfer it. Similar to how noting a dollar<b=
r>
&gt; bill&#39;s serial number doesn&#39;t give you a claim to it after you =
spend<br>
&gt; it. From the BIP:<br>
&gt; <br>
&gt;&gt; =E2=80=8BSince any ordinal can be sent to any address at any time,=
<br>
&gt;&gt; ordinals that are transferred, even those with some public history=
,<br>
&gt;&gt; should be considered to be fungible with other satoshis with no su=
ch<br>
&gt;&gt; history. [1]<br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; Links:<br>
&gt; ------<br>
&gt; [1] <br>
&gt; <a href=3D"https://github.com/casey/ord/blob/master/bip.mediawiki#back=
ward-compatibility" rel=3D"noreferrer noreferrer" target=3D"_blank">https:/=
/github.com/casey/ord/blob/master/bip.mediawiki#backward-compatibility</a><=
br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer"=
 target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--0000000000003d321205d8c59fea--