PTS Forum

Discussion => General Discussion => Topic started by: Empirical1 on November 18, 2014, 01:52:53 am

Title: 101 delegates too many?
Post by: Empirical1 on November 18, 2014, 01:52:53 am
I've noticed Rand Paul Coin is looking to start with only 13 delegates, that's too few imo, but I think there is an argument for fewer delegates especially in a no inflation DAC. (Lower cost.)

I also think nobody knows who the 101 delegates in BTS are, but fewer might get more attention, interest and be more accountable. Even 51 seems like a lot in practice to me. What do others think?
Title: Re: 101 delegates too many?
Post by: freetrade on November 18, 2014, 08:00:19 am
I think we should pick a different number, even if just to differentiate from other DPOS assets.

How about 23?
Title: Re: 101 delegates too many?
Post by: pc on November 18, 2014, 08:29:30 am
We've already discussed that topic:


I am not sure about the impact on the PTS network security if we are to lower the 101 delegate count.  My view is not to change it unless we know how it would impact the security.

Yes, it was probably a stupid idea. Lowering the number doesn't help us at all, it only makes a 51% attack easier.

For a successful 51% attack, the attacker must control more than 50% of the delegates. So for a 51% you need to control only 37 out of 73 delegates, as opposed to 51 out of 101. In reality this will only start playing a role when we have more than 73 different people running a delegate each. This is unlikely to happen soon, so in the short term my idea wouldn't impact security in any way, but in the long run it would make things worse.

IMO 13 delegates is ridiculous. Even if you have 13 different people each running a delegate, only 7 of these must coordinate for a 51% attack. Supposing you have 13 people willing to run delegates it doesn't matter cost- or security-wise if each one of these runs 1 delegate or 8 (hint: you can have many active delegate accounts in one wallet). But in the instant that a 14th guy comes along and offers to run a delegate it *does* matter. Suddenly you need to coordinate more than 7 people for a successful attack, without changing the network parameters. The 14th guy also doesn't change the cost to the network, as delegates are currently paid only from tx fees. That's why starting with 101 delegates doesn't cost anything, but saves you a hardfork later when more delegate-people are available.

Now, the real problem is that for the start we probably won't have even 13 people. We need volunteers (http://pts.cubeconnex.com/index.php?topic=30.0), so if you want to run one or more delegates right from the start give us a pubkey or two and if it's up to me I'll include your delegate in the genesis block.
Title: Re: 101 delegates too many?
Post by: cube on November 18, 2014, 09:29:52 am
I think we should pick a different number, even if just to differentiate from other DPOS assets.

How about 23?

We should have sufficient number of delegates to minimise the chance of attack via collusion among delegates.  101 seems a 'safer' number to start with.

What is your concern to have a smaller number of '23'?
Title: Re: 101 delegates too many?
Post by: fuzzy on November 18, 2014, 10:15:53 am
I've noticed Rand Paul Coin is looking to start with only 13 delegates, that's too few imo, but I think there is an argument for fewer delegates especially in a no inflation DAC. (Lower cost.)

I also think nobody knows who the 101 delegates in BTS are, but fewer might get more attention, interest and be more accountable. Even 51 seems like a lot in practice to me. What do others think?

I think RPCDev stated that with 13 delegates, tx times would approximate at 20seconds.  He/She did it because it represented the first 13 colonies of these United States.  Imho, this is perfect as 13 state campaign headquarters could each run a delegate that gets voted in.  They would likely direct 100% of tx fees to the campaign AND promote it in order to ensure a huge marketcap (which just  makes them more money over time). 
Title: Re: 101 delegates too many?
Post by: freetrade on November 18, 2014, 06:45:56 pm

IMO 13 delegates is ridiculous. Even if you have 13 different people each running a delegate, only 7 of these must coordinate for a 51% attack. Supposing you have 13 people willing to run delegates it doesn't matter cost- or security-wise if each one of these runs 1 delegate or 8 (hint: you can have many active delegate accounts in one wallet).

I think attacks are more likely to come from 1 person running multiple delegates rather than multiple people co-ordinating.

So in the example above, you'd need 1 guy running 7 delegates. I don't see that it's much more difficult to control 7 out of 13 delegate than it is to control 51 out of 101 delegates.

Indeed, it might be easier for one person to hide 51 delegates among 101, because no-one can keep track of who is running the 101 delegates. Whereas if there 13 delegates you'd be easily able to keep track of who had which delegate.

So perhaps more delegates is not always better - especially with a DPOS asset with lower community interest. There's a balance to be reached, for PTS, probably greater than 13, probably less than 101.
Title: Re: 101 delegates too many?
Post by: cube on November 19, 2014, 08:01:30 am

I think attacks are more likely to come from 1 person running multiple delegates rather than multiple people co-ordinating.

So in the example above, you'd need 1 guy running 7 delegates. I don't see that it's much more difficult to control 7 out of 13 delegate than it is to control 51 out of 101 delegates.

Indeed, it might be easier for one person to hide 51 delegates among 101, because no-one can keep track of who is running the 101 delegates. Whereas if there 13 delegates you'd be easily able to keep track of who had which delegate.

So perhaps more delegates is not always better - especially with a DPOS asset with lower community interest. There's a balance to be reached, for PTS, probably greater than 13, probably less than 101.

Could you elaborate on the 'bold' part?
Title: Re: 101 delegates too many?
Post by: freetrade on November 19, 2014, 08:22:52 am

I think attacks are more likely to come from 1 person running multiple delegates rather than multiple people co-ordinating.

So in the example above, you'd need 1 guy running 7 delegates. I don't see that it's much more difficult to control 7 out of 13 delegate than it is to control 51 out of 101 delegates.

Indeed, it might be easier for one person to hide 51 delegates among 101, because no-one can keep track of who is running the 101 delegates. Whereas if there 13 delegates you'd be easily able to keep track of who had which delegate.

So perhaps more delegates is not always better - especially with a DPOS asset with lower community interest. There's a balance to be reached, for PTS, probably greater than 13, probably less than 101.

Could you elaborate on the 'bold' part?

I mean if we have 10 active members with 1 delegate each, and require 101 delegates, that's 91 delegate spots up for anonomous, and potentially bad actors.

Principle is that it is easier for bad actors to hide in a large city than in a small village.
Title: Re: 101 delegates too many?
Post by: randpaulcoindev on November 21, 2014, 06:19:33 am

There are these init-delegates that appear to be running by whoever initializes the chain.  Starting out with 101 delegates is going to take a serious VPS.

FreeTrade is right - it is not really any easier to 51% attack via sybil-delegate attack with 13 delegates.  It is not any easier 51% attack via owning stake.

13 was chosen because it is a workable number. It appears to be a simple constant in a header file. I'm working under the assumption it can be easily changed.  Indeed, if the market cap of RPCD goes up by much then we will look to add delegates.

With 13 delegates, the transaction fees are split by 13 people.  This makes far more economic sense for a chain that is starting out with an unknown market cap.  It is also easier to have 13 fully unique delegates.  These incentives give better security for a coin that might not have a large cap at the beginning.  101 delegates is a big fail all over although is a lot more appropriate for something like BTS.
Title: Re: 101 delegates too many?
Post by: freetrade on November 21, 2014, 06:52:09 am
13 was chosen because it is a workable number. It appears to be a simple constant in a header file. I'm working under the assumption it can be easily changed.  Indeed, if the market cap of RPCD goes up by much then we will look to add delegates.

I'm assuming this would be a forking change?

pc, have you re-considered your position in the light of these arguments? If not, can you tell us why?
Title: Re: 101 delegates too many?
Post by: pc on November 21, 2014, 01:27:57 pm

There are these init-delegates that appear to be running by whoever initializes the chain.  Starting out with 101 delegates is going to take a serious VPS.

Our plan is to find at least 3 volunteers and split the initial delegates among those. More will be better of course, as long as there are reliable candidates.
You don't need a serious VPS to run 101 delegates. I have split the 101 delegates of our PTS test network on 2 servers. The trick is that you don't need to run 101 instances of the wallet in parallel, instead you can load all of your delegates into a single wallet and open that in a single instance.

13 was chosen because it is a workable number. It appears to be a simple constant in a header file. I'm working under the assumption it can be easily changed.  Indeed, if the market cap of RPCD goes up by much then we will look to add delegates.

I don't think you can change to constant so easily. The order in which delegates have to generate blocks depends on the total number of delegates. If you start a chain with 13 delegates and later increase the number, the newly compiled client will most likely choke on your blockchain, because it will look like delegates created block when it wasn't their turn. I suggest you try this out before starting your chain.

With 13 delegates, the transaction fees are split by 13 people.  This makes far more economic sense for a chain that is starting out with an unknown market cap.  It is also easier to have 13 fully unique delegates.  These incentives give better security for a coin that might not have a large cap at the beginning.  101 delegates is a big fail all over although is a lot more appropriate for something like BTS.

101 initial delegates != 101 different people. In fact we would be very happy if we had 13 different people reliably running initial delegates. But once we have 14 different people we will instantly have better security with 101 delegates than with 13, without requiring a hard fork.

You're arguing that it is easier to have 13 fully unique delegates. I agree. However, I also think it is much easier to generate the 7 fake identities required for a 51% attack.
I'm working on the assumption that we won't have 101 unique delegates, but that we can split the delegates across the people we have and scale from there. In the beginning we won't be better off than with only 13 delegates, but we will be better as soon as we have 14 unique persons.
Title: Re: 101 delegates too many?
Post by: randpaulcoindev on November 21, 2014, 04:32:18 pm


This is definitely some great insight. I will need to rethink and test things. Once I get a decent snapshot then we'll move to testnet.

Are 13 delegates actually more or less secure?  I suppose it might depend on the size of the initial community and how many distinct identities are willing to take over roles.
Title: Re: 101 delegates too many?
Post by: randpaulcoindev on November 21, 2014, 09:32:00 pm


Another thought that is key. 

With too many delegates, there are not  proper incentives because they simply are not paid enough.  So by having less real delegates, there is more opportunity for people who are wanting to 51% attack by Sybil.
Title: Re: 101 delegates too many?
Post by: freetrade on November 22, 2014, 05:31:21 am
However, I also think it is much easier to generate the 7 fake identities required for a 51% attack.

I think it is just as easy to generate 7 fake identities running 8 delegates each. This is the key point that you haven't refuted.

Another question, if more delegates are better, why stop at 101. Why not 103 or 1003?

 
Title: Re: 101 delegates too many?
Post by: pc on November 22, 2014, 09:13:34 am
However, I also think it is much easier to generate the 7 fake identities required for a 51% attack.

I think it is just as easy to generate 7 fake identities running 8 delegates each. This is the key point that you haven't refuted.

Again: with 101 initial delegates we're no better or worse than with 13 initial delegates - as long as we don't have more than 13 independent people willing to run them. But at the moment we have 14 independent people we will be better off with 101 initial delegates. At that point it will no longer be sufficient to create 7 fake identities, you will need 8.

Another question, if more delegates are better, why stop at 101. Why not 103 or 1003?

101 is an arbitrary number chosen by bm, yes. Actually I think he chose 100 first and later he realized that this could easily result in two forks with 50 delegates each. With 101 there's always a majority.

Any other arbitrary (odd) number could be chosen as well, yes. But a higher number is only a real improvement if you have enough independent people willing to run them. It is unlikely that we will find 1003 different people willing to run reliable delegates. It is less unlikely that we will find 101, and I think it's almost certain that we will find more than 13 over time.
OTOH, more delegates certainly create more overhead. I don't know how significant that is, but it means we have to make a tradeoff between the potential security improvement of more initial delegates and the additional overhead created by more initial delegates. I really don't care if it's 97 or 101 or 103, but IMO it should be much more than 13 and much less than 1003.
Title: Re: 101 delegates too many?
Post by: lamont on November 23, 2014, 01:12:07 am


Another thought that is key. 

With too many delegates, there are not  proper incentives because they simply are not paid enough.  So by having less real delegates, there is more opportunity for people who are wanting to 51% attack by Sybil.

This makes sense.  101 delegates would not be paid enough to entice anywhere near 101 real delegates.  Fake delegates would have far more power since there would be no legitimate competition.
Title: Re: 101 delegates too many?
Post by: freetrade on November 23, 2014, 08:52:42 am
I feel like I'm going round in circles with pc on this, with neither of us convincing the other. I don't think it's a critical issue, so I'm going to bow out with this my final statement -

I'm not convinced by pc's arguments and favor fewer delegates for the PTS project, (more than 20, fewer than 40) for reasons of improved security, transparency and efficiency.

Title: Re: 101 delegates too many?
Post by: fuzzy on November 23, 2014, 02:24:08 pm
I have no clue why everyone is talking like this is set in stone...

This project is a NEW BEGINNING.  At first, it will need to be slightly more centralized to give delegates the pay required to build infrastructure, market, organize community and otherwise infuse value into the ecosystem.  The amount of delegates can be voted on when there are problems that a large number of community members agree necessitate an expansion in the number of said delegates. 

Let's not be too rigid here guys and girls.  Run a testnet and TEST it.  Then come back with results...and TEST it again until you find the perfect number of delegates given the current marketcap and adoption rate.  PTS can bring GREAT value to the entire DPOS ecosystem, if we take painstaking steps to test and learn...and teach others in the process. 

If you want PTS to be sharedropped on non-stop for the rest of eternity, you need it to be a DAC and Delegate Factory.  The lessons learned from testing things will make for a much more efficient Factory...and will ensure higher quality products are sharedropped on us.  Isn't that what we all want?
Title: Re: 101 delegates too many?
Post by: pc on November 23, 2014, 05:58:24 pm
It's not set in stone. There really is no right number of delegates. There are just lots of wrong numbers, like those below 14 or above 1002, and all non-prime numbers.

freetrade does have a point wrt transparency + efficiency, but we disagree on security.

We can't really test the problem either, as this is not about technology. I'm sure we can just change the number in the code, start a new test chain with 7 delegates (or 2003) and it will just work. That won't tell us anything about security or transparency though.

Anyway, we currently have bigger fish to fry than trying to find the ideal number of initial delegates.
Title: Re: 101 delegates too many?
Post by: Empirical1 on November 23, 2014, 10:57:14 pm
Yeah it's not too serious but I don't think starting lower and increasing it to 101 as network fees allow is a bad idea.
Title: Re: 101 delegates too many?
Post by: fuzzy on November 24, 2014, 02:30:04 am
I was under the impression that the only thing corrupt actors could do in DPOS was refuse to sign blocks...at which point they would be quickly voted out.  So why not simply keep it low starting out and go up? 

Can I get like a bulleted list of reasons for and against this?
Title: Re: 101 delegates too many?
Post by: pc on November 24, 2014, 01:57:40 pm
I was under the impression that the only thing corrupt actors could do in DPOS was refuse to sign blocks...at which point they would be quickly voted out.

If you have 51% of delegates you can have them sign blocks without publishing them.
You send lots of BTS to bter (for example). You wait until the transaction has been included in a block by one of the remaining 49% of delegates. Meanwhile, in your own private fork signed by 51% of the delegates you transfer the money to a different account belonging to yourself. After bter has credited your account, you publish the fork signed by your own delegates. The network should accept your fork because it has the majority of active delegates, and you have successfully double-spent your money.

Note also that the network can't vote you out, because with 51% of the delegates you can refuse transactions that vote against you.

  So why not simply keep it low starting out and go up? 

Can I get like a bulleted list of reasons for and against this?

- Changing the number of delegates requires a hard fork. (In theory, haven't tested this.) We want to avoid hard forks as much as possible.
- If we start with a number that's too low (i. e. less than the number of independent delegates) we are less decentralized (and therefore less secure) than we would be with a higher number.
- Starting with a higher number and having each delegate-person run multiple delegate-accounts is in almost every aspect equivalent to starting with a low number and having one delegate-account per delegate-person.
+ The presumably small fee volume is spread across many delegates, making running a delegate less attractive.
+ Freetrade argues that with a high number of delegates there is less accountability (my wording). I. e. it would be easier to hide a lot of fake identities in a large delegate crowd.
Title: Re: 101 delegates too many?
Post by: fuzzy on November 26, 2014, 06:51:46 am
- Changing the number of delegates requires a hard fork. (In theory, haven't tested this.) We want to avoid hard forks as much as possible.

It makes sense to want to minimize hard forkss...I guess the question though is whether or not it is worth it to do it early to get it perfect (if this is possible) or potentially have bigger problems down the road.  I don't know the right answer though so I'll leave it to the engineers ;)

- If we start with a number that's too low (i. e. less than the number of independent delegates) we are less decentralized (and therefore less secure) than we would be with a higher number.

I am not really necessarily against it being less decentralized in the early days.  In my opinion, if we have a group of core people early on we are more centralized (at first), but can be more agile... focusing efforts in areas where BTS has difficulty adapting.  There are some very important initiatives we need to head up in my humble opinion, if we want to establish ourselves as the "Berkshire Hathaway" of crypto-equities. 

1)  Funding general user education/best practices content
2)  Funding easy solutions for safely claiming sharedropped stake
3)  Funding for highly secure storage solutions for customer funds

I have many more, but these should be the first to be considered as they are things BTS has largely ignored due to its problems with too much decentralization for the number of tools available to adequately overcome. 

Why not be leaner and quicker on our feet compared to BTS, until a certain point?  Make a chart with various marketcaps and have it set up so we know that when we reach and sustain certain marketcap, that the system will be forked to allow for a larger number of delegates.  This way, as we grow, the forks are already predetermined (making them much less volatility-inducing) along with the increase in delegate number. 

I believe centralization in early stages is almost necessary to be able to overcome some of the biggest hurdles we face.  The biggest issue is making sure the whole project scales in such a way that lowers barriers to entry and divides power amongst a larger and larger group as the PTS network grows.   


- Starting with a higher number and having each delegate-person run multiple delegate-accounts is in almost every aspect equivalent to starting with a low number and having one delegate-account per delegate-person.
+ The presumably small fee volume is spread across many delegates, making running a delegate less attractive.
+ Freetrade argues that with a high number of delegates there is less accountability (my wording). I. e. it would be easier to hide a lot of fake identities in a large delegate crowd.

The bolded portion above is a very good point.   Perhaps it would be beneficial to do this instead of the prior solution offered.  However, I am still kind of curious how we will make it so those running delegates will gradually cede power to other delegates... 
If we are not careful, voter apathy will ensure the oldest delegates simply stay in power.  Over long periods of time, there is a very real concern of the centralization of stake (and thus voting power), which further ensures the early delegates never can be taken out of power. 

We need to come up with a plan...
Title: Re: 101 delegates too many?
Post by: pc on November 26, 2014, 08:58:24 am
However, I am still kind of curious how we will make it so those running delegates will gradually cede power to other delegates... 

If we are not careful, voter apathy will ensure the oldest delegates simply stay in power.  Over long periods of time, there is a very real concern of the centralization of stake (and thus voting power), which further ensures the early delegates never can be taken out of power. 

We need to come up with a plan...

Our immediate concern is a different one: we need to get sufficient stake voting for our initial delegates to prevent a medium-sized stakeholder (or group) from taking over the network.

It really is out of our hands after the chain has been launched. The voters decide who the delegates are. The rest is lobbying.
The only good thing here is that large stakeholders should have a high interest in protecting the chain and make therefore wise decisions, actively.
Title: Re: 101 delegates too many?
Post by: fuzzy on November 26, 2014, 09:09:53 am
However, I am still kind of curious how we will make it so those running delegates will gradually cede power to other delegates... 

If we are not careful, voter apathy will ensure the oldest delegates simply stay in power.  Over long periods of time, there is a very real concern of the centralization of stake (and thus voting power), which further ensures the early delegates never can be taken out of power. 

We need to come up with a plan...

Our immediate concern is a different one: we need to get sufficient stake voting for our initial delegates to prevent a medium-sized stakeholder (or group) from taking over the network.

It really is out of our hands after the chain has been launched. The voters decide who the delegates are. The rest is lobbying.
The only good thing here is that large stakeholders should have a high interest in protecting the chain and make therefore wise decisions, actively.

People severely underestimate the value of Mumble hangouts, imho.  I distinctly remember when the BTS merger proposal happened and the BTSX price started tanking.  We held an emergency Mumble Hangout and I literally watched as Dan talked and answered questions and the market slowly gained traction again. 

The reason for this is that the incentives are perfectly aligned to bring in the largest stakeholders.  Why?  Because the largest stakeholders are also the ones with the strongest incentive to want to ask the Dev questions...and to even hold them accountable.  Since it is a town-hall format where anyone can ask questions, they are generally very willing to show up.  If you want to get the biggest stakeholders together at the same time, the best way to do it is to have regular Dev Hangouts.

 Help me get a trusted delegate slate working (using this code made by xeroc:  https://github.com/xeroc/delegate-slate/blob/master/.gitignore) and we can make it one-click to vote for a large number of trusted INITIAL delegates.  After hangouts, I will say that if people appreciate my efforts, to please consider voting for the Beyond Bitcoin Delegate Slate...and the people who will be there will likely be those with the largest stake. 

This is a (partial?) solution to the stated problem.  People are not necessarily willing to tip, but I am almost certain that a delegate voting slate link would be easy to get them to click.   
Title: Re: 101 delegates too many?
Post by: pc on November 27, 2014, 08:45:55 am
Our immediate concern is a different one: we need to get sufficient stake voting for our initial delegates to prevent a medium-sized stakeholder (or group) from taking over the network.

I have thought about this and come up with an idea:

We can have the genesis stake vote for the initial delegates in a random distribution, with a target of (for example) 5% votes per delegate on average. This will secure the network from block #1.

The tricky part here is the fine tuning: choosing a low target makes attacks easier, choosing a high target means that the initial delegates will be difficult to get rid of when it becomes necessary.

@fuzzy: your suggestion regarding the delegate slate is good, we should do that in any case.
Title: Re: 101 delegates too many?
Post by: cube on November 27, 2014, 10:33:28 am
Our immediate concern is a different one: we need to get sufficient stake voting for our initial delegates to prevent a medium-sized stakeholder (or group) from taking over the network.

I have thought about this and come up with an idea:

We can have the genesis stake vote for the initial delegates in a random distribution, with a target of (for example) 5% votes per delegate on average. This will secure the network from block #1.

The tricky part here is the fine tuning: choosing a low target makes attacks easier, choosing a high target means that the initial delegates will be difficult to get rid of when it becomes necessary.

@fuzzy: your suggestion regarding the delegate slate is good, we should do that in any case.

I do not think tinkering the voting system this way is worth the risk.  At the root of the issue for all DPOS-based crypto is voter apathy.  A delegate slate can be a temporary work-around. We need to find a way to increase participation from the voters.
Title: Re: 101 delegates too many?
Post by: pc on November 27, 2014, 10:50:39 am
We can have the genesis stake vote for the initial delegates in a random distribution, with a target of (for example) 5% votes per delegate on average. This will secure the network from block #1.

The tricky part here is the fine tuning: choosing a low target makes attacks easier, choosing a high target means that the initial delegates will be difficult to get rid of when it becomes necessary.

@fuzzy: your suggestion regarding the delegate slate is good, we should do that in any case.

I do not think tinkering the voting system this way is worth the risk.

There is not much tinkering to be done. This is the relevant code in chain_database.cpp line 257:

Code: [Select]
            balance_record initial_balance( addr,
                                            asset( share_type( initial.low_bits() ), 0 ),
                                            0 /* Not voting for anyone */
                                          );

The big advantage is that we have built-in security against delegate takeover right from the start. After that, voters can settle in and appoint real delegates.

At the root of the issue for all DPOS-based crypto is voter apathy. 
We need to find a way to increase participation from the voters.

+1
Title: Re: 101 delegates too many?
Post by: cube on November 28, 2014, 10:17:13 am
Thank you all for presenting your points and putting up a passionate debate and discussion.  A vigorously discussion/debate with input from various perspectives helps us to make a sound decision for PTS.

If there is no objection, we will take up pc's recommendation and turn on 'genesis stake vote'.
Title: Re: 101 delegates too many?
Post by: pc on December 01, 2014, 01:58:25 pm
We can have the genesis stake vote for the initial delegates in a random distribution, with a target of (for example) 5% votes per delegate on average. This will secure the network from block #1.

Implemented and push to develop branch. Vote ratio is configurable in pts_config.hpp.
Title: Re: 101 delegates too many?
Post by: randpaulcoindev on January 27, 2015, 08:41:08 pm

As for my coin is, I look back to 101 from 29 Delegates. My thinking is that people will be able to run these things out of the house. I think smaller network with 25 second blocktimes should be able to handle it. The idea is to get buy-in from people who can work in the console window of windows and use their home computers. I'll write some tutorials about firewalls, etc. There really does not seem to need to VPS's that much (chain servers?), and now, if people do not have to use the command line a lot, just run the CLI window and follow the instructions, then I think we might just be able to get a lot of people excited about being delegates. Of course it will make a profit even less so ... compromises in abundance.
Title: Re: 101 delegates too many?
Post by: fuzzy on February 05, 2015, 12:12:31 am

As for my coin is, I look back to 101 from 29 Delegates. My thinking is that people will be able to run these things out of the house. I think smaller network with 25 second blocktimes should be able to handle it. The idea is to get buy-in from people who can work in the console window of windows and use their home computers. I'll write some tutorials about firewalls, etc. There really does not seem to need to VPS's that much (chain servers?), and now, if people do not have to use the command line a lot, just run the CLI window and follow the instructions, then I think we might just be able to get a lot of people excited about being delegates. Of course it will make a profit even less so ... compromises in abundance.

It will only make less profit initially.  I plan on helping build up many communities just like I helped with BTS and I believe that over time we will see a large explosion in the interest of becoming a delegate. 
I'm actually very interested in your project as I was a strong Ron Paul supporter.  I was less of a Rand Paul supporter but honestly think he was just "playing the game"...never-the-less your pivot to RonPaulMoney is one I back.