Author Topic: Transactions as Proof-of-Stake & The End of Mining  (Read 28161 times)

0 Members and 1 Guest are viewing this topic.

Offline arkanaprotego

  • Newbie
  • *
  • Posts: 11
    • View Profile
Re: Transactions as Proof-of-Stake & The End of Mining
« Reply #45 on: December 05, 2013, 04:36:06 pm »
I think the whole concept of using transactions to secure the network is a little risky, especially during the infancy of a crypto. While there are not many transactions, the network is vulnerable. If everybody is sitting on their Bitshares, the first one to move will have a disproportionate influence. Conversely, after busy trading periods, the network will be depleted in CD because of the delay on CD regeneration after transactions. The network will be more vulnerable then as well.

The first flaw I can see in your proposal is related to this: if you only reward the biggest destroyer of CD, then you implicitly penalize the smaller. So to maximize their gains, the others will just keep their CD by hoarding old coins and spending new coins. Meanwhile the network destroys fewer coins and the network is insecure. You need to provide an incentive or a mechanism to ensure there will always be a steady flow of CD. If CDD fluctuates, the blockchain security is lowered, as periods of lower CDD are opportunities for cheap attacks.

Another thing to consider in your latest proposal is that it introduces a single point of failure (the broadcaster), even though you planned some backups.

It is quite vulnerable to a DOS attack. If an attacker were to score all the highest transactions in terms of CDD, he could delay the chain for long. The more fragmented the legitimate transactions are, the cheaper it is to attack the network.

So I think you should not restrict who can broadcast using such a serial scheme.

The issue with CDD in transactions is that they do not completely meet the non-reusability requirement that is necessary in PoW schemes, and probably in all blockchain structures. Transactions are tied to the previous block, but it does not matter what block they are included in, they are always valid. As a result it is trivial and cheap to generate a better block by simply adding a transaction to the original block. I think you need a way to make transactions depend on each other for this to work properly.

Offline bytemaster

Re: Transactions as Proof-of-Stake & The End of Mining
« Reply #46 on: December 05, 2013, 05:43:37 pm »
arkanaprotego,
   Thank you for your response.   Let me see if I can address some of them and find enhancements.

1) People make transactions for the sake of the transaction, there is no need to reward them because they are already paying a fee for their transaction.  As a result choosing to reward the largest CDD (coin-days-destroyed) holder for hanging around to sign the block does not bother the others.

2) CDD variance does affect confirmation times, but does not affect security.  The reason is that security is defined in terms of CDD and not in terms of blocks.  So if there are many small blocks with low CDD then you may have to wait longer.  The good news is that some times you only have to wait 1 block if a large number of CDD are destroyed.  Thus, on average you will wait 1 hour for confirmations, but it could be 10 minutes or it could be 2 hours.   The better news is that you can use your own CDD to accelerate confirmation if you need it quickly. 

3) The DOS attack you mention is easily countered by the existing financial incentives.  If it appears the #1 CDD holder isn't going to sign in a timely manner, the #2 CDD holder will automatically attempt to claim, then the #3 CDD holder, etc...  The outputs that attempted the DOS would be flagged and not included in new blocks by any other node which would force the owner of those outputs to eventually sign a block with them or never be able to spend them.   This flagging process would have to be carefully designed to prevent honest nodes suffering from network latency from being punished, but I am sure there is a metric that will have few false positives.

4) Infancy... the great thing about POS is that your security isn't defined by blocks but by CDD.   Early stake holders can set up automated scripts to periodically provide CDD and those creating transactions can accelerate the CDD confirmations by paying fees to motivate CDD destruction.   Essentially, every honest node looking to earn extra dollars can monetize their CDD.   
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline arkanaprotego

  • Newbie
  • *
  • Posts: 11
    • View Profile
Re: Transactions as Proof-of-Stake & The End of Mining
« Reply #47 on: December 05, 2013, 08:49:20 pm »
bytemaster,

Thank you for your clarifications, but I am not sure you can neglect time that easily when considering security.

1) The best usage of your CD is still to spend them when you are the most certain that you will be the biggest CD destroyer.

3) Let me try another, more graphic attack to show some issues and try to solve them.
I have 34% of the coins. I don't move them for a year, to get the maximum CD out of them. Then I transfer them all to myself. I am most likely the biggest destroyer of CD in the block. I don't sign it. Now 4 sub-cases:
a) You ban my output and start another block without it. Right after that, I broadcast my signed block. Now all the new nodes that are plugged into the network and were not there when you banned me will follow me, because I have the chain with the biggest CDD, and you cut yourself from it. They can also not trust your ban, since you look like the attacker.
b) You don't ban it and start another block without it. I wait for a year. During this year, the average coin is moved every 2 days. With the 1 day delay after each transaction, your 66% coins generated and destroyed less CD than my 34% had then. I publish the block I had saved, and instantly reverse 1 year of transactions. Note that the more you move your coins, the less I need coins.
c) You don't ban it and include it in your next block, signed by #2 CD destroyer. You are quite sure to be in the longest chain of CDD and I have lost all my CD, unless... I publish the block, which is what you wanted me to do in the first place. I must do it fast, because if I wait too much, you will add more transactions to your chain and your chain will be longer in CDD than I can make mine.
d) Same as c, but I lied and I actually had 40% of the coins. After you start on your version of the block with my 34%, I wait until you destroy nearly as much as my remaining 6% are worth in CD, and publish a block with my 6%. This might take long or not, depending on the volume of transactions.

Long story short, I think the delay on CD regeneration is dangerous, because it creates distortions that can be exploited both ways, and that counting security in CDD is quite impractical if CD are not destroyed linearly, as it exposes you to forks originating far in the past. If C coins have not moved since a date T, and CDD(T, now) coin-days have been destroyed between date t and now, then the chain can be forked back to its state at t by someone who controls the coins if:
CDD(t, now) < C*max(now-T, 1 year)
To prevent this, CDD must be high. However, due to the delay, it is faster to generate unspent CD than to destroy CD.
With no delay though, the fork that accumulates CDD at a faster rate is always the one that has the most coins backing it. If these CD were spent automatically, they would prevent forks, as well as the accumulation of CD required for a fork.

Offline bytemaster

Re: Transactions as Proof-of-Stake & The End of Mining
« Reply #48 on: December 05, 2013, 10:14:06 pm »
bytemaster,
Thank you for your clarifications, but I am not sure you can neglect time that easily when considering security.

1) The best usage of your CD is still to spend them when you are the most certain that you will be the biggest CD destroyer.
Assuming you want to take on the role of securing the network, rather than just 'using the network' which is what 99% of users will be doing.  They may randomly profit when they happen to have the most coindays destroyed (because it is their first trx in a year).   So lets assume there is a certain base level of CDD providing security regardless of any other financial incentive.

3) Let me try another, more graphic attack to show some issues and try to solve them.
I have 34% of the coins. I don't move them for a year, to get the maximum CD out of them. Then I transfer them all to myself. I am most likely the biggest destroyer of CD in the block. I don't sign it. Now 4 sub-cases:
a) You ban my output and start another block without it. Right after that, I broadcast my signed block. Now all the new nodes that are plugged into the network and were not there when you banned me will follow me, because I have the chain with the biggest CDD, and you cut yourself from it. They can also not trust your ban, since you look like the attacker.
b) You don't ban it and start another block without it. I wait for a year. During this year, the average coin is moved every 2 days. With the 1 day delay after each transaction, your 66% coins generated and destroyed less CD than my 34% had then. I publish the block I had saved, and instantly reverse 1 year of transactions. Note that the more you move your coins, the less I need coins.
c) You don't ban it and include it in your next block, signed by #2 CD destroyer. You are quite sure to be in the longest chain of CDD and I have lost all my CD, unless... I publish the block, which is what you wanted me to do in the first place. I must do it fast, because if I wait too much, you will add more transactions to your chain and your chain will be longer in CDD than I can make mine.
d) Same as c, but I lied and I actually had 40% of the coins. After you start on your version of the block with my 34%, I wait until you destroy nearly as much as my remaining 6% are worth in CD, and publish a block with my 6%. This might take long or not, depending on the volume of transactions.
I think there was a misunderstanding here... when I said 'ban' I mean I just don't include the transaction in the block I produce, though anyone with more CDD is able to include that transaction.   Considering Orphans are not really an issue, anyone in the top 5 CDD inputs from unique transactions could strip out the largest transaction and broadcast all at the same time.  The network will ultimately accept the block with most CDD regardless of which of the top 5 broadcast.   

Long story short, I think the delay on CD regeneration is dangerous, because it creates distortions that can be exploited both ways, and that counting security in CDD is quite impractical if CD are not destroyed linearly, as it exposes you to forks originating far in the past. If C coins have not moved since a date T, and CDD(T, now) coin-days have been destroyed between date t and now, then the chain can be forked back to its state at t by someone who controls the coins if:
CDD(t, now) < C*max(now-T, 1 year)
To prevent this, CDD must be high. However, due to the delay, it is faster to generate unspent CD than to destroy CD.
With no delay though, the fork that accumulates CDD at a faster rate is always the one that has the most coins backing it. If these CD were spent automatically, they would prevent forks, as well as the accumulation of CD required for a fork.

We need to be very careful when looking at attacks to see what harm can be done... lets start with a very basic premise:

1) Nodes that are connected continuously to other nodes in many continents will see any fork of sufficient age as suspect.  They should not automatically switch to the chain with more CDD simply because it has more CDD.  After all, if all of the nodes on the main chain see this they could simply 'counter' with a few transactions that 'fix' the problem making the public chain the longest again.  I think any fork more than an hour old without any obvious network issues has a higher burden of proof. 

Lets assume that there is no delay in CD accumulation then an attacker with 1/50,000 of the money supply could spend enough CDD every other block to build 50% of the blocks on average. Putting a delay before CD start accumulating of 100 blocks means the attacker would only have 1% influence on block production assuming 1/50,000 of the money supply. 

Note a 51% attack on any proof-of-work network is possible if the attacker has access to 5% of the money supply, even Bitcoin.   5% of the money supply is enough to purchase 51% of the hash power.  $600 million could buy you a 51% attack on bitcoin.  So I think for the purpose of evaluating POS we should only consider attacks that are possible with less than 5% of the money supply otherwise it is an unfair comparison.

For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline bytemaster

Re: Transactions as Proof-of-Stake & The End of Mining
« Reply #49 on: December 05, 2013, 11:53:17 pm »
Ok so in keeping with the DAC metaphor I have realized an entirely new perspective on Proof-of-Stake.  Every shareholder is given one vote per block per share toward establishing a global consensus.   As a result shareholders must vote to the best of their knowledge and not simply vote how everyone else is voting.  The premise here is that in a well connected network there should be no 'big surprises' and thus everyone will have seen everything.  The chances of something you haven't seen being legitimate are very small.

When a new node connects it connects to friends and family as well as well known public nodes and trusts them first. 

If there is a 'dispute' among the shareholders as to which chain is legitimate, many big players get off the sidelines and vote. 

So like Ripple can reach consensus without proof of work, shareholders can also reach consensus without proof of work.  In the short term (1-3 blocks) shareholders vote by largest proof-of-stake, in the long term they vote with what they have known the longest.

To control such a network requires a majority of shareholder votes.   

In the mean time if there is a 'dispute' resulting in a chain-fork, then nodes can follow both forks and include transactions in both forks.  You can consider your transactions 'confirmed' in such a case as long as they are valid on both forks.  Eventually one fork will gain enough of a lead that the other fork stops growing and dies off due to lack of votes and therefore inability to add new blocks. 

I suppose in the event of a chain fork there is also the concept of 'new CDD' and 'used CDD' where 'new CDD' is any CDD older than the fork itself and 'used CDD' is CD earned on the fork.  This alternative measure could also be used to see if a fork is gaining acceptance from new users or simply supporting itself with its own CD.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline arkanaprotego

  • Newbie
  • *
  • Posts: 11
    • View Profile
Re: Transactions as Proof-of-Stake & The End of Mining
« Reply #50 on: December 06, 2013, 10:50:19 am »
Indeed, I think that vote by shares is the way to go. I am just unsure that spontaneous transactions are the best proxy for shares held, as it can be tightly coupled, but also completely decoupled. At the very least there should be an automated safety mechanism to try and reestablish dominance of your branch by destroying CD, should it become the shortest one, if you have been on that branch for long. I don't think most users would be able to override the detection of the longest chain to keep spending more CD on the legitimate branch.

PoS and PoW have similarities: if you want more power, you have to invest, either in ASIC or in shares. But then, unlike CD, hashrate cannot be saved for later. I think it would be nice to mimic this property, by having CD spent continuously on the branch you follow, like hashing power. Your idea of using transactions seems valid, and IMO is a generalization of PPCoin's PoS mining special transactions. What I propose is a reward for all destroyers of coin-days, proportionally to their coin-days destroyed, to reward them for securing the network, and the removal of the delay for CD regeneration, not to penalize transactions. What it means is that CDD/day is constant and equal to the number of coins that endorse a branch by "PoS mining" or spending on it, which is what you wanted to achieve with "votes by shares". As long as the main branch maintains more than 50% of the coins always "PoS mining" (EDIT: by honest nodes), your branch cannot be forked.

Quote
Lets assume that there is no delay in CD accumulation then an attacker with 1/50,000 of the money supply could spend enough CDD every other block to build 50% of the blocks on average. Putting a delay before CD start accumulating of 100 blocks means the attacker would only have 1% influence on block production assuming 1/50,000 of the money supply. 

Sorry I lost you there... You mean both the attacker who has 1/50,000 and the rest of the network that has 49,999/50,000 have the same influence? Unless I missed something, I think no delay only means that whoever has the most money wins, which seems fair in this kind of situation. If someone has more than 50% of the money then something is rotten in the Decentralization.

If I understood your paper well, I think your motivation to introduce the delay was to protect about people owning too many coins. But as you said yourself, if this happened, then any network would be vulnerable.

Unrelated remark:
Quote
Assuming you want to take on the role of securing the network, rather than just 'using the network' which is what 99% of users will be doing.  They may randomly profit when they happen to have the most coindays destroyed (because it is their first trx in a year).   So lets assume there is a certain base level of CDD providing security regardless of any other financial incentive.
No, this is just what an optimized client would do. Sooner or later it will be available to the public.
« Last Edit: December 06, 2013, 12:09:50 pm by arkanaprotego »

Offline bytemaster

Re: Transactions as Proof-of-Stake & The End of Mining
« Reply #51 on: December 06, 2013, 11:18:37 pm »
Here is one additional detail that can be used to evaluate forks:  the only CDs that count toward confirming a fork are CDs earned prior to the fork.  In other words, a fork cannot confirm itself by re-spending coin-days earned after the fork.   

This particular metric is a bit tricky to maintain, but is possible to calculate.   

I also believe that this is the key to preventing CDs from being reused constantly.... you can start accumulating CD immediately after you destroy them, but if you spend them again too soon they do not count.   I think we can define 'too-soon' as before 3-4x as many CDs have confirmed your original CDD.   So, if you control 1% of the money supply and thus destroy a lot of CD at once, you have to wait until another 4% of the money supply confirms your CDD before your new CD fully vest.   In summary, CD must vest prior to being spent.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline arkanaprotego

  • Newbie
  • *
  • Posts: 11
    • View Profile
Re: Transactions as Proof-of-Stake & The End of Mining
« Reply #52 on: December 07, 2013, 04:12:20 am »
Having to let CDs vest sounds reasonable, since that would also prevent people from spamming the network with transactions to themselves.

However I don't see the need to prevent CDs from being reused constantly, it is their purpose. I think there might be some confusion about the temporal aspect of CDs, as you seem to view coin-days only as a resource that accrues in the hands of stakeholders and that can be engineered at will.

The original idea behind coin-days is to measure how many coins back each side of the fork. A coin is detected as supporting a chain when a transaction involving this coin is added to that chain. However, if we simply summed transaction volumes, fast circulating coins would have a disproportionate weight compared to slower circulating ones, and this could trivially be exploited. So we create a new metric by weighting each transaction by (age of the coin at the moment of the transaction)/(time since reference, ex.: genesis), which ensures that all coins have a weight equal to their value, to vote by transactions on what happened between the reference time and now (because the sum of the ages of the coin at the moments of the transactions is equal to the time elapsed since the reference). Since the time since the reference is present in all weights, you can simplify the expressions by multiplying by it everywhere, and you are left with coin-days as vote weights. This is where coin-days come from.

Given expression of coin-days, the rate at which coins accrue coin-days is constant (1/coin/day), and attempts to alter it will break the proportionality between vote value and coin value if the last equality is not verified  (e.g.: with delay, the sum of weights depends on the number and spacing of transactions).
Also notice that it is tricky to use the timestamp of the fork as a reference time, since it won't exactly match transaction dates for most of the coins. As a consequence, right after the fork, branches start with non-zero and most likely non-equal supplies of CDs. In other words, one chain might have a substantial head-start.

My proposal to address this is to force the spending of CDs regularly, so that branches will always start with close to 0 CDs. This can be done by capping coin age to 1 day and by rewarding everybody for destructing their CDs. Under these conditions, the longest branch is automatically the one in which the alive nodes own the most wealth. It also prevents attackers from accumulating CDs in secret (or accumulating CDs at all).

If you really do not want to automate the destruction of CDs, another way to do would be to implicitly reset coin-days at the fork, by not counting CDs accrued before the fork.
Is it what you wanted to suggest? If you really meant not counting CDs accrued after the fork, your metric to evaluate forks would fail to confirm the right branch if the attacker has more CDs when they initiate the attack. And I think it is the only case when an attacker would bother to start a fork, or the fork could be annihilated instantly by the users of the main branch, provided they are programmed to destroy more CDs in case of a forking attempt.

If you go with the second solution (I think the first one does not really need it, but it might still be safer to do it regardeless), it would be nice to prevent CDs from the same outputs from being destroyed in several chains, as it would reduce the gap between the two chains.
The goal is to prevent honest nodes from irreversibly supporting the attack in good faith, if they mistake an attack for the rightful chain during the time it takes the main chain to reestablish its dominance.
A soft way would be to add a rule to the honest clients so they don't reuse outputs.

Offline bytemaster

Re: Transactions as Proof-of-Stake &amp; The End of Mining
« Reply #53 on: December 07, 2013, 05:22:53 am »
CD can only apply to one chain at a time. So I think we are on the same page. 

I agree vesting would take influence from people transacting every block and give it to savers.   An attacker would then have to hold his coins longer. 

I think we have something.




Sent from my iPhone using Tapatalk
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline arkanaprotego

  • Newbie
  • *
  • Posts: 11
    • View Profile
Re: Transactions as Proof-of-Stake & The End of Mining
« Reply #54 on: December 07, 2013, 12:10:48 pm »
Quote
CD can only apply to one chain at a time. So I think we are on the same page. 
Can they? I think this can be enforced, but by default it isn't, since coin age depends on the date of the last transaction, which depends on which chain you are on. After a fork, coins accumulate CDs on every chain, which is something PoW does not have to deal with.

Quote
I agree vesting would take influence from people transacting every block and give it to savers.   An attacker would then have to hold his coins longer. 
I think I see where we differ finally :)
You base your analysis on an opportunist attacker looking for an easy profit, while I base mine on a malevolent powerful entity that just looks to destroy the network. Is that it?
So in consequence you create economic deterrents while I just look to make the requirements as high as possible (owning half of the money supply).
I think both are valid concerns, but I still believe that my solution solves both.

The one question I have for you is: What is the benefit of allowing people to save CDs? If you just want to reward savers over spenders, I think we could just implement two types of CDs, security CDs (SCDs) and investment CDs (ICDs). Investment CDs can be calculated following the rules you set and be used to distribute dividends as you see fair, while security CDs follow my set of rules and are constantly spent in "security transactions" to the same address to secure the network. Just two ways of counting, I don't think the representation in the block chain has to be altered: make ICDs reset when sending to another address, and SCDs reset at any transaction. "Security transactions" don't even split the coins, which makes SCDs easier to track.
Spending SCDs continuously prevents attacks, and allowing ICDs to be saved rewards your long term investors: you get the best of both worlds.


Quote
I think we have something.
Not sure what you're thinking about, but I'll await it eagerly  :D

Offline Lighthouse

  • Sr. Member
  • ****
  • Posts: 376
  • Making a Market in PTS since 11/06/2013
    • View Profile
    • Lighthouse Bulk Orders and Trusted Escrow (Closed)
Re: Transactions as Proof-of-Stake & The End of Mining
« Reply #55 on: December 07, 2013, 03:17:07 pm »
Here is one additional detail that can be used to evaluate forks:  the only CDs that count toward confirming a fork are CDs earned prior to the fork.  In other words, a fork cannot confirm itself by re-spending coin-days earned after the fork.   

This particular metric is a bit tricky to maintain, but is possible to calculate.   

I also believe that this is the key to preventing CDs from being reused constantly.... you can start accumulating CD immediately after you destroy them, but if you spend them again too soon they do not count.   I think we can define 'too-soon' as before 3-4x as many CDs have confirmed your original CDD.   So, if you control 1% of the money supply and thus destroy a lot of CD at once, you have to wait until another 4% of the money supply confirms your CDD before your new CD fully vest.   In summary, CD must vest prior to being spent.

Arkanaprotego mentioned earlier about how an optimized client would essentially "game" the system automatically.   What would just embracing this?  Can there be a "mining mode" that watches the network looking for advantageous opportunities to be the biggest spender in the network at that particular instant of opportunity?   I bet given the opportunity most people would do that instead of letting their coindays acrue and requiring them to time it manually.  Would this even be possible?  Seems like the client would need to monitor transactions being broadcast and when it identifies a lot of transactions smaller than its potential CDD available it opportunistically fires a TX to itself and attempts to claim the block.  Lots and lots of clients doing this on an ongoing basis would create a very level market if I read my incentives correctly.  Latency would be an issue, opportunities would be spotted by many and fired quickly.....   Either way, you see where I'm going here.
Before you say the price of PTS is too high, take a look at theThe Reason.  Protoshares are an entirely new type of Cryptocurrency, one that pays to hold.

Offline phoenix

  • Sr. Member
  • ****
  • Posts: 275
    • View Profile
Re: Transactions as Proof-of-Stake & The End of Mining
« Reply #56 on: December 08, 2013, 11:06:07 pm »
Here is one additional detail that can be used to evaluate forks:  the only CDs that count toward confirming a fork are CDs earned prior to the fork.  In other words, a fork cannot confirm itself by re-spending coin-days earned after the fork.   

This particular metric is a bit tricky to maintain, but is possible to calculate.   

I also believe that this is the key to preventing CDs from being reused constantly.... you can start accumulating CD immediately after you destroy them, but if you spend them again too soon they do not count.   I think we can define 'too-soon' as before 3-4x as many CDs have confirmed your original CDD.   So, if you control 1% of the money supply and thus destroy a lot of CD at once, you have to wait until another 4% of the money supply confirms your CDD before your new CD fully vest.   In summary, CD must vest prior to being spent.

Arkanaprotego mentioned earlier about how an optimized client would essentially "game" the system automatically.   What would just embracing this?  Can there be a "mining mode" that watches the network looking for advantageous opportunities to be the biggest spender in the network at that particular instant of opportunity?   I bet given the opportunity most people would do that instead of letting their coindays acrue and requiring them to time it manually.  Would this even be possible?  Seems like the client would need to monitor transactions being broadcast and when it identifies a lot of transactions smaller than its potential CDD available it opportunistically fires a TX to itself and attempts to claim the block.  Lots and lots of clients doing this on an ongoing basis would create a very level market if I read my incentives correctly.  Latency would be an issue, opportunities would be spotted by many and fired quickly.....   Either way, you see where I'm going here.

This kind of a node would be very useful to network security, since it would only want to spend it's coin days on a legitimate blockchain. I could see people creating optimized versions of this node, that tracks what other nodes are doing, and then attempting to determine which addresses belong to a single node. The node could then have a better chance of being able to capture a block, since it could make a more informed decision about spending it's coin days
Protoshares: Pg5EhSZEXHFjdFUzpxJbm91UtA54iUuDvt
Bitmessage: BM-NBrGi2V3BZ8REnJM7FPxUjjkQp7V5D28

Offline bytemaster

Re: Transactions as Proof-of-Stake & The End of Mining
« Reply #57 on: December 08, 2013, 11:19:15 pm »
I recently came up with another system that could work, though I am not fully sold on it.

What if the share holders elected people who would sign blocks?   You vote for the signers with CDD. When they sign they spend the CDD they accumulated from people voting for them.  No one would be allowed to sign more than 1 in 100 blocks. 

This plan has many potential problems, but I thought I would add it to the idea pool.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline phoenix

  • Sr. Member
  • ****
  • Posts: 275
    • View Profile
Re: Transactions as Proof-of-Stake & The End of Mining
« Reply #58 on: December 09, 2013, 02:12:20 am »
I recently came up with another system that could work, though I am not fully sold on it.

What if the share holders elected people who would sign blocks?   You vote for the signers with CDD. When they sign they spend the CDD they accumulated from people voting for them.  No one would be allowed to sign more than 1 in 100 blocks. 

This plan has many potential problems, but I thought I would add it to the idea pool.

This could actually work at first, since the majority of people would vote for the most legitimate block available. But over time people would develop software to track who was signing legitimate blocks, and then be less likely to vote for new miners. Also, how do you propose we tell the difference between individuals?
Protoshares: Pg5EhSZEXHFjdFUzpxJbm91UtA54iUuDvt
Bitmessage: BM-NBrGi2V3BZ8REnJM7FPxUjjkQp7V5D28

Offline bytemaster

Re: Transactions as Proof-of-Stake & The End of Mining
« Reply #59 on: December 09, 2013, 04:18:43 am »
I recently came up with another system that could work, though I am not fully sold on it.

What if the share holders elected people who would sign blocks?   You vote for the signers with CDD. When they sign they spend the CDD they accumulated from people voting for them.  No one would be allowed to sign more than 1 in 100 blocks. 

This plan has many potential problems, but I thought I would add it to the idea pool.

This could actually work at first, since the majority of people would vote for the most legitimate block available. But over time people would develop software to track who was signing legitimate blocks, and then be less likely to vote for new miners. Also, how do you propose we tell the difference between individuals?

Public individuals would volunteer so people are voting for who should be the custodians of the chain.   It would be like getting to vote for who is mining BTC rather than having it go to whoever could pay the most.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.