Profits, Performance, Trust & Efficiency

[etherbroker]

Hate to be rude, but is there any way to supply a TL:Dr?

I think that human beings can secure the network instead of miners. 
Is that the main idea?

[bytemaster]

The problem with random round robin, is that a director could become a dictator with just a tad bit of mining to select himself again.  Though I suppose you could set it up so that you are out of the running if you have been selected in the past 10 blocks....

You're right, I forgot this mining isn't hard, so it wouldn't be hard to brute-force the desired hashes.

Maybe make it so that any director can never mine more than 2 blocks in a row.  If the hash comes up to the same director, move on to the next 2 digits in the hash.

Well, no, there's a problem with that too.  A cabal of Directors could come up with hashes that would only pass it around within their group.  And this would be possible for a cabal of any size; if we implemented the "past 10 blocks" rule, then a cabal of 11 Directors could hold the chain indefinitely.  Hmmm....

Ok, how's this: Random round-robin, but nobody can have a turn before everybody else has had a turn, and no back-to-back blocks for any Director (in case they happen to be the last block of one round, they can't be the first block of the next round).

I just don't want there to be a pre-determined flow of blocks from one to the next Director.  Then a set of, say, a given 3 directors would always be mining 3 blocks in a row, and they could collude to allow a double-spend or something.

Considering the increase in the block rate, the certainty of being fired, and the fact that no other peers would (or other directors) would honor blocks produced late I don't think a double spend is possible under any circumstances except the complete isolation of a single user.   If you want to be 'certain' that your block is confirmed simply wait for the majority of the directors to confirm it.   You could have 20 directors confirm it in the time it takes Bitcoin to confirm a single block.  These 20 directors would likely represent the stake of 51% of the network or more. 

[bitbadger]

The problem with random round robin, is that a director could become a dictator with just a tad bit of mining to select himself again.  Though I suppose you could set it up so that you are out of the running if you have been selected in the past 10 blocks....

You're right, I forgot this mining isn't hard, so it wouldn't be hard to brute-force the desired hashes.

Maybe make it so that any director can never mine more than 2 blocks in a row.  If the hash comes up to the same director, move on to the next 2 digits in the hash.

Well, no, there's a problem with that too.  A cabal of Directors could come up with hashes that would only pass it around within their group.  And this would be possible for a cabal of any size; if we implemented the "past 10 blocks" rule, then a cabal of 11 Directors could hold the chain indefinitely.  Hmmm....

Ok, how's this: Random round-robin, but nobody can have a turn before everybody else has had a turn, and no back-to-back blocks for any Director (in case they happen to be the last block of one round, they can't be the first block of the next round).

I just don't want there to be a pre-determined flow of blocks from one to the next Director.  Then a set of, say, a given 3 directors would always be mining 3 blocks in a row, and they could collude to allow a double-spend or something.

[bytemaster]

The problem with random round robin, is that a director could become a dictator with just a tad bit of mining to select himself again.  Though I suppose you could set it up so that you are out of the running if you have been selected in the past 10 blocks....

[bitbadger]

Well, this round-robin "Board of Directors" does sound better than a single "Trustee"/"Timekeeper", but the move away from some sort of PoS implementation leaves me much less comfortable with BitShares.  I have refined some of the ideas that I've come up with and posted on this board earlie

Define PoS... I have kept the spirit of PoS and added a simple delegation... it is like mining pools without the barriers to entry or the risk of trusting your coins to someone else.   

I reviewed the rest of your proposal and find it very interesting but still suspect that is suffers one of the biggest problems to overcome: it is too complex to analyze all potential attacks.    It also suffers from the fact that it is more costly (bandwidth, blockchain size) due to the overhead of proof-of-connection and these costs make it less competitive. 

I think the key is to remove the randomness from the equation and increase the size of the board of directors until you are sure it is decentralized enough.    One though on increasing the size of the BOD is to have every BOD member post collateral equal to the earnings from 100 blocks.  If they fail to produce a block on schedule or voluntarily resign with enough notice then they lose 100 blocks worth of pay.   With this setup you could increase the size of the BOD to a minimum 1% of the votes.    You also cause anyone running for a BOD position to promise better than 99% uptime or they will lose money.   If you do this though then the round-robin technique would have to be adjusted to be proportional to the number of votes you have.   I may have to make it proportional anyway so that shareholders are fairly represented... but perhaps by not making it proportional shareholders will be encouraged to diversify who they support least they reduce their influence.

Well, with each addition to the # of directors, this gets more and more palatable to me, but still it feels like an awful compromise compared to a pure PoS implementation.  I agree with the "Is it better than Bitcoin?" test is a good one, but at the same time, it's a low bar to pass.  You had a good idea with TaPoS, and stake being implemented as destruction of transaction fees.  I believe in you and your ability to brain-muscle your way through the various problems with PoS.  I think you're one of the few people in the world who could get it right.  I hope that, at least, once you get done with BitShares implemented as a BoD, and a bunch of DACs are up and running successfully, you turn your mind toward the PoS problem once again.

You are right, of course; the attack vectors for PoS are numerous, but I think the attacks will only get more concentrated/powerful/sustained by selecting certain nodes to act as Directors.

How will the "campaigning" work?  How will the voting work?  How will I verify that my chosen Director is fulfilling his duties?  Will any of this take place on a sideband, such as this forum?  I do like the idea of thinking of the Directors like a "pool" which is competing for miners.

I think the voting should not require a minimum % needed, no maximum % cap; instead, the top 100 (or 50, or whatever; perhaps it should scale to the # of votes in the system?  5k votes = 10 Directors, 50k votes = 100?  Something like that) vote-getters will always be Directors, and blocks will be randomly round-robin'd based on the hash of the previous block.  First 2 digits found in the hash, determine the director.  a0jEdoKf0 = director #00, rQ3k4pR5 = director #34, etc.  Director #00 = top vote-getter, and so on. 

[bytemaster]

Well, this round-robin "Board of Directors" does sound better than a single "Trustee"/"Timekeeper", but the move away from some sort of PoS implementation leaves me much less comfortable with BitShares.  I have refined some of the ideas that I've come up with and posted on this board earlie

Define PoS... I have kept the spirit of PoS and added a simple delegation... it is like mining pools without the barriers to entry or the risk of trusting your coins to someone else.   

I reviewed the rest of your proposal and find it very interesting but still suspect that is suffers one of the biggest problems to overcome: it is too complex to analyze all potential attacks.    It also suffers from the fact that it is more costly (bandwidth, blockchain size) due to the overhead of proof-of-connection and these costs make it less competitive. 

I think the key is to remove the randomness from the equation and increase the size of the board of directors until you are sure it is decentralized enough.    One though on increasing the size of the BOD is to have every BOD member post collateral equal to the earnings from 100 blocks.  If they fail to produce a block on schedule or voluntarily resign with enough notice then they lose 100 blocks worth of pay.   With this setup you could increase the size of the BOD to a minimum 1% of the votes.    You also cause anyone running for a BOD position to promise better than 99% uptime or they will lose money.   If you do this though then the round-robin technique would have to be adjusted to be proportional to the number of votes you have.   I may have to make it proportional anyway so that shareholders are fairly represented... but perhaps by not making it proportional shareholders will be encouraged to diversify who they support least they reduce their influence.

 

[bytemaster]

Why do you need 'blocks' as such for transactions in this kind of scheme? When you send a transaction, it can get signed by 2-3 'metronodes' and then it is accepted by the network. This will also make transactions near instantaneous, limited only by speed of network propagation.

Might not be for this, but in future it will be interesting if we get some 'on-demand' chain instead of a blockchain.

Because each block is proven with a hash.  You can prove all of the transactions in the block by proving the block.  Each block also proves the prior blocks in the chain.  An atomic transaction system that still uses a chain-like structure like you propose would require each transaction to be rather large.

Also that would be putting too much power in the nodes.  They only have veto power, they do not have the power to declare it valid.  All nodes on the network perform this function are reject any block signed by a director that violates the articles of incorporation of the DAC.

[bitbadger]

Why do you need 'blocks' as such for transactions in this kind of scheme? When you send a transaction, it can get signed by 2-3 'metronodes' and then it is accepted by the network. This will also make transactions near instantaneous, limited only by speed of network propagation.

Might not be for this, but in future it will be interesting if we get some 'on-demand' chain instead of a blockchain.

Because each block is proven with a hash.  You can prove all of the transactions in the block by proving the block.  Each block also proves the prior blocks in the chain.  An atomic transaction system that still uses a chain-like structure like you propose would require each transaction to be rather large.

[bitbadger]

Well, this round-robin "Board of Directors" does sound better than a single "Trustee"/"Timekeeper", but the move away from some sort of PoS implementation leaves me much less comfortable with BitShares.  I have refined some of the ideas that I've come up with and posted on this board earlier, and created a proposal for a new implementation of Proof-of-Stake with Proof-of-Connection.  I think that it fixes many of the issues that current PoS coins have.  I have recently posted this to both bitcointalk and peercointalk forums.  This will be my last attempt to convince you to go with PoS.  I believe that you, Dan, have the ability to implement this better than anybody else could.  This proposal has the benefit of being compatible with TaPoS, and I believe that it is novel.

There are two parts to this proposal: Stake-Days (and Stake-Days Destroyed) and Proof-of-Connection.

Stake-Days are the rough analogue of Coin-Days.  As Stake-Days go up, PoS mining difficulty goes down.  If I hold 30 coins for 30 days, my Stake-Days are equal to 900.  This is the equivalent of somebody with 900 coins holding them for 1 day.  The key part is this: My Stake-Days only drop back to 0 when I actually mine a block with that stake.  Since Stake-Days are only reset to 0 when a block is mined, they can be transferred from one address to another without being reset.  The stake travels along with the coins (and can probably be additive within a given address, although this may make things too complicated).  If I receive coins from you, and your coins have Stake-Days built up, I receive that stake when I receive the coins, and my chances of mining a block with that stake are just as high as they were when you held that stake.  (So sending a transaction from one of your own addresses, to another of your own addresses, if you were vying for a block in TaPoS, would NOT destroy your Stake-Days.  You could simply try again with the next block.)  Proof-of-Stake mining still remains a stochastic process, but every address has its own difficulty level based on the stake associated with that address.

Now for Proof-of-Connection.  A big problem with existing PoS coins (and indeed, PoW coins) is that nobody is incentivized to run a full node.  With (say) PeerCoin, if I have low stake and little chance of mining a PoS block, I can turn off my PeerCoin client and leave it off for a month or three while my stake continues to build.  I am not helping to secure the network or propagate transactions when my node is turned off.

So there needs to be a way to make stake dependent on running a node continuously.  The proposed mechanism for this is as follows:  Every block has a hash.  Let's say the hash for a given block starts with ABC.  Once this block is created, every address matching AxxxxxxBxxxxxxC (or some other formulation; this is just an example) must "check in" by sending a transaction to themselves to prove that they're connected.  These Proof-of-Connection transactions will be included in the next mined blocks.  This transaction does not lose Stake-Days or Coin-Days.  If this Proof-of-Connection transaction does not appear in a block within X blocks (perhaps 30 minutes' worth?) of the triggering block, their Stake-Days drops back to 0.  This would prevent people from accumulating stake by simply keeping their coins dormant.

The parameters could be chosen to try different lengths of expected-time-to-check-in, which would also be dependent on the block production rate.  I would suggest a target of something between 6 and 24 hours, although given the random nature of this process, and in the interest of having smaller blocks, perhaps longer times could be used.  On a coin with fast blocks, maybe 2 or 3 bytes would be required to match; on a coin with slow blocks, just 1 or 2.  Of course, full bytes would not necessarily be required; it could be a bitwise match of a certain number of arbitrary bits from the hash of a block, matched with arbitrary bits from the coin address.  Full bytes just make it easier to understand.

The Proof-of-Connection transactions will include the hash of the entire blockchain up to and including triggering block, signed with the address's private key, in order to tie the PoC transaction with the block that triggered it and also to prove that the address is running a full node.  Due to the random nature of this process, all stakeholders will be incentivized to keep their nodes up and running all the time.  If they want to shut down for a few days, they will simply not earn stake during that time.

[sumantso]

Why do you need 'blocks' as such for transactions in this kind of scheme? When you send a transaction, it can get signed by 2-3 'metronodes' and then it is accepted by the network. This will also make transactions near instantaneous, limited only by speed of network propagation.

Might not be for this, but in future it will be interesting if we get some 'on-demand' chain instead of a blockchain.

[bytemaster]

Not being a programmer, I'm unfamiliar with the 'job description' of a representative of a mining pool; and extrapolating - to the theoretical "knights of the round table" of BitShares. 

Out of pure curiosity - what is that user experience like for approving a block with current mining pools?  What would it be like for BitShares X?  ...What would keep someone from writing a software program to approve the block automatically if they are AFK?  If this were possible - would it create [unidentified by the network] false trust in the board members?

For starters, this is all entirely automatic.  In the case of BitShares X there is a system preferences setting with sane defaults and the user can change the setting if they know what they are doing.   Any time the user makes a transaction these setting will automatically be respected.   If the software detects one of the directors is misbehaving then the user interface will show a warning to the user.   The user can then change their settings and either wait until the next time they make a transaction or make a transaction immediately.   Whether they pay a fee to change their vote immediately or wait to piggy back on a normal transaction will depend upon the severity of the behavior.    In any case, immediate user intervention is not necessary. 

In the case of Bitcoin, a director must setup and maintain a mining pool infrastructure.  They are subject to DDOS attacks because their servers are public, and they can be shutdown by governments.   Users must first detect that their miners are off line (view a warning) and then point them at a new pool.  Often miners are setup with an automatic failover pool.   Most miners do not audit the blocks being produced by the pool they are on.  In fact, as we experienced with ypool not including transactions in PTS blocks, most miners don't even care what the pool operator is doing so long as they get paid. 

Shareholders on the other hand care if their delegate isn't producing blocks or including transactions because it will affect their dividend payments and share valuation.   

[G1ng3rBr34dM4n]

Not being a programmer, I'm unfamiliar with the 'job description' of a representative of a mining pool; and extrapolating - to the theoretical "knights of the round table" of BitShares. 

Out of pure curiosity - what is that user experience like for approving a block with current mining pools?  What would it be like for BitShares X?  ...What would keep someone from writing a software program to approve the block automatically if they are AFK?  If this were possible - would it create [unidentified by the network] false trust in the board members?

[bytemaster]

I kept coming to either TAPOS with stakeholder-elected nodes for either Ripple-like or NXT-like block production. I was leaning towards Ripple (see unity+tapos post) because I thought getting to pick transactions for your block if there is a market is a no-no? Think they would just get caught and get fired?

Yes... manipulation would be statistically detectable and they would get fired.  The amount of manipulation would be very small and any profits earned would just be part of the cost of doing business.   

[toast]

I kept coming to either TAPOS with stakeholder-elected nodes for either Ripple-like or NXT-like block production. I was leaning towards Ripple (see unity+tapos post) because I thought getting to pick transactions for your block if there is a market is a no-no? Think they would just get caught and get fired?

[bytemaster]

I want to make one thing clear, I do not attempt to manipulate public opinion as suggested above by introducing something very centralized so my slightly more decentralized solution will be selected.   If I were any other man I might be offended by such insinuation.

My real challenge here is that I know several things for certain:

1) Proof of Work is not just unprofitable, it results in the worst kind of centralization and control.
2) Proof of Stake systems are more experimental and only Nxt has a pure proof-of-stake system.
3) Ripple is a form of consensus where you trust a set of nodes not to collude, but where growing this set of nodes from 5 nodes all controlled by Ripple to 1000's of nodes in a manner that doesn't fork the network is an unresolved issue.   Effectively Ripple is a club that gradually adds members and these members collectively agree to reach consensus.   Ripple uses a complex algorithm for this club and if the core members of the club go one way then the shareholders (XRP) have no say. 

So I am sitting here trying to innovate solutions that are better than everything that has gone before and this involves deep thought about the nature of the problem, the risks involved, etc.   Fortunately the DAC metaphor gives us the answers we need.

1) We want to give shareholders a way to delegate their vote to a key that doesn't control their coins 'so they can mine'.
2) We want to maximize the dividends shareholders earn
3) We want to minimize the amount we must pay people to secure the network.
4) We want to maximize the performance of the network
5) We want to minimize the cost of running the network (bandwidth / CPU / etc)

So the key is that the shareholders remain in control.  If they remain in control then it is decentralized and as much as I hate voting on anything, when it comes to shared ownership of something like a company it is the only viable way.  Fortunately if you do not like who is running the company you can sell and this market feedback causes shareholders to vote more rationally than citizens.   

So every shareholder gets to vote for someone to sign blocks in their stead (a representative if you will).  Anyone who can gain 5% or more of the votes can join the board.  No representative may have more than 20% of the delegated votes.  The representatives become a "board of directors" which take turns in a round-robin manner signing blocks.  If one of the directors misses their turn clients will automatically switch their vote away from them and eventually they will be voted off the board and someone else will join the board. 

So how is this different than Bitcoin?   In bitcoin the users must pick a mining pool and each pool generally has 10% or more of the hash power.  The operator of these pools is like a representative of the clients pointed at the pool.   Bitcoin expects the users to switch pools to keep power from becoming too centralized, but collectively 5 major pools control the network and manual user intervention is expected if one of the pools is compromised.   If a pool goes down then the block production rate slows proportionally until it comes back up.   Which pool one mines in becomes a matter of politics.

Therefore, I am expecting the same kind of behavior from users of BTS X except instead of having to point their hashing power at a pool, they merely change a setting in their wallet.  This setting can even be setup with a chain of command so that users do not have to think much about it.  Instead of only miners voting, everyone can vote.  Like bitcoin, if a representative goes down, block production will slow by a proportional amount until the representative comes back on line or users vote them out of office automatically.

The reason to avoid randomly selecting the representative from all users is the following:

1) high probability they are not online
2) attackers would gain control proportional to their stake without any peer review...
3) without any mining at all, the generation of a random number in a decentralized manner is impossible and thus an attacker could control the random number generation.

The benefits of the representative approach is that:
1) After fewer than 20 blocks ( 10 minutes or less ) almost everyone has indirectly ratified the block-chain through their representative in an immutable way.
2) block production can be much faster
3) no one can prevent transactions from getting included in the chain for more than 10 minutes... compared to bitcoin this is HUGE.

So from the perspective of decentralization I believe I have a design which achieves more than Bitcoin, Nxt, or Peercoin can hope to achieve with a much higher level of security in a much more rapid manner than previously possible.