If the tokens are not powered up...
The point that @edicted made is that while exchanges ignore it now, because it is not worth the hassle, once adoption kicks in (and token price with it) they will "stake" the tokens of their customers not in order to do something malicious, but in order to gain interest associated with the stake. The fact that they time lock the tokens, and therefore might expose themselves to liquidity problem, won't stop them. They might even do it in legitimate way by asking users for permission, and the experiences of other cryptos tell us, that users will go for it in exchange for some passive income.
The idea behind 30 day delay of stake activation in Hive was that it gives us time to notice a problem and to rally users behind common goal of averting disaster. However if exchanges power up coins for yield, there won't be clear sign of malicious intent. Even if users might be wary at first, there is no way to be in a state of constant high alert. Once everyone sees the exchanges just want to earn money, they will go back to regular business. The 30 days will pass and if at some point an exchange decides to go rogue, we won't have the time buffer anymore.
Even if the exchange never does anything wrong, the fact that its nontrivial stake will be used for automated yield farming is going to be detrimental to the network, in line with any powerful bot. Eventually, as exchanges are regulated entities, they might have no choice but to push for something the rest of us would not want, f.e. promote censorship of certain transactions, or impose strong KYC when creating new accounts etc. It might be easier on Koinos in that aspect because it does not seem to have politics and social agendas embedded in its core functionality.
The proposed solution is to give exchanges a financial reason to use decline_voting_rights_operation. If the benefits are strong enough and the exchange still moves the coins to other non-locked account and powers them up, we'll have much stronger argument that they do it for something bad, warranting stronger response, and there will be still full 30 day delay ahead of us.
There are many things to consider though. Starting from general - how strong the incentives should be: just the passive income from rising price of VESTS, or should we also include part/all income related to curation? We should also consider that stake comes with potential of selling HP and RC delegations. Next technical - the income comes from different sources, depending on answer to first question, so how do we pass correct interest without actually using regular mechanisms? F.e. if we let locked accounts power down instantly (basically turning VESTS into liquid asset), it makes it easy to handle passive income (normal code is used), but it removes safety aspect of time locking stake, which might be a no-no for some. Finally we'd need to predict human behavior - if we give too much incentives, not just the exchanges, but many other users might choose to decline voting for passive income. Which might be good, because such people probably use curation bots at the moment, but if too many do that, it reduces active stake, making it cheaper to do regular money attack. On top of all above considerations I can see some holes in current mechanism, so if we decide to go that path, we'd most likely need to reinvent the operation and reset accounts that used it in the past, so the users can decide if they still want to lock their accounts given new way it's going to work. I'm going to tag @blocktrades and @gtg for some attention, so we can discuss and possibly escalate it further.
For instance, the witnesses with low votes do not have the chance to produce blocks. Maybe a mix between top20 and proportional stake below top20 would be a good solution.
That's exactly how it works in Hive. Witnesses outside of top20 are chosen for 21st schedule position with frequency proportional to the power of their backing. I've described the mechanism here when we had to fix a bug introduced to that mechanism.
It's true that a regular user will not verify it but this is the case of all blockchains.
That's not the point. When dealing with consensus code one can assume someone unrelated actually looked through the changes (it is the job of validators to check that before they vote for new version). Moreover the code is under scrutiny of people that invested a lot of effort (and most likely also money) in the project. That is not true for contracts that anyone can build at any time. Next point is that you don't have to trust compiled version. It is usually very easy to pull source code and run single script to build it (and even if you don't have required compiler installed, Linux is going to tell you what command you have to run in order to install it). Any user can do it. Again, that is not true for contracts. One more thing is that when you build from sources yourself, you know that what you are running is the thing that matches the sources you have. In case of contracts, even if you have the sources and can build them, the build has to be repeatable (exactly the same binary output for each compilation), because you are not going to run it yourself - the nodes are going to run the binaries uploaded to the chain, so all you can do is compare if the uploaded version is the same as what you managed to build (unless of course the contract is uploaded as a source code to be compiled by nodes - that would mean all contracts are open source, enforced by upload mechanism).
Very interesting read. Ok, this is good, I was not aware of this 21 place. But 21 is not enough in my opinion, it should be much more. As I said I prefer this design rather than a pure proportional. It would be good to propose a similar approach in koinos. There is no need to remove the proof of burn mechanism. We just have to limit the effective VHP. The miner can accumulate any amount of VHP, but during the computation of the difficulty their VHP is limited to some value that depends on the total supply. In this way it can reproduce the same strategy used in Hive. But I would like to increase the number of nodes. Let's say the VHP limitation is 1/100 of the total supply, so the top 100 will have the same influence. And change it from time to time depending on the number of miners in the network. @andrarchy
The same logic applies to contracts. If someone is investing a lot of money or efforts in a project, he will make an exhaustive scrutiny whether it is a blockchain or a smart contract. There is no difference because there is money involved.
Correct. This is the process to verify at 100% that the source code matches with the contract in the chain, and in this case there is no doubt of the transparency of the dApp developer. Apart from that, the verifier also has to check if there was a contract in the past for this address, in order to check if the data in the storage was not manipulated. Then it's fine.
For instance, in fogata (the mining pool) we provide a docker to compile the contract. Then the docker will always use the same compiler in order to compile the same binary. Then everyone can verify it matches with the binary in the chain. In the future new services could emerge to simplify this process, like the source code verification used in etherscan.