Topic: Blockchain size - problem ? (Read 1805 times)

Thanks, I'll obviously have to do some reading on SegWit to catch up.

Exactly. It seems that some people tend to think that if Bitcoin "fails" for whatever reason that an altcoin is going to take over. However, this is most likely going to end bad for everyone. If Bitcoin collapses, it is likely that everyone will jump ship.

If there was a standard for those hard fork proposals, then that would make sense. However, if you start wanting to fragment the community with randomly set percentages and grace periods, then it will end badly.

You will never get a well recognized coin when you start over from start everytime large part of comunity disagrees with some feature and preffer new altcoin over compromise and continue with just Bitcoin.

There can be competing Bitcoin implementations with diferent features or even hardfork proposals, and free market decides what defines Bitcoin. This way you know you can trust Bitcoin evolves and stay as #1 cryptocurrency choice and not fragment to many altcoins or become obsolete, so whoever can compromise and respect others as well can continue using just Bitcoin, others can just switch to tens/hundreds of altcoins.

There is high incentive to just use Bitcoin and dont confuse regular users with tens/hundreds of different altcoins. The incentive is it is much easier to use just Bitcoin for most people.

Exactly what potential features have resulted in the community dividing itself? I don't recall that happening. Anyhow, this is could also be a signal that the feature is not really useful/desired. Keep in mind that a block size increase is not a feature (in case that some try to assume this).

Bitcoin can't always add features because attempts to do so result in massive division in the community.

That's why alternatives that compete with bitcoin should implement the features.

I don't think this is the case. This "flaw" (if you can call it like that) is inherent in all implementations that use Bitcoin's code. Unless something is completely re-engineered from scratch, it can't really be better/much better as Bitcoin could always add features (hence open source).

Correct. This is why people want to rush the block size limit because they're hoping that as many people as possible jump on the ship (regardless of the size being safe or not).

Bitcoin is also the first implementation of the idea.

It may be time for a better implementation of the idea. Multiple implementations.

The problem is greed, too many people are holding a lot of coins hoping to retire in luxury one day and that won't happen if Bitcoin takes the back seat to better implementations.

Bitcoin can not grow much larger with a 1 MB block size limit and no secondary layer. We are slowly reaching the maximum capacity at this size. Obviously, it doesn't mean that everyone is going to jump ship (why would they?), but it means that growth would be limited/impaired.

The miners aren't the one who solve problems, the developers are.

Although this is a serious  issue in BitCoin, but this does not mean that due to this bitcoin will lose its popularity.
BTC has and will always find its way through difficulties and this time also Bitcoins miners will find a solution to this very
soon.

Your statement does not make sense to me. A user does not need days to fully download nor synchronize the chain. This is a faulty generalization. This is very dependent on the setup that the users are running. Currently with libsecp256k1 it is possible to synchronize from scratch within a few hours (IIRC). Additionally, the average user does not need to and should not bother with running a node. However, I'd argue that this option should exist (relatively cheaply and easily), but it is up to the individual. I'm positive that many do not have the desire to run a node especially since there is no incentive to do so.

I understand your point and it's a problem IMO too, Currently a user needs days to fully download the chain and that would limit the number of normal nodes, and with that the specialized nodes can actually impact the network in a way.

Segwit will also require more bandwidth IIRC.

That opinion does not matter much right now though as they've reached consensus and decided a while ago to do it via a soft fork. From what I understand, the plan is to clean up some things in a hard fork in the future (I have no idea what exactly and when).

I'm certain that it would not be seen as such a bad thing if they choose a proper grace period and consensus threshold. Even Gavin's partner, Garzik, does not agree with him.

nah blockstream should be the competitive altcoin.. wait.. , they are already trying that with LN and sidechains and liquid..

green column: maths is based on a normal transaction being on average 500bytes
sources: (average transactions per block based on blocks over 950k) https://blockchain.info/blocks


yellow column: maths is based on blockstreams projections of segwit 190% capacity
source: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012248.html
source: (lauda blockstream faboy) https://bitcointalksearch.org/topic/m.13973783
i used the higher 190% instead of the lower 170% so that i could be has unbiased as possible and rewarding segwit with a potential 3800 instead of 3400..so they can atleast appear to offer similar(close enough) capacity growth compared to a real hard limit buffer rise


red column: maths is based on blockstreams estimates of CPC adding 250bytes to a transaction
sources: (quotes 344bytes):http://voxelsoft.com/dev/cct.pdf

other sources quote differing amouts but i averaged it as 250bytes. again i tried to be generous rather than doomsday

No - I had misconceptions about what SegWit would do and I don't like that. It too should be done as a hard fork.


Bitcoin as a whole economy needs competition it doesn't currently have.

Classic could have provided that by being an alt-coin. They chose note to because if they did, then success of classic would mean a drop in value of the bitcoins they already hold and they are too greedy for that. So instead they chose to try and hijack Bitcoin.

Care to provide a source for that image/calculation? It's intriguing data but I'd like to have the full story.

basically you want blockstream to have 100% corporate control.. ok you made that obvious

maybe if you used statistics, logic and rational judgement you would see a blockstream 3800tx block of segwitCPC is 2.85mb.. vs a proper 2mb hardblocklimit offers 4000tx..

thus increasing the hard limit and sticking with standard transactions is less bloated

lol maybe you should use an altcoin.
its not about classic vs core.. its about bitcoin as a whole economy and how there should be no control and no single path blindly following one corporation

In all honesty I see it as an ecological waste.

Why does the transaction I made to myself need to be stored on every full node in every country for eternity?

Keep the blocks small and distribute the transactions with altcoins (or LN)

Classic should have just run a different port and started a new genesis block. With all the support from commercial wallets and exchanges, it would have been listed everywhere and then the market could choose which they preferred instead of having the choice made for them.

because if people stop doing normal traditional transactions and instead embrace segwit the real data is actually worse. im not talking about the bat and switch twisting data, im talking about the actual measurements of real data.

also if you continue to embrace blockstreams roadmap and do segwit confidential payment codes(CPC) the real data grows again.
here. a simple image for you


basically keeping the hard limit to 1mb(as blockstream wants) and then everyone doing segwit CPC transactions equates to 2.85mb for only 3800 transactions.
but if we had 2mb hard limit and stuck to traditional style transactions we can have 4000transactions per 2mb block.

so although blockstream tries to say that 2mb hardlimit bloats peoples hard drives. it is infact segwit and CPC that will
so although blockstream tries to say that 2mb hardlimit causes extrea processing. its infact segwit and CPC that will (imaging not only handling extra tx's but then trying to validate balances hidden inside a payment code that it needs to process and check)

so having a 2mb limit and sticking to standard transaction types is actually more beneficial. and yes libsecp256k1 can be used on traditional transactions without the need to make Segwit/CPC transactions. so a 2mb hard limit will be faster than people thought last year before libsecp256k1.

so relax. the hard limit is just a buffer that allows REAL capacity growth and controls the real data expansion. unlike blockstream features that can expand uncontrolled
maths is based on a normal transaction being on average 500bytes
maths is based on blockstreams projections of segwit 190% capacity
maths is based on blockstreams estimates of CPC adding 250bytes to a transaction

my personal opinion is to have 2mb+segwit to allow people the freedom to do proper bitcoin transactions OR segwit CPC bloated transactions, without contention, without any corporate control. and hope that people use their brains and do the transaction that suits them personally. rather then being led down a one way street

A higher blocksize ceiling will cause extra strain on nodes if it is implemented. Sure, running a node doesn't take up much, but it will still try your hardware more intensely. Why not SegWit?