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

[luckybit]

So would the ideal mining strategy be to have a lot of shares, and a decent amount of hash-power? Also, couldn't you include a transaction to yourself in the block you're mining, but not broadcast that transaction until you broadcast the block, thereby increasing the number of CDD in your block, but without risk of losing the CDD if you fail to mine out a block?

For what purpose is hashing power used? I thought Bitshares isn't mined by PoW?
Or now it's PoW/PoS hybrid like Peercoin?

[jae208]

The way I think about it is to imagine the Rate at which a node produces "block chances."  This rate is impacted by three things:  Hardware, coins, and time.

"Hardware" refers to how many hashes per second your CPU / GPU / ASIC can produce.  Architecture is irrelevant as far as the network is concerned, only the rate at which hashes can be produced.

"Coins" refers to how many coins (BTS) you have (duh).

"Time" refers to how long you have held those coins.

Of course, CDD = coins * time (by definition).

Increasing your hardware increases your Rate by allowing you to try more hashes per second.  Increasing coins or time also increases your Rate because the network will lower your difficulty.

In traditional PoW cryptocurrency (Bitcoin / Litecoin), rate is equal to hash power:

    R = h

The most intuitive way to define rate is to have Rate be linear in everything:

    R = h * c * t

More complicated schemes are possible.  But fundamentally I think you should be linear with respect to h and c.  To see why, think about hardware whales and coin whales.  (A "hardware whale" is somebody who has a lot of mining hardware; a "coin whale" is somebody who has a lot of coins.)

If the partial derivative of R w.r.t. hardware is decreasing, then it incentivizes hardware whales to split up their hardware among multiple accounts (i.e. become sibyls).  There is no way the network can prevent a whale from using as many addresses as needed to reduce his whaleness arbitrarily small (at least until he gets so small that transaction fees become significant).  This is a highly undesirable behavior, so the partial derivative should not be decreasing.

If the partial derivative of R w.r.t. hardware is increasing, then it incentivizes centralization.  An increasing partial derivative would mean that you and I would be able to combine our hardware and get profits above and beyond what we could get if we ran our hardware individually.  This is highly undesirable behavior, so the partial derivative should not be increasing.

Thus R'(h) must be constant, i.e. R is linear in hardware.  A similar argument applies to the partial derivative of R w.r.t. coins.  So R must have the following form:

    R = h * c * f(t)

This is quite clear.  You have some time-dependent boost factor f(t), you can design it to have whatever desirable characteristics you want.  The faster f(t) rises, the more advantage ancient balances have against recent balances.  You don't want f(t) to rise too fast, since this might make the network's total rate fluctuate too quickly for the difficulty adjustment to keep up, which could lead to undesirably long or short times between blocks.  But if f(t) is flat, large stakeholders have too much of an advantage.  I believe Peercoin's f(t) increases linearly for one month, then becomes flat.

 

[phoenix]

You are at risk of losing your valuable Coin-Days for no return.

What if the block rewards were simply distributed to all transaction-makers included in the block, in proportion to the CDD, with some minimum in order to provide a return?  (Say 10 or 30 days)  So if I save up my coins, waiting to make a transaction / block, at least I know I will get some return on the transaction even if I happen to not mine a block.  People who are trading constantly don't get to keep the transaction fees, they go to the actual miner of the block.

This is what dividends do.. they transfer fees to all holders.   Think of lost opportunity to 'mine' as part of your transaction fee.   Making transactions isn't 'free' for the network.  In fact, when you make a transaction you want to to help secure the network so you shouldn't be 'paid' for making a transaction.

Wait, I'm confused.  I thought that this whole mining thing was being promoted as the method by which the dividends were earned/paid.  But now I go back and read in the OP: "these fees must be split between miners and shareholders as dividends".  So people can earn dividends (still through burned transaction fees, right?) aside from this mining reward.  Got it.

I now have far fewer reservations about this whole thing.  I thought that this was going to be the only way to earn interest/dividends/PoS/whatever-you-want-to-call-it.  But if it's just one of a couple of ways, I have no problem with it, and I think it's a good idea to encourage mining.

I still think that the "ad-hoc pool" thing is a cool idea, though.  So the transaction fees would be split 3 ways: A) Dividends to all shareholders (burned); B) Miner; C) Returned to transaction-makers with significant CDD included in the block and who were therefore plausibly vying to mine the block.  Maybe they only get their own transaction fees back; the rest of the fees are split between (A) and (B), while the folks in (C) at least didn't lose any coins by trying to mine and destroying their Coin-Days.

Could we implement something like p2pool, where miners submit their transactions to themselves, then mine together and then they're paid according to both hash-power and CDD contributed to the pool?

[theoretical]

The equation in my previous post,

    R = h * c * f(t)

has an interesting consequence.  Let's assume you can trade US dollars for either hardware or coins.  In particular you have a budget of W dollars.  You spend x dollars on coins, and W-x dollars on hardware.  Then your rate becomes:

    R = k * (W - x) * x * f(t)

where k is a constant factor (the product of the hps-per-dollar and coins-per-dollar exchange rates).

This is a parabola with two zeros, at x=0 and x=W; the maximum occurs at a vertex halfway between them.  The practical interpretation is that profit-maximizing miners will desire to have equal investments in coins and hardware.  This means miners will serve as a buffer that will stabilize the USD exchange rate.  If BitShares start to lose value, miners will be able to increase their profits by selling hardware and buying BitShares; if BitShares value starts to increase, miners will sell BitShares and buy more hardware to maintain that 1:1 investment ratio.

There are significant downsides, however.  If BitShares market capitalization becomes big, it seems wrong to believe that investments in mining hardware will keep pace.  That means people who have hardware will play a disproportionate role in securing the network.  Also, it seems reasonable to assume BitShares will experience a rise in value after launch as people join the ecosystem due to its features.  The stabilization effect above will act as a brake on this increase in value; miners will sell BitShares to invest in hardware.  Presumably AGS / PTS genesis block investors will be particularly annoyed.  I would assume such investors would prefer not to have any brakes on the early expansion of BitShares' market capitalization, and would be willing to pay the price of increased exchange rate volatility in the long run.

I think Peercoin solves these issues by a complex mechanism that amounts to putting a very small upper bound on the hashpower a single address is allowed to have.  I'm not sure off the top of my head how Peercoin deals with sybil whales.  But Peercoin is surely a good place to look for proof-of-stake design ideas.  I would go so far as to say that deviations from Peercoin's design should require significant justification.

[bitbadger]

You are at risk of losing your valuable Coin-Days for no return.

What if the block rewards were simply distributed to all transaction-makers included in the block, in proportion to the CDD, with some minimum in order to provide a return?  (Say 10 or 30 days)  So if I save up my coins, waiting to make a transaction / block, at least I know I will get some return on the transaction even if I happen to not mine a block.  People who are trading constantly don't get to keep the transaction fees, they go to the actual miner of the block.

This is what dividends do.. they transfer fees to all holders.   Think of lost opportunity to 'mine' as part of your transaction fee.   Making transactions isn't 'free' for the network.  In fact, when you make a transaction you want to to help secure the network so you shouldn't be 'paid' for making a transaction.

Wait, I'm confused.  I thought that this whole mining thing was being promoted as the method by which the dividends were earned/paid.  But now I go back and read in the OP: "these fees must be split between miners and shareholders as dividends".  So people can earn dividends (still through burned transaction fees, right?) aside from this mining reward.  Got it.

I now have far fewer reservations about this whole thing.  I thought that this was going to be the only way to earn interest/dividends/PoS/whatever-you-want-to-call-it.  But if it's just one of a couple of ways, I have no problem with it, and I think it's a good idea to encourage mining.

I still think that the "ad-hoc pool" thing is a cool idea, though.  So the transaction fees would be split 3 ways: A) Dividends to all shareholders (burned); B) Miner; C) Returned to transaction-makers with significant CDD included in the block and who were therefore plausibly vying to mine the block.  Maybe they only get their own transaction fees back; the rest of the fees are split between (A) and (B), while the folks in (C) at least didn't lose any coins by trying to mine and destroying their Coin-Days.

[bytemaster]

Great analysis. 

[theoretical]

The way I think about it is to imagine the Rate at which a node produces "block chances."  This rate is impacted by three things:  Hardware, coins, and time.

"Hardware" refers to how many hashes per second your CPU / GPU / ASIC can produce.  Architecture is irrelevant as far as the network is concerned, only the rate at which hashes can be produced.

"Coins" refers to how many coins (BTS) you have (duh).

"Time" refers to how long you have held those coins.

Of course, CDD = coins * time (by definition).

Increasing your hardware increases your Rate by allowing you to try more hashes per second.  Increasing coins or time also increases your Rate because the network will lower your difficulty.

In traditional PoW cryptocurrency (Bitcoin / Litecoin), rate is equal to hash power:

    R = h

The most intuitive way to define rate is to have Rate be linear in everything:

    R = h * c * t

More complicated schemes are possible.  But fundamentally I think you should be linear with respect to h and c.  To see why, think about hardware whales and coin whales.  (A "hardware whale" is somebody who has a lot of mining hardware; a "coin whale" is somebody who has a lot of coins.)

If the partial derivative of R w.r.t. hardware is decreasing, then it incentivizes hardware whales to split up their hardware among multiple accounts (i.e. become sibyls).  There is no way the network can prevent a whale from using as many addresses as needed to reduce his whaleness arbitrarily small (at least until he gets so small that transaction fees become significant).  This is a highly undesirable behavior, so the partial derivative should not be decreasing.

If the partial derivative of R w.r.t. hardware is increasing, then it incentivizes centralization.  An increasing partial derivative would mean that you and I would be able to combine our hardware and get profits above and beyond what we could get if we ran our hardware individually.  This is highly undesirable behavior, so the partial derivative should not be increasing.

Thus R'(h) must be constant, i.e. R is linear in hardware.  A similar argument applies to the partial derivative of R w.r.t. coins.  So R must have the following form:

    R = h * c * f(t)

This is quite clear.  You have some time-dependent boost factor f(t), you can design it to have whatever desirable characteristics you want.  The faster f(t) rises, the more advantage ancient balances have against recent balances.  You don't want f(t) to rise too fast, since this might make the network's total rate fluctuate too quickly for the difficulty adjustment to keep up, which could lead to undesirably long or short times between blocks.  But if f(t) is flat, large stakeholders have too much of an advantage.  I believe Peercoin's f(t) increases linearly for one month, then becomes flat.

[bytemaster]

You are at risk of losing your valuable Coin-Days for no return.

What if the block rewards were simply distributed to all transaction-makers included in the block, in proportion to the CDD, with some minimum in order to provide a return?  (Say 10 or 30 days)  So if I save up my coins, waiting to make a transaction / block, at least I know I will get some return on the transaction even if I happen to not mine a block.  People who are trading constantly don't get to keep the transaction fees, they go to the actual miner of the block.

This is what dividends do.. they transfer fees to all holders.   Think of lost opportunity to 'mine' as part of your transaction fee.   Making transactions isn't 'free' for the network.  In fact, when you make a transaction you want to to help secure the network so you shouldn't be 'paid' for making a transaction.

[bytemaster]

(This also seems like a perverse incentive IMO.... PPC holders are incentivized to simply buy and hold, which I guess is good for raising the commodity value of the coin, but bad for encouraging transaction)

This is the old inflation / demurrage / encourage transactions for transactions sake fallacy.   Encouraging people to hold the coins is the goal... it causes the price to rise until they decide they would rather cash out at which point your 'transactions' happen as they would otherwise.

[bitbadger]

So would the ideal mining strategy be to have a lot of shares, and a decent amount of hash-power? Also, couldn't you include a transaction to yourself in the block you're mining, but not broadcast that transaction until you broadcast the block, thereby increasing the number of CDD in your block, but without risk of losing the CDD if you fail to mine out a block?

You seem to have it right.

Doesn't this seem like a perverse incentive?  Everybody will be hiding their transactions in hopes of mining their own block!

It seems to me that the system should be balanced, so that people are not punished for making transactions, nor punished for holding stake (stake defined as actively mining and running a node, not just holding in a cold wallet).

Stake as defined in this system is in conflict with stake as defined in other PoS coins.  Other PoS coins have stake grow until the stakeholder mines a block, at which time it is reset.  Conducting a transaction with those coins resets the Stake back to 0, and often requires a long period for Stake to start to build again.  (This also seems like a perverse incentive IMO.... PPC holders are incentivized to simply buy and hold, which I guess is good for raising the commodity value of the coin, but bad for encouraging transactions, which should be the lifeblood of any coin... one of the things that BTC got right, with the declining mining awards balanced by the hopefully increasing transaction fees.)

With TaPOS as defined (and as I understand it -- I could be wrong here), your Stake is reset to 0 when either A) you make a transaction or B) you mine a block.  But your only chances of (B) is to do (A).  But (B) is not guaranteed when you do (A), so making a transaction is risky if your goal is to mine a block.  You are at risk of losing your valuable Coin-Days for no return.

What if the block rewards were simply distributed to all transaction-makers included in the block, in proportion to the CDD, with some minimum in order to provide a return?  (Say 10 or 30 days)  So if I save up my coins, waiting to make a transaction / block, at least I know I will get some return on the transaction even if I happen to not mine a block.  People who are trading constantly don't get to keep the transaction fees, they go to the actual miner of the block.

So it looks like this:
BLOCK MINED:
TX with less than 30 CDD (A, B, C, D, E) -> TX Fees and actual TX outputs
TX with greater than 30 CDD (F, G, H) -> TX Fees and actual TX outputs
TX fees for A, B, C, D, E + F, G, H -> split among F, G, H in proportion to CDD.
This block would have been mined by F, G, or H, one of which would have had the greatest CDD, and therefore would receive the majority of the reward.

In other words, F, G, and H form an ad-hoc pool based on their Stake contributed to this block!

[bytemaster]

So would the ideal mining strategy be to have a lot of shares, and a decent amount of hash-power? Also, couldn't you include a transaction to yourself in the block you're mining, but not broadcast that transaction until you broadcast the block, thereby increasing the number of CDD in your block, but without risk of losing the CDD if you fail to mine out a block?

You seem to have it right.

[phoenix]

So would the ideal mining strategy be to have a lot of shares, and a decent amount of hash-power? Also, couldn't you include a transaction to yourself in the block you're mining, but not broadcast that transaction until you broadcast the block, thereby increasing the number of CDD in your block, but without risk of losing the CDD if you fail to mine out a block?

[Tuck Fheman]

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.

 

[bytemaster]

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

This kind of behavior is something I am trying to visualize... but I think that the division by min_votes helps control the gain significantly.

min_votes == min_coindays ... I am trying to change the terminology to votes as an easier concept for people than coindays.
miner_votes == coindays_destroyed_by_miner

min_votes is the minimum number of coindays required to produce a block
available_votes is the number of votes available in all unspent outputs
min_votes = available_votes / 100K

Therefore anyone with at least .0001% of the share supply (4 BTS) meets this requirement every block.   We can then conclude that the range on miner_votes/min_votes is somewhere between 100K and 0.    Because an individual can mine at 1000 cpm we can then conclude that someone with 4 BTS can equal the 'hash power' of someone with 100% of the share supply (but isn't mining) once every 100 minutes.   For efficiency sake, the individual who owns 4 BTS should not mine until they have accumulated enough votes (by waiting) such that there is a high probability that they can find the block in the next 5 to 10 minutes. 

If someone with 1% of the share supply starts producing blocks every 10 seconds... then the difficulty will rise until even with 1% of the shares they still have to mine for 5 minutes.    This rise in difficulty would mean that someone with .001% of the share supply would only get an opportunity to mine once every 3.5 days and they would have the same probability of finding a block when they mine as someone with 1% who attempts to mine every block.    Now in theory there are 1000x as many people with .001% as there are with 1% and while only 1 out of those 1000 would have a chance of mining the block every 3.5 days, *someone* would have an opportunity every block and thus someone with 1% would only have a 50/50 chance of winning any given block when competing against 1000 with .001%.

Also... assuming someone with .001% waited 7 days rather than 3.5 days, then they are in the position of mining a block in 2.5 minutes rather than 5.

What all of this means is that mining difficulty merely sets the average 'holding period' before someone starts mining proportional to how much they own.  Whether they own 10% or 1%.     

Assuming everyone on the network is mining, someone with .001% of the shares would fire up their miner once per year, while someone with 1% would fire it up 1000x per year and someone with 10% would fire it up 10,000x per year.  Someone with 100% would fire it up 100K per year.

This all assumes of course that people only mine when the expected time to find a block is less than 5 minutes.  Because there is profit from mining, many people may choose to mine anytime the cost of mining for the 'expected time' is less than the expected rewards.  This will increase the base difficulty of the network, but is otherwise neutral to the calculations. 

There are other factors that will slow down block production: 
1) The minimum time between blocks is 1 minute (the network will not propagate blocks with timestamps less than 1 minute after the previous block)
2) The network will not propagate blocks with a timestamp in the future.
3) When you do produce a block, being first is not what matters... being the best is what matters.
4) Your mining reward is proportional to transaction fees, therefore, there is no sense in producing a block until there are actually transactions from other people.
5) To prevent attacks and provide stronger guarantee of payment irreversibility, the network will not allow forks beyond a couple of blocks to even be considered without a large percentage (25%+) of the votes on that fork.  This should filter out all naturally occurring latency induced forks and prevent attackers from even attempting to produce an alternative chain because any merchant dealing with significant funds would wait until after this window had passed.







 



 

[Agent86]

   Thanks bitbadger and drltc for your suggestions.  I agree we need to think this through and get the best solution.