Bitcoin Forum
November 24, 2017, 07:18:30 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 3 4 5 »  All
  Print  
Author Topic: Small blocksize increase should be done first and SegWit second  (Read 3100 times)
LiteCoinGuy
Legendary
*
Offline Offline

Activity: 1148


In Satoshi I Trust


View Profile WWW
December 30, 2015, 05:00:59 PM
 #1

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.

1511551110
Hero Member
*
Offline Offline

Posts: 1511551110

View Profile Personal Message (Offline)

Ignore
1511551110
Reply with quote  #2

1511551110
Report to moderator
Join ICO Now A blockchain platform for effective freelancing
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Amph
Legendary
*
Offline Offline

Activity: 1708



View Profile
December 30, 2015, 05:45:55 PM
 #2

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
LiteCoinGuy
Legendary
*
Offline Offline

Activity: 1148


In Satoshi I Trust


View Profile WWW
December 30, 2015, 08:05:50 PM
 #3

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

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.

keepdoing
Full Member
***
Offline Offline

Activity: 140


View Profile
December 30, 2015, 08:18:28 PM
 #4

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

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.
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.
helloeverybody
Hero Member
*****
Offline Offline

Activity: 854


★YoBit.Net★ 350+ Coins Exchange & Dice


View Profile WWW
December 30, 2015, 08:26:02 PM
 #5

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?

BitcoinNewsMagazine
Legendary
*
Offline Offline

Activity: 980



View Profile WWW
December 30, 2015, 08:41:25 PM
 #6

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.

keepdoing
Full Member
***
Offline Offline

Activity: 140


View Profile
December 30, 2015, 08:47:40 PM
 #7

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.
If I honestly believed that was a possible outcome - I would sell my bitcoins today.
Amph
Legendary
*
Offline Offline

Activity: 1708



View Profile
December 30, 2015, 09:13:40 PM
 #8

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

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.

actually it seems that segwit is even less, around 1.3, i had a conversation with a guy here saying this https://bitcointalk.org/index.php?topic=1299293.msg13328502#msg13328502
brg444
Hero Member
*****
Offline Offline

Activity: 644

Bitcoin replaces central, not commercial, banks


View Profile
December 30, 2015, 09:18:38 PM
 #9

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

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.

actually it seems that segwit is even less, around 1.3, i had a conversation with aguy here saying this https://bitcointalk.org/index.php?topic=1299293.msg13328502#msg13328502

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.


"I believe this will be the ultimate fate of Bitcoin, to be the "high-powered money" that serves as a reserve currency for banks that issue their own digital cash." Hal Finney, Dec. 2010
Lauda
Legendary
*
Offline Offline

Activity: 1680


GUNBOT Licenses -15% with ref. code 'GrumpyKitty'


View Profile WWW
December 30, 2015, 10:36:24 PM
 #10

Why I feel a small blocksize increase should be done first and SegWit done, as soon as safely possible, second
'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.


▄██████████████████
███████████████████
███████████████████
█████████████████
███████████████
████████████████
████████████████
█████████████████
███████████████████
████████████████████
█████████████████████
▀████████████████████
Bazista®
██ █  ██ ██
██   ██  ██
██  ██   ██
██ ██  █ ██
██ █  ██ ██
██   ██  ██
██  ██   ██
██ ██  █ ██
██ █  ██ ██
██   ██  ██
██  ██   ██
██ ██  █ ██

██ █  ██ ██
██   ██  ██
██  ██   ██
██ ██  █ ██
██ █  ██ ██
██   ██  ██
██  ██   ██
██ ██  █ ██
██ █  ██ ██
██   ██  ██
██  ██   ██
██ ██  █ ██
|||
maokoto
Hero Member
*****
Offline Offline

Activity: 770


✪ NEXCHANGE | BTC, LTC, ETH & DOGE ✪


View Profile WWW
December 30, 2015, 10:49:37 PM
 #11

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.

franky1
Legendary
*
Offline Offline

Activity: 1862



View Profile
December 30, 2015, 11:34:46 PM
 #12

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

I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
Don't take any information given on this forum on face value. Please do your own due diligence & respect what is written here as both opinion & information gleaned from experience. If you wish to seek legal FACTUAL advice, then seek the guidance of a LEGAL specialist.
brg444
Hero Member
*****
Offline Offline

Activity: 644

Bitcoin replaces central, not commercial, banks


View Profile
December 30, 2015, 11:45:36 PM
 #13

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

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.

"I believe this will be the ultimate fate of Bitcoin, to be the "high-powered money" that serves as a reserve currency for banks that issue their own digital cash." Hal Finney, Dec. 2010
keepdoing
Full Member
***
Offline Offline

Activity: 140


View Profile
December 30, 2015, 11:56:42 PM
 #14


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.
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.
brg444
Hero Member
*****
Offline Offline

Activity: 644

Bitcoin replaces central, not commercial, banks


View Profile
December 30, 2015, 11:59:23 PM
 #15


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

 Roll Eyes

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

"I believe this will be the ultimate fate of Bitcoin, to be the "high-powered money" that serves as a reserve currency for banks that issue their own digital cash." Hal Finney, Dec. 2010
franky1
Legendary
*
Offline Offline

Activity: 1862



View Profile
December 31, 2015, 12:02:33 AM
 #16


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.

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 DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
Don't take any information given on this forum on face value. Please do your own due diligence & respect what is written here as both opinion & information gleaned from experience. If you wish to seek legal FACTUAL advice, then seek the guidance of a LEGAL specialist.
brg444
Hero Member
*****
Offline Offline

Activity: 644

Bitcoin replaces central, not commercial, banks


View Profile
December 31, 2015, 12:02:38 AM
 #17

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

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.

It's just a hard fork tho. Srsly. What's the big woop?

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.

"I believe this will be the ultimate fate of Bitcoin, to be the "high-powered money" that serves as a reserve currency for banks that issue their own digital cash." Hal Finney, Dec. 2010
BlindMayorBitcorn
Legendary
*
Offline Offline

Activity: 1064



View Profile
December 31, 2015, 12:04:09 AM
 #18

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

Forgive my petulance and oft-times, I fear, ill-founded criticisms, and forgive me that I have, by this time, made your eyes and head ache with my long letter. But I cannot forgo hastily the pleasure and pride of thus conversing with you.
franky1
Legendary
*
Offline Offline

Activity: 1862



View Profile
December 31, 2015, 12:05:14 AM
 #19


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.

so you admit, that people would need to upgrade and download a new version just to be a full node and stay part of the network...
hmmmm hard fork!

I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
Don't take any information given on this forum on face value. Please do your own due diligence & respect what is written here as both opinion & information gleaned from experience. If you wish to seek legal FACTUAL advice, then seek the guidance of a LEGAL specialist.
brg444
Hero Member
*****
Offline Offline

Activity: 644

Bitcoin replaces central, not commercial, banks


View Profile
December 31, 2015, 12:08:04 AM
 #20

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)

No.

Full nodes who have not updated can still safely use and deal with regular transactions and fully verify every economic activity they are involved with.

require no upgrades and its just other people that treat the data differently locally to themselves..

That's exactly what segwit does

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!!!

Not true, miners will still push out blocks containing regular transactions which the full nodes who haven't updated can still fully verify.

Segwit does not change the nature of the blocks so as to make it incompatible with older Core versions. That's just plain wrong.

"I believe this will be the ultimate fate of Bitcoin, to be the "high-powered money" that serves as a reserve currency for banks that issue their own digital cash." Hal Finney, Dec. 2010
Pages: [1] 2 3 4 5 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!