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.


Messages - bytemaster

Pages: 1 2 3 4 5 6 [7] 8 9 10 11 12 13 14 ... 656
91
General Discussion / Using Casper Protocol for Secure Price Feeds
« on: February 17, 2016, 03:46:58 pm »
Vitalik published a well written blog post on the new Casper POS protocol being researched by Ethereum. 

https://blog.ethereum.org/2015/12/28/understanding-serenity-part-2-casper/

This paper was very enlightening and introduces some useful concepts. Perhaps one of the most interesting aspects is this:

Quote
The validator will wish to make such a bet only if they believe block X is likely enough to be processed in the universe that people care about that the tradeoff is worth it. And then, here’s the economically recursive fun part: the universe that people care about, ie. the state that users’ clients show when users want to know their account balance, the status of their contracts, etc, is itself derived by looking at which blocks people bet on the most. Hence, each validator’s incentive is to bet in the way that they expect others to bet in the future, driving the process toward convergence.

The original goal of BitUSD was to create a system that didn't depend upon price feeds and yet would maintain a peg. This system depended upon creating an "economically recursive" feedback loop.  In our initial experiments with BitUSD we saw that without a price feed or settlement it is possible for market participants to "short the USD to 0".  The economic feedback loop we conceived failed if one side or the other in the market had more strength and could push the price around and "wait out" the other party. 

Now we have the CASPER protocol which is designed to reach consensus on the current blockchain. Users place bets on each block on whether or not it will be included in the final chain. They cannot bet on all chains at the same time or they forfeit their deposit. 

A price feed can be viewed as a blockchain where the goal is to reach consensus on the price at any given point in time. There can only be "one" consensus value at a time so given a set of published prices they cannot all be "true" at the same time. This is like a blockchain can only have one history, not two.

So if we assume the CASPER protocol works as advertized then we can use it to get more secure decentralized price feeds.

CASPER rewards people for moving toward consensus and punishes those who deviate. It is claimed that the incentives are structured to reward some deviation and incentivise participants to defect from attempted collusions.  I have my doubts on this, but for now I will assume this is true.

If the reward from colluding is much greater than the penalty for failed collusion then the participants may find it worth the risk to collude. Furthermore, people are not machines and are biased toward trusting one another more than we should. This means that in a prisoners dilemma where each individual is better off defecting, people remain loyal more often than rationality would suggest.

Assume a price feed controls the forced-settlement ratio and the validators are using CASPER protocol to bet the next settlement price. If the bettors have a large stake dependent upon the outcome they will be more likely to bet on a favorable price, even if they lose the bet. Essentially, if the bet gains them 1 if they win and costs them 100 if they lose, it still make sense if they can shift the price by more than 1% and have have $10,000 available for settlement. It is impossible to know what side-bets participants have.  Those side bets could even be encoded in smart contracts.

My hypothesis is that either CASPER works for both Price Feeds *AND* Blockchains or it is fundamentally insecure for both.
The corollary here is that all consensus algorithms work for both Price Feeds and Blockchains or are equally insecure for both.

If my hypothesis is correct then DPOS witness published feeds are equally secure as CASPER based feeds *IF* CASPER and DPOS are equally secure consensus protocols.

If CASPER doesn't work as well for price feeds as it does for block production, then perhaps that says something about the fundamental security assumptions of CASPER.

So I am looking for people to evaluate how CASPER can be used to produce reliable price feeds.  Some thoughts to consider:

1. The security of CASPER depends upon the total amount bet
2. What happens if the feed being bet upon controls 1% of the amount bet
3. What happens if the feed being bet upon controls 100x the amount bet
4. What happens if the feed controls "NOTHING"





92
I suggest that we will move to Bitshares 2.1 when this feature is released because it is a really big change in the Bitshares blockchain. It will also give a little bit help with marketing – easy way to signal everybody that we are doing something new here.

Good call.  It will be a hard forking change.

93
Also note that dan & co do the windows release builds.

94
General Discussion / Re: [ATTENTION] STEALTH will come on 18th Feb?
« on: February 16, 2016, 09:00:12 pm »
https://github.com/bitshares/bitshares-2/releases/tag/2.0.160216

I'm little sick of this kind of practice...

BM said the upgrade will be Thursday only in mumble. NO pre-announcement.

Theoretical post update Tuesday. NO announcement on forum or via email.

The devs should realize that Github notification is not an announcement. We need more formal and official one, to become a successful platform.

We are in the process of notifying exchanges and posting the update in the appropriate threads.  We cannot broadcast on all channels at the same time.  Also, it is helpful to have witnesses verify the code before we notify exchanges.

95
General Discussion / BitShares 2.0.160216 Released
« on: February 16, 2016, 08:56:11 pm »
https://github.com/bitshares/bitshares-2/releases

Windows binaries will be posted shortly.

96
General Discussion / Re: Witness Alerts and Status
« on: February 16, 2016, 08:54:33 pm »
A new release and HARD FORK has been posted to github.

https://github.com/bitshares/bitshares-2/releases

This release includes a multitude of bug fixes and enhancements.

All full nodes must update by Tue Feb 23 18:00:00 UTC 2016.

97
General Discussion / Re: Today's wallet seems to be very not smooth
« on: February 16, 2016, 05:09:08 pm »
Last I heard the OL server has CPU overheating issues.  The number of active connections is also growing.

The next release should include more options for servers.

The actual network is running fine.
local full client can easy run by local running witness_node +GUI, 
but it need to re-index by every time restart witness_node .  it is there any way to void re-index when restart witness_node

The reindexing issue has been fixed with the latest release.

98
General Discussion / Re: Today's wallet seems to be very not smooth
« on: February 16, 2016, 04:40:09 pm »
Last I heard the OL server has CPU overheating issues.  The number of active connections is also growing.

The next release should include more options for servers.

The actual network is running fine.

99
General Discussion / Re: Favorite Forum
« on: February 16, 2016, 02:25:28 pm »
which UI is the best?

100
General Discussion / Favorite Forum
« on: February 16, 2016, 01:41:50 pm »
I know we discussed this in the past, but I am curious about what alternative forums do you like?

Why do so many people like reddit? What do you like about our current forum? What are the pros and cons over moving to something like reddit?


101
General Discussion / Re: [ATTENTION] STEALTH will come on 18th Feb?
« on: February 15, 2016, 08:49:41 pm »
We will give exchanges 1 week notice from the time we publish the final code.

102
General Discussion / Re: [ATTENTION] STEALTH will come on 18th Feb?
« on: February 15, 2016, 07:35:44 pm »
Ben is preparing the release for stealth, we can set the hard fork date to any day we like, but the code should be frozen today with all changes merged to the Bitshares branch.

103
I did a quick review of the implementation and believe it accomplishes 90% of what I wanted to accomplish. The only thing this doesn't do is dynamically adjust the fee in response to load.

Assuming this gets properly tested I would support integrating it.

104
General Discussion / Re: Roger Ver Bonus Hangout: (SILVERTICKET Entry Fee)
« on: February 14, 2016, 05:28:03 pm »
I have lots of other work to do,  so I suppose we will have to try again some other day.
Sorry everyone.

:( Thanks for trying.

105
General Discussion / Re: Roger Ver Bonus Hangout: (SILVERTICKET Entry Fee)
« on: February 14, 2016, 05:19:59 pm »
I've started a google hangout if people want to chat about things for a bit.

It is my first time hosting,  but anyone should be able to join:   https://hangouts.google.com/call/l6o5dick2bbdlyjjuvuih4oqsia

It said I wasn't allowed to join the call.

Pages: 1 2 3 4 5 6 [7] 8 9 10 11 12 13 14 ... 656