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 - xeroc

Pages: [1] 2 3 4 5 6 7 8 ... 851
but it seems witnesses are more professional in coding/server maintenance than in financial analysis, and MCR is not like price, it's a key financial parameter, I don't think traders like a MCR that changes frequently, which will bring much trouble to their decision making.
Neither am I but I am supposed to vote on it.

What I am trying to say is that, after plenty of discussion already, I would expect the witnesses (which are paid in contrast to proxies and committee members) to take an advantage and catch on!

+5% for laying out your plan!

On 1), I would actually expect the witnesses to become more pro-active and implement their own algoritms (presented to the voters) instead of the voters telling them a fixed number for MCR. This should bring up competition and I am willing to use my voting power to support those proactive witnesses!

On 3), BSIP40 is a tough beast as it requires thorough review - discussions are ongoing about how to best proceed.

General Discussion / Re: option trading with BTS
« on: March 07, 2019, 02:18:06 pm »
If i read that right, I can put options on BTC/USD pricing using BTS as currency. Quite cool.

General Discussion / Re: Cryptofresh API
« on: March 07, 2019, 02:16:12 pm »
In Bitcoin it is easy to connect using JSON-RPC. Is there something similar for Bitshares in the works, or what is the best way to do it? I want to be able to query the balance, to register a listener for incoming transfers and be able to send Bitshares or BitAssets.
Is there a way to do this efficiently?   

[]DevOps Training in Kukatpally[/url] | <a href="">DevOps Training in kukatpally</a>
Sure BitShares backends come with websocket/HTTP rpc interface. Example:
Code: [Select]
curl --data '{"method": "call", "params": [0, "get_dynamic_global_properties", []], "jsonrpc": "2.0", "id": 1}'

Stakeholder Proposals / Re: Proxy: xeroc
« on: March 07, 2019, 11:16:12 am »
Removed my vote from witness "delegate-zhaomu". He is double producing blocks:
Code: [Select]
Got block: #35402824 021c34487edacb4c6b6a679bc43c6371a8a9f9f2 time: 2019-03-04T17:52:27 transaction(s): 31 latency: 344 ms from: delegate-zhaomu
Got block: #35402824 021c3448705f175cfd865f4ed2c7aade0e0ec1ea time: 2019-03-04T17:52:27 transaction(s): 30 latency: 601 ms from: delegate-zhaomu

Technical Support / [pyBitShares] Release 0.3.0
« on: March 04, 2019, 03:41:58 pm »
Hello everyone,

just so you guys don't miss it, python-bitshares version 0.3.0 has just been tagged.
This release took quite some efforts as it lays out the foundation to share more code with other blockchain.
Additionally, new operations (including HTLC) have been added and (shitton of) bugs found by the community
have been resolved.

At this stage, I would like to discuss with the community, how to continue with this project as I cannot promise to find
the time to work on this as actively as I would like to. Should we go for a bounty based development setup (funded by
a worker), or rather look for funding from existing projects that use pybitshares (like dexbot) and have their team
also work on pybitshares more actively?

Ultimately, I would very much love to see this grow (even more) into a community project with more contributions
being merged in. As you can see from (,
there are already some 20 contributors in the repo. Let's make this 40, please!

Stakeholder Proposals / Re: [Worker] Reference faucet via
« on: March 03, 2019, 12:22:23 pm »
Options to resolve this from the top of my head:

1. One option to prevent this kind of issue going forward would be to implement a two-step account registration that requires verification of an email address or even better a mobile phone (SMS). However, this is considered too aggressive w.r.t. privacy concerns and barriers of entry by many.

2. Another option to reduce this kind of attack would be to require an invitation code for account registrations which could be tightly integrated into and anyone with an account there could get an invitation code that fills up to a certain threshold within 24hr or so. (might be interesting in combination with becoming the referrer). Obv, people would need to have an account on

3. Yet another way could be to require a *signed message* from a life-time member that could then be set as referrer. This does not require people to have an account on but signed message are longer and more cumbersome than simple invitation codes.

Anyone with another way of dealing with this?

Stakeholder Proposals / Re: [Worker] Reference faucet via
« on: March 03, 2019, 12:15:12 pm »
Due to a distributed attack on the onboarding faucet, account registration for account names that are shorter than 6 is now forbidden. The (now stopped) attacker tried to have hundreds of thousands of accounts registered with community funds.

The way the attacker misuses the faucet made me force this limitation onto everyone. I am truly sorry that, after having tried to slow him down by other means, the ultimate answer to the attacker is to restrict account names to a length of 6 or more.

If any business relies on account creations that are no longer possible, please contact me directly and have your setup whitelisted. Thank you.

Stakeholder Proposals / Re: [Poll] BSIP59:Reduce MSSR of bitCNY to 1.02
« on: February 28, 2019, 02:29:35 pm »
Instead of reducing MSSR affecting all borrowers, it is possible to implement dynamic individual MSSR dependent on CR of the position. Here is the example:

- borrowers with CR=1.75 got margin called with MSSR 1.01
- If CR dropped to 1.7, MSSR is 1.05
- CR = 1.6 -> MSSR 1.10
- CR = 1.5 -> MSSR 1.20
- CR = 1.4 -> MSSR 1.30
- and so on

I think you got the idea. So, borrowers are always incentivized to maintain higher CR. Undercollaterized positions will create an acute price pressure and stimulate arbitrage.
That idea is also part of ongoing discussions in the community.
Thanks for bringing it up again!

What I like most here is that it closes the gab between BitShares and Ethereum (potentially other chains).

For those that don't know, HTLC can be used for and this worker proposal proposes to build a 2 party scenario for Ethereum!

Technical Support / Re: New fee schedule not correctly charging fees
« on: February 19, 2019, 01:25:03 pm »
The balance id that stores your refund is in your account objected and is called "cashback_vb"

General Discussion / Re: BTS volume on Binance...
« on: February 15, 2019, 07:20:50 am »
Confirmed ... 90M BTS volume on binance .. wow

Stakeholder Proposals / Re: [Worker Proposal] Core Team 2019
« on: February 15, 2019, 07:17:53 am »
As a proxy voting for this worker, I do fully understand the concerns raised by @dexy - I came to ask myself the very same questions.
My conclusions is that this is the cost for an **independent** development team. If we (the BTS community) wanted this cheaper, we'd
need to hire a company to work on this. Developers in that company would earn less (probabably about 60-80$/hr) and will be managed
by the company. But then, don't expect that this company will invoice only the rates of those developers. That's not how a software
house can survive for long, profits need to be made for the company too, hence, you are looking at a rate that is at least as high as
current core devs'. And even if you found a company that was willing to contribute for less, I still prefer to have our own team that's
knowledgable trusted and loyal to the BitShares community. Totally fine with paying for that.

General Discussion / Re: Review of OMO
« on: February 15, 2019, 07:14:02 am »
I agree with plan A.

Stakeholder Proposals / Re: [Worker] Reference faucet via
« on: February 14, 2019, 08:39:49 am »
Thanks everyone for your support. The reference faucet worker is active now and account creation continues as usual.

Pages: [1] 2 3 4 5 6 7 8 ... 851