あなたは単独のコメントのスレッドを見ています。

残りのコメントをみる →

[–]yummty 0 ポイント1 ポイント  (20子コメント)

[–]rnicoll 4 ポイント5 ポイント  (6子コメント)

The "For/against" split there gives the wrong impression - the "For" is only those who agree with 20mb as a target size (and the page does note this). Whether we need an increase is IMHO less controversial than the details of what the increase is, when it occurs, and whether any other hard-fork features get through at the same time.

Personally I think Bitcoin needs bigger blocks, but I think the timeline for the switch is too early. Having blocks get to the point where they're mostly full, and then grow at around the rate of traffic increase until 20mb would be my ideal scenario, although there's a lot to be said for keeping it simple.

[–]kingcolex 2 ポイント3 ポイント  (3子コメント)

Then we would have a fork every year, it's better to do a 20mb fork and let it work for 5+ years

[–]rnicoll 2 ポイント3 ポイント  (2子コメント)

Well, I see no reason block size couldn't scale over time in the way rewards do (except, growing rather than shrinking). One code change, one fork, but staggered changeover.

[–]cha0sman 0 ポイント1 ポイント  (1子コメント)

Well, I see no reason block size couldn't scale over time in the way rewards do (except, growing rather than shrinking).

Or maybe the way that difficulty is adjusted, except, based upon the number and size of the transactions.

[–]rnicoll 0 ポイント1 ポイント  (0子コメント)

Something I'm thinking about and I'll write up tonight in detail is that we probably need better tools for miners to decide what to include in blocks, based on cost/reward. A 20mb block size limit by no means requires miners use all of it.

[–]yummty -4 ポイント-3 ポイント  (1子コメント)

Whether we need an increase is IMHO less controversial than the details of what the increase is, when it occurs, and whether any other hard-fork features get through at the same time.

I disagree. Most of the devs are against any sort of increase. That's my understanding of what's going on.

I asked for a for/against split because it helps us lay people keep score.

[–]rnicoll 1 ポイント2 ポイント  (0子コメント)

Apologies, I'd mixed up Matts and thought Matt Corallo had revised his comments after his initial post. You're right, it's clearer than I thought.

[–]cbeast 7 ポイント8 ポイント  (12子コメント)

Gavin has math to back him up. The others haven't shown their math.

[–]petertoddPeter Todd - Bitcoin Expert 5 ポイント6 ポイント  (11子コメント)

[–]CrazyTillItHurts 2 ポイント3 ポイント  (4子コメント)

Explain this bit:

Q + (1-Q)*Q = (1-Q)2 -> Q2 - Q + 1/2 -> Q = (1 - \sqrt(2))/2

Q ~= 29.2%

Firstly, I'm not sure the significance here of = over ->

When I use -> that usually means a simplification step. I don't know what you are doing here. Also, if you assign an actual value to Q, let's say 5 for instance, the first bit works out to:

5 + (1-5) * 5 = (1 - 5)2

Which ends up

-15 = 16

[–]petertoddPeter Todd - Bitcoin Expert 0 ポイント1 ポイント  (1子コメント)

Yes, -> means simplification.

Q is % of hashing power, so it must be between 0 and 1. Assigning 5 to Q makes no sense.

[–]CrazyTillItHurts 0 ポイント1 ポイント  (0子コメント)

Thanks. I don't know the math, just trying to understand it

[–]CardboardHeatshield 0 ポイント1 ポイント  (0子コメント)

That means 5 is not the answer youre looking for...

[–]didyoudyourreps 0 ポイント1 ポイント  (0子コメント)

Also, if you assign an actual value to Q, let's say 5 for instance

What the fuck makes you think you can just put any number in there?

(1-x)2 = 0

(1-5)2 != 0 WTF?!

Also, the first -> shows the equation rewritten in the general form for a second order equation (=0 is implied), and the -> the solution given by the usual formula.

[–]cbeast 6 ポイント7 ポイント  (5子コメント)

That's a social game about withholding blocks. You think too small. The big boys will withhold 51% hashing power not only to keep costs down, but to orphan your blocks when you gamers try to play block games.

[–]awemany 0 ポイント1 ポイント  (1子コメント)

This is actually a damn good argument that I thought about today myself. If consensus is to keep BTC running, making insane blocks as a miner will make others (effectively) eject you from the blockchain.

Which brings me to an interesting point: What would happen if the max. block size would be a configurable variable that the full node operator has to select? Would the network fragment or would eventually everyone who runs a full node select a high but still reasonable (against such attacks) limit?

.. it would also be absolute freedom / anarchist/'market force'-based, so maybe it would appeal to that crowd?

EDIT: I mean, essentially, the whole block size hard limit and hard fork is a social thing. We all accept the code that is on github.com/bitcoin. But there is nothing preventing anyone from fiddling with this already - so if it would be unlimited with the clear option to fiddle - would it stabilize or would Bitcoin seperate into fighting fractions? For some reason, I believe people would still come to some kind of agreement, but would like to hear input from others.

EDIT #2: After a sufficient while and in case some people/miners start rejecting blocks with an arbitrary size cutoff, there should still be a chain that is the longest (has 51% of hashing power) and is therefore the gold standard. So isn't putting in a block size limit effectively saying: 'well, 51% is gold, but not quite, because it must be <1MiB, too'.

EDIT #3: Creating uncertainty in 'what the right Bitcoin is' would be IMO the most effective way to attack Bitcoin right now. Maybe something to ponder about. And I hereby out myself as a supporter of Gavin's 20MiB proposal. (I actually liked his original growth formula even better)

[–]cbeast 0 ポイント1 ポイント  (0子コメント)

Bitcoins will be a useful currency, but will only be a small fraction of the overall cryptoconomy.

[–]petertoddPeter Todd - Bitcoin Expert -1 ポイント0 ポイント  (2子コメント)

Well you are right, in a sense: if Bitcoin is almost completely broken then my analysis doesn't apply.

[–]cbeast 4 ポイント5 ポイント  (0子コメント)

It's not that it will be broken, but block rewards will not be significant compared to the metadata they protect.