0 Members and 1 Guest are viewing this topic.
Is this Leonardo maybe? Because if it is that could be huge, that would provide bot cross trading between mayor centralized exchangesand 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?
Quote from: xeroc on March 21, 2017, 07:43:31 pmConvinced?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.
Convinced?
Quote from: xeroc on March 21, 2017, 03:46:25 pmNow 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.
Now increasing liquidity in the USD:BTS market:
What is the ETA on the Foundation becoming operational?
UpdateA couple minutes ago, we have process the first "combo-proposal" in order to1.) Obtain the worker pay2.) Obtain 4350 bitUSD from the BTS:USD market3.) 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.pyObviously, 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 groupQuoteIt'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
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)
A "Trailing stop loss" sounds like the perfect addition to UpTick.Also mostly keeps your positions off the blockchain until executed.
Cast your votes, anything to help developers create Bitshares related projects is great for the community.
Yes, it does. I guess, this whole process could be automated with a simple bot, can it?
Quote from: yvv on February 04, 2017, 12:52:15 pmActually, 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?
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.
import yamlfrom pprint import pprintfrom bitshares import BitSharesfrom bitshares.account import Accountfrom bitshares.blockchain import Blockchainconfig = 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)) passif __name__ == '__main__': run()
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.
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 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:BTS3. Multisig fill worker orders and send USD to worker again.5.RepeatIf this is the case, why 5%?
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?
https://bitsharestalk.org/index.php/topic,23698.0.html20 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.
voting.
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.
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
python-bitshares