hpr-knowledge-base/hpr_transcripts/hpr2857.txt

Episode: 2857
Title: HPR2857: Creating CounterParty Collectible Tokens for the Bitcorn Game
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr2857/hpr2857.mp3
Transcribed: 2025-10-24 12:16:30

---

This is HPR Episode 2857 entitled Creating Counterparticleectable Tokens for the Bitcoin Game.
It is the first show my new host might be Mike, and is about 17 minutes long, and Karim
a clean flag.
The summary is how to create Bitcoin Collectibles, Tokens issued on Bitcoin blockchain, used in
Bitcoin Farms Game.
This episode of HPR is brought to you by archive.org.
Arch-Universal Access to All Knowledge by heading over to archive.org forward-slash-donate.
Hi everyone, it might be Mike here.
Today I'm going to walk you through counter-party assets, creating them, trading them, buying
them, selling them, and specifically we're going to walk through creating a collectible
card and token combination for the game called Bitcorms.
So let's get started.
First of all, counter-party is a meta-protocol because it's built on top of the Bitcoin protocol.
What that means is the key counter-party transactions, like creating a counter-party token or asset,
trading it, selling it.
These are recorded on the Bitcoin blockchain.
This lens stability and security to the protocol.
Other things are not.
For example, counter-party has a built-in DEX decentralized exchange.
Now, first of all, this is a bit of a misnomer.
Decentralized exchanges are not really, are they?
A better term for these is probably no escrow exchanges.
So I don't need to go fund an account somewhere and let them actually own my tokens.
And this particular DEX is built right into counter-party.
First of all, Bitcoin transactions have the ability to embed a small amount of arbitrary data in them.
In particular, there's one field called OPRE-TURN that currently supports embedding up to 80 bytes of arbitrary data.
Now, a protocol built on top of Bitcoin, by definition, Bitcoin is not going to recognize what that data is.
So an application operating at that higher level of abstraction, a counter-party aware application,
is going to recognize this data signifies the creation of an asset or a send or something like that.
So just to brief bit of history, counter-party protocol was kind of patterned after MasterCoin protocol.
It was created back in 2014 by a group of guys.
Principally, Adam Krillinstein and Robbie Dermity created this.
And it's a collection of Python scripts that enable all the basic asset creation, trading, listing,
and the exchange and the placing of buy-and-sell orders and more of the features like betting and so on.
There's also a database there that holds the information that is not embedded into Bitcoin transactions.
Really don't want to have every single event and action be a Bitcoin transaction.
This is one of the real pain points with a lot of Ethereum dApps, for example.
For blockchain-based games, there seems to be a trend away from the old web strategies,
which means that we see all the program logic and data and configuration all on chain.
Doesn't seem to make sense since every node needs to execute that logic and store that data in perpetuity, which costs money.
So the trend has been to push that off onto side chains or use highly performant, very centralized block chains to do that.
And I don't think that makes sense because you're trying to get away from the very efficient, very centralized systems that work so well in the traditional world.
I'm just replacing it with less efficient, less secure, less well-known, and understood ways.
So a traditional centralized system with a database and a server works very, very well.
There are reasons to keep some asset information on chain.
The example that's always trotted out is if I want to buy an in-game asset.
And if there were the kind of ubiquitous standards where all game makers would in some fashion
recognize and support that asset in their game, that would make a lot of sense.
I could pay a lot of money for an asset and reuse it across many games.
But I think that requires many similar types of games that are developed using similar types of platforms and aren't too compelling to use.
But we'll see where that goes. It's an interesting thing.
Bitcoin was deliberately built not to have enough storage space to put programming logic and data on chain.
So counter-party really encourages a more pragmatic approach in my view.
And that's what we'll see in Bitcoins when we take a look at that in a minute, if I can stay focused here and stay on track.
If you've created ERC tokens before, that's the token standard, our set of standards on Ethereum.
You know that essentially you deploy a smart contract and it keeps track of ownership of the tokens inside the smart contract.
There's a hash basically with addresses and account balances.
And in counter-party, there is a database that keeps track of all that and you can query it through RPC.
There are APIs available.
So I might as well go into explaining a little bit about wallets now.
We need all this background so we can walk through the process of creating an asset.
A counter-party wallet is essentially a Bitcoin wallet with some added functionality to recognize counter-party assets.
So a counter-party asset lives at a Bitcoin address.
And in fact, when you create it or transfer it, you're going to need a little bit of Bitcoin.
Because that transaction needs to get recorded on the Bitcoin blockchain,
so you need to pay a minor fee for that transaction to get included in a block.
Now, counter-party has a native token, it's called XCP.
And all assets created on this are generally traded and bought and sold for XCP.
You could say that counter-party tokens are denominated in XCP.
They are traded for other things.
You can trade them directly one for another.
There are games and collections that have their own native tokens, so to speak,
where their currency examples of this are Pepe Cash for Rare Pepe's,
BitCorns for the BitCorns game.
There's Mafia Cash for Mafia Wars.
But at the end of the day, you can buy and sell and trade all of these for XCP, the native token.
And I call it a native token and it has utility because when you create an asset,
in some cases, you're going to need to pay XCP to create that asset too.
We'll get into that in a minute.
But to do so, you're going to need to have a wallet set up first.
So let's go there.
There is the reference client.
The original web-based wallet created by the counter-party founders.
You can find this at counter-wallet.io.
Now, this is a web-based wallet as so many of these are.
And I think a word of caution is in order here.
You don't want to use a variety of different web-based wallets all the time
because you're going to be sending your credentials to all of these websites
on a regular basis.
That's a bad idea because you're trusting a variety of websites with your credentials
and you're quite often transmitting them to the various websites.
And this kind of gets at the very nature of one of the main drawbacks of this system.
People build collections of assets and have some XCP tokens to use
and a little bit of Bitcoin to do transactions with.
All at the same Bitcoin address, which is very public and known to anybody that trades with you,
as opposed to the best practices for holding and trading and buying and selling Bitcoin,
which is to never reuse addresses.
Leaving that aside, though, at this Bitcoin address, you will want to have a little bit of Bitcoin
enough to pay the minor fees for the transactions as you create by and sell tokens.
Now, you're also going to want to get a little of the native token XCP.
And once you have those two things, you're ready to go.
I'll just walk through the example in the reference wallet, but it's similar in other wallets.
Now, in the reference client, you'll notice just to the right of your Bitcoin address,
there's a little blue menu and one of the choices on there is create token.
When you create a token here, it's much simpler than, say, creating a token on Ethereum
or on a similar blockchain.
In those cases, you need to deploy a smart contract that defines the properties and features of your token.
But in practice, almost every token needs the same sort of properties and features,
especially these collections of related assets, games based around collectibles.
There are exceptions, of course, where you want your own logic that's a little bit different.
And for those, something like Ethereum is a great platform with the ERC721 standard, for example.
But in most cases, as I say, just need a basic set of parameters to create a fully compliant token
whose properties are known and well understood by the other clients that are out there.
So in this case, a templated approach makes sense.
There are two types of assets you can create, named assets, and I suppose unnamed assets.
The unnamed assets are free to create in terms of XCP.
You still need a mine or a fee to get that creation event in a transaction included by a minor in a block on the Bitcoin blockchain.
There's an interesting new project called Freeport that lets you create unnamed assets for free, basically.
That is to say, only the Bitcoin mine or a fee is needed to create the asset.
Check it out.
It's right now a Chrome plugin and a Firefox plugin is in the works coming soon.
It may even be out by the time you've listened to this.
Now for a named asset, and what I mean by that is you've selected a name that you want.
You will need to pay one half of an XCP token.
This is hardwired into the protocol from the beginning and how much money that costs varies depending on the price of XCP.
So you either go with the free asset creation, which is going to have a name beginning with an A and then a string of numbers,
or you give it a custom name.
A custom name can be up to 12 characters.
I find this a bit limiting, but it's a vestige left over from the early days when Bitcoin's opt-return only held 40 bytes of data instead of 80.
So pick a name for your new asset and pick an amount to issue.
Now there's a couple things to say about the amount to issue.
First of all, you could just issue a billion or you could issue one if you want it to be unique.
The next thing to say about them is there are a couple little properties you'll see in the form,
no matter which client you're using.
One is locking.
If you lock the issuance, however many tokens you issue, that's it.
Can't be changed later.
If you don't lock the asset, you can go back at any time and issue more of these.
That does affect the price, of course, if this is something that's going to be in any way rare or value.
Another property you'll notice on there is divisibility.
So just like Bitcoin itself, this token can be divisible.
You can send someone 0.000001 of a token.
And there's nothing wrong with this.
But for collections of collectible assets, you notice I keep bringing that up.
It doesn't really make sense to have an asset and send somebody a small fraction of that asset.
If you have a collectible card in a game, you want to send somebody a whole number of cards.
One card or five cards, not 0.000003 cards.
OK, so another thing you'll notice there is there's an optional description field.
This could be a short text description of the asset.
It is changeable later.
So you don't have to make up your mind.
You can initially leave it blank, fill it in later, change it later.
One common thing to do, however, is to use this field to put a URL in that points to a JSON file describing the asset.
The reason you might want to do this is to provide more context.
These assets are often issued associated to an image or other media.
Big shout out to DJJ Skrilla, who pioneered the use of associating a token, a card, image to audio files.
Your new token that you create could be associated to an image of a card of video or audio file or anything else.
And you can define this relationship in depth in a JSON file that's pointed to.
Another common use of the description field is to provide a hash.
Now without going too deep, of course, those of you that know the basics of cryptography know that a hash provides integrity.
So what this really means is, let's say I create a token and it's associated to an image of a collectible card.
I want to assure people that by and trade these tokens, that the image has not changed since it was issued.
The way that I can do this is the original image is hashed and the hash is embedded in the original description.
I said earlier that the description can be changed after the fact, but the old description is still exists in the counterparty database and can be looked up.
So in that way, it can provide integrity for the original media that's associated to the token.
Got it? Let's create that token. Now what you're going to want to do is buy and sell that token later.
Now the Bitcoin's game, this was invented by Droplister.
It's an idle farming game based around a counterparty token called Bitcoin.
Owning another counterparty token called Crops gives you a farm.
That farm is your Bitcoin address.
So using his application that he's built, this is a web-based game.
So you go to the website, you will see your farm along with other assets that are part of the game.
These other assets are counterparty tokens, of course, and they have card images.
Now there's a standard for these, there's a template used to help you create these.
And the way you do it is go read the instructions on bicorns.com, download the template, create your artwork,
create the token as we just walk through doing, and submit it for approval.
And if it gets approved, it'll become one of the official game cards of Bicorns.
So now that we've gone through all of that, let me finally tell you how to play the game.
All you have to do is nothing.
Seriously, this is a four-year game.
So when your own crops tokens, you own a farm automatically.
And on that farm, you have farm art, you have a generic picture at first, you can upload your own.
And you'll want to pick a location on the map, you can pick anywhere in the world.
Middle of the ocean is fine.
You can name your farm, I suggest that you do.
And all the collectible cards that you buy will show up on your farm page.
And that's all you have to do.
Once every quarter, there's a harvest of free bicorns, proportional to the amount of crops that you have.
This is a great game, a lot of fun to play.
Check out bicorns.com and feel free to check out the Telegram channel.
If you're having any trouble creating assets and you want help,
or if you're just having trouble figuring out what to do and how to create these assets,
feel free to reach out.
There's a sort of a scholarship that was set up by one guy called Bench
that will actually pay your way to creating your first asset.
We'll give you a little bit of Bitcoin to pay the minors fee,
a little bit of XCP to pay the asset creation fee,
and the bicorns needed to submit your card to be accepted by the Bitcoin Foundation
and publish as an official card in the game.
So reach out to Bench if you can't find him, a droplister or myself,
might be Mike.
And come play bicorns, you're going to like it.
Tell him you heard about the game from Hacker Public Radio
and we'll give you some free cards.
This is might be Mike, take care.
You've been listening to Hacker Public Radio at Hacker Public Radio.org.
We are a community podcast network that releases shows every weekday, Monday through Friday.
Today's show, like all our shows, was contributed by an HPR listener like yourself.
If you ever thought of recording a podcast,
then click on our contribute link to find out how easy it really is.
Hacker Public Radio was founded by the Digital Dove Pound
and the Infonomicon Computer Club,
and is part of the binary revolution at binrev.com.
If you have comments on today's show,
please email the host directly, leave a comment on the website
or record a follow-up episode yourself.
Unless otherwise stated, today's show is released on the
Creative Commons, Attribution, ShareLife, 3.0 license.