Topic: Well, I've been a Segwit supporter for a while now but... - page 2. (Read 1441 times)

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.

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

In what way?

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

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

That rhetoric...you just did it again.

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.

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.

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.

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.

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.

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^

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.

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

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.

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.

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.

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.