5 posts tagged with "xx chain"

• The problem
  • Did you know...
• The Mission in xx Network era 1107
• Rewards
  • Rewards for participating validators
  • Rewards for Space chat participants (non-validators welcome!)
• Rules
  • Rules and crieteria for participating validators
    • Criteria for validators
  • Rules for non-validating chat participants
• Payouts
• Technical tips
  • How to find IP address for the validator?
  • How to block and unblock an IP address?
  • How to sign your wallet address?
  • What happens to my validator if I participate?
• Questions and answers about the game
  • What happens if the target changes their IP address?
  • How can I time the firewall rule to begin or end just before or after the era?
  • How does the nominator compensation work?
  • What is the expected outcome
  • Is denying IPv4 access the best way
• Sample game workflow for validators
• Hop on the chat to get started

The problem​

xx Network has a small, but growing number of nodes owned by centralized entities ("pools"). As far as I can tell most Substrate-based chains do.

I happen to care about xx Network and I don't think we should have anyone control more nodes than the current cMixx round size (which is five).

There are variuos measures the xx Network Council has initiated to protect enhance decentralization, but as a demonstration of a working decentralized approach I'm willing to spend some of my XX coins to make a point.

Did you know...​

This is only loosely related, but: did you know that Polkadot has a community event called "The Spammering" that is about to happen?

The Spammening, Polkadot’s ultimate stress test!

Polkadot is about to be put to the test as we push it to its limits in real-time. Get ready to witness the network’s resilience and scalability under extreme load as we #RekTheMeter!

This game can be thought of as a watered-down version of xx Network spammering (and in the opposite direction).

The Mission in xx Network era 1107​

Your mission is to block an IPv4 address of a cMix ID node (the cMix ID) during the game era ("the era", which is 1107).

That IPv4 address will belong to a pool node identified by the cMix ID.

The cMix ID will be shared 3-4 hours before the era begins so that you have time to find and block the IP (which takes mere seconds - see below).

Rewards​

Rewards for participating validators​

You will get over 100% of your normal validator reward if you successfully complete the mission. Those who partially (>50% failure rate) succeed will also get rewarded, but less.

Assumption:

• You make 40 XX in most recent era directly preceding the game era(s) (era 1106)
  • Assumption: node earnings 182 XX x 22% (maximum validator commission acceptable for this game)

Examples of earnings for two outcomes with rewards:

• Validator successfully fails 100% of cMixx rounds with the target during the game
  • Due to these failures you make 30 XX in the era (lose 10 XX, (40 - 30)). I will compensate you for the 10 XX
  • You will receive a separate bonus of 100% of your earnings from the previous era (40 XX * 100%)
  • My net payment to your address: 50 XX
• Validator fails between 50%+1 and less than 100% of the rounds shared with the target
  • Due to less failures than the more successful players, drop in earnings is maybe just 5 XX (40-35)
  • I will compensate you for the 5 XX and pay 40% of the earnings from previous era: (40 - 35) + (40 x 40%)
  • My net payment to your address: 21 XX
• Validator participates but is incompetent and doesnt' hit > 50% failure rate
  • They may lose 2-3 XX ("small success") or nothing (ineffective application of firewall rules)
  • They get no compensation and no reward, so if you can't take the risk just join the chat
  • I may compensate their nominators depending on the type and extent of screw-up (stupid screwups - no compensation)
    • Example of a stupid scrweup: you block IP address of the cMixx permissioning server instead of the cMixx ID you're supposed to

Separately, I will compensate all of your nominators for the difference (drop) in rewards for the era compared to the previous era.

Additional rewards may be dispensed depending on effectiveness of the game and if less than 10 validators participate in era 1107, the game will continue into era 1108 and I may increase rewards for the remaining slots in era 1108.

If five or more validators hit 100% failure rate with the target(s), I may give additional rewards to those five validators. I may also lower the criteria for above rewards if the target makes frequent changes to the IP address that make achieving these objectives hard.

Please check the rules and qualifying criteria.

Rewards for Space chat participants (non-validators welcome!)​

Contributing and silent observers are welcome to join the Space. Those disapproving of the game will be permanently blocked from the Space.

A reward of 30 XX will be given to most valuable chat participant in the Space based on quality of their feedback related to this game. Both validators and non-validators qualify and validators don't need to meet any additional criteria besides their validator application.

This will be evaluated between UTC 4:03am before the era until the end of the era (27 hour period). The number of messages sent must be more than one, but whether it's 2 or 20 will not influence the odds of getting this reward. Quality first, engagement second.

Please make sure to check the rules and requirements below.

Rules​

This is a bit complex, but it has to be because participants can apply and not participate. I could use multi-sig and a trusted co-signer to get minimum deposits for no-show participants, but this is easier.

Rules and crieteria for participating validators​

I have to share wallet addresses because everyone must be able to verify that all applicants are qualified. That's why I cannot accept applications via DM.

• First 10 qualified participants who apply will be accepted
  • If you see more than 10 submissions maybe it's not too late to apply - you may want to check those wallet addresses to see if the applicants qualify. If they obviously don't, submit your
  • As I check each application, I will comment and approve or reject until 10 have been approved or the era begins (whichever comes sooner)
• Objections regarding qualifications can be shared in the Space
• You may DM me with private questions
• No applicants details from DM will be shared or retained by me (whether or not you're accepted)
  • Note the xx Haven Space is public, so if you join the Space others will be able to see your Haven ID
    • You may join the Haven Space using a disposable Haven ID, submit your application, then leave the Space and optionally rejoin with a different Haven ID to monitor updates.

Criteria for validators​

The first 10 people who post their signed wallet addresses and meet the following criteria:

• Active validator in the era directly preceding "the era" (of the game)
• 22% or lower commission the era prior to, and during, the game
• At least 15K XX validator stake on the node in the game era (if you don't have now, you can bond before the era and unbond later)
• Not a pool wallet. Wallets from pool nodes or obvious node farmers with 5 or more nodes will not be accepted
• No nodes with recent history of > 25% commission as per xx Network Wallet (validator commission chart in the official wallet - see this example of a qualified node in terms of validator's commission history)

Note that some delays may happen in posting how many people have qualified.

Expected Haven message format for validator submission:

VALIDATOR
Address: <address>
Signature: <walletSignature>

See technical tips on how to do this.

Rules for non-validating chat participants​

Soft requirement: sign a XX wallet using the same wallet address.

• Those without a signed wallet may be blocked at my discretion
• Those without a signed wallet won't qualify for chat rewards (because I wouldn't be able to pay them)

Expected Haven message format for validator submission:

CHAT
Address: <address>
Signature: <walletSignature>

See technical tips on how to do this.

Payouts​

The payout will happen within three eras after the game era. Why so long?

Because I need to check thousands of rounds of the target node and make sure that participating validators have not participated in any of the successful ones. That will take time.

I plan to write a script that checks all rounds or (worst case) manually check a sufficiently big ample of the target's successful rounds and verify that each participant's node has failed more than 50% or all 100% of them in during the era.

Chat rewards will be dispensed promptly.

Technical tips​

How to find IP address for the validator?​

Search the cMixx log for cMix ID 0wjnYzegPz42ZZVc_dpB0RMRfddbEbdy_AkmsBbyrdMC or its substring:

cat /opt/xxnetwork/log/cmix.log | grep "Disconnected from 0wjnYzegPz42ZZVc"

If you can't find it, ask for help in the Space.

How to block and unblock an IP address?​

sudo ufw deny from <ip address>

How to sign your wallet address?​

Look at the screenshot or see this example.

• Validators: sign your node's validator's (not controller's) wallet address. From that I can see your cMixx ID for the game era, and check if meet the qualifying criteria. Validators are automatically qualified for chat rewards
• Non-validating chat participants: sign any wallet address (to which you hope to receive chat reward) using the same wallet

Based on the output in the screenshot above, the validator would paste this into the Haven Space:

VALIDATOR
Address: 6aCE19CakDJBp8wnVHB2HpHYfaeNiwx2RxQcsAcyWvPLVn5k
Signature: 0x9071685d1321e337a7e5b6bcecba433dc75ed18e5ac6e867fccb18ad2c1c31427757d241d021b6b8bcb5450472d65abb0ab5a261c4cfcd013ef089bd791a588a

Chat participants would just replace VALIDATOR with CHAT - the rest would be the same.

What happens to my validator if I participate?​

Rounds in which the blocked IP participates would fail due to pre-comp timeout. Other rounds will work fine.

If your node was to fail 20% of the rounds, you'd make close to 20% less, i.e. your validator earnings would drop by almost 20% of your commission (assuming your commission is 22% that would be 22% - (20% x 22%) or a drop of less than 5 XX).

Your nominators will be similarly impacted, but they'll be fully compensated as I've explained above.

Questions and answers about the game​

What happens if the target changes their IP address?​

There are several potential targets, so they're unlikely to watch our Space and change IP address before or during our little game. If they do, though, let's consider some scenarios:

• the target changes their IP address before beginning of the era: nothing changes for us. You may want to delete the outdated firewall rule and create a new one, and still earn partial rewards even if you do that hours into the game era - you just need to fail more than 50% of common rounds shared with the target
• the target changes their IP address after beginning of the game era: my reward criteria will likely be loosened, but you can still modify your firewall rules to make more
  • if they change the node IP eight hours into an era and you update your rule 10 hours into an era, you can still meet the objective for more than 50% of the rounds and get the second tier reward
  • if they change several times during the game era (which I can check in my own logs), rewards will be prorated for the longest stretch (e.g. 6 hours) between two changes will be considered. In that case your node would make normal earnings for 24-6 hours (as blocking would fail), and I'd pay out a quarter (6/24 hours) of rewards. For six hours of successful blocking on a node that made 50 XX in that era, I'd reward you 50 x (1/4) x 100% (12.5 XX) if all of your rounds shared with the target during those six hours failed

In any case, you and your nominators won't make less in the era unless you act completely incompetently and mess up your node.

How can I time the firewall rule to begin or end just before or after the era?​

Use the sleep command or use OS scheduler. For example, you can login as root (or a passwordless sudoer) and run the rule delete command after the sleep command.

sudo ufw deny ...        # enable blocking 
sudo ufw list numbered   # note the rule number
su - root                # passwordless suders don't need this
sleep 87000 && ufw delete ... # remove the rule (by the number)

Or simply just login tomorrow and remove the rule any time in the next era.

How does the nominator compensation work?​

In the era before the game, your node earns 190 XX. In the era, if you do well your node will earn less, let's say 160 XX.

I will compensate your nominators for that difference (which would be (190 x 22%) - (160 x 22%)).

I will check every winner's nominators in the game era and send each nominator their ideal share of the loss. For example: if a nominator has 30% of all nominations, they'll get 30% of 6.6 XX (total drop of nominators' earnings after validator's commission is deducted).

What is the expected outcome​

It is to estimate the effect (reward reduction for bad actors and their nominators) and costs (drop in rewards for the rest of us) of a community action like this. It's a special take on Polkadot's spammering, so to speak.

Ideally I'd like the community to be able to hurt pools in a cost-effective fashion.

Alternatively, the network can use formal measures by the Council or democracy vote, but voluntary community action is vastly superior to that approach.

Is denying IPv4 access the best way​

It's not, but it's easiest.

Participants are free to use any way they want to fail rounds with the target.

Sample game workflow for validators​

Sign your validator wallet address using the same address as explained above.

Paste the address and signature into the Haven Space:

VALIDATOR
Address: <yourValidatorWalletAddress>
Signature: <generatedSignature>

I'll review and - at least two hours before start of the era - publish up to 10 accepted participants' addresses and name the target (example: cMix ID 0wjnYzegPz42ZZVc_dpB0RMRfddbEbdy_AkmsBbyrdMC).

Find the IP address:

cat /opt/xxnetwork/log/cmix.log | grep "Disconnected from 0wjnYzegPz42ZZVc"

Let's say this shows you the IP address is 1.2.3.4.

Shortly before the era begins, block the IP and note the UFW rule number:

sudo ufw deny from 1.2.3.4
sudo sudo ufw list numbered

After the era begins, use the xx Network Dashboard to confirm rounds are falling.

You may login or recheck the dashboard during the era to confirm the target is still using the same IP. If not, remove the existing UFW rule and update it to continue blocking.

You can do this to remove the rule in little over 24 hours.

su - root
sleep 87000 && ufw delete <ruleNumber>

Do not log out. If that is not secure, then use screen to issue the command and detach, or create a one-time cronjob.

Or you can login in the next era and remove the rule(s) with sudo ufw delete <ruleNumber>.

Login after the era to confirm the node is no longer blocked in ufw. Or keep them blocked, if you want to help the network.

Hop on the chat to get started​

Join ArmchariAncap Chat Space to ask questions, watch or participate!

• Admin: recruitAnarchicIntent
• ArmchairAncap's wallet used for (outgoing) payments: 6VXfntvzZTzY2YPA4KtSVZMx1YqPFTo7o8qtddNLB4K91Mcn

• Intro
• What matters and what doesn't
• Why care about the Polkadot ecosystem?
• What opportunities are there?
  • xx coin in Substrate walelts
  • Universal Polkadot addresses
  • xx chain can work with many Polkadot projects
• Past and present examples and opportunities
• Take-aways

Ah, look at all the blinded people!
Ah, look at all the blinded people!

Eleanor Rigby wants cMixx used by the banks that have been
Lives in a dream
Dreams about use case which we all know won't get out of the door
Who is it for?

All the blinded people
Where do they all come from?
All the blinded people
Where do they all belong?

Intro​

I'm going to turn a few thoughts into a blog post because it should be on the Internet and stay there for a while. (Ironically, this won't be published soon as I'm still waiting for Github to tell me what I did to have my account suspended - but more on that once I find out!)

Claim: very few xx Network community members realize or highlight opportunities related to the fact that xx Network uses a Substrate-based chain.

According to this article, there's over 300 projects in the Polkadot SDK-based ecosystem.

What matters and what doesn't​

Dr. Chaum and the Team behind xx Network are well aware of the benefits of having a Substrate-based chain, but years after the launch 90% of community members are still mesmerized and distracted by the peripheral stuff.

What's periferal stuff?

It's both old and new things - the BIS/CBDC trials, the Charles Hutchison-Trump administration thing, digital voting in government-organized elections...

Why care about the Polkadot ecosystem?​

The Team of course knows the value of Polkadot ecosystem which is why they picked a Substrate-based chain.

But if one looks at what most people in the community are paying attention to, most don't appear to see it. They're blinded by the seeming ease of scroing bigly, or simply lazy to learn and so they tirelessly look in the wrong places.

Such as? Various quantum computing news, the Charles/Trump thing, rumored crypto payments on X, etc.

It is true that Dr. Chaum himself has participated himself in BIS/CBDC-related research and evaluations, but that's because he should. I wouldn't expect, or want him to build embedded wallets. He is focused on the tech behind cMixx and the best evagelist and promoter we have.

But the opportunities that Polkadot SDK offers to xx Network are many and significant.

• approachable: they're suitable for community and developer engagement. You and that dApp developer you know don't need a PhD in cryptography or deep understanding of the workings of central banks in order to use cMixx and xx Chain to create useful and practical solutions today
• immediate: some of my ideas for dDpps require mere days to develop and launch. I know because I've done some simple ones myself. They don't take quarters to discuss and years to develop, trial and put in production. You don't need to look for "investors" to fund their development. Imagine & implement!
• low-cost: in some cases, 7 engineer days to users and maybe even revenue
• permissionless: these opportunities are real and don't depend on anyone reaching out to Elon or some political figure doing us a favor (or even realizing that it'd be us doing them a favor)

I could go on, but hodlers are doing themselves disservice looking for opportunities in the wrong places.

How hard is it to realize that fiat currencies aren't meant to be transparent, decentralized or private? It seems very. It won't happen.

Yes, cMixx should be trialed with the BIS and central banks. Why?

• to show that it won't happen despite the tech being there. In other words, to expose central banks and governments so that everyone can see that it's not about technical challenges, "the tech not being there" or whatever other excuse they come up with
• to scientifically and practically prove that xx Network can do this for private/permissionless use cases

I'm convinced 95% of people in the xx Network community don't realize or disagree with the above two points. But these are the key points when it comes to choosing where to engage and contribute (especially since most of us neither connected nor qualified to contribute - and no, asking "wen" doesn't count).

If anything, post-quantum mixnets may be implemented by central banks and governments, but in order to hide their own inner workings from taxpayers and public debt investors.

In other words, they may implement them to hide and obfuscate transactions between central banks or between central banks and private banks with whom they do business. It won't be on xx Network or any other public mixnet or chain. Got it?

What opportunities are there?​

I hope I shouldn't need to explain, but given the visual impairedness of many in the community, I'll mention several examples:

• My recent posts on dApps and Hacktoberfest 2024 wins give some concrete examples
• Other opportunities (high-level only, as I may try to realize some of them):
  • Most Substrate-based (aka Polkadot SDK-based) wallets can access xx Chain
  • All xx Chain addressses are valid on almost every Substrate-based chain
  • Almost all Polkadot-related projects could use xx Chain and make use of cMixx (xx Network mixnet service)

I'll explore each of these claims, but feel free to skim through them if you understood what I meant to say.

xx coin in Substrate walelts​

If one has "a" Substrate based wallet, they can likely use it to hold xx coin.

Not a big deal, there are many wallets that work with multiple chains, right?

Yes, but you have to pick a wallet that supports two or more coins that you have which in many cases means some L2 and therefore L1 - often Ethereum, which has been stagnant. Sometimes, if you use two L2s, you may need two Ethereum wallets. Or maybe three if you also use another chain. Oops!

For bitcoiners, it's even worse because there's barely anything going on there in terms of useful decentralized applications. Anyone who uses crypto (rather than keep BTC parked and watch the number go up and down) needs one for Bitcoin and several for useful apps.

In the Polkadot ecosystem, there are many good L1 and L2 chains and apps. You usually need just one wallet to access all your tokens and NFTs.

That makes it easy to own XX token and enables cross-polination across Substrate-based networks.

Universal Polkadot addresses​

That first statement about xx Chain adddresses being the same across all Substrate chains isn't entirely correct as stated above - that was purposedly simplified.

What's valid across most Substrate chains is your regular wallet pass phrase and private key(s). SS58 addresses are different for every chain, but can be derived from the same pass phrase or private key(s).

Why should we care? Because you can have a Substrate wallet that uses a single pass phrase for (probably) any dApp in the Polkadot ecosystem.

An xx Network address looks differently from its Polkadot "representation", but these are - and must be, to prevent confusion and loss - because these are different SS58 networks. That is amazing.

xx chain can work with many Polkadot projects​

Because of the two earlier points, Substrate L1 and L2 chains and apps can be easily interconnected.

What if I use Kusama and need to pay for cMixx "postage" (i.e. "premium" service tier, once xxPostage becomes available)?

I'll need only one wallet, just one pass phrase, KSM (tokens) and the ability to buy and sell XX tokens on a DEX to pay for "postage" on xx Network. cMixx postage hasn't been implemented yet, but the only thing that's missing is the ability to buy/sell XX coin with KSM which is technically possible today (e.g. see Hydration) and only a matter of making a small-to-moderate implementation effort.

What if I use XX token and want to use for some non-zero cost service on one of the many Substrate-based chains?

The same thing - one wallet, one pass phrase, and the ability to buy/sell other Substrate tokens - directly or indirectly (e.g. sell XX token to buy DOT or KSM, then sell DOT or KSM to buy the Substrate L1 token you need).

Until direct or indirect on-Substrate-chain DEXes that support XX token become available, one can still do this by using a DEX outside of the Substrate chain ecosystem, but for that we need a wallet that supports said DEX. At this time the easiest way to buy/sell in either direction would be to use a DEX and Ethereum-based wrapped XX coin. That's not perfectly convenient, but at least it doesn't require much overhead - it takes minutes at most.

For free services on Substrate-based entworks (where there's no need for buying and selling) - you can access them as soon as they're implemented. For example, the token- and asset-gated acces demo app only requires ocassional, potentially one-time transfer or transaction and you're good to go for months if not years. Some don't require any, for example in the case a site lets you access it with any Substrate-based token, as long as the USD equivalent of your balance is more than 10 dollars.

Past and present examples and opportunities​

In addition to the dApps I wrote about recently, I want to highlight one opportunity which I thought was real, and that was to evangelize and popularize the integration with Crust Network, a Substate-based network storage project.

xx Network added a Curst Network files app to the official xx Network wallet, but most people didn't pay attention or didn't want to think about it, so the feature wasn't maintained or improved and now it doesn't work (it appears Crust Network no longer maintains that pallet/API).

Crust Network isn't equally private and post-quantum resistant, but it's convenient and not less private that 99% of other chat apps let you upload "attachments" or inline images.

What if the idea didn't make any sense? Was it practical and usable at all? I've no doubt it was.

• Text - and Crust Network download links - go to cMixx
• Blobs (memes, audio clips, etc) go to Crust Network storage nodes and can be downloaded or shown inline in cMixx chat app

You lose some privacy for such binary data, but that's a low-cost tradeoff. In return we could have had "unlimited" size attachments in cMixx chat apps for 2 years now. But no one showed much interest and we still don't have that feature in Haven today.

While Crust Network is now out of the focus due to low interest, similar opportunities abound so I know what I'll do - I'll be looking at other opportunities in the Polkadot ecosystem because they're approachable, immediate, low-cost and permissionless.

Proxxy is another low-hanging fruit. As a reminder, it proxies chain RPC calls through cMixx, which means once a Substrate-based chain becomes supported by Proxxy, many Substrate chains could be supported within days. xx Network's cMixx mixnet is free to use and there's 300 projects that could add this "enhanced privacy" feature easily. And maybe just four-five wallets would have to be enabled to add this feature to hundreds of Polkadot SDK-based projects, to put it another way and tie with those earlire points mentioned above.

Proxxy originally focused on Ethereum wallets and just like with Crust Network integration, the community thought it's better to focus on those "high-profile" use cases I find unlikely to happen. I think Proxy should focus on Substrate-based chains instead.

Take-aways​

Many dApps from the Polkadot ecosystem could be used directly from xx Chain wallet and many Substrate chains could have a privacy setting that flips their wallet RPC transactions to use cMixx even if they don't pay for it with xx coin. That works today.

The lack of a mobile Haven client - once XX Messenger was discontinued - has been hindering such dApps and integrations, but thanks to one of the winners of Hacktoberfest 2024 now we have a responsive Haven application that works from Android clients. It doesn't work great (it's not power-efficient on mobile - those improvements need to be added), but it works. If your mobile device connects to cMixx periodically - for example to download notifications or batch-upload data - there's no problem to do that on Android today.

If we look in the right places, and those places are not in central banks or governments, opportunities are plenty.

I look forward to seeing - and maybe even creating some related PoCs - some cool Polkadot ecosystem integrations happen in 2025.

• xxblockdumper
• Using with xx chain
• What does this all mean
• Conclusion

xxblockdumper​

xxblockdumper is another nice utility from Rick.

It aims to provide the following features to xx chain users (from current repo description):

• Fetch complete block data from any Substrate-based chain
• Retrieve state data and extrinsics
• Export data to JSON format
• Support for latest or specific block numbers
• Configurable node endpoint
• Built-in retry mechanism with exponential backoff

Using with xx chain​

Download, install, use.

Three comments regarding today's main tree:

• Currently click.echo(f"Debug - Block structure: {json.dumps(block, indent=2)}", err=True) causes SCALE codec malfunction, so I mark it out before installing (this will probably get fixed soon)
• I've updated some packages before installing, including Python Substrate Interface and SCALE codec, but this will probably be updated in main soon
• -n ${BLOCKNUMBER} is optional and None means CURRENT
• You may see this error as well

$ blockdumper -n ws://192.168.1.3:63007

Connecting to node: ws://192.168.1.3:63007
Fetching data for latest
Block hash: 0x610dfaf8cfae9c0cc7478183e490cf38f56c497f48b9dd744b5fec9f20777bde
Error fetching state data: {'code': -32702, 'message': 'Response is too big', 'data': 'Exceeded max limit of 1048576'}

Yeah.

Change your xx chain configuration to allow large responses and restart chain service. Here the maximum response size is upped to 32 MB.

  --rpc-max-response-size 32 \

You need to be careful with this on servers that provide public services - this can get "expensive"!

As you can imagine, Dwellir's public RPC endpoint hasn't made those adjustments for your freeloading convenience.

Full console output:

Fetching data for latest
Block hash: 0x463b0a5145b3a2b5b8d10e5572122a554f0eb9772712a787b4a6ffd2edc1f2a0
Found 150325 storage keys
Fetching state data  [####################################]  100%          
Fetching extrinsics  [####################################]  100%

Output file name is currently hard-coded (block_<number>_<timestamp>.json) because xxblockdumper was created to enable simple DIY auditing of individual blocks.

In my case it was saved to ./dumps/block_15567031_20241110_155449.json.

What does that dump file look like? Like this. 52 MB JSON in this particular case.

{
    "block_data": {
        "block_number": 15567031,
        "block_hash": "0x463b0a5145b3a2b5b8d10e5572122a554f0eb9772712a787b4a6ffd2edc1f2a0",
        "state_root": "0x2218a4590b9906c25b5ad251379db00fcea731450bdc8a1adfebf640d04a41ba",
        "extrinsics_root": "0x47480d63db002bcbbebb44b37077cedc9624949fda470aa3ce72be8de0d306ca",
        "parent_hash": "0xd275c4801726c9ea7f69aea84ccb0d392e0b4dbfbb45dd8d8fa86c62174f0e27"
    },
    "state_data": {
        "0x1809d78346727a0ef58c0fa03bafa3231d885dcfb277f185f2d8e62a5f290c8500899da26b8497b0eaf20675a608ec9d7a7fa0f71648c62291d8ddbfe020a0675a70fe6788aa21d9": "0x04b26ce6317a87d3d9fdebe0362b568803e2057989d2fab2aa958870b57680c3670400000000406489aa040000000000000000000000",
    ...
    }
}

It needs to be further analyzed.

extract.py (currently just a stub in the repo) is to-do item that will contain a specific example for which the utility is being created. It will be executed against the dump file(s) to perform extraction, decoding and reporting.

$ python3 extract.py

What does this all mean​

It means you get detailed chain info off your xx chain server in the convenient JSON format.

It means you can use this for certain things without having a big chain explorer at your disposal.

It means you may not be able to react as quickly as by API-querying an explorer - as you can see, it takes a bit more than 6 seconds to get this stuff out of your RPC endpoint.

If not all data are requested, it may be possible to provide near-real-time watch services (for example), but I haven't verified this - I just imagine if a fraction of data is required, certain queries could be done in seconds.

On a fast server we could run multiple xxblockdumper tasks, but as long as each task takes more than 6 seconds to get data and analyze it, that can't work for near-real-time analytics - for that you'd need a different tool.

If you want to dump details of old block data you'll need to run your node in archive mode and have > 200 GB of disk space to play with. Nodes discard state fairly quickly depending on settings (minutes or hours).

For example, my dump file above contained many entries like these:

"Error fetching storage: 
{
    'code': -32000, 
    'message': 'Client error: UnknownBlock: State already discarded for 0x463b0a5145b3a2b5b8d10e5572122a554f0eb9772712a787b4a6ffd2edc1f2a0'
}"

In order for xxblockdumper to work you need an archive node.

Alternatively, if you look for current or very recent blocks and have a fast system, but state pruning timeout is 256 blocks, so for 1 hour you'd need (60s/6bps)x60 min= 600 at least.

./xxnetwork-chain -h | grep pruning
      --state-pruning <PRUNING_MODE>
          Specify the state pruning mode [default: 256]
      --blocks-pruning <PRUNING_MODE>
          Specify the blocks pruning mode [default: archive-canonical]

--blocks-pruning archive is what will always work, but xx chain node will need hundreds of GBs, possibly on flash media.

Conclusion​

xxblockdumper provides convenience to Python users who want to work with xx chain block data.

There are minor bugs that will be sorted out and then we'll be able to use it to build other tools.

• Intro
• Building blocks
• Building dApps for xx Network
  • Feature-full native chain
  • Native currency
• Use cases for these building blocks
• Is that legal
• Summary

Intro​

As Hacktoberfest 2024 just finished and I've churned out some more or less coherent stuff for it, I want to share a few very short additional notes about it here.

Building blocks​

xx Network has a mixnet (which in turn has an SDK called xxDK) which applications use to work with cMixx.

xx chain is a Polkadot SDK-based (aka Substrate-based) chain which has its own ecosystem, libraries, API.

Applications can use xxDK to send messages on xx Network for free, so there's no need to write to xx chain or own XX coins. It is expected that only power-users may have the need to buy XX coin to pay, which is to say casual use should never require anything but xxDK.

What does that mean for dApp authors? I think that means xx Network is a good platform for messaging dApps.

Building dApps for xx Network​

Usually the fact that xx Network is "bootstrapped" in a blockchain elicits negative comments (see these examples), if any at all.

Most people have no opinion about that, which isn't much better. It's a major difference and has to be considered. If you have good reasons why being blockchain-based is bad, that's fine as well.

I think it has a very positive impact that may not be obvious if you haven't thought about it and all you've heard is "crypto is full of scams".

For example, I happen to think that xx Network (and the Foundation) has a better setup than Signal and their foundation. Let's take a look at some more practical differences between xx Network and chainless apps.

Feature-full native chain​

xx Network is are one of very few networks that provide anonymous messaging and have its own L1 chain to work with.

xx Network has a good (Substrate-based), fast, low-cost chain with plenty of features - from assets to governance - so for many use cases entire apps can be written to it without using anything else.

Most other decentralized private messaging guys have to write dApps for 3rd party chains - which we can do, too - and we do not. More choice.

The PoC code for XX token- and asset-gating of Web sites shows how easy Polkadot-style dApps can work with xx Network - it wasn't too hard to modify the app for xx Network and add asset-gating. It would also be easy to modify that code to use asset-gating on other Substrate-based channels with asset support.

Native currency​

Most other private messaging apps don't have a native currency, so they have to pick a wallet and integrate with another chain.

xxDK dApps can do that as well, but it's simple enough to use xx chain, especially if you need to handle postage that I mentioned earlier - in that case your app may be able to use one wallet and one currency.

Once XX coin gets listed on a DEX, it will be easy to acquire XX coin with any major crypto-currency and use it to pay postage (when it becomes available), so using xxDK from a dApp that defaults to other coins isn't any different from using other similar networks.

Use cases for these building blocks​

I mentioned some of them in the token-gating post, but I'll make one additional example here to illustrate why I worked on those "building blocks" recently - we can put them together to build some simple dApps (or semi-dApps).

• It is easy to download a file, but if you need to do it reasonably privately, you can use Tribler
  • The challenge is getting the link equally (or more) privately
  • Find me in my Haven Space, pay me some coins, and I'll seed the file for you in Tribler (and give you the link). I can automate this completely as I explained in the Hacktoberfest post, or I can make it fully manual (which is necessary for on-demand items), semi-automated, or AI-powered
• If you need even more privacy for downloads, you can park them on S3 and use an asset-gated Web site in the public cloud
• If you need even more privacy, you can run xx Haven container and Web service on Onion network
• If you want to use a Web3 app without using public cloud, you can create an app that uses xxDK for chat and something like Crust Network to share content

With XX chain (or other Substrate-chain) asset-gating we an even serve the same content using different routes (links) for different membership levels all on xx Network.

Is that legal​

Of course, some will inevitably think "crypto is only good for scams and crime".

I wouldn't be posting about this if I couldn't think of a lawful use case.

There are valid use cases for rare or unique data that can't be free (because it may require 100s of GBs in egress bandwidth).

There are dApps that specialize in blobs (Storj, etc.), but there are use cases where data has to be posted on demand.

In other cases you may not want to charge for egress in dApp, so you could use Tribler. Or you may want to speed up seeding in an ad-hoc manner, which is very easy to do in a community-powered way. Put a file on Tribler, share the link in a Haven space and ask everyone to help out:

• no crypto-currency involved
• zero barrier to entry - one free app to install (Tribler), no wallet to create, no DEX/CEX or any registration to use

So, it's not at all true there are no lawful use cases here.

xxNetwork cMixx is used mostly to share links or other metadata that benefits from its PQE and mixnet. It could be used for paid access to low-bandwidth data feeds, but I did not consider such use cases in this post.

Legal uses with P2P payments are also possible. In xx Network validator community there have been multiple occasions where people needed to download a copy of xx Chain faster than xx Chain could download it on its own: if you don't get ready by next validator election deadline you may not get elected and lose 50 XX by not validating, so paying 25 XX to get it faster would have saved validators money.

Storj egress is $0.007/GB, so 200GB is $1.4, and about $0.8 to upload. $2.2 is still very cheap, but with some friction for both sides (Storj account setup, payment, setup).

Haven-Tribler:

If they were Solana validators they would pay with Solana because that's what they already have ready to go. That doesn't change anything.

Summary​

So we have everything you need and there's no need to use any other network, right?

Wrong! I'm not an XX coin maximalist, folks.

I'd never "encourage" you to use or buy XX coin. If you - a user or developer - think that it would help you, use it.

I only want to share why I think xx Network mixnet is quite unique in its approach. It does give you more flexibility and more convenience.

Anyone can build for xxDK and use (or not) whatever crypto currency they like in their dApp. They can also use several - for example:

• some currency which is their first choice
• XX coin for xx Postage
• Crust for blob storage
• Ethereum for ENS (name and reputation)

Any permutation of these will work, and not having any coin will also work (Haven + Tribler, for example).

With just a couple of building blocks we can build reasonably private dApps.

Some other building blocks I'd like to see (not a complete list):

• Reputation (maybe through Ethereum ENS)
• Identity (maybe on Polkadot or Ethereum ENS) for easier
• Blob app integration (add xxDK chat to Crust app, or run Haven + Crust in the same browser tab)

If you have own ideas, check out the xx Foundation Grant program or reach out on X or the XX Discord.

• Tokens, assets, NFTs, WTF
• Token-gated access control
• Asset-gated access control
• Query (check asset balances)
• Buying and selling assets on xx chain
• Dealing with subscription expiration
• Use cases
• Alien assets and NFTs
• Summary

Tokens, assets, NFTs, WTF​

xx Network has its native currency XX coin, assets and NFTs. Unfortunately, XX is referred to as a "token" (not a currency).

Most of the Polkadot SDK-based chains promote NFTs, but xx Network hasn't adopted those - at least not in the official wallet.

But we can issue and use assets, which is a sensitive term (the SEC, etc.) even when used in non-asset contexts like this one.

To me XX coin is a currency, and "assets" are tokens, but this confusing official terminology is something we have to deal with.

Token-gated access control​

I modified a Kusama example for xx Network (xx chain) and made it available here.

It checks the balance on the address in your Polkadot.js wallet and depending on that value it allows you to access the site.

That's great, so all Substrate-based chains can do this and limit access to apps to hodlers or whales, etc. You don't have 100xx in your wallet? Piss off!

But what about them "soulbound tokens"?

That's a different lookup/API, for "assets" rather than "token" balances (for XX).

Asset-gated access control​

We can also limit access to hodlers of certain assets, and by that I mean token-like assets available on xx Network.

In the case you've been so engaged that you missed their existence, you can find them in xx Network Wallet under Network > Assets.

Let's consider two, test (ID: 4) and Intelligence (ID: 42).

We need to know how to query their balance in user's wallet.

For the impatient JS users - find sample JS code in the same repository.

Query (check asset balances)​

It's unbelievable and ludicrous, but it took me many hours to find this info. As if no one needs this stuff.

I find that hard to believe! But look above - after several years of mainnet and there's just half a dozen test-grade assets, so maybe that's true?

Anyway, let's go:

from substrateinterface import SubstrateInterface

substrate = SubstrateInterface(
    url="ws://192.168.1.30:63007"
)

# Asset test
ASSET_ID = 4  # asset ID: test
ACCOUNT = '6Xo3ESdU9nW3iiAk5ZqDA7kKqYJMcJFGiRz91LkoZKvvTjAV' # owner / issuer
account_info = substrate.query(
    module='Assets',
    storage_function='Account',
    params=[ASSET_ID, ACCOUNT],
)

print(f'Balance: {account_info["balance"]}')
# Balance: 100000000000

# Asset Intelligence
ASSET_ID = 42  # asset ID: Intelligence
ACCOUNT = '6ZsMetbm4yoj9JQJdmhn2dKScFNkUnxULXwTBsNpmL1FM3KY' # owner / issuer

account_info = substrate.query(
    module='Assets',
    storage_function='Account',
    params=[ASSET_ID, ACCOUNT],
)

print(f'Balance: {account_info["balance"]}')
# Balance: 42

All right!!! I think this should work for other addresses (not just the owner) but I don't know if any of these owners have sent them to other people.

Hey, that issuance amount of test looks weird - how come there's 100000000000 of 'em when the screenshot says 100?

The reason is assets may have different properties. We can use TFM (where is it?) or try the "create asset" workflow to see what goes in.

So, it appears Intelligence is an integer-based asset, while test has a crapload of decimals.

That's good to know, but it doesn't matter much to us in this particular workflow: we don't need to know how to look up an asset's properties as we usually accept one or more known assets. If you're interested in that, however, find it here - it's api.query.assets.metadata (in JavaScript). Polkadot.js API details related to assets can be found in the repo.

In JS I managed to do this:

import { ApiPromise, WsProvider } from "@polkadot/api";
import type { StorageKey, u32 } from '@polkadot/types';
const assetDetails = await api.query.assets.asset(assetId);
console.table(assetDetails.toHuman());
const assetMetadata = await api.query.assets.metadata(assetId);
console.table(assetMetadata.toHuman());

.. and get this. But these are the details I don't care about much, as I've mentioned.

┌──────────────┬────────────────────────────────────────────────────┐
│   (index)    │                       Values                       │
├──────────────┼────────────────────────────────────────────────────┤
│    owner     │ '6VXfntvzZTzY2YPA4KtSVZMx1YqPFTo7o8qtddNLB4K91Mcn' │
│    issuer    │ '6VXfntvzZTzY2YPA4KtSVZMx1YqPFTo7o8qtddNLB4K91Mcn' │
│    admin     │ '6VXfntvzZTzY2YPA4KtSVZMx1YqPFTo7o8qtddNLB4K91Mcn' │
│   freezer    │ '6VXfntvzZTzY2YPA4KtSVZMx1YqPFTo7o8qtddNLB4K91Mcn' │
│    supply    │                       '102'                        │
│   deposit    │                 '100,000,000,000'                  │
│  minBalance  │                        '1'                         │
│ isSufficient │                       false                        │
│   accounts   │                        '3'                         │
│ sufficients  │                        '0'                         │
│  approvals   │                        '0'                         │
│    status    │                       'Live'                       │
└──────────────┴────────────────────────────────────────────────────┘
┌──────────┬──────────────────┐
│ (index)  │      Values      │
├──────────┼──────────────────┤
│ deposit  │ '18,000,000,000' │
│   name   │      'JUNK'      │
│  symbol  │      'JUNK'      │
│ decimals │       '0'        │
│ isFrozen │      false       │
└──────────┴──────────────────┘

I got lucky with api.query.assets.account(assetId, accountAddress) hours later.

I used the issuing address to mint 1 JUNK to a beneficiary address.

assetId = 5 # Asset: JUNK
accountAddress = '6aCE19CakDJBp8wnVHB2HpHYfaeNiwx2RxQcsAcyWvPLVn5k'
const accountInfo = await api.query.assets.account(assetId, accountAddress);
if (accountInfo.isEmpty) {
  console.log(
    `No balance found for asset ${assetId} and address ${accountAddress}`
  );
} else {
  console.log(
    `Account balance for asset ${assetId} and address ${accountAddress}:`,
    accountInfo.toHuman()
  );
}

Log:

Account balance for asset 5 and address 6aCE19CakDJBp8wnVHB2HpHYfaeNiwx2RxQcsAcyWvPLVn5k:
    { balance: '1', isFrozen: false, reason: 'Consumer', extra: null }

My Github repo contains a working code example. It's poorly written but it works and you may be able to improve on it.

The Wallet has some smart examples in these files, but they're too smart for me - I could't figure out how to use them.

• packages/page-assets/src/Balances/useBalances.ts
• packages/page-assets/src/useAssetIds.ts
• packages/page-assets/src/useAssetInfos.ts

Buying and selling assets on xx chain​

Houston, we have a problem... I'm not sure how to do that.

OTC to the rescue! Create and publish Haven Space address for your OTC store and sell assets there. It sucks, but it can be automated. How?

You can build a bot - I once created a crude one - that reads comments in your channel and sells this stuff.

Price list for your Validator Monthly Intelligence newsletter:

• Basic subscription - 10 XX/mo
• Premium - 100 XX/mo

Buyer says "I've transferred 10 XX (extrinsic hash attached), please credit me 1 Intelligence to this address 6ZLG..":

/buy 1 Intelligence 6VwDT9VMgPrswqtJtqUH4PU7DkcaHggJjyjnkuUZyNA5c5j1 \
    0xaba65810f33f905e2d136e6a12c0a7e4ae7111a4f6c59415ffa83a3d0d7663c0

The bot checks that transaction (everything checks out, 10XX received). It mints 1 Intelligence to 6ZLGrh6Mu7uDioL7bAVS4kTsRSez7w1Lz18fiApUqRHNWnxd and appends an extrinsic hash and timestamp for easier troubleshooting.

/mint 1 6VwDT9VMgPrswqtJtqUH4PU7DkcaHggJjyjnkuUZyNA5c5j1 \
    0xaba65810f33f905e2d136e6a12c0a7e4ae7111a4f6c59415ffa83a3d0d7663c0 {timestamp}

If something fails, Haven keeps data for 21 days so there's enough time to chit-chat in another Space (for human-powered support) where refunds and other issues can be dealt with.

I'm sure there are some edge cases I haven't thought of, but there's no reason why this can't work and there must be some detailed production-worthy examples in other ecosystems.

Anyway, let's move on. As Teddy KGB said, "Pay him... Pay that man his fxxxing money". Or send the man his freaking asset:

from substrateinterface import SubstrateInterface

KEYPAIR = '....'

# Asset: Intelligence
ASSET_ID = 5  
ASSET_QTY = 1
# Subscriber's wallet to use in Polkadot{.js} for authorization
SUBSCRIBER_ID = '6VwDT9VMgPrswqtJtqUH4PU7DkcaHggJjyjnkuUZyNA5c5j1'

call = substrate.compose_call(
    call_module="Assets",
    call_function="transfer",
    call_params={'id': ASSET_ID, 'target': SUBSCRIBER_ID, 'amount': ASSET_QTY}
)

extrinsic = substrate.create_signed_extrinsic(call=call, keypair=KEYPAIR, era={'period': 64})
result = substrate.submit_extrinsic(extrinsic, wait_for_inclusion=True)

I haven't tried this one yet, by the way.

I'm not sure about the difference between minting and transferring - obviously the former increments the issuance while the latter sends existing, but I haven't looked at the minting API in Python yet. I wonder if minting is a term for asset transfer (I hope not, as it implies additional issuance).

Dealing with subscription expiration​

Yes, there are more problems...

Next month that guy will still have his 1 Intelligence. But we need to charge him again. What can we do?

Normally we'd use "Smart Contracts", but we can't (or at least I don't know how to do that on xx chain), so we have to come up with workarounds such as:

• Check for a new token (Intelligence-Jan, Intelligence-Feb) every month (you can pre-release, and not sell, 12 of them at once), or
• Sell 12 month subscriptions and issue a new asset every year , or
• Buy back tokens at a tiny fraction of the original price, or
• Check date of last pay the wallet did as well as the balance (complicated)

Use cases​

Few wallets have good reputation, but there are folks out there who could probably charge for monthly subscription.

• Newsletter (say, monthly validator analysis for stakers/nominators)
• xx chain-related reports (nominator pays 10xx for staking payouts and Web reports/stats, for example)
• Discord bots for asset-gated access to special channels
• Private training/consulting (for Haven admins and users, e.g. 1 unit of an asset buys you 1 minute)
• Classic "soulbound" assets given away for free (no OTC trading necessary)

Managed Haven instance hosting sounds like another possibility, but that idea sucks:

• It requires absolute trust
• Users who access such instances immediately identify themselves by their wallet ID (and xx is not a privacy coin) and maybe IP address, browser fingerprint and more

Alien assets and NFTs​

Polkadot has a rich asset/NFT ecosystem that can do more and even has bridges to other L1 chains (alien NFTs, one might say).

While that's nice, it's more than we need here.

Of course, xx chain could adopt some of those features, but I think it objectively doesn't need them.

Summary​

In xx Network wallet NFTs are there (based on the xxchain code pallet-nfts v4.0.0 is used), but there's no way to issue them from the wallet. You can find the NFT Pallet documentation here, just mind the fact that xx Network Wallet won't let owners see them unless wallet itself gets some upgrades.

As we've seen assets exist, but aren't likely to be used as "assets".

The xx Network community hasn't done much to monetize Web (or should I say "Web3" to highlight my "DeFi" prowess) access.

One of the reasons is surely lack of examples and documentation, and another is a small market size.

With XX coin-gated and NFT-gated apps (based on xx "assets"), that is easy to do now. Get the code here.

Market for xx chain-related token- and NFT-gated services (based on xx chain "assets") is still small, but it does exist. Anyone who builds something and makes it available for others, lowers the entry barrier for more xx Network services. Let us hope such services emerge in coming months.