if this is correct then there would be an incentive for big pools.
Sigmike, why will most people run their own client? If a user can keep coins in cold storage, and release a minting key to a pool, that would save electricity, hardware cost, and hassle vs. running their own client. What is the disincentive to do this?
Sigmike, why will most people run their own client? If a user can keep coins in cold storage, and release a minting key to a pool, that would save electricity, hardware cost, and hassle vs. running their own client. What is the disincentive to do this?[/quote]
Would also be keen to hear the reasoning behind this. As soon as there is a trustworthy entity doing this, many would go for this (laziness factor, tragedy of the commons etc.). This will result in large pools increasing the risk of 51% attack.
The only reason imo that this wouldnât happen is that individuals would put the community interest above their own short term interest. Although examples of this do exist (philantropy) they are very rare.
This was posted in another thread. I just wanted to move it over here, because I feel itâs relevant.
Should we interpret this to mean that sigmikeâs proposal is the chosen solution?
Personally, I think it is the best candidate, but there have been many proposals and I would be very interested to know if there have been any evolutions in Mikeâs thoughts.[/quote]
Yes, discussion about this is still ongoing in the main cold-minting thread. Are you and Sigmike taking into consideration everything being proposed in that thread, or is the original proposal a done deal?[/quote]
So far I think Mikeâs proposal has been quite solid. It also includes disincentive against publishing of minting key. Itâs still a work in progress, so comments and suggestions are still open.[/quote]
Iâm interested to know if the approach has a way to disincentive pool minting[/quote]
Mike posted some reply earlier:
I would like to mention that the cold minting feature does not allow a minting pool to reduce variance. This is because in coinstake the outputs addresses of coinstake must match the spent coins in the kernel input, so it prevents pools from mixing different users coins into the same coinstake transaction.
This means in order for the minting pool to reduce variance and waiting time, it cannot just collect usersâ minting keys. It must have users actually deposit the coins with the pool in order to achieve that. That is a significant disincentive for pool formation.[/quote]
No, the holder of the minting key wonât be allowed to move the reward (or the coins) to another address. But this is precisely to avoid pools.
If you can move the reward then you can build variance reduction pools very similar to bitcoin pools. To do that you split each reward to all the members of the pool, proportional to their amount. And you keep a fee.
If you do that, most people will want to join the biggest possible pool because they would get more frequent rewards. They wouldnât have to wait a random amount of time to finally find a block.
That inevitably leads to always bigger pools, like in bitcoin.
If you canât move the reward you canât do that. You can mint for someone else, but you canât split the reward across members nor take a fee. Youâre a minting service provider, youâre not a pool.
The first post of this thread still applies and contains the details.
The only thing thatâs going to be added is that if someone receives 2 blocks from the same stake he will discard both blocks (right now he only discards the second one). That prevents people from giving away their minting keys because they risk not getting any reward (because someone may propagate a duplicate block each time they find a block).
Because anyone running a free minting service is suspicious. The cost to mint is very low but itâs not 0. Especially if the number of outputs is very large. Remember they canât take a fee from the rewards. So why would anyone do that for free? If heâs not a friend helping you, the most likely is heâs gathering minting power to make a 51% attack. Maybe he is trying to increase the security of the network by helping others to mint. But he also concentrates minting power and that endangers the network. So if his purpose is Peercoin security he will certainly be careful about not growing too much (or just not do it at all).
Also running your own client is very simple. You just run your usual Peercoin client with your minting key loaded. Even if itâs not 24/7 itâs helping the network and will provide rewards. You can run the program at startup for example. Projects like Peerbox will also make it very easy to run a 24/7 client.
And by doing it yourself youâre guaranteed youâre not helping a malicious minter. So you protect the value of your coins. Thatâs especially important if you are a large holder. The more Peercoins you own, the more important its value is. And hurting its security is hurting its value.
Also by giving your minting key thereâs a small risk you loose your reward. Thatâs not because the minter can spend it, but because if your coins are ever minted by 2 people at the same time then the network will reject your block. It may happen if your provider gets hacked for example. Of course it may also happen if you get hacked. It depends who you trust the most to handle security. Note that the hacker has nothing to gain here besides annoying you, so the risk is probably negligible.
But even if people use providers (free or not), itâs much less a problem than in Bitcoin. In Bitcoin you must choose a big pool. Small pools canât work because they rarely finds a block and thus rarely reward the minters. So competition is very hard. The cost to entry for new pools is huge. That leads to only a few major actors.
Thereâs no such thing here. Someone can start a minting service with a Raspberry Pi and a home internet link and will provide you the exact same reward as a big company minting tons of coins.
Bigger providers will probably have lower fees than smaller providers so that may lead to bigger actors. But if the provider is doing real business you will have to pay him because he canât get money by other means. Thatâs very different from Bitcoin where you must use a pool who can get money from the rewards and the transaction fees.
I think most people will rather run their own client or ask a friend than pay a big provider.
[quote=âsigmike, post:126, topic:2336â]But if the provider is doing real business you will have to pay him because he canât get money by other means. Thatâs very different from Bitcoin where you must use a pool who can get money from the rewards and the transaction fees.
I think most people will rather run their own client or ask a friend than pay a big provider.[/quote]
Not sure, why canât they take a fee from the rewards if you provide them with the minting key? You get your rewards minus say a 1% fee or some fixed cost/3 months in return for minting. Sounds great for someone who doesnât have the time to mint or reckons buying a Peerbox and paying for energy is more expensive. They only risk their rewards, their coins all still in cold storage. I can see a viable business which could potentially own a lot of minting keys. You can only hope that large shareholders can withstand the short term gains of outsourcing their minting versus the risk of 51% attacks.
Or did I miss something?
I guess itâs because of this:
I guess itâs because of this:
Yes, thanks for spotting that, if the rewards always go to the same (cold storage) address as the stake, then it would be safe.
[quote=âsigmike, post:126, topic:2336â]But even if people use providers (free or not), itâs much less a problem than in Bitcoin. In Bitcoin you must choose a big pool. Small pools canât work because they rarely finds a block and thus rarely reward the minters. So competition is very hard. The cost to entry for new pools is huge. That leads to only a few major actors.
Thereâs no such thing here. Someone can start a minting service with a Raspberry Pi and a home internet link and will provide you the exact same reward as a big company minting tons of coins.
Bigger providers will probably have lower fees than smaller providers so that may lead to bigger actors. But if the provider is doing real business you will have to pay him because he canât get money by other means. Thatâs very different from Bitcoin where you must use a pool who can get money from the rewards and the transaction fees.
I think most people will rather run their own client or ask a friend than pay a big provider.[/quote]
i agree that problem is less than for btc because user canât benefit of variance reduction. however cost for pool to mint 1 key or 100 keys is same. pool could work with donations, or charge like $10/year (prepaid). who is going to bother using peerbox if u can just outsource everything for like $10/year? so the benefit of using pools is less than btc but there is still some benefit. also cost to run pool is probably so low that even if only some ppl pay instead of everyone itâs still worth keeping the pool running.
maybe a solution could be making a very high quality opensource pool software so to make it very easy for anyone to make a high quality pool and avoid concentration?
also it would be nice if the minting key would look different than the priv/pub keys so that one can immediately see the key type and avoid mistakes (like giving priv key to pool)
[quote=âsuperppc, post:130, topic:2336â]cost for pool to mint 1 key or 100 keys is same. pool could work with donations, or charge like $10/year (prepaid). who is going to bother using peerbox if u can just outsource everything for like $10/year?
maybe a solution could be making a very high quality opensource pool software so to make it very easy for anyone to make a high quality pool and avoid concentration?[/quote]
Good thoughts. Keep an eye out for the Chronos Pool of Anti-hackers? :
You need more power to process 100 keys. The cost difference is very small, but itâs not null. And it becomes not so small if you want to manage thousands of keys.
People who already have a computer running 24/7, people who donât trust providers, people who have less than $1,000 in peercoins (because $10 is what they can get with the reward), people who want to be certain they donât help a malicious minter, people who like DIY, etc.
But itâs fine if people use providers. It helps bring more Peercoins to the minting power and makes 51% attacks more difficult.
It would be a problem only if a provider (or anyone) could manage to get 51% of the minting coins. And I think the forces here do not push to this direction, unlike in Bitcoin.
Yes that would probably be nice.
Note that if youâre ready to manually manage member payments and manually add keys, you just need the official peercoin client to do that.
That would mean adding a new type of key and change significant parts of the code. It would be nice but Iâm not sure it is worth the troubles.
Good answers, Sigmike. I think youâre taking the right approach. I do have to point this out, though:
This is not correct. As explained here and also discussed here and here, a malicious entity with less than 51% can still easily wait to get lucky for a successful attack.
[quote=âChronos, post:133, topic:2336â]Good answers, Sigmike. I think youâre taking the right approach. I do have to point this out, though:
This is not correct. As explained here and also discussed here and here, a malicious entity with less than 51% can still easily wait to get lucky for a successful attack.[/quote]
I believe thatâs a valid concern, today, but doesnât situation become more difficult to replicate as the number of people minting on the network increases? It was my understanding that the situation can happen today because there arenât enough people actively attempting to solve blocks â if the cold storage minting (as described by SigMike, or a similar implementation) is successful and people are encouraged by the increase in security â I only see it getting harder and harder for an entity to solve a larger number of blocks in series, eventually approaching the need for over 51% of the minting coins on the network.
Am I misunderstanding what youâre implying?
Ben, I think you are misunderstanding. What Iâm trying to say is that 51% of the minting coins is enough to perpetually double-spend and/or control the blockchain, just as 51% of hashpower could be used in bitcoin. However, with less than 51%, the attacker could wait until getting a lucky 6-blocks-in-a-row to attack. (Unlike in Bitcoin, where the attacker wastes hashpower trying to get lucky, this Peercoin attacker can attempt at negligible cost, only destroying coindays when the attack is likely to work.) Thereâs a tradeoff between luck required and coins held, but the threshold for a reasonable attack is well below 51% of minting coins.
See the linked threads in my other post for details.
Ok, I wasnât understanding the vector that you were concerned with, but after reading what you wrote, I can visualize it now. Thank you for the clarification.
@Sigmike - I really appreciate the transparency in your plans for v0.5 and your engagement with this board!
I have a question about implementation of the following:
If I understand correctly, a node will entirely reject a block signed by the same stake if it âreceivesâ it more than once⌠how does this approach account for latency in the network wherein a legitimate single block may arrive at a node through more than one route? I understand some cases where two âduplicateâ blocks may actually contain slightly different sets of transactions (very unlikely with current low volume), but how will a client differentiate a block that has originated from a two distinct wallets vs one originating from a single wallet?
If I understand correctly, a node will entirely reject a block signed by the same stake if it âreceivesâ it more than once⌠how does this approach account for latency in the network wherein a legitimate single block may arrive at a node through more than one route? I understand some cases where two âduplicateâ blocks may actually contain slightly different sets of transactions (very unlikely with current low volume), but how will a client differentiate a block that has originated from a two distinct wallets vs one originating from a single wallet?[/quote]
If the new block is exactly the same as another one already received, then itâs just ignored because you already have it. Nothing happens.
If itâs a different block but the kernel has already been used in another block then both blocks are rejected.
Note that this only applies to the highest block. You wonât reject a block that has already been confirmed by another block.
i now understand sigmikeâs strategy, itâs counterintuitive and brilliant:
-intuitively it seems that mint only key with no risk to user (as no coins can be spent with it) could lead to pool centralization as users are not too worried of giving that key to a pool (no risk)
-however for that same fact that coins canât be accessed with mint key, pools canât âpoolâ the money of users to reduce variance, removing the main incentive for pools to become big (main issue with btc)
-so ppl may just use small pools, virtual servers, their computer, raspberry-pi, etc⌠with no fear of hacking and no desire to go to the biggest/most reliable/safest pool and so PPC stays decentralized
iâm impressed, what is the ETA for this to be released?
I donât know because Iâm very busy right now. I think it will be released with Peercoin 0.5.