The real disastor that could happen (forking Bitcoin)...

[SebastianJu]

..Because a blocksize increase means faster and more frequent transactions and faster confirmations.

Actually you only misunderstood him. He meant that a transaction will receive confirmations faster, blocks won't be found faster then. But a transaction will most probably be implemented in the next block. So his sentence is fine.

[Jet Cash]

..Because a blocksize increase means faster and more frequent transactions and faster confirmations.

Actually you only misunderstood him. He meant that a transaction will receive confirmations faster, blocks won't be found faster then. But a transaction will most probably be implemented in the next block. So his sentence is fine.

Doesn't this apply to SegWit as well?

[CIYAM]

Doesn't this apply to SegWit as well?

If you mean that the tx capacity should increase by around twofold then yes.

[figmentofmyass]

what is with this new obsession with "democracy?" did gavin write a new blog about how bitcoin is supposed to be a "democracy" or something?

[Amph]

Who the fuck is this classic shit?

Is sounds to me like some bad commercial!

it's an hard fork for the 2mb capacity incrase nothing else

we have two side here, those that want to hard fork no matter what and those that want a soft fork

but the result is basically the same, capacity must increase all the other shit does not matter

[SebastianJu]

I think they need only to check if the coins reached on the deposit address on both chains. Then these coins are safe. It doesn't matter then which chain will win since they have the bitcoins on both chains.

Huh?

You are not making sense. An exchange is going to on one fork or the other (not both unless they want to be giving away fiat).

If your exchange decides on Fork A and then Fork B finally wins out then that exchange will go "belly up" (as all the coins it has had deposited would be unsalable).

You are right, they will chose one chain. But that doesn't say that they can check incoming deposits against the deposit on the other chain. When they received the bitcoins not only on their chosen chain but on the fork too then they can accept that deposit because it is riskless.

Why should they not monitor the other chain and instead close down completely? That makes no sense businesswise.

[CIYAM]

You are right, they will chose one chain. But that doesn't say that they can check incoming deposits against the deposit on the other chain. When they received the bitcoins not only on their chosen chain but on the fork too then they can accept that deposit because it is riskless.

Why should they not monitor the other chain and instead close down completely? That makes no sense businesswise.

You are talking nonsense (again) - if you accept coins that end up being on a failed fork then you cannot spend them. Got it?

So if I am exchange A and I accept coins on Fork A and am giving someone fiat for those coins then I've already spent the fiat and end up becoming a bag-holder of a useless alt.

Now tell me why any business is going to take on such a risk?

[figmentofmyass]

Who the fuck is this classic shit?

Is sounds to me like some bad commercial!

it's an hard fork for the 2mb capacity incrase nothing else

we have two side here, those that want to hard fork no matter what and those that want a soft fork

but the result is basically the same, capacity must increase all the other shit does not matter

of course it does. that's what this is all about. whether capacity can increase before the system is more scalable. i am reminded of children in the back seat screaming "ARE WE THERE YET?!??!?!?!"

decentralization > increased capacity. always.

otherwise wtf is it all for? if bandwidth bottlenecks continue crippling node health as block size increases -- and we know this happens because that is the historical trend -- how much is too much? eventually, your transactions are censorable.

so yes, all the other shit matters. the fact that SegWit offers a capacity increase in the interim while weak blocks/IBLTs are worked on (which will reduce peak bandwidth requirements by 90%+ for full nodes)... makes this a no-brainer.

then we can talk about increasing block size limit -- when bandwidth loads for nodes are more sustainable.

[SebastianJu]

Fake bitcoin classic nodes would not be able to raise the percent of support since they aren't actual miners. At the end the amount of hashrates are mattering.

Hashers can throw their power behind a classic miner then later withdraw their hashing power.

What would be the sense of doing so? You can't send a reasonable amount of hashingpower to fake nodes just to try raising the hashrate, you would need to put real power into it. And you would only do this when you are sure that the fork wins. You can't fake hashrate like you seem to suggest. At the end it comes to the blocks that are found. And when a classic node miner has XX TH and spreads this hashpower around 10 fake nodes then on that chain there still would only be XX TH from that miner.

I think you mix the kind of vote the XT fans tried with actual votes by hashpower. It's not the same and the number of nodes decides nothing.

And when a fork happens then when support for this new system raises a high value which means everyone will switch then since it is very unlikely that they will drop again then.

As I've stated I don't think we are just dealing with sensible people making sensible decisions.

If Bitcoin Classic were to stick to the way that soft forks have so been done (95% before activation of the new feature) then all of this controversy would go away.

If the vast majority of people do want 2MB blocks then I don't see that 95% should be a problem (and for the record I don't really care if the blocks are 1MB or 2MB).

It might be that the problem is that one can foresee that there will always be more then 5% miners that categorically would block such a change. Which would make it impossible. On the other hand 75% is a strong sign of the will of the community, well miners aren't actually the community but comes near to it. And it's better to let the majority decide instead staying undecided.

At the end it doesn't matter. Sigwit might get taken over by the net realitively without problems, ln doesn't need a fork but i doubt it will be used very much. And at one point in time it is inevitable anyway to raise the blocksize. It's grinding some time, that's all.

[CIYAM]

Why should they not monitor the other chain and instead close down completely? That makes no sense businesswise.

You can't just watch as you are risking the loss of your fiat - so any sensible business is going to put up a sign like this:

"Sorry - no fiat withdrawals until the fork situation has been resolved."

[CIYAM]

Fake bitcoin classic nodes would not be able to raise the percent of support since they aren't actual miners. At the end the amount of hashrates are mattering.

Hashers can throw their power behind a classic miner then later withdraw their hashing power.

What would be the sense of doing so? You can't send a reasonable amount of hashingpower to fake nodes just to try raising the hashrate, you would need to put real power into it. And you would only do this when you are sure that the fork wins. You can't fake hashrate like you seem to suggest.

I am not talking about "faking hashrate" I am talking about a planned attack with real hashrate.

The motivation for such an attack would be financial (i.e. spend your BTC twice or convert it to fiat twice if exchanges end up on different forks).

[Jet Cash]

Why should they not monitor the other chain and instead close down completely? That makes no sense businesswise.

You can't just watch as you are risking the loss of your fiat - so any sensible business is going to put up a sign like this:

"Sorry - no fiat withdrawals until the fork situation has been resolved."

I did this before I read your post.

OK, so I'm only buying Satoshis, and I'm only a small node operator, but there must be many others who are starting to think like this.

[SebastianJu]

Bitcoin is not a democracy (have you not even read Satoshi's paper?).

Satoshi said 1 vote per CPU (not 1 vote per person) so surely you can understand that one person can have more than one CPU?

Yes, in this sense it is not a democracy... maybe a technocrazy... cpu's are voting... So at the end the wealthy has more power. Was inevitable. But still it is some kind of decision finding. And the strongest wins because he can.

[marky89]

Bitcoin is not a democracy (have you not even read Satoshi's paper?).

Satoshi said 1 vote per CPU (not 1 vote per person) so surely you can understand that one person can have more than one CPU?

Yes, in this sense it is not a democracy... maybe a technocrazy... cpu's are voting... So at the end the wealthy has more power. Was inevitable. But still it is some kind of decision finding. And the strongest wins because he can.

Uhhh, shouldn't the best code win?

Perhaps then, we should leave development as it should be -- meritocratic. Not based on a Reddit/Twitter political campaign.

You better hope miners don't support the mob rule Classic approach....because if this tiny minority of developers is to replace Core....it will be very dark days ahead for bitcoin.

[SebastianJu]

I don't see why it is fine for you to run a softfork that activates after 75% of the hashpower is using it or a hard fork that goes life after similar thresholds. Double standards? It would still show that the majority supports something.

All soft forks so far have only been enforced after a 95% threshold (and this will apply with SegWit as well).

The only people trying to push for a 75% hard-fork are Bitcoin Classic, Bitcoin Unlimited and Bitcoin XT (the latter being now defunct).

Yeah, though the chances are not fair if you think about it. 75% is the majority of hashpower for sure. That's the first point. Then they can do it.

The otherside will make segwit come with higher threshold and lightning network without decision finding.

The problem is that the core developers block the raising of the blocklimit and they can enforce it. So in fact they force all the rest of the community to follow the way they want it to be. I think they can not complain about classic doing a similar thing. Classic at least would know the majority behind themself at that point. Coredevs don't really care about such decision.

In order to allow a decision there is no other way than to present an alternative. So at the end coredevs complain about the possibility to vote. They decided for themselves and for all to not raise the blocksizelimit. Everyone had to follow. Force. Now a way to find the opinion of the community was found and they complain about that happening since they already did their decision for us all.

No, i think the worse enforcer are the core devs. Deciding for everyone without giving a choice and when someone creates a choice then he wants to break everything in their eyes.

[SebastianJu]

..Because a blocksize increase means faster and more frequent transactions and faster confirmations.

Actually you only misunderstood him. He meant that a transaction will receive confirmations faster, blocks won't be found faster then. But a transaction will most probably be implemented in the next block. So his sentence is fine.

Doesn't this apply to SegWit as well?

Yes i think so. Though Lauda wrote like the author of that sentence was so stupid to think that the confirmation time (the 10 minutes) will be lower. At least i interpreted it so since the sentence otherwise would be fine.

[CIYAM]

No, i think the worse enforcer are the core devs. Deciding for everyone without giving a choice and when someone creates a choice then he wants to break everything in their eyes.

It isn't up to the core devs at all (remember it is about CPUs or more specifically ASICS voting?).

Quite likely the core devs will decide to simply accept 2MB if the fork risk is looking very likely (as they are not the ones trying to wreck things here) but I would pretty much guarantee that with in a month or two after that Gavin will be back with something that has 4MB (with another hard-fork threat).

[SebastianJu]

You are right, they will chose one chain. But that doesn't say that they can check incoming deposits against the deposit on the other chain. When they received the bitcoins not only on their chosen chain but on the fork too then they can accept that deposit because it is riskless.

Why should they not monitor the other chain and instead close down completely? That makes no sense businesswise.

You are talking nonsense (again) - if you accept coins that end up being on a failed fork then you cannot spend them. Got it?

So if I am exchange A and I accept coins on Fork A and am giving someone fiat for those coins then I've already spent the fiat and end up becoming a bag-holder of a useless alt.

Now tell me why any business is going to take on such a risk?

You write as if this exchange wouldn't own the same address on the other chain then too. But they would ideally. Well, probably depends on the way their wallet creates addresses. Core might be not good if i remember correctly.

But let's assume they own the same deposit address on both chains. Then it would not matter if they receive the coins on both chains and the chain they used on their exchange suddenly dies. They still would have the coins on the other chain. Nothing would be lost.

I hope you got now what i meant.

[CIYAM]

You write as if this exchange wouldn't own the same address on the other chain then too. But they would ideally. Well, probably depends on the way their wallet creates addresses. Core might be not good if i remember correctly.

No - you can't do this - the person who is sending you (being the exchange) has the private key for those UTXOs (not you the exchange).

So it is within their potential ability to "double-spend" (not you the exchange).

Clear yet?

(why do I get the feeling you don't even know what UTXOs are)

[Lauda]

Doesn't this apply to SegWit as well?

This doesn't apply to anything and is a ignorant statement. The average confirmation time for normal transactions stays the same regardless of remaining capacity in the block. The blocks right now are rarely full and the only transactions that don't get confirmed are those that don't have a proper fee. The situation would be the same at 2 MB with occasionally full blocks.

Uhhh, shouldn't the best code win?

Perhaps then, we should leave development as it should be -- meritocratic. Not based on a Reddit/Twitter political campaign.

You better hope miners don't support the mob rule Classic approach....because if this tiny minority of developers is to replace Core....it will be very dark days ahead for bitcoin.

If people weren't ignorant and playing politics around here it would be that way. Look at all the developments that Core developers have made, now look at the Classic developers and tell me what they've created? Nothing. Toomin's plan is to copy things from Core.