Topic: Small blocksize increase should be done first and SegWit second - page 5. (Read 3493 times)

^Not true. I have a strong sense of decency!

Have a look at network nodes version distribution?

Although knowing you people surely you wouldn't feel bad about leaving a couple of persons behind.

accomodating more transactions means making full nodes store over 1mb of hard drive storage, which negates the whole point of the 1mb limit.
accomodating more transactions means upgrading peoples clients to be able to stay part of the network if miners are using segwit.. (meaning its not a soft fork)

a soft fork is where fullnodes see no difference, require no upgrades and its just other people that treat the data differently locally to themselves.. a hard fork is where it affects everyone and they need to upgrade their bitcoin-core to stay part of the same network..

segwit should not make such change to bitcoin-core.. as making miners change how a block is created and is relayed IS A HARD FORK!!! because other people would need to upgrade too just to get the same data as miners push out

 

I mean I understand if you feel alone this Christmas but no need to come and spread your delusions all over the forum.

More lying nonsense from the Blockstream Puppets.  The MAIN point of Segwit is to buy time so that Blockstream can gain advantage in it's war for control over the financial institutions.

Mike Hearn is willing to mutate Bitcoin into a monster that can be used to crush the people.  Blockstream Puppets want to cripple Bitcoin so they can control it, keep it in a box that only they have the keys to.

Bunch of Biased, Untrustworthy, Selfish, Shortsighted, Greedy Scum.   It's like watching 2 political parties have a debate.  You know that while both have differing pitches, they both are lying and in the end you'll all get screwed.  2 sides of the same coin.

The point of segwit is not to persist with the 1MB limit but to accomodate more room for transactions without having to do a hard fork and meanwhile solve a plethora of issues with regards to malleability.

It doesn't want to trick anyone and you're talking a whole lot of nonsense.

segwit is a sham!

the reasons for the 1mb block rule is that nodes hard drives should only grow by 1mb a block..

segwit wants to trick the bitcoin-core (fullnode) code by throwing only 70% of txdata into the 1mb block and putting the other 30% on the side.. but that simply makes fullnodes hard drives 1.3mb growth per block... which invalidates the whole damn point of the 1mb limit in the first place!

if lite clients want only 0.7mb per block by throwing away signatures.. then let them parse and ignore that data when they save the data locally to their lite client hard drives.. because bait and switching data in a full node is just tricking the blocklimit rule... which is implimented to keep hard drive space of full nodes below 1mb..
so it makes no sense to keep the 1mb block limit if hard drive storage increases by 1.3mb a block.. as the only reason for the limit is hard drive space rationing..

segwit just makes no sense in respects to the data structure of splitting the chain for full nodes.. again that all can be done by lite clients without even touching bitcoin-core source code

Yes, the blocksize things seems to be a neverending issue, although in most people's eyes it does not seem as complicated and the majority advocates the blocksize rise.

'Why I (a person without no relevant background) feel we should do X before Y' is what I read. Not trying to be offensive but this has zero meaning to the important people in the ecosystem.

---

---

One of the main problems is that people (especially some of the developers) are afraid of a hard fork. I have no idea why that is. If there were warnings pretty much everywhere about the required change (incl. alert system), I'm pretty sure that we would come close to 99% of clients upgrading to the next version. I always wondered why they don't bump it up to 2 MB or something and then proceed with their roadmap. Those so called "developers for X years" that are complaining about complexity of the code are just average (if not worse) developers that have never worked on really huge projects.

Obviously no one knows but 1.3 is pretty conservative.

Understand that service providers and wallets responsible for most of the transactions on the network have a strong economic incentive to be proactive and implement SW as soon as possible so it is reasonable to expect SW to be deployed by most major companies quite quickly.

actually it seems that segwit is even less, around 1.3, i had a conversation with a guy here saying this https://bitcointalksearch.org/topic/m.13328502

If I honestly believed that was a possible outcome - I would sell my bitcoins today.

Core developers have made it crystal clear they will do whatever is in their power to delay the hardfork required for a blocksize increase. I think the best you can hope for is SegWit integration by soft fork about April 2016, then a hardfork about one year later to adopt the BIP miners most prefer.

From mu limited knowledge on the subject, from what ive read so far there will be a blocksize increase at some point correct? and if so then why not at least move us up to 2mb to at least keep us going in the meantime?

This is a good proposal / thread.  So simple, so realistic.  Would be nice to see some sort of mini-automated scaling built in to the increase at a minimum.  But the above highlight really is the issue.  You've got a few people that are willing to sink the ship to get their way, even if in the end they drown themselves.  So sad.

segwit is an increase of only 1,75 - 2 MB in the mid term and much more complicated than the 2 MB increase.

a 2 MB hard fork (which everyone agrees on and has zero risks / easy to deploy) will at least double the capazity.

funny that we are now at 2 MB and not even then some devs like Peter Todd agree on that. i guess when one or two people can veto against the will of 99%, bitcoin is in trouble.

afaik segwit, it's only an effective 2mb increase as average with a 4mb as a peak, so it would be pointless to do it after a mini increase like 2mb

Why I feel a small blocksize increase should be done first and SegWit done, as soon as safely possible, second

It is important to realize that SegWit actually is a block-size increase if you don't play semantic games. They are breaking apart the block data into two streams, both of which have to be stored on the users hard drive. The combined size of the two streams will increase the disk space requirements for full nodes.

It is important to note the hypocrisy here. For months the core party line against having a blocksize increase was because it would hurt centralization due to the increased bandwidth and disk space requirements. However, SegWit has essentially the same increased bandwidth and disk space requirements as a simple blocksize increase. It is the same data, just stored into two separate streams instead of one. Now, they are all in favor of increasing the bandwidth and disk space requirements (in the form of SegWit) but their excuse is that it can be done via a 'safe' soft fork instead of an 'evil' hard fork. The goal posts move an awful lot with these guys.

The reason to do SegWit is less about scaling and more because it is a relatively clean fix to the long standing transaction malleability problem.

The reasons not to hold up a blocksize increase for SegWit should be obvious. Remember, both approaches ARE a blocksize increase. It is just that one plays a semantic game by breaking the blocks apart into two interleaved streams of data; which adds a remarkable amount of complexity by the way.

Let's compare the two approaches.

Increase the blocksize limit

    -A single line code change to the client
    -Unlikely to break hardly any existing software anywhere or, if it does, the fix will also just be a one line code change
    -Has roughly the same disk footprint requirements as SegWit
    -Does nothing about transaction malleability
    -Requires a hard fork
    -Could be done on a much shorter time scale since the risk is extremely low and updating software extremely trivial
    -Immediately provides a doubling of the transaction capacity of the entire bitcoin network as soon as it is activated.

SegWit

    -Fixes transaction malleability (YEAH!)
    -Increases disk space requirement roughly the same as a blocksize increase would.
    -It is a highly complex code change that will require a lengthy period of time to be fully vetted and tested.
    -If done as a soft-fork, instead of a hard fork, it will be even more complicated and 'silently' break nearly every piece of software in the existing infrastructure
    -Breaks almost all wallets, nodes, and block-explorer type apps, requiring a significant code refactor to be able to parse and correctly interpret the separate signature stream. Could cause some wallets and explorers to crash and many nodes to fail to validate fully.
    -If done as a hard fork it is much, much, safer, because it won't be activated until most of the network has upgraded their software and with a substantial lead time.
    -Doesn't actually achieve the transaction throughput benefit until the entire software infrastructure has switched over to using the new feature; which will be 'opt-in'.

In my opinion, we should do both, but do a 2mb blocksize increase as soon as possible and SegWit once it has been fully vetted and thoroughly tested.

Unlike the vast screaming hordes, I do not believe that hard forks are dangerous or something to be avoided. I strongly believe we need to change this mentality. The bitcoin ecosystem must be agile enough to upgrade software on a fairly regular basis; this is a basic requirement of any modern software development project.

I much prefer that SegWit be done as a hard fork, it is simply much, much, safer to do it that way. It introduces a lot of complexity and will have numerous dangerous side effects throughout the ecosystem if done 'silently' as a soft-fork.

https://www.reddit.com/r/btc/comments/3ypkhd/why_i_feel_a_small_blocksize_increase_should_be/



that would be a compromise and the war could be over. everyone (except Peter Todd) can live with that.