This post is hopefully going to grow to a whole bunch of sessions eventually.

Session 1:
https://www.youtube.com/watch?v=TKg53MQw6GA
- cli_wallet & witness_node
- Installation of Python Library
- Basics about BitShares Objects and the blockchain
- Basics about how to interface with wallet & witness node
- Advanced interfacing and notifications


Session 2:
Doodle: http://doodle.com/poll/rsikf4rr63p89cqb
- Trading in the DEX: buy, sell, borrow, getTicker, get orderBooks etc..


#paidbyprotocol

I had I nice talk with the CTO of tether and he was very aware of the drawbacks of his centralized approach and surprisingly was already familar with smartcoins. He has no explanation as to why it is so rarely used/trades.

Anyway, he was very interested in BitShares and sees some benefits in using BitShares for tether.

Do you want me to follow up with him?

Dear shareholders,

The first few weeks of 2016 have been quite exciting but feel like nothing compared to what is yet to come and within reach. With the most recent developments about

* the proposed fee schedule
* the proposed 0-fee options as well as BSIP#10
* as well as a proposal for advanced bitassets (thanks tonyk)

there is still plenty of work to be done, let alone all the development around the backend, GUI, and complementary libraries.

Additionally, it turned out that not only newcomers need to be supported when they first get in touch with BitShares and Graphene, but also the existing community needs quite some education about what is possible already and how things are technologically interconnected.

Sooner or later this task will be covered by professional consulting businesses that are already forming around the blockchain business in general and the Graphene technology in particular (nothing more can be said yet). In the meantime, I would like to offer my services around technical support and documentation to every community member and shareholder as a part of a worker on the blockchain.

Furthermore, a second worker has been created to fund my ongoing work on the python libraries. Quite some features are yet not well exposed neither to the python libraries and need to be integrated. Additionally, I would like to continue developing a python bot infrastructure that makes applying bot strategies to the DEX as well as arbitrage with our assets a lot easier.

Both workers have a starting date that is after the termination of my
current worker, pay a total of €3000 (2k+1k) for a total of 20h/week (though it might well end up to be again more than that), are limited by 4 months and vest their pay for 90 day.

As usual, the detailed job application can be found on github
         https://github.com/xeroc/worker-proposals/blob/master/2016-02.md
and has a PGP signature next to it. You can verify the content has been signed by me using
gpg --verify 2016-02.md.sig

I'd appreciate your votes for 1.14.31 and/or 1.14.32!

Talking about all what went "wrong" with how I approached the committee about the fee schedule made me believe that we should think about mailing lists for organizational tasks.
Forums are great, Telegram is great too. But non of them really work well when you want to post structured well-though posts AND answer to other's queries.

I think we should really consider (publicly archived) mailing lists for many of our organizational tasks and use this forum mainly for individual stuff like support and welcome as well as brain storming.

They do have the advantage that they are archived publicly, you can just collapse those threads that you don't want to read (assuming you have a reasonable modern mail client) and .. well .. mail is universal and does not rely on some external devs that don't do their job properly on maintaining forum software ..

Here is an example of bitcoin-dev:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/thread.html
What's your opinion?

I used to think that most of the ethereum community has either none or positive sentiments for BitShares, but I start to be rather disappointed about them given this posts and voes:

https://www.reddit.com/r/ethereum/comments/43j5dc/ethereum_vs_bitshares/

Is this just the bad influence of r/bitcoin or have we just lost another open community?


Oh btw, it seems people
a) still think that SHAREHOLDERS=COMMUNITY and
b) community is toxic

So, could we at least be a little more welcome and positive in the near future? Please..

Hello there,

let me start with thanking @Riverhead for providing a machine the machine for this! Please give him some or even better, some BROWNIE.PTS

Anyway, @puppies brought up the idea of constructing a public testnet and I took the idea and used it to also document the steps necessary to deploy a graphene-based blockchain.
This is the result:

- http://testnet.bitshares.eu
- http://docs.bitshares.eu/testnet/

Since I also installed a faucet, if you register an account in the web wallet, you will be donated 10k TEST so you can play around.

I planned to have three MPAs on that chain of which only two are currently "running" (price feeds). The third one got globally settled already due to a bug in one of my scripts.

Backend Code:
Please clone https://github.com/bitshares/bitshares-core, checkout "testnet" branch or latest tag starts with "test".


Have fun!

So,

BitShares is in great need for users, traders, and is currently failing to attract them.
Hence, I propose to have fees for the core features be drastically reduced and have it combined with a marketing campaign
for traders and users ...

This offer should be limited for a period of 3 to 6 months since we want a profitable DAC.

It is important to understand that a few users which are willing to pay high fees, could be as profitable as a high number of users paying a small fee.

Thinking about the future of BTS I realized that quite some homework has to done first.
What is still unclear to me are the requirements for 'approval'.
I came to the conclusion that we probably want to distinguish different thresholds for different objectives.

First of all, an approval needs to be a binary decision. The, what we already have by now is approving a worker to be paid by the blockchain. The approbal here is reached if the worker proposal is upvoted enough to receive a pay (either above the current refund400k or above any of the other refund/burn workers later). So that is already fine, shareholders know the drill and have several options (upvote/downvote).

What is left is a consensus about how a hard fork proposal delegate should be dealt with and how to reach consensus about it.

My first thought would be to set the threshold for approval to exactly zero net positiv votes. Here shareholders compete with pro and contra votes. If the net vote result is negative, the proposal is rejected. If it is positive, the proposal is accepted. That would give everyone a 'fair' share in the decision but of course has (arguable) drawback that whales' decisions are difficult to prevent. (Arguable because of "shareholder"!!! consensus) ..

To relax the rule, we could have a threshold worker (zero pay) so that shareholders can define the threahold as well ... The interessting consequence would be that those that dont want to see ANY change to the protocol can upvote the threahold while thoae that want a flexible protocol can downvote it ... This worker would then correspond to refund worker for hired positions.

To extend the idea, we could (maybe) characterize different BSIPs into categories (tier-1, tier-2..) and have a distinct thrshold for them.

But the leads to the question whether we. (Not necessarily the shareholder) can find a specification for the categories.

And then of course we can combine them. A hard threshold which must be passed by ever soft threshold and a successfully approved proposal must surpass the hard threshold AS WELL as the category-specific soft threshold.

Discuss!