[worker] Python-steem and uptick (1.14.52)

[xeroc]

For those that want to use `uptick` to build their own 'scripts' .. e.g. for trading ... you may want to take a look at this example:
https://gist.github.com/1f9a296447fd63f8b3ee446afc10bf14

[xeroc]

I have made a new proposal `1.10.1805`. This proposal
**a)** claims the BTS in the vesting blance,
**b)** sells them for bitUSD at up to 5% premium,
**c)** sends 4k bitUSD to `chainsquad` for the worker payment and
**d)** sends another 100 bitUSD to `chainsquad` for the API node.

As you can see from the milestones in the worker proposal
    https://github.com/xeroc/worker-proposals/blob/master/2017-02.md
and the code provided in
   https://github.com/xeroc/python-bitshares
and
   https://github.com/xeroc/uptick
 .. you can see that milestone 2 has been reached (overfullfilled actually)

The script that proposes the proposal above can be found here:
   https://github.com/xeroc/worker-proposals/blob/master/2017-02-claim-2.py

The proposal expires in 4 days.

Kind regards
  -- Fabian

Remark:
There is currently 23,822 bitUSD worth BTS that are now owned by the shareholders and not me due
to going through a multisig worker with USD pricing instead of my own worker! Given the 2.5x ratio in
mind, this makes an opportunity cost of 9500 bitUSD for me.

[tbone]

Is this Leonardo maybe? Because if it is that could be huge, that would provide bot cross trading between mayor centralized exchanges
and DEX, and as a bonus, providing DEX exposure to big game players.

That could certainly be financed by new worker. How much fund are needed in your estimation?

This has value.  How much value it has depends on a) what functionalities this company offers and intends to integrate with Bitshares, b) how many existing users they have who could take advantage of this new support for Bitshares, and c) whether other softwares that are compatible with Poloniex would now also become compatible with Bitshares.   And then of course the worker cost also matters.

[Geneko]

Is this Leonardo maybe? Because if it is that could be huge, that would provide bot cross trading between mayor centralized exchanges
and DEX, and as a bonus, providing DEX exposure to big game players.

That could certainly be financed by new worker. How much fund are needed in your estimation? 

[xeroc]

Recently, I was contacted by a company that builds graphical trading software/bots for crypto exchanges. They were asking about how to best integrate with BitShares.
During the discussion, we came to the conclusion that the easiest way of doing so would be to run a local API endpoint. You can think of this like having a background
process that basically mirrors the API of poloniex, or that of BTC38 or any other exchange, but you don't connect to poloniex's server but to 'localhost' and see all the same
functionality.

So, the idea would be to build something that would work like this for the enduser:

1) Install piston-polo
2) Run piston-polo --user xeroc --password mySecret --port 8080
3) Modify your polo bot to use 'localhost:8080' instead of api.poloniex.com, and use your credentials as login, or API key
4) Run your bot as if it was using poloniex

Do you think this has value? How can this be funded (a feature like that is not covered by the milestones in the worker discussed here)? Someone here willing to help me put this thing together?

[xeroc]

Convinced?

Got it. So shortly speaking, you are long on BTS, but committee still pays this worker in bitUSD, because it is better to have the pay rate fixed this way. It is up to committee how to get bitUSD (borrow or buy), and it is up to you how to spend them (hoard or short), depending on current market . Makes sense.

P.S. Finally, a market pegged asset is actually used exactly the way a contract for difference is supposed to be used, i.e. to fix the price of a long term contract, a worker contract in this case. And this is very cool.

Exactly!

Just one minor correction at this point. The committee-account is part of the multisig account and part of the owner permission. However, in order to be able to do things more quickly there are a bunch of other trusted entities in the group that can approve a proposal.
The reason here is that in order for the commitee-account to approve a proposal, you need to reach 51% approval on the committee members and then wait for the committee review period for the approval of the proposal to execute (just the approval, not the proposal itself) .. In the end, going through the committee for payouts is extremely slow. That's why the active permission is a 3 of 5 setup with trusted members of the community, namely: blocktrades, cass, svk, fox, and chainsquad .. (the owner is the same plus the committee-account).
Basically just an implementation detail

[yvv]

Convinced?

Got it. So shortly speaking, you are long on BTS, but committee still pays this worker in bitUSD, because it is better to have the pay rate fixed this way. It is up to committee how to get bitUSD (borrow or buy), and it is up to you how to spend them (hoard or short), depending on current market . Makes sense.

P.S. Finally, a market pegged asset is actually used exactly the way a contract for difference is supposed to be used, i.e. to fix the price of a long term contract, a worker contract in this case. And this is very cool.

[Geneko]

Convinced?

I am. It is better this way, only if we could adjust all workers and witness pay to this method. 

[xeroc]

Now increasing liquidity in the USD:BTS market:

I don't get it. multisig-worker bought bitUSD at 210 BTS/bitUSD and now you are selling them at 180 BTS/bitUSD. This looks like expensive way to increase liquidity.

Well, the bigger picture is that the bitshares shareholders paid me in bitUSD instead of paying me in company stock (BTS). If the worker was paying me BTS directly (not going through multisig group), then I would end up with BTS worth twice as much as what they have been valued at when I created the worker - simply because the price has been raising for a couple days now already.

So the multsig group removes all the volatility and pays the worker in bitUSD what he asked for.

Now that `chainsquad` has been paid for the work delivered, it is our freedom to do with the USD what we like, that includes keeping them in the wallet instead of selling them - However, we believe in the future of BTS (for multiple reasons) and we also mentioned increased liquidity as one benefit of the whole setup. That is why we are placing a sell order at market price + a few percent.

In the end, it is actually a good deal for the shareholders even tho it is a bad deal short term.
Arguable, it could have been better to borrow bitUSD instead of buying them, but that would leave the multisig account (and thus the shareholders) with an open short position - arguable, too risky.

Also keep in mind that other exchanges pay for their liquidity as well. In this case, you even get volume (the multisig worker buying bitUSD) and you get liquidity from the freelancer (chainsquad) selling bitUSD.

Convinced?

[yvv]

Now increasing liquidity in the USD:BTS market:

I don't get it. multisig-worker bought bitUSD at 210 BTS/bitUSD and now you are selling them at 180 BTS/bitUSD. This looks like expensive way to increase liquidity.

[xeroc]

Now increasing liquidity in the USD:BTS market:

[Thom]

Thx for the update, keep us posted on progress / people involved with Foundation setup.

[xeroc]

What is the ETA on the Foundation becoming operational?

My partners ran into some private trouble .. both of them.
But there are other leads that BitShares can benefit from. There is plenty of work and we are on the way of getting the required funding to "bring it on"

[Thom]

Excellent xeroc! I hope this concept takes hold and it becomes a more reliable and superior method to fund workers.

What is the ETA on the Foundation becoming operational?

Update

A couple minutes ago, we have process the first "combo-proposal" in order to
1.) Obtain the worker pay
2.) Obtain 4350 bitUSD from the BTS:USD market
3.) Send the USD to chainsquad (in 4 chunks according to the proposal)

The script that generated the combo-proposal can be found here:
https://github.com/xeroc/worker-proposals/blob/master/2017-02-claim-1.py

Obviously, it uses python-bitshares.

As a remark, after the approval of the proposal by 3 parties in the multisig group, the transaction executed instantly and created some volume in the DEX.

This is the message I have sent to the people involved in the multisig group

It's time to continue our little multisig experiment. I have created a proposal that a) claims all BTS from the worker, buys USD and sends USD to chainsquad: 1.10.1457.

I would appreciate your approval.

All points in the first milestone (https://github.com/xeroc/worker-proposals/blob/master/2017-02.md) have been reached, code is published and working (the proposal has been created with that library) - milestone 2 is almost ready, except for the trading algorithm specific code.

Feedback is welcome. Please approve the proposal until "2017-03-21T11:27:23" (UTC) .. then we can see if everything works as expected ..

PS. this is not meant for the public as I don't want anyone to take advantage of the rather big USD-buy order that this proposal is going to create (+fill)

I'd say, the whole setup works nicely and I recommend to consider it more actively fro future workers.

Regards
 -- Faban

[xeroc]

Update

A couple minutes ago, we have process the first "combo-proposal" in order to
1.) Obtain the worker pay
2.) Obtain 4350 bitUSD from the BTS:USD market
3.) Send the USD to chainsquad (in 4 chunks according to the proposal)

The script that generated the combo-proposal can be found here:
https://github.com/xeroc/worker-proposals/blob/master/2017-02-claim-1.py

Obviously, it uses python-bitshares.

As a remark, after the approval of the proposal by 3 parties in the multisig group, the transaction executed instantly and created some volume in the DEX.

This is the message I have sent to the people involved in the multisig group

It's time to continue our little multisig experiment. I have created a proposal that a) claims all BTS from the worker, buys USD and sends USD to chainsquad: 1.10.1457.

I would appreciate your approval.

All points in the first milestone (https://github.com/xeroc/worker-proposals/blob/master/2017-02.md) have been reached, code is published and working (the proposal has been created with that library) - milestone 2 is almost ready, except for the trading algorithm specific code.

Feedback is welcome. Please approve the proposal until "2017-03-21T11:27:23" (UTC) .. then we can see if everything works as expected ..

PS. this is not meant for the public as I don't want anyone to take advantage of the rather big USD-buy order that this proposal is going to create (+fill)

I'd say, the whole setup works nicely and I recommend to consider it more actively fro future workers.

Regards
 -- Faban

[ebit]

 

[xeroc]

I have released another version of uptick and python-bitshares

https://github.com/xeroc/python-bitshares/releases/tag/0.1.3
https://github.com/xeroc/uptick/releases/tag/0.1.1

Have fun building your platforms ..

[xeroc]

This is the announcement for the 0.1.0 release of uptick .. the command line tool
http://steem.link/Eqo7Q

[xeroc]

I am please to announce the first release of python-bitshares:
http://steem.link/5ij4g

[xeroc]

A "Trailing stop loss" sounds like the perfect addition to UpTick.

Also mostly keeps your positions off the blockchain until executed. 

For this, I need websocket notifications to track the market changes. That's what I was working on today. I can't promise this kind of feature will be available with the first release but I am making great progress in that regards ...

[iHashFury]

A "Trailing stop loss" sounds like the perfect addition to UpTick.

Also mostly keeps your positions off the blockchain until executed. 

[xeroc]

@shareholders, @community, and @developers,

As I am making significant progress with both, pybitshares library and uptick, I would like to request input from you as to what features you would like to have in the library and the command line tool uptick in an upcoming public first release candidate.

Uptick currently supports these calls:
  addkey
  allow
  balance
  broadcast
  buy
  changewalletpassphrase
  configuration
  delkey
  disallow
  getkey
  history
  info
  listaccounts
  listkeys
  openorders
  orderbook
  permissions
  randomwif
  sell
  sign
  trades
  transfer

and uses pybitshares to execute those calls on the blockchain.
What do you want to have in addition? I'll try to make it happen right in the first release.

[xeroc]

Absolutely .. in fact, I actually NEED this kind of code to run this worker and get paid (due to the multisig nature of the escrow service for bitUSD payments).
Building bots will be very easy. You can see the same code base in action on STEEM called pysteem (pytsteem.com). It's a very popular library for python devs.

PyBitShares will simplify using the BitShares blockchain and build businesses around BitShares and I am not just talking about faucets or mm bots. Any kind of buisness that wants to run on top of BitShares could build a MVP in python very quickly and move over to custom libs/code while they grow their user base. Or they stick with pybitshares which is build with scalability in mind.

[nmywn]

Is Python good enough to start a very simple community based sidechain? By saying sidechain I mean bunch of bots operating as multisig account in minimum 2 blockchains (e.g. steem <=> bitshares). Bots read data from blockchain's apis, voting on transactions and store data about it. Is that sidechain? Workers, pegged assets, custom dividend schemes, mining... All done with python bots, flexible UIA's and multisig groups - with possibility to upgrade to faster language if business model generate enough income to hire devs. Every time I see fractals like that I'm super exited. Is this a way how Graphene blockchain is supposed to scale or my uneducated imagination led me to false conclusions?

[xeroc]

Morning everyone. I am still looking for some support for my worker proposal. Please consider voting so that we can improve the python tools and libraries that other devs can then use to build their apps and improve the ecosystem. Examples are the faucet (tapin) or a market making bot (stakemachine) but even more is possible like tipping bots, trading bots and any kind of automation of your account (like donations of some tokens to new accounts as done on the testnet).

[vikram]

Cast your votes, anything to help developers create Bitshares related projects is great for the community.

 

[Brekyrself]

Cast your votes, anything to help developers create Bitshares related projects is great for the community.

[xeroc]

This is a kind reminder for shareholders to consider voting for this worker. There are only a few votes left.
Regards
 -- Fabian

[xeroc]

Yes, it does. I guess, this whole process could be automated with a simple bot, can it?

Yes it can .. more of less .. everything that involves the worker account needs to be approved by the multisig group tho ..
But you can concatenate multiple operations into a single transaction/proposal so that they only need to approve once ..

[yvv]

Actually, there is no need to put 2.5x collateral. If there are no offers between feed and SQP price, borrow bitUSD with minimum (1.75x) collateral and let it be margin called as soon as an offer appears between feed and SQP.

Depends. Margin Calls can force you to pay up to 10% above the feed while if you maintain collateral, you can just to partially close your position at lower premium.
Given that the shareholders (on paper) pay with more dilution for this worker already, I don't think it's fair to also ask them to pay for margin calls. Hence, 2.5x collateral.
Makes sense?

Yes, it does. I guess, this whole process could be automated with a simple bot, can it?

[xeroc]

updated the faucet code for the testnet to run on the new library. This is a worker/background process donates TEST tokens to every newly created account (even if you create it):

Code: [Select]

import yaml
from pprint import pprint
from bitshares import BitShares
from bitshares.account import Account
from bitshares.blockchain import Blockchain

config = yaml.load(open("config.yml").read())

bitshares = BitShares(
    "wss://node.testnet.bitshares.eu",
    keys=[config["wif"]],
    nobroadcast=False
)


def run(begin=None, end=None):

    blockchain = Blockchain(
        mode="head",
        bitshares_instance=bitshares
    )

    for op in blockchain.stream(
        opNames=["account_create"],
        start=int(begin) if begin else None,
        stop=int(end) if end else None,
    ):
        try:
            pprint(bitshares.transfer(
                op["op"][1]["name"],
                config["donation_amount"], config["donation_asset"],
                account=config["registrar"]
            ))
        except Exception as e:
            log.error(str(e))
            pass


if __name__ == '__main__':
    run()


[xeroc]

I see one flaw. Collective account income isn't specified. Are they working for free? I would give them 10% of savings that they made, or better to say: if. Fair offer.
Your idea is amazing btw.

The original plan was to get the BitShares foundation bootstrapped by offering this as a service for a fee. But due to some time-delaying issues they couldn't make it til now. Hoping to find a way to do this for a subsequent worker.

[nmywn]

It is going to be exactly like @Geneko described it.
The only thing that is not yet clear to me from the procedure, is
* Should a collective account be used to borrow bitUSD instead of spreading shareholder-owned collateral to multiple accounts?
* Should the account's permissions be set to be committee owned after the expiration, or should it be re-useable?

I personally, prefer to send BTS to a separate account that holds the collateral position and sends back the bitUSD. This makes accounting easier but requires another multisig group to organize and maintain the collateral.

I see one flaw. Collective account income isn't specified. Are they working for free? I would give them 10% of savings that they made, or better to say: if. Fair offer.
Your idea is amazing btw.

[xeroc]

First of all, thanks for the support!

I would love to read more about trading part. For now I see one simple scheme.

1. Multisig borrow USD and send to worker.
2. next day worker make sell order 5% above feed at USD:BTS
3. Multisig fill worker orders and send USD to worker again.
5.Repeat

If this is the case, why 5%?

It is going to be exactly like @Geneko described it.
The only thing that is not yet clear to me from the procedure, is
* Should a collective account be used to borrow bitUSD instead of spreading shareholder-owned collateral to multiple accounts?
* Should the account's permissions be set to be committee owned after the expiration, or should it be re-useable?

I personally, prefer to send BTS to a separate account that holds the collateral position and sends back the bitUSD. This makes accounting easier but requires another multisig group to organize and maintain the collateral.

We also support this worker proposal. I am looking forward to creating more dev tools for the community. Please also add an extended documentation to the tool so that new devs can get started easily.

Short question:

- How much time will you dedicate for this worker and BitShares?
4,000 euro a month sounds like a full-time worker for 3 months.

- Are you also working on further steemit related projects?

Thanks for the support, chris!
The worker is based on milestones. So you get all milestones fulfilled for 3 months * 4000$/mth =12k$
The amount of time I need to put into it depends on how fast I can bring it on and how many problems I run into it.
In the end, this way is in favor for BTS holders and makes it more risky for me .. but I am pretty confident I can deliver in time

I also have commitments with some Steem projects. No commitments so far for Steemit Inc.

Actually, there is no need to put 2.5x collateral. If there are no offers between feed and SQP price, borrow bitUSD with minimum (1.75x) collateral and let it be margin called as soon as an offer appears between feed and SQP.

Depends. Margin Calls can force you to pay up to 10% above the feed while if you maintain collateral, you can just to partially close your position at lower premium.
Given that the shareholders (on paper) pay with more dilution for this worker already, I don't think it's fair to also ask them to pay for margin calls. Hence, 2.5x collateral.
Makes sense?

https://bitsharestalk.org/index.php/topic,23698.0.html

20 hours per week，1600 USD a month，Just want to compare.

and，The job will take ten months to finish？

I think you hold the BTS appreciation is expected to pay part of the wage.

The referred worker has a backing of BTS-munich while I am an independent developer. If someone is willing to top this up, we can negotiate something new after this worker has ended.

[wao]

https://bitsharestalk.org/index.php/topic,23698.0.html

20 hours per week，1600 USD a month，Just want to compare.

and，The job will take ten months to finish？

I think you hold the BTS appreciation is expected to pay part of the wage.

[yvv]

Actually, there is no need to put 2.5x collateral. If there are no offers between feed and SQP price, borrow bitUSD with minimum (1.75x) collateral and let it be margin called as soon as an offer appears between feed and SQP.

[Chris4210]

We also support this worker proposal. I am looking forward to creating more dev tools for the community. Please also add an extended documentation to the tool so that new devs can get started easily.

Short question:

- How much time will you dedicate for this worker and BitShares?
4,000 euro a month sounds like a full-time worker for 3 months.

- Are you also working on further steemit related projects?

[cass]

voted

[BunkerChainLabs-DataSecurityNode]

Proposed worker 1.14.52 has been approved by proxy bunkerchainlabs-com

[Geneko]

I understood it this way:

1. Multisig try to buy bitUSD 5% above feed. If it cant buy enough rest of bitUSD is going to borrow providing 2.5times collateral (Total budget for that operation is 90000BTS/day). BTS used for collateral never leaves multisig account.
2. Multisig send bitUSD to Xeroc.
3.  Xeroc use bitUSD as he likes (sell on whatever market he likes adding liquidity)
4. Every thing that is not paid out after the end of the worker will be settled and returned to the reserve fund
5. Everything left and held as collateral will be maintained by the committee and kept in full by the BitShares shareholders

[nmywn]

I would love to read more about trading part. For now I see one simple scheme.

1. Multisig borrow USD and send to worker.
2. next day worker make sell order 5% above feed at USD:BTS
3. Multisig fill worker orders and send USD to worker again.
5.Repeat

If this is the case, why 5%?

[Geneko]

@JonnyBitcoin
Excellent test bed for adding bitUSD liquidity!!

[$bkt]

This endeavor has the power to make Bitshares great again! We as Bitkapital support this proposal to the fullest extent.

[Fox]

This worker proposal will provide value to the BitShares network. I support this effort.

[xeroc]

voting.

Thanks! Your support is much appreciated!

[fav]

Anyways, the python-bitshares library will hopefully be extremely useful for people building projects on top of bitshares pretty much the same way as python-steem enabled countless tools to be build on top of STEEM. It a matter of making it easier for developers to get their handy "dirty" on a network.

easy adoption, that's one thing I do understand

voting.

[xeroc]

I used piston to reset my keys after the hacking incident, but what can you do with it today?

For who would this be useful in bitshares, given the fact that you can almost do everything via GUI as end user?

What's the use-case?

ELI5 pls, not a dev (obviously)

uptick is probably not very interesting to many except the nerds and developers .. and of course those that need to maintain non-usual tasks - for instance asset maintenance tasks that are just so rare that it makes no sense to add them to the GUI. Also there are plenty of features available on blockchain level that are note expose in the GUI yet .. withdrawal_permissions for one.

Anyways, the python-bitshares library will hopefully be extremely useful for people building projects on top of bitshares pretty much the same way as python-steem enabled countless tools to be build on top of STEEM. It a matter of making it easier for developers to get their handy "dirty" on a network.

[fav]

I used piston to reset my keys after the hacking incident, but what can you do with it today?

For who would this be useful in bitshares, given the fact that you can almost do everything via GUI as end user?

What's the use-case?

ELI5 pls, not a dev (obviously)

[xeroc]

To those that want to dig deeper, you can see the existing already implemented work here:

https://github.com/xeroc/python-bitshares/tree/develop
https://github.com/xeroc/uptick/tree/develop

Once stable, I would like to move the repository to the official BitShares project.

These features are already available in uptick:

[xeroc]

This is a worker proposal to refactor the python library and build a tool called uptick, both Open Source under MIT license.

Preface
In the last couple months, I have been focusing on python development for the Steem blockchain due to it's quickly growing user and developer base. During that time, I have developed piston and the python-steem library which became very popular and are widely used.

Given that many Steemians already know about BitShares, it makes sense to bring in this popular toolkit to BitShares. Instead of extending piston to also work on the BitShares network, I hereby announce the beginning of a new tool called:

Code: [Select]

uptickThis tool will be similar to piston (Steem) and sx (Bitcoin) and allow to interact with the BitShares blockchain on a simple command line tool. With this tool, it will also be easy to manage your BitShares assets, use whitelists and halt markets, as well as transfer assets, or trade on the DEX.

To be able to build this tool and add functionality, I will first develop

Code: [Select]

python-bitshareswhich is a library that actually interfaces with the blockchain and makes further development of end-user apps super easy (see for instance how people write bots for STEEM using python-steem). I have already started work on this library and am happy to tell that the foundations are already up and running. This library will also be used for the testnet stress test.
Tasks & Milestones

Milestone 1

•     Extract the BitShares specific code from python-graphenelib
•      Refactor BitShares code in a distinct python library
•      Add local encrytped wallet
•      Setup a redundante public API node
•      Allow the usage with BitShares and the TEST network

Milestone 2

•     Create modules to abstract blockchain obects (Amounts, Prices, Assets, Accounts, Block, Blockchain, Witnesses)
•     Add commonly used operations like transfer, buy, sell, create account
•     Create a DEX specific module to simplify the creation of trading bots
•     Create a command line tool uptick to access the libraries methods

Milestone 3

•     In-code documentation for developers
•     Tutorials and howtos to describe the use of the library
•     Tutorials to show the power of uptick command line tool

Milestone 4

•     Add ability to create and maintain multisig accounts
•     Ability to easily monitor the blockchain for specific operations or blocks

Worker
Given that a worker will be voted in for quite some time, I would like to propose a new model of running a worker: with shareholders keeping a say:

•     I created a new account, upgrade it to LTM and make it multisig with the committee account and trusted members of the community
•     The worker will redeem it's funds on a regular basis and buy up bitUSD from the market (only up to above market)
•     If the market doesn't offer sufficient bitUSD, the worker account will borrow bitUSD at 2.5x collateral
•     For this reasons, the actual pay of the worker is 2.5x the USD value
•     The worker will only pay the agreed amount of money and only in bitUSD to chainsquad
•     Every thing that is not paid out after the end of the worker will be settled and returned to the reserve fund
•     Everything left and held as collateral will be maintained by the committee and kept in full by the BitShares shareholders

Unfortunately, the BitShares foundations is not yet in a state to supervise this. Thus I have contacted a couple trusted community members to be my excrow agents and help implement the above procedure:

•     (3/3) committee-account
•     (1/3) dev.bitsharesblocks
•     (1/3) cass
•     (1/3) chainsquad
•     (1/3) fox
•     (1/3) blocktrades

Duration and Salary
This proposal will last for 3 months starting at 15. February 2017.
The pay constitutes a regular and a fixed part. The latter consisting of

•     $100 account LTM fee and
•     $150 worker creation fee

while the monthly fee contains:

•     $4000/mth python development
•     $100/mth public API reachable on this.uptick.rocks

These settings, plus the additional backoff of 2.5x amount to rougly 90,000 BTS of daily pay. Keep in mind that the BTS will be paid to a multisig account which only pays the above mentioned USD to chainsquad. None of the BTS will be transfered out of the multisig account.