Hey all, I haven't been able to make the past few hangouts and couldn't find any transcript of the September 25th one. So, here you go; lightly edited for clarity. Non-bytemaster content slightly more heavily edited. []'s indicate editor notes.
Fuzzy: Intro
Bytemaster: It's been another week; another significant step forward in the life of BitShares 2.0 as we march towards releasing on October 13th. For those of you who were here last week we just started a new, and hopefully final, testnet. I'd like to report on how that testnet has gone this week.
So far we have 33 witnesses who have been voted in and we have a total of 100% witness participation, which is actually better than the current BitShares network which has 96% participation. I'd like to thank all of you testers out there who have helped set up nodes. These are 33 unique servers that have managed to stay in sync, despite all the spamming and even attempts at double signing blocks were done this week – just trying to mess the network up. We survived the double block signing without a single missed block. With all the fixes that we put in last week we were able to boost the transaction throughput. The testers were able to achieve several blocks with a couple hundred transactions in them. These are three second blocks. We're doing really well as far as throughput goes, far more than a real network will ever need to process in the short-term. I am very happy with the results of this test network and am feeling very good about upgrading on October 13th. If any of you had doubts due to bugs or the problems we've had with the networking code in the past month, those issues appear to have been resolved. We have a relatively stable blockchain, at least as stable as BitShares [0.9.3]. My full witness nodes have basically been running on their own without issue for some days now. The general takeaway from all of this is we're on track for October 13th, the network is extremely stable and that leaves the long pole[?] in the
tent: the user interface.
I'd like to give some updates on the user interface. We have a full node downloadable GUI that some of you were able to test. It hasn't been updated with all the changes since earlier in the week but we have the build process and infrastructure in place [such] that we will be putting out another release of a full node graphical wallet that seems to work pretty well. We also are planning a light wallet that you can download that's similar to the full node but instead of connecting to a local witness, it connects to a remote witness. That's sort of an Electrum model. The [light wallet] uses the exact same interface as the website and the full node. One interface, three different ways that you can use it with different levels of security consideration.
Fuzzy: The question I would ask, if you don't mind, for the downloadable light-client: what's the downside to that in terms of security? This seems like a common concern.
Bytemaster: From a security point of view, you are not fetching new, mutable JavaScript from a remote server. That's the biggest improvement to security of the light-node. You're still trusting the server to accurately report the state of the blockchain to you. The worst it could do is lie to you, but there's actually no incentive for them to lie. You can use the exact same server as the hosted wallet or whatnot. Even if they did lie to you it's entirely possible to construct transactions that go to who you want them to go to or no one else. It's really just a matter of whether or not you trust a remote node. You can pick and choose different remote nodes for use with your wallet and that will give you the middle-ground. If you don't trust anyone and want to run your own node, that's the most trustworthy [and secure]. Allowing someone else to run the node and you just run your own GUI, that's the middle ground. Using a hosted wallet is the least secure option [requiring the most trust of third parties,] but it's not so bad assuming the server doesn't get hacked and its JavaScript changed to try to steal keys. If the server were hacked you're only vulnerable if you visit the server and log in while it's compromised. Only active users during the time of the attack are [vulnerable]. {Sound cuts out here.} Of the three, I'd say your biggest risk with using a hosted web wallet is that if you clear your browser cache your wallet gets deleted. If you don't have a backup of your wallet and you clear your cache you're SOL, [shit out of luck]. That's one of the big motivators for having the light version and the full desktop version. To make sure that you can clear your bowser cache without risking your wallet. It seems there are a lot of people who recommended clearing the browser cache suggesting everything will be fine. This isn't safe if you have $100,000 worth of BitShares floating around in your wallet. It'd be a very sad day.
Fuzzy: When you first set up your wallet and it asks if you want a BitShares brainkey, say yes, write it down, don't lose it, make a copy of it.
Bytemaster: Technically yes. Although brainkeys aren't able to recover all the keys your wallet might have in it. If you import keys to a wallet from BitShares 0.9.3 or you change your brainkey – you might have more than one brainkey over time – we've concluded that a brainkey is not a general purpose approach. It only works for the basic case where you have a new account and you never change your brainkey and you never import keys. We didn't want to design a user interface around that assumption. It's not a safe assumption. We want it to be safe for all users. We will have a brainkey and you'll be able to write it down and [using it] you'll be able to recover keys. But that's not going to part of the regular work-flow. It's going to be more like a condensed, future-proof backup. All new keys that you generate in your wallet will be derived from the brainkey. Which means your existing backups are good and if you have your brainkey then you can recover those keys. The process that we've set up will require you to save a file and keep that file secure and backed-up. We're working on coming up with more automated backup solutions but for now, it'll be your responsibility to backup your wallet and all your keys to a file on disk so it can be imported later. Do not rely on your browser cache.
Fuzzy: Joey asks: "Would there be a code or paper wallet functionality that could help with that problem that you can foresee?"
Bytemaster: Older paper wallet functionality is just a matter of generating a public key and private key offline and transferring the public key to a wallet. If you configure the permissions on an account to a public key where the private key is kept cold, never has been on a [ed. networked] computer, then you have cold storage. We don't have any tools in place to generate those keys easily for you. You'd have to use one of the command-line tools offline.
Fuzzy: But they are available for somebody who wants to do that?
Bytemaster: It's easy to create the tools [ed. probably just simple wrappers around already existing API calls,] we just haven't prioritized it.
Bytemaster: Othername asks, "Why doesn't remembering your password for the web wallet suffice in case the cache is deleted?" The reason is the password never goes to the server and the server doesn't store your wallet. Your wallet is also kept locally [in the browser cache] and you're never authenticated to the server.
Future versions of the web wallet might have server-side storage and backup of your wallet file for you. In which case your wallet file would be stored on the server encrypted, meaning the server can't read your keys and they never get your password. They can give you your [wallet] file back to you thus you can restore from the server. This would be a good way to move [wallets] between devices automatically, though it would require server-side infrastructure and we haven't been focused on server-side infrastructure at this point in time.
Othername[?]: Isn't such a web wallet, where if you deleted your cache all your funds are gone, a potential source of bad PR? Might a solution be to just release a local light-client [and full-client]?
Bytemaster: Yes, there's risk there associated with that particular issue. It's not really a problem once you've done a backup. Then you don't have to worry about your cache being cleared anymore. The benefits of the hosted wallet are that you get free, automatic upgrades as we improve things. Whereas you have to download new versions of the other wallets each time. Adding server-side storage to make the hosted-wallet as reliable as possible, to allow it to function even if you clear your cache, is a desired feature for the future.
Othername[?]: DataSecurityNode just mentioned, "What about an initial forced backup?"
Bytemaster: Our plan is to have a notification on the user-interface that indicates if a backup is required and how long it's been since you last backed-up. It's not there now but we've been engineering the data tracking into the wallet. So we can display a big red warning with a button to backup now. On every page. Until you do it.
Fuzzy: Every user should be backing things up and we should have an easy process for them to do it.
Someone: We're going to want to educate people about this. Eventually it'll be taught in schools, "You've got to be responsible and that means backing-up your cryptocurrency files."
Bytemaster: I think in the future, when cryptocurrency is successful, it's all going to be managed automatically behind the scenes. You'll be able to recover your password and your cryptocurrency funds with similar difficulty to resetting your password on an existing banking system. Regular people out there are not going to magically change and learn how to do all this stuff. We're still at the early-adopter phase. During the early-adopter phase, yes, we can expect people to learn that stuff. Long-term all of the stuff's going to have to be managed because the risk of a hard-disk failure, network failure, forgetting your password is too great.
It's a greater security risk with cryptocurrency than exists in the current banking system. The probability of you losing your money in the bank is far less than the probability of losing your money with cryptocurrency even though, technically, someone can steal your money or freeze your accounts, but guess what? You forget your password, you lose your wallet, your computer
dies: all those things can cause you to lose your funds. The only difference with cryptocurrency is that it's somewhat in your control whereas with the banking system it's not in your control. For the average person out there, their ability to control and be responsible actually means that a cryptocurrency is less secure for them, because they're not able to be responsible. We need to create products and services that cause the average person – who knows themselves well enough to know that they're going to forget their password, they're going to do something stupid with their computer, they're going to misplace their backup – [to be confident that their funds will be safe.] Very smart people make those types of mistakes and need those types of services. People don't want to think about their money. They just want it to be there and they want to use it and they want to know that they can always get to it. We need to migrate to systems that are that easy to use, that easy to recover, that automatic. Where you're never at risk of getting locked out of your account. I think most people would choose to have the risk of their funds being stolen over the risk of being locked out for doing something stupid.
Fuzzy: I've noticed there are a lot of users who are starting to come in who have been BitShares users for some time but have had trouble with the current wallet. Some have asked, "How do I protect my backup? Is there a best-practice?"
Bytemaster: I've seen lot's of people ask those types of questions regarding wallet backups and transition [to 2.0]. There was a new release [on the] 0.9.3 [branch/series] this past week. I apologize for the botched [initial] release, I uploaded the wrong file and some people got a old, old 0.4 version. So 0.9.3c is out. It has an updated backup function that exports to a format that's compatible with Graphene and BitShares 2.0. You don't have to do anything with your existing wallet until you want to migrate. When you migrate you need to download and install 0.9.3[c], load up your wallet, export it to a file on disk and then load that file into Graphene/BitShares 2.0. There will be a button and instructions for how to load that file. Once you do that all your funds will show up in your BitShares 2.0 account.
Someone: In 0.9.3 is the exporting just through the GUI export function or does it require the command line?
Bytemaster: I updated the menu in the menubar to use the new version.
I'd like to switch gears and start talking about some of the raging debates. It started with last Friday's mumble session when we talked about how much pay a witness should receive. We then went into a broader discussion about how many witnesses we should have. This then broke into several different
categories: how much is necessary from a technical perspective? How much is necessary from a marketing perspective? Those were some very lively discussions. I want to thank everyone who was on the forum and participating in those discussions. I would like to address some related things today, simply because it's good to think about these things. It's good to double check that we're not losing perspective on what our risks are, what we're trying to defend, why we're doing what we are doing
I set out to build free market solutions for securing life, liberty and property because I want freedom. BitShares is a tool that allows us to get freedom. The question
is: does it serve these needs? Is it robust against the types of attacks it will face? There are many different types of defense mechanisms out there. Each defense mechanism is good against a different type of attack and has different types of problems. In nature, [for example,] you can have really thick armour or be really fast and agile or you can camouflage. Three different strategies that are employed to secure oneself against an adversary. The adversary that blockchains are typically concerned about is [at worst] a government adversary. This is an adversary that is big, strong, has almost unlimited funding and, more-or-less, controls the infrastructure upon which all of society is built. That is a pretty tough adversary to design a system to be robust against.
When we're talking about witnesses it's kind of like talking about how much difficulty one needs in a proof of work algorithm before it's secure? Do we need to increase the difficulty 10x before Bitcoin is finally secure? How much does it cost to attack the network? In the old days, with just proof of work, people thought, "Well, eventually, proof-of-work will get so difficult that not even the government will be able to do more work than everyone else." I hope everyone here has seen that that's very short-sighted. If you build a reinforced steel wall and you have it right next to an unlocked door, people aren't going to bother going through the steel, they'll use the door.
That gets us to the point of identifying the weakest point. You don't need to build a wall that is significantly stronger than your door or your window because the adversary is going to attack you at your weakest point. Any money you spend making the walls stronger [without also securing the weaker links] buys you very little security. If we're going to go up against an adversary that likes to control everything in our lives, [especially] our financial lives, and we want to maintain our financial freedom, then we need to have security that's based on something really difficult for the government to attack. That means, most-likely, the security is not coming from technology. It's entirely too easy to filter packets, it's entirely too easy to target hosted-wallet providers, public seed nodes; all those things provide redundancy against technical failure or against nuclear war and all the things the internet was designed to provide redundancy against, but the security doesn't come from how many block producers you have. How many people that actually sign the blocks. That doesn't give you much actual security at all. You could have one person do all the block signing and you could still have a blockchain that is resistant to double spend attacks and is immutable and can't change. The reason you have more than one person signing blocks is to avoid censorship and to have a little bit of redundancy in case that person gets taken down. Your funds are secure so long as there is a public record and the copy is widely distributed to as many people as possible. It doesn't matter if theoretically the witnesses could create an alternative set of blocks. Everyone out there already knows what they have already seen and the weak subjectivity that Vitalik [of Ethereum –
https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/] talked about is a major part in the security of these systems.
If you want a system to actually be secure, the only thing that protects you is lacking the political will to attack you. To make attacking your system politically difficult. Because if you can get political support behind it then you're safe, even right out in public. If widespread public opinion turns against you, it doesn't matter if you're a country with nuclear weapons. The government's going to invade and take you down. It doesn't matter who you are or what kind of defenses you have. If public opinion turns against you, the powers that be will take it down.
A fundamental right that we all have is free speech. To the extent that we can make all this stuff about free speech and anti-censorship, the fact that the message being communicated is, "transfer funds to someone", you're allowed to say that and everyone is allowed to hear it and everyone is allowed to change their actions based upon what they heard. Doing things that keep the system pure and honest and convey a sense of goodness, so that the average person says, "How dare you attack that little kid? That innocent person?" Those are the things that secure a system against being taken down by the government. It's for the general public to see the system, see that it's good, not harming anyone and that it's something that they want to use. And [we need to] make attacking any individuals within the system seem like a bully picking on a little kid. That is ultimately the only defense any technology has against the mob. The governments and the media, they are tuned to manipulate the mob. It is the mob, through their passive consent, that allows governments to get away with genocide. If we want to design systems it needs to be something that's difficult to turn the mob against. The best way to do that is to make it so that the mob depends on and loves your system. It's difficult for the government to shut down twitter or Facebook or the Internet, because everyone has come to love and depend on [such services] and cutting [users] off of those technologies would cause riots in the streets. Therefore the political cost of attacking those [services] is too high. That's how it has to be for all decentralized systems.
There is a threshold where if you make it easy for them to shut you down – you know, they raid your office and now you're offline – they're probably just going to do it. So you need to make it just difficult enough that it's kind of like pirated music. They can try but a new site will pop up. Once they realize that it's going to be whack-a-mole, they stop trying. Or once they realize that you just moved to another country and host all your servers in a jurisdiction that's friendly, then they give up. From a technological perspective, we need to be decentralized enough that it is statistically unlikely for over half the nodes to fail at the same time. We need a system that is robust enough that if that statistically unlikely event happened the downtime should be as short as possible.
Let's say that the government-arranged for a simultaneous raid of all witnesses and shut down all block production. Your funds aren't lost. Everyone still knows what the public record was. Interested parties, stakeholders, already know people in the community and already have a mechanism to broadcast transactions and do voting. All it takes is for someone in the community to stand up and say, "Alright, here's the new chain. Picking up right where we left off. Go." Total downtime is less than the typical bank holiday. If we try to design a system that is free from any and all downtime that's probably over-designing it. We just need the probability of downtime to be in the .01% [range]. Our ability to recover is robust. People are used to the banks being closed every weekend. I think that this desire to over-engineer to the point of perfection, where that last .01% of security consumes the vast majority of the cost. That's what we need to be careful [about] and observe.