Author Topic: Announcing BitShares 2.0  (Read 18977 times)

0 Members and 1 Guest are viewing this topic.

Offline canucklehead

  • Full Member
  • ***
  • Posts: 54
    • View Profile
Re: Announcing BitShares 2.0
« Reply #105 on: June 08, 2015, 10:50:29 pm »
Fantastic! All of you! I bet BTCJesus2.0 is gonna want some royalties for the name.

Offline biophil

  • Hero Member
  • *****
  • Posts: 880
  • Professor of Computer Science
    • View Profile
    • My Academic Website
  • BitShares: biophil
Re: Announcing BitShares 2.0
« Reply #106 on: June 08, 2015, 11:32:43 pm »
Also, it seems the new client is not the same codebase as 0.9.x.

Is TITAN also baked in the new codebase? Will we have privacy built-in by default?
No, no TITAN. This is a good thing! TITAN wasn't really very effective for privacy, but it gave the illusion of privacy. Also, TITAN was one of the reasons the client was so unbelievably slow.

Sent from my LGL34C using Tapatalk

Support our research efforts to improve BitAsset price-pegging! Vote for worker 1.14.204 "201907-uccs-research-project."

Offline wackou

Re: Announcing BitShares 2.0
« Reply #107 on: June 08, 2015, 11:33:24 pm »
I'm floored! This is an absolutely brilliant proposal, can't wait to see it in action :D
Please vote for witness wackou! More info at http://digitalgaia.io

Tuck Fheman

  • Guest
Re: Announcing BitShares 2.0
« Reply #108 on: June 08, 2015, 11:38:16 pm »
Referrals: how does the client know who referred someone? will there be a special client download?

also,

Quote
Reward Vesting Requirements

All cashback and referral income are deposited into a special balance which must vest linearly for 1 year. This means that after 6 months you can withdraw about 50% of your cash back, but your remaining funds will take an additional year to vest. This is because the vesting process is based upon accumulating “BTS-years”, for each BTS-year accumulated you can withdraw 1 BTS. If you leave 100 BTS in the account for 1 year then you will have accumulated 100 BTS-years and can withdraw 100 BTS. On the other hand, if you withdraw 50 BTS after 6 months, then you will have consumed 50 BTS-years leaving your account with 50 BTS and 0 BTS-years. It will take a full year to accumulate another 50 BTS-years.

I don't like this at all. If you spent time bringing people to the network, you probably need some money for advertisement etc. you won't be able to reinvest this way

 +5%

Sadly, vesting was required to address a potential attack vector on the referral incentives.    Also, it helps mitigate Ponzi/Pyramid/Get Rich Quick type accusations.

 :-\

Tuck Fheman

  • Guest
Re: Announcing BitShares 2.0
« Reply #109 on: June 08, 2015, 11:46:34 pm »
Please elaborate on ...

... the value of a rate limit on their liquidation will become apparent.
« Last Edit: June 08, 2015, 11:50:25 pm by Tuck Fheman »

Offline donkeypong

  • Hero Member
  • *****
  • Posts: 2329
    • View Profile

Offline donkeypong

  • Hero Member
  • *****
  • Posts: 2329
    • View Profile
Re: Announcing BitShares 2.0
« Reply #111 on: June 09, 2015, 01:22:43 am »
This news is great. Congrats to the team and thanks for all your hard work!

The referral program is a step in the right direction. For those of us who care and believe in BitShares as a long term earth-shaker, we will love using this referral program to help market it. As for the casual fan, I'm not so sure. Can BitShares' marketing really go viral with this vesting requirement? It sure can if the market cap rises to a certain point. We'll see if this can help us get to that point.

Offline zhangweis

  • Sr. Member
  • ****
  • Posts: 304
    • View Profile
Re: Announcing BitShares 2.0
« Reply #112 on: June 09, 2015, 01:34:24 am »
I'm excited that titan removed and market matching rule aligning most exchanges. What about maker-taker to improve the spread?
I'm bit dispointed that there's no burning any more but as long as the total supply doesn't change it should be ok.
Weibo:http://weibo.com/zhangweis

Online alt

  • Hero Member
  • *****
  • Posts: 2806
    • View Profile
  • BitShares: baozi
Re: Announcing BitShares 2.0
« Reply #113 on: June 09, 2015, 01:58:47 am »
can we persist some name that used for business?
like: btsbots, transwiser

oh my goodness this is all gonna take my feeble mind a while to digest.

am I understanding this one small part correctly, is there going to be a race for valuable account names for DNS purposes?

all names registered after today will have a prefix appended to them.

That TODO item got lost in the rush to get this info out.

but once the migration occurs such a race will happen?

Perhaps, but quality names will cost much more.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
Re: Announcing BitShares 2.0
« Reply #114 on: June 09, 2015, 03:51:02 am »
Wow, great work. Can't wait until it's released.

A few things I was pleasantly surprised to hear:
  • The new blockchain processing architecture changes (and corresponding performance improvements) sound really amazing.
  • The new permission/authorization system is also really great.
  • Transferable account names!
  • Finally the recognition that maintenance collateral is all that matters to support the peg. I assume this means shorts will be able to adjust collateral levels up and down as long as it satisfies the maintenance collateral limit, and actual partial covering is possible. Also, I would like to hear more about what a forced margin call is like in the new BitAsset system.
  • Actual limit orders! No WYAIWYG.
  • Bringing back TaPOS for added security (though it is optional).

I'm a little sad to hear that even the minimal existing barriers (in the form of TITAN) to prevent people from getting your transaction history and balance amounts will be removed (even though to someone sufficiently motivated they weren't actually protecting anyone's privacy), but I guess I expected that and it does provide a lot of other benefits. I just wish we can have some other tools later to help manage our privacy better.

One thing I am a little concerned with is if the fact that unique IDs are used rather than hashes means there are more vulnerabilities for successful attacks from a fake blockchain attack. If someone is able to fork everyone over to a new blockchain history with changes in that last 10 blocks or so could they possibly somehow cause someone elses transaction that was meant to send someone else funds send the attacker the funds instead if the attacker is able to "take over" the ID number the transaction was referring to? I guess I would need to actually understand how this new BitShares 2.0 blockchain engine works before I can better articulate this concern. Perhaps TaPOS where the transaction refers to a recent block on the correct chain could help prevent any potential attacks like that (if such attacks even exist)?

Another thing I was thinking about while reading about the changes was how the state is committed to disk only on exit. I understand that it stores the blocks to disk as it receives them so that it can always recover the database state from scratch if necessary. But I don't see why it couldn't periodically commit the database state to disk so that if it fails it doesn't need to replay from the last time the program successfully exited (which may be a long time ago). In fact, if memory usage is so low, I think it would be cool to use just double the memory by using some memory page copy-on-write system to take a snapshot of the memory state while continuing to evolve the other copy, and then asynchronously serializing the snapshot copy to disk. Then when that serialization is done, the memory of the snapshot copy can be freed from RAM to repeat the process over again by taking a snapshot of the evolved copy. In fact, maybe the serialization can be delayed by some period to ensure that the time limit for chain reorganization has passed and so that you know you (almost never) would need replay the blockchain from any committed state older the most recent one, which is probably less than 5 hours old.

Then there are the few things I would have really liked to see if we were going to have such a huge change that requires a complicated migration strategy, even though I of course didn't actually expect to see them. The biggest would be a way of repeatedly and asynchronously committing a snapshot of the state (one that could be agreed upon via the consensus protocol) to a single cryptographic hash that could be committed and approved by all the witnesses as part of their responsibilities. This could allow users to quickly bootstrap to the current state of the database using a copy of a recent serialized snapshot state (which would be less than a day old) and a trusted hash of a recent block. I know that the new engine should speed up replay dramatically, but this would also allow the node to not need to download the entire blockchain either (and they may be constrained by bandwidth more so than CPU speed) as long as they didn't care about transaction history. And in the long term, one of the old snapshot states (that everyone for sure agreed was valid) could effectively act as the new genesis state and allow for blockchain pruning to save disk space. Furthermore, if the commitment of the state snapshot to a single hash was done intelligently, it could allow anyone to provide small proofs of the existence of objects in the database state at the time of the snapshot, where the verifier only needs to trust that the majority of witnesses at the time they committed the hash of the state snapshot to the blockchain did not collude to provide a false proof. This could allow lightweight clients and hosted wallets to (independent of further participation by witnesses) provide the user extra assurance that their view of the database is correct (even if that extra assurance is delayed by a few hours).

Finally, I hope you guys haven't given up on the following:
  • Hosting the web-based GUI interface locally. I of course would expect to be able to run a full node and have the web-based code running in my browser to connect the local daemon running on my local machine. But I would also like to be able to run a lightweight setup where the browser-based GUI securely connects to a trusted public server instead even if I am serving the browser code locally rather than from some other server. I don't want the only official lightweight GUI setup for using BitShares to require us to hope that a MITM attack (likely made possible with compromised certificate authorities) hasn't replaced the browser code with a version that phones home private keys. For regular users, I hope this also means that you are still working on a Chrome web app packaging the browser-based GUI to reduce the chances of a MITM attack.
  • Will you still be working on the mobile QML wallet? Will the new web-based GUI be responsive and adaptive enough to be used on mobile? Even if so, I can't imagine that it could be as capable as an app specifically designed for the mobile platforms (Android and iOS). Will you not focus on this and instead allow third parties (e.g. ElMato's LimeWallet) to build the mobile-optimized BitShares clients?
« Last Edit: June 09, 2015, 03:58:57 am by arhag »

Offline Riverhead

Re: Announcing BitShares 2.0
« Reply #115 on: June 09, 2015, 04:02:01 am »

Another thing I was thinking about while reading about the changes was how the state is committed to disk only on exit. I understand that it stores the blocks to disk as it receives them so that it can always recover the database state from scratch if necessary. But I don't see why it couldn't periodically commit the database state to disk so that if it fails it doesn't need to replay from the last time the program exited (which may be a long time ago). In fact, if memory usage is so low, I think it would be cool to use just double the memory by using some memory page copy-on-write system to take a snapshot of the memory state while continuing to evolve the other copy, and then asynchronously serializing the snapshot copy to disk. Then when that serialization is done, the memory of the snapshot copy can be freed from RAM to repeat the process over again by taking a snapshot of the evolved copy. In fact, maybe the serialization can be delayed by some period to ensure that the time limit for chain reorganization has passed and so that you know you (almost never) would need replay the blockchain from any committed state older the most recent one, which is probably less than 5 hours old. LimeWallet) to build the mobile-optimized BitShares clients?

I work with a large software package from IBM, called TM1, that runs an entire corporate financial planning system in RAM with state only written to disk on exit. It does store a transaction log which serves the same purpose as the blocks being written to disk. It has caused us some headaches during initial deployment but since has worked out fairly well. We do bring it down every other night to write out the state to disk to help contain transaction log size. This obviously isn't a concern where the blockchain is concerned since the whole thing will be downloaded regardless.

Anyway, my rambling point is that there is precedent in another major software package for this type of thing.
« Last Edit: June 09, 2015, 04:06:10 am by Riverhead »

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
Re: Announcing BitShares 2.0
« Reply #116 on: June 09, 2015, 04:07:29 am »
We do bring it down every other night to write out the state to disk to help contain transaction log size.

Now that I think about it, the witness nodes don't even need to go down. A separate node running in parallel could just successfully exit once per day to keep a daily serialization of database state to disk. It being offline when the witness node needs to sign blocks is irrelevant since the witness node would not need to exit. Then if the witness node crashes, the administrator can move the recent snapshot state from the disk of the other node to the witness node and just replay from there. So yeah, there is no need for the live periodic state dumps.

Offline Riverhead

Re: Announcing BitShares 2.0
« Reply #117 on: June 09, 2015, 04:14:03 am »
We do bring it down every other night to write out the state to disk to help contain transaction log size.

Now that I think about it, the witness nodes don't even need to go down. A separate node running in parallel could just successfully exit once per day to keep a daily serialization of database state to disk. It being offline when the witness node needs to sign blocks is irrelevant since the witness node would not need to exit. Then if the witness node crashes, the administrator can move the recent snapshot state from the disk of the other node to the witness node and just replay from there. So yeah, there is no need for the live periodic state dumps.

In practice the other node would just become the block signing node and the crashed node would become the backup once recovered. This is due to the fact that recovery may take longer than a round depending on what went wrong and the backup node is already good to go.

Offline BunkerChainLabs-DataSecurityNode

Re: Announcing BitShares 2.0
« Reply #118 on: June 09, 2015, 04:45:43 am »

I want to thank bytemaster for bringing this technology from the future back to us today.. screw the other timelines, we deserve this.

I already have some ideas of things that could be done to make this more efficient. Or possibly create new markets.

+-+-+-+-+-+-+-+-+-+-+
www.Peerplays.com | Decentralized Gaming Built with Graphene - Now with BookiePro!
+-+-+-+-+-+-+-+-+-+-+

Offline tonyk

  • Hero Member
  • *****
  • Posts: 3308
    • View Profile
Re: Announcing BitShares 2.0
« Reply #119 on: June 09, 2015, 05:00:04 am »
OK for the  slower guys like me ...

after figuring out that Cryptonomex   is actually Crypto + Economics . And is pronounced like Crypto + Economics


Can someone help with the same for:
Graphene

I guess the first part is from Graph...
Lack of arbitrage is the problem, isn't it. And this 'should' solves it.