I just thought of a particularly tricky situation regarding snapshots of DACs with BitAssets and was hoping to get some reassurance or explanation of how we could handle this hypothetical situation.

Let's say we wanted to at some point create a snapshot of BTSX stake to fork off a BitShares X clone that allowed for dilution. The idea is that at the point of the fork people have equal stake in BTSX and BTSXD (BitShares X with dilution), but then they have the ability to sell one and buy more of the other depending on their preferences. After the fork, the price of BTSX would quickly drop while the price of BTSXD (after being available for trading on exchanges) would quickly rise from zero, until they reach a new initial equilibrium. Let's say the market is initially equally split on which DAC is better, so the price of BTSX suddenly drops to half after the fork. Isn't this a huge black swan risk to the BitAssets on the original chain? It would be even worse if the market consensus favored the new chain more.

Are we supposed to split the BitAssets (both holdings and amounts owed by shorts) between the two DACs? Meaning we actually create two new forks (BTSXD and BTSX'). BTSX' would be the continuation of BTSX but with the adjusted BitAssets. The idea is that after the fork, BTSX becomes completely worthless (and all BitAssets on their chain are also worthless), but people effectively "continue" that chain with the BTSX' chain and its adjusted BitAssets. Also, they have the remainder of their BitAssets on the BTSXD chain. BitAsset holders still keep the same value of BitAssets as before, and they can use cross-chain trading to get the BitAssets over to their preferred chain.

The problem is that we need to decide how to split the BitAssets between the DACs depending on how we expect the value of BTSX to be split into BTSX' and BTSXD. This decision needs to be made before the actual fork, but we won't know the true market valuations until after the fork. Thus, we need some mechanism of estimating BTSX holder consensus of how much they think each future DAC is worth. If the estimation is too inaccurate, we risk a black swan event in one of the forked chains (accuracy of estimation needed is of course dependent on the minimum collateral ratio).

I am concerned with the community support for low delegate payrates (for example see this thread: https://bitsharestalk.org/index.php?topic=7553.0).

There is a reason public corporations do not pay out dividends to shareholders until much later in their lifetime. That money can be better used by reinvesting into the company. The growth in the company's stock made possible from the reinvested money (if done well) can provide greater value to shareholders than giving out dividends.

DACs are no different. The income of the DAC is the network fees which are collected by the delegates. By lowering the payrate, delegates are essentially paying out dividends to the DAC stakeholders. But in the early stages of DACs like BitShares X, that money can be more efficiently used by reinvesting in the DAC. In the case of DACs, that means the delegates need to transfer the money collected from fees to individuals/organizations/firms that have a plan to improve the DAC and the ecosystem. Transparency is incredibly important so that stakeholders know the appropriate amount of BTSX was transferred from the delegate who received the fees to the organizations who deserve to get them. The stakeholders indirectly get to choose which organizations receive the money by voting for delegates that pay the fees to the desired organizations. I think Agent86's worker model would be a better way of doing this personally, but this is the way it has to be done in the current system.

I think it is incredibly important in these early stages to use the vast majority of the network fees to fund further development and marketing. There are so many important things to fund. I would like to see some funds go to I3 so they can hire more people to work on important efforts such as lightweight clients, further improving the user interface, and porting the clients to all relevant platforms (mobile, desktop, web). I would like to see funds go to firms who want to create multisig security companies, chain servers, and even a BitPay-like service that provides (initially) free technical support for merchants who want to set up clients to accept BitUSD. And of course funds should also go to marketing organizations who will spread the news about BitShares, make the mechanics and value of the system very easy to understand, convince merchants to accept BitUSD, and convince users of the benefits of holding BitUSD or other similar BitAssets.

The purpose of this thread is to convince people to not waste our potential. Bitcoin core developers have trouble getting funding even though BTC has over a $6 billion market cap. DPOS can fix this problem because it makes DACs profitable. Let's take that profit and reinvest it to grow the value of BTSX even more. I hope this starts the discussion of how we should spend the profit and which organizations are best able to execute the plans that we envision will grow BTSX value.

This is an incredibly minor complaint meant for the devs who I know are super busy, but then again I think it's a really simple fix.

For some reason CMakeLists is setup to build the web wallet code in the source directory during make buildweb. Shouldn't that go into the build directory instead?

The way I build on my system is to keep the build directory separate from the source directory (the directory I do git pull updates on). But after doing the git pull and git submodule update commands, I can't just do "cmake -DINCLUDE_QT_WALLET=ON ../bitsharesx & make buildweb & make" in a new build directory because make buildweb complains about htdocs already existing. But if the HTML interface changes, then I cannot leave out make buildweb or else I will get the old UI in the Qt client, correct? So, I need to go delete bitsharesx/programs/qt_wallet/htdocs (and possibly bitsharesx/programs/web_wallet/generated and bitsharesx/programs/web_wallet/dist) before running make buildweb. However, if make buildweb were to create and check for the existence of these directories in the build directory rather than the source directory, this inconvenience wouldn't be necessary.

After the discussion at https://bitsharestalk.org/index.php?topic=6584, I realize it is really important to have a coherent argument to address the POS vs POW debate. The hard part of getting other cryptocurrency fans, who are not already enlightened about POS, over to BitShares is going to be addressing all of their concerns about POS, Nothing-at-Stake, and their belief that POW is necessary for secure consensus. The other difficult challenge that will need to be addressed is convincing the POS believers, and NXTers in particular, that there is an appropriate balance between centralization and decentralization, and that hopefully DPOS has properly struck that balance to be decentralized enough (and with low enough barrier to entry) to be corruption-free and trustless, but centralized enough to be efficient (low transaction fees and fast block production). There is already great discussion on that topic happening at https://bitsharestalk.org/index.php?topic=5564. But this topic is not about the centralization vs decentralization argument but rather the POW vs POS argument.

This is a first draft, and I would appreciate feedback. I hope I didn't make mistakes in understanding some of the details of the technologies, but please correct me if I am wrong. I am also interested in what people think about my arguments about the economics of fake blockchain history attacks for resync periods less than the threshold (and whether 6 months is even an appropriate threshold or not). I really want to try to develop an argument that can address POW supporters' concerns and convince them that POS is the right way to go.

POW vs POS consensus systems

People in the POW (Proof-of-Work) community generally accept the concept of Nothing-at-Stake as a fundamental flaw in POS (Proof-of-Stake) consensus systems that make those systems, in their view, inferior to POW consensus systems. What is Nothing-at-Stake and is it actually a legitimate concern in practical POS systems? I hope that I will be able to convince people that it is not really an issue, and that, on the contrary, POS has many advantages to POW.

All consensus systems require all participants to maintain a consistent view of a shared database as the database is modified over time. In blockchain-based consensus systems, this database is a log of appended blocks of data, in which each block (other than the first block, called the genesis block) contains a hash of the content of the previous block. This forms a cryptographically secure chain of blocks such that modifying any block requires modifying all of the blocks that come after it in the chain. In a blockchain-based consensus system in which all participants are always connected to the network, consensus can be maintained as long as all participants can agree on which block to append next. Temporary network disruptions may cause some short forks which need to be resolved quickly. So, some other mechanism is also needed to resolve these forks. Finally, since all participants cannot be online all of the time, some mechanism is needed for participants to safely resync with the network after some period of time offline.

Deciding which block to append next:

POW systems use a stochastic computational process, called mining, to determine which block everyone agrees to accept and
append to the blockchain. It is essentially a cryptographic lottery in which the probability of winning is a function of a specific form of computational power (called hashing power) and the current consensus-accepted difficulty. Anyone can verify that a block won the cryptographic lottery by looking at the block and knowing the current difficulty.

The POS system in Peercoin also uses mining to determine which block everyone agrees to accept next. However, in this case the probability of success is a function of hashing power, the current consensus-accepted network-level difficulty, and the coin-age (product of the unspent transaction output value and elapsed time since transaction was created) of the stake used for block production. The function has a very strong dependence on the coin-age such that it is more profitable to buy more coins (or stake) to increase coin-age than to buy more computing power to increase hashing power. Again, anyone can verify that a block won the lottery by looking at the block, knowing the current network-level difficulty, and verifying that the coin-age used to produce the block is legitimate (which requires having a consistent view of the blockchain up to that point).

The POS system in BitShares is called Delegated Proof of Stake (DPOS), because it allows stake owners to delegate the power that their stake provides to other users called delegates. This power is the same power that stake provides in Peercoin and other POS systems: the power to create new blocks. Given a consistent view of the blockchain up to a certain point, anyone can know who the current active delegates are, the order in which these delegates will produce blocks in the current round, and thus which specific delegate is responsible to produce the next block. A cryptographic lottery in the form of mining is not necessary to determine who earns the right to produce the next block. Random values from the non-colluding delegates of the previous round determine the random ordering of the delegates for the next round. Stakeholders are able to vote for delegates using their stake through cryptographically-secure transactions that are stored in the blockchain, and the voting activity by the stakeholders can change the set of active delegates at any time.

Resolving short forks:

Due to the nondeterministic nature of mining as well as network propagation delays, short forks are possible in both POW systems and Peercoin-like POS systems. Network propagation delays may also cause extremely short forks in DPOS as well.

POW systems resolve the forks by agreeing to build on the chain with the most work done (the sum of the difficulty values at each block up to current head block in the blockchain). If everyone follows this rule, eventually all the nodes will come to a consensus on one particular chain, thus resolving the fork.

Peercoin-like POS systems can resolve the fork by building on a chain with the most amount of some other metric, like the total amount of coin-age consumed. Again, as long as everyone follows the same rule, the network will eventually naturally converge to just one of the forks.

Although, DPOS is able to randomize the order of delegates within a round, the order of the delegates in a given round is known prior to any of the delegates producing blocks in that round. For this reason, block production order can be considered deterministic. Nevertheless, very small forks could be possible because of network issues. For example, if block N is delayed by the network for too long, the producer of block N+1 might assume that the producer of block N was not available to produce his block at his designated time slot, so instead will chain off block N-1. The producer of block N+2 may have seen block N and/or block N+1. If he saw both, he always chooses the one that is supposed to come later in time, on the other hand if he sees only one or the other, he builds off of the one he saw. Thus, the chain is built with either block N or block N+1 considered missing, but the network is able to quickly get back to a consensus on the true chain because of the deterministic ordering of block producers.

Resyncing with the network after some period of time offline:

So far, the assumption has been that all participants were well connected to the network and therefore able to easily maintain consensus on the blockchain. Under these assumptions POW does not provide any advantages over POS. But realistically, users cannot always be online. And yet, they need some way of reconnecting with the network and getting up to speed on the current state of the blockchain from where they last left it without allowing an attacker to fool them onto a fake chain. If an attacker is able to fool the user into believing in fake additions to the blockchain since the last block seen by the user's client, the attacker can break consensus and thus damage the value of the network. In particular, the user becomes vulnerable to a double-spend attack by the attacker since they think they are getting tokens of value in exchange for goods/services (due to belief in the fake transaction history) but others on the true chain know that those tokens are worthless and will therefore not accept them in exchange for goods/services.

POW resolves this issue by using the same method used to resolve short forks: pick the chain with the most work done. Attackers have no way of faking the block acceptance criteria. They need to put in the work necessary to match the difficulty requirements at that point in the blockchain. Attackers can create a fake blockchain history by putting in the necessary work, but if they have less than <50% hashing power, their accumulated amount of work will be less than the accumulated work of the true chain. As long as the true chain is made visible to the resyncing user, he can easily pick it over the fake chains.

POS tries to resolve this issue by also making it difficult for attackers to fake the block acceptance criteria. In the case of Peercoin-like POS systems, it needs to be difficult for attackers to get coin-age (which is ultimately dependent on the amount of stake in the attacker's control). In the case of DPOS, it needs to be difficult for the attacker to get control of the delegates. Because of the way delegates work, the attacker would actually need to control nearly all of the 101 delegates to fake the blockchain history (see here and here for details). However, if the attacker controlled more than 50% of the stake, he could vote in all of his own delegates. So all POS systems are ultimately vulnerable if the attacker is able to get the majority of the stake. For a POS system to be secure from fake blockchain history attacks, the majority of the stake in the system needs to be kept away from the control of an attacker during the time a user is offline. However, if an attacker was able to capture only a small minority of the stake while the user was offline, the attacker cannot create a fake blockchain that the user would accept as valid.

POW supporters like to point out that the attacker does not need to control >50% on a live system; as long as an attacker controls >50% of the stake at any point in time t on the blockchain, that attacker could easily build a fake blockchain from that point forward that would fool a user's client if its last resync point was before time t. For a completely new user synchronizing from the genesis block, this means the attacker only needs to control >50% of the stake at any point in time in the history of the blockchain. This is the meaning behind the Nothing-at-Stake name. The users who owned >50% of the stake in the system in the past, may no longer own any stake in the system in the present. While it would be foolish for a present-day >50% stake holder to harm the network, someone who held >50% of the stake in the past but holds nothing at stake in the present has nothing to lose with an attack attempt.

As bad as this may look for POS systems, with more careful analysis, it is clear it is not actually a problem. A user in a POS system will always have a checkpoint in the not-too-distant past. This checkpoint either comes from the last block of the locally-saved, trusted blockchain (or perhaps just the locally-saved hash of the last seen block), or it can be hardcoded into the particular version of the wallet. As long as that checkpoint is in the not-too-distant past, users would not be vulnerable to fake blockchain history attacks in realistic scenarios. If the checkpoint is older than some threshold, then other measures are needed. This threshold can vary depending on the circumstances of the network and the paranoia of the user, but I think a threshold of 6 months is sufficient in most realistic scenarios.

Resyncing after being offline for less than 6 months should not be a cause for concern of fake blockchain history attacks. The only way such an attack can successfully work is if the attacker obtains ownership of >50% of the stake existing at some point during that 6 month period. The attacker would like to buy old private keys at very low cost from users who had stake in the system in the 6 month period but now no longer do. They have to no longer have stake in the system otherwise they would be foolish to sell old private keys to someone whose only purpose for buying old keys is clearly to attack the system and thus reduce the value of the seller's existing stake. But the attacker will not be able to find enough private key sellers that match that criteria, because it is extremely unlikely for stakeholders with >50% of the stake to completely exit out of the system within a 6 month period. The attacker is forced to legitimately buy into the system at a high cost if he wants to attack the network. But an attacker who grows his stake over some period of time until it reaches >50% would likely not attack the network while still holding the stake, otherwise they would cause the most damage to themselves. If the attacker is able to begin and finish selling their >50% of stake during that 6 month period, then the attacker has the opportunity to carry out a fake blockchain history attack against the victim who was offline for 6 months. However, the price one pays trading assets depends on how quickly they need to finish the trade. The attacker can take his time building up the stake to not have to overpay in order to incentivize stake holders to sell, but he is forced to sell at a discount to incentivize enough people to buy to quickly sell off his stake before the 6 month deadline. Pulling off this kind of buy-sell cycle is going to cost the attacker a lot of money. It is only rational to do this if this one buy-sell cycle provides him with enough opportunity to recover his costs through double-spend attacks. But the only people he can attack are people who were offline for about 6 months. Most people would be resyncing at much higher frequencies than that, which would be really hard to attack. Trying to sell >50% of stake in one week would cause a flash crash of the price of the coin (hurting the attacker the most). Also, from a practical manner, the attacker doesn't have any good way of knowing who has been offline during the same time period they set up the buy-sell cycle to actually target these individuals. So, even if there are a decent number of people out there that the attacker could target to make his money back, it isn't trivial to identify them.

So what about resyncing after being offline for more than 6 months? With the exception of resyncing from a genesis block on a new computer, it would be a very unusual circumstance to be doing this. The vast majority of people would be resyncing on a much more frequent basis. Nevertheless, in these rare cases, users would follow the same procedure that users who are resyncing from a genesis block on a new computer would follow. First, if the user already has an up-to-date blockchain on one computer and they just want to set up their wallet on a new computer, the clients could provide an easy method for the existing trusted client to communicate a hash of a recent block to the new client. Since a user obviously trusts himself and the client he has already been using, he can carry over that trust to the new device. What about a completely new user who has never been part of this network before? Or someone who lost their hard drive (but still has a backup of their private keys) and wants to reinstall the client from scratch on their computer? In these cases, the users would rely on the snapshot hardcoded in the latest version of the client software (which would be <6 months old). A new user needs to download the client software anyway; and, they need to have some way of trusting the software they download. If the attacker was able to provide a fake client with a fake snapshot, they would again be vulnerable to the fake blockchain history attack. But if the attacker was able to provide a fake client, the user would be compromised in so many ways. The fake client could just steal the user's private keys! Or if they are using a hardware wallet, the fake client could present a false view of the blockchain to make the user think he got paid when he didn't.

Ultimately there has to be some trust when it comes to these consensus technologies. Bitcoin users may not worry about fake blockchain histories because of POW, but if their wallet is compromised none of that matters. Therefore, Bitcoin users still need to somehow trust the Bitcoin client software they run on their computers. They can compile from source, but they still need to trust that the source is safe. They can rely on other people to audit the source code and tell them it is safe, but then they are just putting the trust on the auditors. Those auditors could collude together to attack the user. If the user is really geeky, he can audit the source code himself, which would take a very long time.

Similarly, in a POS system, the users also typically rely on either the developers or auditors to tell them that a particular client is safe to use. But that also carries with it the information of the most recent snapshot. If the developers try to change the snapshot hash to carry out a massive fake blockchain attack, auditors who have the legitimate blockchain up to the time of the client upgrade stored locally on their computer can check to see that the snapshot hash does not match any of the blocks on their stored blockchain and sound the alarms. If the user does not want to trust the developer or the auditors, he can audit the source code himself, but he would also need to somehow verify the latest snapshot hash. If he has a stored version of the blockchain up to client upgrade time, he can verify it the same way the auditors did. If he is evaluating this starting from scratch, then he needs to ask people he trusts that have already been on the network for a while that the hash is correct (and thus whether this program he has on is computer is going to connect him to the thing everyone else is already connected to). This may seem like a lot of work, but it is far less work than the code audit.

Advantages of POS over POW:

The point of all of the above was to show that in realistic scenarios, the cost of a 51% attack is too high to benefit the attacker. It is typically too expensive to get 51% of hashing power of a high hash rate proof of work coin for the minimal benefits it provides (killing the network and/or difficult to acheive double-spends). And, it is typically too expensive to get 51% of the stake in a high market cap coin for the minimal benefits it provides (killing the network and/or difficult to acheive double-spends). But users trade the guarantee that fake blockchain history attacks are virtually impossible in POW systems for an assurance that fake blockchain history attacks are merely highly improbable in POS systems. If that was the only difference between POW and POS, it would make sense to use POW. However, there are a few very important ways that POS is actually superior to POW.

In a POW system, if the attacker has enough hashing power to attack a POW system, he can also attack any other weaker POW system that uses a similar hashing algorithm. On the otherhand, buying up 51% of the stake of a POS system does not give the attacker any advantage for attacking another POS system. On the contrary, it is likely going to consume the attacker's money, leaving him too little money left over to do it again. This is incredibly important when one realizes what would likely happen if someone was foolish enough to try to buy 51% of the stake in a DPOS DAC only to kill it by taking over the delegates and refusing to sign blocks. People can take a snapshot of the failed DAC, identify the unspent transaction outputs which were voting for the corrupt delegates at the time of the DAC failure, and create a new genesis block from that snapshot with those particular unspent transaction outputs made void. A DAC identical to the previous failed one is created using this new genesis block, which takes stake control away from the attacker leaving the other innocent 49% of stake holders with 100% of the stake of the new DAC. Those who sold to the attacker should be happy because they made a voluntary exchange and got out before the DAC failed; those who did not sell to the attacker are also happy because they doubled their stake in a DAC that will quickly regain its old value, which should hopefully compensate them for the brief outage of the DAC.

The other major benefit of POS over POW is the cost needed to secure the network. In a POW system, the security of the network is directly tied to the cost of mining. If the cost of mining is cheap, an attacker can afford to gain more than 50% of the hashing power. No amount of clever mining algorithms or ASICs will change that relationship. As the electricity cost per gigahash goes down, the difficulty will go up to keep the total cost of mining high enough to secure the network. At some point when growth in the value of the system saturates and it can no longer support large coin inflation to pay miners, like is the case in Bitcoin currently, the cost of securing the network will fall entirely on the transaction fees. POW will either have higher transaction fees than POS systems to secure the network, or if users do not accept transactions fees that are too high, the security of the network will get worse. POS systems do not suffer from these issues because they do not need to waste the money from fees on electricity to secure the network. And in fact, as the system gets bigger (meaning the market cap grows) the POS system becomes even more secure naturally because it becomes harder for an attacker to acquire >50% of the stake.

Does the BitShares toolkit currently have support for multisig transactions? And how does that work with TITAN? It would be great if there was some documentation on it.

Regardless of the current state of support of multisig, I think it would be really great if registered accounts could post their default multisig preferences. I suppose they can include that information today by storing it in the public data JSON, but I would like a protocol where the wallet clients of people sending money by default automatically respect the multisig wishes of the recipient. This would make multisig for the purposes of security far more convenient, since the receiver of money wouldn't have to immediately spend the transaction to themself just to secure it with multisig.

For example, one could upload 3 public keys to the blockchain under their account name, one of them a primary key and the rest secondary keys. The primary private key would be used to derive the shared SECRET used to decrypt the memo (also maybe a 4th observer key could also do this to track received transactions on the user's behalf). The secondary keys would not be able to derive SECRET (and thus not see the memo or who the transaction was from), but would be necessary to sign the user's spending transactions with a 2 of 3 multisig. One of the secondary public keys would be that of a user-chosen third-party validator that validates the user's spending transactions, and for the other secondary public key, its randomly generated private key would be encrypted and stored offline as a backup (possibly split among friends and family using something like Shamir's Secret Sharing). It should also be possible to change the public keys stored on the blockchain under the registered account at any time, again using multisig.

This kind of functionality would be incredibly useful from a security standpoint. In fact, I think the default behavior of the wallet should be to ask users to setup 2 of 3 multisig. Normal operation for the user would be to use a secure connection to the semi-trusted third-party validator to prove their identity in some way and send the transactions for the validator to sign. The strength of the proof of identity could vary depending on the conditions of the transaction, anything from just a BitShares XT Login to coming into a facility in person to verify using bio-metrics. If the validator is suspicious of the user's activity, or the accumulated spent amount of money signed by the validator in the last 48 hours is larger than some threshold, etc., then the validator can ask for a stronger proof of identity as a safeguard against thieves compromising your wallet (hacking, extortion, etc.). If the user no longer trusts the validator, or the validator is refusing to sign legitimate requests, the user can always wait until they can get access to their offline key and together with the primary key spend any transaction they want (most likely to change the validator on their account).

I am interested in what bytemaster has to say with regards to: incorporating this functionality in all BitShares DACs; whether this needs a hard fork to accomplish; how multisig works with TITAN and without compromising user privacy; and, assuming the blockchain and network allows for all of this today, how much of a priority it is to implement this functionality in a user-friendly way in the clients.