One open issue we still have (and must be settled before we move on) is with regards to how Bitcoin should work.

(Note that we are discussing the concept of Bitcoin within both games; it may be presented differently, for instance as Hexcoin. See #5).

This is sort of a continuation of the previous discussion at Phabricator.

Some stuff I think we should aim to:

• Users cannot change wallet "password" (private key), but they can create a new one. So users can have multiple addresses.
• BTC transactions are public, with an in-game system similar to blockchain.info
• BTC transactions are anonymous.

Traceable Cash-out

Here's an idea:

• Players can trade BTC <-> in-game $.
• This trade is traceable, specially cash-out (BTC->$). Reasons:
  • It's how real life works (cashing out BTC is hard).
  • It is an incentive (or barrier) to keep players using two different monetary systems at the same time. Each with their own strategy/pros/cons.
  • If someone steals my wallet and I'm utterly mad at the attacker, I can stalk their wallet relentlessly until they cash out (might never do).
  • It brings even more strategic and exciting dynamics into the game.

Mind you, a player need not cash-out her money. As outlined in the Phabricator discussion, BTC buys almost everything (but not everything because balance).

Tracing a transaction would mean:

1. Hack the local BTC Market used for cash-out
2. Recover the relevant log

Protecting yourself from traces would be the opposite:

1. Hack the local BTC Market
2. Forge the log with fake information (optional)
3. Hide the log

Trace would lead to the user's IP, which could be bounced, so it's yet another protection layer for anonymity.

Local BTC market ensures we do not have overly centralized servers like we do on Legacy.

Protecting and Stealing Bitcoin

On Legacy, the only way to steal (and protect) Bitcoin is to keep an eye on the logs. We can't use this same logic on HE1/HE2 because Logs work in a different way (all of them are recoverable).

On HE1/HE2, BTC transactions are logged, but only the public address. This gives a way to "attack" BTC anonymity (and defending from this is also easy, it's a matter of forging logs and misguiding attackers). Possession of the Public address does not allow attackers to crack and figure out what the private key is.

In order to perform any BTC transaction (send BTC to another address; buy something with BTC; cash-out), the Wallet must be "readable", i.e. accessible from the user's filesystem. So the best way to protect the Wallet is to keep it on an external HD / pen drive, which you plug only during transactions, and removes later. To avoid abuse, there's a minimum time in which the drive must be plugged (say, 10 min), which exposes the user to wallet theft. If the wallet is encrypted/hidden, it must be decrypted/un-hid.

I know this makes BTC theft harder than usual, but the alternatives are flawed. Storing Private Key on logs make it extremely easy to steal. Simply encrypting and hiding it is also too easy. Any attacker can un-hide, decrypt and download the file, very quickly.

Wallet Size

To be honest, there is one alternative that could balance BTC theft, and that's been suggested on the previous discussion: wallet size. Decrypting and un-hiding a wallet could be fast (depending on software), but downloading it would be quite slow. Still, I believe a well-equipped attacker could do all of this within 1 hour. Even if victim's firewall detect the attack and notify her, it's still too easy to catch someone off-guard (offline).

Using external disks, BTC theft is already hard, and further hardening it with large wallets isn't good for balance. So unless we have a different idea, I think BTC wallets should be kept small so all an attacker needs to do is to spot the plugged-in drive.

Maybe vpn's could be added, such as a vpn virus that you can upload to a machine you hacked, and ip's in logs point to the machine you hacked.
There could also be a paid vpn service?
To balance out, maybe the vpn virus should only work while the machine with the virus on is online.

Sorry if this was already being planned.

Just a fun idea discussed in the development discord, perhaps they could lead to actual NPCs in the game, too.
Terrible hand-crafted example included:

(.pdn for if someone wants to make it better:
downloadextraramcom.zip

Two very basic things:

1. Add a CONTRIBUTING.md file with information on how to contribute (or include the information in the readme).
2. Add more labels so we can better categorize suggestions and filter them when searching for specific ones.

I was the one who suggested replacing Bitcoin with the fictional "HexCoin". The few design documents on the topic on github only refer to a fictionalized Bitcoin.

Is there no possibility of using HexCoin? If there is, was it simply a design decision? If HexCoin is legally impossible, may I suggest "HexBucks", "HexCash", "HexCheck", "HexChip", "HexCred", "HexFund", "HexGold", "HexMint", "HexPay", or to have a currency named "HEX" which stands for "Hub-based EXchange" or "Handshake EXchange"? The last two would be a stand-in for cryptocurrencies, a fully digital currency which works (in-universe) in a much different way than Bitcoin and Altcoins, but serves the needed purpose in HE2.

I can see why HEReborn would keep Bitcoin, seeing as the original game used it and HEReborn is a remake. However, I feel that HE2 is more like a "reboot" of the original than a remake, and a thematically appropriate currency with a name such as "HexCoin" or similar would make the game feel more... immersive? ...if the currency is not a fake and thus incompatible version of a real cryptocurrency.

I always wanted to add DNS and domain name to the game, but I've been postponing these features as they weren't "essential", in any way, to the base game. As it turns out, a very simple DNS implementation is required for the base version. Let me explain why:

• Our game design is geographically distributed, and this is one of the pillars for balance. It avoids overly concentrated areas/servers, like we've seen in Legacy.

• As such, HE1 and HE2 NPCs like Banks, Police Dept, BTC Market, City Hall, Chamber of Commerce etc. are distributed across several physical regions, based on (player) population density.

Let's use Banks as an example. Player A, located in Europe, may access his bank using IP X. Player B, located in Australia, may access his bank using IP Y. Both banks are the same, but those are different terminals/ATMs.

Suppose player A accesses ip Y (located in Australia), but instead wants to use her local bank. She'd have to memorize IP X (or lookup on Finances app, which would lead to memorization). That's where DNS shines: just access bank.com and you have direct access to your local bank IP. I could also access bank.com/branch/australia/sydney-1 instead, to have direct access to IP Y.

World's Simplest Introduction to DNS

DNS maps a domain name to an IP address. That's it. But obviously, that's not it.

DNS Unicast

Unicast DNS maps exactly one domain to one IP. Always.

DNS Anycast

Anycast DNS allows multiple IP addresses to answer for the same domain. The benefit it brings is that the nearest server will answer first, much faster than others.

DNS in the game

First and most importantly, players don't need to know anything about DNS. That's totally transparent to them.

DNS have one major reason to exist: it's hard to memorize IPs. It's much easier to type google.com than 172.217.29.206. For HE1/2, there's another reason: resolving to the local NPC, automatically.

The bank example nails it:

• bank.com will always resolve to the nearest ATM to the connection's Exit Node (which is not necessarily the Player's location). That's Anycast.
• bank.com/branch/brazil/sao-carlos-1 will always resolve to branch brazil/sao-carlos-1. That's Unicast.

In real life, the two examples above would be answered by the same DNS server, as the path (/branch/...) doesn't matter for DNS resolution. Helix, however, consider the full path, which makes implementation a lot easier.

Under the hood, our servers calculate the nearest bank.com server to the Player's location using GIS algorithms.

Other examples:

• wop.com/local resolves to nearest WOP station, while wop.com resolves to global WOP database.
• new-york.us or sao-paulo.br resolves to the relevant city WHOIS (with information about Police Dept, News, City Hall, Chamber of Commerce etc).

Custom domain names

We'll have domain name support, so players can register their own domain. myclan.com or username.com. All player- and clan-powered DNS/domains are Unicast.

But... not now. We'll consider implementing custom domain names only after the game has been marked as Stable/1.0 (2018+).

Reverse DNS & browser behavior

We'll have an in-game system similar to reverse DNS (rDNS). It's mostly used on Browsers.

When player accesses an IP in the browser, if there is a reverse DNS, the relevant Unicast domain will be showed alongside the IP. It's informative, so the player knows there's an easier way to access this site.
When browsing a website with its domain, the browser will always show the corresponding IP as well.

Logs

At least initially, logs will only store IP addresses. In the future, storing both IP and domain, like a.b.c.d (bank.com/branch/fr/paris-1), seems a nice improvement.

Protocol

In real life, we use the HTTP(S) protocol to browse the Web. For HE2, I'd like to have in-game websites using a fake protocol like he2(s):// or hex(s)://, for two reasons:

1. It avoids confusion; it makes crystal clear that the website is not real
2. It enables us to serve real sites within the game. The next step is playing HE1 inside HE2. (Obviously this still have to be widely discussed and planned. Lots of potential security problems).

I had a ton of ideas for corporations to appear in auto-generated missions on the old Phabricator. I'll be putting them here once I've edited the list for generally improvements.

The purpose of this task is to figure out how to achieve objectives described on the statement page.