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

Pages: 1 ... 73 74 75 76 77 78 79 [80] 81 82 83 84 85 86
1186
General Discussion / Re: Dry Run 5: The Final Countdown
« on: June 23, 2014, 09:54:19 pm »
I added my delegates and followed the instructions.
There are no votes for my delegates.
Shall I make a transaction ?

1187
General Discussion / Re: Dry Run 5: The Final Countdown
« on: June 23, 2014, 09:35:35 pm »
Removing the initial delegates was a good idea as the network was terribly slow initially.

1188
General Discussion / DDOS prevention
« on: June 23, 2014, 08:50:55 pm »
Imagine the following setup:

A delegate is running behind a firewall, being able to connect ONLY to specific peers list (relays, spread throughout the world) owned by the delegate's owner.
Each relay does not share the delegate's IP with its peers. (Is this implemented? Will it be?)

The result should be private delegate IP known only to the relays (which are owned by the same person).
A consequence should be that DDOS attack against any of the relays will not stop the delegate from producing blocks. In order to stop the delegate you should either DDOS its IP (which is unknown) or take down all the relays (GL with that).

Am I correct?

If hiding peer's IP (relay not sharing the delegate's IP) is already implemented - how to enable it ?

1189
Why not naming it something meaningful for everyone and using that (full) name everywhere until people start using abbreviation(s)?

Bitshares Base ?

1190
Why not naming it something meaningful for everyone and using that (full) name everywhere until people start using abbreviation(s)?

1191
General Discussion / Re: Approval Voting vs Delegation
« on: June 23, 2014, 08:14:28 am »
Top 101 cannot all have 66 %. If each share holder is limited to 33 votes.   The best they could achieve is 66 delegates with 33% each. 
Got it! Thanks!

So a person cannot vote for more than 33 delegates with his whole stake. So this is approval voting with limit of maximum votes to 33% of 101 (number of elected delegates).
And the reason for this limitation is transaction size ?

1192
General Discussion / Re: Approval Voting vs Delegation
« on: June 23, 2014, 07:00:08 am »

The approach implemented allows each share to vote for a max of 1/3 of delegates.  This means someone with 33% is guaranteed representation. 


How this guarantees representation for a 33% stake?
Imagine 1000 registered delegates. Top 101 with 66% approval each. The entity controlling 33% stake could never elect his own delegate.

1193
General Discussion / Re: Approval Voting vs Delegation
« on: June 23, 2014, 06:48:30 am »
I need to ban BM from posting without PR review.

We aren't diluting the first chain, end of story. Edit: by "we" I mean "anywhere I have the final say"... looks like me amd dan and stan are out of sync about wtf the plan is

"Randomness" is an OPTIONAL feature for OPTIONAL PRIVACY ENHANCEMENT. Delegates are NOT selected randomly, you just fuzz your votes over time IF YOU SO CHOOSE.
A PR wouldn't allow you to post this also... publicly stating people inside the organization are "out of sync about wtf the plan is" doesn't do much about the confidence of potential investors.

1194
General Discussion / Re: Clarifications about BTS X plan
« on: June 23, 2014, 06:41:26 am »

It's non of the devs issues to educate the people in a proper way .. its the task of the investor do research BEFORE investing

Anyway .. i see the community failing could and should do better in explaining BitShares ecosystem, BitShares XT and BitShares X to the masses.
However, once the community wrote sth. it's up the the people to READ it.

BTW. this forum has neat feature called 'search'

Though it is wise all the information investor needs to be systematic, conscious and easy to understand. This could be done even removing most of the details about the implementation and other stuff. Just state what problem is solved and how could one use the product. Make sure to include as little details as possible. Those who need technical details will find it anyway.

1195
General Discussion / Re: Attack scenario
« on: June 22, 2014, 06:58:07 am »
*Autovoting algorithms that can be gamed
Autovoting algorithm exploitation depends on the predictability of the voting algorithm not on the voting system. One can still exploit it even in approval voting.

*Cat and mouse of trying to vote down delegates
Yes. Having exclusive voting system (able to vote for only one entity) and ability to switch vote, enables a lot of vote-switching scenarios.

*Downvoting has too much opportunity cost
As I said I don't like exclusive vote - if you downvote you should still be able to upvote. However this particular moment needs more research.

*Large shareholders profit from voting themselves to be delegate or negotiating kickbacks.
The idea in DPOS is - shareholders elect delegates. If there is a large shareholder he will elect his own delegate(s).
As the votes are public negotiating will be always possible. Imagine the deal: You vote for me, I vote for you, none of us vote for anyone else.

*Small shareholders most likely don't get these benefits or can't negotiate kickbacks
This is correct in both systems. Negotiating efforts should produce value - you dont negotiate for 10 units but you will do it for 10 mil.

*No incentive for delegates to reinvest profits to help the DAC
Votes are always incentive. Most people will elect delegate that helps the system. These just for profit might not stay unless backed by large shareholders.

*Attacking entity can buy 50+ delegate positions through kickbacks
Where is that explained?

*Shareholders can't vote for all delegates they trust (must pick 1 at time)
Yes! This could be an issue. (although you can spread your stake by % )

*Person with 3-4% has lots of power (can basically vote in or out a handful of delegates at will)
Correct! And even such person could manipulate the autovote easily as I stated initially.

*Delegates don't need/have broad community support
Yes, but they must not irritate a lot of people because they could downvote them. Which is costly (unless upvoting/downvoting is not exclusive)

*Pulls community and shareholders apart instead of bringing them together.
*Is confusing and not intuitive
*Ruins our one chance to make a great 1st impression on 1st time users.
... cant comment on this.

It looks like approval voting is better. Although there are still things to consider.

1196
General Discussion / Re: Dry Run 4: A New Hope
« on: June 22, 2014, 06:06:46 am »
One of my test delegates that I intentionally made misbehaving is not getting downvotes although he has 35 missed blocks.

322         secondtester             89026995            0                   0.0008904976421 %   0               35

1197
General Discussion / Re: Attack scenario
« on: June 21, 2014, 06:15:15 pm »
And as bytemaster proposed hardfork with removal of balances voting for misbehaving entity => this might affect LAZIES which are presumably normal lazy users who let the software autovote for them. Hardforking without their stake might be something even more evil than EVIL's initial plan.

1198
General Discussion / Re: Dry Run 4: A New Hope
« on: June 21, 2014, 03:50:15 pm »
This is what happens with late friday fixes/relases (: .
Go get some sleep and rest - Its weekend.

1199
General Discussion / Re: Dry Run 4: A New Hope
« on: June 21, 2014, 12:34:15 pm »
do you connect through 107.170.30.182:8763 ?
,{
    "addr": "107.170.30.182:38519",
    "addrlocal": "xxx.xxx.xxx.xxx:xxxxx",
    "services": "00000001",
    "lastsend": 1403353891,
    "lastrecv": 1403353921,
    "bytessent": 121024,
    "bytesrecv": 82512,
    "conntime": "20140620T214351.588474",
    "pingtime": "",
    "pingwait": "",
    "version": "",
    "subver": "bts::net::node",
    "inbound": false,
    "firewall_status": "not_firewalled",
    "startingheight": "",
    "banscore": "",
    "syncnode": "",
    "bitshares_git_revision_sha": "e724df5e08f57522cc69406c7b8f3164952cdacf (different from ours)",
    "bitshares_git_revision_unix_timestamp": "20140620T203400",
    "bitshares_git_revision_age": "16 hours ago (older than ours)",
    "fc_git_revision_sha": "accb6fddcbde110600edaf46de4a749130b90046 (same as ours)",
    "fc_git_revision_unix_timestamp": "20140619T195141",
    "fc_git_revision_age": "41 hours ago (same as ours)",
    "platform": "linux"
  }

1200
General Discussion / Re: Dry Run 4: A New Hope
« on: June 21, 2014, 12:26:22 pm »
"blockchain_head_block_num": 1070,
  "blockchain_head_block_time": "20140621T122530",
  "blockchain_head_block_time_rel": "24 seconds old",
  "blockchain_confirmation_requirement": 303,
  "blockchain_average_delegate_participation": 61.585365853658537,
  "network_num_connections": 40,
  "ntp_time": "20140621T122554.457943",
  "ntp_error_seconds": -0.0040379999999999999,

Pages: 1 ... 73 74 75 76 77 78 79 [80] 81 82 83 84 85 86