Well, I've been a Segwit supporter for a while now but...

[franky1]

There's nothing anyone can do to stop the mempool filling up in an unsustainable way, all you need is just 1 Bitcoin output, and you can send the same output again and again and again from one address to the next ad infinitum, totally spamming the mempool.

lol face palm ... really??

pseudocode:
if parent.output = unconfirmed then
      child.tx = drop from mempool
end if

i know no one wants to do that because that then ruins the CPFP features.. but when CPFP can also be used maliciously for other attacks we shouldnt really have that stuff in there.

[1715477726]

1715477726

[1715477726]

1715477726

[1715477726]

1715477726

[1715477726]

1715477726

[1715477726]

1715477726

[Ucy]

Thought this problem has been settled already & September is the date to activate the segwit thing?
Please you all should consider the HUGH impression this is leaving on new Crypto users. Many would likely never comeback after their first sad experience.  
If this will take lots of money to fix am ready to donate half of what I have earned so far from Crypto.

This shld be time for big sacrifice not the time to make money or be greedy

[cellard]

Where's the effort to compromise? Sorry, but capacity is getting too high. A revamp of the HK agreement would be nice, but now I'm even leaning toward segwit+2mb proposal since core/blockstream aren't willing to budge or talk (AFAIK), or perhaps even thinking blocksize increase sans Segwit is the best way to go. This impasse is ridiculous and unnecessary. I used to think small blocks were better but after doing plenty of research I found out that the risks are way overstated. Imagine we could have bitcoin with big blocks and soon with RSK and sidechains Bitcoin will be incredible.

The HK agreement was to activate segwit, then a hard fork to 2MB later on, considering that Core CAN NOT guarantee a hard fork because guess what, Core doesn't control bitcoin so it CAN NOT guarantee a HF (it depends on global community consensus).

It's the miners that broke the agreement by not supporting segwit, specially bitmain because segwit kills covert ASICBOOST (so now it's clear why they don't want a softfork for segwit).

They will either activate it or we users will with UASF.

[CoinCube]

The lack of code is probably a good thing at this juncture. I have been following this dispute only recently but the strong impression I get is that the only possible path to consensus on something like the miner agreement is if the code is ultimately produced and vetted and shipped by the core developers.

The miner agreement at this stage is simply a proposal. That proposal must now be vetted by the rest of the community to determine if a grudging consensus can be built around it.

Hopefully such a consensus will be possible. It strikes me as a far healthier path forward then stagnation forever in the current state or a civil war leading to a split into two coins.

That sounds good in principle but alas the miner agreement does a lot wrong that core can't condone. If they were to run with core's segwit implementation and a 2MB hard fork it would be different (as already proposed on the mailing list), but the agreement goes to great pains to say that segwit will be on a different bit implementation and be activated concurrently with a hardfork. Core can't agree to something that undoes the existing implementation which won't expire till November to adopt their more radical approach. If core agrees to do segwit followed by 2MB HF, it has to be with their existing implementation or they lose the next 6 months' opportunity to activate the heavily tested prepared segwit component already. The mining consortium has to ease their stance to meet them or we do nothing for another 6 months again or fork galore or risk an outside provided code base to work off. BU proved that's not a safe option with their incredibly unstable implementation of just one feature. The miner agreement is one by people who appear to not even know what they're agreeing to and ignores - or doesn't understand - what is realistically doable in a safe manner. The halfway point is core agreeing to their current segwit implementation AND a 2MB base blocksize hard fork that they implement - it's my gut feeling that's what we'll end up with but there needs to be a lot of rhetoric, chest thumping and circle jerking in the interim.

As a member of the community who is totally uninvolved in either mining or development but who nevertheless has a substantial interest in bitcoin I kindly request the all parties commence immediately with the necessary chest thumping so we can move on to the halfway point bolded above.

[25hashcoin]

The lack of code is probably a good thing at this juncture. I have been following this dispute only recently but the strong impression I get is that the only possible path to consensus on something like the miner agreement is if the code is ultimately produced and vetted and shipped by the core developers.

The miner agreement at this stage is simply a proposal. That proposal must now be vetted by the rest of the community to determine if a grudging consensus can be built around it.

Hopefully such a consensus will be possible. It strikes me as a far healthier path forward then stagnation forever in the current state or a civil war leading to a split into two coins.

That sounds good in principle but alas the miner agreement does a lot wrong that core can't condone. If they were to run with core's segwit implementation and a 2MB hard fork it would be different (as already proposed on the mailing list), but the agreement goes to great pains to say that segwit will be on a different bit implementation and be activated concurrently with a hardfork. Core can't agree to something that undoes the existing implementation which won't expire till November to adopt their more radical approach. If core agrees to do segwit followed by 2MB HF, it has to be with their existing implementation or they lose the next 6 months' opportunity to activate the heavily tested prepared segwit component already. The mining consortium has to ease their stance to meet them or we do nothing for another 6 months again or fork galore or risk an outside provided code base to work off. BU proved that's not a safe option with their incredibly unstable implementation of just one feature. The miner agreement is one by people who appear to not even know what they're agreeing to and ignores - or doesn't understand - what is realistically doable in a safe manner. The halfway point is core agreeing to their current segwit implementation AND a 2MB base blocksize hard fork that they implement - it's my gut feeling that's what we'll end up with but there needs to be a lot of rhetoric, chest thumping and circle jerking in the interim.

As a member of the community who is totally uninvolved in either mining or development but who nevertheless has a substantial interest in bitcoin I kindly request the all parties commence immediately with the necessary chest thumping so we can move on to the halfway point bolded above.

Except Core is unwilling to compromise. It must be said...they are single handedly the ones responsible for bitcoins lack of scalability.

[25hashcoin]

Where's the effort to compromise? Sorry, but capacity is getting too high. A revamp of the HK agreement would be nice, but now I'm even leaning toward segwit+2mb proposal since core/blockstream aren't willing to budge or talk (AFAIK), or perhaps even thinking blocksize increase sans Segwit is the best way to go. This impasse is ridiculous and unnecessary. I used to think small blocks were better but after doing plenty of research I found out that the risks are way overstated. Imagine we could have bitcoin with big blocks and soon with RSK and sidechains Bitcoin will be incredible.

The HK agreement was to activate segwit, then a hard fork to 2MB later on, considering that Core CAN NOT guarantee a hard fork because guess what, Core doesn't control bitcoin so it CAN NOT guarantee a HF (it depends on global community consensus).

It's the miners that broke the agreement by not supporting segwit, specially bitmain because segwit kills covert ASICBOOST (so now it's clear why they don't want a softfork for segwit).

They will either activate it or we users will with UASF.

Complete lies. If Core supported a 2mb hardfork we would have segwit and larger blocks. What Core did was sign the agreement knowing ahead of time that they would try to pawn off Segwit as 2mb. When people saw right through this, those Core devs that signed pulled out and turned back to strangling scaling if they don't get their way. It's beyond ridiculous to say "our way or no way" in a decentralized system. Core will compromise or get forked out to their own blockstream coin.

[cjmoles]

None of this makes any sense!  Might the community be just as culpable for this stalemate as the developer teams?  It seems that lower fees and faster transactions times would better suite a wider cross section of the community, right?  What's really going on here...too many alternative facts?  What proposal will help lower fees and increase transaction speeds?  I can't even get a cup of coffee anymore, dammit!

[creative~mind]

I'm sure that the amount of transactions has greatly increased in recent months, but would anyone have an estimate of how much of this is spam? Are the blocks really full, as some have been saying?

[SvenBomvolen]

Where's the effort to compromise? Sorry, but capacity is getting too high. A revamp of the HK agreement would be nice, but now I'm even leaning toward segwit+2mb proposal since core/blockstream aren't willing to budge or talk (AFAIK), or perhaps even thinking blocksize increase sans Segwit is the best way to go. This impasse is ridiculous and unnecessary. I used to think small blocks were better but after doing plenty of research I found out that the risks are way overstated. Imagine we could have bitcoin with big blocks and soon with RSK and sidechains Bitcoin will be incredible.

Maybe segwit is a compromise, but it is the best way to make bitcoin even faster. How to increase the number of blocks but still ensure the security of bitcoin? I think segwit is the only way.

We don't know what changes SegWit will bring while it will not come the truth. Today we can only suppose who'll it be good for bitcoin or it will not. I hope it will bring only positive changes, but with the time I can change my opinion.

[The One]

None of this makes any sense!  Might the community be just as culpable for this stalemate as the developer teams?  It seems that lower fees and faster transactions times would better suite a wider cross section of the community, right?  What's really going on here...too many alternative facts?  What proposal will help lower fees and increase transaction speeds?  I can't even get a cup of coffee anymore, dammit!

A pool may have 20,000 workers and perhaps 50 of those workers are here shrilling continuously for small blocks to defend their high fees. Why? They want their investments in hardware to be paid off asap before becoming out-of-date.

[BillyBobZorton]

SegWit is the compromise. It increases the block size to 4MB, for no other reason than that people kept asking for it. But it seems nobody actually wants the block size increase after all, and the big-blockers were all full of hot air. No matter. If SegWit fails to gain support in its current form, it can always be re-proposed without the controversial block size increase.

opposite is true...except for blockstream and bitfury and dcg...no one really wants segwit.

Good ol big blocker shill lies.

The poll done by 21 suggest that around 75% of big players in the space want segwit and the 70.5% reject Buggy Unlimited explicitly:




https://medium.com/@21/using-21-to-survey-blockchain-personalities-on-the-bitcoin-hard-fork-1953c9bcb8ed

Not to mention nobody but Roger Ver runs nodes.

So it's pretty obvious BU is in general a failure.

UASF is working, nobody is talking about BU anymore. We are now in the acceptance phase. Everyone knows segwit is going to activated, the question now is how.

The next step is for certain miners to accept segwit as a softfork to end the covert ASICBOOST exploit, if certain miners do not cooperate, UASF will keep going up.

Accept reality or get burned.

[freebrax]

SegWit is the compromise. It increases the block size to 4MB, for no other reason than that people kept asking for it. But it seems nobody actually wants the block size increase after all, and the big-blockers were all full of hot air. No matter. If SegWit fails to gain support in its current form, it can always be re-proposed without the controversial block size increase.

opposite is true...except for blockstream and bitfury and dcg...no one really wants segwit.

Good ol big blocker shill lies.

The poll done by 21 suggest that around 75% of big players in the space want segwit and the 70.5% reject Buggy Unlimited explicitly:


https://pbs.twimg.com/media/C8HwIp7VwAEGPBb.jpg

https://medium.com/@21/using-21-to-survey-blockchain-personalities-on-the-bitcoin-hard-fork-1953c9bcb8ed

Not to mention nobody but Roger Ver runs nodes.

So it's pretty obvious BU is in general a failure.

UASF is working, nobody is talking about BU anymore. We are now in the acceptance phase. Everyone knows segwit is going to activated, the question now is how.

The next step is for certain miners to accept segwit as a softfork to end the covert ASICBOOST exploit, if certain miners do not cooperate, UASF will keep going up.

Accept reality or get burned.

wow 61 random votes xd . why is this relevant for the comunity?

[TryNinja]

Good ol big blocker shill lies.

The poll done by 21 suggest that around 75% of big players in the space want segwit and the 70.5% reject Buggy Unlimited explicitly:


-img-

https://medium.com/@21/using-21-to-survey-blockchain-personalities-on-the-bitcoin-hard-fork-1953c9bcb8ed

Not to mention nobody but Roger Ver runs nodes.

So it's pretty obvious BU is in general a failure.

UASF is working, nobody is talking about BU anymore. We are now in the acceptance phase. Everyone knows segwit is going to activated, the question now is how.

The next step is for certain miners to accept segwit as a softfork to end the covert ASICBOOST exploit, if certain miners do not cooperate, UASF will keep going up.

Accept reality or get burned.

wow 61 random votes xd . why is this relevant for the comunity?

Rofl. Not just 61 randoms. This poll was targeted at experts and personalities from the Blockchain community. On the 21.co page itself, you can see some of the people who are part of the group where the poll was made. Do some work first before trying to spam for some posts count. https://21.co/blockchain/

Adam Back (CEO of Blockstream), Brian Armstrong (CEO of Coinbase), Nejc Kodric (CEO of Bitstamp), and others. Just some random folks right?

Btw, BillyBobZorton is right. Segwit is indeed the only right choice.

[Nagadota]

SegWit is the compromise. It increases the block size to 4MB, for no other reason than that people kept asking for it. But it seems nobody actually wants the block size increase after all, and the big-blockers were all full of hot air. No matter. If SegWit fails to gain support in its current form, it can always be re-proposed without the controversial block size increase.

opposite is true...except for blockstream and bitfury and dcg...no one really wants segwit.

Apart from [insert several major/influential groups], no one wants SegWit.  It's the same kind of logic as "apart from Bitmain, no one wants BU", when in fact the community support is harder to gauge.

[franky1]

....

oh billy. did you even look at the article

[BillyBobZorton]

....

oh billy. did you even look at the article

So fucking what. Did you actually look at this image?




Just because some people would also be ok with other ways to scale bitcoin, doesn't mean they are against segwit, because otherwise the numbers don't add up.

75% want segwit.

70% do not want segwit.

49% replied to a vague ass question where they support some sort of undefined scaling method (which does not mean they aren't in favor of segwit too)

Once again franky1 trying to twist facts to promote his agenda.