As we discussed elsewhere in more detail, my current take is YOLO-allowing doesn’t actually do harm as long as the spec is clear about how people should handle their tokens downstream.
Yeah I think so long as we are “strict” about it in that we only allow TXOs that parse correctly and are “legal” in some abstract sense (correct capability byte, <= 40 byte commitment, amount >0 if pure fungible, etc), then I think that’s “safe” in a way. Just have to be careful when summing up category ID’s to catch overflow (but that’s an implementation detail for nodes)… sure. Wouldn’t be catastrophic.
And I predict the following: not a single TXO will be intentionally mined in this way. I would be surprised if more than a handful… or even more than 0 will appear between now and activation time. So long as we are very clear in the spec how to handle this, there is little incentive for “griefers” to do this to us.
If we don’t anticipate it happening, and we have bugs in our code… then yes, griefers may do this to us. But just having a plan for this I think is enough to avoid potential attacks from BCH haters…
Another thing we should probably add to the spec: A special rule for coinbase txns.
I propose the following consensus rule post-activation:
A coinbase txn should not be allowed to generate any vouts with PREFIX_TOKEN.
This would avoid the situation where miners can endlessly mint for CategoryID 0x0000000000000000000000000000000000000000000000000000000000000000 which would be both fairly useless and also annoying.
It is implicitly disallowed because coinbase inputs have prevout index 0xFFFFFFFF, but we only consider inputs with prevout index 0 as genesis candidates. Jason has this line:
Note: coinbase transactions have only one input with an outpoint index of 4294967295 , so they must never include a token prefix in any output."
Agreed, it should be explicitly stated it’s disallowed.
Oh yeah duh… coinbase has prevoutN == 0xffffffff and so it can never be genesis.
So yeah – it can’t be genesis. But definitely think it should be explicitly stated that coinbase txn blanket forbidden to have token PFX_BYTE in its outs at byte position zero – as a blanket thing to explicitly point out…
Notably, the CHIP now includes ~3,500 full-transaction test vectors validating all aspects of the upgrade; these should make developing and validating new implementations much easier.
First CashTokens testnet
The first public CashTokens testnet has been very successful – a test activation occurred on Sun Sep 04 2022 00:06:40 UTC, forking from testnet4. Since then, thousands of test transactions have been successfully created and mined.
Thank you to @cculianu for spearheading BCHN’s CashTokens implementation and preparing a testnet release, and thank you to @im_uname for helping to start and maintain this testnet.
We’ll continue operating this testnet until the next coordinated activation test in mid October. To connect a BCHN node:
(Optional) If you have a testnet4 node running already, you can copy the whole data directory (e.g. name the copy ctnet). To run simultaneously with testnet4, you’ll need to update your configuration with alternative ports, e.g. bitcoin.conf:
Be sure to open/forward the port on your router or firewall so other nodes can connect to you.
Run the CashTokens-enabled BCHN client using this iteration’s activation time: -upgrade9activationtime=1662250000 (that is Sun Sep 04 2022 00:06:40 UTC)
Using RPC or the debug UI window, force your node to follow this testnet fork: first invalidateblock 00000000df3ee02e8912e2fd1205ed9366ea74bdaebf207b5e02601589de82d4, then: reconsiderblock 00000000a27de85e9f7799175aa1adb5df4095d1a277299135a479caf2bd40e9. If you’re still having trouble connecting, try manually adding a peer: t4fork.c3-soft.com:28333 or testnet4.imaginary.cash:28333.
If you want to join a mining pool, @cculianu’s node (t4fork.c3-soft.com) is accepting non-standard transactions, stratum server at: t4fork.c3-soft.com:3333.
Work on higher-level token standards
I’ve started another topic for discussion of higher-level, application-specific token standards:
I’ll be focusing on these higher-level token standards throughout this month.
Next CashTokens testnet
We will reset the CashTokens Testnet by testing another activation on testnet4 in mid October. The goal is to have as many node implementations and software teams participate as possible.
I’ll share the updated connection information here soon, but we’re tentatively targeting an activation time of 1666094400 – Tuesday, October 18, 2022 at 12 UTC.
Stakeholder review
The CHIP is nearing a final draft, and we have several implementations and a public testnet.
Following the CHIP process, I’ll be collecting reviews and feedback from stakeholders over the next month. The goal is to reach near-unanimous approval from all stakeholders, so I’ll work with the other contributors to address any outstanding concerns we identify during this process.
If we can demonstrate widespread approval across the Bitcoin Cash ecosystem, all stakeholders will consider the CHIP “locked-in” for the May 2023 upgrade.
Creating “chipnet”
Staging “locked-in” CHIPs on a long-running testnet could allow for more thorough testing, improve business certainty around upgrades, and even allow for May product launches following upgrades. (More discussion in this topic: Staging CHIPs on Testnet.)
So: the plan is to fork from testnet4 on November 15th at 12 UTC as part of “lock-in day”. We’re tentatively calling the new network chipnet, and the goal is to activate CHIPs on chipnet exactly 6 months before they activate on mainnet.
If chipnet proves valuable this year, it may be an ideal network for the ecosystem to coalesce around for upgrade staging and product testing.
Discussion & feedback
Reviews and feedback are deeply appreciated, either here or in the CHIP issue tracker. You can also join the discussion in CashToken Devs on Telegram.
I have two questions about the two new Token-Aware CashAddress types. My assumption, which may be incorrect, is that pure BCH transactions can occur with the new CashAddress types:
Will an observer of the BCH blockchain data be able to distinguish non-token BCH transactions sent to these addresses from current CashAddress transactions (either in an obvious or subtle way)?
The CHIP says, “Token-aware wallet software – wallet software which supports management of tokens – should use these CashAddress version byte values in newly created addresses.” Does this mean that wallet developers who want users to be able to use CashTokens are expected/encouraged to set all receiving addresses to the new CashAddress versions regardless of whether a particular transaction will involve CashTokens?
I am asking these questions because I want to know the possible impact on transaction uniformity, fungibility, and privacy outside of the CashToken ecosystem.
No – the addresses encode the exact same information, the only difference is a single bit that indicates whether or not the receiver “understands” tokens. In fact, you can’t be confident that the receiving address understands tokens even if it receives them – it could be token spam designed to throw off chain analysis. So information is only leaked when the receiver spends tokens.
As written, that’s the recommendation, but we’re considering removing that sentence: it’s only a sensible recommendation for token-only applications. (E.g. the receiver wants some amount of a stablecoin, but the user has a non-token-aware wallet. If the receiver uses an address recognized by the wallet, the user may be confused into sending the equivalent stablecoin value in BCH rather than the requested token; creating more work for both parties in correcting the situation.) I’ll reference this post in the issue, thanks!
I’ll never rewrite any of the git history (so commit hashes won’t change either), but I agree that it’s nice to have tags as a sort of documentation. Makes it easy to click through to specific versions in many git interfaces.
(More discussion in this topic: 