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

[gulu]

What's the motivation for mining? Since no more extra BTXs will be generated to dilute my positions, I will simply off-storage my BTXs and move them once every year, paying one-time tx fee. To be frank, the mining rewards are not that significant, especially when tx fees are split half between mining rewards and dividends. The amount of BTXs that will be engaged in mining is proportional to the significance of tx fee. Therefore the dividend setup will reduce the number of miners by half. After all, mining with BTXs takes extra risk, extra time and extra efforts. I think I personally will chose not to mine but pay the tx fee once every year.


Sent from my iPad using Tapatalk

[toast]

any transaction

[luckybit]

Perhaps something with multi-signature addresses.   If you require 2 signatures to spend a balance, but just 1 to mine with it then you may have additional security.

If the pool operator's signature is required to spend your balance, doesn't that mean you can't get your balance back if the pool operator disappears?

If you're considering this idea, I'm pretty sure you'll wind up exactly where I suggested -- having a way to sign over the authority to mine with your balance, but not to spend it.

Exactly, if you use multisig for this, people can have full control of their own wallets, but send a copy of one key to the pool operator to mine for them.  It's possible most people wouldn't care who mined for them, and would thus make their "mining key" basically public, potentially undermining POS.

If mining income could be directed to an address other than the mining address, that would force people to care who mined for them, but then it seems like you might as well just allow full multiple input multiple output mining transactions.

Here is how I view things... once a year you need to bring your wallet on line if you want to avoid a 5% inactivity fee.  If you 'mine a block' while you are online anyway then you still contribute to the security of the network even if your keys are not 'online' all of the time.

What counts as activity?

[bytemaster]

Perhaps something with multi-signature addresses.   If you require 2 signatures to spend a balance, but just 1 to mine with it then you may have additional security.

If the pool operator's signature is required to spend your balance, doesn't that mean you can't get your balance back if the pool operator disappears?

If you're considering this idea, I'm pretty sure you'll wind up exactly where I suggested -- having a way to sign over the authority to mine with your balance, but not to spend it.

Exactly, if you use multisig for this, people can have full control of their own wallets, but send a copy of one key to the pool operator to mine for them.  It's possible most people wouldn't care who mined for them, and would thus make their "mining key" basically public, potentially undermining POS.

If mining income could be directed to an address other than the mining address, that would force people to care who mined for them, but then it seems like you might as well just allow full multiple input multiple output mining transactions.

Here is how I view things... once a year you need to bring your wallet on line if you want to avoid a 5% inactivity fee.  If you 'mine a block' while you are online anyway then you still contribute to the security of the network even if your keys are not 'online' all of the time.   

[Troglodactyl]

Perhaps something with multi-signature addresses.   If you require 2 signatures to spend a balance, but just 1 to mine with it then you may have additional security.

If the pool operator's signature is required to spend your balance, doesn't that mean you can't get your balance back if the pool operator disappears?

If you're considering this idea, I'm pretty sure you'll wind up exactly where I suggested -- having a way to sign over the authority to mine with your balance, but not to spend it.

Exactly, if you use multisig for this, people can have full control of their own wallets, but send a copy of one key to the pool operator to mine for them.  It's possible most people wouldn't care who mined for them, and would thus make their "mining key" basically public, potentially undermining POS.

If mining income could be directed to an address other than the mining address, that would force people to care who mined for them, but then it seems like you might as well just allow full multiple input multiple output mining transactions.

[theoretical]

Perhaps something with multi-signature addresses.   If you require 2 signatures to spend a balance, but just 1 to mine with it then you may have additional security.

If the pool operator's signature is required to spend your balance, doesn't that mean you can't get your balance back if the pool operator disappears?

If you're considering this idea, I'm pretty sure you'll wind up exactly where I suggested -- having a way to sign over the authority to mine with your balance, but not to spend it.

[Troglodactyl]

Do you think people will be reluctant to mine, because they don't want to have their wallet open and private keys on a networked computer? (no cold storage protection)  Is there any way to allow more peace of mind than I am imagining?

I think NXT had a problem that not many people ran nodes and not many people bothered to mine.

Perhaps something with multi-signature addresses.   If you require 2 signatures to spend a balance, but just 1 to mine with it then you may have additional security.

This would open us up to a new kind of mining pool, also.

[bytemaster]

Do you think people will be reluctant to mine, because they don't want to have their wallet open and private keys on a networked computer? (no cold storage protection)  Is there any way to allow more peace of mind than I am imagining?

I think NXT had a problem that not many people ran nodes and not many people bothered to mine.

Perhaps something with multi-signature addresses.   If you require 2 signatures to spend a balance, but just 1 to mine with it then you may have additional security.

[Agent86]

Do you think people will be reluctant to mine, because they don't want to have their wallet open and private keys on a networked computer? (no cold storage protection)  Is there any way to allow more peace of mind than I am imagining?

I think NXT had a problem that not many people ran nodes and not many people bothered to mine.

[sumantso]

Is it possible to have a system where the mining reward is shared by all the active nodes? This will incentivize keeping nodes running.

[bitbadger]

Can someone first clarify the meaning of 'mining' in the context of TaPOS?

It is not something similar to POW that performs hashing computation.

For TaPOS, I don't think it is hashing or anything computational intensive. That is not the purpose of POS. Is this  'mining' just 'leave the wallet process running'?

Even in 'standard' POS such as Peercoin, there is a "mining" process.  This is to create a random/stochastic process for the minting of PoS blocks, similar to the mining of PoW coins.  If it were deterministic in a sort of round-robin process, this would create security problems.  So there is still a "race" to "discover" the "best" block among all peers.... nobody can guess beforehand who will mint the next PoS block.

Each client works constantly on a hashing problem.  The PoS block contains only a single transaction, the miner sending his staked coins to himself.  The difficulty is very easy compared to PoW, but it is still a hashing problem.  Peercoin keeps the hashrate low by having the hashrate limited to 1 hash per second.  The hash is based only on the present timestamp, and some essentially static data (the PoS transaction inputs, and the hashes of previous blocks).  So the equivalent to a PoW nonce is the timestamp, which changes only once per second!  I suppose somebody could "cheat" by calculating ahead, but the utility of this is limited to the next couple of minutes -- by that time, the next block will be found, which will change the data to be hashed.  And the required difficulty decreases according to the number of stake-days included in the block.  The stake-days, of course, can be verified by anybody on the network.

So you can still be "lucky" or "unlucky" in PoS mining.  There is still a hashing problem, and a difficulty level to be met.

It appears that bytemaster has a different idea in mind for TaPoS mining, which would allow those with greater hashpower to mine blocks more readily.  I am not 100% sold on the idea, as it could lead to another hardware arms-race, but the PoS rewards are not likely to be high enough to really matter.

EDIT: It is *necessary* to have mining rewards on top of TaPoS, as simple TaPoS does not require one to participate in the "minting" of blocks in order to obtain one's PoS/"dividends" (unlike Peercoin).  Each transaction includes fees which are burned.  This increases every stakeholder's proportional interest in the BitShares ecosystem, whether they are connected to the network or not; whether they are mining or not.  This greatly simplifies the PoS part, but it requires the addition of mining rewards in order to incentivize mining.  If this can be achieved without creating a hardware arms-race, that would be great.

[ffwong]

Can someone first clarify the meaning of 'mining' in the context of TaPOS?

It is not something similar to POW that performs hashing computation.

For TaPOS, I don't think it is hashing or anything computational intensive. That is not the purpose of POS. Is this  'mining' just 'leave the wallet process running'?

[oco101]

Selling Bitshares to buy mining hardware seems to be pointless if PoS can secure the network. I thought Bytemaster was going with Ripple consensus and if that is the case why do we need mining via PoW at all?

Unfortunately he's not going with Ripple consensus anymore. He mention that he'll maybe look in to it for the next Dac's witch I hope he does !! In the meantime we are stuck with mining and all the problems drltc mentioned.

[theoretical]

For what purpose is hashing power used?

This is an excellent question.  The answer is provided by the thread's opening post.

we still rely upon mining for one function:  decentralized selection of who gets to produce the next block.

It's not that including PoW mining is desirable.  From what I've seen, all Invictus / bytemaster marketing materials, forum posts, etc. about BitShares have suggested that PoW is undesirable.

But the network must have a means of selecting one node to produce the next block.  And PoW mining is a known algorithm to have the network select a single node in a decentralized fashion.

Using PoW in this way has some traps for the unwary protocol designer.  I'm skeptical about the specific way bytemaster proposed to use PoW.  I'm still open-minded about whether a PoW-based scheme, or a PoW/PoS hybrid, could be workable.

I've suggested looking at Peercoin for design ideas.  I'm not very familiar with its inner workings, but since it's a PoS currency which has been proven in the real world, it seems like a natural place to look.

[luckybit]

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.

I think the goal should be the constant upward increase in price of Bitshares stock. It's not a currency so volatility is irrelevant. How can you provide an incentive to make people want to hold and avoid selling Bitshares unless absolutely necessary?

Selling Bitshares to buy mining hardware seems to be pointless if PoS can secure the network. I thought Bytemaster was going with Ripple consensus and if that is the case why do we need mining via PoW at all?

Do your equations alter the incentive? Remember Bitshares is a stock not a currency, and Bitshares is supposed to resemble a profitable corporation, not a precious metal.

Think of Bitshares as Birkshares (like Berkshire Hathaway). How can we make it the penultimate store of value? If miners can sell their hardware then you want them to buy more Bitshares. If they sell Bitshares to buy mining hardware then something is critically wrong.

This would mean the network would be insecure if they don't mine with better hardware. Is that really the case?

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

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

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

[ffwong]

Hi Dan

Thanks for the write-up.

But do you mind to tell in more layman term on how to maximize their income from the miner point of view? I believe most miners are not necessarily a programmer. They may not be able to understand the meaning of the algorithm and protocol.

I think, by knowing how to maximize their own interest, we can predict how the people behave aggregately.

[barwizi]

lol, the deal never stops evolving.

[Agent86]

Ok, here is my idea for TaPOS... perhaps you hear me out:

instead of having a fixed one year date where there is a 5% charge:

The way you do it is you have a sliding scale, where the longer you keep your money dormant the faster you lose money.  At some point it crosses a threshold where it makes sense to pay a transaction fee to move your money and "reset the clock" so to speak.  Before that point it saves you nothing to move your money without other reason.

The transaction fee is similar whether you are moving a large amount of shares or a very small amount of shares and is based on the size of the transaction in bytes.

So what this accomplishes is that a large account needs to move their money (back and forth) and use their CDD to secure the network more often than a small account because the transaction fee is a smaller percentage of the value of the larger account.  So basically the more stake you have in the Bitshares network the more involved you have to be in creating transactions and securing the network, which is only fair and is what we want.

You gain nothing by combining or separating your shares because if you have one large account you have to move it more often but if you have a bunch of smaller accounts you have to move each one less often but you have more accounts so it is the same amount of transactions and work.

You can set this scale based on the balance of the amount of security and coin movement you want with the trade off of the size of blockchain / bandwidth you are trying to keep.

The client could time these auto transactions for you but if you don't time your money movement perfectly it is really no big deal and won't cost you much, just don't let a large account sit there dormant forever and you'll be fine.

[fuzzy]

 

[bytemaster]

If you make it trustless there is no possinle harm from large pools. There are efforts to get all btc miners on p2pool, for example

Sent from my SCH-I535 using Tapatalk

Trustless is not possible if difficulty is driven by the CDD on a single output... this single output would be in the hands of a single individual.

[toast]

If you make it trustless there is no possinle harm from large pools. There are efforts to get all btc miners on p2pool, for example

Sent from my SCH-I535 using Tapatalk

[luckybit]

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

Wouldnt this centralize the whole thing again into the handy of the pool adminds?

Pools would not get too large because you have to trust them with your shares.  The payout would be small given the risk.

So if we make it trustless what would stop the pools from getting too large then?

[bytemaster]

I think that in addition to adjusting the fees earned based upon CDD... that the difficulty of the block should factor in CDD of the miner.

Assuming equal hashing power, someone with 1% of the shares should find a block 1% of the time.   This will combat the problem of outside miners (non-shareholders) being able to control the network. 

[bytemaster]

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

Wouldnt this centralize the whole thing again into the handy of the pool adminds?

Pools would not get too large because you have to trust them with your shares.  The payout would be small given the risk.

[phoenix]

So, will people start to create customized miners that allow them to maximize the efficiency that they spend their CDD?

[santaclause102]

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

Wouldnt this centralize the whole thing again into the handy of the pool adminds?

It seems like a combination of P2Pool and CoinJoin might be possible if this is a concern.

I never mined anything... Is p2pool what it sounds like? A pool in which voting power is completely distributed?

yes, p2pool for BTC has its own separate chain of shares people found that are a part of the p2pool network. When a block is found, the p2pool network includes payouts to the last N number of shares. It is entirely decentralized and trustless. The downside, lately, is that the difficulty to find a share is thousands of times harder than a normal pool, so variance is larger - especially for small miners (<10GH/s).

Also there is no adavantage to use p2p pools for miners if you assume the centralized pools work / are trustworthy which should not be such a big issue a pool admin could max take 25 btc and run before he is not trusted anymore. So there is no incentive for miners to decentralize mining in POW (AND Tapos?).

[maqifrnswa]

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

Wouldnt this centralize the whole thing again into the handy of the pool adminds?

It seems like a combination of P2Pool and CoinJoin might be possible if this is a concern.

I never mined anything... Is p2pool what it sounds like? A pool in which voting power is completely distributed?

yes, p2pool for BTC has its own separate chain of shares people found that are a part of the p2pool network. When a block is found, the p2pool network includes payouts to the last N number of shares. It is entirely decentralized and trustless. The downside, lately, is that the difficulty to find a share is thousands of times harder than a normal pool, so variance is larger - especially for small miners (<10GH/s).

[toast]

I just realized this is a natural side effect of having tx fee be per-byte. Carry on.

Sent from my SCH-I535 using Tapatalk

[bytemaster]

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

Wouldnt this centralize the whole thing again into the handy of the pool adminds?

Yeah isn't this why you didn't like NXT forging?

Sent from my SCH-I535 using Tapatalk

It is something I didn't like about Nxt.   In fact there is a lot to be said for Nxt... so lets consider our goals and see how well each solution achieves the goals:

1) Minimize waisted Resources (electric bills).. Nxt wins hands down by using deterministic selection of who gets to sign the block.
2) Maximize the percentage of shareholders contributing to security  (TaPOS = 100%, Nxt = 10-20%?).... TaPOS advantage...
3) Maximize the rate at which shareholders contribute to security... the minimum POS per block would require 6 months to have 51% of shareholders 'vote' for the block that included your transaction.   
       Best case a shareholder with 51% would simply move their funds every block and make it irreversible...
       We want to minimize the number of blocks it takes to get a statistically significant voting advantage over an attacker... the minimum rate is .001% of votes get cast per block.... we would like this to be much higher if possible.

4) Distribute control as far and wide as possible
       A large pool is bad for this, but good for #3...  pool size is mitigated by risking your funds to a 3rd party holding them in a 'live wallet'.
5) Maximize the rate at which transactions are included in blocks
6) Prevent Denial of Service by not including transactions or failure to produce blocks.
     - Nxt forgers can exclude transactions from the network.. though they are paid by including them.
   

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

Wouldnt this centralize the whole thing again into the handy of the pool adminds?

Yeah isn't this why you didn't like NXT forging?

Sent from my SCH-I535 using Tapatalk

[santaclause102]

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

Wouldnt this centralize the whole thing again into the handy of the pool adminds?

It seems like a combination of P2Pool and CoinJoin might be possible if this is a concern.

I never mined anything... Is p2pool what it sounds like? A pool in which voting power is completely distributed?

[Troglodactyl]

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

Wouldnt this centralize the whole thing again into the handy of the pool adminds?

It seems like a combination of P2Pool and CoinJoin might be possible if this is a concern.

[santaclause102]

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

Wouldnt this centralize the whole thing again into the handy of the pool adminds?

[bytemaster]

We have been on a major kick to eliminate mining from way the network provides security and to maximize profitability; however, we still rely upon mining for one function:  decentralized selection of who gets to produce the next block.  This means that while BTS is not created by mining, miners can still EARN BTS through mining.

To produce a block you must include the minimal number of 'votes' (CoinDaysDestroyed) as proof of stake.   However, network security depends upon how quickly votes can be accumulated on top of every block.   It is in the networks best interest if a large percentage of BTS shares can sign off on every block in an efficient manner. 

We want to pay people for voting with their BTS shares by leaving their wallet 'open' and actively producing blocks.   Further more we want to encourage rapid prioritization of blocks that include as many possible voting transactions using as few bytes as possible. 

Every block generates fees, and these fees must be split between miners and shareholders as dividends.   The network can significantly enhance its security by paying miners who include the most possible votes in the most timely manner.  I am contemplating how to set the mining reward as a percentage of transaction fees and have the following proposal:

MIN_VOTES        = min CDD required to produce a BLOCK
ACTUAL_VOTES  = total CDD by the block
BLOCK_INCOME  = total fees paid by all transactions included in the block.
DIVIDEND_RATE = 50% ?? 
MAX_REWARD    = DIVIDEND_RATE * BLOCK_INCOME

REWARD = MAX_REWARD * (1 - (MIN_VOTES / ACTUAL_VOTES))

The result is that as the number of ACTUAL_VOTES approaches infinity, the percentage of MAX_REWARD actually payable to the miner goes to 100%

So how does one maximize their mining efforts?   By including as much of their own VOTES per block as possible and insuring the REWARD for their block is > than the cost of including their own transaction to up the CDD.   

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

Because mining difficulty and reward are independent of who makes the transaction, everyone has incentive to include as many transactions as possible and no one has incentive to not relay transactions.   Keeping transactions secret and failing to relay will not hurt your competitions mining ability, though it may hurt their profits while increasing the dividends paid to all shareholders.   So selfish nodes benefit the network at the expense of other miners.   No node has any incentive to exclude transactions because the transaction their income depends upon including as many as possible.

Mining is profitable for all, but you can increase your profits by owning more and using it to produce blocks.