DAO Extension #530

aguycalled · 2019-06-14T21:55:37Z

This PR includes a serie of Deployment Proposals as described in https://www.reddit.com/r/NavCoin/comments/bs4pvn/proposal_for_the_extension_of_the_community_fund/:

Adds support for abstaining in the votings. (Version Bit 19) - includes functional test
Enables voting state cache, reducing the amount of votes which need to be broadcasted down to 1 per address. (Version Bit 22) - does not include specific functional test, but old fund tests pass having this deployment activated
Enables DAO consultations. (Version Bit 23) - includes functional test
Enables modification of consensus parameters through DAO consultations. (Version Bit 25) - includes functional test
Enables voting delegation and voting from light wallets. (Version bit 27) - includes functional test
Allows fund proposals to have a different address for signing the payment requests and for receiving the payment. This allows to use arbitrary scripts as payment addresses, like multisig addresses. When the payment address differs from the owner address, the first will be specified using the p parameter on the JSON object embedded on the strDZeel property of the transaction.
Includes UI to manage the new DAO features.

Abstention votes

Abstention votes will be added to the yes and no votes from proposals and payment requests to calculate the minimum quorum.

Consultations can also have abstentions.

New op codes and voting

Op codes

Name
OP_ABSTAIN	0xc7
OP_REMOVE	0xc8
OP_DAO	0xc9
OP_ANSWER	0xca
OP_CONSULTATION	0xcb

Voting

The following assumes the deployment of the voting state cache has been accepted in the network.

Proposal and payment request voting

Script	Description
OP_RETURN OP_CFUND OP_PROP OP_YES HASH	Inserts a yes vote for the proposal HASH in the state cache
OP_RETURN OP_CFUND OP_PROP OP_NO HASH	Inserts a no vote for the proposal HASH in the state cache
OP_RETURN OP_CFUND OP_PROP OP_ABSTAIN HASH	Inserts an abstention vote for the proposal HASH in the state cache
OP_RETURN OP_CFUND OP_PROP OP_REMOVE HASH	Remove the vote stored for the proposal HASH in the state cache
OP_RETURN OP_CFUND OP_PREQ OP_YES HASH	Inserts a yes vote for the payment request HASH in the state cache
OP_RETURN OP_CFUND OP_PREQ OP_NO HASH	Inserts a no vote for the payment request HASH in the state cache
OP_RETURN OP_CFUND OP_PREQ OP_ABSTAIN HASH	Inserts an abstention vote for the payment request HASH in the state cache
OP_RETURN OP_CFUND OP_PREQ OP_REMOVE HASH	Remove the vote stored for the payment request HASH in the state cache

Consultation support and voting

Script	Description
OP_RETURN OP_DAO OP_YES HASH	Insert a support vote for the range consultation or answer HASH in the state cache
OP_RETURN OP_DAO OP_REMOVE HASH	Remove the support stored for the range consultation or answer HASH in the state cache
OP_RETURN OP_CONSULTATION OP_ANSWER HASH	Inserts a yes vote for the consultation answer HASH
OP_RETURN OP_CONSULTATION OP_ANSWER HASH VALUE	Inserts a vote with value VALUE for the range consultation HASH
OP_RETURN OP_CONSULTATION OP_ABSTAIN HASH	Inserts an abstention vote for the range consultation or answer HASH in the state cache
OP_RETURN OP_CONSULTATION OP_REMOVE HASH	Remove the vote stored for the range consultation or answer HASH in the store cache

Vote from light wallets

Wallets can now create a new type of Cold Staking address where the voting rights are delegated to a third address.

Syntax:
getcoldstakingaddress staking address spending address voting address

Coins sent to this new type of address will be sent to the following script:

<VOTING PUBKEY HASH> OP_DROP
OP_COINSTAKE OP_IF
    OP_DUP OP_HASH160 <STAKING PUBKEY HASH> OP_EQUALVERIFY OP_CHECKSIG
OP_ELSE
    OP_DUP OP_HASH160 <SPENDING PUBKEY HASH> OP_EQUALVERIFY OP_CHECKSIG
OP_ENDIF

The blocks where the coin stake transaction spends one output of this new class, will use the votes stored in the state for the voting key.

Light wallets will be able to modify the voting state by submitting to the network a transaction with the following requirements:

The version of the transaction is 8.
The first input spends a P2PKH output from the voting address.
It contributes to the fund a minimum amount of CONSENSUS_PARAMS_DAO_VOTE_LIGHT_MIN_FEE=0.1NAV
Some of its outputs has voting scripts as described in the previous sections.

Consultations

Consultations are permission-less open questions submitted to the network.

Once consultations are created they must gather a minimal support (defined by consensus parameter CONSENSUS_PARAM_CONSULTATION_MIN_SUPPORT=1.5% for range consultations and by CONSENSUS_PARAM_CONSULTATION_ANSWER_MIN_SUPPORT=1.5% for the rest of consultations) in a minimum of 2 answers if a normal consultation or 1 answer if the consultation is about a consensus parameter. Range consultations do not have this requirement. Instead, range consultations must receive support themselves.

In order to give enough time to a large number of stakers to add new answers to consultations, a consultation will never pass until the cycle defined by CONSENSUS_PARAM_CONSULTATION_MIN_CYCLES=2 is over. Consultations will be in a looking for support phase for a maximum of CONSENSUS_PARAM_CONSULTATION_MAX_SUPPORT_CYCLES=4 cycles, and the voting phase will last a fixed amount of CONSENSUS_PARAM_CONSULTATION_MAX_VOTING_CYCLES=4 cycles. An exception will be consultations about consensus parameters, which could end earlier whenever one of the answers have a minimum of 75% affirmative votes at the end of a voting cycle. Between the looking for support and voting phases, there will exist a reflection phase with a lenght of CONSENSUS_PARAM_CONSULTATION_REFLECTION_LENGTH=1 cycle.

Consultations are created through the creation of a transaction with version 6, pay at least a fee of CONSENSUS_PARAM_CONSULTATION_MIN_FEE=100NAV and a JSON object in the strDZeel parameter with the following structure:

{ "v": version bits of the consultation,
 "q": question of the consultation,
 "m": if the consultation version indicates this is a range consultation, sets the lower bound of the range,
 "n": if the consultation version indicates this is a range consultation, sets the higher bound of the range, otherwise, sets the maximum amount of answers a staker can vote in the same block for a consultation,
 "a": an array of strings containing candidates to answers
}

The version bits are:

Bit	Dec	Desc	Comment
0	1	Base
1	2	Answer is numeric and a range between `m` and `n`
2	4	Stakers can propose more answers	Allows `a` to be empty, otherwise it must have 2 elements
3	8	Consultation is about a consensus parameter	`m` is used to refer to the id of the consensus parameter, `n` must be 1 and `a` can be empty.

Consultations are identified by the hash of the transaction where it was created.

Stakers can submit during the looking for support phase proposals for different answers for every consultation which is set up as such through the creation of a transaction with version 7 and a JSON object in the strDZeel parameter with the following structure:

{
 "v": version bits of the answer, in this implementation only version 1 exists,
 "h": the hash of the parent consultation,
 "a": the proposed answer
}

Answers are identified by the hash of the concatenation of the transaction hash where it was created and the string of the answer.

answer.hash = Hash(tx.hash || strDZeel.a)

New RPC commands

createconsultation

Creates a DAO consultation

Syntax:
createconsultation Question max of simultaneous answers
createconsultation Question lower bound higher bound range bool
Create a normal consultation
createconsultation "Should we all dance together?" 1
Create a range consultation
createconsultation "What will be NavCoin price in USD at the end of the year?" 1 5 true

proposeanswer

Creates a proposal for a consultation answer.

Syntax:
proposeanswer hash answer
Propose an answer
proposeanswer d95ea23a22b723dbdf0d095d8e9998fab0576daf8cb9dd48c14f3bbd3df10f2f "Yes"

support

Signals support for a specific answer or consultation.

Syntax:
support hash bool
Support an answer
support d95ea23a22b723dbdf0d095d8e9998fab0576daf8cb9dd48c14f3bbd3df10f2f true
support d95ea23a22b723dbdf0d095d8e9998fab0576daf8cb9dd48c14f3bbd3df10f2f false

consultationvote

Sets the vote for a range consultation or answer.

Syntax:
consultationvote hash yes|value|abs|remove (value)
Vote yes for an answer
consultationvote d95ea23a22b723dbdf0d095d8e9998fab0576daf8cb9dd48c14f3bbd3df10f2f yes
Vote a value for a range consultation
consultationvote d95ea23a22b723dbdf0d095d8e9998fab0576daf8cb9dd48c14f3bbd3df10f2f value 10000
Vote abstain for a consultation
consultationvote d95ea23a22b723dbdf0d095d8e9998fab0576daf8cb9dd48c14f3bbd3df10f2f abs
Remove a vote
consultationvote d95ea23a22b723dbdf0d095d8e9998fab0576daf8cb9dd48c14f3bbd3df10f2f remove

consultationvotelist

Shows the list of votes for consultations

Syntax:
consultationvotelist

supportlist

Shows the list of support votes.

Syntax:
supportlist

getconsultation

Shows details of a consultation

Syntax:
getconsultation hash
getconsultation d95ea23a22b723dbdf0d095d8e9998fab0576daf8cb9dd48c14f3bbd3df10f2f

listconsultations

Shows the list of consultations. Possible filters: not_enough_answers, waiting_for_support, reflection, voting and finished

Syntax:
listconsultations filters
listconsultations waiting_for_support finished

getconsultationanswer

Shows details of a consultation

Syntax:
getconsultationanswer hash
getconsultationanswer d95ea23a22b723dbdf0d095d8e9998fab0576daf8cb9dd48c14f3bbd3df10f2f

getconsensusparameters

Shows a detailed list of the consensus parameters which can be defined by the DAO.

Syntax:
getconsensusparameters

proposeconsensuschange

Creates a proposal to change the value of one of the consensus parameters.

Syntax:
proposeconsensuschange parameter id value
proposeconsensuschange 10 10000

Consensus parameters

Id	Name	Desc	Type	Default value
0	CONSENSUS_PARAM_VOTING_CYCLE_LENGTH	Length in blocks of a voting cycle	NUMBER	20160
1	CONSENSUS_PARAM_CONSULTATION_MIN_SUPPORT	Minimum of support needed for starting a consultation	PERCENT	150
2	CONSENSUS_PARAM_CONSULTATION_MIN_CYCLES	Earliest cycle when a consultation can get in confirmation phase	NUMBER	2
3	CONSENSUS_PARAM_CONSULTATION_MAX_VOTING_CYCLES	Length in cycles for consultation votings	NUMBER	4
4	CONSENSUS_PARAM_CONSULTATION_MAX_SUPPORT_CYCLES	Maximum of voting cycles for a consultation to gain support	NUMBER	4
5	CONSENSUS_PARAM_CONSULTATION_REFLECTION_LENGTH	Length in cycles for the reflection phase of consultations	NUMBER	1
6	CONSENSUS_PARAM_CONSULTATION_MIN_FEE	Minimum fee to submit a consultation	NAV	1000000000
7	CONSENSUS_PARAM_CONSULTATION_ANSWER_MIN_SUPPORT	Minimum of support needed for a consultation answer proposal	PERCENT	150
8	CONSENSUS_PARAM_CONSULTATION_ANSWER_MIN_FEE	Minimum fee to submit a consultation answer proposal	NAV	5000000000
9	CONSENSUS_PARAM_PROPOSAL_MIN_QUORUM	Minimum of quorum for fund proposal votings	PERCENT	5000
10	CONSENSUS_PARAM_PROPOSAL_MIN_ACCEPT	Minimum of positive votes for a fund proposal to be accepted	PERCENT	7000
11	CONSENSUS_PARAM_PROPOSAL_MIN_REJECT	Minimum of negative votes for a fund proposal to be rejected	PERCENT	7000
12	CONSENSUS_PARAM_PROPOSAL_MIN_FEE	Minimum fee to submit a fund proposal	NAV	5000000000
13	CONSENSUS_PARAM_PROPOSAL_MAX_VOTING_CYCLES	Maximum of voting cycles for fund proposal votings	NUMBER	6
14	CONSENSUS_PARAM_PAYMENT_REQUEST_MIN_QUORUM	Minimum of quorum for payment request votings	PERCENT	5000
15	CONSENSUS_PARAM_PAYMENT_REQUEST_MIN_ACCEPT	Minimum of positive votes for a payment request to be accepted	PERCENT	7000
16	CONSENSUS_PARAM_PAYMENT_REQUEST_MIN_REJECT	Minimum of negative votes for a payment request to be rejected	PERCENT	7000
17	CONSENSUS_PARAM_PAYMENT_REQUEST_MIN_FEE	Minimum fee to submit a payment request	NAV	0
18	CONSENSUS_PARAM_PAYMENT_REQUEST_MAX_VOTING_CYCLES	Maximum of voting cycles for fund proposal votings	NUMBER	8
19	CONSENSUS_PARAM_FUND_SPREAD_ACCUMULATION	Frequency of the fund accumulation transaction	NUMBER	500
20	CONSENSUS_PARAM_FUND_PERCENT_PER_BLOCK	Percentage of generated NAV going to the Fund	PERCENT	2000
21	CONSENSUS_PARAM_GENERATION_PER_BLOCK	Amount of NAV generated per block	NAV	250000000
22	CONSENSUS_PARAM_NAVNS_FEE	Yearly fee for registering a name in NavNS	NAV	10000000000
23	CONSENSUS_PARAMS_DAO_VOTE_LIGHT_MIN_FEE	Minimum fee as a fund contribution to submit a DAO vote using a light wallet	NAV	10000000

Type of parameters

NUMBER. This is a normal numeric parameter.
PERCENT. This is percentage and is expressed in cents. 0,5% is written 50. 90% is written 9000.
NAV. This is a NAV amount and is expressed in Navoshis. 1 NAV has 100000000 Navoshis.
BOOL. This is a boolean and can only be 0 or 1.

mxaddict · 2019-07-23T20:16:38Z

@aguycalled I tried a gitian and cross compile build of this branch and I ran into a similar issue that I did with my #557 branch.

I've since solved the issue (Making modifications to how the qt.mk is built)

You might wanna take a look at how I did it to get this branch to build in gitian and in travis-ci.

mxaddict · 2019-07-23T20:17:47Z

More specifically I think the changes are in this commit: 194ef50

mxaddict · 2019-07-24T11:05:54Z

Same error as the one in travis-ci OSX build

mxaddict · 2019-07-24T22:25:52Z

@aguycalled I've pushed a commit to this branch which fixes the gitian and cross compile build for qt

mxaddict · 2019-07-25T01:13:36Z

Fixed a failing test

mxaddict · 2019-07-25T02:53:11Z

@aguycalled Am getting this error on boot of a node with existing datadir

EDIT: Also tried with a bootstrap, and got same error

mxaddict · 2019-07-26T01:39:33Z

@aguycalled Am getting this error on boot of a node with existing datadir

EDIT: Also tried with a bootstrap, and got same error

This seems to be resolved in the latest test I did with the PR

src/chainparams.cpp

chasingkirkjufell · 2019-10-02T14:41:52Z

This is the first round of report.

Is there a max amount of answer? Tried up to 22 and still going. The display of the answered should probably be ordered.
Not that important but if one propose a question, maybe just default support it? Same as when creating a consultation with answer options.
Current test field does not support typing of other languages I think(tested Chinese), but copy and pasting works.
the RPC command "createconsultation "question" "max of simultaneous answers" does not describe how to also put the answers when creating a consultation.
After a consultation finishes, the view result initially displayed the results view, but then after 1 or more block cycles, results cannot be viewed.
Waiting for support for range consultation does not show any support votes. I understand there is no answer to vote on but might still be helpful to show support count
When changing consensus parameter, waiting for support phase will mess up the look. Wrapping test should fix this easily.
Maybe consider adding a counter for current block cycle? like 182/20000
Same block and blockhash so didn't fork but displayed different count. The node displaying 2/2 votes doesn't seem to get the votes from the other node.

They seem to be in different block cycle, one is one block cycle behind than the other. The lagging node is the node that created the consultation, this consultation had two options but three choices.
Still working on trying to replicate it to nail down what happened.

And below is from the nodes that are in the same network but didn't vote at all. Notice voting cycle is different on one of them.

aguycalled · 2019-10-02T18:21:48Z

there's no max. amount of answers. i'll commit a patch to adjust the fee based on the number of answers.
good idea. the wallet should at least suggest it.
do you mean some specific text field?
i'll create a new rpc command createconsultationwithanswers
will review
will review
will add wrapping
yup
will have a look

nice review!

chasingkirkjufell · 2019-10-02T18:28:33Z

just realized it's because i was forwarding the window into a different machine and used a language not installed by the original machine so please ignore this point.

chasingkirkjufell · 2019-10-04T17:49:12Z

fired up 6 nodes connected to each other. clean start. only using one node to stake and to create consultation.

the one node staking:
First generated 900 blocks to activate all the forks.
Waited for 120 blocks to ensure consensus parameters didn't change automatically
Created a consultation called"2nd test 10/4" with two answers "1st answer" "2nd answer" not allowing other to suggest answers and only allowing 1 vote.
checked in every now and then to ensure network parameter staying the same and they did
right after consultation finished voting this happened.

no proposal was submitted but it changed on itself

aguycalled · 2019-10-04T18:39:47Z

did you vote for the consultation?

chasingkirkjufell · 2019-10-04T18:44:23Z

after creating the consultation, voters vote for the answers and once answers found support, the consultation will enter another around of waiting for support. Is it the intended behavior? if so, what support is it waiting for since answers already were supported?

{
"version": 1,
"hash": "be9b78de7beb1153fbdd6f1df9b7f2dc6c6e22e8c7757525a0f64388efdcbd5b",
"blockhash": "d0a653f4de20af43b8239f276fa665c2b2761a2755c93be2dc31aed5abd5666c",
"question": "2nd test 10/4",
"support": 0,
"answers": [
{
"version": 1,
"string": "2nd answer",
"support": 20,
"votes": 0,
"status": "found support, waiting for end of voting period",
"state": 0,
"parent": "be9b78de7beb1153fbdd6f1df9b7f2dc6c6e22e8c7757525a0f64388efdcbd5b",
"hash": "8a702d9fae8c398e4180827edfafcce779b470f2f2d4bf34ff2d2cebf3bf16e8"
},
{
"version": 1,
"string": "1st answer",
"support": 20,
"votes": 0,
"status": "found support, waiting for end of voting period",
"state": 0,
"parent": "be9b78de7beb1153fbdd6f1df9b7f2dc6c6e22e8c7757525a0f64388efdcbd5b",
"hash": "66b8a954166c6bf7c801318d0541bbf34797270e072662f1a78736210a5df948"
}
],
"min": 0,
"max": 1,
"votingCycle": 0,
"status": "waiting for support",
"state": 0,
"stateChangedOnBlock": "0000000000000000000000000000000000000000000000000000000000000000"
}
Fri Oct 4 18:40:23 UTC 2019
{
"version": 1,
"hash": "be9b78de7beb1153fbdd6f1df9b7f2dc6c6e22e8c7757525a0f64388efdcbd5b",
"blockhash": "d0a653f4de20af43b8239f276fa665c2b2761a2755c93be2dc31aed5abd5666c",
"question": "2nd test 10/4",
"support": 0,
"answers": [
{
"version": 1,
"string": "2nd answer",
"support": 1,
"votes": 0,
"status": "found support",
"state": 1,
"parent": "be9b78de7beb1153fbdd6f1df9b7f2dc6c6e22e8c7757525a0f64388efdcbd5b",
"hash": "8a702d9fae8c398e4180827edfafcce779b470f2f2d4bf34ff2d2cebf3bf16e8"
},
{
"version": 1,
"string": "1st answer",
"support": 1,
"votes": 0,
"status": "found support",
"state": 1,
"parent": "be9b78de7beb1153fbdd6f1df9b7f2dc6c6e22e8c7757525a0f64388efdcbd5b",
"hash": "66b8a954166c6bf7c801318d0541bbf34797270e072662f1a78736210a5df948"
}
],
"min": 0,
"max": 1,
"votingCycle": 1,
"status": "waiting for support",
"state": 0,
"stateChangedOnBlock": "0000000000000000000000000000000000000000000000000000000000000000"
}
Fri Oct 4 18:41:23 UTC 2019

chasingkirkjufell · 2019-10-04T18:44:47Z

did you vote for the consultation?

i did

aguycalled · 2019-10-04T18:48:15Z

In order to give enough time to a large number of stakers to add new answers to consultations, a consultation will never pass to reflection phase until the cycle defined by CONSENSUS_PARAM_CONSULTATION_MIN_CYCLES=2 is over.

aguycalled · 2019-10-04T20:23:53Z

Paid 11,500NAV from dev bounty to NL9jPW75P4kNMdvQmFBpYVkZ3sABQtXfYY
minor ux (300) + minor ux (300) + minor ux (300) + minor ux (300) + minor ux (300) + consensus (5000) + consensus (5000)
5993262f1201206a1649a58f4a019849760ee62577840997683f433eb8846ec4

chasingkirkjufell · 2019-10-04T20:23:54Z

(suggestion) might be helpful to let the user know how many characters are allowed in proposals and answers during the creation window. Would be even better if it's a countdown. Like somewhere in that area.

chasingkirkjufell · 2019-10-07T14:14:39Z

fail to compile locally
coins.cpp: In member function ‘boost::unordered::unordered_map<uint256, CPaymentRequest, SaltedTxidHasher>::const_iterator CStateViewCache::FetchPaymentRequest(const uint256&) const’: coins.cpp:157:34: error: could not convert ‘((const CStateViewCache*)this)->CStateViewCache::cacheProposals.std::map<uint256, CProposal>::end()’ from ‘std::map<uint256, CProposal>::iterator’ {aka ‘std::_Rb_tree_iterator<std::pair<const uint256, CProposal> >’} to ‘boost::unordered::unordered_map<uint256, CPaymentRequest, SaltedTxidHasher>::const_iterator’ {aka ‘boost::unordered::iterator_detail::c_iterator<boost::unordered::detail::ptr_node<std::pair<const uint256, CPaymentRequest> > >’} return cacheProposals.end(); ~~~~~~~~~~~~~~~~~~^~ CXX libnavcoin_common_a-keystore.o make[2]: *** [Makefile:6132: libnavcoin_common_a-coins.o] Error 1 make[2]: *** Waiting for unfinished jobs.... make[2]: Leaving directory '/home/-/navcoin-core/src' make[1]: *** [Makefile:10465: all-recursive] Error 1 make[1]: Leaving directory '/home/-/navcoin-core/src' make: *** [Makefile:706: all-recursive] Error 1

chasingkirkjufell · 2019-10-07T21:26:28Z

(suggestion) I think a better way of showing support is maybe dividing the current support or vote count by the current block cycle height. Say if there are 3 answers and they got 10 5 2 supports repectively on 20th blocks in a 30 blocks block cycle, the support pie will show 50% support 10% support and 4% support for answers 1, 2, and 3. Same for the range consultation since now it showed the whole block cycle block count as the denominator.
(just an observation of inconsistency, either is fine)Right click on consultation in qt wallet and click view votes, only range consultation updates voting whenever "view votes" is click, option based consultation will only update after clicking other tabs like "fund proposals" and then click back to "consultations"
getconsultation returns different sorting sometimes
I think support counting should be stopped and stored at the end of support phase? Right now support is still being reset on voting phase sometimes (I think it's reset if the answer is voted on, meaning it counts both support and votes all over again. If the answer is not voted on, support count stays the same as when it passed support phase)
Unchecking the boxes does not remove voting power, it actually results in voting on both answers not only for multiple answer questions, but also breaking the rule and voting on both when only 1 answer is allowed.
Why would it be 0? Wouldn't it be either 30/30 or 1/30 for block cycle of 30 blocks?
Also, the cycle progress percentage does not update the denominator if the consensus parameter is changed.
(suggestion) Maybe not so many decimals?
"Range consultation" vote count still accumulating after it's finished. It's not reset for each cycle just keeps adding up(the only staking and voting node).
"Option consultation" resets voting count and voted again after it's finished in qt wallet (the only staking and voting node).
(working on replicating it) nodes are seeing different vote counts after "range consultation" is finished.

chasingkirkjufell · 2019-10-08T02:27:02Z

for point 13, i 'd like to change to suggest to display % still but it'll stop increasing once it reaches the requirement % to be supported (1.5%) to prevent influencing voters decisions from having differnet amount of supports. Just an idea though.

by the way voting list still not sorted

chasingkirkjufell · 2019-10-08T03:24:48Z

14 is not existent on a linux virtual machine. did you fix it with last commit d96d886....?

navbuilder · 2020-04-16T12:36:06Z

A new build of dcf494b has completed succesfully!
Binaries available at https://build.nav.community/binaries/dao_extension

navbuilder · 2020-04-16T17:16:35Z

A new build of 2c72313 has completed succesfully!
Binaries available at https://build.nav.community/binaries/dao_extension

navbuilder · 2020-04-16T18:54:14Z

A new build of 89d3f56 has completed succesfully!
Binaries available at https://build.nav.community/binaries/dao_extension

navbuilder · 2020-04-28T21:44:11Z

A new build of 73a5003 has completed succesfully!
Binaries available at https://build.nav.community/binaries/dao_extension

navbuilder · 2020-05-08T19:57:11Z

A new build of 482939a has completed succesfully!
Binaries available at https://build.nav.community/binaries/dao_extension

navbuilder · 2020-05-08T21:29:24Z

A new build of 35ce8c7 has completed succesfully!
Binaries available at https://build.nav.community/binaries/dao_extension

navbuilder · 2020-05-11T12:34:08Z

A new build of 0332bc5 has completed succesfully!
Binaries available at https://build.nav.community/binaries/dao_extension

navbuilder · 2020-05-13T13:40:49Z

A new build of 72cf43e has completed succesfully!
Binaries available at https://build.nav.community/binaries/dao_extension

navbuilder · 2020-05-13T15:15:35Z

A new build of 8ae0039 has completed succesfully!
Binaries available at https://build.nav.community/binaries/dao_extension

aguycalled added the work in progress label Jun 14, 2019

aguycalled mentioned this pull request Jul 11, 2019

Create a GUI for Deployment Voting #529

Closed

mxaddict mentioned this pull request Jul 15, 2019

Spelling/graphic error of GUI on cfund page #478

Closed

aguycalled added ready for review and removed work in progress labels Jul 21, 2019

aguycalled requested review from marcus290, mxaddict and proletesseract July 21, 2019 22:50

jottum reviewed Sep 14, 2019

View reviewed changes

src/chainparams.cpp Show resolved Hide resolved

move extended dao log to category daoextra

dcf494b

alex v added 2 commits April 16, 2020 17:43

take title out of qchart into qlabel

2c72313

checks conditional to deployment being active

89d3f56

alex v added 2 commits April 28, 2020 22:08

move check to ContextualCheckBlock

46d97ca

use pindexprev instead of chainactive

73a5003

alex v added 2 commits May 8, 2020 20:24

reset testnet

482939a

message start

35ce8c7

alex v added 2 commits May 10, 2020 00:12

admit csv2 address as change

0216e76

fix typo

0332bc5

alex v added 3 commits May 13, 2020 14:10

voting cycle fixes and extra info in jsonifier

72cf43e

fixes max cycles

3051b91

fixes current cycles for state

8ae0039

alex v added 8 commits May 14, 2020 00:26

fix max cycles for accepted state

119a16b

reverse mapState k/v

a8a286f

fix expired for consensus consultation

5e9a0b2

fix tests

0d51895

fix qa/rpc-tests/dao-consultation-consensus-cycle-length.py

488f8d4

tests

ae59d48

bump version to 5.0.0

5ba9efc

Update 5.0.0 release notes

fa23a74

aguycalled merged commit 7fd0713 into navcoin:master May 18, 2020

DAO Extension #530

DAO Extension #530

Uh oh!

Conversation

aguycalled commented Jun 14, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Abstention votes

New op codes and voting

Op codes

Voting

Proposal and payment request voting

Consultation support and voting

Vote from light wallets

Consultations

New RPC commands

createconsultation

proposeanswer

support

consultationvote

consultationvotelist

supportlist

getconsultation

listconsultations

getconsultationanswer

getconsensusparameters

proposeconsensuschange

Consensus parameters

Type of parameters

Uh oh!

mxaddict commented Jul 23, 2019

Uh oh!

mxaddict commented Jul 23, 2019

Uh oh!

mxaddict commented Jul 24, 2019

Uh oh!

mxaddict commented Jul 24, 2019

Uh oh!

mxaddict commented Jul 25, 2019

Uh oh!

mxaddict commented Jul 25, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mxaddict commented Jul 26, 2019

Uh oh!

Uh oh!

chasingkirkjufell commented Oct 2, 2019

Uh oh!

aguycalled commented Oct 2, 2019

Uh oh!

chasingkirkjufell commented Oct 2, 2019

Uh oh!

chasingkirkjufell commented Oct 4, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

aguycalled commented Oct 4, 2019

Uh oh!

chasingkirkjufell commented Oct 4, 2019

Uh oh!

chasingkirkjufell commented Oct 4, 2019

Uh oh!

aguycalled commented Oct 4, 2019

Uh oh!

aguycalled commented Oct 4, 2019

Uh oh!

chasingkirkjufell commented Oct 4, 2019

Uh oh!

chasingkirkjufell commented Oct 7, 2019

Uh oh!

chasingkirkjufell commented Oct 7, 2019

Uh oh!

chasingkirkjufell commented Oct 8, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

chasingkirkjufell commented Oct 8, 2019

Uh oh!

navbuilder commented Apr 16, 2020

Uh oh!

navbuilder commented Apr 16, 2020

Uh oh!

navbuilder commented Apr 16, 2020

aguycalled commented Jun 14, 2019 •

edited

Loading

mxaddict commented Jul 25, 2019 •

edited

Loading

chasingkirkjufell commented Oct 4, 2019 •

edited

Loading

chasingkirkjufell commented Oct 8, 2019 •

edited

Loading