This has been mentioned before. To create a pure Proof-of-stake coin you would need to do an auction for coins from the genesis block before hand. And then no transactions can be made while all the coins are maturing.
And then you would need to distribute the BTC that you get. So, maybe you can create a site to verify you own the PoS coin and link it with a btc address.
Maybe you'll donate some of the coins to developers. Maybe you'll use some of it to distribute to stakeholders who registered. So if you own ppcoin not only you get stake but you also get btc stake.
Topic: What challenges would a pure Proof-of-stake coin face? (Read 5687 times)
You are welcome to join Nxt project. In 2 months I will reveal the source code, until that you can contribute with ideas.
Colored coin amounts will be in the range from 1 to 1 billion units. Each account will be able to issue up to 16777216 different "colors".
Colored coin amounts will be in the range from 1 to 1 billion units. Each account will be able to issue up to 16777216 different "colors".
@BCNext; It sounds very much like we're contemplating a very similar coin launch, even including some of the same longer range goals. (native support for multiple issues in the block chain that goes well beyond 'colored coins', pure proof-of-stake, awareness of other block chains and supporting cross-chain decentralized trading, point-to-point encryption, etc).
I'm not ready to announce a launch date though; I'm still in the process of organizing my own fork of the code (I chose to start with Litecoin because it's simpler than most) and I don't know when it'll be ready.
Just BTW, if you're serious about a billion-coin issue, you should be aware of exactly how wide the number you're using to record the amounts is. Given the 1 Bitcoin / 10M Satoshi setup of Bitcoin, you don't have enough bits there to handle that many coins.
I already ran into that when I was adding a field to keep track of coin-type. Explanation: the basic "Crypto-Credit" coin in my system is coin type zero; but users could issue other coin types with different names, different sets of rules, and different sets of standard transactions, sharing the same block chain. They could be other cryptocurrencies, or company stocks, or bonds, or whatever, and by default that would allow a distributed market in which issues could be traded for one another.
Anyways, I'm pointing this out because if you're amenable and have the same vision, we could cooperate.
I'm not ready to announce a launch date though; I'm still in the process of organizing my own fork of the code (I chose to start with Litecoin because it's simpler than most) and I don't know when it'll be ready.
Just BTW, if you're serious about a billion-coin issue, you should be aware of exactly how wide the number you're using to record the amounts is. Given the 1 Bitcoin / 10M Satoshi setup of Bitcoin, you don't have enough bits there to handle that many coins.
I already ran into that when I was adding a field to keep track of coin-type. Explanation: the basic "Crypto-Credit" coin in my system is coin type zero; but users could issue other coin types with different names, different sets of rules, and different sets of standard transactions, sharing the same block chain. They could be other cryptocurrencies, or company stocks, or bonds, or whatever, and by default that would allow a distributed market in which issues could be traded for one another.
Anyways, I'm pointing this out because if you're amenable and have the same vision, we could cooperate.
Yes, that's basically the same plan I was talking about, except that I want to fix it so people can't tell in advance when they're going to get "lucky." In the protocol I'm describing, there are two effects as time passes: The difficulty comes down (the target you have to meet gets larger) and you get more chances (the number of nonces you can use goes up).
So, yah, you can solve your few hundred hashes and see when the two will meet in the middle as soon as the block starts; but someone else's chances may meet in the middle first, and you don't know when.
Also, there's a point in sending your block around to signatories first; that's so you can't have a "winning" block (ie, one with a lower timestamp or hash than the current accepted block) that will cause a chain reorg, unless you have announced it in a timely way. And also, it allows six different people to submit lists of all the tx they've seen, which you cannot then leave out of the block. So unless six randomly chosen stakeholders are cooperating with you, you cannot leave a chosen transaction out of the block. That ought (I hope) to put a cramp in the style of those who want to double spend, or keep transactions out of the blockchain.
Finally, it allows the idea of an explicit "rejected" message. In the bitcoin protocol, a transaction which conflicts with one that's already been seen simply never confirms. Somebody waiting for a transaction to mature might not realize there's a problem when waiting more than an hour for a transaction to mature. But if you get explicit lists of transactions that must be included from various sources, then you are likely to get conflicting transactions in the same block. That means that if you accept one, you have to accept the other but mark it "INVALID" or "REJECTED" or whatever, and that is likely to happen in the very first block after a double spend is made, so there's no question what's going on or complaint that the miners aren't picking up transactions fast enough, etc, when a transaction just fails to confirm.
Anyway, as I see it, even if you're holding 50% of the stake, the odds of getting away with a double spend for even a single block, or successfully choosing to leave a particular transaction out of your block, are only about 1 in 64.
So, yah, you can solve your few hundred hashes and see when the two will meet in the middle as soon as the block starts; but someone else's chances may meet in the middle first, and you don't know when.
Also, there's a point in sending your block around to signatories first; that's so you can't have a "winning" block (ie, one with a lower timestamp or hash than the current accepted block) that will cause a chain reorg, unless you have announced it in a timely way. And also, it allows six different people to submit lists of all the tx they've seen, which you cannot then leave out of the block. So unless six randomly chosen stakeholders are cooperating with you, you cannot leave a chosen transaction out of the block. That ought (I hope) to put a cramp in the style of those who want to double spend, or keep transactions out of the blockchain.
Finally, it allows the idea of an explicit "rejected" message. In the bitcoin protocol, a transaction which conflicts with one that's already been seen simply never confirms. Somebody waiting for a transaction to mature might not realize there's a problem when waiting more than an hour for a transaction to mature. But if you get explicit lists of transactions that must be included from various sources, then you are likely to get conflicting transactions in the same block. That means that if you accept one, you have to accept the other but mark it "INVALID" or "REJECTED" or whatever, and that is likely to happen in the very first block after a double spend is made, so there's no question what's going on or complaint that the miners aren't picking up transactions fast enough, etc, when a transaction just fails to confirm.
Anyway, as I see it, even if you're holding 50% of the stake, the odds of getting away with a double spend for even a single block, or successfully choosing to leave a particular transaction out of your block, are only about 1 in 64.
Guys, I would like to hear your opinion about such PoS algorithm -- https://bitcointalksearch.org/topic/m.3361014
An observation about that plan is that you wind up with a number of tx (per block) equal to the total number of coins in the universe. And each block puts more coin into the universe, so the bandwidth requirement per block grows linearly, and if they stay in the blockchain, then the space required by the blockchain grows geometrically.
Hmmm, that said, until Moore's law hits the wall, bandwidth is growing exponentially, so a linear growth in bandwidth requirements isn't a huge problem. Also, no money changes hands when someone mines unsuccessfully, so it ought to be possible to prune them from the blockchain when they get old enough. All that needs to be remembered at a given moment, if you're regulating via coin age, is when the *last* mining attempt for (or transfer of) a given coin was made. So the blockchain itself need not grow geometrically in the long run.
It's a good idea to regulate stake via coin age, but doesn't really solve the problem of people simultaneously mining in more than one version of the blockchain. After all, they have the same coin age in both versions, and coin age can only be destroyed once (assuming only one chain survives) no matter in how many chains they mine.
However, the idea of having miners announce their intention with a special tx does make anti-cheating measures enforceable. If we assume that the "I am mining" tx must announce which chain it's mining in, then that transaction can be entered in that chain for a possible mining reward, and also in other chains as a guard against cheating. Essentially, if anyone announces mining in more than one version of the block that's at a given height, then that person is clearly cheating. The coin they were using to mine could be simply destroyed by the protocol, or transferred to the winning miner, or whatever.
Hmmm, that said, until Moore's law hits the wall, bandwidth is growing exponentially, so a linear growth in bandwidth requirements isn't a huge problem. Also, no money changes hands when someone mines unsuccessfully, so it ought to be possible to prune them from the blockchain when they get old enough. All that needs to be remembered at a given moment, if you're regulating via coin age, is when the *last* mining attempt for (or transfer of) a given coin was made. So the blockchain itself need not grow geometrically in the long run.
It's a good idea to regulate stake via coin age, but doesn't really solve the problem of people simultaneously mining in more than one version of the blockchain. After all, they have the same coin age in both versions, and coin age can only be destroyed once (assuming only one chain survives) no matter in how many chains they mine.
However, the idea of having miners announce their intention with a special tx does make anti-cheating measures enforceable. If we assume that the "I am mining" tx must announce which chain it's mining in, then that transaction can be entered in that chain for a possible mining reward, and also in other chains as a guard against cheating. Essentially, if anyone announces mining in more than one version of the block that's at a given height, then that person is clearly cheating. The coin they were using to mine could be simply destroyed by the protocol, or transferred to the winning miner, or whatever.
With proof-of-work, you are required to use a resource (kilowatt-hours) that cannot be used to extend more than one chain. With proof-of-stake, your stake exists in both chains, and on the assumption that whichever chain isn't eventually given consensus simply "doesn't exist" there's no remaining evidence that you were trying to cheat.
before they can attempt (just once) to mine a PoS block. If it gets orphaned, tough luck, just like PoW works.
Okay, Gavin was helpful and explained it precisely.
The problem occurs when someone attempts to use his stake to generate blocks in more than one version of the blockchain.
With proof-of-work, you are required to use a resource (kilowatt-hours) that cannot be used to extend more than one chain. With proof-of-stake, your stake exists in both chains, and on the assumption that whichever chain isn't eventually given consensus simply "doesn't exist" there's no remaining evidence that you were trying to cheat.
I think that this can be addressed. But clearly it cannot be done on the basis of "orphaned blocks/chains simply don't become part of the shared history." Orphaned blocks/chains need a way to be sucked back into the main chain, at least insofar as they represent sets of transactions not conflicting with one another.
But coinbase and other chain-specific transactions are by definition going to conflict, so the merge can never be total. I will have to think about it a bit.
The problem occurs when someone attempts to use his stake to generate blocks in more than one version of the blockchain.
With proof-of-work, you are required to use a resource (kilowatt-hours) that cannot be used to extend more than one chain. With proof-of-stake, your stake exists in both chains, and on the assumption that whichever chain isn't eventually given consensus simply "doesn't exist" there's no remaining evidence that you were trying to cheat.
I think that this can be addressed. But clearly it cannot be done on the basis of "orphaned blocks/chains simply don't become part of the shared history." Orphaned blocks/chains need a way to be sucked back into the main chain, at least insofar as they represent sets of transactions not conflicting with one another.
But coinbase and other chain-specific transactions are by definition going to conflict, so the merge can never be total. I will have to think about it a bit.
instead of proof of work
each wallet can only have one address. this address is pregenerated with a "seedcoin". this is an unspendable input(is that even possible).
stake can be generated from this one coin, over two hour periods, but stake can not be generated on its own, it has to be generated by some form of work. one solution for this work, would be boinc. in this setup, the seedcoin would be the parent and the stake would be the children, and are spendable inputs. stake is generated based on boinc utilization scores over a two hour period, similar to grid coin but different as boinc its self serves as a pseudo-proofofwork. in order to secure the stake chain, all clients are coded to compute work using no greater than 1% cpu of host machine.
each wallet can only have one address. this address is pregenerated with a "seedcoin". this is an unspendable input(is that even possible).
stake can be generated from this one coin, over two hour periods, but stake can not be generated on its own, it has to be generated by some form of work. one solution for this work, would be boinc. in this setup, the seedcoin would be the parent and the stake would be the children, and are spendable inputs. stake is generated based on boinc utilization scores over a two hour period, similar to grid coin but different as boinc its self serves as a pseudo-proofofwork. in order to secure the stake chain, all clients are coded to compute work using no greater than 1% cpu of host machine.
The whole point of a double spend attack is reusing coins (reusing stake). There's no penalty for making the attempt in Bitcoin nor any other Proof-of-Work chain.
There is a penalty. One must expend resources (hashing power) to attempt such an attack in a PoW system. No such overhead exists in PoS. See the following:https://bitcointalksearch.org/topic/m.3104704
https://bitcointalksearch.org/topic/m.2392797
https://bitcointalksearch.org/topic/m.2521367
https://bitcointalksearch.org/topic/m.2014924
If you don't understand the basic pros/cons to these two protocols you don't have any business launching a coin. Technical issues aside, there are a host of logistical issues that make such a system infeasible.
Okay, I may be dense here, but I'm not seeing what there is about a Proof-of-stake system that makes this attack any easier.
I don't want to launch a crapcoin that dies to a protocol disaster in the first few days, so I really do need to know exactly what threat I'm defending against here.
The whole point of a double spend attack is reusing coins (reusing stake). There's no penalty for making the attempt in Bitcoin nor any other Proof-of-Work chain.
And the way I've outlined it above, there is no need for anyone to even have all the claimed transactions in a block to reject it if it's bogus, so there's no way to attack bandwidth. All you have to do is check the coin address that the payout would go to, the hash of the last block, and the claimed nonce. Make a single hash, see that it doesn't meet the target or match the claimed hash, and reject the block. In fact, the signers can reject invalid blocks more cheaply than the attacker can create them (because the attacker is also constrained by bandwidth).
So .... just not seeing a DoS problem here that's worse than with any other coin.
I don't want to launch a crapcoin that dies to a protocol disaster in the first few days, so I really do need to know exactly what threat I'm defending against here.
The whole point of a double spend attack is reusing coins (reusing stake). There's no penalty for making the attempt in Bitcoin nor any other Proof-of-Work chain.
And the way I've outlined it above, there is no need for anyone to even have all the claimed transactions in a block to reject it if it's bogus, so there's no way to attack bandwidth. All you have to do is check the coin address that the payout would go to, the hash of the last block, and the claimed nonce. Make a single hash, see that it doesn't meet the target or match the claimed hash, and reject the block. In fact, the signers can reject invalid blocks more cheaply than the attacker can create them (because the attacker is also constrained by bandwidth).
So .... just not seeing a DoS problem here that's worse than with any other coin.
So there are vague notions that it is unsafe but nobody has a specific reason why?
Because unlike proof of work, proof of stakes are reuseable. An attacker can reuse the same stakes an infinite amount of times until he succeeds. And he doesnt lose anything and isnt penalized in the process.Could you elaborate? When you generate a proof of stake the source input is locked for a while.
What prevents anyone from doing that in any existing POW/POS system?
It'd just be easier under a PoS only system.
Distribution would probably be your only problem
lol and thats not becoming a problem with POW
So there are vague notions that it is unsafe but nobody has a specific reason why?
Because unlike proof of work, proof of stakes are reuseable. An attacker can reuse the same stakes an infinite amount of times until he succeeds. And he doesnt lose anything and isnt penalized in the process.Could you elaborate? When you generate a proof of stake the source input is locked for a while.
What prevents anyone from doing that in any existing POW/POS system?
So there are vague notions that it is unsafe but nobody has a specific reason why?
Because unlike proof of work, proof of stakes are reuseable. An attacker can reuse the same stakes an infinite amount of times until he succeeds. And he doesnt lose anything and isnt penalized in the process.Could you elaborate? When you generate a proof of stake the source input is locked for a while.
Only if you can find Biggs
Biggs is dead. Wedge is a survivor. He knows when is the right time to pull out.
So there are vague notions that it is unsafe but nobody has a specific reason why?
Because unlike proof of work, proof of stakes are reuseable. An attacker can reuse the same stakes an infinite amount of times until he succeeds. And he doesnt lose anything and isnt penalized in the process.Isn't that kinda how POS works in the first place? That's not an attack, that's just the POS process...? but I'm sure I misunderstand something.
So there are vague notions that it is unsafe but nobody has a specific reason why?
The initial distribution is the biggest problem, I think. The thing about a proof of stake system is that until someone has coin, nobody can get coin. It operates more like interest than pay for work.
I do not really have a solution for that. But rich get richer really is how the world works.
Anyway I'm open to all the suggestions people come up with, but most of the obvious ideas fail in the presence of sybil attacks. All that it has to be is verifiable via software and not farmable. And there is nothing that requires that there be only one giveaway.
The initial distribution is the biggest problem, I think. The thing about a proof of stake system is that until someone has coin, nobody can get coin. It operates more like interest than pay for work.
I do not really have a solution for that. But rich get richer really is how the world works.
Anyway I'm open to all the suggestions people come up with, but most of the obvious ideas fail in the presence of sybil attacks. All that it has to be is verifiable via software and not farmable. And there is nothing that requires that there be only one giveaway.
An alternate is to have a different kind of proof-of-work. Instead of hashing, have people actually contribute somehow. Reward coin to people that resolve software bugs, or offer services, or contribute to an official wiki, or even just for advertising in their sig. That way you kill two birds will one stone. It would handle the distribution, and it would make the coin bigger/stronger all at once.
It was my idea. I get the first reward.
Only if you can find Biggs
So there are vague notions that it is unsafe but nobody has a specific reason why?
The initial distribution is the biggest problem, I think. The thing about a proof of stake system is that until someone has coin, nobody can get coin. It operates more like interest than pay for work.
I do not really have a solution for that. But rich get richer really is how the world works.
Anyway I'm open to all the suggestions people come up with, but most of the obvious ideas fail in the presence of sybil attacks. All that it has to be is verifiable via software and not farmable. And there is nothing that requires that there be only one giveaway.
The initial distribution is the biggest problem, I think. The thing about a proof of stake system is that until someone has coin, nobody can get coin. It operates more like interest than pay for work.
I do not really have a solution for that. But rich get richer really is how the world works.
Anyway I'm open to all the suggestions people come up with, but most of the obvious ideas fail in the presence of sybil attacks. All that it has to be is verifiable via software and not farmable. And there is nothing that requires that there be only one giveaway.
An alternate is to have a different kind of proof-of-work. Instead of hashing, have people actually contribute somehow. Reward coin to people that resolve software bugs, or offer services, or contribute to an official wiki, or even just for advertising in their sig (all proportionally of course). That way you kill two birds will one stone. It would handle the distribution, and it would make the coin bigger/stronger all at once.
It was my idea. I get the first reward.
So there are vague notions that it is unsafe but nobody has a specific reason why?
Because unlike proof of work, proof of stakes are reuseable. An attacker can reuse the same stakes an infinite amount of times until he succeeds. And he doesnt lose anything and isnt penalized in the process. Jump to: