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.

Topics - Bhuz

Pages: [1]
General Discussion / Next Committee Proposal: Witness Pay
« on: May 07, 2017, 09:01:20 pm »
Since the last Committee Proposal went through (fee-adjustement), [member=120]xeroc[/member] remembered and asked the Committee tu discuss about the witness pay, and more precisely what is a rational payment for a witness job
The following is the reply I wrote on the telegram committee group and, as suggested by [member=18687]abit[/member] soon after, I am now posting it here too, for a wider discussion with the community

These are just inputs... there surely are more questions that may be worth asking and answering... please comment and discuss them, modify or add your own

If instead you want to decide what a witness pay should be without consider what his job is really about and what it is worth for the blockchain etc, then I am not interested in the discussion... I will vote for whatever the committee or shareholders decide, but probably without giving any meaningful input or personal thought

Questions we should answer:
1- Should we consider how much the witness "ideal" guy is worth on the real world? (ie. how much a (even Junior) SysAdmin gets paid)
2- Should we consider the 24/7/365 requirement aspect of the witness job? (you can sleep, have week-ends and holidays, but you still have to "go to the office" in a timely manner no matter what the day and time is)
3- Should we consider how much other blockchains spend (invest?) for their own security? (ie. how much BTC, ETH, etc spend, compared to market-cap) (even other dpos like STEEM and soon PEERPLAYS)
4- Should we consider the current profitability of the DEX DAC?
   4a- If so, should it be able to greatly increase what the points 1,2,3 would suggest?
   4b- If so, should it be able to greatly decrease (or even reset) what the points 1,2,3 would suggest? (ie, no profit for the DEX == no profit for the witnesses --> witness pay = costs of running a witness)

Maybe more tough (and subjective?) questions:
5- How much is the whole blockchain task, security and decentralization worth? (this is what a witness really do, from a pure blockchain pov) (looking at point 3 may help)
6- Should 4, and particularly 4b, be able to overcome 5?

IMHO we shouldn't start from a number to later check if that is sustainable for a witness, but rather start from what an adequate pay for the job is, and only later set the pay...
So, witness pay = job pay + costs (adequate/deserved witness net income + costs that the job itself requires)


BTW, it's basically one year that I pay my BTS witness costs thanks to STEEM... if it was for BTS itself I wouldn't have earned nothing, or worst I would be at loss...
I hope this will be read and understood by all those people that were jumping and screaming around as soon as bts (finally) rose in value, to point the finger to the witnesses that, suddenly, were "earning too much" thanks to their "unbelievable, unaccettable and absurd pay"
I also hope this will be considered for choosing an adequate BTS witness pay

_ _ _ _ _ _ _ _ _ _ _ _ _ _
Some data about point 3 at the time of this post, from coinmarketcap, considering current rewards
Market-cap: $25,617,582,661
Price: $1570.05
Monthly blockchain expenses: 12.5(btc/block) * 144(blocks/day) * 30(days/month) * 1570(usd/btc) = $84,780,000
BTC expenses / BTC market-cap --> 84,780,000 / 25,617,000,000 = 0.0033

Market-cap: $132,000.000
Price: $0.562
Monthly blockchain expenses: 25 * 0.189 / 63 * 86400 * 30 * 0.562 = $109,252.80 (edited to consider the x5 runner-up cost)
STEEM expenses / STEEM market-cap --> 91,800 / 132,000,000 = 0.00083

Market-cap: $95,908,469
Price: $0.036894
Monthly blockchain expenses: 3600 (bts/hour) * 24(hours/day) * 30(days/month) * 0.037(usd/bts) = $95,900
BTS expenses / BTS market-cap --> 95,900 / 95,900,000 = 0.001

This means, compared to their market-cap:
BTS current expenses is less than 1/3 of BTC's expenses
STEEM current expenses is about 15% lower than BTS's current expenses
_ _ _ _ _ _ _ _ _ _ _ _ _ _

If interested in the matter, please comment, discuss, and share your thoughts. Thanks

The recent release of GUI wallet introduces a 'Force Settlement' button. This Force Settlement function allows some users to exploit the current 'loophole' in the bitCNY market and gain profit at the expense of the bitCNY providers.
(See,20283.0.html and,20287.0.html)

Transwiser (a major partner who provides bitCNY<->CNY fiat) and a number of Chinese users who depend on this service are suffering big losses.  This is not the worst.  They fear more losses to come.

The Force Settlement function closes the borrow/short positions with lowest collateral ratio and sells their collateral at the settlement price. For the bitCNY market, this means an immediate loss to the shorters (and a gain for the ‘force settle’ users) because bitCNY is trading below the feed price. As we found out, the feed price does not accurately reflect the CNY price.  It is in fact lower than the price listed in major China websites like OKCoin. The price discrepancy created an artificial arbitrage opportunity for the ‘Force Settle’ opportunists.

In addition, the shorters will be forced to sell their collateral even if they have sufficient collaterals to avoid a margin call. 

All this means that the Force Settle opportunists could force settle to exchange bitCNY for BTS on the DEX and then sell them at profit in a centralized chinese exchange eg BTC38.  This HURTS A LOT of bitCNY shorters, no matter the liquidity available in the DEX.

Effectively, they are being forced to sell their collaterals and close their positions against their will.  This introduction of this ‘force settlement’  was not known by the Chinese community at large.  Little wonder that the Chinese community considers this behaviour as ‘robbing the shorters’.

Urgent call for help
bitcrab and alt, representing the Chinese community, called on the committee members for help. After a lengthy and intense discussion (for over six hours), we consider the situation warrants an urgent response as follows:

1) Temporarily SUSPEND the "force settlement" function by raising its fee to 1Billion for about a  week.

This will give us time to put in a remedy:

1) Disable frontend "settlement" button when there are buy orders available above the feed (requires Svk work)
2) Adjust price feed for bitCNY market by including other Chinese exchanges in sourcing CNY prices (xeroc has agreed to work on the changes)
3) Get a CNY liquidity bot to put up buy orders with bids over the feed price and so protecting the shorters from abusing the force settlement function for an opportunistic gain.  ( bitcrab to work on it)

In normal circumstances, the Committee would like to give the Community enough time to discuss the proposals we intend to put up - first with a forum discussion and then setting the proposal period to one week.

As we are facing a crisis now, we would like to ask the Community to support the Chinese’s call for help - and to make this change as soon as possible (within 24 hours) in order to save the Chinese shorters from further losses.

We seek your kind understanding and support for this proposal.

The Bitshares Committee

General Discussion / First Organized Mutually Agreed Proposal
« on: November 17, 2015, 08:06:08 pm »
After the last major debates on what the fees amount should be, The Committee Members, trying to consider all the different wishes and requests expressed by The Community, agreed on the following changes:
-Transfer fee is now 30 BTS (reduced by 25%)
-Account creation fee is now 95 BTS (halved to avoid vesting)
-Scale is now 1 (trying to avoid a possible bug on vested amount from referred LTM upgrade)

These changes will be effective from Thu Nov 19, 2015 14:07 UTC (a little less than 2 days from now)
You can check the proposal here:

We really hope to have been able to suit everyone for the time being.

The Committee Members - bhuz, bitcrab, bitcube, clayop, logxing, mindphlux

General Discussion / Missing random blocks
« on: November 16, 2015, 01:25:55 pm »
[member=5]bytemaster[/member] Could you please explain what is happening in the following situation?

Code: [Select]
3141381ms th_a       application.cpp:496           handle_block         ] Got block: #938169 time: 2015-11-15T10:52:21 latency: 383 ms from: fox  irreversible: 938140 (-29)
3146998ms th_a       witness.cpp:185               block_production_loo ] Generated block #938170 with timestamp 2015-11-15T10:52:27 at time 2015-11-15T10:52:27
3147201ms th_a       application.cpp:496           handle_block         ] Got block: #938170 time: 2015-11-15T10:52:24 latency: 3203 ms from: in.abit  irreversible: 938146 (-24)
3150236ms th_a       application.cpp:496           handle_block         ] Got block: #938171 time: 2015-11-15T10:52:30 latency: 238 ms from: bue  irreversible: 938146 (-25)
3150236ms th_a       db_block.cpp:137              _push_block          ] Switching to fork: 000e50bb5ba87838b334fa8f7e330fa4fa00113c
3150237ms th_a       db_block.cpp:147              _push_block          ] pushing blocks from fork 938170 000e50ba27bba65c3f756856e880e72553c061c9
3150238ms th_a       db_block.cpp:147              _push_block          ] pushing blocks from fork 938171 000e50bb5ba87838b334fa8f7e330fa4fa00113c
3153138ms th_a       application.cpp:496           handle_block         ] Got block: #938172 time: 2015-11-15T10:52:33 latency: 140 ms from: maqifrnswa  irreversible: 938146 (-26)

And same here

Code: [Select]
1152088ms th_a       application.cpp:496           handle_block         ] Got block: #968534 time: 2015-11-16T12:19:12 latency: 88 ms from: rnglab  irreversible: 968513 (-21)
1158000ms th_a       witness.cpp:185               block_production_loo ] Generated block #968535 with timestamp 2015-11-16T12:19:18 at time 2015-11-16T12:19:18
1158248ms th_a       application.cpp:496           handle_block         ] Got block: #968535 time: 2015-11-16T12:19:15 latency: 3248 ms from: dragonball  irreversible: 968515 (-20)
1161624ms th_a       application.cpp:496           handle_block         ] Got block: #968536 time: 2015-11-16T12:19:21 latency: 624 ms from: fox  irreversible: 968515 (-21)
1161624ms th_a       db_block.cpp:137              _push_block          ] Switching to fork: 000ec7587fdba930c1d08a4c9918394160eceb62
1161624ms th_a       db_block.cpp:147              _push_block          ] pushing blocks from fork 968535 000ec757516cb356622a848c9bce44ed535a55b7
1161625ms th_a       db_block.cpp:147              _push_block          ] pushing blocks from fork 968536 000ec7587fdba930c1d08a4c9918394160eceb62
1164150ms th_a       application.cpp:496           handle_block         ] Got block: #968537 time: 2015-11-16T12:19:24 latency: 150 ms from: delegate-1.lafona  irreversible: 968516 (-21)

I can't figure out if:
1-my witness node is generating the block with 3sec delay (still there is no message about "missing block because replaying after 500ms" etc), making me miss the block and calling another witness to sign it for me.
2-my witness is called to generate a block consequently a missed block by another wittness that, with 3sec delay shows up and replaces my block, making me the one who missed a block(?!)
3-some block propagation problem

Could you clarify this? Thanks

Stakeholder Proposals / bhuz as temporary committee member
« on: October 28, 2015, 07:13:21 pm »
Hello guys,

I am stepping up as a temporary committee member to help in the process of push through some proposals (by mindphlux, puppies, cube, and fav according community requests and practical needs) that still need more votes to take effect.

Since I am also a witness, I will abstain to do any proposal about witness pay and such.

There is a real need of decentralization power for committee members, we need to take over the inits power to have the chance to vote and approve what the community demands.


General Discussion / Order of witnesses signing blocks
« on: October 07, 2015, 01:09:44 pm »
Hi guys,
I have a question / idea...but not knowing exactly how the DPOS 2.0 protocol works, maybe this idea is based on wrong assumption and/or is not feaseble for implementation or security tell me :)

My assumption is that even if the order of witnesses signing blocks seems random, it really is deterministic, based on...previous hashes?... I don't know, but still, is deterministic.

At this point, could we change the way in which the order is determined?
Maybe the protocol should take into account the latency between witnesses?

It should knows all the latency from a witness to the others, for each witness, and then maybe with a modified version of Dijkstra algo (some kind of algo for shortest paths), it could find the best routing through all the witnesses.

This could lower the average latency between consecutive witnesses and so it could be easier to decrease the blocks interval (specially for 1 sec) without the necesity of increasing the bandwidth, and above all it should also decrease (kind of eliminate) the number of missing blocks due to:
1)high latency between very distance node
2)nodes with not so high bandwidth capacity

Since we anyway should aim to a good decentralization of witnesses around the world in different regions and continents, this approach could really keep the overall latency very low.
...or maybe not?!

Technical Support / Missing balance?
« on: September 13, 2015, 02:27:05 pm »
Hello guys,
I hope someone of you can help me figuring out if I really miss some funds, or if what I see is just a bug...

First of all, I claimed my BTS from PTS a long time ago, july 2014...with, I guess, one of the first version of the wallet (so not bug free :D)

What is (maybe) wrong:
In recent transaction I can see 2 claim from genesis. They have the exactly same "memo" and "amount". Already at that time, the "balance" in the "recent transaction" was the sum of the two, while the "balances" at the top of the wallet (the one next to "estimated yeld") showed only the half there was only one claim. I tought that was a bug, since the wallet was still in beta and so on.
What do you think about this? Its a bug or I really miss half of my funds?

One more thing that may help understand if there is something wrong...
If I am not wrong, the command wallet_account_balance_ids should list all the addresses that in the present have some balance, right? Not the ones that had balance in the past...
So, with that command the wallet list 2 address. Looking their balance with blockchain_get_balance <addr>, I can see that the sum of the two is different from what wallet_account_balance show me.
Its like one of the two addresses has the second claimed bts, but they don't show in the total account balance...

What do you think?

Thanks, and sorry for bad english :)

Pages: [1]