Author

Topic: voting, qualified vs simple majority (Read 1949 times)

sr. member
Activity: 672
Merit: 258
https://cryptassist.io
June 02, 2011, 09:53:47 PM
#6
Interesting. Voting with existing Bitcoins would essentially amount to using past hashing work (Bitcoins) for security instead of or in addition to present hashing work (mining). Reminds me of HashCash and the concept of "reusable proof-of-work" which is one way of looking at Bitcoins. That would strengthen the network against an attacker, but as Nick points out there are a lot of practical and theoretical challenges associated with it.

right, and as current bearer of the actual value you have a direct incentive not to do anything that breaks confidence in the main block chain.

as far as technical challenges I don't think the ability to throw weight behind one branch of the block chain over the other weighted by the size of your associated wallet is that hard to have.  "voting" already takes weights into account, this would just alter that.  It is secure since you need to have the private keys associated with a block of bitcoins to use them as a block of votes.
sr. member
Activity: 416
Merit: 277
June 02, 2011, 08:55:27 PM
#5
You're right. I suppose if you were talking about an entirely new system (i.e. not Bitcoin) you could design rules that require a transaction to be to publicly disseminated for a certain period of time before it can be included in a block.

Under the current system, if you really wanted to ensure that all miners had a fair stab at any fee-containing transactions you could change the majority client software so that it did not relay a block containing fee paying transactions it had not previously seen.
Miners have free reign over what they include in a block, the only censure available to everyone else is not to relay their blocks.

At the moment, clients are catholic in their acceptance of block contents. This is to prevent rule-based block chain forks which would be painful to reconcile and extremely damaging to the bitcoin enterprise.

ByteCoin
full member
Activity: 234
Merit: 100
AKA: Justmoon
June 02, 2011, 08:36:22 PM
#4
Note that it's cheap for a miner to rack up fees artificially (using the above terminology) by including a transaction with a large fee in the block he's trying to hash but not distributing it across the network so that other miners can't get the fee if they solve the block first.

You're right. I suppose if you were talking about an entirely new system (i.e. not Bitcoin) you could design rules that require a transaction to be to publicly disseminated for a certain period of time before it can be included in a block.
sr. member
Activity: 416
Merit: 277
June 02, 2011, 08:29:43 PM
#3

* number or value of transaction fees as payor, payee, or both by a key

Note that this is not the same as the third list item as fees are not always proportional to the transaction amounts. In fact it is fairly cheap to rack up high transaction amounts artificially, whereas it is just as costly to rack up fees artificially as it is to incur them normally.

Note that it's cheap for a miner to rack up fees artificially (using the above terminology) by including a transaction with a large fee in the block he's trying to hash but not distributing it across the network so that other miners can't get the fee if they solve the block first.

ByteCoin
full member
Activity: 234
Merit: 100
AKA: Justmoon
June 02, 2011, 07:37:53 PM
#2
Interesting. Voting with existing Bitcoins would essentially amount to using past hashing work (Bitcoins) for security instead of or in addition to present hashing work (mining). Reminds me of HashCash and the concept of "reusable proof-of-work" which is one way of looking at Bitcoins. That would strengthen the network against an attacker, but as Nick points out there are a lot of practical and theoretical challenges associated with it.

* proof-of-work/mining effort (what Bitcoin currently does)
* value or number of coins or solution bits owned by key
* number or value of transactions as payor, payee, or both by a key
* number or value of transactions weighted by how recent they are
* various combinations of the above

To add to that list:

* number or value of transaction fees as payor, payee, or both by a key

Note that this is not the same as the third list item as fees are not always proportional to the transaction amounts. In fact it is fairly cheap to rack up high transaction amounts artificially, whereas it is just as costly to rack up fees artificially as it is to incur them normally. Edit: Actually, miners can rack up fees for free, see ByteCoin's message below.
sr. member
Activity: 672
Merit: 258
https://cryptassist.io
June 02, 2011, 02:06:52 PM
#1
I posted in the comments section of Nick Szabo's latest blogpost on bitcoin and I thought his response might be of interest.

 nazgulnarsil said...
One issue I haven't been able to wrap my head around so far is the fact that bitcoin holders themselves don't have any decision making power in the network. The people with the power to confirm/deny things are the masses of people running clients and the people with the most hashing power. while these are *generally* the people with a lot of bitcoins this doesn't necessarily have to be the case. It seems tha, like with a joint-stock company, you should need to have a vested interested to be able to make decisions. The people with the most bitcoins have the highest incentive to prevent fraud, therefore they should have the power. gmaxwell pointed out on #bitcoin that bitcoins can easily be traded for either hashing power or the ability to spam lots of client nodes (bot nets). But this still strikes me as odd. You don't have to sell your stocks to exercise the voting power.


 nick said...
nazgulnarsil, it doesn't readily come to my mind what conflicts of interest miners might have with other stakeholders (which I tend to think of as holders, creditors, and debtors). What biases on their part did you have in mind? Current Bitcoin or bit gold holders do have a bias towards deflation. Albeit this historically has not been as big a problem as inflation, they and creditors do have a conflict of interest with debtors.

Your objection does suggest to me an interesting possible improvement in the Byzantine agreement security. Instead of, or in addition to, the Byzantine "voting power in case of civil war" going to those proving work (i.e. the miners), require that participants sign challenges with their ownership keys to prove they own solution bits. The behavior of conflicting sending nodes, when the receiving node can't otherwise distinguish between correct and incorrect behavior, then gets weighted by the value of solution bits owned by said sender, either par or market, or similar. With such method one would have to own most of the money in circulation, rather than just most of the mining power, to corrupt the system (i.e. to successfully attack the subset of features that only have a Byzantine rather than cryptographic level of protection). This would discourage anonymity since doing these signatures and verifications over many keys would get computationally intensive, but I don't think strong anonymity is a feasible property in bit gold or Bitcoin anyway.


 nazgulnarsil said...
I haven't studied the source code intensively so I'm not sure about the technical merits of such attacks. It just struck me as odd that a simple majority rather than a qualified majority was implemented to begin with when Satoshi seemed have thought everything else through quite well.  also I don't think it has to be a proportional vote using private keys all the time. It could be a manual thing that only comes up under circumstances that merit it i.e. being attacked.

basically give the holders of large wallets significant veto power in case of emergency.

 nick said...
nazgulnarsil, that's basically the only time the "voting" matters, in an emergency when there are errors in the network corrupting the messages (unlikely) or (more importantly) an attack where nodes intentionally corrupt important properties of the protocol that aren't cryptographically protected.

There are also out-of-band reactions that can occur even if a majority corrupts the system. For example a minority can fork the block chain in Bitcoin (or title registry in bit gold) and then try to convince the world that their transaction history is the correct one and that the corrupt majority is in error. However, it's not clear what kinds of things can be proven out-of-band; this is a topic that deserves much further study.

Canonically Byzantine agreement assumed each node had a secure true-name identity, but because privacy is a desiderata, and because it would be very difficult to implement such a secure identity system on the Internet, we have to use some characteristic of users provable within the Bitcoin or bit gold system to weigh Byzantine "votes". I've now come up with a list of provable attributes in Bitcoin (or bit gold) by which message correctness "votes" might be weighed:

* proof-of-work/mining effort (what Bitcoin currently does)
* value or number of coins or solution bits owned by key
* number or value of transactions as payor, payee, or both by a key
* number or value of transactions weighted by how recent they are
* various combinations of the above

This is an incomplete list, especially if we add new attributes. One of the general ideas here is to weigh Byzantine "voting" towards those with more experience in the system, making a novel invasion more difficult. However in a currency there should also be a balance between various stakeholders (holders, creditors, and debtors). Since Bitcoin- or bit gold- denominated contracts generally exist outside the system, one would have to, at the very least, publicly register those contracts signed by the parties' keys for creditor or debtor status to be provable.

I should add, critiquing my own idea, that most of the attributes I list just above are not fully provable with cryptography but in part rely on Byzantine correctness.

For example, a majority attacker can prune the transaction chain to reduce the value of his opponents' coins (or solution bits in bit gold) and thus his votes. Fortunately the majority can't add value, at least in bit gold: it does require proof of work to _add_ solution bits and owner signatures which no majority can forge to receive solution bits from others.

It would be worth studying this in more detail -- does the attacker already need to have reached a majority in order to launch a vote-altering attack, rendering it irrelevant, or does the asynchronous nature of the protocol provide a way for a minority attacker to exploit the lack of cryptographic proof to bootstrap their way to a majority? I suspect a much more detailed look at the protocol is required to answer this question.

gwern, are you reading? Most of this stuff is indeed far from straightforward. :-)

Also, one of those annoying edge cases is how the system can safely bootstrap starting with zero coins and zero transactions.


Jump to: