[mikekchar]

I can answer part of that question. You can't make it much more frequent because the amount of time for the difficulty has to be balanced against propagation time for blocks or else you will have lots of forks. Probably you can make it work, but there are a fair number of assumptions in the Bitcoin protocol about this and it would probably be better to start a new coin if you want to do that. The 10 minute update was chosen specifically to avoid common network partition events.

As for block size, it's been ages since I looked into this stuff at all (and I've only ever watched out of the corner of my eye), but my impression is that the block size is currently limited for relatively arbitrary reasons. I don't think there is actually a lot of resistance to increasing the size sometime. It's just that the developers want to limit the size now to guide development in certain ways.

And really, as far as I'm concerned that's totally fair. If you don't like it, fork the coin. Or start a new one. Or stick with Bitcash. The developers are in control because that's the whole point -- to guide development in the way that they think will work best. Not everybody is going to agree. So what?

I think the only reason people get upset is because of the ludicrous amount of potential money on the line. And again: if you are controlling that ludicrous amount of potential money, you are able to vote with your feet -- to the extent that you can convince other people with ludicrous amounts of potential money to follow suit. If all that insane speculation and fraud were to vacate Bitcoin, the developers could happily code away and there would be nobody left to complain.

Let's face it. If we believe that there are billions of dollars tied up in BTC, the owners of that coin could easily afford to hire programmers to fork the protocol. They don't do it because the politics of doing so is essentially impossible. Most people want to stick with the dev group. Again, I'm left with saying, so what?

[DennisP]

> You can't make it much more frequent because the amount of time for the difficulty has to be balanced against propagation time for blocks or else you will have lots of forks.

The same problem also limits block size, since large blocks take longer to propagate.

But that's why Ethereum went with GHOST, which was originally proposed for Bitcoin. Instead of choosing the block with the most hashpower behind it, you choose the block with the most hashpower in the entire tree after it, so that forks contribute to a block's security. The original paper calculated that this allowed both faster blocks and higher throughput, and it's the reason Ethereum has 15-second blocks.

Here are a couple papers:

https://eprint.iacr.org/2013/881.pdf

https://eprint.iacr.org/2016/545.pdf

[nullc]

Ethereum abandoned ghost because of its amplification of selfish mining. Inclusion of 'uncles' does not increase block selection weight there.

[DennisP]

Looks like you're right. I found this stackoverflow answer:

https://ethereum.stackexchange.com/questions/38121/why-did-e...

...which says Ethereum actually uses a version of the "Inclusive Protocol," which according to its paper has similar advantages:

https://www.cse.huji.ac.il/~yoni_sompo/pubs/15/inclusive_ful...

[nullc]

> non-conflicting transactions of blocks outside the main chain are included in the ledger

I am pretty sure that isn't true. I'm looking at the code, and the only thing I see included for 'uncles' is the header. This has the beneficial property that higher orphan rates increase difficulty which should lower orphan rates.

OTOH, it doesn't appear that including other people's orphans is incentive compatible without the rest of ghost (because it lowers your own future income).

"a version of" -- there is no close in cryptography. :) Security analysis usually do not apply well to approximations.

Edit: See also this answer, https://ethereum.stackexchange.com/a/41647

[statoshi]

Indeed; the market has clearly chosen to prefer optimizing for low cost of full system validation (running a full node) over lost cost of transacting (cheap block space.)