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 SummaryTestnet 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.
Topic: BitShares Dev Hangout: Bytemaster – October 9, 2015 Quick Summary (Read 1341 times)
