It has been stable. And I do not see any missing blocks since the last update (despite the short 3-second block time). 

Quote from: cube on December 03, 2015, 02:01:58 pm

Bug report:

http://cryptofresh.com/p/1.10.19 incorrectly shown percentage approval.  It should be 100%.

Thanks cube, I'm not immediately sure what to do about this.. that panel is reporting directly from the blockchain, and I'm not sure why it changes after the fact. That doesn't make sense to me..

I did suggest that we need something like the following:

Quote from: roadscape on December 03, 2015, 01:16:08 am

bool get_final_proposal_state(proposal_id_type id) - to retroactively look at the final results of a proposed op

So at least we could look back and see if a proposal was approved or not.
The ability to see individual committee votes at the end of review would be great too.

I am not sure if the devs have any intention of storing the state in the blockchain after the proposal is completed.  If they are not going to be kept there, would you be able to store them in your server and keep a copy there?  If this is not possible too, you may like to give some notice to the users visiting the completed proposal that it is completed but no other available information.

Quote from: mf-tzo on November 30, 2015, 07:30:48 pm

thank you very much. Good luck with the project!
Looking forward to a nice collaboration in the future with bitshares.

Thanks, we too. The ball is largely in your (Bitshares') Court. We've been open and ready to discuss collaboration and overlap for weeks, so just let us know when you guys are ready

Also: IOTA's first sale period, 'Pioneer', is ending today at 14:00 UTC. This period yields 15% more IOTA to the purchaser.

So far we've raised over 460 BTC and 35 000 JINN (equivalent to ~220BTC)

I highly recommend that you join in our weekly meeting via mumble  this Friday 10am EST.  Bytemaster will be there talking and sharing with a number of community members.

Mumble details - https://beyondbitcoin.org/mumbleinfo/

Bug report:

http://cryptofresh.com/p/1.10.19 incorrectly shown percentage approval.  It should be 100%.

Witness  bitcube ( "id": "1.6.23") is an active and dedicated witness.  I have been an active witness since the beginning of Muse. I am glad to be part of the team.

Quote from: alt on December 02, 2015, 11:23:33 pm

Quote from: theoretical on December 02, 2015, 09:57:13 pm

Created 1.10.21, documented how I created it:  https://github.com/cryptonomex/graphene/wiki/Howto-propose-committee-actions

thanks, I think we  need to change this for all asset right?
do we must do it one by one?

I have the same opinion. We have to update all smartcoins, especially USD.

Voted.

I wonder if there is  a way to make a proposal to update all the bitassets at one go, rather than one bitasset at a time.

Quote from: clayop on December 02, 2015, 06:11:52 am

There was active exploiting that uses inaccurate price feed and generates free money for the exploiter.

http://bitsharestalk.org/index.php?topic=20356.msg262329.msg#262329

we talked in the past already about inaccurate price feeds a lot.

It is not just an inaccurate price feed as in a feed with fluctuating price but a feed with a consistently wrong CNY price due to the fact that the algorithm does not pull in any China website sources.  It is like getting USD fiat prices not from the USA but from some other non-related places.  This price figure is simply wrong and cannot be relied upon.  And no matter how you want to call it, the price feed script is flawed.  The flawed price feed in the DEX allowed opportunistic flaw exploiters to gain unfairly at the expense of one side of the long-short players.

The rest of the points are really out of the scope of the proposal.  But for the sake of completeness, let's discuss them.

i wanted to have them as good as possible. with metaexchange we had the problem in exchanging bitBTC - BTC .

claiming not working pricefeeds - hurts only shorters, so i ask transwiser direct - why are you holding CNY shorts?

not working pricefeeds will happen again and again and if transwiser justs holds CNY and bitCNY it is not their concern.

it was also already stated - force settlement is in the command client since the beginning, so nothing new here at all.

this reaction tastes not good in my mouth.

the committee saved some speculators and hurt other speculators.

Out of Scope Discussion
=========================

As you said it, metaexchange "had the problem in exchanging bitBTC - BTC".  AFAIK, nobody - absolutely no businesses are pegging 1 bitBTC : 1 real BTC in the bitshares DEX.  But why?  IMHO, the risk of losses is probably too high to justify any profit.

Transwiser, on the other hand, is literally pegging 1 bitCNY : 1 CNY (with a small fee) and offering this bitCNY to CNY fiat onramp and offramp services to our users.  Transwiser is a real legitimate business that bitshares users benefit greatly.  To say that the Committee saved some speculators is simply a false statement.

The price feed flaw has been there all this while but it was not exposed publicly.  The recent introduction of the 'Settle' button exposes the price feed flaw.  Not surprisingly, the opportunistic flaw exploiters took advantage of it and gained unfairly at the expense of Transiwiser business, as well as other short players.

The 'Settle/Settlement' function has nothing much to do with the whole story.

Quote from: lil_jay890 on December 01, 2015, 05:21:02 am

Quote from: merockstar on December 01, 2015, 04:33:31 am

theoretically, python could be used to write a wallet that communicates with bitshares blockchain, even though graphene is written in react.js, right?

I believe graphene is written in c++

appreciate the correction.

question still stands though, if I wanted to make an alt wallet (a BTS equivalent to BTC/LTC's electrum, if you would), and actually saw this thing through long enough to get to that point, could that be done in python?

Yes, you can do that.