Announcing the first Coin Holder's Straw Poll!

I don’t think this is sybil-resistant, but pretty much all of the name options are fine, so I’m not too worried about.

That is the issue - how can you tell those 1.5k people are 1.5k people with 1 ZEC or 1 coin holder who has split their 1500 ZEC over all those addresses? The financial cost of performing these transactions are somewhat trivial (even assuming the default fee 1500 transactions would be a little over $10 in fees). For someone motivated enough if the incentive is high enough this would certainly happen.

I do think an indicative vote based on stake is informative assuming it is non-binding (for something more meaningful than that proposed).


I agree, but 1.5k people are not going to vote because of that one large “vote” this is not a straw poll by any interpretation.

I was going to vote 12 times, from 12 addresses but the total sum is 0.0002311 something on each account (like 0.01cents) there is no point me going through the motions to vote now.

Also as shawn pointed out, if he wants to vote he is going to have to deshield a large portion if not all of his coins to even get a vague hope of his vote meaning something. If this is considered acceptable on something as trivial as name selection, why does it feel like a dry run for something else.

And to be fair, zooko hasn’t directly stated more zec = more weight. so it is just an assumption.


You see the obvious contradiction here? As such that 1500 ZEC holder feels that their single vote (assuming they hold it in one address) isn’t worthwhile. This is why centralised voter registration systems exist and the community governance panel, which not perfect, is also a very valuable indicative input for future decisions such as these.

Think we can only define this as -
‘1500 ZEC voted for…’ or ‘X% of total coins voted for…’

Can’t safely connect it to an individual, which is kinda the point of fungability.


Yes, that was my point.

It sounds like you didn’t read the part of my Original Post about how coin-holders aren’t the only important voices, but how they are important and valuable members of the community.


Yes, you are right. I apologise for derailing the thread and making what was obviously a “wow look at this” statement a bit too seriously and ran with it. initially it was a joke, then I dragged others into derailing this thread.

out of interest though if another option were to get 12 votes that total 0.001 zec would you then recommend that instead of bloom? - this is a light hearted question, feel free to antagonise me with the response :slight_smile:

just so you know where im coming from, the word “bloom” is like nails on a chalkboard for me.

Im not good at this governance stuff. I will stop picking holes in things I don’t understand. I hope you appreciate that I do put a lot of effort into other parts of the forum though. (this isn’t an excuse, im about to start pleading)

Please anything but bloom. plant wise, we have produced our first sap wood, had our first blossom, now we need to put on heartwood (I think this fits with the companies goals for the next upgrades too, the partiy+foundation and 2of2 is massive and is exactly what a tree builds on heartwood.) No idea why I am still typing. I will think before posting in these sorts of threads next time.

1 Like

Yes. Also true of me: Announcing the first Coin Holder's Straw Poll!

Str4d has an idea for how to implement shielded coin-holder’s polling: Announcing the first Coin Holder's Straw Poll!

1 Like

Here’s a more concrete sketch of my idea.

A poll response is a reduced form of a transaction:

  • A poll ID (something unique to the poll, so that prior poll responses can’t be replayed against newer polls).
  • The public poll response (message etc.)
  • An anchor for the height at which the poll is being conducted.
  • A SpendDescription (including nullifier) per note being used for polling.
    • Dummy notes could potentially be used, but I don’t think they should be encouraged, because they are unlikely to contribute any privacy (the nullifiers for the real notes will eventually be revealed, whereas the nullifiers for the dummy notes would likely never be seen on-chain).
  • An Output proof, plus necessary public commitments, to whatever change is not being used in the poll (respondents may wish to use some round amount, or an amount lower than their real input balance).
  • A valueBalance field showing the total funds being used for the poll.
  • bindingSig (binding valueBalance to the spends and outputs).

Signatures would be over the above format instead of using the SignatureHash algorithm. The signatures themselves might be moved around to make this easier.

(A private version of this could be created where there is a near-standard OutputDescription containing the poll response encrypted to the poll operator’s Sapling address. In this case valueBalance would be zero and could be omitted, but bindingSig would need to remain.)

This poll response has the following properties:

  • Smaller than the equivalent fully-shielded transaction, and can be explicitly specified as non-malleable.
  • Poll response can be an arbitrary message (either publicly or privately).
  • Poll response can be associated with an arbitrary amount of Zcash (up to the total amount controlled by the respondent). This includes zero (in both public and private schemes), enabling polls of coin-holders by number of notes rather than value, which is maybe useful?
  • The poll respondent’s Sapling address (that controls or controlled the funds) does not need to be single-use, because it is never revealed.
  • It is possible to verify both that the polling funds existed at the polling height (by the anchor), and that the funds were unspent as of that height (by checking that the revealed nullifiers did not exist in the nullifier set at the polling height).
  • Double-spending in poll responses is prevented by the nullifiers.
    • This has the explicit downside of linking the poll response to the on-chain transactions. If a single poll response uses several notes, and those notes were spent separately on-chain, this would link the on-chain transactions. I think this is unavoidable for any retroactive scheme (e.g. if one poll response were created per note, the linkability then just moves up one layer, to figuring out whether the same person submitted several poll responses).
    • If the poll height is picked in advance, users can prevent this issue by merging their polling funds into a single note before the poll height, and then unmerging them after the poll height. This ensures that the on-chain transaction linked to the poll is only the unmerging (or first subsequent usage) transaction.

I just remembered that exists, and it looks like the discussion there arrived at similar (conceptually, not technically) design as above for off-chain polling. I’ll continue there.

1 Like

Sent to me via email:

please post it
t1XchoPy9gEuV8ZPmMpN99KcRrwSiDSxR2w “NU3 should be named Heartwood”

1 Like

And now we have 5000 for heartwood! - I reread your message zooko. Again im sorry I completely misread what you wrote about your advice to Nathan, not only that, I then ran with my own completely wrong narrative for a few posts. I do feel suitably stupid if that helps.

Who ever is that address. you are my new favourite person!!

Welp, this is already exciting/bizzarre. The vote was supposed to conclude on Aug 2. That 5000 address apparently first showed up exactly on Aug 2 and still holds that balance
There’s no timestamp associated with the signature itself though, just Sonya’s post on Aug 5. So should this even count, or not?
Edit- And if so, new votes could still show up today, signed by addresses with a balance as of some snapshot on Aug 2. Then what?


I think this clearly demonstrates their commitment to zcash, and heartwood. They have left the balance there for this long to prove this point. :slight_smile:

They could be new, and wanted to deshield just to vote for heartwood and not got round to the complexity involved in signing a message and finding the appropriate person to send it to so they could keep their anonymity.

Most of this post is in jest. but yeah it certainly got interesting. the day I get back off holiday too. heh. thankyou t1Xcho you are a legend. :smiley: I hope you read this.

I don’t know. let people vote up until 12hrs before the name is decided?


Paging @nathan-at-least to respond to the above and… I dunno… sort this out somehow :joy:


Concur that it should be Nathan’s job to figure out how to clarify and finish and complete this experiment that I initiated.


Doh! I started to post to this thread a couple week ago to clarify those edge conditions and never hit send. Here’s the draft:

Yes, I’m fine to do that as an experiment. Let’s try to nail down a lot of ambiguity here and also document some known trade-offs or outstanding problems:

Q. When does the poll end?

A. A straw poll vote will be tallied if it meets these strict conditions:

  • The latest release of zcashd gives a success indication for: zcash-cli verifymessage $TADDR $SIGBLOB $MESSAGE
  • The $MESSAGE unambiguously advocates for a single name for NU3. If you are creating a message and want to ensure there’s no ambiguity use "NU3 should be named <your name here>" like in an earlier post.
  • A post with the full verifymessage command is posted before 2019-08-02 23:59:00 UTC. (This is August 2, even though Zooko said July 2.)
  • others can recreate the verifymessage result successfully.

That’s as far as I got. I might not have any time to look into this until about two weeks from now (unless I can get to it on weekends/nights).

Edit: If there were votes posted above that missed the deadline I wrote in my draft, I think we’ll have to fudge it, since it’s not at all fair to have unannounced deadlines.