He has a large enough number of shares in order to make himself the top signer, which is already causing people to doubt the future of the project. He can possibly cause problems with a 2 of 3 multisig group. We can’t afford lost confidence right now.
Downvoting him isn’t going to stop him. It wastes your voting power, which could be better spent elsewhere. The only way to truly erase him from the network is to dilute his shares. My post above tells you exactly how to do that. In addition, it gets rid of non-minters and apathetics. We would need your help though in order to pass a BlockShare grant. Here it is again…
1)Pass a motion of RSOT and ask Jordan/Phnenix/Angea hand over their NBT fund to this team.
If Jordan/ Angela agree, it means they don’t want to be hostile to community, so let’s cooperate. With regard to Nu’ situation, we believe both community and Jordan should apology for this crisis, Jordan of course made mistakes but the community also not innocent, how many of you disagree his revenue model in 2014-2015?How many of you vote for the NSR buyback?
After the crisis, both sides want to make the other as scapegoat, this really disgusts me. I would like to see either side‘s self-criticism rather than blaming each other. I didn’t fully agree with Jordan when Nu operated smoothly in 2014, 2015, and I will not demonize Jordan after the crisis. Therefore, I won’t start serious hostile activity towards any side until my RSOT motion passed. If RSOT motion passed and Jordan/Angela refuse to hand over their fund, I’ll become complete enemy of Jordan/Phoenix/Angela. I’ll down vote him with all my share and even help to start a new blockchain/new project if @sigmike agrees to help.
To sum up, I won’t do anything hostile to Jordan if RSOT not passed, this is my principle. RSOT motion is the touchstone for me to judge Jordan/Phoenix ultimately.
Isn’t it listed in the blockchain? I assumed the answers were there and could be found out similar to the analysis @mhps did with the addresses that voted for the motions Phoenix put forward.
It’s too complicated and easy to hurt those minters whose hardware/client happen to ave problems in that month. I still think this idea is much bettter:
We can do this often and keep the pressure on.
However as JL pointed out this will turn away people who have money but little time, which BC probably need.
Wouldn’t shareholder takeover of top signers be something that can be detected while it’s happening if it becomes a problem?
Say we establish a sufficient amount of trusted signers with a few untrusted ones. How long would it take a majority shareholder to vote enough new signer identities to the top in order to begin stealing trades?
Is it possible to detect malicious signing and abort further trades?
If we build in a safety mechanism that triggers when signers are rapidly replaced?
Could traders get to choose which signers they trust?
Ahh, thanks for summarising your idea. How would rooms be created? Are rooms basically preset preferences for traders? Can traders also cherry-pick signers?
I am under the impression that shareholders select signers that traders automatically use. Is this incorrect?
How much complexity is added by the room idea? Perhaps warranted, but I have not understood why it’s necessary. What are the main concerns?
I remain curious about the following, as it should function as an immediate emergency halt making the most an attacker can get away with be one trade.
The trader publishes what it wants to happen, and if that isn’t what happens, clients should be able to detect that and cancel all trades.
It’s likely I don’t understand how BCE functions. If the coins are already in escrow by signers, there’s nothing the traders can do at that point?
Hmm.
I’m still not convinced the risk is substantial. I’d like to see responses to the other questions in my previous post.
It was not clear to me when I read the design paper. I asked about that in the protocol specs I wrote but I’m not sure Jordan saw it. It’s about the requirements on deposit address requests:
If the keys must be from the top n signers with available keys, then the user cannot choose the signers (n being the voted number of required signers on the asset, it’s not related to the number of rewarded signers).
To allow signer selection we can loosen that to allow a request to include keys from the top X signers. X would have to be defined (for example the top 2*n signers, or could be added as a voted value on each asset).
That is crucial info. We d never get an exchange running if we do not have assets selected.
There is no awareness across shareholders about the importance of the same exponent value.
But what is this exponent value in any case?
It’s the number of decimals allowed on the asset. In the asset vote dialog this value is already defined for all the preset assets. So shareholders only have to decide it on custom assets (or if they disagree with the preset values).
The value should generally be the one used by the asset on its blockchain. It should only need special thoughts when this number is large (like the 18 decimals of Ethereum), in which case a smaller number must be used. It would be very complex to allow this value to change, so if this asset’s value ever becomes too large and shareholders want to allow trading of smaller units they would need to add another asset with a different exponent (for example adding a wei asset with zero decimals). Signers handling this asset would have to do the appropriate adjustments.
The result is not based on the majority. It’s a median.
Consider each vote individually. There are 672 votes for 4, 335+141 votes for 5, etc. Sort them by the value they vote for. So the first 672 are the votes for 4, the next 335+141 are for 5, etc. Then take the vote exactly at the middle of this long chain and you have the median (the middle is actually between two votes, so we take the one immediately after the middle). It means half of the votes are below or equal to the median, and the other half is above or equal to it.
That’s why the votes are returned sorted by voted value and an accumulated percentage is calculated to make it easy to find where the middle is (the first value with an accumulated percentage > 50).
So the median is still 5 because there are more votes for 5 or less than for 6 or more. But only by a small number of votes (7.4% of 2000 = 148 votes).