BitCANN - Bitcoin Cash for Assigned Names and Numbers

BitCANN - Bitcoin Cash for Assigned Names and Numbers – is a decentralized domain name and identity system built on the Bitcoin Cash Blockchain.

  • Decentralized Domain Names like .sat and .bch and more.
  • Add Records, RPA Pay Codes, Add Currency Addresses, Text Records, Custom Records, Social, Email, and more.
  • No Renewals or Expiry*
  • NFT Domain ownership, enabling secondary market trading.
  • Easy lookups
  • Sign-In using your Identity
  • Plugin for other contract systems
  • Earn by protecting the system by:
    • Burning illegal registration attempts
    • Identifying and burning registration conflicts
    • Proving domain violations

Looking forward to feedback and discussions :slight_smile:

Additionally, I’d like to open a discussion on how we can audit contract systems like BitCANN and establish a process and how would that process look like? We did some discussion about the same at General Bull 43 “BitCANN and Smart Contract Audits” https://x.com/GeneralProtocol/status/1893361808355795254

9 Likes

On getting a contract system audited, this is my approach:

Unit Testing

Using the “mocknet” feature of CashScript is great to unit test isolated functionality.

In theory, it would probably be best practice to have unit test assertions hitting every condition of each contract; in practice, it would probably be excessive to retest similar conditions.

Currently the “mocknet” provides great debugging BitauthIDE links. But meep is also back online if you get the transaction hex.

Integration Testing

If all the contracts appear to work as intended, regression testing them on against a real node is next.

There can be automated tests against regtest, chipnet or mainnet. The advantage of regtest network is that features dependent on time can be simulated by mining new blocks.

Audit

Once the system is tested and somewhat “fixed”, they can be sent to audit.

An auditor is likely to suggest optimizations, enhancements and improvements, those changes could be easily made and retested with regression tests.

The simplest way to engage a good auditor is with money.


Just downloaded your GP talk, will circle back later.


This was the audit for Future Bticoin Cash, completed by the Bitcoin Cash Autist in July 2024.

BCA and Jason have a better understanding of what is possible in the VM beyond conventional application layer stuff.

BCA also has a broader understanding of cryptographic and on-the-wire attacks.

A markdown audit makes it easy to convey in many formats and machine readable.

4 Likes

Thanks! This is solid advice.

Along with this, I am preparing a checklist that I’ll keep on updating here:

  • Find and list the entry points
  • Find future upgrade vulnerabilities (for example relying on 40 bytes of commitment length, an attacker can update the nftCommitment in a way that creates a Denial of Service).
  • Find who can inject the input in the transaction, p2pkh or p2sh
    • For example: In cases where someone wants to store the pkh from an input, they’ll probably split the lockingbytecode but if the input is from a p2sh then the stored value in the commitment will be incorrect leading to a DoS. require(tx.inputs[x].lockingBytecode.length == 25);
  • Find potential utxo injections
  • Find unintentional burns
  • Find unintentional minting
  • Find category leaks (token going somewhere where it was not supposed to)
  • Find deadlocks due to state updates (nftCommitment getting updated in such a way that it can’t be used anymore)
  • Check Genesis configuration (Mis-configurations can lead to failed states later on)
  • Mathematical errors
  • Find input and output restrictions (If any)
  • Find version checks (timelocks, etc.)
  • Split errors without checking the length
1 Like

Just created a Telegram group for discussions

1 Like

Auditing and security is the level “below”, but also we need the level “above” which is a nice UI interface, wallet integrations, a marketplace to easily trade the domains etc.

I’m thinking about that as I look into this, I’ll let you know if I have any ideas.

Good space with a lot of discussion about this idea: https://x.com/i/spaces/1mnxegbdNMNGX

(Might be worth /someone preserving it and uploading to Youtube)

Small update:

I recently started working on an npm package and a basic react frontend. I have been a bit busy so the progress is slow :slight_smile: I’ll speed up the development a bit now and also improve the documentation as I work on the package and app.

bitcann.js GitHub - BitCANN/bitcann.js at develop
frontend app: GitHub - BitCANN/app

2 Likes

Released the v1-draft for SORTS

The document defines the Simple Op Return Text Standard (SORTS) for use in on-chain identity and metadata systems. It is designed for append-only, immutable environments like BitCANN or similar smart contract systems, where data is in fixed-size or limited-size (e.g max 223 bytes in BCH, 2025). The SORTS enables flexible key-value data, namespacing, robust revocation, deduplication, and support for large values through fragmentation. The goal of this standard is to provide a human-readable, stateless, and portable format that supports extensibility and simple parsing.

1 Like

Thanks for sharing this project. I have a few questions that could be added in the FAQ:

1. Can the platform issuing the contract or any miner artificially bump up the price of an auction?

Let’s say I want the name “apple”, and I start an auction. The platform issuing the contract sees this and automatically makes a bid for 1 USD (in BCH), using a different address to hide themselves.
When I see the 1 USD bid, I bid let’s say 5 USD. Then the platform makes another bid of +10%, that is 5.50 USD, and I increase again to 6 USD. The platform does not bid any more, I finally get the name, and the platform makes x% of 6 USD.
What happened here is that I paid 6 USD for a name when the name had no real demand behind: the platform did not really want to use the name, they only wanted the registration money.
If the platform tunes their algorithm correctly, they can automatically get some bucks for names they do not wish to use (same for a miner, but with the probability of mining a block).
Is this possible in BitCANN?

2. Do all names belong to the same namespace?

In BitCANN there can be multiple platforms issuing registration contracts. Do the names registered by different platforms belong to the same namespace?

3. (In case all names belong to the same namespace) Can a user just become a platform and always get 100% of the registration money?

Let’s say I want to register “apple”. I can take a look at the contract that would be created using an existing platform, and then decide to build my own contract putting one of my addresses as the recepient of the registration money.
In that case I would get all the names I want for free. Doesn’t that give free range to squatters, and incentivizes users to bypass platforms?

4. The fact that name registrations are visible from the start doesn’t it make it easier for squatters to squat?

In naming systems, squatters try to purchase the names that will have more demand so that later they can resell them at a higher price. However, since auctions are fully public from the start in BitCANN, that signals squatters where the demand is.

Why is this prefered to hiding the name during registration as Namecoin does?

2 Likes

Thank you for looking into it, I’ll add these as part of the QnAs on Bitcann Protocol

Platform: The fee is collected on an auction-by-auction basis. It’s possible for anyone to bypass any or all steps of the platform. Any technically advanced user, another platform, or a third-party software can be used as a legitimate competitor to facilitate users claiming their domain and potentially offering a cashback, reducing the platform’s revenue. Hence, the platform is disincentivized to engage in such activity, as new competitors will emerge and disrupt their revenue model. Platforms are incentivized to give the best user experience and maintain a network effect for their own benefit.

Miner: No miner can be certain they will mine a specific block a given number of blocks in the future. Hence, if they try to artificially pump up the price, they must rely on other participants to place a higher bid and hope that they themselves mine the block containing the winning bid.

Yes, they belong to the same namespace/TLD.

No, it’s not possible for anyone to claim a domain solely by knowing the contract that will be created. Each domain contract includes restrictions that make self-claiming impossible. Ownership must be obtained through the auction process.

Since it’s not possible to hide the domain being auctioned directly, an alternative approach is to use a hash-based auction.

  • Creating a registry of hashes is easy, which undermines the perceived privacy of a hash-based auction.

  • We can probably agree that satoshi.bch has far more value than a3n-ns210.bch, so a hash-based system is only making it harder for a select few squatters. Any dedicated squatter would still be easily able to know the name that is hashed by looking up into a private/public registry.

  • Since it’s an auction and not a fixed price, it gives interested parties a fair chance to compete for ownership of a name.

  • Squatters must initiate or place a bid in an auction and hope that no one else participates. If another bidder enters, the squatter faces increased financial burden, as each new bid must be higher by a certain percentage (e.g., 5%), discouraging speculative hoarding.

  • At the contract level, if the revealed name is greater than 20 bytes, it’s impossible to claim it, essentially locking money forever. This adds more to the already weak case for using a hash-based auction.

Furthermore, BitCANN allows people to do a lot with their domains. This means someone might buy up many and develop a leasing platform, renting them out to others.

Quite a bit of discussion of BitCANN on the latest Podcast episode.

1 Like

Thank you for the answers!

The fee is collected on an auction-by-auction basis. It’s possible for anyone to bypass any or all steps of the platform. Any technically advanced user, another platform, or a third-party software can be used as a legitimate competitor to facilitate users claiming their domain and potentially offering a cashback, reducing the platform’s revenue. Hence, the platform is disincentivized to engage in such activity, as new competitors will emerge and disrupt their revenue model. Platforms are incentivized to give the best user experience and maintain a network effect for their own benefit.

Makes sense, although it would be difficult for a user to come to a conclusion that the platform is increasing prices, since the address will be different. So the user would need to compare the average final auction price of all name registrations between platforms, and come to the conclusion that another platform is “less rigged”.

Miner: No miner can be certain they will mine a specific block a given number of blocks in the future. Hence, if they try to artificially pump up the price, they must rely on other participants to place a higher bid and hope that they themselves mine the block containing the winning bid.

Agreed, miners have it more difficult to extract money from the system, but still there could be a certain range that could be beneficial (according to their probability to mine a block). Nonetheless, it seems the reward would be too small to compensate such a setup.

No, it’s not possible for anyone to claim a domain solely by knowing the contract that will be created. Each domain contract includes restrictions that make self-claiming impossible. Ownership must be obtained through the auction process.

Sorry, by “knowing the contract” I meant it makes it easier for anyone to “reverse engineer” and become a platform in their own right. They would still need the necessary libraries/SDK to build a new contract just like any regular platform.

The thing is, if anyone can potentially be a platform, then users have the possibility to:

  1. Create contracts using a platform address they control.
  2. Start auctions using a user address they control.
  3. No matter the final auction price, all the money will go to the platform’s address controlled by them.
  4. The user gets the name and recovers the money.

I suppose that the question is:

5. Can the platform owner use a regular user address to acquire names and recover the bidded money (since they control the platform’s address too), meaning the names are free for a platform owner?

Besides acquiring free names, the platform would also gain fake activity and appear more popular than it is.

  • Creating a registry of hashes is easy, which undermines the perceived privacy of a hash-based auction.
  • We can probably agree that satoshi.bch has far more value than a3n-ns210.bch , so a hash-based system is only making it harder for a select few squatters. Any dedicated squatter would still be easily able to know the name that is hashed by looking up into a private/public registry.

I see, yes, this makes sense. Still, a rotating salt could be used, though it would mean you’d need 2 salted hashes (current and next) for each name (otherwise you cannot compare hashes that have the rotation point between them but are separated by less than an hour, or the time range elligible for comparison).

  • Since it’s an auction and not a fixed price, it gives interested parties a fair chance to compete for ownership of a name.

This would make sense if the interested parties happened to decide to acquire the name at similar times. But this is a rare occurrence unless the auction lasts a long time, which gives a bad UX. This means that most likely, the users acquiring a name will be bidding against squatters (which want to resell or lease) or cheaters (platform owner, miners).

By hiding the name behind salted hashes, you ensure that only someone that happened to want the same name within the same time window can bid for it.

  • Squatters must initiate or place a bid in an auction and hope that no one else participates. If another bidder enters, the squatter faces increased financial burden, as each new bid must be higher by a certain percentage (e.g., 5%), discouraging speculative hoarding.

Still, squatters will acquire names as long as the cost does not exceed future expected gains (reselling, leasing), so I don’t think this compensates for not having salted hashes.

  • At the contract level, if the revealed name is greater than 20 bytes, it’s impossible to claim it, essentially locking money forever. This adds more to the already weak case for using a hash-based auction.

Interesting, that means the client app hashing the name would need to make sure to disallow long names.

Since each auction is unique and likely involves a different individual or address, it’s unclear how platforms will predict whether a bidder will follow through with a higher bid after the platform has already placed one. That said, I think there may be cases where the platform or other actors will attempt to randomly test the waters to see if they can inflate the price without ultimately winning the name themselves.

Once the bitcann’s static 8 contracts are set in place, no one can change them. It’s not possible to create contracts using any platform address. Infact, there isn’t a concept of platform address in the contracts.

I see, to tackle this issue, the ‘factory’ contract that ends up creating the name has a parameter called maxPlatformFeePercentage and that is set only once at the genesis phase, let’s say that is set to 50% then will only be able to get 50% of their money back. So the platform has a lot to loose by generating fake revenue.
Also, for a single instance of bitcann an auction on a completely different platform will be visible on all the other platforms as well, allowing bidding and any other interaction.

Hmm, I am not able to imagine/understand it correctly. Who will add the salt and then create the hash?

  • If the party starting the auction adds it then it’s not known by the next bidder so that’s not going to but it.
  • If the salts are already known, that circles back to the same issue we have but more complicated

I am sure I am missing the point, can you give an example?

Right, from what I have researched, there is no clear solution to squatting so disincentivising is a great way to find a balance.

I think I can imagine a way to ‘refund’ this at the contract level as well but I am still not convinced that hashes provide any real value.

Once the bitcann’s static 8 contracts are set in place, no one can change them. It’s not possible to create contracts using any platform address. Infact, there isn’t a concept of platform address in the contracts.

I was under the impression that:

  • Anyone can become a platform, with the necessary libraries/SDKs
  • At genesis phase, the platform creator can choose any parameters they desire.

I see, to tackle this issue, the ‘factory’ contract that ends up creating the name has a parameter called maxPlatformFeePercentage and that is set only once at the genesis phase, let’s say that is set to 50% then will only be able to get 50% of their money back. So the platform has a lot to loose by generating fake revenue.
Also, for a single instance of bitcann an auction on a completely different platform will be visible on all the other platforms as well, allowing bidding and any other interaction.

Can I create a platform that sets 100% payout to the platform ( maxPlatformFeePercentage := 100) at genesis phase?

If so, then I can start auctions, and no matter the final price, all the auction money will go to me, since I created the platform with 100% payout.

Who will add the salt and then create the hash?

You can use (part of) the last block hash; this would require the cheater to build the hashes each hour (or whatever the max duration of an auction is).

Also, the important part of hashes is that they protect non-obvious names. If a squatter has a list of obvious names, they won’t wait until a user makes an auction, they’ll just start the auction as soon as possible to get them the cheapest.

But non-obvious names are not on any list. By hashing them, you hide them from squatters/cheaters.

The bottom line is: squatters won’t waste time hashing popular/known names, they’ll just acquire them. What you are protecting with hashes is more unpopular names that noone has considered yet.

If your auctions have names in clear text, you are just providing the squatters/cheaters a full list of all popular and unpopular names, and they can counter-bid any name they wish.

1 Like