Topic: So who the hell is still supporting BU? - page 26. (Read 29824 times)
Isn't it funny how BU is gaining more popularity each day? makes this thread title ironic.
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.
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. 
Segwit is required to fixing the quadratic hashing problem
Red herring.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:The issue solves itself. Today. No change needed.
BU or not is a completely orthogonal consideration.
Quote
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.
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'.
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.
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? The issue solves itself. Today. No change needed.
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.
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. 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.
On the other side, BU is speculating on this "emergent consensus" pseudo-science.
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 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)
Quote
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.
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 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)
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
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.
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.
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.
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.
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). 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.
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.
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?
Can anybody explain me what is BU? I have no idea and it's sounds mysterious to me all this talk, but I would like to know.
https://www.bitcoinunlimited.info/https://www.bitcoinunlimited.info/faq
Can anybody explain me what is BU? I have no idea and it's sounds mysterious to me all this talk, but I would like to know.