Quote from: liondani on May 22, 2014, 01:16:36 pm

Quote from: Bytemaster

There has been significant progress and developments over the past several days.   One of the most significant is the introduction of a random number generation scheme and random delegate selection today.   This was done for two reasons: it resolves a security vulnerability discovered with sequential DPOS and it facilitates one of the more challenging parts of the Lotto DAC.

We have implemented UPNP networking.

The news getting better and better

Right

Becoming a delegate requires:

1) Ability to run provided software on a low-latency connection 
2) Ability to setup a secure linux environment
3) Ability to get 1% of the vote...
      a) unique geographic location
      b) trusted member of the community
      c) 1000 BIPS  (a couple of PTS or AGS) registration fee... (keep out spammers)

Remaining a delegate requires:
      a) low latency, 99.9% uptime
      b) non-discrimination of valid transactions
      c) better reputation than all but the top 99

How to earn the best reputation:
      a) Provide the most additional services for your pay.
            - seed node supporting thousands of connections
            - block explorers
            - free web wallets
            - high speed blockchain downloads
      b) Provide the most proof as to your transparency
     

You get the idea... who ever is willing to provide the most service for their pay will likely win over someone attempting to provide the least service. 
 
     

http://107.170.30.182/security/delegated-proof-of-stake.php

Quote from: bytemaster on March 30, 2014, 02:17:44 am

The key thing with notaries is that they must be prepared to have servers with very high uptime and redundancy. 

If you have multiple notaries, this is unnecessary.  In fact, having multiple notaries and fast recovery from a single notary going offline means that there's really no reason an ordinary node can't serve as notary.

So I propose using a random selection algorithm (Poisson process) to add notaries one at a time, and have the oldest notary's term expire if there are too many.  Thus notary duty is not for some elite users with fast servers and connections to the right people to get into a hard-coded list somewhere, rather it is open to any node, with your chance to be selected proportional to your balance.  (As I've explained previously, both here and elsewhere, not using your balance to determine the weight of your vote makes it easy to game the system by making a large number of addresses with tiny balances.)  You get the benefits of fork protection and predictable block times, but the degree of centralization is actually quite limited.

To alleviate uptime concerns, I propose a five-stage scheme:  Unknown, pending, eligible, secondary, primary.  Unknown nodes are most of the network most of the time.  Pending nodes have been selected by the random selection algorithm as potential notaries, but they have to pass an uptime test by signing every block for UPTIME_TEST_LENGTH = 1 hour.  Eligible nodes have successfully passed the uptime test and are waiting for a "seat" to open up.  Secondary / primary refer to active notaries; primary notary duty rotates every block.