Collect Bit

Summary:
CollectBit is an implementation of a Digital Collectible Network
Published: 5/25/2021
Update:
Author: GiverofMemory
Maintainer: GiverofMemory
Creator:
License: Site License
Categories: See Footer
See Also: Digital Collectible Network
Page: (upload / browse / edit / print)
Discussion: CollectBit-Talk
Archive: ,
Download: URL,PDF from URL

See Digital Collectible Network whitepaper for a more in-depth design document of which CollectBit is based on.

Intro

CollectBit is a new type of Crypto project; cryptocollectible [1] instead of cryptocurrency. It differs because it consists entirely of collectibles that cannot be divided. This gives us several advantages.

First each unit on the network (token) has it's own proof of creation baked into the token itself. In a cryptocurrency you have to maintain a chain of history from when the coin was created as a coinbase reward, all the way to the current ownership in order to verify that work was done to create it. In CollectBit, the proof follows the token, everywhere. So an immutable history, that a UTXO blockchain is necessary to maintain, is simply not needed. If you own the password (private key) for the token, then you own it. The token has no history apart from that. In order to trade it the public key is simply changed (which corresponds to a new private key ie: password). So the only history that is kept is a string of public keys, which means nothing because they are unique to the token, and cannot be used to trace or connect this token with any others. The only person who knows they own a token is the one holding the private key. There is nothing to analyze to attempt to determine an owner. Only the owner knows who they are.

Each token is self contained, containing all the information to verify that it is valid and which public key it is associated with. Therefore this token can be held, apart from any network. The network simply exists to host the tokens. So you could have your token hosted on several networks if you wanted.

If networks do not want to be compatible with other networks, they could require a special string be cryptographically integrated into the token, ensuring that the token was created specifically for their network.

Trade

To trade tokens, the giver gives the receiver their private key for that token (this can be done offline). Then the receiver uses the private key (that both giver and receiver know) to sign for a new public key to be associated with the token (that presumably only the receiver holds the private key to). Now we basically have an updated token when that transaction is broadcast to the network.

So this updated token is submitted to the network(s). If it matches previous signatures that the node has on file and it is a longer chain (more signatures for key changes) than the token that the network already had on file, then it updates their database accordingly. If it is the same length or shorter, it is rejected (it is also rejected if it is longer but doesn't match the nodes previous signatures for the token). So the receiver of the token can now view the network database and verify that the network accepted the key change, and can alert the giver that it went through and we can proceed with the exchange of goods.

You cannot send the collectible to the wrong address, so the giver never has to worry about loosing the funds. The receiver does need to make sure the new key they associate with the collectible is correct though; but that is on the receiver, not the giver.

Trade second option

Another option to trading tokens is for the receiver to generate a new private-public key pair. They then send the public key to the person who currently owns the token. The current owner then sends a transaction message to the network using their current private key to sign for a transfer of ownership to the new public key. This way a private key never needs to be shared, so it can be done on un-encrypted communication channels. The downside to this method is that this transfer cannot be done offline, unlike the first method.

Technical Features

  1. Infinite potential transactions per second - no limit. Can potentially be offline.
  2. Emission scales perfectly with adoption like Gold - stable: non-inflationary and non-deflationary. Constant amount of work (One CPU-WEEK) required to produce each token.
  3. Mining utilizes primarily the CPU and has the strongest ASIC and GPU resistance possible. GPU can speed up the CPU by never more than 20%, CPU will always be required for the majority of the work. Mining is offline.
  4. Fully Permission-less and Fungible. Mining and trading can be offline for impeccable censorship-resistance. Tokens are stand-alone and are not associated with each other - perfectly untraceable.
  5. Consensus mechanism is natural convergence. Majority (51%) attacks are not formulaic to achieve and the network can adapt to resist any attempt.
  6. Tools are given to nodes for them to build a reputation to become more trusted and thus more profitable. Staking, Vouches, Reputation, Popularity, and Disputes are all factors. If you can reliably get the network to converge to your ledger, people will trust your ledger more.

Comparison to Cryptocurrency

See an in depth comparison [2]

Speed of Transactions

CollectBit transactions are instant, as fast as the network allows. There is no waiting for blocks to be formed, and mined. There is no bandwidth limit, as fast as transactions can be broadcast, verified, and listed, they are confirmed. Another step is for the person receiving the transaction to verify that the nodes have reached consensus on accepting their transaction (A "transaction" is a simple key change for the collectible). So transactions will confirm just about as fast as a centralized database, a second or two.

In Bitcoin, transactions are broadcast, verified, and listed, but then have to go through the 10 minute step of mining them into a block. If the transaction does not fit in the block, then it will have to wait to be hopefully listed in a future block. This is a very slow and tedious process that has both limited speed and bandwith.

Privacy

CollectBit is private by nature. Each collectible has it's own public and private key and therefore cannot be linked in any way with other collectibles. The only way linking can happen is if you tie the collectible with an identity. For example if you have an account with a node and pay them $1 a month to list all your mined collectibles, then you would have to log in to post your collectibles. Now that node knows which collectibles are linked with your identity. To avoid this you can either host your own node that syncs up with the rest of the network, or you can find a node that doesn't charge any fee for listing and therefore you would not need to link the collectible to your identity in order to get it listed.

In Bitcoin, all a person's funds are grouped into one (or more) public and private key. Public and private keys in the same wallet might also be linked together by analysis. So every coin that comes into that address (or wallet) or has once been in that address are linked to the same identity. This makes analysis possible, and as far as anyone knows, any coins that have gone through an address has the same current owner and can be tracked.

Ledger

CollectBit runs on a simple database. So each node would be hosting a SQL or similar database and would sync with (preferably) a handful of other nodes. They sync by looking for collectibles that they do not yet have listed, and list them. If they already have a collectible and someone has the same one, then they compare the key change chain (kcc). If the key change chain for a collectible that the other node has are the same as what they have, yet there are more key changes, they will update those new key changes (which each required a valid signature to do). If the key changes of the other node do not all match with what they have, then they will reject it. Every collectible is just a single line in the database.

In Bitcoin the ledger is also a distributed database, but it has a special format and is not a simple SQL file. It is long and complex and hard to sync. Bitcoin's may be smaller than collectbit to store the same value though, since many coins are in every address; but it still will be much more complex.

Nodes

CollectBit nodes are the leadership of the network. There is no node hierarchy, anyone can host a node and sync up with the network, and they are encouraged to do so. There are certain things that nodes can do to improve their credibility such as staking collectibles that can be blacklisted if the node is dishonest, getting vouches from other trusted nodes, being well connected with other nodes, staying clear of disputes, and offering good customer service. Ultimately every node is equal the only question is what nodes the customers (users of the network) trust. Oftentimes when verifying their transaction went through they will check the top trusted nodes and assume the rest will fall in line. Also they might submit the transaction to only a handful of the most trusted nodes. Nodes will also have the ability to make the rules and set the digit length of the tokens to maintain their respective Time Standard (TTS). Every year should be a convention where the TTS-30d (Orca) holders can vote on proposals. Nodes will have a veto power however as a sort of "Supreme Court" where they maintain the principles of CollectBit as laid out in the whitepaper (which is editable by the community). In CollectBit miners have little power, thier only power is which nodes to submit their tokens to. This can be a little power if they only submit tokens to their chosen network fork and therefore provide liquidity to that network.

In Bitcoin nodes are not worth much. The decisionmakers in Bitcoin are the miners; Satoshi's 1 CPU= 1 Vote. This means the only factor that can determine trust in bitcoin nodes is how much hashpower they exert. but hashpower is not a good measure of trustworthiness or customer service. Usually the miners fall in line with the developers, with node runners nothing more as "seeders" and "relays" for the blockchain for others to download and miners to use.

Consensus

CollectBit consensus is not forced. However consensus is necessary to be a part of the same network. So in CollectBit there are methods to gain influence like Staking collectibles, getting vouches, staying free of disputes, and practicing good customer service would make nodes popular and trusted by the community and therefore influential. A new unknown node wouldn't be able to convince other nodes that their ledger is correct but an influential one will.

Besides that, everything listed on the network is cryptographically verifiable and provable. So an influential node cannot simply make up transactions or list fake tokens. The only thing a node can do is to omit transactions and collectibles, but if other nodes are carrying them, then people will realize the node in question is censoring and it would be booted from the network.

The biggest challenge will be some nodes listing a different key chain (ownership history) which would have been a collectible owner attempting a double spend. The first listed would be the valid one, and that is something the network has to converge to agree on. This is why every transaction is allowed to propagate the network and the network agree that it is valid and accepted before goods change hands in a transaction. The receiver of CollectBit simply has to wait enough time for the network to achieve consensus, which should be on the order of a second or two.

Mining

Leadership

Only Virgin (untransferred) Orca tokens can vote, and they can only vote for 1 year after token creation. This is to help prevent people from buying and hoarding voting tokens. The goal is everyone mines one orca token a year to participate in the convention.

Security

You cannot send a collectible to the wrong address.

Tokens

Challenges

As a brand new type of good - and network - CollectBit will have unique challenges, even though it solves basically all of Bitcoin's challenges.

Node centralization

Even though collectibles cannot be linked by analytics, prying eyes can spy on some of the main nodes on the network. These high profile nodes due to their popularity, will attract attention. If someone has an account with a main node, or get their IP address logged by this node when submitting collectibles, then that is a potential vector for surveillance for governments and other spy organizations. So say the most popular node requires you to create an account to upload collectibles to their database, and therefore get synced with the rest of the network. Now every collectible you mine and submit would be linked to your account. The only way I can find around this linking to an identity (even if it is a pseudononymous identity) is for no account to be needed and no IP address logged (or allow probable VPN IP's) and listing would be free. As long as any payment is used, even if cryptocurrency, then that is a vector to link collectibles to an identity. Even if you used a mined collectible to pay for hosting another mined collectible (which likely will happen in CollectBit since there is nothing stopping nodes from doing it), then those two collectibles would be linked to the same owner. So our network would need to tend towards free listing to keep everything perfectly private. This free hosting is not as much to ask as it is for Bitcoin, since the ones recording transactions in Bitcoin are miners using mass amounts of electricity. In CollectBit it is normal full nodes that host and transfer collectibles, not miners, and therefore they use minimal electricity and computer resources.

A solution to node centralization

Since we now have smaller denominations like Vaquita tokens which only take 20 mins to mint, noes could require someone to pay for hosting tokens with Vaquita's. Say you want to upload a Beluga token, you pay the node a vaquita token to do it, and tokens can still remain unlinked (besides knowing that the vaquita token and beluga token were at one point owned by the same person, which shouldn't be a big deal).

Current Settings

These settings will be revisited yearly and will be voted on every year by the community. Changes can be vetoed by the nodes via the nodes simply refusing to change the rules according to what the community wants. Veto power should be used very rarely and carefully because community consensus is very important. Every node participating in a veto should make a public statement as to why, or that they agree with another nodes reasoning. Nodes should not make changes on their own, as doing such is forking the network. Thus nodes can veto by refusing to make changes but cannot change anything on their own accord. Things that should not change is the semiprime requirement (challenge numbers can only have exactly two factors) and the time standards (for example beluga token signifies 1 CPU Week).

Beluga token

  1. Beluga tokens currently require a semiprime challenge number that has 151 digits and the smallest of the two factors must be equal to or greater than 0.36 * 151 so 54.36 which is rounded up to 55 digits. This ensures that each token takes about the same time to mine and requires ECM as well as GNFS to complete. The 0.36 is open to change as well as the 151 digits to both maintain resistance to pure ECM (GPU) factoring (which can currently go up to 0.34 times the number) as well as keeping it to 1 cpu-week to factor with a decent new computer.
  2. Beluga can be traded 1,000 times before it is fully degraded. Thus each token looses 0.1% of it's value every trade. So if you send $1,000 worth of beluga tokens, you are paying $1 in degradation. This does not apply to NFT's or LFT's which have a separate degradation method.

Blue Token

  1. Blue Token should take 1 year of CPU work to mint. Blue can be transferred 1,000,000 times before it fully degrades. So if you transferred $1,000,000 of blue tokens you would loose $1 to degradation. Blue looses 0.0001% of it's value per transfer.

Humpback Token

  1. Humpback Token should take 6 months of CPU work to mint. Humpback can be transfered 100,000 times before it fully degrades. So if you transferred $100,000 in Humpback tokens you would loose $1 to degradation. Humpback looses 0.001% per transfer.

Orca Token

  1. Orca token should take 1 CPU-month to factor. So we will start with a requirement of 161 digit challenge number and 0.36 minimum factor length so 58 digits.
  2. Orca token can be transfered 10,000 times before it fully degrades so it would loose 0.01% of its value every trade. If you transfered $10,000 worth of Orca token you would loose $1 to degradation.
  3. Orca token is the voting token and is part of what is required to have a valid vote, and this fact should not change unless the voting period has been different than one year for 3 periods in a row. If so then a majority vote can change the voting token. If the voting period ever reverts back to 1 year, then the voting token reverts back to Orca.
  4. An orca used in voting must have been mined after the last vote, and must be untraded (virgin) since this means votes cannot be bought or sold.

Ginko Token

  1. Ginko token takes 2 days of CPU work to mint. Ginko can be transferred 500 times before it fully degrades. So if you transferred $500 worth of Ginko tokens you would loose $1 worth to degradation.

Bottlenose Token

  1. Bottlenose token should take 8 hours of CPU time to mint. Bottlenose can be transferred 100 times before it fully degrades, so 1% per transfer. So sending $100 worth of bottlenose tokens would loose $1 in degradation.

Hourglass Token

  1. Hourglass token should take 1 hour of CPU time to mint. Hourglass can be transferred 100 times before it fully degrades, so 1% per transfer. So sending $100 worth of Hourglass tokens would loose $1 in degradation.

Vaquita Token

  1. Vaquita token should take 20 minutes of CPU time to mint. Vaquita can be transferred 100 times before it fully degrades, so 1% per transfer. So sending $100 worth of bottlenose tokens would loose $1 in degradation.



Other pages that link to CollectBit:

T

Attachments to CollectBit:

Password to edit: nature