I think there is a place for PTS to be the litecoin/liteshares of the dpos world. A simple dpos implementation without all the bells and whistles of bitshares. The new merged bitshares is hugely ambitious and complex. There is a place for a simple dpos asset that has had a fair distribution and has a recognized brand. PTS holders might as well capture this value rather than some other altcoin.

Quote from: FreeTrade on November 07, 2014, 08:34:27 am

If the same holds true for BitShares Music, and a dilution of up to 8% p.a. is allowed to fund delegates, what's to stop an individual amassing an 8% stake and awarding the full 8% dilution to themselves?

The other 92% which overtime start realizing that a particular delegate does not increase revenue/profit and as such vote no more for it ... hence the required min. Approval will rise above 8% ..

So it relies on voter engagement? I think the proxy voting (slates) are a good move to increase voter participation, but I don't see there will be sufficient engagement to overcome this problem.

One possible solution - Perhaps delegates should require a minimum of 50% of active votes to draw a salary.

Interested in everyone's take.  Please let me know at least one POW based coin that fulfills a market niche or attempts to act like a DAC to a degree that DPOS would significantly increase the value for its shareholders.

Hmmm, Lottoshares, Chancecoin, devcoin maybe

I would hardly view asking a question as a personal attack but if you took it that way I am sorry.

Sorry, no I didn't view your comments as an attack - that was a fair question.

My other comments are better understood as a general response to other participants screaming scam, trojan, dodgy rep, abandonment, etc.  I should have made a separate post for them.
     

How to handle failing to disclose or vouching cases if applied to DPOS?

And the process seems requiring transaction to communicate, right?

Participants must either vouch or 'blame' other participants. Where a participant is 'blamed' for not revealing a key where he was required to do, the participants must restart the random number generation.

The process requires communication - perhaps messages on the network, but doesn't require those messages to be stored as transactions.

Puh... nice idea .. but for 101 delegates that's > 10 time slots each with 10 transactions containing the secrets for a SINGLE random number .. assuming that this should happen ON the blockchain that would result in a delay of >100sec plus the costs for 100! transactions .. am I wrong?

besides that the scheme sounds solid .. somehow reminds me of ring signatures ;-)

I was thinking of it as a general solution to distributed random number generation - so no need for it to be on the block chain. As long as there is some way to protect against a sybil attack, it might be applicable for a range of uses. But where you have 101 delegates already lined up, that seems like the ideal circumstance. 

Here's my proposal for generating fair random numbers in a distributed manner. I'll explain with a worked example with the smallest number of participants - three.

Three brothers, Jack, Bobby and Teddy agree to have a random draw to choose which one of them wins a prize, but they are in different locations.

They each create a public/private key pair and publish the public keys.

Each brother signs an agreed string with his private key, the resulting signature is his secret. The hash of the concatenated three secrets is used as a seed to generate the random number.

We want to guard against the possibility that one brother has access to the result before he has revealed his secret, enabling him to discard his secret and prevent the result from becoming known.

Round 1.

Step 1. Limited Disclosure
Jack sends his secret to Bobby. Bobby sends his secret to Teddy. Teddy sends his secret to Jack.

Step 2. Vouching
Bobby vouches that Jack has disclosed to him. Teddy vouches for Bobby. Jack vouches for Teddy.

Round 2 (Final Round for 3)
Step 1. Limited Disclosure
Jack sends his secret to Teddy. Bobby sends his secret to Jack. Teddy sends his secret to Bobby.

All three brothers now have all three secrets and can generate the random number.

Let's say Teddy waits in the final round to receive Jack's secret, generates the random number, doesn't like it and doesn't send his secret to Bobby. Bobby can always request Teddy's secret from Jack. As long as a majority are not dishonest or in collusion, the random number generated is fair, and there is no optionality problem.

For DPOS, you'd probably want to use it in combination with the existing chain of delegates - so the block would be generated first with the existing method, and then the random number is generated by N previous delegates. It should be possible to expand to N delegates, using a number of rounds of disclosure and vouching. For 101 delegates, the first round might involve each delegate disclosing to 10 other delegates, followed by vouching, followed by 10 more etc

Sounds like you might be running into a memory problem - the genesis block is big . . maybe adding more memory would help.