Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - thisisausername

Pages: [1]
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. 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 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, as I mentioned in my last post I haven't been able to make the past few hangouts.  There wasn't a transcript of the October 2nd one on Beyond Bitcoin but I also didn't have copious amounts of time today; so here's a summary of that one.  []'s indicate editor notes and keep in mind this is all my interpretation I could've got something wrong (but I don't think I did.)

(Code tags were the only way to make the tabpsaces big enough for this to be readable. Copy it to notepad or something for an even better experience.)

Code: [Select]
- Thanks for testing corner cases.
- Testnet discovered blackswan
- Killed network [hardfork required]
- Wasn't supposed to be able to happen
- Every new block failed for the same reason
- Now fixed
- Accounts can vote for vary numbers of witnesses
- Default behavior was to vote for the minimum number
-Lazy voter turnout (like now) would result in minimum number of witnesses
- Now, if you don't vote for at least 2 people you defer to those who do so for the number of witnesses that you will vote for
- If you wish to abstain you can abstain, whereas before you couldn't
- New, fixed testnet is already up
- Very successful testing
- Network stayed in sync w/ floods
- Margins calls, order matching, forced settling (aside from black swan) all worked well
- UI has continued to improve
- Permissions added
- Add/remove multisig keys
- Memokey
- Creating/Issuing assets fixed
- Help integrated into wallet
- Content is sparse at the moment
- Confident for Oct 13th launch
- Deploying infrastructure
- Making sure exchanges are prepared
- Xeroc has some docs for them
- They have been following the upgrade
- Statement will be requested
- Safest thing to do is hold funds locally
- Releasing soon:
- Hosted wallet, testnet
- Light-weight wallet, downloadable executable
- Full-node wallet, for mac, executable
- For windows will be DIY
- Built version coming ASAP
- Light-node or full-node offer best security
- Working on getting referral program in place
- Only very minor GUI changes from now to launch
- Wallet is looking good working under Graphene
- After Oct 13th still providing updates on a weekly basis
- New GUI release first
- No hardforks after Oct 13th expected
- Many things to be added [requiring hardforks], going to be judicious in doing so is a big disruption to the entire network
- Hardfork to add features once a quarter, unless fatal bug

- Metaexchange, blocktrades (Integrate bridges into the web wallet?)
- Working with blocktrades

- Close to release, is how to connect to network going to change?
- Livenet will be similar to test
- Need to checkout from BitShares repository (not testnet repo)
- BitShares 1 can stay alive, but Bytemaster sees no point in doing so

- Have BitShares 2.0 witnesses been selected?
- Start with initial witnesses voted in
- Publish seed node
- Start election
- Were unable to migrate votes from BitShares 1
- Thus many default witnesses at first
- They do not plan on running witnesses for the long-term, just the transition

- Why can't delegate votes be moved over?
- Fundamental architectural difference
- Every balance not tied to account name, has balance in 1.0
- Every balance tied to account and has balance in 2.0
- Also 1 has many stale votes, new election would be good

- The risk is high with CNX being the initial witnesses
- We will select people we know [trustworthy people] to be the initial witnesses
- Not necessarily CNX employees

- Connect to backbone nodes exclusively.  DDOS protection.
- Hasn't been implemented, would like to eventually

- Long-range nothing-at-stake attack against initial witnesses
- Public record out there makes it so that you won't trust any other chain, regardless of length, everyone knows what the real chain is
- Vitalik, weak subjectivity
- TaPoS
- Not a worry for any Graphene DPOS chains
- Long-range nothing-at-stake: someone who used to have control offer block production can create an alternative chain and isolate a victim and make them think they have been sent real money
- User's account wouldn't exist on their chain
- If it did, your keys wouldn't be the right keys
- See Bytemaster's blog post on long-range nothing at stake
- Based on how rapidly witnesses can be voted in on testnets, 30+ in 24 hours
- Once checkpoint made, (~24 hours), long-range attacks can't be executed
- Checkpoint: universally known good state
- Full-nodes have these

- Eventually community will be able to hire competing actors?
- Bytemaster: Yes.
- Cryptonomix is producing the software (free speech)
- Other people run nodes
- Spreads legal risk by separating these tasks
- Software is open-source, so no trust is needed
- Best regulatory protection by not needing trustworthy

- Worker proposals: When worker's ask for shares/share dilution, are they setting a date in the future on which their shares will mature? Or a 100 day sliding window?  [Does payout come all at once or over some time-frame]?
- Sliding window.

- Pros/cons of allowing workers to bundle vested shares into savings bonds instruments that could be traded to raise capital to fund something; like a sovereign bond, network itself is guarantor. Market will look at trust of whole network and set price for such bonds.
- Bytemaster: Almost possible by transferring account of worker to cash provider and cash provider gives shares immediately
- Like OTC transaction
- Still on network, but finding buyer
- Similar to bond sale (country, corp)
- Bytemaster: Right
- [Being able to trade vested shares from one user to another.] No bid/ask market? Because bonds are bundled together with shares that have different maturity dates?
- Bytemaster: Vesting system is more robust than that
- Not a bunch of different bonds, one for each day
- Each day you're adding to the bond
- Can withdraw after accumulating
- For each coin-year can withdraw 1 coin
- 365 coins, each day can withdraw 1
- Similar to vested shares from merger, adding another restriction, incentivized to wait out the whole period
- Bytemaster: If you keep it all there you get to all fastest, if you take out half takes twice as long to get the second bit
- Shareholders could appoint trustees or workers who bid on this, raise funds based on the trust in the network and sell promissory notes (dilution in the future)
- Network can borrow in the present and not feel the effects of dilution until the future
- Bytemaster: Very complex economic scenario
- Price in present based on sell-pressure now
- If someone plans to hold for 1 year and they swap for a bond, so someone else can sell in the present
- There's still selling in the present
- Just added a bit of guaranteed long-term holding
- Discounted with time-value money, other factors
- How is the sell pressure of a vested share different from the sell pressure of an actual present, existing share?
- Bytemaster: Accounts can be transferred, vesting account balances cannot be directly transferred
- It would be very easy to add this functionality
- Vesting funds aren't fungible though, and there's no market for it
- Could be done off-network

- Mumble / live-stream on Oct 13th, 2015?
- Fuzzy: Will look into it
- Connect Google hangouts, mumble, Skype
- Bytemaster: On 13th we are doing open-heart surgery
- A lot of infrastructure role-out
- Differentiate day of starting network from grand opening
- Issues may occur
- Have grand opening once everything has been working well for a while
- 13th is like beta release
- UI still needs work
- Bugs will be discovered
- Fuzzy: Now we're going to open-beta, anyone can be a tester
- Bytemaster: Emphasize beta
- There're so many unknown-unknowns
- Only real test is length of time in market
- This is why Bitcoin doesn't change anything
- Few "emergency days" would not be unsurprising [hardforks?]
- More unit-tests than ever before
- Every feature tested at protocol level
- So many variables
- Even in case of hardfork, funds are safe if private keys are safe
- Exchanges will use delayed node that looks back several blocks
- Blackswan problems tend to stop the chain
- Still confident in system
- Audience: Team has good track-record with dealing with such issues

- Fuzzy: Bitcoin is static because they are stable. When will BitShares 2.0 achieve this?
- Bytemaster: Individual call.
- Once every op has been used once, every scenario has happened would inspire confidence for me
- Others will need more
- 6-months seems like a good time for vetting existing features
- Hardforks may reset this clock if they change these features
- We're likely to see issues in month 1 or not see them at all (electronics failure curve)
- Audience: Simultaneous dev chain? Run features on dev chain for 3-6 months before consideration of forking into main chain?
- Looking at ways of making the blockchain technology at the core robust and unchanging and allowing features to be added without breaking things from a blockchain perspective [separation of concerns].
- The challenge with consensus is that anything that changes ownership of tokens changes everything after it. Butterfly effect.

- Bytemaster: Some smart people have been criticizing our claims of 100,000 transactions per second.
- They are attacking a strawman
- Addressed this on the forum
- "We keep everything in RAM and at 100,00 TPS that's a terabyte of RAM per day that would need to be added - this doesn't scale."
- This would not work.
- Not all transactions are kept in RAM though
- Only the state, account balances
- 99% of transactions are simple transfers and result in no net increase in the [complexity of the state or] RAM usage
- I analyzed this from a perspective of, if each account has 1 KiB of data, which is a bit
- Their pubkey, balances, assets, open orders
- Most accounts use much less
- Used 1 KiB as average
- All account information for 1 billion accounts in 1 TiB of RAM
- Can support 2 TiB today
- By the time we grow to be this big, RAM will not be a barrier we will face
- Sequential processing bottleneck sets transaction rate limit (market operations, transactions that impact the market)
- Everything else can be done in parallel
- No way of getting around this within the market
- Every op affects the order book, can't do things in parallel without parallel markets
- Spreads, more complexity
- Parallel chains, one consensus set: side-chains approach. Only accelerates some tasks (cores vs speed CPU analogy - cores only help with parallel tasks)
- Probably max out at a couple thousand transactions per second right now (whole system perspective)
- Have seen couple hundreds of TPS in testnet
- Far in excess of what we're likely to generate in the near future
- If we did we'd be deflationary immediately (more funding, could get needed infrastructure)
- Marketing should be refined to reflect this TPS business

- Minimum requirements for witness VPS?
- Bytemaster: Digital Ocean 1 GiB node has worked for some
- No more than couple hundred megabytes of RAM
- Almost any computer

- Bytemaster summary: Working on deployment issues
- Exchanges
- Forking codebase
- Setting up for release
- Please test on testnet this week
- Test wallet soon
- Several iterations, dry run of open-ledger wallet
- Have reached out to exchanges
- Get others in contact with Bytemaster
- Xeroc also working on exchange integration

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 –] 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.

4 directs users to download 0.6.1 directs them to 0.6.2

General Discussion / Delegates on IRC
« on: January 23, 2015, 10:42:13 pm »
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  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.


General Discussion / Some interesting reading
« on: June 19, 2014, 04:22:17 am »
Not a DAC idea yet, but perhaps something to think about.

The part of most interest for those here is probably below 'Scooped by Plato'.

Pages: [1]