You can mine BTS with TaPOS... miners of the world rejoice!

[bitbadger]

I'm feeling uncomfortable about this.  I think that small stakeholders should be able to have a good chance to mine, as well as a good incentive to keep their nodes up and running.

As I understand it, the only way to earn stake now is to mine a block with one of your own transactions in it.... a transaction which destroys your own CD.  So for a small stakeholder, it's a one-shot deal; you save up your CD, then make a transaction (could be back to yourself), and hope that the CDD earns you the block.

I propose a second metric, Stake Days Destroyed, to go along with CDD.  This would also impact the Difficulty.  As SDD goes up, difficulty goes down.  If I hold 30 shares for 30 days, my SDD is 900.  This is the equivalent of somebody with 900 shares holding for 1 day.  The key part is this: My SDD only drops back to 0 when I actually mine a block.  The SDD essentially help the smaller guys "cut in line" by being able to mine easier when they have been saving up their Stake for a long time.  And since Stake is only reset to 0 when a block is mined, it can be transferred from one address to another without being reset.  The stake travels along with the shares and can be additive.  If I've got 0 stake (I just mined a block with my shares) but I buy shares from you, and your shares have stake built up, I receive that stake when I receive the shares, and my chances of mining a block go up again.

I don't know, I just feel that fundamentally, PoS mining should not result in the large stakeholders getting ALL of the blocks.  The chances should be proportional to the stake held by each.  If I own 1/100,000 of the shares, I should have a 1/100,000 chance of mining a block (unless I do something to ruin my chances somehow, such as not allowing my stake to mature or whatever).

I get the idea of TaPoS as encouraging transactions rather than sitting on shares and never trading with them.  But if the only way to earn PoS is to save up your CD for the big shot transaction which is likely to win a block, and to conduct that transaction once per year, this will incentivize perverse behavior as well.  Just leave your client off most of the time, fire it up once per year, make a transaction from one address to another, and then turn it off until next year.  Doing basically nothing to secure the network.

We want to incentivize making transactions, and also incentivize having client nodes running and mining.  I feel like the system as presently described (as well as I understand it, which granted is not fully) does not incentivize the little guys to mine, which leads to concentration/centralization of mining power, which is exactly what we're trying to get away from by moving from PoW to PoS.

EDIT: To elaborate a little more.  Stake is associated only with the shares, not the shareholder.  If I have 2 shares, I mine a block, they now have 0 stake-days, their stake-days start to build up.  If you transfer to me 2 shares, that have not mined a block in 5 days, they now have 10 stake-days (5 each).  Now I have 4 shares, 2 of which have 0 stake-days, and 2 of which have 10 stake-days.  If I send them all 4 at once, they can act as though there are 10 stake-days destroyed as part of that transaction.  Or if I send 1 share to somebody else, I have to pick whether I want to send a 0-stake-day share or a 5-stake-day share.  The system will, by default, keep my highest stake-day shares and send the lowest stake-day shares.

Even when my stake-days have built up, I am not incentivized to spam the blockchain with transactions sending shares back-and-forth from one address to another in hopes of mining a block, because the CDD still contributes the difficulty, and very small CDD will make the difficulty pretty high.  I am not proposing to eliminate CDD, only augment it with a parallel system that works similarly.

[theoretical]

     block_difficulty  =  difficulty(hash_of_block) * coindays_destroyed_by_miner / min_votes 

If block_difficulty is measured in bits, and if this means what I think it means, then it looks like this has pretty extreme nonlinear behavior.  E.g. if we can both easily produce hashes of 12 bits difficulty (12 leading zero bits), and I have 10x as many CDD as you have, then my blocks are rated 120 bits and yours are rated 12 bits.  My effective hashpower is 2^108 times yours.

The "gain" is much too high.  It looks to me like you would get a split where some "unsaturated" addresses need more-hashpower-than-exists-on-earth to pass their target, other addresses are "saturated" and can meet their target in less than a second even if their CPU is from the 1980's, and the "sane" region between the two is so narrow that there's a very high probability it contains zero addresses.  The network might be DoS'able if a modestly wealthy attacker waits until the saturated set consists of only his nodes, then takes them all offline.  And it doesn't really satisfy the goal of electing a unique node (or relatively small set of nodes) to produce a block; I'm not convinced off the top of my head that the saturated set will be small.  And keep in mind that, the smaller the saturated set is, the more the network's vulnerable to the DoS attack.

This is just intuition; a simulation or more detailed mathematical writeup might change my mind.  And I might be mistaken about the meaning of the equation above...

[Agent86]

I have enhanced the mining system in the following way:

When evaluating the difficulty of a block for comparison to the target difficulty, calculate:   

     block_difficulty  =  difficulty(hash_of_block) * coindays_destroyed_by_miner / min_votes 

When evaluating the reward of a block, calculate:
  min_votes      = available_votes / BLOCKS_PER_YEAR
  max_reward   = block_fees / 2
  actual_reward = max_reward - (max_reward*min_votes) / valid_votes

When considering two blocks as a candidate for the 'head block', the one with the most valid_votes wins.

When you mine under this system, the older your balance the easier it becomes to mine.   Large holders of shares will get to produce blocks more frequently than small holders.   This system operates in such a way that those who own only a few BTS are unlikely to accumulate enough CDD to produce a block.  It also means that large holders have a difficult time producing many blocks in a row.  Lastly, it encourages large shareholders to mine regularly with large balances on a single output because this would allow them to maximize the fees they collect while also maximizing the rate at which the network is secured and the difficulty for an attacker to produce an alternative chain.

Lastly this system heavily biases block production by CDD over hash power.  This means how much hash power you apply is almost meaningless to what you earn.  The purpose of the hash power is merely to prevent everyone from submitting a block every time and to give those who apply a little hash power.

You wrote:  block_difficulty  =  difficulty(hash_of_block) * coindays_destroyed_by_miner / min_votes
This looks to me like higher coindays_destroyed_by_miner = higher block_difficulty
I thought that was the opposite of what you wanted.  Am I reading this wrong? or did you mean to say:
block_difficulty  =  difficulty(hash_of_block) * min_votes / coindays_destroyed_by_miner

[Tuck Fheman]

Large holders of shares will get to produce blocks more frequently than small holders.

^ Why I stopped attempting to forge NXT with 1,000 shares.  It's sounding like I (or any small investor) should skip mining BTS as well at this rate.  As far as I can tell, only the early large investors in NXT ever forge a block. So, for us small fries who weren't there zero day ... there really is no point in even trying(?). =/

[theoretical]

That removes the disincentive for centralizing control, which is a feature IMO

The un-accountability of fiduciary pool operators indeed acts as a force against the formation of pools.  But I think this force won't be strong enough, and pools will form regardless.  As the Mt. Gox situation shows, people are all too willing to trust fiduciaries with their money [1].

To elaborate, the OP's system -- as OP rightly notes -- has an incentive to centralize funds in pools.  A pool has reduced variance, and furthermore doesn't suffer from the problem of the very low production rate (with < 1 block / year, your CDD will likely be wiped out by the required annual transaction before it can produce a block).  Thus small-time stakeholders will be encouraged to join a pool.

I'd certainly like to get rid of the incentive to form a pool, but I think it's simply not possible, for the good and simple reason that there will always be customers with small balances who want to reduce their variance.

If you take it as a given that there will be pools regardless of whether my proposal is implemented or not, the course becomes clear:  If it's technologically possible it's better for the network to include a mechanism to make the pools accountable to their participants.  My proposal gives pool participants the power to walk away from a pool that's attempting a 51% attack or otherwise damaging the network or ecosystem.  And allows pool participants a way to obtain the benefits of a pool without requiring them to place fiduciary trust in the pool.

[1] AFAIK, Mt. Gox accounts never produced interest or income, and never promised to do so.  The fact that BTS pools will produce income makes them even more attractive.

[bytemaster]

I have enhanced the mining system in the following way:

When evaluating the difficulty of a block for comparison to the target difficulty, calculate:   

     block_difficulty  =  difficulty(hash_of_block) * coindays_destroyed_by_miner / min_votes 

When evaluating the reward of a block, calculate:
  min_votes      = available_votes / BLOCKS_PER_YEAR
  max_reward   = block_fees / 2
  actual_reward = max_reward - (max_reward*min_votes) / valid_votes

When considering two blocks as a candidate for the 'head block', the one with the most valid_votes wins.

When you mine under this system, the older your balance the easier it becomes to mine.   Large holders of shares will get to produce blocks more frequently than small holders.   This system operates in such a way that those who own only a few BTS are unlikely to accumulate enough CDD to produce a block.  It also means that large holders have a difficult time producing many blocks in a row.  Lastly, it encourages large shareholders to mine regularly with large balances on a single output because this would allow them to maximize the fees they collect while also maximizing the rate at which the network is secured and the difficulty for an attacker to produce an alternative chain.

Lastly this system heavily biases block production by CDD over hash power.  This means how much hash power you apply is almost meaningless to what you earn.  The purpose of the hash power is merely to prevent everyone from submitting a block every time and to give those who apply a little hash power.

 

[Troglodactyl]

Would allowing multiple inputs/outputs for miner transactions actually be a problem?  Apologies if I'm behind on this...

[toast]

What does this mean for mining pools?   It means that they can be very profitable so long as someone is willing to trust the pool with their shares.  A mining pool would be able to cast a large number of ACTUAL VOTES for the least number of bytes (individual transactions).   

Centralization is bad.  A big part of BitShares' strength / value proposition is it gets rid of the necessity of having a fiduciary organization [1] to perform trades between different asset classes.

If pools are encouraged to hold large part of customers' funds because that allows them to be more profitable, that seems like a poor design.

I propose a modification:  Have a new transaction type which allows an address to assign its current and future CDD to another address.  Thus, a single private key controlled by a pool operator can use a minimal number of bytes to vote on a block in representation of a large number of pool participants.  The pool participants get the advantage of the pool, but don't have to give up control of their funds to the pool operator.  You can think of this as "proxy voting" [2] (note, this is not quite the same as "proxy" in computer networking terminology).  You can specify any BTS address to act as your proxy, and you can "fire" your proxy at any time (i.e. you can make a transaction at any time to assign your CDD to a different pool, or give them back to yourself).

It's doable, but there are a lot of implementation details to consider.  I think it'd be prudent to forbid transitive proxies (i.e. if anybody else proxies to you, you can't proxy them onward to somebody else).  Each address has CDD(address, t) which is linear when there are no transactions (my slope, the rate at which I generate CDD's, is equal to my balance plus the funds entrusted to me for proxy voting minus the funds I entrust to others for proxy voting).  A transaction changes the slope, so overall CDD(address, t) is piecewise linear.

[1] By "fiduciary organization" I mean someone who holds money that belongs to someone else.

[2] http://en.wikipedia.org/wiki/Proxy_voting

That removes the disincentive for centralizing control, which is a feature IMO

[bytemaster]

See what your saying, but that is what 5% is for.  5% of 100 BTS is only 5BTS.  While 5% of 100,000 BTS is  5,000

The reason it is a percentage is because all shares need to vote and if a key is lost it helps recover the funds.   The 5% is charged when the miner moves the output forward and thus you can guarantee that you never need more than 100K blocks.   

[theoretical]

What does this mean for mining pools?   It means that they can be very profitable so long as someone is willing to trust the pool with their shares.  A mining pool would be able to cast a large number of ACTUAL VOTES for the least number of bytes (individual transactions).   

Centralization is bad.  A big part of BitShares' strength / value proposition is it gets rid of the necessity of having a fiduciary organization [1] to perform trades between different asset classes.

If pools are encouraged to hold large part of customers' funds because that allows them to be more profitable, that seems like a poor design.

I propose a modification:  Have a new transaction type which allows an address to assign its current and future CDD to another address.  Thus, a single private key controlled by a pool operator can use a minimal number of bytes to vote on a block in representation of a large number of pool participants.  The pool participants get the advantage of the pool, but don't have to give up control of their funds to the pool operator.  You can think of this as "proxy voting" [2] (note, this is not quite the same as "proxy" in computer networking terminology).  You can specify any BTS address to act as your proxy, and you can "fire" your proxy at any time (i.e. you can make a transaction at any time to assign your CDD to a different pool, or give them back to yourself).

It's doable, but there are a lot of implementation details to consider.  I think it'd be prudent to forbid transitive proxies (i.e. if anybody else proxies to you, you can't proxy them onward to somebody else).  Each address has CDD(address, t) which is linear when there are no transactions (my slope, the rate at which I generate CDD's, is equal to my balance plus the funds entrusted to me for proxy voting minus the funds I entrust to others for proxy voting).  A transaction changes the slope, so overall CDD(address, t) is piecewise linear.

[1] By "fiduciary organization" I mean someone who holds money that belongs to someone else.

[2] http://en.wikipedia.org/wiki/Proxy_voting

[Pixar]

See what your saying, but that is what 5% is for.  5% of 100 BTS is only 5BTS.  While 5% of 100,000 BTS is  5,000

[Agent86]

Forcing a yearly transaction can also fight blockchain bloat by guaranteeing that the last year of blocks represents the full balance of all addresses.

I'm not arguing that the yearly transaction requirement or 5% fee is bad, I'm just arguing that it is arbitrarily chosen and can be done better.

I'm not sure that it completely forces a yearly transaction but certainly incentivizes it with a 5% fee.  Do you know in the case that someone loses a private key do they lose 5% per year until the balance is gone after 20 years or do they lose 5% off of the prior year's balance and therefore the balance never really goes away or takes much longer?

Of course the good thing with the Invictus model of using snapshots is you can take a snapshot later and make improvements if these types of changes are not worth exploring right now.

I think the ideal POS system would have the big stakeholders also being the big miners.  If you don't carry your weight and mine proportionally to your stake you will lose relative stake to those who are active and doing the work over the long haul.  There's no point mining far beyond your level of stake for the same reason we don't want people mining who are not stakeholders: because you are only trusted to the limit of your level of stake in the system.

A new user with a few shares doesn't have to do much of anything to maintain their stake, if anything at all; but if you are going to take a big stake in the DAC you need to do the work or start to lose that stake to those who are doing the work.

[Troglodactyl]

To clarify my previous idea, I think if you said accounts lose stake at a rate that is directly proportional to coin days accumulated that this would mean big accounts should move more often to use up their CD.  But overall, if everyone is just holding their money and moving it back and forth at the threshold time all accounts would retain the same respective value.

I'm envisioning that accounts are mining the blocks that include their transactions.

Basically, if you are trying to attack the network by accumulating coin days, the more you accumulate the faster you lose.

Actually, it is the opposite.   As coindays accumulate your mining difficulty falls and your mining reward grows.   The goal is to motivate with a carrot rather than a stick.

My proposal was not related to mining rewards.  You have already suggested a "stick" that is necessary: people must transact once per year or face a 5% penalty and loss of "voting rights."  I am proposing a better stick. (please see my original post preceding the one you quoted)
I may need to draw up something to more clearly demonstrate it or run a test to see how it would play out.  I don't demand you spend time on it if it doesn't strike you as valuable.  I admit I need to do some more reading to more clearly understand your proposed mining rewards.
Incidentally, carrots and sticks are functionally equivalent; you can call it punishing inactivity or rewarding activity but it's the same as I'm sure you are aware.

Forcing a yearly transaction can also fight blockchain bloat by guaranteeing that the last year of blocks represents the full balance of all addresses.

[Agent86]

To clarify my previous idea, I think if you said accounts lose stake at a rate that is directly proportional to coin days accumulated that this would mean big accounts should move more often to use up their CD.  But overall, if everyone is just holding their money and moving it back and forth at the threshold time all accounts would retain the same respective value.

I'm envisioning that accounts are mining the blocks that include their transactions.

Basically, if you are trying to attack the network by accumulating coin days, the more you accumulate the faster you lose.

Actually, it is the opposite.   As coindays accumulate your mining difficulty falls and your mining reward grows.   The goal is to motivate with a carrot rather than a stick.

My proposal was not related to mining rewards.  You have already suggested a "stick" that is necessary: people must transact once per year or face a 5% penalty and loss of "voting rights."  I am proposing a better stick. (please see my original post preceding the one you quoted)
I may need to draw up something to more clearly demonstrate it or run a test to see how it would play out.  I don't demand you spend time on it if it doesn't strike you as valuable.  I admit I need to do some more reading to more clearly understand your proposed mining rewards.
Incidentally, carrots and sticks are functionally equivalent; you can call it punishing inactivity or rewarding activity but it's the same as I'm sure you are aware.

[bytemaster]

To clarify my previous idea, I think if you said accounts lose stake at a rate that is directly proportional to coin days accumulated that this would mean big accounts should move more often to use up their CD.  But overall, if everyone is just holding their money and moving it back and forth at the threshold time all accounts would retain the same respective value.

I'm envisioning that accounts are mining the blocks that include their transactions.

Basically, if you are trying to attack the network by accumulating coin days, the more you accumulate the faster you lose.

Actually, it is the opposite.   As coindays accumulate your mining difficulty falls and your mining reward grows.   The goal is to motivate with a carrot rather than a stick.