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

[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.

[Foxpup]

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.

[mademerich]

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 event 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.

I couldn't agree more, segwit + 2mb would effectively quadruple the blocksize and fix the problems we are having now for the foreseeable future. A doubling of the block size isn't going to ruin bitcoin anymore than blocks from 500kb to 1mb would. I understand people are afraid of 8 mb or higher blocksizes but 2 mb is an acceptable compromise while further negotiations for more permanent solutions can be found.

[25hashcoin]

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.

Honestly tired of this rhetoric. It's really just playing dumb when you know what is meant by blocksize increase. The accusation is that the Blockstream/Core side is trying to constrain the blocksize to 1mb forever. This is a real concern, and people want to see it lifted, and there's no reason not to. That is the fairest compromise I have ever heard for activating segwit. Pro Segwit side is being unreasonable by refusing this.

[jonald_fyookball]

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.

[dinofelis]

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.

Well, segwit IS a smarter way of writing the transactions on a chain.  Technically, bitcoin's transactions are horribly designed, and do a lot of stupid things.  Segwit arranges that up to some point.  It is a better digital format of the information.  If you look at the technical improvements that Segwit brings over the design flaws in the original bitcoin transactions, I think one can only be in favour of the new format.

However I think the discussion is not about this.  I think the discussion is about the religious attitude against hard forks.  If one "gives in" to that attitude now, then we are essentially stuck *for ever* with the 1 MB block size + witness data.  For the moment, that could bring relief.  But maybe one day, the "equivalent 4 MB" will be again a limit.  And then, a hard fork WILL be needed.  Moreover, Segwit has been made more complicated as needed, just to *be* a soft fork.  It would have been cleaner as a hard fork.

There's no difference on the conceptual side between a hard fork and a soft fork: BOTH ARE MODIFICATIONS OF THE PROTOCOL.   A soft fork is not "softer" than a "hard fork".   The only difference resides in the "fighting block chain dynamics" when miners disagree.  Then a soft fork has much more power to just kill the opponent: a good majority is sufficient to suffocate the opponent ; while hard forks become truly independent coins.   In other words, hard forks are free choice elements, soft forks are "winner takes all" elements.   But both of them make a different protocol.

One can have two conceptions of crypto: one is "immutability".  A coin has an immutable protocol, which is a Nash equilibrium because of decentralization.   That coin is what it is, and will live with its protocol for ever.   Or the other is "dev-centralized evolving piece of software".   Then hard forks are not a problem: the devs centrally decide (eventually with one or other voting mechanism).

The point is that bitcoin's economic dynamics is such, that at a certain point, it will need scarcity of transactions, to make transactions expensive, because they have to pay for the mining PoW which won't be paid for any more because of goldbugonomics (no tail emission).  And for the moment, this was (accidentally) provided for with a hard limit on the number of transactions.  If one thinks one should allow bitcoin to have more transactions in one way or another, in the end, a hard fork will be needed to modify this.  

This has, in fact, nothing to do with the technical improvement of writing down the data on a binary record, which is segwit.

Hard forks are perfectly compatible with a decentralized conception of crypto.  Any entity decides to make a new coin, forking off from an existing coin, in the same way that any entity can start a new crypto currency from scratch with a new genesis block.  The only difference between a hard fork and a new genesis block is that one takes over the existing balances of the coin one forks off from.  Hard forks don't need collusion. 

Soft forks are an anti-decentralisation element, because they need a 51% collusion to succeed.

[Kakmakr]

The developers and the people behind them do not care what we think. They have their own hidden agendas and if our goals with Bitcoin goes along with their agenda, it would just be a bonus for them. I have been reading endless posts about people's opinion on this matter and cannot grasp, why people might think that our opinion would matter to greedy and power hungry groups with hidden agendas. ^grrrrrrr^

[mackenzied]

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.

[Xester]

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.

If we cant have segwit we cannot have Bitcoin unlimited also. The only choice left for consensus is the activation of segwit. Bitcoin can no longer last long having thousands of transactions pending at the mempool. If there will be no consensus and segwit will not be activated the big companies that are planning to enter the market will surely back-out. Hence we need to activate the scaled segwit and we need the consensus the sooner the better.

[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.

If we cant have segwit we cannot have Bitcoin unlimited also. The only choice left for consensus is the activation of segwit. Bitcoin can no longer last long having thousands of transactions pending at the mempool. If there will be no consensus and segwit will not be activated the big companies that are planning to enter the market will surely back-out. Hence we need to activate the scaled segwit and we need the consensus the sooner the better.

Except it's not segwit vs unlimited. It's segwit vs segwit with 2mb blocks. The big block side has compromised, the segwit side has not.

[Foxpup]

Honestly tired of this rhetoric. It's really just playing dumb when you know what is meant by blocksize increase.

I'm not the one playing dumb. "Blocksize increase" means the maximum size of blocks is to be increased. SegWit increases the maximum size of blocks from 1MB to 4MB. It's not "equivalent" to 4MB, it is 4MB. Metric megabytes, in case there's any confusion. 4 million bytes, that is, 32 million bits. That's four times as much data to transfer and store forever in the blockchain, and it's understandable that not many people want to spare the bandwidth and disk space for it. That's why it was so controversial when it was first introduced.

The accusation is that the Blockstream/Core side is trying to constrain the blocksize to 1mb forever.

Which is false, of course. Of all the Core devs, I think only Luke-jr is in favour of keeping blocks small. I've always been in favour of larger blocks myself, but I have to concede that Luke does have a point. Not everyone can handle bigger blocks, and the increase to 4MB may be problematic. I'm willing to support 1MB SegWit if it turns out nobody wants 4MB blocks after all.

[25hashcoin]

Honestly tired of this rhetoric. It's really just playing dumb when you know what is meant by blocksize increase.

I'm not the one playing dumb. "Blocksize increase" means the maximum size of blocks is to be increased. SegWit increases the maximum size of blocks from 1MB to 4MB. It's not "equivalent" to 4MB, it is 4MB. Metric megabytes, in case there's any confusion. 4 million bytes, that is, 32 million bits. That's four times as much data to transfer and store forever in the blockchain, and it's understandable that not many people want to spare the bandwidth and disk space for it. That's why it was so controversial when it was first introduced.

The accusation is that the Blockstream/Core side is trying to constrain the blocksize to 1mb forever.

Which is false, of course. Of all the Core devs, I think only Luke-jr is in favour of keeping blocks small. I've always been in favour of larger blocks myself, but I have to concede that Luke does have a point. Not everyone can handle bigger blocks, and the increase to 4MB may be problematic. I'm willing to support 1MB SegWit if it turns out nobody wants 4MB blocks after all.

That rhetoric...you just did it again.

[The One]

The developers and the people behind them do not care what we think. They have their own hidden agendas and if our goals with Bitcoin goes along with their agenda, it would just be a bonus for them. I have been reading endless posts about people's opinion on this matter and cannot grasp, why people might think that our opinion would matter to greedy and power hungry groups with hidden agendas. ^grrrrrrr^

Opinions matters. If no one does then greed and evil will have no barriers and a licence to do what they what.

[The One]

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.

Only those with limited closed mind could use the word only. Codings can do many ways.

[The One]

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.

Well, segwit IS a smarter way of writing the transactions on a chain.  Technically, bitcoin's transactions are horribly designed, and do a lot of stupid things.  Segwit arranges that up to some point.  It is a better digital format of the information.  If you look at the technical improvements that Segwit brings over the design flaws in the original bitcoin transactions, I think one can only be in favour of the new format.

However I think the discussion is not about this.  I think the discussion is about the religious attitude against hard forks.  If one "gives in" to that attitude now, then we are essentially stuck *for ever* with the 1 MB block size + witness data.  For the moment, that could bring relief.  But maybe one day, the "equivalent 4 MB" will be again a limit.  And then, a hard fork WILL be needed.  Moreover, Segwit has been made more complicated as needed, just to *be* a soft fork.  It would have been cleaner as a hard fork.

There's no difference on the conceptual side between a hard fork and a soft fork: BOTH ARE MODIFICATIONS OF THE PROTOCOL.   A soft fork is not "softer" than a "hard fork".   The only difference resides in the "fighting block chain dynamics" when miners disagree.  Then a soft fork has much more power to just kill the opponent: a good majority is sufficient to suffocate the opponent ; while hard forks become truly independent coins.   In other words, hard forks are free choice elements, soft forks are "winner takes all" elements.   But both of them make a different protocol.

One can have two conceptions of crypto: one is "immutability".  A coin has an immutable protocol, which is a Nash equilibrium because of decentralization.   That coin is what it is, and will live with its protocol for ever.   Or the other is "dev-centralized evolving piece of software".   Then hard forks are not a problem: the devs centrally decide (eventually with one or other voting mechanism).

The point is that bitcoin's economic dynamics is such, that at a certain point, it will need scarcity of transactions, to make transactions expensive, because they have to pay for the mining PoW which won't be paid for any more because of goldbugonomics (no tail emission).  And for the moment, this was (accidentally) provided for with a hard limit on the number of transactions.  If one thinks one should allow bitcoin to have more transactions in one way or another, in the end, a hard fork will be needed to modify this.  

This has, in fact, nothing to do with the technical improvement of writing down the data on a binary record, which is segwit.

Hard forks are perfectly compatible with a decentralized conception of crypto.  Any entity decides to make a new coin, forking off from an existing coin, in the same way that any entity can start a new crypto currency from scratch with a new genesis block.  The only difference between a hard fork and a new genesis block is that one takes over the existing balances of the coin one forks off from.  Hard forks don't need collusion. 

Soft forks are an anti-decentralisation element, because they need a 51% collusion to succeed.

Smarter doesn't always mean better. If the data goes up due to CT, then more storage is needed per transaction.

In what way?

[The One]

Honestly tired of this rhetoric. It's really just playing dumb when you know what is meant by blocksize increase.

I'm not the one playing dumb. "Blocksize increase" means the maximum size of blocks is to be increased. SegWit increases the maximum size of blocks from 1MB to 4MB. It's not "equivalent" to 4MB, it is 4MB. Metric megabytes, in case there's any confusion. 4 million bytes, that is, 32 million bits. That's four times as much data to transfer and store forever in the blockchain, and it's understandable that not many people want to spare the bandwidth and disk space for it. That's why it was so controversial when it was first introduced.

The accusation is that the Blockstream/Core side is trying to constrain the blocksize to 1mb forever.

Which is false, of course. Of all the Core devs, I think only Luke-jr is in favour of keeping blocks small. I've always been in favour of larger blocks myself, but I have to concede that Luke does have a point. Not everyone can handle bigger blocks, and the increase to 4MB may be problematic. I'm willing to support 1MB SegWit if it turns out nobody wants 4MB blocks after all.

Codswallop. 4mb every 10 minutes is nothing. I DL whole series of TV programmes that has more data than the blockchain itself. Stop worrying about poor people with 56k bandwith. One can not prevent evolution, improvement and societal advancements due to some poor people. Otherwise nothing will ever get done. If people can't handle bigger blocks then they don't have to partake in running a full node. They can use pruned version of the blockchain. Millions will have the means to run full nodes, so it isn't a problem.

[franky1]

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.

segwit does not give 4mb (4x) capacity increase!!!
if..  if.. again ill emphasise this IF every single transaction inside a base block was a segwit funded keypair.. the best expectation is around 2.1mb

with all the malicious spammers,
the fact there are 46m+ native/legacy outputs,
the fact that the keypairs wont even be available right at the day of segwit activation.
the fact that not everyone wants to waste an average of $3 in fee's just to get it into a segwit keypair.
the fact that if everyone did want to do it the mempool bloat would grow rapidly.
... you will not see a block with 100% segwit utility.

just like not everyone wants to do lean transactions to help out the community to get 7tx/s for the last 8 years

so i emphasise this you wont even get 2x capacity growth..

please dont read the reddit scripted utopian fud and start running actual scenarios.. not utopian scenarios but rational realistic scenarios. and you will see segwit is a empty gesture of half promises.

people that want to maliciously spam/quadratic a block, will stick with native keypairs. so dont expect segwit to be the miracle because it does not stop native keypair functionality.

[aesma]

Codswallop. 4mb every 10 minutes is nothing. I DL whole series of TV programmes that has more data than the blockchain itself. Stop worrying about poor people with 56k bandwith. One can not prevent evolution, improvement and societal advancements due to some poor people. Otherwise nothing will ever get done. If people can't handle bigger blocks then they don't have to partake in running a full node. They can use pruned version of the blockchain. Millions will have the means to run full nodes, so it isn't a problem.

Exactly. Besides, only miners really matter, and miners are spending ungodly amounts of money already, the cost of storage isn't even registering.

[dinofelis]

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.

Well, segwit IS a smarter way of writing the transactions on a chain.  Technically, bitcoin's transactions are horribly designed, and do a lot of stupid things.  Segwit arranges that up to some point.  It is a better digital format of the information.  If you look at the technical improvements that Segwit brings over the design flaws in the original bitcoin transactions, I think one can only be in favour of the new format.
...

Smarter doesn't always mean better. If the data goes up due to CT, then more storage is needed per transaction.

In what way?

Well, I already wrote a few posts about how bitcoin transactions are wasting space *uselessly* and make verification *uselessly* complicated.

I will quickly indicate what is wrong if one wanted to win room, without modifying anything to the principles, apart maybe one.

A) we keep bitcoin's rules exactly as they are:
Aa) there is no need to publish the public key.   The public key can be derived from the signature and the message (ok, very few signatures could fail, in that case, one should have foreseen it, and modify the nonce of the signature, but it is one chance in 10^36 or something if I remember well).  That's 256 (and noncompressed, 512) useless bits.
Ab) the output transaction hash (256 bits) is much, much too long.   The number of the output, on 32 bits, (4 billion outputs !!) is too long too.  Note that indicating the transaction hash is not really an element of security, it is a way to help find the right output.

But this brings us to what would have been a very good rule in bitcoin:

-> don't allow address re-usage.   This could have been in the protocol !

B) if that applies, then there is not even any need to specify any output transaction hash: 256 + 32 bits won again !  Because there's only one single output in the whole block chain that has this single input address (found by the hash of the public key, found by looking at the signature).

Moreover, forcing single-address usage would improve the cryptographic security somewhat, because the public key would never be exposed before it was useless, and many other things would be better.  There would not be any notion of transaction malleability either.

So we would only need a signature as an input.  Nothing else.  No referred-to previous transaction and transaction output, nor any public key.  And the search would be easier (just a single address).

We would win more than half of the room of an input/output pair that way, if we consider compressed keys, and even almost a factor of 3 of the uncompressed case.

[Carlton Banks]

Bitcoin can no longer last long having thousands of transactions pending at the mempool.

This is often said, but it's not true.


The mempool wouldn't exist if unconfirmed transactions didn't serve a useful purpose; it's all about setting the price of transactions per byte. Unconfirmed transactions are dropped from the mempool in a rolling 1 week window, but it's really easy to fill up the mempool while the window is still open.

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. Some of the spam attacks literally were exactly that, the same BTC sent in a massive chain of thousands of unconfirmed transactions (way to make it obvious)