Author Topic: Announcing BitShares 2.0  (Read 45036 times)

0 Members and 1 Guest are viewing this topic.

Offline liondani

  • Hero Member
  • *****
  • Posts: 3737
  • Inch by inch, play by play
    • View Profile
    • My detailed info
  • BitShares: liondani
  • GitHub: liondani
Graphene should be inferior than Ethereum...

Sent from my ALCATEL ONE TOUCH 997D


Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
Can someone help with the same for:
Graphene

I guess the first part is from Graph...

Damn ... @stan will DEFINITELY love this: http://arxiv.org/abs/1505.04254
TL;DR; scientists discovered a new propulsion system exploiting properties of graphene

Offline btswildpig

  • Hero Member
  • *****
  • Posts: 1424
    • View Profile
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...

http://en.wikipedia.org/wiki/Graphene
meaning bts is like this thing 's cool feature
这个是私人账号,表达的一切言论均不代表任何团队和任何人。This is my personal account , anything I said with this account will be my opinion alone and has nothing to do with any group.

Offline onceuponatime

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

 Graphene is an atomic-scale honeycomb lattice made of carbon atoms.

Graphene (/ˈɡræf.iːn/)[1][2] is an allotrope of carbon in the form of a two-dimensional, atomic-scale, hexagonal lattice in which one atom forms each vertex. It is the basic structural element of other allotropes, including graphite, charcoal, carbon nanotubes and fullerenes. It can also be considered as an indefinitely large aromatic molecule, the limiting case of the family of flat polycyclic aromatic hydrocarbons.

https://en.wikipedia.org/wiki/Graphene

Offline tonyk

  • Hero Member
  • *****
  • Posts: 3308
    • View Profile
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.

Offline BunkerChainLabs-DataSecurityNode


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 and Sweeps!
+-+-+-+-+-+-+-+-+-+-+

Offline Riverhead

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 arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
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


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
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 alt

  • Hero Member
  • *****
  • Posts: 2821
    • View Profile
  • BitShares: baozi
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 zhangweis

  • Sr. Member
  • ****
  • Posts: 305
    • View Profile
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

Offline donkeypong

  • Hero Member
  • *****
  • Posts: 2329
    • View Profile
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.


Tuck Fheman

  • Guest
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 »