Market-Based Solution to the Decentralization vs. Speed Trade-off

[cunicula]

My points:

1) Decentralization is an important source of a cryptocurrency's value. [If true increased decentralization should increase mkt value all else equal.]
2) Low Cost and speed of txns is another important source of a cryptocurrency's value. [If true lower cost and greater speed should increase mkt value all else equal.]
3) There is a trade off between (1) and (2). Increasing (1) implies decreasing (2) and vica versa. [decentralization requires duplication of data processing.]
4) The optimal mix of (1) and (2) should be left up to the market, not picked by omniscient developers. [The mkt should pick a value-maximizing combination.]

Consider the following system:
a) There are between 0 and 1 trillion units of a base currency. Call this base currency 'silver'.
b) There are also between 0 and 100,000 units of a currency 'gold'.
c)  Within the system, gold and silver are convertible at a fixed exchange rate of 1 gold=10 million silver. The market price may differ of course.
d) Total units of value in the system are equal to 1 trillion 'silver' at all times.
e)  Holders of the gold currency are authorizers of txns. If a 2/3 majority of gold currency holders all sign a block than the block is valid.  
f)  Silver holders can also vote by converting 10 million silver into gold in a single txn and singing a block that includes this txn. The silver holder then counts towards the 2/3. [This makes a hostile takeover of any gold cartel possible.] Similarly gold holders can remove themselves from the voting body by converting gold into silver.
g)  Blocks with a larger number of gold signatures displace blocks with a smaller number.
h)  A block must include at least as many txns as there are holders of gold currency. [This is an artificial constraint determining block spacing. Adding a third specie could relax this.]
i)  Once one of the gold holders has accumulated enough txns. He packages it into a block and submits it for signatures.
j)  There is absolutely no difficulty, PoW, etc.
k)  Txns are prioritized based on fees. Fees are evenly distributed across the network in proportion to currency holdings.

Observe the following:
1) Txn Processing Speed is highly variable. If there is just 1 gold coin, txns are instant (up to the 1 guy's processing, transmission, and storage capability). If there are 100k gold coins, you have to wait for the next 100k txns to show up before getting your txn processed. Processing is duplicated 100k times.
2) Decentralization of the system is highly variable. There could be just 1 voter - complete centralization. There could be up to 100,000 voters - great decentralization
2a) Note also that complete centralization is not an absorbing state. The 1 voter can be displaced by 2 voters who convert their coins from silver to gold.
3) The decentralization vs. speed trade-off is set by the market.
3a) If the market price of gold is higher than 10 million silver. Then the market is asking for more decentralization and less speed. To profit, I should buy silver. Convert the silver to gold. Sell the gold to whoever wants to take on the job of running a node.
3b) If the market price of gold is lower than 10 million silver. Then the market is asking for less decentralization and more speed. To profit, I should buy gold. Convert the gold to silver. And sell the gold on the market.
4) The only incentive to process txns is the gold owner's desire to maximize his asset value + txn fee interest on the asset.
5) Speed limitations become less of an issue as txn volumes increase. Therefore decentralization would likely increase over time.
6) The amount of storage required for each txn is fixed at approximately double what it is in bitcoin. [This is due to the artificial contraint.]

Would a cryptocurrency system like this work? Why or why not?
Should the speed vs. storage space trade-off be left to the market too? [downside is the market's search problem for an optimal mix of speed, storage efficiency, and decentralization becomes a 3-D search and the market is more likely to fuck up.]

Note: For initial distribution I would suggest an IPO of a mixture of silver and gold, with some of the currency sold on the market and other currency distributed to people who were engaged in useful projects.

[iddo]

1) Decentralization is an important source of a cryptocurrency's value. [If true increased decentralization should increase mkt value all else equal.]
2) Low Cost and speed of txns is another important source of a cryptocurrency's value. [If true lower cost and greater speed should increase mkt value all else equal.]
3) There is a trade off between (1) and (2). Increasing (1) implies decreasing (2) and vica versa. [e.g. decentralization requires duplication of data processing.]

I'm not so convinced that there's a tradeoff. I agree that more decentralization implies more security. I think that technology-wise we can provide fast enough speed (say new block every 2 minutes or 10 minutes), so if you wait e.g. 10 minutes or 60 minutes you can be confident that your txn cleared, which is much better than what centralized banks offer at the present (for example having to wait days until your money reaches mtgox). For scenarios that require even faster speeds, we can have external (more centralized) payment processing systems on top of the cryptocurrency (discussed e.g. at Talk:Scalability and this old wiki revision). Regarding low fees, I agree that this would increase the value of the cryptocurrency, but can you explain why there's supposed to be a tradeoff between low fees and more decentralization? Also, could you explain why the pure-PoS protocol that you propose here is supposed to imply lower fees than the pure-PoW protocol?
I think that rather than this supposed tradeoff, the advantages of PoS over PoW are (1) better security because the stakeholders are (also) responsible for providing security, and (2) more efficient energy use.


Initial thoughts regarding this particular protocol:

1/3 malicious gold-holders can destroy the cryptocurrency by denying service. If you change the signatures requirement to 1/2 instead of 2/3, then a malicious majority could double-spend. Similar scenario was discussed here. We generally seek to obtain a secure system as long as the majority isn't malicious, while your system is vulnerable if just 1/3 is malicious.

The initial distribution isn't so clear, could you elaborate? Who would control the initial distribution process? Can it be done in a decentralized fashion?

[cunicula]

1) Decentralization is an important source of a cryptocurrency's value. [If true increased decentralization should increase mkt value all else equal.]
2) Low Cost and speed of txns is another important source of a cryptocurrency's value. [If true lower cost and greater speed should increase mkt value all else equal.]
3) There is a trade off between (1) and (2). Increasing (1) implies decreasing (2) and vica versa. [e.g. decentralization requires duplication of data processing.]

I'm not so convinced that there's a tradeoff. I agree that more decentralization implies more security. I think that technology-wise we can provide fast enough speed (say new block every 2 minutes or 10 minutes), so if you wait e.g. 10 minutes or 60 minutes you can be confident that your txn cleared, which is much better than what centralized banks offer at the present (for example having to wait days until your money reaches mtgox).

Banks are ridiculously inefficient, but I don't think that is related to centralization vs. decentralization. Banks don't adopt modern technology and need to maintain legacy systems that maintain compatibility with one another. Once you adopt one technology with network effects (e.g. Windows, magstripe cards, QWERTY), it is very difficult to get rid of even if it obviously sucks. Problem is that trying to get upgrade it breaks all the infrastructure built around it.

For scenarios that require even faster speeds, we can have external (more centralized) payment processing systems on top of the cryptocurrency (discussed e.g. at Talk:Scalability). Regarding low fees, I agree that this would increase the value of the cryptocurrency, but can you explain why there's supposed to be a tradeoff between low fees and more decentralization? Also, could you explain why the pure-PoS protocol that you propose here is supposed to imply lower fees than the pure-PoW protocol?
I think that rather than this supposed tradeoff, the advantages of PoS over PoW are (1) better security because the stakeholders are (also) responsible for providing security, and (2) more efficient energy use.

The trade-off here is about duplication of effort storage and processing effort (nothing to do with PoW). It doesn't really apply yet because effort is so tiny, but it is just starting to apply with bitcoin (e.g blockchain download). The people dealing with exclusively silver could be running light nodes. They just need to keep their own private keys. They don't need to verify every single txn and store the complete database. They are trusting the gold guys to keep things running. They don't need the complete database and they don't need to verify every txn. At peak load, VISA is processing 10k txns per second. That is 2.5 1 MB blocks per second that need to be broadcast and stored. If VISA was decentralized, we would need each of the data centers to duplicate storage and processing of 75 TB each year. I have no idea how much this would cost. I don't think we can just add up hard drives and get a reasonable estimate (someone supply me with reasonable figures please). Let's assume 50k USD per year. What if there was one node for each bitcoin? That would be 21 million*50,000=1,500 billion USD in annual operating costs. That would need to be paid for with fees. VISA generates 8 billion USD in revenue for year, so the fees per txn necessary to support this would need to be 200 times the average fee per txn charged by VISA. Clearly this can't work. Under this completely baseless 50k assumption, we can't have more than 160,000 nodes and be competitive with VISA in terms of fees. If our goal is to be fiercely competitive in terms of fees, we should probably have less than 10,000.

Of course, you could just limit the scale of bitcoin to preserve decentralization (http://www.reddit.com/r/Bitcoin/comments/13jj0d/in_favor_of_not_increasing_the_block_size/), but that seems like a ridiculously stupid choice. In a currency system, scale brings network effects and network effects are everything (watch VISA stick around and dwolla fail to attract customers). Bitcoin is worth something because there is a small probability it will take off.

Initial thoughts regarding this particular protocol:

1/3 malicious gold-holders can destroy the cryptocurrency by denying service. If you change the signatures requirement to 1/2 instead of 2/3, then a malicious majority could double-spend. Similar scenario was discussed here. We generally seek to obtain a secure system as long as the majority isn't malicious, while your system is vulnerable if just 1/3 is malicious.

It isn't quite like that. Any individual or organization holding 10 million silver could sign a txn converting his silver to gold and instantly help the good guys sign blocks. There are coordination/trust issues if the silver is fragmented, but coordination seems possible in this type of emergency. In theory, all of the silver people can participate in voting immediately if they share their private keys and convert their silver to gold. Anyways, I don't think denial of service by the 1/3 is plausible. If the market thinks it is important to have a large amount of gold out there, then 1/3 of gold will mean a huge investment in the system.

2/3 of gold-holders could conspire double-spend, true. Again, the silver holders would have some recourse because they could coordinate to undo the double-spending.
Again, I don't think such a conspiracy is at all plausible though. The gold-holders have a huge investment in the system. Double-spending destroys confidence.
[/quote]

The initial distribution isn't so clear, could you elaborate? Who would control the initial distribution process? Can it be done in a decentralized fashion?

There are many possibilites. It could be centralized in which case the creator or creator(s) sell it in tranches (10% one month, 10% the next) and give it away slowly (will you set up blockchain.info and the online wallet for our currency? great thanks here is 1%. Will you adopt the currency and send me receipts for anything purchased with it? Great I'll subsidize each purchase., etc.) I think this is a good model, but I guess I'm a rare bird. The important thing is that it is transparent and does not enrich the creators (i.e. they can't keep more than a very small amount).

One could simply take the bitcoin database and assign ownership to everyone who holds bitcoin (i.e. they just import their wallet.dat). This seems like a good model to me too. It would reach a comparatively wide audience. One could combine the bitcoin database with privately held coins that were given away to bribe businesses. Again transparency is key to the bribery not being perceived as theft. You would have to ask the public who to bribe and then accept their choices.

There could be PoW-based distribution. This is becoming more and more pointless though. The original idea was to give everyone with a computer a small amount. Increasingly it means giving a significant amount to whoever started a large mining operation and a useless amount to everyone else. The mining operations don't actually do anything useful to promote the currency.

One model I like is to give 50% to PoW miners and then 50% to an organization elected by coin-owners (e.g. a business that offers to accept the currency in exchange for a bribe). The organization could change over time through periodic election. This is a very transparent and fair way of organizing business subsidies.

[cunicula]

You see, this why you should become a programmer. Create a simulation with a large number of players, give the players certain properties so that -- individually -- they behave predictably, and see how the different scenarios play out.

I can run mathematical simulations like this.

Coding software is a completely different thing though. I waste much too much time already to even think about learning that.

[iddo]

The trade-off here is about duplication of effort storage and processing effort (nothing to do with PoW). It doesn't really apply yet because effort is so tiny, but it is just starting to apply with bitcoin (e.g blockchain download). The people dealing with exclusively silver could be running light nodes. They just need to keep their own private keys. They don't need to verify every single txn and store the complete database. They are trusting the gold guys to keep things running. They don't need the complete database and they don't need to verify every txn. At peak load, VISA is processing 10k txns per second. That is 2.5 1 MB blocks per second that need to be broadcast and stored. If VISA was decentralized, we would need each of the data centers to duplicate storage and processing of 75 TB each year. I have no idea how much this would cost. I don't think we can just add up hard drives and get a reasonable estimate (someone supply me with reasonable figures please). Let's assume 50k USD per year. What if there was one node for each bitcoin? That would be 21 million*50,000=1,500 billion USD in annual operating costs. That would need to be paid for with fees. VISA generates 8 billion USD in revenue for year, so the fees per txn necessary to support this would need to be 200 times the average fee per txn charged by VISA. Clearly this can't work. Under this completely baseless 50k assumption, we can't have more than 160,000 nodes and be competitive with VISA in terms of fees. If our goal is to be fiercely competitive in terms of fees, we should probably have less than 10,000.

I don't think that you explained the tradeoff between txn fees and decentralization?

I think that if you wish to buy for example a new car then you can transact directly on the blockchain, and for less valuable fast txns there could be centralized transaction hubs, on top of the cryptocurrency: https://en.bitcoin.it/w/index.php?title=Myths&oldid=27737#Point_of_sale_with_bitcoins_isn.27t_possible_because_of_the_10_minute_wait_for_confirmation

1/3 malicious gold-holders can destroy the cryptocurrency by denying service. If you change the signatures requirement to 1/2 instead of 2/3, then a malicious majority could double-spend. Similar scenario was discussed here. We generally seek to obtain a secure system as long as the majority isn't malicious, while your system is vulnerable if just 1/3 is malicious.

It isn't quite like that. Any individual or organization holding 10 million silver could sign a txn converting his silver to gold and instantly help the good guys sign blocks. There are coordination/trust issues if the silver is fragmented, but coordination seems possible in this type of emergency. In theory, all of the silver people can participate in voting immediately if they share their private keys and convert their silver to gold. Anyways, I don't think denial of service by the 1/3 is plausible. If the market thinks it is important to have a large amount of gold out there, then 1/3 of gold will mean a huge investment in the system.

I remain unconvinced. There are at most 100,000 gold coins in total, so a malicious entity can obtain 1/3 of all the gold coins in sync with the rest of the participants, until it gets 33,334 gold coins at the most. I still claim that if 1/3 of the stakeholders are malicious then this system would be destroyed.

If we replace 2/3 by 1/2 then the double-spending risk becomes more pronounced, in particular when we use your common assumption that the majority is rational rather than honest. Even if only (say) 30% of the stakeholders are malicious, there would need to be just 20% rational stakeholders for double-spending to occur.

[cunicula]

I don't think that you explained the tradeoff between txn fees and decentralization?

Sorry, it is implied. The operations of the data center have to be compensated paid some how. This would have to come from some form of fee (interest, inflation, fee).
VISA does not work for free.

I remain unconvinced. There are at most 100,000 gold coins in total, so a malicious entity can obtain 1/3 of all the gold coins in sync with the rest of the participants, until it gets 33,001 gold coins at the most. I still claim that if 1/3 of the stakeholders are malicious then this system would be destroyed.

Sure, but why would someone do that?

If we replace 2/3 by 1/2 then the double-spending risk becomes more pronounced, in particular when we use your common assumption that the majority is rational rather than honest. Even if only (say) 30% of the stakeholders are malicious, there would need to be just 20% rational stakeholders for double-spending to occur.

Profits from double-spending = Stake Value After Double-Spend - Stake Value Before Double-Spend  + Double-Spend Profit

If they are double spending, then presumably Stake Value After Double-Spend - Stake Value Before Double-Spend <0.
I find it hard to believe that they collectively they will earn more from double-spending than they would lose from damaging the reputation of the currency.

Anyways, the same kind of calculation applies to the system we were discussing in the other thread. The Gold coin holders are almost perfectly analogous to participating stakeholders. If you are worried that there may be too few then you can just give them all of the txn fees rather than distribute them evenly. If you are still worried that these fees are too low you can add some additional mandatory payments.

One of the points I am trying to make here is that this system is a very close analogy to the other system, but is much simpler. I'm happy with the other system too.
 

[iddo]

I don't think that you explained the tradeoff between txn fees and decentralization?

Sorry, it is implied. The operations of the data center have to be compensated paid some how. This would have to come from some form of fee (interest, inflation, fee).
VISA does not work for free.

Not sure that I understand the scenario exactly. At the end of the day the user who wishes to do some txn has to pay some fee to the entity that handles his txn. When the system is decentralized, he pays the fee to the decentralized node that processed his txn, and when the system is centralized he pays the fee to the central entity. Why do you claim that the fee to the central entity will be lower than the fee to the decentralized node? Wouldn't the central entity be a monopoly who could jack up fee prices, while decentralized nodes compete and therefore the fee prices are pushed downward?

I remain unconvinced. There are at most 100,000 gold coins in total, so a malicious entity can obtain 1/3 of all the gold coins in sync with the rest of the participants, until it gets 33,001 gold coins at the most. I still claim that if 1/3 of the stakeholders are malicious then this system would be destroyed.

Sure, but why would someone do that?

How about blackmail, for example the 1/3 malicious minority could say "pay us X silver coins otherwise we deny service" ? You might even describe this 1/3 minority as rational instead of malicious?

All I'm saying is that a protocol that withstands 1/2 malicious stakeholders is preferable to a protocol that only withstands 1/3 malicious stakeholders, and those were just the initial thoughts, maybe there are even worse vulnerabilities that we're still missing. One other drawback of this protocol vis-a-vis the lottery protocol is that here the malicious majority (actually 1/3) can deny service completely, while with lottery the 1/2 malicious majority could only generate empty blocks half of the time. Edit: actually with 3 consecutive mandatory stakeholders blocks, the performance will become 8 times slower, and 1/8 of the time the malicious 1/2 will create empty blocks.


I don't think that double-spending/denial-of-service attacks with this pure-PoS protocol are analogous to the mixed PoW+PoA protocol. With mixed PoW+PoA the attacker depletes his resources while he's carrying out the attack, because of the PoW element. With pure-PoS it's costless for the malicious/rational stakeholders to carry out attacks.

[iddo]

If there are 100k gold coins, you have to wait for the next 100k txns to show up before getting your txn processed.

Two problems.

1) Suppose that there are (say) 50k gold holders. With Bitcoin, you know that your txn will be processed in about 10 minutes. Here, you said nothing about the variance. The user who wishes to do a txn has to wait until 50k other users also wish to do txns, so the amount of time he has to wait could be highly unpredictable. I'm not sure whether it'd all converge to predictable numbers, and how long it would take to re-converge if some fundamentals have changed, etc.

2) The much more severe problem is forked branches. After 49,999 txns were broadcasted, when a 50,000th txn is broadcasted it might compete with another 50,000th txn that reaches other network nodes first, so we've forked into two branches. After the next 50k txns, those two branches could fork into 4 branches, and so on.

BTW, how does the Bitcoin client behave when it solves a block which gets rejected by other nodes because they saw another solved block (slightly) earlier? Does it try to extend its solved block, or throw it away because of the rejections? If it tries to extend, does it mean that a mining pool that solved a would-be orphaned block will waste the next 10 minutes (on average) trying to extend it?

[cunicula]

1) Suppose that there are (say) 50k gold holders. With Bitcoin, you know that your txn will be processed in about 10 minutes. Here, you said nothing about the variance. The user who wishes to do a txn has to wait until 50k other users also wish to do txns, so the amount of time he has to wait could be highly unpredictable. I'm not sure whether it'd all converge to predictable numbers, and how long it would take to re-converge if some fundamentals have changed, etc.

Txns arrival rates are usually modelled using the poisson distribution. http://en.wikipedia.org/wiki/Poisson_distribution
This is the same as the distribution that describes block arrivals in bitcoin. It should be quite similar (though there would likely be diurnal cycles).

A completely reasonable criticism though is that this is highly inflexible. There is no reason why we should have 1 txn per gold holder. Why not 2 txns per gold holder or 1 gold holder per 10 txns? You could adjust this using a third coin (call it copper). People could exchange copper into silver at a fixed rate and the amount of copper issued in the previous block would determine the number of txns per gold holder. I've just left that out for simplicity. You can think of all the exchangeable currencies as voting mechanisms.

2) The much more severe problem is forked branches. After 49,999 txns were broadcasted, when a 50,000th txn is broadcasted it might compete with another 50,000th txn that reaches other network nodes first, so we've forked into two branches. After the next 50k txns, those two branches could fork into 4 branches, and so on.

For one such a fork to happen we need to have one-third of the gold holders to sign two branches of equal height. You would only do that with deliberate malicious intent. So these guys would be obvious saboteurs / double-spenders. It's not clear what their motivation would be since they collectively have a large stake in the network. Since their crime is clearly established, it would be pretty easy to design a rule that confiscate their coins. [e.g. If duplicate signature on blocks of equal height and you have not built on it yet, merge the 2 new blocks, send the responsible gold coins to the txn fee fund, drop conflicting txns (pretend they never occurred), and count the merged block  as two blocks instead of one]. I'll say we don't have this rule and think about what happens. I'm just going to assume that the destructive conspiracy is limited to this one-third of gold holders.

It's useful to note that it is impossible to have more than 2 active forks of the same height with just a 1/3 conspiracy. 2/3 of miners only sign one block for any given height. It is impossible to have more than 2 valid branches of one height.

The instructions in bitcoin are to extend whatever branch you see until you see a branch that is strictly longer than your own. There are three possibilities:

1) Fork A is extended before Fork B (or vica versa). Enough of Fork B's signers learn about this that Fork B is not extended. If so, the two chains merge.
2) Fork A is extended before Fork B, but not enough Fork B signers learn about this, so they extend their own fork. If so, then the two chains continue to be forked.
3) Both Fork A and Fork B split into two more forks and stall. Neither chain is extended.

Eventually we end up at (1) or (3).

(3) happens if 1/6 of people sign Fork A1, 1/6 of people sign Fork A2, 1/6 of people sign Fork B1, 1/6 of people sign Fork B2, and the remaining 1/3 signs everything. None of the branches will have a quorom and the whole thing will stall.

If the one-third conspiracy involves about 1/3 of the entire money supply, then the whole thing stalls forever. This type of 1/3 conspiracy kills the whole thing.

If the conspiracy involves somewhat less than one-third, then silver holders can intervene at any time to convert coins to gold. The conversion process signs one of the 4 forks and appends a txn. I'm going to assume that silver holders all sign which ever fork currently has the most signatures. Once sufficient silver holders do this, then one fork is chosen as the main chain. Also, the next block has a lot more gold, so the conspiracy of 1/3 is diluted and can probably no longer generate forks. This will regenerate network stability.

Hmmm. This brings up another problem as well. There could be stalling even if people sign only one block of the same height. (i.e. if 2 blocks are generated and people each sign 1/2 of one.) To prevent this you would need to have some waiting time between signatures that prevents the network from getting balkanized. I'll have to think more about it.

BTW, how does the Bitcoin client behave when it solves a block which gets rejected by other nodes because they saw another solved block (slightly) earlier? Does it try to extend its solved block, or throw it away because of the rejections? If it tries to extend, does it mean that a mining pool that solved a would-be orphaned block will waste the next 10 minutes (on average) trying to extend it?

The default behavior is to try to extend until you see a longer chain (i.e. waste the next 10 minutes). The problem is that your block might be the majority block and the rejected block might be the minority block. You can't be sure.

[cunicula]

You see, this why you should become a programmer. Create a simulation with a large number of players, give the players certain properties so that -- individually -- they behave predictably, and see how the different scenarios play out.

I can run mathematical simulations like this.

Coding software is a completely different thing though. I waste much too much time already to even think about learning that.

If so, just DO it, simulate that is.
Maybe you'll get completely new insights about this' thread topic.
For cheap.

Completely possible. But you kind of need to know what you are looking for in order to learn from a simulation. If you don't know, then you probably won't implement the simulation correctly. At this point, this suggestion is still a thought experiment.

[iddo]

For one such a fork to happen we need to have one-third of the gold holders to sign two branches of equal height. You would only do that with deliberate malicious intent. So these guys would be obvious saboteurs / double-spenders.

As you say in your subsequent comments, things are not so clear. I admit that my initial comment here was somewhat confused, but I still think that the concern is quite real. So for example if the last txn of the block competes with another txn, and 50% of the gold holders see and sign the block with the first txn and the other 50% sign the block with the competing txn: it could be that none of the gold holders is malicious, but we've reached a gridlock, so if 16% honest gold holders switch and also sign the other block, and vice versa, we get two forked branches. In case the gold holders are rational instead of honest, more elaborate scenarios that involve e.g. extortion could arise when the last txn is valuable.

BTW, how does the Bitcoin client behave when it solves a block which gets rejected by other nodes because they saw another solved block (slightly) earlier? Does it try to extend its solved block, or throw it away because of the rejections? If it tries to extend, does it mean that a mining pool that solved a would-be orphaned block will waste the next 10 minutes (on average) trying to extend it?

The default behavior is to try to extend until you see a longer chain (i.e. waste the next 10 minutes). The problem is that your block might be the majority block and the rejected block might be the minority block. You can't be sure.

I pity PPS pool operators...
I was wrong, the pool better work on its own branch even if the vast majority of the hashpower works on the competing branch, because it has its usual chances of solving the next block (and thereby solve two consecutive blocks), and if it switched to the competing branch then the likely-to-be-orphaned block that it solved immediately goes to waste.

[iddo]

cunicula, in case you missed it, please respond to (the first part) of post #8 when you're back.

[Sunny King]

I dunno I feel you have even more rules picked by the "omniscient developers". 10 million coins to become a trusted node  Does sound a lot like the direction realsolid was going with solidcoin/microcash, i.e. compromising decentralization to improve scalability and speed.

More seriously I think limiting block to have at least x number of transactions sounds like a bad choice. Block chain could get stuck when transaction volume is low, or ppl would flood useless transactions just so block chain can be 'unstuck'. I don't see how that is an improvement over the current block spacing target approach.

Also I often see this crucial point left unexplained in a block signing proposal: how do you deal with the situation that a majority of signing nodes are offline. Does that mean block chain is stopped? No I don't think it's reasonable to assume there is always a majority of signing nodes online, for a decentralized system intended to be run by general public.