Bitcoin Contract Protocol
The Bitcoin Contract Protocol(BCP) is a simple protocol that simulates smart contracts on Bitcoin layer 1. It uses a JSON structure and contains five parts.
{"p":"bcp","ca":"1XX","sub":"Coinmap","pt":{"op":"deploy","tick":"ordi"},"sig":"XXX"}
The value of p is always “bcp”, ca(contract address) is a legacy btc address, sub is the name of a sub-protocol under BCP, pt (plaintext) represents the information to be encrypted/signed, and sig is the signature of pt using the private key corresponding to ca.BCP mainly adds two pieces of information, namely, the Contract Address and the signature.
Users can interact with CA through a website/Bot to generate consensus info. The consensus info is stored in pt. BCP uses the private key of CA to perform asymmetric encryption or signing, and then the user inscribes the JSON on btc network, so that all can verify the consensus message.
Three Principles of BCP
Principle 1: Correct and First.
Usually, there is a “First is First” rule when deploying/minting tokens/NFTs in the Bitcoin ecosystem. Because of the introduction of CA and signatures, BCP is only valid for the first inscription with a correct signature.
Principle 2: One address, one contract.
Only the first BCP deployment on an address is valid. BTW: BCP uses legacy btc addresses as CAs.
Principle 3: More Freedom.
There is no restriction on the tick name and tick length, and there can be tokens with the same name, which are distinguished by CAs. BTW: Tick names are case-insensitive.
Sub-protocols can be designed under the BCP protocol, which increases the flexibility and playability of the protocol even more.
Plaintext Processing Rule
BCP's Plaintext uses a hash structure, and in order to ensure uniqueness a series of rules must be adopted.
Pt is a single-level hash that cannot be nested. Pt is compact with no unnecessary spaces. All keys in pt are treated as lowercase and sorted in ascending order. Tick values are uniformly converted to lowercase.
Coinmap Sub-protocol
Coinmap is the first application of BCP. Coinmaps are maps for FTs/NFTs in BTC ecosystem. A Coinmap has 21,000 cells(100*210), as BTC FTs are usually integer multiples of 21,000. For example, the famous BRC20 ORDI has 21,000,000 tokens with 1,000(max limit) multiples of 21,000 ideal mints. It can also be 10,000(100*100), usually the amt of an NFT Collection.
BCP20 Sub-Protocol
All-in-one minting can drastically reduce gas fees. This approach can also be used for FT token issuance. We plan to launch BCP20 sub-protocol in due course, unlike all current FTs on btc chain, this sub-protocol will use All-in-one minting, which will drastically reduce the gas consumption at the time of minting, lowering the gas price and avoiding network congestion. The protocol could use transfer methods similar to BRC20 or runes. We prefer a runes-like transfer method combined with our unique all-in-one minting. We also note the recent cat20 protocol, which is unique in that its token balance information is not associated with multiple utxo's of the user, but rather is stored in a token account. The cat20 protocol is currently unavailable to the bitcoin network due to the absence of OP_CAT, while its transaction size is too large and consume too much gas. We will synthesize the strengths of several protocols to design our BCP20 protocol.
All-in-one Minting, High-dimension Minting and Visualized Minting
When you mint tokens of brc-20 or runes, if you want 1000 mints you have to mint 1000 times. These tedious and repeated mints are called 0-dimension minting. In contrast, Coinmap proposes a new way called All-in-one minting. First, you select a start point in the Coinmap, then you set the width and height of your mints. If width*height equals 1000, you have a 2-dimesion mint which matches 1000 times traditional mints.
A website as the service provider offers visualized minting to users. In addition to all-in-one minting, it offers many helpful services such as order locking, inventory checking. The services will significantly reduce the number of mints and high gas fees, avoiding the waste of UTXOs and also avoiding tons of invalid mints in so-called fair launches.
Service Fee
Fair launch has been a cultural phenomenon in the crypto world and especially the Bitcoin ecosystem. It is a systematic revolt against the darkness of traditional VC finance and is generally encouraging. But it also has its share of problems such as proton attacks, sky-high GAS fees, huge amounts of over-limit invalid mints. In Fair launch, only miners can get the revenue, which will not be conducive to the development of the project and the healthy development of the ecosystem.
Through all-in-one minting and other order and inventory management services, BCPs like Coinmap can provide users with significant Gas savings. In this way, Coinmap-like protocols deserve charging appropriate service fees. BCP is actually a better Fair launch.
Coinmap's current rate is, 6$/0-d-mint.
We would like to establish an industry practice, through a protocol similar to Coinmap. For example, the total number of mints is set to 21,000, and depending on the project, each mint is charged 1-20$, which can provide the project with a revenue ranging from 21000-420,000$. Of course, this is a preliminary initiative and will be modified according to the situation.
Duck Test of BCP
The structure of BCP is very simple, some people may think it is not a genuine smart contract. But according to the Duck Test, if it walks like a duck and quacks like a duck, it's a duck. BCP has a contract address, BCP has a signature that verifies the consensus, and the consensus can be permanently inscribed on the btc blockchain. What’s more, BCP is able to issue tokens on demand like an erc-20 contact does instead of the current quantized 0-dimension minting in brc-20 and runes. This is a real smart contract for users, who don't care about those annoying technical details.
BCP Advantages
1. Saving GAS,
2. Reducing UTXOs waste,
3. Avoiding invalid mints,
4. Ticker freedom,
5. Better security against Bots,
6. Appropriate revenue for developers, good for ecosystem.
Examples of BCP Inscriptions
{
"p":"bcp",
"ca":"1CogXXX",
"sub":"coinmap",
"pt":{
"op":"deploy",
"tick":"ordi",
"width":"210",
"height":"100",
"base":"100",
"origin":"bottom-left",
"start":"0"
},
"sig":"XXXX"
}
Notes:This is the deployment of a Coinmap named “ordi”.
The ordi Coinmap is 100*210, which has 21000 grids.
The orgin of the map is at the bottom-left.
The 21000 grids are numbered and serialized in a base of 100.
“Start is 0” means the ordinal number of the first grid is 0.
For more details, visit https://Coinmap.click.
{
"p":"bcp",
"ca":"1CogXXX",
"sub":"coinmap",
"pt":{
"op":"mint",
"start":"100",
"width":"20",
"height":"50",
"target":"bc1xxxx",
"deadline":850412,
"tick":"ordi"
},
"sig":"XXXX"
}
Notes:1. Target is the owner address of this inscription.
2. Deadline is the deadline block which you should mint before.
Deadline = JSON generated block + delay
Currently, delay is set to 1000 blocks, so you can choose a low gas block to mint in about a week delay. Delay may vary, so notice the exact number of deadline.