Quote from: solex on February 05, 2013, 07:08:27 AM

Quote from: Maged on February 05, 2013, 06:46:12 AM

Quote from: Gavin Andresen on February 04, 2013, 05:17:08 PM

Rationale: we should use time-to-verify as the metric, because everything revolves around the 10-minutes-per-block constant.

...let's lower that constant. ...
In summary, I propose that to avoid the tragedy of the commons problem, instead of limiting the available space, we limit the available time allowed for the block to propagate instead. Now THAT is a Bitcoin 2.0 (or rather, 1.0)

For the rest of us who are catching up, are you proposing what seems far more radical than eliminating the 1Mb limit?

Quite possibly. However, if we think of the 10 minute constant as not actually having to stay at that constant, we can adjust it so that at the time we disable the 1 MB limit, the largest block that miners would practically want to make at that time would be 1 MB. Basically, this would protect us from having a 1 MB limit one day, to a practical 50 MB limit (or whatever is currently practical with the 10 minute constant). I mainly want people to remember that changing the block time is also something that's also able to be on the table.

Quote from: solex on February 05, 2013, 07:08:27 AM

Can you please clarify. Are you proposing reducing the 10 min average block creation time?

Yes.

Quote from: solex on February 05, 2013, 07:08:27 AM

If so, what happens to the 25 BTC reward which would be excessive, and need a pro-rata reduction for increased block frequency?

Just like you said, it would have a pro-rata reduction for increased block frequency. Sorry, I assumed that was obvious, since changing anything about the total currency created is absolutely off the table.

Quote from: caveden on February 05, 2013, 08:04:34 AM

Quote from: Maged on February 05, 2013, 06:46:12 AM

Quote from: caveden on February 04, 2013, 07:25:00 PM

EDIT: Oh, and of course, there must be tolerance levels too (if I'm X blocks behind the chain I once rejected, I'll give up and start building on top of it). You don't want to create that many chain forks!

Absolutely. Of course, that sadly means that we won't be able to ever trust a block until it gets past that point (which I think should be 2-4 blocks).

Would it really?

Yes. You wouldn't be able to trust that a majority of the network acknowledged a block until it gets past the point where all clients are required to accept it as part of the chain.

Imagine that only 10% of the network accepts blocks over 10 MB and 100% accepts blocks less than 1 MB. What if that 10% got lucky and generated two 11 MB blocks in a row? Well, the other 90% would just ignore them because they are too large. So, those blocks get orphaned because the rest of the network found three small blocks. If you just accepted the 11 MB blocks as a confirmation and sent goods because of it, you could be screwed if there was a double-spend.