Topic: Unique serial number for every single satoshi (Read 3719 times)

There are many ways to represent an Ordinals satoshi. It is up to the implementation. At its core, an ordinal is a number from 0 to 2099999997689999. As long as  the specification is followed, everything else is just a conversion between numbering systems.

it's not style bitcoin written in. there're own types like one used for nBits (it's called like vInt or something) . in packet structure it'll be rounded up to 8 bits . with no alignment . as it is in blockheader struct. nBits goes appended to smth else so complete thing occupies integral number of bytes. And it itself has integral size too .But may be it hasn't do not remember. Like 3 bytes

I feel as though the numbering system would save a LOT of space if it was in binary.

21,000,000 bitcoins in circulation * 100,000,000 sats per bitcoin would put the total number at around 2,100,000,000,000,000. That will take about 50 bits (in hex this value would be 775F05A074000 which is 13 hex characters long, but since the upper nibble (4 bits) of the first character is unused it can be omitted).

The block height is the part that can get tricky as it needs to be future-proofed.

We are way past 800k blocks over the last 15 years. Obviously a 14-bit number (64-50) cannot hold this amount so 64-bit ints are out. But you can fit every possibly practical block height inside a 78-bit (128-50) integer. I chose 128 bits because of memory alignment issues where smaller amounts will basically use this amount of space anyway.

110000 is the number of the block that the satoshi was created in. Using the numbering system in the post, the 5,000,000,000 satoshis created in that block are numbered 110000.1 through 110000.5000000000.

While the OP might be a large text to read more carefully to understand, I might follow through on some of them but, I really didn’t pick in on how (what I might consider as the constant) 110000. While .5000000000 and all might explain for failing zeros and the 50BTC in Satoshi conversion, how did the supposedly #110000 which continues to reoccur in the rule of inheritance for output and input comes to be?

What is not practical for them however is the fact that Bitcoin will be more and more inaccessible to new people, since the cost of sending bitcoins will simply be to high for a usually small first investment. But yes it is not surprising that also the Bitcoin community will at some point drown in their greed and there will be a new innovation that will flush Bitcoin away.
As they say at some point you will become your own evil if you are drunk enough in your success.

rising fees for miners.

which like or not is very practical for them.

The Ordinals system specifically describes the association between the satoshis in the inputs and the satoshis in the outputs, so there is a real association when you use the Ordinals system. I think the jury is still out on whether there are any practical uses.

Curious to know how you were proven wrong. I also was just wondering the same thing. Is there any real association between input satoshis and output satoshis?

Ordinals is implemented outside of the Bitcoin protocol, so only the privacy of those who use Ordinals can be affected.

You mean this concept can lead to unique coding to each and every Satoshi that is already in circulation and those which will be minted in the future? If so then what happens to the privacy of transactions. I mean one could see that my XYZ property is getting moved to ABC address and it would be public information. I’m not sure technically this is correct or not but it’s gonna be anti-privacy to me.

 
Yeah you can literally change the color, size and shape of every bit of information on it. So that’s another level of burden. Already looking bad to chain.

11 years later, ordinals implement it.

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


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.


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/

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.


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.

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.

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.

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.

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.

That idea is so crazy, it just might work

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

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.

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?

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.

I'm happy to admit that I was proven wrong, but I'm still waiting for a practical use. I'm not saying that there is no practical use, just that I am too closed-minded to come up with one.

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

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

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.

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.

I think my scheme provide (much) higher anonymity. Imagine a secret society use this system for some secret trading etc., they can embed some colored satoshis in a normal size transaction, and it will just look like an ordinary transaction. With some tailor made algorithm, they may even "swap" the color of two satoshis. You system has more strict requirements. The dust inputs and outputs with special order could be spotted out easily from the blockchain.

Good point. But I work mostly on "low-level" stuff, I'll forward this consideration to people who work on app level.

Then you should add this rule explicitly to your scheme: if a coin is decolorized, the last holder retains the value of the colored coin. The issuer may issue a new token to the last holder on request (service charge may apply).

Why do you think it's a good thing? If we don't want them to be mixed, they can be mixed only accidentally.

So, if accident happens, with order-based coloring you get uncolored output, so information is destroyed. Now if they represented something valuable, issuer can issue a new token and give it to last holder after he learns about an accident. So accident is resolved by issuer.

With your scheme, some random party might get ownership of valuable coins in case of accident. Yes, they won't be destroyed, but is lottery really a way to resolve this?

There is one more advantage: the color information won't lose if coins with different color are mixed.

Good. We may transform it to Base-58 format, which will take 9 characters. We may also add 3 characters as checksum

Given an algorithm like this, one could effectively say that every satoshi is already numbered, it's just that nobody has yet bothered to calculate it.  That wouldn't change it.

If I were going to number each satoshi, I probably wouldn't bother to number them with the block.  I'd just number them from 0, and consider the genesis block to be satoshis 0 thru 4999999999 (despite them technically being unspendable).  The proceeds of block 1 would be 5000000000 (5e9) thru 9999999999(1e10-1).

The last satoshi of the block with 50 BTC reward would be 1049999999999999 (50*210000*1e8-1).

Block 210000 would be 1050000000000000 - 1050002499999999, spanning a total of 25*1e8 satoshis.

Because a technology can be used negatively, does not mean it is unacceptable. Colouring satoshis has many practical and useful aspects. The benefits outweigh the negatives.

It's more like "taint all the money!"

I've been looking for a place to put this

http://www.foopics.com/show/ebf4989def30ec9ef246ffe2c11359fa

As I understand, this is largely compatible with order-based coin coloring, i.e. as long as transactions adhere to order-based coloring rules this proposal and order-based coloring will produce identical results.

The only practical advantage I see is that it's possible to pay fees with colored coins, i.e. miner can take advantage of coins' color.

However we I'm not convinced that we need this more complex system just to handle fees, since there are some ways to use colored coins for fees with order-based coloring.

There is no reason for someone who owns a coloured satoshi to melt it down. That only ensures the satoshi is sent to someone who does not recognize its value.

You always have the freedom to setup a coin melting mining pool, and I encourage you to do so. However, joining your pool is voluntary. Unless there is a protocol change, my proposal will still work.

When people trade "penny stocks", they will also consider the face value of the colored coin. For example, if someones wants to buy 1 colored BTC with 0.1 BTC, he has to pay 1.1 BTC to the seller. If 1 satoshi stock worths less than 1 satoshi, it either means the stock is worthless (people may trade in bigger unit, e.g. 10000 satoshi), or 1 satoshi worths too much (we need a hard fork to add more zero after decimal place)

lol then all of a sudden precision increases by one!

Another one claiming for "tainted Satoshis".

We need urgently a coin melting mining pool in order to get protected for this kind of "visionaries".

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

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.

Although bitcoin is designed as fungible, it is possible to assign an unique serial number to each atomic unit (aka satoshi). With this serial number, a satoshi may represent more than its face value (e.g. colored bitcoin, smart property, securities).

Serial number has two parts: the integer part is the block number where the satoshi is generated, and  the fractional part represents each unique satoshi. Taking the generation at block 110000 as example:

http://blockexplorer.com/tx/4e10436ca8206a2dd760dd351210a5120a3824d4eb53011be0a7b9a33b368208

There were 50BTC, or 5000000000 satoshi generated. Therefore, the serial number of these satoshi are #110000.0000000001 to #110000.5000000000. Tailing zeros are reserved.

Here we define RULE OF INHERITANCE: In a transaction, the input sequence atomized to satoshi, with each satoshi has its unique serial number. The satoshi sequence is mirrored to the output, based on the output sequence. If transaction fee is paid (i.e. input > output), the fee is considered as the last output. In case of coinbase transaction, transaction fee is sorted after standard block reward, according to the transaction order in the block.

Using the previous example, the 50BTC is completely transferred to another address:

http://blockexplorer.com/tx/3abed8a3aa728e881a9ef85062fe11b79b490c885295c3c55fc6a534199a5dc5#i398943

Therefore, 12WFtKBsRLtV8p1NwRqe7YwYdi1rjwTZhA inherits satoshis #110000.0000000001 to #110000.5000000000.

Next, the 50BTC is split into two outputs: the first one with 5.2BTC and the second one with 44.8BTC:

http://blockexplorer.com/tx/2faea2cc59b32f5cc19fd8aee85db3e82bbdccb32c52879fecddc592b172d981#i399136

Therefore, the first output inherits satoshis #110000.0000000001 to #110000.0520000000, and the second output inherits satoshis #110000.0520000001 to #110000.5000000000.

The next one becomes more complicated. The 5.2BTC output in the previous transaction is mixed with other inputs. There were two outputs, with 0.36BTC and 60BTC respectively:

http://blockexplorer.com/tx/2ba980e8b17c46e671e8a09bef43815e26ae561facc35f415ef04b11bf4b7545#i405322

Based on the rule of inheritance, the first output will inherit the first 36000000 satoshis in the first input (bfdc71884b80...:0). All the rest will go to the second output. Those satoshis #110000.0000000001 to #110000.0520000000 are embedded somewhere in the middle of the second output. To be precise, they are the #2171000001st to #2691000000th satoshis in the second output. (5.11-0.36+5.49+5.3+1.15+5.02=21.71)

In the following transaction, the 60BTC is mixed with other inputs to make a single output of 954.27BTC

http://blockexplorer.com/tx/03616a5d76508d45a0def171c29b3672714410c49648704eb766f2e74b4ed1fe#i406741

Therefore, the satoshis #110000.0000000001 to #110000.0520000000 become the 81598000001st to 82118000000th satoshis of the output. (1.25+500+19+1+161.82+5.2+106+21.71=815.98)

Here we use another example with transaction fee:

http://blockexplorer.com/tx/afe357b19ca0b0c939b414d3dd63d523bb2a518237df51afc7d6f26098967c7d

Transaction fee of 0.00574567 (574567 satoshi) is paid. According to the rule of inheritance, transaction fee is the last output. The last 574567 satoshis of input comes from transaction bcf2b1c4f75c...:0, which is the generation of block 99120. Therefore, the transaction fee is satoshis #99120.4999425434 to #99120.5000000000

The fee is collected by the miner of block 100035:

http://blockexplorer.com/block/00000000000135cb86be36978e74a54cfd2b9143f827a589c9e27fde3463b753

Since this is the only transaction with fee in this block, those satoshis #99120.4999425434 to #99120.5000000000 are embedded at the end of the coinbase transaction. Therefore, the coinbase transaction has satoshis #100035.0000000001 to #100035.5000000000 and #99120.4999425434 to #99120.5000000000, in the exact order.

With this system, every satoshi has its unique identifier, or “color”. To make a lending contract, for example, the borrower will send a colored satoshi (e.g. #123456.1357924680) to the lender, and the lender will send the loan in the same transaction. The lender may sell the contract to other people with similar mechanism, and the borrower will repay to the address with the colored satoshi.

We can also have decentralized security market with the system. Each satoshi sent from the issuer’s address is equal to one share. Although the serial numbers of these satoshis may not be continuous, it is still traceable. The issuer will pay dividend to the addresses with colored satoshis, and the shareholders will vote using the address private keys.

Please note that this proposal has nothing to do with criminals/scammers tracing.