Great, so are you going to take the initiative and add a "One BTS One Vote" algorithm into the list of Canonizer algorithms as well as the tools necessary to verify the signatures to allow users to prove stake ownership?
Absolutely. It would definitely be possible to get this to do everything being proposed, and I will do everything in my power to code this and make it happen.
I must warn everyone that I have a full time job, and have other commitments, so the amount of time I can commit to this is limited. If others could step up and help with this, we could get it up and running much faster. There is quite a large list of things that need to be done to get this functional.
I have other commitments as well but I am happy to freely discuss and iterate on the foundation and architectural design of the system I would like to see created. I discuss some of this architecture in this post. The end product of all of this beyond the website itself would be to develop the minimum open source software needed that can communicate with a trusted client using the RPC interface, as well as changes to the client itself, to facilitate any website to create a voting/governance system based on one bts = one vote. The architecture and specifications would also be designed so that the website could optionally provide all the necessary cryptographically-signed proof that it logs to the public so that they can use their client and these open source tools to verify the accumulated votes for any specific issue/topic/camp. I would also support a few delegates to fund the development of these open source tools and the necessary changes to the client (no hard fork changes needed).
Currently, we do the canonization process in real time, every time someone loads the page. I'd think we should be able to have a cashed snapshot of the block chain share ownership being constantly updated, and continue doing this in real time.
Yes, I don't think it should (can?) be done in real time. Here is how I view things happening on the servers of a site like Canonizer that is modified to support this type of BTS voting. The databases on the servers would regularly take certain snapshots of data as it is either updated in real time or computed from a prior snapshot. There would be five classes of snapshots:
- BTS stake devoted to each user on the website.
- Delegation of voting power of users on the website to each other.
- Voting decision by each user on the website for each issue (or camp) on the website.
- BTS voting power controlled by each user on the website.
- The accumulated BTS votes for each issue (or camp) on the website.
The website would have a client running on the servers to gain read-only access to the BTS blockchain/database. People can register users on the website and associate a public key to that user (they locally generate and safely store the private key). Users can optionally associate themselves to a BTS TITAN name if they wish. To do so they need to mutually link the accounts by signing a statement of the link by both the Account key on the blockchain (requires BTS client support) and the private key meant for the user on the website.
Users can at any time update the devotion to their user. Doing so requires signatures from keys that are allowed to vote for (currently that also includes the ability to spend) the unspent BTS balances sitting on the blockchain. This also requires BTS client support. I imagine a simplified process where a link (bts URI scheme) on the website launches the client with a request to update devotion to a user. The client then prompts the user to select all TITAN accounts whose current BTS balances they want to devote to the website user. The user makes the selection and presses the OK button which causes the client to make all the necessary signatures and then feed this data to the website using a HTTPS GET request. The website then gets this data, verifies the signatures are good using its RPC access to the blockchain/database (the data should follow some standard specification and the actual verification should be done by the common open source tools), and updates the BTS balances devoted to the particular website user. The website also needs to use its access to the client to get notified whenever an unspent BTS balance that was used to devote to a user is spent on the blockchain (this requires changes to the client and new RPC APIs). The website can then update the BTS balances devoted to a particular website user if some previously devoted stake now becomes invalid since it was spent to another address. All of these updates to the current devoted stake for each website user is happening in real time.
What is also happening in real time are the changes by the website users in how they delegate their voting power and how they vote on the various issues or which camps they support. Users can split their voting power as they wish to any number of other users on the website. This forms a graph where the vertices are the users and the directed edges are the delegation of voting power. It is important to avoid cycles in this graph (so it should be DAG, directed acyclic graph). Thus the request to change a user's delegation of voting power is submitted to the server, but the change doesn't actually occur in the database until the website confirms it is valid (it does not create cycles). The servers check for cycles and if they exist the update is cancelled and the user is provided with an appropriate error message explaining the issue. The user's request to change the issues they vote for or camps they support should quickly succeed without failure on the other hand. In both cases, the requests need to be timestamped and signed using the user's website private key (this is important to allow later validation by anyone).
Every once in a while the server will take a snapshot of the existing databases storing the information about the current BTS balances devoted to each user and the current delegation structure between users. This would be a class 1 and 2 snapshot. At the same time, the server would also take a snapshot of the database storing the voting decisions of each user, which would be a class 3 snapshot. The server can then proceed to calculate the BTS voting power controlled by each user and then the accumulate BTS votes for each issue.
After the class 1 and 2 snapshot, the server can use this information from the snapshot to construct the adjacency matrix for the eigenvalue problem that solves for the BTS voting power controlled by each user. The server can then proceed to solve that eigenvalue problem. All of this is happening in parallel to the normal operation of the server including the updates being made to the BTS stake devoted to each user and the delegation of voting power between users (hence the need for the class 1 and 2 snapshots). Once the eigenvalue problem has been solved, the server then caches those results (class 4 snapshot), and uses them along with the class 3 snapshot to calculate the accumulated BTS votes on each issue (which it also then caches with the class 5 snapshot). The server can then repeat this process again with a new class 1 and 2 snapshot of the current state.
While the previous process is occurring, the server can also provide a less accurate but more recent update to the accumulated BTS votes on each issue. Say the class 1 and 2 snapshots occurred at time t1. A class 3 snapshot also occurred at time t1. These snapshots eventually lead to the class 4 snapshot for the data taken at time t1 and then quickly thereafter a class 5 snapshot for the data taken at time t1. Once that is done, the server can then take a new class 1, 2, and 3 snapshot at time t2 and repeat the process. However, while the server is computing this information (the eigenvalue problem can take some time) it can make use of the class 4 snapshot for the data taken at time t1 along with a more recent class 3 snapshot to get an estimate of what the class 5 snapshot will be. The server can first use the class 3 snapshot at time t2 and the class 4 snapshot for the data taken at time t1 to calculate an estimated class 5 snapshot for the data taken partly at time t1 and partly at time t2. Once that is done, the server can then repeat this process using a new class 3 snapshot taken at time t3. This will generate an estimated class 5 snapshot for the data taken partly at time t1 and partly at time t3. You can imagine this can repeat for a while (say until time t5) before the eigenvalue problem has been solved and a new class 4 snapshot for data taken at time t2 is available. The server would then calculate a class 5 snapshot for data taken at time t2, but then it would also calculate an estimated class 5 snapshot for data partly taken at time t2 and partly taken at time t6. The server would then also take a new class 1 and 2 snapshot at time t6 to repeat the eigenvalue problem.
I imagine the previous paragraph was pretty confusing and I should try to better clarify it later. But the point is that the server can do many things in parallel, and at any given time it has two types of the most recent voting results for each issue. One type is the very accurate but older one which are the accurate results as determined if someone were to take a snapshot of the blockchain at a certain time as well as a snapshot of the delegation and voting decisions of the website users at the same time, and then determine the consensus from that data. All the information for calculating this should be stored by the server so that it can be provided to users who can then use it to prove the validity of the consensus reached. The other type is an estimate of the consensus that will eventually be properly calculated in the next complete snapshot. While less accurate (since the voting power in control of each user may have changed but not yet reflected in their voting consensus) it is also more recent. I think the website should show the recent results of both types next to the issues/camps they refer to, along with the snapshot dates that the calculations were using.
True, the text and structures of the camps, and such, would be centrally controlled and run on a server, but anyone would be able to validate any of the votes for these camps with appropriate tools, any time. And that is the only thing that really needs to be on the block chain, at least to get started. And my understanding is that the "vote" stuff being developed already does what we need.
So with the system I described as long as the website stored and makes available on request the signed BTS balances devoting to particular users for all valid unspent BTS balances at the time of the snapshot, and the users' most recent (up to the limit of the snapshot date) signed requests for updates to their delegation and voting decisions, then all of that information along with the information accessible from the blockchain would be enough for users to independently verify the voting results on any issue (or the amount of support behind any camp). Obviously there would need to be some standard specification for all of this and an open source client that users can run to do all the necessary calculations using the provided data to derive the consensus results.
Also in my view the voting decisions by the users would follow the standard specification of voting with approval on a particular unique issue represented by a hash. Different websites could use this fundamental construct to represent different things. For example the hash respresenting the issue can be split into three hashes: a hash of the concatenation of the hash representing the issue and the string "upvote"; a hash of the concatenation of the hash representing the issue and the string "downvote"; and, a hash of the concatenation of the hash representing the issue and the string "neutral". That allows this fundamental construct of approving an issue to be extended to an upvote/downvote of an issue (the most recent approval is the one that counts so that it wouldn't be possible to have both an upvote and a downvote). An upvote/downvote on a hash that represents a proposal could be interpreted as yea/nay on the proposal to determine whether the proposal should be accepted by the community. An upvote/downvote on a hash of a post could be used to determine its score in a style similar to Reddit. An upvote of a hash of a camp (with all relevant text included as part of the hash to prevent people from changing the meaning of the camp by editing the text after people vote) could be interpreted as the user supporting (or joining) that camp, while a more recent neutral vote could represent removing support of a camp they previously supported (leaving a camp). The hash extension concept can be expanded to have hashes representing any of the options of a poll (including the option of not voting for anything) where these hashes all ultimately depend on the hash of the data representing the poll. All kinds of possibilities exist. At the most general level the hash could simply be a hash of a ballot which itself includes the hash of an election. These ballots can then contain whatever information necessary to come to a consensus on the results of the election. And this method allows anyone who has the desire (assuming they can get access to all of the most recent, up to the limit of some snapshot deadline of course, raw signed data necessary from the websites or peers) to verify the results of all of these consensus systems independently using open source running on their computers. With enough skeptical people taking the time to do this and sounding the alarms if something is clearly wrong, most users can instead just trust the convenient results the website provides for most things and only bother to verify it themselves if it is a particularly important or controversial consensus result.
A "One share, one vote" canonization algorithm would definitely be the priority, but it would be great to enhance that so we could do things like bias the vote so people with fewer shares could have more of a vote, bias vote towards expertise/reputation, and anything else anyone would propose and we could build a near unanimous consensus around.
That is the beauty of the vote delegation system and liquid democracy. Someone with zero BTS could still get considerable voting power if they can convince the BTS stakeholders to delegate their voting power to him because they trust him to make smart decisions on their behalf that will grow the value of their stake. This person could even be paid by tips by these people to further incentivize him to do a good job and even use that income to grow his stake in BTS which even better aligns his incentives (and this system would allow users to optionally prove the amount of stake they have in their control by the way). And of course the stakeholders could always change the delegation of their stake at any time so the trusted user would know that he would lose that voting power if he makes decisions that go against the interests of the people delegating their voting power to him.
But ultimately the voting power needs to be derived from some initial source. If we want the source to be objective rather than subjective (so that we can actually come to a consensus), it cannot be based on how much each user is trusted because that is entirely subjective. It has to either come from: 1 BTS = 1 vote; 1 person = 1 vote (with trusted third-parties verifying who a unique person is); or some authority declaring by fiat what the voting weight of each user is. The last option is problematic for many reasons but one fundamental issue with it is the issue of how we even determine that authority figure in the first place. The second option also requires some trust in verifying the uniqueness of a human being (although that can be worked around to some extent). The second option is good for democracy applications that the voting DAC can be used for, but it is a bad idea for deciding the direction of a DAC since the stake of the DAC, the value of which will be affected by these decisions, are not uniformly distributed to each human being. I would imagine the second strategy can play a very important role in government and democracy related functions as well as perhaps determining the cultural zeitgeist through ranking regular discussion using Reddit style upvotes/downvotes, but it shouldn't be used to determine the strategic business decisions of a DAC (such as determining dilution caps or which marketing effort to spend the diluted BTS on). For those types of DAC decisions, I would say the most fair and sensible thing to do is to use the 1 BTS = 1 vote model but also allow the delegation of voting power as I described in this post so that people who trust others to make better decisions on their behalf can do so.
Topic: BTS Governance step 1: Basic stake polling (Read 10091 times)
