So who the hell is still supporting BU?

[classicsucks]

And you don't see a problem with that? Isn't bitcoin supposed to be more open than that?

Don't get it twisted, what im saying with Core calling the shoots means that they are still the number 1 coders doing all the hard work.

Most BU people are trolls and the software is not as good in any case.

I'm sad to say that I now support and run BU. Core doesn't call the shots anymore because their last few releases aren't being adopted.

Core IS the number one dev team by miles, but they are stubbornly clinging to the poorly supported, overcomplicated, and likely failed Segwit solution, and they are not listening to the miners or the critics. Running BU is the only way to communicate to them that Segwit needs to go away. Meantime, Ver and his team will gain more steam with BU because Core has buried their heads in the sand. Likely we'll be at a deadlock for 6 months+. I think when BU passes Segwit hashrate we might see some debate or compromise proposals. I've already heard talk of merging Segwit with larger block support.

Miners currently benefit from small blocks because fees keep climbing. Anyone who has waited 2 days for their transaction to confirm knows the horrible feeling that is ironically similar to getting your Paypal account banned.  At some point when BTC fees are too high and/or transaction times are unacceptably high, more people will switch to an altcoin like Monero, which has better anonimity than Bitcoin anyway. Bitcoin is running on inertia with name recognition, exchange support, and Wall Street money.

I would be truly saddened if Bitcoin faded into obscurity due to this conflict.

So you think Andreas Antonopulos is wrong? (someone who is always neutral and is learning about bitcoin stuff 24/7)

Get real, the only thing not tested here and proven to fail is BU. If BU gets anywhere notably we are fucked. Segwit is safe compared to BU. BU depends on Core's hard work, if Core stopped updating their software, BU wouldn't have anywhere to rip off and copy and paste code from, it would be the end.

Here is Andreas explaining why segwit is the way to go:


https://medium.com/segwit-co/segregated-witness-and-aligning-economic-incentives-with-resource-costs-7d987b135c00#.yrq6jipqg

Andreas is super smart and I almost always agree with him. In this case, I think he's being a Segwit fanboy. Also he's prone to rooting for the over-complicated solution because he is a geek.

I never said BU is perfect. In fact, it sucks a bit, but not nearly as much as XT and classic. However, I'll keep running BU until core or their replacement increase the blocksize.

Do you really want to go through this 2 years of blocksize increase drama every 5 years?

[1715182242]

1715182242

[jbreher]

Do you really want to go through this 2 years of blocksize increase drama every 5 years?

The problem is that, if we are only doubling asst each iteration, we won't have two years each cycle. So we'll need to endure two years of drama every year. Dramaception.

[BillyBobZorton]

And you don't see a problem with that? Isn't bitcoin supposed to be more open than that?

Don't get it twisted, what im saying with Core calling the shoots means that they are still the number 1 coders doing all the hard work.

Most BU people are trolls and the software is not as good in any case.

I'm sad to say that I now support and run BU. Core doesn't call the shots anymore because their last few releases aren't being adopted.

Core IS the number one dev team by miles, but they are stubbornly clinging to the poorly supported, overcomplicated, and likely failed Segwit solution, and they are not listening to the miners or the critics. Running BU is the only way to communicate to them that Segwit needs to go away. Meantime, Ver and his team will gain more steam with BU because Core has buried their heads in the sand. Likely we'll be at a deadlock for 6 months+. I think when BU passes Segwit hashrate we might see some debate or compromise proposals. I've already heard talk of merging Segwit with larger block support.

Miners currently benefit from small blocks because fees keep climbing. Anyone who has waited 2 days for their transaction to confirm knows the horrible feeling that is ironically similar to getting your Paypal account banned.  At some point when BTC fees are too high and/or transaction times are unacceptably high, more people will switch to an altcoin like Monero, which has better anonimity than Bitcoin anyway. Bitcoin is running on inertia with name recognition, exchange support, and Wall Street money.

I would be truly saddened if Bitcoin faded into obscurity due to this conflict.

So you think Andreas Antonopulos is wrong? (someone who is always neutral and is learning about bitcoin stuff 24/7)

Get real, the only thing not tested here and proven to fail is BU. If BU gets anywhere notably we are fucked. Segwit is safe compared to BU. BU depends on Core's hard work, if Core stopped updating their software, BU wouldn't have anywhere to rip off and copy and paste code from, it would be the end.

Here is Andreas explaining why segwit is the way to go:


https://medium.com/segwit-co/segregated-witness-and-aligning-economic-incentives-with-resource-costs-7d987b135c00#.yrq6jipqg

Andreas is super smart and I almost always agree with him. In this case, I think he's being a Segwit fanboy. Also he's prone to rooting for the over-complicated solution because he is a geek.

I never said BU is perfect. In fact, it sucks a bit, but not nearly as much as XT and classic. However, I'll keep running BU until core or their replacement increase the blocksize.

Do you really want to go through this 2 years of blocksize increase drama every 5 years?

We'll have a blocksize increase after segwit. It's not Core's fault that miners are fucking stupid and are not signaling for segwit as soon as possible. Segwit is needed before we increase the blocksize.

[Lauda]

We'll have a blocksize increase after segwit. It's not Core's fault that miners are fucking stupid and are not signaling for segwit as soon as possible. Segwit is needed before we increase the blocksize.

Segwit provides a blocksize increase. Putting that aside, I would welcome a properly written HF proposal that builds upon Segwit. However, I would not be willing to accept something that reduces the block size limit (as proposed recently by luke-jr).

[Carlton Banks]

We'll have a blocksize increase after segwit. It's not Core's fault that miners are fucking stupid and are not signaling for segwit as soon as possible. Segwit is needed before we increase the blocksize.

It wouldn't actually be a good idea to activate Segwit now from the miners perspective, or even proponents of Segwit. Segwit ready nodes are just about 50% of the network now, and there's too high a risk that a Segwit block generated today would not propagate around the Bitcoin network sufficiently well with only 50% of nodes capable to relay the Witness data (i.e. the extra 3MB of blockspace that would be available).

To put it another way, an attacker might try to exploit this effect by amplifying it somehow. That could mean network disruption serious enough to start attributing blame to the design approach of Segwit, when in fact it was caused by careless rollout.

I'm not sure what percentage of Segwit nodes major miners would deem safe, but it's a reasonable assumption that it's > 50%.

Segwit provides a blocksize increase. Putting that aside, I would welcome a properly written HF proposal that builds upon Segwit. However, I would not be willing to accept something that reduces the block size limit (as proposed recently by luke-jr).

That's not a very good description of what Luke's (latest) Hard Fork plan actually is; the blocksize limit depends on absolute blockheights in his proposal, and so whether or not the blocks are bigger than 1MB or smaller depends on when the fork is activated.

If that hard fork activated tomorrow, we'd have 300 KB blocks. But that's very unlikely to actually happen. By the time a fork proposal like that activated, it could easily have reached the stage of progress where the blocksize is bigger than 1MB (I think Luke is using the 17% per year "technological growth" factor that Pieter Wuille did in BIP103)

Don't get me wrong, I'm not totally convinced myself, Luke's ideas are often a little eccentric superficially. But let's not forget that he's contributed useful stuff that wasn't considered too "out there", not least a soft-fork for Segwit, which not everyone thought was possible beforehand.

[hv_]

We'll have a blocksize increase after segwit. It's not Core's fault that miners are fucking stupid and are not signaling for segwit as soon as possible. Segwit is needed before we increase the blocksize.

Segwit provides a blocksize increase. Putting that aside, I would welcome a properly written HF proposal that builds upon Segwit. However, I would not be willing to accept something that reduces the block size limit (as proposed recently by luke-jr).

If you want a block size increase for all  ( I suppose ) , you do not need compli seg wit (might work for a few).

Agreed (?), we need this increase - so let's do this first ... yes HF is needed to remove artificial legacy code of 1MB  anyway.

If seg wit is part of this HF - I  m fine.

[BillyBobZorton]

We'll have a blocksize increase after segwit. It's not Core's fault that miners are fucking stupid and are not signaling for segwit as soon as possible. Segwit is needed before we increase the blocksize.

Segwit provides a blocksize increase. Putting that aside, I would welcome a properly written HF proposal that builds upon Segwit. However, I would not be willing to accept something that reduces the block size limit (as proposed recently by luke-jr).

Luke-JR is the only guy in Core that does not want to raise the blocksize. He is free to propose a smaller one, it will never happen since that would cause a major shitstorm.

Im pretty sure the rest of the Core team is okay with raising to 2MB after segwit is implemented, so we must get segwit going. It's funny that the same idiots that are complaining about lack of blocksize increase are blocking segwit and by doing so blocking any real chances of a blocksize increase.

[Carlton Banks]

Im pretty sure the rest of the Core team is okay with raising to 2MB after segwit is implemented, so we must get segwit going.

Part of Luke's rationale for reducing the blocksize (in the medium term) is that Lightning will be available before any hard fork anyway.

His expectation is that Lightning might prove that 1MB is too large, if enough transaction capacity is transferred to the Lightning layer. That doesn't sound implausible to me, but neither does a 2MB blocksize (not now, but in the next 2 years, say). We'll have to wait and see how well Lightning delivers to know.

[Lauda]

That's not a very good description of what Luke's (latest) Hard Fork plan actually is; the blocksize limit depends on absolute blockheights in his proposal, and so whether or not the blocks are bigger than 1MB or smaller depends on when the fork is activated.

If that hard fork activated tomorrow, we'd have 300 KB blocks. But that's very unlikely to actually happen. By the time a fork proposal like that activated, it could easily have reached the stage of progress where the blocksize is bigger than 1MB (I think Luke is using the 17% per year "technological growth" factor that Pieter Wuille did in BIP103)

I think it's a fair description of what it is. It initially lowers the block size, which is exactly what I wrote. Take a look here:

if in 2018 January, it would begin at ~356k; or if in 2024 June, it would begin at just over 1 MB.

Block size is only going above 1 MB in 2024 with his proposal.[1]

If you want a block size increase for all  ( I suppose ) , you do not need compli seg wit (might work for a few).

Segwit is required to fixing the quadratic hashing problem in this aspect. It comes with plenty of other benefits as well.

Im pretty sure the rest of the Core team is okay with raising to 2MB after segwit is implemented, so we must get segwit going. It's funny that the same idiots that are complaining about lack of blocksize increase are blocking segwit and by doing so blocking any real chances of a blocksize increase.

The problem is that there is no hard fork proposal that does this. Someone should create one that builds on Segwit and raises the block size by a certain amount.
[1] - https://github.com/luke-jr/bips/blob/bip-blksize/bip-blksize.mediawiki

[Carlton Banks]

That's not a very good description of what Luke's (latest) Hard Fork plan actually is; the blocksize limit depends on absolute blockheights in his proposal, and so whether or not the blocks are bigger than 1MB or smaller depends on when the fork is activated.

If that hard fork activated tomorrow, we'd have 300 KB blocks. But that's very unlikely to actually happen. By the time a fork proposal like that activated, it could easily have reached the stage of progress where the blocksize is bigger than 1MB (I think Luke is using the 17% per year "technological growth" factor that Pieter Wuille did in BIP103)

I think it's a fair description of what it is. It initially lowers the block size, which is exactly what I wrote. Take a look here:

if in 2018 January, it would begin at ~356k; or if in 2024 June, it would begin at just over 1 MB.

Block size is only going above 1 MB in 2024 with his proposal.[1]

Yes, and under that proposal, the 1MB limit can remain until Lightning begins to soak up some transactions. You can't make a real case for 2MB until the true capacity of operational Lightning is observed in the real world, I think that's reasonable.

Why increase the 1MB size if blocks became more empty than they are now after Lightning is available? I think most sensible people in cryptocurrencies recognise that full blocks are an important requirement for getting the miner/user incentives properly aligned for establishing fees.

[Lauda]

Yes, and under that proposal, the 1MB limit can remain until Lightning begins to soak up some transactions. You can't make a real case for 2MB until the true capacity of operational Lightning is observed in the real world, I think that's reasonable.

Why increase the 1MB size if blocks became more empty than they are now after Lightning is available? I think most sensible people in cryptocurrencies recognise that full blocks are an important requirement for getting the miner/user incentives properly aligned for establishing fees.

I do not like speculating like this on important issue. There is no way to tell exactly how much of the TX volume LN would acquire in a week, month, in a year. On-chain scalability should not be based on speculative patterns but rather past patterns (e.g. once there is a history of LN usage, then factor that in as well). Besides, LN is not a close reality yet. It's currently being tested, and it doesn't even have a GUI (from what I've seen). It's far from being part of the main-net and even further away from being consumer friendly.
On the other side, BU is speculating on this "emergent consensus" pseudo-science.

[jbreher]

Segwit is required to fixing the quadratic hashing problem

Red herring. There is no quadratic hashing problem. There is a quadratic hashing aspect, this is true. However, as it stands today (i.e., with no changes to the protocol), mining incentives are such as to render it a non-problem.

Miners will either abandon calculating hashes of such blocks, or they will be bankrupted by other miners who do.

The issue solves itself. Today. No change needed.

[Lauda]

Segwit is required to fixing the quadratic hashing problem

Red herring.

Nonsense. This is improper usage of logical fallacies. The user mentioned Segwit. Mentioning what Segwit aims to fix is not a diversion of the subject.

There is no quadratic hashing problem. There is a quadratic hashing aspect, this is true.

It is a problem, you can put your useless 'semantics' somewhere else.

However, as it stands today (i.e., with no changes to the protocol), mining incentives are such as to render it a non-problem.

You mean, the same miners who use the safe *cough* SPV mining?

Miners will either abandon calculating hashes of such blocks, or they will be bankrupted by other miners who do.

The issue solves itself. Today. No change needed.

This just shows how delusional BU is: You are leaving an attack vector open in hopes that everyone plays nicely?

[jbreher]

Why increase the 1MB size if blocks ... now after Lightning is available?

If use of lightning was already routine, your rhetorical question might have some value. Alas, a lightning usable by end users is still but a pipe dream.

Why increase the 1MB size if blocks became more empty than they are now after Lightning is available?

With average blocks in the 85%+ of capacity range, you've got a pathological interpretation of 'empty'.

[jbreher]

Segwit is required to fixing the quadratic hashing problem

Red herring.

Nonsense. This is improper usage of logical fallacies. The user mentioned Segwit. Mentioning what Segwit aims to fix is not a diversion of the subject.

Sorry. I meant the entire consideration of the quadratic hashing aspect is a red herring. In the broader 'what is good for bitcoin' context.

There is no quadratic hashing problem. There is a quadratic hashing aspect, this is true.

It is a problem, you can put your useless 'semantics' somewhere else.

I don't know what you are trying to accomplish, babbling about 'semantics'. I'll say it again: mining incentives are already aligned such to ensure that the quadratic hashing aspect is a non-problem.

However, as it stands today (i.e., with no changes to the protocol), mining incentives are such as to render it a non-problem.

You mean, the same miners who use the safe *cough* SPV mining?

No. And yes. I mean each and every rational miner.

Miners will either abandon calculating hashes of such blocks, or they will be bankrupted by other miners who do.

The issue solves itself. Today. No change needed.

This just shows how delusional BU is:

BU or not is a completely orthogonal consideration.

You are leaving an attack vector open in hopes that everyone plays nicely?

No.

I see you are incapable of arguing your position, relying upon simple unsupported rebuttal to make your case. Not my issue that you can't seem to reason yourself out of a paper bag. Too bad, so sad.

[Lauda]

Alas, a lightning usable by end users is still but a pipe dream.

Calling it a 'pipe dream' is an exaggeration considering the successful testing that is happening on testnet.

I see you are incapable off arguing your position, relying upon simple unsupported rebuttal to make your case. Not my issue that you can't seem to reason yourself out of a paper bag. Too bad, so sad.

Standard BU and r/btc tactic. Once you're out of words, attack the character. Quite shameful. No wonder that the majority dislikes it.

[jbreher]

Alas, a lightning usable by end users is still but a pipe dream.

Calling it a 'pipe dream' is an exaggeration considering the successful testing that is happening on testnet.

How is that decentralized efficient routing design shaping up? About done yet?

I see you are incapable off arguing your position, relying upon simple unsupported rebuttal to make your case. Not my issue that you can't seem to reason yourself out of a paper bag. Too bad, so sad.

Standard BU and r/btc tactic. Once you're out of words, attack the character.

I'm not attacking your character. I am merely pointing out that your reply was non-responsive.

[RawDog]

Isn't it funny how BU is gaining more popularity each day?  makes this thread title ironic.

[Carlton Banks]

There is no way to tell exactly how much of the TX volume LN would acquire in a week, month, in a year. On-chain scalability should not be based on speculative patterns but rather past patterns (e.g. once there is a history of LN usage, then factor that in as well).

Yes. But you're not disagreeing with me, that's what I said too: wait until Lightning has some reliable medium term stats before we start deciding that 1MB, 2MB or anything else is needed. How can you know before Lightning is established?

Besides, LN is not a close reality yet. It's currently being tested, and it doesn't even have a GUI (from what I've seen). It's far from being part of the main-net and even further away from being consumer friendly.

Further away than a successful (planned) hard-fork? Not sure about that.

[franky1]

Im pretty sure the rest of the Core team is okay with raising to 2MB after segwit is implemented, so we must get segwit going. It's funny that the same idiots that are complaining about lack of blocksize increase are blocking segwit and by doing so blocking any real chances of a blocksize increase.

segwit is not actually a 2mb blocksize.

its a effective one time boost which .. wait for it..
IF EVERYONE moved their funds over to P2WPKH /P2wSH keys.. then statistically there would be around 2.1x transactions(2.1mb) MAXIMUM expectation.
but you cant re-segwit a segwit to double again... its a one time max potential..

and right now knowing only 50% have segwit nodes... and half of that wait 3-6months before upgrading to latest software
would mean
once activated, there is a lul period*. after that when the full segwit wallet version is available only 25% would move to the version with P2WPKH/P2PSH key wallets included within 3-6months. so only assume 1.25mb blocksize effectively..  

then after that only assume 1.5mb blocksize effectively.. due to only half the network with segwit nodes that would have caught up with upgrading.
so at best, based on the node count stats of now as reference, even upto a year after activation. only expect 1.5x transactions (1.5mb) and then some iffy time period if or when there may or may not be 100% utility of p2Wpkh.p2WSH keys to get to the 2.1x(2mb) maxim

*even core themselves have stated even if pools got to 95% and activated.. core wont release the full segwit (including p2wPKH/p2wSH key generation) node for atleast a few weeks or long AFTER activation..
so dont expect to see anything actually change any time soon


the funny part. if they went with hard(meaning nodes first, then pools) consensus(meaning meaning agreement not split)  the nodes would be ready sooner, the pools would gain confidence nodes could handle it. and they would be ready sooner. and the possibility that after activation nodes would then download the full version with P2W wallets active, would be possibly higher. to get even closer to the 2.1mb maxim hope..

but that 2.1mb maxim is a best possible.. and unrepeatable boost. so dont bet any funds on it actually occuring... much like dont expect toput a bet on that bitcoin could actually achieve 7tx/s between 2009/2016.. if you time travelled back to 2009.. even if 'expectations' say it was possible.