Liquid Democracy on Blockchain and In Parliament

General Technical
1

Hi All,

Unsure if this sort of post is welcome here but I thought I’d give it a try considering there’s a good appreciation for Liquid Democracy (LD) in pirate parties.

I’m building a new political party called the Neutral Voting Bloc (NVB) and I’d like input and comments if you have any. (Also just to let you know about it, because the Pirate Party will need to decide whether it wants to preference the NVB anyway in the 2016 senate elections)

This party is designed to cannibalize senate seats and basically give people a way to directly interact with the senate through LD-esq voting, and I think it has the game theory to get it there.

A brief introduction: The NVB starts as a party, the elected candidates of which vote in parliament based on the outcome of ballots held online, with votes given to members, non-member voters, and other parties in a weighted fashion. The NVB has no policies of its own. The basic idea is to (ab)use GVTs to get candidates elected. This is done by exchanging preferences for internal votes. The elected senators then vote in such a way to match the proportional yes-no votes from party participants (not all of whom need to be members). I’m planning it to be as free and open as possible so all citizens can become non-member voters.

While direct democracy is an option I think we all appreciate that it’s way too cumbersome and something like LD is a much better option. I’ve implemented (ongoing, but the minimum viable product is done) a voting-client and voting-tallier pair that use a blockchain as the host for votes. A blockchain is the only type of uncensorable database capable of providing the properties I’m looking for, which is the main reason LiquidFeedback is inappropriate. There’s a demo over at vote-explorer.xk.io if you want a quick look.

Now, the (ab)using GVTs part. I call this the Senate Preference Hack, and it mainly works because we force parties to compare all other parties to submit their GVT. By comparing everyone an economic decision is made and so offering an economic incentive can boost preference numbers, theoretically. I’ve gone into more detail here. I’ve also done some simulations and confirmed intuitive predictions, like the more parties the better the hack works, and the less happy people are with major parties the better the hack works. Furthermore, part of making the offer competitive is creating an efficient and fair environment to vote in, so it naturally favours neutral, low participation, high yield systems (like LD).

To give you an idea of how well this can work, my simulation yields the following based on 2013 election data for NSW Senate elections:

With 1% of the primary vote, and a 50% participation from other parties (which means they preference the NVB first) and half participation by default for other parties (which means they preference the NVB randomly), the NVB would have an 85% chance of winning a senate seat if it ran in the 2013 NSW Senate Elections.

There’s more information over at the wiki: http://nvb.wiki (if you want to read more).

Any comments or thoughts are appreciated.

Cheers,
Max

2 Likes
2

I was only able to include two links, so here are more:

Oh, and I’m also interested more generally if anyone would like to share about starting a party and the challenges the PPAU ran into.

3

I believe there’d certainly be room for collaboration toward this goal; we’ve actually had a fair bit of talk regarding LD, and at one point were planning our own implementation (I don’t believe there’s any substantial amount of code as of yet). Regarding blockchain LD, we had some brainstorming around that also, but similarly no progress on an actual implementation.

Since that previous discussion, I’ve since come to the conclusion that we’d likely be better served working something out atop the the existing Bitcoin blockchain rather than establishing an entirely new blockchain & cryptocurrency, most likely built atop data embedded in OP_RETURN transactions as you’ve also proposed, or if necessary at a higher layer (Ethereum contracts can now be executed on Bitcoin’s blockchain, via the Counterparty protocol).

My only reservation is in regards to your proposed “Senate Preference Hack”, in that it may be difficult (but hopefully not impossible?) to reconcile with PPAU’s democratic & transparent approach to preferencing.

Would love to see what other’s have to say on this topic, could be a rather interesting discussion. Apologies for the terse post, exhausted and a tad under the weather right now.

4

Thanks for your reply, Jack.

You’re more than welcome to use the NVB implementation if you like. I’d be quite happy to work with the PPAU to whitelabel it if you want to go in that direction. However, it’s very much just a voting system and offers nothing in terms of writing or collaborating on legislation.

There are two sides to this I see:

  • NVB – Preferencing will probably be a random sort based on unpredictable entropy (block_hash[n] XOR block_hash[n+1][::-1]) and will probably be run for multiple tickets to create a bit of balance.
  • PPAU – It’s my hope that with enough debate the PPAU will find it appropriate to preference the NVB first or at least somewhere up there. This would allow for a small say in the senate and “pooling” of votes across state boundaries. Ideally this helps the PPAU grow because they can be seen to be doing something and active. Of course, the PPAU (like everyone) is free to ignore the NVB and preference it last in the GVT.

If the PPAU did preference the NVB first, and the NVB won a seat in every state, the PPAU would control roughly 0.1588 seats in the senate. (Using 2013 election data) (In reality it is not this clean, depending on preferences it could be more or less). While that’s not a lot, if a vote comes down to the last one or two seats these numbers become significant, which is one of the reasons minor parties are so important. (Side note, a great paper on the importance of small parties / independents is Accidental Politicians which explores election via lottery).

Other parties will receive essentially the same info as above, though probably geared more towards the economic choice: “preference the NVB and get internal voting rights proportional to the level of commitment”. Other parties can deal with that choice in whatever way they deem fit, but I am going to be sure to send as many letters as possible to get debate going everywhere it possibly can.

In my mind good policy will be produced in any open, reactive forum that values a culture of conjecture. If you can’t already tell I’m pretty in to fallibilism.

I’ve also come to that conclusion. I was actually on the original dev team for ethereum (I’m near the bottom listed as “developer”). I’ve since left. Counterparty (as well as Ethereum) just add another layer of dependence in my mind, and restrict one to using inferior languages with bad support. No doubt one day they may grow to be suitable, but I’d feel far more comfortable using OP_RETURNs on the main Bitcoin blockchain: the security is good, requirements are low, invalid instructions are easily discarded, and I can use real python (instead of serpent).

With the NVB I’m trying hard not to let the perfect be the enemy of the good. There are a lot of great ideas out there that are one or two stages too far for a bare-bones entry level system that just does the job. There’s plenty of room for expansion later, and the added conjecture from NVB participants will help produce a better product in the long term.

5

Have you guys seen this: https://github.com/chozabu/trunktesting/tree/meshdemoc

It essentially is attempting the same thing, however doesn’t require the overhead and processing power that blockchain solutions and PoW verification requires.

Not finished yet because Retroshare is still working on releasing their 0.6 client, but it’s got promise.

6

I haven’t yet had a chance to take a look at your implementation (I assume this is your nvbclient repo on Github?). It’s not really my decision however to decide whether or not we adopt it. In all honesty, most LD discussion within the party has simply been brainstorming - I don’t believe there are any firm implementation plans as of yet.

Certainly worthy of further discussion. If NVB is up and running by the next election, I may well direct my preference vote highly toward it.

Ideally, yes, but aren’t we assuming that every other party will act rationally and preference NVB highly. I’d suspect many would not, either due to lack of understanding in the concept, or a perception that they’re sacrificing their political sovereignty

Agreed, and this is a significant reason for my own participation in PPAU. Every policy is discussed extensively (primarily on IRC, as most of our policies predate this forum), developed iteratively and with absolute transparency (Minutes for every PDC meeting are on the wiki)

.

Fewer layers is certainly preferable, in so far as simplifying the implementation. However, by simply using the blockchain as a backing store, aren’t we re-introducing the need for trust, in the form of the client software that parses said OP_RETURNs? While people could run their own copies to validate the published results, wouldn’t Ethereum (whether that may be Ethereum itself, or the Counterparty implementation) guarantee that the actual computation was performed to spec, eliminating the potential for subversion?

Please do correct me if I’m wrong (I’ve been a bit out of the loop on crypto & blockchain topics for a while), but due to the immutable nature of data stored in the blockchain, wouldn’t non-compatible changes after launch be quite difficult, requiring a consensus (or at least, absolute majority) between all nodes running the client?

I had a quick look at the demo; regarding the url field encoded in the resolution, is the intent of this to be a pointer to the resolution text? If so, as this is a mutable resource, what mechanism is there to ensure that the text of a given resolution isn’t modified while a vote is underway / once it has completed, a la a bait-and-switch scam?

I hadn’t seen this, and while I’m aware of it, I’m not too up to speed on the workings of Retroshare, beyond a very high level view (i.e. it’s an overlay network where physical peers are ideally pre-existing friends outside the network, and that one peer never directly communicates outside their immediate friends) - how is immutability of data ensured on Retroshare?

Just an aside to either/both of you, it’s not directly relevant to the topic in hand, but you might find it worthwhile observing the meeting tonight for the Distributed Digital Currencies and Economies Policy Working Group. It’s on #ppau-pdc at 2030 AEST (40 minutes from now).

7

Actually that’s about the limit of my knowledge too. I should try and contact the devs, see if they’re interested in explaining exactly how it works. It might also tie in with PPAU nicely, there are other Pirate organisations who use Retroshare for private and group chats now too.

8

I couldn’t find much in the way of documentation on Retroshare’s protocol. I’ll have a look again later, but as things stand, blockchain based solutions seem better understood and more appropriate as to the characteristics (immutable, trustless, decentralised) required for a secure voting s ystem

9

I hadn’t seen that. But I have many of the same concerns Jack has, plus a few more. It looks great for use cases where LiquidFeedback would be suitable, and if retroshare is already being used it’s great, but it’s a lot to buy in to if one is just looking for a voting system.

If all goes well we should be registered by the end of the year and ready for the next election.

Well, there are a lot more assumptions, actually. Realistically PPAU could hope for 10-20% of a seat, with 5-25% being bounds. If fewer parties participate that increases the participatory reward but decreases the odds of winning seats. I just added together total proportions of quotas in each state. That will roughly translate

I have faith that with sufficient discussion, conjecture, and criticism most parties will come to a well-reasoned conclusion, even if they don’t preference the NVB highly. At the end of the day there’s always an incentive for preferencing it above polar parties (I imagine Family First will preference the NVB above the Greens, for example, regardless of how they feel about their political sovereignty).

Technically, no, but the de facto implementation does introduce trust. My idea is to work with parties to set up their own vote-explorers (which do the tallying), and nodes to read the blockchain.

Counterparty would need PoW before anything about it’s implementation provides any more benefit than plain OP_RETURN (which is possible and useful). Ethereum doesn’t provide the security that Bitcoin does, so eh. Also it’s not even live. Even trusted computing is not really needed, though would make SPV clients nicer. I don’t consider it a priority; it would be the type of thing to come up in a few years if/when ethereum becomes the stronger blockchain, since immutability >> SPV in my mind. The potential for subversion is greater when a blockchain is weak, at least Bitcoin only requires 1.3 GB in pruned mode and a dedicated server, which is cheap when you’re securing a national voting system.

No more so than changes to the Bitcoin protocol. It would be a hard fork, yes, but the NVB has far more control over the protocol than the Bitcoin core devs have over the blockchain, and the same approach would apply: if timestamp > HARD_FORK_TIME then postfork else prefork. Most changes would be extensions, though, not changing fields and encoding, which is much easier to deal with. I’m coding in alerts atm to deal with that. Consensus among NVB members would be required by party policy, I don’t think other parties will end up having a say, though. They will have politico-economic guarantees that can’t be violated, ofc, but they won’t get to vote on a new opcode or something.

:smiley: the first protocol criticism! Great success! Public voting will pretty much just be on bills before the senate, so they’re technically mutable anyway, but if we don’t trust the parliamentary process there are bigger issues. Additionally the field isn’t validated so any bytes can be put there, it’s also 20 bytes wide so you can fit a hash160 (or sha256 truncated hash) in which should provide enough immutability in those cases. One way to deal with this for internal NVB policy would be to put the first 20 bytes of the pull request’s most recent commit’s hash if it were a software thing. Maybe renaming the field would be appropriate, to ‘comment’ or something.

I get the feeling it isn’t at all, so one party could provide two different answers to two different requests, for example. My knowledge of the protocol is lacking, though.

I can’t find logs of the meeting anywhere, and moreover I found this in the IRC code of conduct: “Do not publish logs where they are publicly available.” :frowning:.

10

Just a partial reply at the moment, as I’m at work and can’t type up a proper one right now - I’ll edit this post to expand it tonight.

I believe this is simply in regards to general chat in #ppausocial and the like. Formal meetings are always publicly minuted on the wiki. Looks like the ones from last night haven’t gone up on the wiki yet, but the pad containing the draft policy and the IRC logs can be found here. I’d ask that you refrain from editing this as you’re not, to my knowledge, a member of PPAU.

11

Thanks Jack, and ofc, will refrain from editing.

12

This is still a key issue given current patterns of behaviour by sitting members. Voting on law changes without enough time to even read through and comprehend the proposal is one. Trade agreements implemented without public oversight which affect Australian laws is another - TPP is still a potential issue.

Anything which moves Australia towards a more open and accountable system where we can know and trust the actions of our representatives is a step in the right direction.

1 Like
13

Is this really a great idea in a world where most citizens don’t install OS updates?

If it gets any traction the rational incentive is to start hacking. Given that computing history is full of widespread vulnerabilities, a reasonable use for a 0day is to interfere with voting.

If you expect members of LD to secure their computers against new 0days, that’s an assumption worth calling out since it can’t be done.

14

I’d like to preface this post with “Don’t let the perfect be the enemy of the good.”

In the early years it will be mostly parties using this system, so easy to manage the security of it with so few actors. Also, since everything is done on the blockchain it’s super easy to notice when things happen you don’t approve. The authority and voter can work together to nullify any attack quickly. I also have plans to integrate single-voter functionality into accessible sites (changetip is a good candidate, though it’s not like I’ve talked to them about it or anything). Additionally TREZOR can provide simple hardware security via USB and bitSIM can provide hardware security on phones. Your security concerns are valid but not really potent. The time when there are 20 million devices in Australia to easily be targeted by malware is decades away, so it’s not much use thinking about joe bloggs yet.

Sure. However, 0days aren’t everyday events and because all this is blockchain based you see immediately if someone has unauthorized access, then IDs are easy to revoke (unlike TLS certs). This is would not even be close to world-ending.

Many protocol proposals can mitigate this sort of behaviour, even going so far as network-wide vote freeze if something crazy happens + revocation of the resolution abused. They are inconvenient events, but it should be okay and easily survivable.

That’s not what I’m saying. I’m just saying the risks are relatively low and easily mitigated.

Also, for anyone interested, I’m hosting a meetup and going over a lot of detail about the NVB, you can see the meetup page here. Will be happy to answer questions in detail on the night.

15

If it never gets past the early years is it worth doing?

Again, this works in the small but not in the large.

There are well over 20 million devices in Australia which are easily targeted by malware.

If you actually have a way to know that, I’d love to find out how; by definition 0days are not known at the time they are being used.

I don’t think you’re completely right about either of those statements. The blockchain certainly removes a large subset of possible attacks, but if you’re comparing it to the current paper systems it’s vastly less secure.

16

Ofc, how else will we know if it ever gets past the early years. Even just changing the balance of power permanently to a LiquidDemocracy structure with open participation has MASSIVE benefits. Surely, you’re not denying that, are you? If you are, then do you think Liquid Democracy is a good idea? If so, please reconcile how we would be worse off if the NVB held the balance of power, because I am unable to.

Come on, use your imagination. Email digests of how you voted that day, plus if you’re account has the transfer flag activated, etc. There are tonnes of ways to build reactivity and decent security models into this.

I don’t even know what your point is here.

And the reason they stay hidden is they are not widely used. The economics of 0days is very interesting and provides some insight into why manipulating a public voting system is not really a good use; private voting systems, sure. Also, 0days aren’t some panacea for attackers. You seem very antagonistic.

That’s not true. Attacks on paper based systems are harder because they’re larger from a human perspective. However, if I drop two ballets in there is no possible way for you to tell. If I vote twice on a blockchain you know straight away. There are obvious cases where the integrity and security of blockchain voting is vastly superior because it is of a completely different construction. Additionally anyone can count votes from home using blockchain voting; to perform an audit of a paper based system is both nondeterministic and expensive.

17

This is not effective in a large system. A 30% open rate is an excellent result when sending large numbers of emails. Manipulating email en masse is well within the reach of the NSA (but then, the American government would never throw an election, right?).

Have you written a threat model? I’d love to see a link.

18

No, the protocol isn’t even done yet so that’s premature in my mind. The other half would basically be like any other Bitcoin wallet, and the same threats apply.

That doesn’t address my argument, just my example. Insert SMS/App/Telephone call even, any form of push notification.

19

You’re designing a voting protocol without a model of who might attack it and why?

20

I am considering these sorts of things as I go along but please don’t be surprised when the few-month-old project that one dude’s been doing on nights/weekends doesn’t use enterprise grade design procedures. I haven’t written a thread model because the cost would be high and the benefit low. If this pans out then sure, a thread model and security audit and all those sorts of standard practices will be done, but it is far too early to discuss this now. The security model itself is stable enough and battle-tested (since it is mostly inherited from Bitcoin).