Bitcoin Rhodium Dev Log #1

baff5b
xRhodium
5 min readJun 2, 2019

--

This is the first in a series of articles pacing the development of Bitcoin Rhodium. Being a still very new coin, the issues we have reflect its infancy: building network effects, improving weaknesses to support mining adoption, etc.

The source code release opened up opportunities for mining pool adoption that we had to work with. This work is still in progress. Various pool operators jumped in and are now increasing their contribution. We are seeing now the mining network finally being decentralized away from poolcore.bitcoinrh.org, which is a big plus as more people adopt Bitcoin Rhodium. The cost-to-price difference remains competitive despite price falls and the hash rate remains high. Fixing the network hashrate calculation issue was also due and now we are getting a real picture of the network contribution: it remains consistently high, which is a confirmation of sorts of our progress.

As you might imagine, supporting a coin on in a small team is a feat with whatever time commitments we all have. We are still sitting on a number of other “coin development” issues: getting fully recognized by CMC, more decent exchanges, etc. It has pulled all of us into different directions. However, even focusing on the roadmap, we are pulling through:

  1. Getting all the information about the coin supply for CoinMarketCap has been an ongoing issue and very important, given how CMC has become extremely important in the market,
  2. Always searching for new exchange opportunities
  3. Getting a clean new website up to improve our look and message,
  4. The new ambassador program was formalized with people joining in,
  5. On the tech side, the new version of Electrum-XRC with Trezor support looks very good across multiple platforms. It hasn’t been the highest priority at this point to release, but I have used the new version a lot and it is looking good. Expect also speed bumps, particularly for encrypted wallets with lots of transactions, since it is based on 3.3.4 of Electrum.
  6. “Private” transactions has been mentioned in the roadmap, but as the prior article has suggested, it is an open topic. The next part of this article discusses just that.

This is just a small sample of the stuff we are doing right now.

Privacy in Bitcoin Rhodium

“Privacy” on a blockchain is a feature that people apparently want, but it seems like a big catch-all expression for a variety of features that cover one or multiple aspects like balance retrieval and making payments. There is a lot more that goes into “privacy” than hiding balances on a blockchain. The subject here is part of a bigger discussion on data privacy: privacy in what you are sending, how you are sending it, what data you are retrieving, who is keeping a log on your inquiries, who gets to see the final results and so on.

To be honest, it helps that all users learn what they can do if they require a level of privacy further than the default. They can learn to use Tor, for example. But, there are some things that an “expert” can drive forward.

When I try to think about what I am trying to solve, I try to pose it in terms of a problem and then a type of user who can benefit from the problem. Let’s pose this as a simple user story as to what a “private transaction” could mean:

  1. As a user, I want to hide or obfuscate my balances in some sufficient manner so no one can discover my full balance or associate prior transactions to my current balance,
  2. As a user, I want to transact without revealing the destination of payments, so that I can be assured that who I am paying or why I am paying for something is not identified easily.

Keeping these in mind, Bitcoin Rhodium is a scarcity coin with anonymous dividend program that relies on blockchain data to send correct payments to. This is the primary value proposition.

I can’t see how we can offer both MW/CT level privacy and the dividend option when we base our pay-out decision on current balances, without altering the rules around the program. Also, integrating MW/CT is non-trivial.

I am trying to take a user-oriented perspective here. Most of XRC’s community are not technical and are here primarily to invest. My goal is to make this simple to get started for users, but there is a path we have follow and requires effort, similar to what was already pushed on Bitcoin.

I started to look at lightweight solutions. They don’t solve the privacy problem completely, but are a part of a bigger effort. What caught my interest was the ideas in Samourai Wallet:

  1. STONEWALL, which is based on BIP 126, is a non-collaborative pseudo-CoinJoin that depends on a rich UTXO set for a wallet to build CoinJoin-like transactions,
  2. Ricochet, which allows a single payment to go through many transactions over multiple blocks to hide payment intent at a slightly higher cost.
  3. Boltzmann scores: measuring “transaction entropy”; that is, seeing how connected addresses are. This tooling is useful for testing purposes.

I think these are interesting, but we need to put effort into “shaping” the chain for our purpose. The first two solutions are not final answers; I am not sure yet if they accomplish the type of expectations I have. But, we have to start somewhere, which is more important than having nothing to work with.

So I feel at this point, there are some real things to do:

  1. Start with small samples on testnet. Technically competent members of the community can participate also when the appropriate functions are ready.
  2. Demonstrate an increase in transaction anonymity using boltzmann and make reports on how this worked out.
  3. If positive, move to mainnet and execute the same functions with real XRC.
  4. When proven, implement the correct functions into the official wallets. Release the semi-CoinJoin Kraken and see things work :)
  5. Move on to the next feature. We will have to because we are still in a situation where our new transaction type could have inputs that can be viewed as “being from the same owner” by virtue of the fact that this is the only thing deployed.

This approach is better than including the kitchen sink of privacy functions. There could be other things to add, for example, an Electrum server behind Tor. But, we have to take baby steps on this.

(On the Bitcoin Wiki, there is a new, very long article on Bitcoin privacy which can apply to Bitcoin Rhodium: https://en.bitcoin.it/Privacy. I say “can apply” because Bitcoin has a much larger reach and network effect, so things might apply less to BTR as this point. However, everything in the article is good to consider.)

Was this interesting/useful/completely wrong? Contact me on Discord: https://discord.gg/WmxceSm.

If you want to donate to me for the work I am doing and also learn to use a privacy-preserving Bitcoin wallet that implements payment codes, then please send to my PayNym via Samourai: https://paynym.is/+roundscene490. In Samourai, you send to my PayNym name instead of an address. Payment codes are something I’d like to have for the official XRC wallets.

Out on the interwebs: https://www.bitcoinrh.org
Follow the team here on Medium: https://medium.com/@BitCoinRh
Follow Bitcoin Rhodium on Twitter: https://twitter.com/BitCoinRh
Join the discussion on Telegram: https://t.me/BitcoinRhodium_BTR

--

--