public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Billy Tetrud <billy.tetrud@gmail.com>
To: damian@willtech.com.au,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Draft-BIP: Ordinal Numbers
Date: Thu, 24 Feb 2022 09:55:57 -0600	[thread overview]
Message-ID: <CAGpPWDYGheCFZS67agC=wVvrrC2VNunQs-LqCa=V34bAQYBosg@mail.gmail.com> (raw)
In-Reply-To: <a54b2632d9b20f9330cf129706f5c886@willtech.com.au>

[-- Attachment #1: Type: text/plain, Size: 4212 bytes --]

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:
> >> ​The least reasonable thing I could expect is some claimed former
> >> 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:
> >
> >> ​Since 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-compatibility
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 5439 bytes --]

  reply	other threads:[~2022-02-24 15:56 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-23  0:43 [bitcoin-dev] Draft-BIP: Ordinal Numbers Casey Rodarmor
2022-02-23  7:02 ` damian
2022-02-23  7:10   ` Casey Rodarmor
2022-02-23  7:24   ` damian
2022-02-23  7:31     ` Casey Rodarmor
2022-02-24  2:34       ` damian
2022-02-24 15:55         ` Billy Tetrud [this message]
2022-02-24 21:03           ` Casey Rodarmor
2022-02-25  4:59             ` Billy Tetrud
2022-02-25 11:17               ` AdamISZ
2022-02-25 15:56                 ` Billy Tetrud
2022-02-24  7:02   ` vjudeu
2022-02-24  7:17     ` Casey Rodarmor
2022-02-24 17:52 vjudeu
2022-02-24 21:02 ` Casey Rodarmor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAGpPWDYGheCFZS67agC=wVvrrC2VNunQs-LqCa=V34bAQYBosg@mail.gmail.com' \
    --to=billy.tetrud@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=damian@willtech.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox