Unique serial number for every single satoshi

[dree12]

No -- losing color by accident (or intentional design) just means the property is lost.  Just like you can "burn money" today by throwing away a private key, or sending bitcoins to a non-existent key, or any number of other ways.

Amen. It's not the algorithm's role to prohibit destruction of coloured coins, just as it's not the network's role to prohibit destruction of regular coins.

[1680274561]

1680274561

[1680274561]

1680274561

[1680274561]

1680274561

[jtimon]

Interesting approach, but there are some issues with this.  Since the supply of satoshis is limited, this means that penny stocks aren't practical, since the coins that record their ownership will become worth more than the stocks themselves.  Etc, etc.

Regular order coloring also suffers the same problem. The fork I call ripplecoin allows any quantities to be issued. The idea is similar to killerstorm referes to as tagging outputs here. The tag/color would be just the issuing public key.

Such a fork could also have binding advertisements to solve the "enforce trades" problem. For this last thing you would need a rule that says something like "This (partially signed) transaction it's only valid if it gets into the chain before block E".

That condition is also needed for a fully decentralized exchange (with ripplecoin, not colored coins). If you don't do that, there's DoS attacks waiting.

Imagine we're trading 2 aCoins for 2 bCoins.
I sign the transaction with my key A, wait for you to complete it...and nothing happens.
With colored coins I can just double spend to cancel the transaction. But with ripplecoin you can't always do that. If I'm actually issuing the two aCoins with that transaction, I just can't double spend an issuing operation. Probably this can also be solved with escrow transactions but I think that adding an expiry script instruction (OP_BEFORE_BLOCK) would be cleaner.

Anyway, nobody else seems concerned with this artificial limit to the divisibility of the smart assets, so...

[rodarmor]

So, funny story, in the beginning of 2022, I came up with the exact same scheme discussed in this thread. After I finished the scheme, I realized that it was basically serial numbers for satoshis, typed "satoshi serial numbers" into Google, and found this post. It feels natural extension to bitcoin, so it makes sense that multiple people have come up with it over the years.

I called it "ordinal theory" or "ordinals", because it uses order in multiple places:

• The order of satoshis in the supply of satoshis, for numbering
• The order of inputs and outputs of a transaction, for inheritance
• The order of transactions in a block, for inheritance of fees

I've spent the last year implementing it, so just 10 years after the OP, you can finally try it out!

The binary, written in Rust, is called ord, and the code is on GitHub at https://github.com/casey/ord.

I has a bunch of functionality:

• Conversion between different, equivalent, notations, including the raw integer notation, block.offset notation, names, and degree notation, which is based on relation to difficulty adjustments and halvings.
  
• An index that connects to a Bitcoin Core node instance and tracks the location of all sats.
  
• An NFT implementation which embeds NFT content in Taproot witnesses, assigning them to the first sat of the first output of the transaction, "inscribing" that sat with content
  
• A rarity system: common = not the sat of the block, uncommon = first sat of the block, rare = first sat after a difficulty adjustment, epic = first sat after a halving, legendary = first sat after a conjunction, which is the difficulty adjustment and the halving happening on the same block, which happens every 6 halvings, and mythic = first sat of genesis block.
  
• A naming system, which assigns unique names consisting of the letters a through z to each sat, basically base 26, but starting backwards, so that all short names aren't locked in the genesis block.
  
• A block explorer, with a signet instance hosted at https://signet.ordinals.com and a mainnet instance at https://ordinals.com. The block explorer supports search, try putting in different representations for a sat: 0, 0.0, satoshi, etc.
  
• A wallet, which can construct transactions to send particular sats and make and send inscriptions.
  

Everything is open source, permissively licensed, and independently developed, so try it out and let me know what you think! Keep in mind that this is still very much alpha software. We're as careful as possible developing it, but it hasn't been audited and may have bugs

[odolvlobo]

So, funny story, in the beginning of 2022, I came up with the exact same scheme discussed in this thread. ...
I've spent the last year implementing it, so just 10 years after the OP, you can finally try it out!
The binary, written in Rust, is called ord, and the code is on GitHub at https://github.com/casey/ord.

Sounds like a fun project, but I don't think the idea has any practical use because there is no real association between the satoshis in the inputs and the satoshis in the outputs.

[NotATether]

Not withstandaning the implementation that was just posted, but does anyone else find it odd that even in 2012, these kind of "markers" were already considered to be well-known, to the point where such ideas were almost redundant?

Old ideas -- Search for "colored coins" and "smart property".

[maikrothaman]

Not withstandaning the implementation that was just posted, but does anyone else find it odd that even in 2012, these kind of "markers" were already considered to be well-known, to the point where such ideas were almost redundant?

Old ideas -- Search for "colored coins" and "smart property".

I believe that colored coins should be natively supported by Bitcoin. Even though a ton of shitcoins will circulate on the bitcoin network, ethereum will be rendered useless.

[n0nce]

Not withstandaning the implementation that was just posted, but does anyone else find it odd that even in 2012, these kind of "markers" were already considered to be well-known, to the point where such ideas were almost redundant?

Old ideas -- Search for "colored coins" and "smart property".

I believe that colored coins should be natively supported by Bitcoin. Even though a ton of shitcoins will circulate on the bitcoin network, ethereum will be rendered useless.

Bitcoin does support them; as you're also proving.

Bisq for instance uses colored coins; the probably most popular actual token on the Bitcoin blockchain.
https://bisq.wiki/DAO_technical_overview#BSQ_token

I do think this serial number idea is interesting; especially reading the ideas, doubts, potentials that people have thought about this 10 years ago and how they might have changed with the latest developments like SegWit, Taproot, Lightning, ...

[houseo]

So, funny story, in the beginning of 2022, I came up with the exact same scheme discussed in this thread. After I finished the scheme, I realized that it was basically serial numbers for satoshis, typed "satoshi serial numbers" into Google, and found this post. It feels natural extension to bitcoin, so it makes sense that multiple people have come up with it over the years.

I called it "ordinal theory" or "ordinals", because it uses order in multiple places:

• The order of satoshis in the supply of satoshis, for numbering
• The order of inputs and outputs of a transaction, for inheritance
• The order of transactions in a block, for inheritance of fees

I've spent the last year implementing it, so just 10 years after the OP, you can finally try it out!

The binary, written in Rust, is called ord, and the code is on GitHub at https://github.com/casey/ord.

I has a bunch of functionality:

• Conversion between different, equivalent, notations, including the raw integer notation, block.offset notation, names, and degree notation, which is based on relation to difficulty adjustments and halvings.
  
• An index that connects to a Bitcoin Core node instance and tracks the location of all sats.
  
• An NFT implementation which embeds NFT content in Taproot witnesses, assigning them to the first sat of the first output of the transaction, "inscribing" that sat with content
  
• A rarity system: common = not the sat of the block, uncommon = first sat of the block, rare = first sat after a difficulty adjustment, epic = first sat after a halving, legendary = first sat after a conjunction, which is the difficulty adjustment and the halving happening on the same block, which happens every 6 halvings, and mythic = first sat of genesis block.
  
• A naming system, which assigns unique names consisting of the letters a through z to each sat, basically base 26, but starting backwards, so that all short names aren't locked in the genesis block.
  
• A block explorer, with a signet instance hosted at https://signet.ordinals.com and a mainnet instance at https://ordinals.com. The block explorer supports search, try putting in different representations for a sat: 0, 0.0, satoshi, etc.
  
• A wallet, which can construct transactions to send particular sats and make and send inscriptions.
  

Everything is open source, permissively licensed, and independently developed, so try it out and let me know what you think! Keep in mind that this is still very much alpha software. We're as careful as possible developing it, but it hasn't been audited and may have bugs

That idea is so crazy, it just might work

[NotATether]

Not withstandaning the implementation that was just posted, but does anyone else find it odd that even in 2012, these kind of "markers" were already considered to be well-known, to the point where such ideas were almost redundant?

Old ideas -- Search for "colored coins" and "smart property".

I believe that colored coins should be natively supported by Bitcoin. Even though a ton of shitcoins will circulate on the bitcoin network, ethereum will be rendered useless.

~

That idea is so crazy, it just might work

Two months from my earlier post, it looks like ordinals are doing just that. It's a pleasant surprise, considering that implementation (coding) was accomplished almost singlehandedly by one guy, and not by the Bitcoin Core developers at all.

Never underestimate the decentralized developer community. We can get pretty much anything done at this point.

[larry_vw_1955]

Two months from my earlier post, it looks like ordinals are doing just that. It's a pleasant surprise, considering that implementation (coding) was accomplished almost singlehandedly by one guy, and not by the Bitcoin Core developers at all.

usually when some new feature is added to bitcoin it has to go through some type of an approvals process. that happens by someone making a BIP and then it might get implemented by the devs if they agree it would make a useful addition to bitcoin. ordinals didn't happen that way. so we really don't know if ordinals was meant to exist or not. because the devs didn't have a chance to consider it before it just came into existence.

Never underestimate the decentralized developer community. We can get pretty much anything done at this point.

hopefully the devs won't try and shut down this "loophole" or should i say "unintended functionality"? either way, when people depend on some functionality they should have the reassurance that it will not be removed or taken away at some later date. we don't have that with ordinals.

[ETFbitcoin]

Two months from my earlier post, it looks like ordinals are doing just that. It's a pleasant surprise, considering that implementation (coding) was accomplished almost singlehandedly by one guy, and not by the Bitcoin Core developers at all.

usually when some new feature is added to bitcoin it has to go through some type of an approvals process. that happens by someone making a BIP and then it might get implemented by the devs if they agree it would make a useful addition to bitcoin. ordinals didn't happen that way. so we really don't know if ordinals was meant to exist or not. because the devs didn't have a chance to consider it before it just came into existence.

Creating BIP or consult with other Bitcoin developer is totally optional choice since Bitcoin supposed to be decentralized. IMO there's no need to do that when ordinals doesn't require any change on Bitcoin protocol or full node software. Other usage which insert arbitrary data to Bitcoin blockchain (such as RSK sidechain merge mining) have no BIP either.

[larry_vw_1955]

Creating BIP or consult with other Bitcoin developer is totally optional choice since Bitcoin supposed to be decentralized. IMO there's no need to do that when ordinals doesn't require any change on Bitcoin protocol or full node software.

from what i've heard and what i can tell, this ordinals thing is just using a loophole in the transaction witness size to store data. probably not how it was intended to be used. didn't they once reduce the size of OP_RETURN when people was abusing that? well hopefully that doesn't happen here or it's goodbye ordinals. nice knowing ya.

Other usage which insert arbitrary data to Bitcoin blockchain (such as RSK sidechain merge mining) have no BIP either.

well you got me on that one because i'm not too familiar with that whole topic.

at any rate, i have to congratulate rodarmor here because he really did something quite unique and alot of people got excited about it.

[ETFbitcoin]

Creating BIP or consult with other Bitcoin developer is totally optional choice since Bitcoin supposed to be decentralized. IMO there's no need to do that when ordinals doesn't require any change on Bitcoin protocol or full node software.

from what i've heard and what i can tell, this ordinals thing is just using a loophole in the transaction witness size to store data. probably not how it was intended to be used.

At very least, i never hear anyone promote Taproot to store arbitrary data/used to create NFT before Taproot is activated.

didn't they once reduce the size of OP_RETURN when people was abusing that? well hopefully that doesn't happen here or it's goodbye ordinals. nice knowing ya.

The only change i'm aware is changing limit from 40 bytes to 80 bytes. But such limit only makes the transaction become non-standard and can be bypassed by asking miner to include their transaction manually.

Other usage which insert arbitrary data to Bitcoin blockchain (such as RSK sidechain merge mining) have no BIP either.

well you got me on that one because i'm not too familiar with that whole topic.

Here's some reference (for RSK merge mining) in case you're curious,
https://dev.rootstock.io/rsk/architecture/mining/
https://dev.rootstock.io/rsk/architecture/mining/implementation-guide/