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

0 Members and 1 Guest are viewing this topic.

Offline bytemaster

The problem with all existing systems (except Ripple) is that blocks are 'centralized' in who defines the block.  When you add markets to a blockchain this becomes a problem.

The Ripple algorithm allows many nodes to reach consensus and provided you have a solid set of Unique Nodes you don't have to trust any one node.

I believe that the Ripple algorithm can be used to build blocks, and transactions as proof-of-stake can be used to slowly ratify those blocks over time.   Your transactions would confirm almost instantly and once enough CDD have passed the state is beyond reproach in the event all of the major UNL are taken down (internet Kill switch) and the network must restart on the other side.

Why should we try to replace something Ripple has already solved?   

So you're proposing a hybrid system, that's a combination of Ripple's consensus algorithm, and transaction POS? I think this could work very well, and I like the idea of combining the fast confirmation time of Ripple with the added security of POS

Keyhotee helps build a darknet of solid UNL based upon all of your friends and family.  Tie in a couple of 'super nodes' from major businesses and exchanges and the network consensus would be very robust.
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
The problem with all existing systems (except Ripple) is that blocks are 'centralized' in who defines the block.  When you add markets to a blockchain this becomes a problem.

The Ripple algorithm allows many nodes to reach consensus and provided you have a solid set of Unique Nodes you don't have to trust any one node.

I believe that the Ripple algorithm can be used to build blocks, and transactions as proof-of-stake can be used to slowly ratify those blocks over time.   Your transactions would confirm almost instantly and once enough CDD have passed the state is beyond reproach in the event all of the major UNL are taken down (internet Kill switch) and the network must restart on the other side.

Why should we try to replace something Ripple has already solved?   

So you're proposing a hybrid system, that's a combination of Ripple's consensus algorithm, and transaction POS? I think this could work very well, and I like the idea of combining the fast confirmation time of Ripple with the added security of POS
Protoshares: Pg5EhSZEXHFjdFUzpxJbm91UtA54iUuDvt
Bitmessage: BM-NBrGi2V3BZ8REnJM7FPxUjjkQp7V5D28

Offline bytemaster

The problem with all existing systems (except Ripple) is that blocks are 'centralized' in who defines the block.  When you add markets to a blockchain this becomes a problem.

The Ripple algorithm allows many nodes to reach consensus and provided you have a solid set of Unique Nodes you don't have to trust any one node.

I believe that the Ripple algorithm can be used to build blocks, and transactions as proof-of-stake can be used to slowly ratify those blocks over time.   Your transactions would confirm almost instantly and once enough CDD have passed the state is beyond reproach in the event all of the major UNL are taken down (internet Kill switch) and the network must restart on the other side.

Why should we try to replace something Ripple has already solved?   
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
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.

Wouldn't that generate an awful lot of network spam? At each block, each node would have to know what each other node has voted?


I have an idea based on a lottery system.

It requires the introduction of another type of coin-days that are reset after each block. I'll refer to as BCDs, for Block Coin-Days.

After a node receives a block, it takes the hash of the block and the hash of its Bitshares address, and applies a binary AND on them. The result is a speed of BCD gain per coin.
The node can then compute the number of BCD held by its address as a function of time: BCD = time_since_last_block * (block_hash AND address_hash) * number_of_coins.
It will broadcast a block when the amount of BCD reaches a target set by the protocol, depending on previous blocks. The block must reference the outputs used to generate the BCDs.


The idea is that the node with the highest BCD gain speed ((block_hash AND address_hash) * number_of_coins) will win. As time passes, it is more and more likely that someone will meet the target (like PoW), and the randomness prevents the biggest stake-holders from always publishing the block. They still have more chance of meeting the target though, since the expected value of the BCD gain speed is proportional to the amount of resources owned (also similar to PoW).
Unlike some other lottery systems addresses, this does not reward splitting your funds into multiple addresses.

Difficulty target can be initialized analytically to target a specific block generation time, as the distribution of Protoshares can be calculated at the genesis of Bitshares. However, I think target adjustment would have to be completely empirical afterwards (increase if blocks are generated too fast, decrease if too slow).
To help constrain block generation time, I think a polynomial weighting of time could be used (e.g.: use time_since_last_block^4 instead). If time_since_last_block < 1, it is harder to reach the target. If time_since_last_block > 1, it is easier. Stronger degrees increase this effect.

Latency is not an issue, given that if you receive two blocks, you can easily see which one met the target first. However, this implies using the sum of BCDs to determine the main chain (at least to some extent).

I really like this approach and am attempting to internalize it.

Glad you like it :)

However I just realized I was a little too hasty in assuming the probability to broadcast a block was proportional to the coins you owned.
This is because when you are a small owner, you do not just need to be lucky to publish a block, you also need all the bigger owners to be (much) less lucky than you.
In other terms, it's not BCD that should be proportional to the number of coins owned, it's the probability that your score will be the highest, which is not the same.

A quick fix would be to use "lottery tickets" instead of addresses. Each ticket has a value equal to hash(signature(hash(previous_block)+sequence_number)). If you have 3 coins, you have 3 tickets (sequence numbers 1, 2 and 3. All tickets are equivalent, so this time your odds to win are truly proportional to your number of coins, i.e.: number of tickets.
Then when time_since_last_block^n * AND(ticket, hash(previous_block)) ==  target, you can claim your gains by broadcasting the new block, with your signed message embedded.
If you try to claim ticket 4, it won't work because the other nodes know you don't have 4 coins.
The use of a signature is to deter people from trying to guess other people's tickets and engineering blocks that would be better for them (adding/shuffling transactions). It might not be necessary, depending on how long/how much it takes.

EDIT: another variant, even closer to PoW. Remove time_since_last_block from the target calculation. Instead, everybody draws additional tickets every second: ticket = hash(signature(hash(previous_block)+sequence_number+seconds_since_last_block)). Now it truely is like PoW, and there is some hashing involved, but your contribution is capped by your stake and not by your hardware. If you have 1000 coins, your are capped at 1kH/s. Of course, units are arbitrary.
The benefit is that it makes block generation time less variable.

EDIT2: It seemed to me all these lottery systems are potentially vulnerable to block engineering: if someone had enough hashing power, they might be able to produce favorable blocks with very few coins, by performing minor changes on the list of transactions.
I suppose the system could be made resistant to block engineering by only taking the hash of fields in the block that cannot be altered for lottery purposes, like the signature of the reward claimer and the block height. If you have a ticket good enough to claim the reward, your only degree of freedom is to claim it or not, so your possibilities for block engineering are very limited.
New blocks still have to reference the hash of the previous full block (i.e.: including transactions) though, for obvious security/consensus reasons.
« Last Edit: December 16, 2013, 05:14:01 pm by arkanaprotego »

Offline arkanaprotego

  • Newbie
  • *
  • Posts: 11
    • View Profile
I just thought of a variant of the BCD system I proposed: use BCD from the Protoshares chain to secure the Bitshares chain, and issue Bitshares through subsidies, based on ownership of PTS  (somewhat like Bitcoin, but using Protoshares as "hashing power"; subsidies don't have to be for finding blocks though, read below). I haven't really thought about all the implications yet, but I realized there was no reason to keep security and wealth so tightly coupled, so I'm putting this idea on the table. All comments are welcome.

Pros:
- Strong incentive to keep Protoshares in the long run: "mining" Bitshares
- There is a public (yet pseudonymous) ledger of "hashing power" (PTS), so this mining does not require centralization and few special transactions: no matter how little you "mine", just parse the Protoshares chain to see how many Bitshares you (or anyone) can claim from "mining", and claim them at the same address on the Bitshares chain using a special transaction from time to time (e.g.: once a day). EDIT: You can also bust freeloaders: do not award subsidies if the claiming address could have published better blocks than those in the chain but did not.
- Increase liquidity of Bitshares, since you don't need to hoard more to earn more.
- Bitshares distribution is not simply the result of the snapshot of Protoshares at one point in time, but at all points in time: the wealth distribution is not set in stone; see the case of Nxt: the whole money supply was issued at launch. 70 people hold all of it and are just sitting on it, preventing any one from entering the market at a similar price.

Cons:
- You have to remember to keep an eye on the distribution of PTS to make sure it is not overly centralized.
- This might lead to an increase in the price of PTS, reducing the last pro, but if it is still easier to buy PTS than ASICs, I'll still consider this a success. Unlike ASICs, PTS do not age. EDIT: Also, no pre-orders.
« Last Edit: December 16, 2013, 10:57:51 am by arkanaprotego »

Offline phoenix

  • Sr. Member
  • ****
  • Posts: 275
    • View Profile
I mean Trustees as central points of failure.  Even with 100 trustees, that's only 100 private keys to capture to completely control the network.

True, the more Trustees there are the better. I would hope that the people running for Trustee positions would keep their wallets encrypted.
Protoshares: Pg5EhSZEXHFjdFUzpxJbm91UtA54iUuDvt
Bitmessage: BM-NBrGi2V3BZ8REnJM7FPxUjjkQp7V5D28

Offline Lighthouse

  • Sr. Member
  • ****
  • Posts: 376
  • Making a Market in PTS since 11/06/2013
    • View Profile
    • Lighthouse Bulk Orders and Trusted Escrow (Closed)
I mean Trustees as central points of failure.  Even with 100 trustees, that's only 100 private keys to capture to completely control the network.
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
Agreed, that is a REALLY interesting proposal. 

Trustees are tempting but I think taking that shortcut will bite us.

I think that it wouldn't actually bite us to much, since if there was any attempt to manipulate the block chain, people would stop voting for the Trustees responsible for the manipulation, and then they would quickly lose power, and things would continue just fine.
Protoshares: Pg5EhSZEXHFjdFUzpxJbm91UtA54iUuDvt
Bitmessage: BM-NBrGi2V3BZ8REnJM7FPxUjjkQp7V5D28

Offline Lighthouse

  • Sr. Member
  • ****
  • Posts: 376
  • Making a Market in PTS since 11/06/2013
    • View Profile
    • Lighthouse Bulk Orders and Trusted Escrow (Closed)
Agreed, that is a REALLY interesting proposal. 

Trustees are tempting but I think taking that shortcut will bite us.
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 bytemaster

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.

Wouldn't that generate an awful lot of network spam? At each block, each node would have to know what each other node has voted?


I have an idea based on a lottery system.

It requires the introduction of another type of coin-days that are reset after each block. I'll refer to as BCDs, for Block Coin-Days.

After a node receives a block, it takes the hash of the block and the hash of its Bitshares address, and applies a binary AND on them. The result is a speed of BCD gain per coin.
The node can then compute the number of BCD held by its address as a function of time: BCD = time_since_last_block * (block_hash AND address_hash) * number_of_coins.
It will broadcast a block when the amount of BCD reaches a target set by the protocol, depending on previous blocks. The block must reference the outputs used to generate the BCDs.


The idea is that the node with the highest BCD gain speed ((block_hash AND address_hash) * number_of_coins) will win. As time passes, it is more and more likely that someone will meet the target (like PoW), and the randomness prevents the biggest stake-holders from always publishing the block. They still have more chance of meeting the target though, since the expected value of the BCD gain speed is proportional to the amount of resources owned (also similar to PoW).
Unlike some other lottery systems addresses, this does not reward splitting your funds into multiple addresses.

Difficulty target can be initialized analytically to target a specific block generation time, as the distribution of Protoshares can be calculated at the genesis of Bitshares. However, I think target adjustment would have to be completely empirical afterwards (increase if blocks are generated too fast, decrease if too slow).
To help constrain block generation time, I think a polynomial weighting of time could be used (e.g.: use time_since_last_block^4 instead). If time_since_last_block < 1, it is harder to reach the target. If time_since_last_block > 1, it is easier. Stronger degrees increase this effect.

Latency is not an issue, given that if you receive two blocks, you can easily see which one met the target first. However, this implies using the sum of BCDs to determine the main chain (at least to some extent).

I really like this approach and am attempting to internalize it.
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

Decentralized Continuous Election of Trustees

Suppose we were to accept the notion that it may be beneficial to have a handful of “trusted” individuals around to certify the official block-chain.   We would want to ensure that these trustees are indeed trust-worthy and not simply self-appointed opportunists who had enough capital to corner the voting market.   Everyone should have a an opportunity to vote without having to purchase special hardware or spend billions every year in electricity just to cast their vote.  Lastly, only those who currently own the currency should have a vote proportional their investment in the currency instead of giving the vote to foreigners who have no current interest in the currency.

Fortunately such a voting system is easy to setup by utilizing a concept known as coin-days-destroyed by a transaction to vote for trustees.  Coin-days-destroyed is calculated as your account balance multiplied by the length of time you have held that balance.    When you create a transaction to make a purchase you also include the address of the Trustee you would like to vote for using the coin-days destroyed by the transaction.

Each trustee would accumulate coin-days-destroyed in their voting balance, and when they vote on a block they consume some of their accumulated coin-days.  The best block is the one which has been voted upon by the most trustees.    While Bitcoin block creation is centralized in one person at a time, this new system would require several unique individuals as elected by the shareholders to approve every block.  As a result not even a single block is centralized into a single user.

The trustee’s could use a consensus model based upon the Ripple algorithm to agree on which blocks to create.    This means that in theory blocks could be produced multiple times per minute.   

Trusting the Trustees in an otherwise Trust-less system. 

The major innovation of Bitcoin was that it claimed to create a trust-less currency; however, as we have seen recent developments have reintroduced trust focused on the mining pools.   Does electing Trustees to certify the network open the network up to abuse of power?  In our opinion there is no such risk as the Trustee cannot create transactions that violate the rules of the block-chain and they have their signature on every block they produce.  Any trustee that signed two different blocks that would result in a double spend could be held accountable and of course as long as there are more honest trustees than dishonest trustees this is not a problem.
Modify message
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

At the Inside Bitcoin conference in Las Vegas the CEO of Butterfly Labs did a presentation on “The Future of Mining”.   In his presentation he pointed out that about 5 people collectively control 75% of the hashing power behind Bitcoin and 2 people control over 51%.   He then made the case that this centralization was good for Bitcoin because it means they could coordinate to rapidly resolve unexpected forks such as the one that occurred in March 2013.     According to Sonny Vleisides, without this centralization in mining Bitcoin would have died 9 months ago as decentralized clients would have been unable to reach a consensus on which fork to follow in a timely manner.

Whether or not you agree that Bitcoin would have died,  Sonny Vleisides has effectively admitted that Bitcoin has become centralized, that a small handful of powerful pool operators can unilaterally decide which block chain fork is the “official” fork, that they all know each other and that they effectively vote on which chain to support.   The session ran out of time before I had an opportunity to publicly ask the following question:  “If a small handful of self-appointed people have taken it upon themselves to decide which chain to officially support, then why should the Bitcoin ecosystem spend $1 billion dollars per year in electric costs to provide the same effective security as having 2 or 3 signatures on every block that costs next to nothing while providing infinitely more security?” 

Whether signatures or hashing power, the regular Bitcoin user has no more control over the official block chain policy than the regular Federal Reserve Note user has over official monetary policy.   Their only way to ‘vote’ is to switch to another currency which will have a smaller network with fewer exchanges, products, and services available to it. 

The fact that mining results in centralization should not have been a surprise to those who understand economies of scale.  Mining profitability is a function of efficiency and large centralized mining farms powered by the latest capital-intensive ASICs packaged and cooled in an industrial setting will eventually push all profitable mining into the hands of a single player.  Effectively, mining means that consensus is defined by an organization that can derive profits from alternative revenue streams such as taxation, tainted coins, or limiting transactions to privileged players.   It means that in the name of ‘progress’, these large miners will support other changes to the protocol that also benefit from economies of scale such as reducing block intervals, increasing block sizes, and offering instant transaction validation services.   
We have come to the conclusion that there is no traditional proof-of-work system that can provide security and decentralization at the same time.  A new approach is needed.
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 gloine

  • Newbie
  • *
  • Posts: 11
    • View Profile
Hi,

I want to point out one aspect of Proof-of-Stake system. It is vulnerable to physical attacks on major shareholders.

You can easily control the system by hacking or spoofing the computers of major shareholders, or just bringing a gun to their home and threatening them to do transactions on the attacker's behalf. In case of PoW, the damage is limited to the attacked person only, but in case of PoS, the whole network is damaged.

So unless major shareholders are rich enough to defend all the physical attacks on themselves (which could be true for crypto-coins but not for DACs), it would be safer to rely on PoW systems to protect the network. In other words, those who 'work' for the network should be distributed and 'replaceable', unlike shareholders.

On a side note, PeerCoin has a vesting period of 30 days and a maximum coin age of 60 days (numbers could have been changed, but it does have them).

Regards,
Gloine

Offline arkanaprotego

  • Newbie
  • *
  • Posts: 11
    • View Profile
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.

Wouldn't that generate an awful lot of network spam? At each block, each node would have to know what each other node has voted?


I have an idea based on a lottery system.

It requires the introduction of another type of coin-days that are reset after each block. I'll refer to as BCDs, for Block Coin-Days.

After a node receives a block, it takes the hash of the block and the hash of its Bitshares address, and applies a binary AND on them. The result is a speed of BCD gain per coin.
The node can then compute the number of BCD held by its address as a function of time: BCD = time_since_last_block * (block_hash AND address_hash) * number_of_coins.
It will broadcast a block when the amount of BCD reaches a target set by the protocol, depending on previous blocks. The block must reference the outputs used to generate the BCDs.


The idea is that the node with the highest BCD gain speed ((block_hash AND address_hash) * number_of_coins) will win. As time passes, it is more and more likely that someone will meet the target (like PoW), and the randomness prevents the biggest stake-holders from always publishing the block. They still have more chance of meeting the target though, since the expected value of the BCD gain speed is proportional to the amount of resources owned (also similar to PoW).
Unlike some other lottery systems addresses, this does not reward splitting your funds into multiple addresses.

Difficulty target can be initialized analytically to target a specific block generation time, as the distribution of Protoshares can be calculated at the genesis of Bitshares. However, I think target adjustment would have to be completely empirical afterwards (increase if blocks are generated too fast, decrease if too slow).
To help constrain block generation time, I think a polynomial weighting of time could be used (e.g.: use time_since_last_block^4 instead). If time_since_last_block < 1, it is harder to reach the target. If time_since_last_block > 1, it is easier. Stronger degrees increase this effect.

Latency is not an issue, given that if you receive two blocks, you can easily see which one met the target first. However, this implies using the sum of BCDs to determine the main chain (at least to some extent).

Offline MrJeans

  • Hero Member
  • *****
  • Posts: 599
    • View Profile
  • BitShares: mrjeans
It looks like the top dogs are talking on this thread so excuse my comments if they seam newbie.

I dont like the idea of mining as it only really benefits the people who mine early on. This is fine at the start when everyone has the hardware to mine and mining can therefore be decentralized.

However, as difficulty increases, mining becomes more centralized (due to technology/know-how constraints on the masses).

I like proof-of-stake as this rewards the persons who are investing in the idea/network/currency. Persons should simply be rewarded for holding the coin  allowing for a steady inflation. If inflation is low enough over the 12 years then the value of each coin should increase over time as the value of the service increases faster than inflation.

This will allow for a decentralized way of distributing new BitShares.

Mining can be used for the processing of transactions and securing the network.

Alternatively why have inflation at all. Why not distribute all BitShares to protoshare holders in one go. People can then mine for transaction fees. (I see how this alternative could be problematic but its something to think about).