Hey all, here's a summary of the October 9th hangout with Bytemaster. A different format than last time, even more my interpretation of things. Still, I think I get across pretty much everything. All text is Bytemaster summarized unless prefixed by "Q:".

Also, I have a request: if any of my past transcript of sep 25th or summary of oct 2nd (check 'em out if you haven't!) have been helpful to you, feel free to throw some spare brownie.pts or bts my way: tiau or thisisausername on BitShares 2.0. So far I haven't made anything, not even what I would've had I not missed two hangouts.



BitShares Dev Hangout: Bytemaster – October 9, 2015 Quick Summary

Testnet has run for a week, survived flooding, stayed generally in sync.  100 TPS achieved; 1000 TPS could be done, but would more likely be an attack at this point. This parameter will be mutable. Found and fixed a number of issues along the way this week.  Tuesday launch schedule is a go.

Subtle issues fixed this week: Non-deterministic behavior in iterating over accounts (hash lookup non-deterministic, switched to ordered indexes instead of hash indexes - slower but deterministic) can switch back in the future. Didn't require a hardfork for this fix. Finding these types of bugs is a good sign.

Fixed some free memory reading bugs. Nothing big enough to cause a hardfork.

Exponential decay of bugs found; thus, at this point, bugs are to be expected. Bug-free can only be achieved by massive testing that requires release. Release must also be 'good enough'.

Major bugs have all been fixed. Polish type bugs being found now. Potential rounding errors could be found. Order of magnitude more confidence in BitShares 2.0 than 1. Funds will be safe if private keys are safe. Bugs can be fixed - very unlikely for account balance affecting bug.

Q: Hardfork bugs v. others?

Non-hardfork: Anything in the UI (most issues are here, at the moment)
Hardfork: Changes the behavior of something the witnesses did in the past, changes the validity of future transactions

Fork: Change in the the interpretation of the history of events. Some changes restrict things, things that were possible in the past are no longer possible.  For example, if non-deterministic behavior were found we'd have to define that non-determinsitic behavior as the expected behavior.

Another type of hardfork: allowing something in the future that wasn't allowed in the past. In this case just need to have all witnesses update in time.

Unplanned hardfork: All witnesses running the same code, but code isn't deterministic. Eventually some transaction is allowed that shouldn't be (valid for some, but no others;) chain splits.

Unplanned hardforks are the most dangerous. Bitcoin 2013 blocksize bug was like this.

Bitcoin took a couple hours to find (few people managed double spend,) multiple chains for a bit.

BitShares has Last Irreversible Block: last block confirmed by 2/3rds of the witnesses. This block is nonvolatile. 1 minute after transaction irreversibility has been achieved. Much faster than six hours for Bitcoin. Proves all witnesses had consensus at a certain point in time, so even if communication was lost it would be the only point to rebuild from. The Last Irreversible Block protects the network from unforeseen hardforks.

Q: Minor fork with 35% witnesses last night; resolved soon?

Haven't looked into that fork yet. There was a fork from Internet being lost. Also a recent patch to fix some forking behavior. Bottom line is that such a fork will just require witnesses to be diligent [and patch] and resync back to the main chain.

This won't affect most users using light-wallets (light-wallet operators will have to keep up to date.) Such bugs are likely to be fixed very quickly.

graphene.bitshares.org is test wallet for tesnet [probably now defunct since real launch has happened].

Genesis state will be published on October 13th; community please review this. See new 0.9.3c RPC commands for how to generate genesis file, but please review officially provided one. [This task, also irrelevant due to release having happened already].

NOTEs (and TESTNOTEs) getting own blockchain, not migrated to BitShares 2.0. MUSE launching soon, BitShares 0.9.3c wallet will be needed to claim NOTEs.

Q: Value in subjecting code base to 3rd-party review; worker proposal?

More eyes on code is better, probably other things of higher priority at the moment, but up to the community.

Q: When will transaction ordering be separated from block-signing responsibility?  Require hardfork?

Not necessarily [hardfork]. Witnesses could voluntarily agree to let someone else order for them. Currently witnesses have complete control over order of transactions included in block. All transactions must be hash-ordered, or expiration date ordered. Such constraints allow people who produce transactions to have a bit of control and then game the system (mine transaction ID, set expiration dates opportunistically). Witnesses always have the option to include or not include a transaction so now allowing reordering within a block doesn't completely fix this trust issue. Witnesses currently implement first-come first-serve ordering. This has lots of benefit, if witnesses are trusted [which they kind of have to be]. Good debate for the community to have on whether these responsibilities should be separated.

OpenLedger is going to be like graphene.bitshares.org wallet, themed a bit differently and a few different features (deposit/withdrawl).

Q: "To pay at a store via BitShares PoS wallet QR codes are required, will new light-wallets support this?"

Not on day one, but a great feature.

Q: Licensees for wallet backend?

About half-dozen licensees for wallet backend. Not sure, Stan spearheading this.

Q: Light-weight wallet can query multiple nodes?

Not currently. In the future this could be possible. Recently added ability to change host server. Can point to cloud [or locally, presumably] hosted full-node.

Q: Accounts in genesis block sorted as BitShares 1, Keyhotee accounts no longer first?

Probably several hours worth of work, don't have the time to do that. Manual edits will be required, will move Keyhotee founders to front manually.

Q: Feed frequency: important to publish feeds every 20 minutes; perhaps each hour?

Depends on how fast the market is moving. Usually every 20 minutes is more frequent than necessary. An hour generally seems too long. To minimize risk to shorts (and thus spreads) price feeds should be updated every time they change more than a fraction of a percent.

Q: How will fee pool markets work?

A fee pool is a set of BTS available for paying fees. The issuer of the asset says, "I will buy back my asset and give you BTS at the bts exchange rate." So convert USD to BTS; the issuer gets the USD and the network gets BTS from the fee pool to pay the referrer and the network fees. The issue of the asset must keep the pool funded and set the bts exchange rate.

So BitAssets have the issuer as the committee account. Can access and spend all the fees paid in BitUSD. Can sell BitUSD for BTS and put in back into the fee pool.

Q: 5% premium for core [bts] exchange rate makes sense?

Yes, to cover risks / costs of market operations. Not necessary though.

Q: Any luck working with exchanges to remove BTS/NOTE pairing?

NOTEs should not be on a centralized exchange [snapshot for MUSE soon]. NOTEs bought on exchange after 13th may or may not be honored, up to MUSE folks.

Q: Negative mining attack on Bitcoin?

Bitcoin is secured by the profit margins of the miners. Wide margins give lots of security. Cost of attack is the size of the margin. Bitcoin has a consensus model, though large mining pools control everything. This is as secure as BitShares with a similar (six or seven) witnesses. Risk is that someone can buy out the network [pay more than the margin the pools are making]. Bitcoin and proof-of-work are not likely to die. The true-believers of proof of work are not likely to switch to other systems.

Actually buying out Bitcoin is a fascinating idea.

Q: How much would it cost to buy out the pools?

100x cheaper to attack than people think. 25 BTC * $250 every 10 minutes; actually only the margin matters. Mining profitability was assumed to be 5%. Hard to calculate with difficulty rise, electricity cost, new hardware, price fluctuations, et cetera. Block reward halving within a year will cut margins even more.

Current Bitcoin pools may only sell for some multiplier. This is unknown, different incentives, goals and revenue streams. Value of being in control of Bitcoin network is unknown. Bitcoin could already have been taken over by people with some unknown profit-motive. Paying people high margins to raise the cost of their defection is crazy. Out of line markets with artificially high margins force the market to the same rate of return; thus the 5% rate of return assumption. Above 5% return one would expect the Bitcoin mining market to be liquid enough to bring in down to such levels. The other 95% (non-margin part) does not contribute to the security.

Don't have to worry about witness collusion (with BitShares 2.0) due to high margins. Cost to buy them out is proportional to what they're getting paid to stay honest. More profit also gives more incentive for witnesses to be validated. Security is proportional to witness pay. Current witness pay may be $300/month, at Bitcoin's size would be ~$70,000/month. At current dilution (a fraction of Bitcoin) it is more expensive to get enough witnesses to defect than it would be for Bitcoin, were BTS the size of Bitcoin.

Community can decide how expensive it wants it to be to buy defection [what level of security it wants.]

Q: What about state actors? Infiltration?

This is always a risk. Any business is at risk from this. The network can adapt and respond, barrier of entry of creating alternative networks or voting someone out is low, provided the attack is detected. Blockchain technology makes it very difficult to corrupt election process.

Q: Identabit?

Identabit snapshot will not occur until exact rules for snapshot date are established. Could have already happened, could be in the future. Doing this to minimize impact on BitShares price and thus bit assets. Algorithm will be published as soon as a fair one is found in the future.

Q: Referral system?

Referral system is operational and  good to go.  Affiliate system is somewhat implemented but not all there, will be rolled out after upgrade to 2.0.

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.

I think we should have more delegates -- especially 100% delegates who are likely to be able to answers specific questions in-depth, as they are experts on various aspects of the BitShares ecosystem -- in #bitshares on irc.freenode.net.  I think the only 100% delegate currently there is indolering (assuming he's been voted in by now.)

I realize that IRC doesn't seem to be a popular communication medium for the devs, but simply idling in the channel, perhaps checking even daily to answer questions or clear up misunderstandings, could really be quite valuable at a minimal expense of time.

Thoughts?