Topic: Really no talk of segwit / big blocks.. - page 2. (Read 2129 times)

There is no talk because developers of bitcoin decided segwit or nothing.
Its not perfect solution, its solution tho.
HDD space is a issue, not in ur case (one time payment of 120$) but in server costs payed each month.

no other solution are in play besides segwit/2mb/4mb block limit etc...? what about the dynamic block limit(the block size will adapt to the transaction, so you will have the size you need only when n° of tx will increase) that was propose?

I'm sure there have been at least 3 different threads about it over the last two weeks.  We don't have to talk about it in a brand new topic literally every day.  It is a little overdone.  Also, keep an eye on the Development & Technical subforum, as some threads end up there.  In particular, I feel more people should pay attention to ones like this thread.  Dynamic blocksize for the win!

Segwit may be good, but it makes it easier to make bigger changes in the future that would allow hard forks. This gives more power to the current Core team. People find that this goes against Bitcoin's philosophy, which tries to make the network as decentralised as possible. But I guess you could say that about any other hard fork.

Currently I'm split between Bitcoin Unlimited and adopting Segwit. Im unsure about Blockstream's future, and I like Bitcoin Unlimited's approach to scalable blocksize.

Yes i agree many thread on here that talking about activation of segwit, I think it is not political is like election for me
unfortunately there are some people who doesn't agree for activation of segwit.

But it is decentralize (it is more democratic ), we must accept about it and maybe must there are other solution about block size except segwit.

you raised a valid point.
although a LN tx is just a 2-in  2-out tx. people need to think about the multi-hop trades where one entity (hub) starts becoming the arbitrator/manager. where to ensure satisfaction MANY separate transactions need to settle at the same time to ensure each channel gets what it should.

so although over 2 weeks people can play within their offchain channels. one tx of funding becomes dependant on the IOU trust of another tx of funding, meaning suddenly many tx's need to broadcast to aggregate and settle equally. leading to a bottleneck. especially if there are more tx's than there are space in a block to accept it.

yes i know LN has a CLTV to freeze funds and not make them spendable for x blocks. (like blockreward maturity/banks 3-5day funds unavailable) to allow a grace period so transactions can be plopped in over several blocks, aslong as all tx's aggregated together all eventually confirm in time..

but this is not enough precaution to avoid a mainnet mempool bottleneck. because that can cause a fee war, where transactions will need to be renegotiated to cover the larger fee's then predicted X blocks ago.

---

let alone allowing space for legacy (non-LN) transactions to get confirmed at a reasonable fee. because turning bitcoins mainnet into just a LN settlement layer where the only option for people to use bitcoin is only within a LN PERMISSIONED channel, is foolish and the polar opposite of bitcoins permissionless ethos.

and yes needing a second party to sign off on your decision to transact (multisig) is permissioned.. and no longer permissionless.

Litecoin is not a real test scenario, the traffic in litecoin is really small compared to bitcoin, so you can't extrapolate any useful data to apply on bitcoin as far as a I know.

In any case, it's obvious why we need segwit and lightning network (and increase blocksize to 2mb after we get segwit running)

Decentralization <> Consensus.
We have had decisions taken when the majority support an initiative. If a fork is required for us to progress, so be it.

I strongly agree with achow101's view. Hard disks are pretty cheap today but we can't tell the same about network bandwidth and especially upload speed. Of course this is not a problem for educational institutes to run their full node but for enthusiasts home users is a big hassle in every day operation. I would like try to run a full node at least for a month but I don't know the consequences in other network operations. So I don't know what is more preferable for network load. Segwit or the alternative of bigger block sizes. Somewhere I had read that last year the number of full nodes has considerably reduced and now is no more than 5500 nodes globally. At last I have read some things about the two different views but in none of them Ι was able to distinguish what is preferable when we see only the computing and network load.

Some altcoiners're afraid of SegWit and Lightning because their alts become meaningless so they impede segwit's implementation. Roger ver one of them he bought lot's of shitcoins and now scheming bitcoin

There are talks on SegWit but in my own opinion it is more political and ego than the actual technology, and this is a concern

does litecoin really need segwit, they have no block limit problem, they numbers of transactions per day is very small not comparable with bitcoin


it's about consensus, there isn't a centralized party that will decide for everyone, that's is the bad part about decentralization, when you actually need something to be implemented asap but none agree

Until someone acknowledge that we need a streamlined scaling solution or until they bump the block size. At this time, both sides wants to be right, so they bumping heads over trivial nonsense. The suggested solution is overkill i.m.o but it is a start.

The issues is more about politics and ego than the technical merit of the solution, but you will never be able to take the human factor out of the equation. ^hmmmmmm^

How much longer is this going to go on?

Why do we need big blocks again? Why do we need SegWit again?

Let's see how SegWit works for Litecoin first.

Here are my thoughts on why most of the core developers want to increase the blocksize to 2mb after SegWit activation. To avoid a bottleneck for the closing of channels in the Lightning Network. Imagine we still have 1mb blocks and have hundreds of LN channels closed at the same time on a regular basis. This could cause those transactions back onchain to be stuck and the mempool would go higher than we have seen before.

the linear/quadratics issue has never been an issue.. if core implemented some rules properly
users dont need the capability of 20,000-80,000 sigops for their single transaction. the solution is not to limit bitcoins whole growth out of fear of one malicious users... but limit users individual sig-op allowance so that malicious users cant do crap.

EG say 100sigops max.. definitely not 20,000

EG imagine a single transaction with say 141 inputs
imagine 141 transactions with 1 inputs each

same data, same destinations same funds coming and going..
but nodes process the 141 transactions easier

its pure logic..
dont let one person bloat a whole block with a single bloated tx.. .. set a TX sigop limit so not only does a 'malicious bloater' have to make multiple tx's which no longer cause time delays for the network.. but does make time delays for the malicious user having to make the tx's himself (good for both reasons).. but also allows a better chance of random honest peoples tx getting into a block due to it not being completely filled by a single tx.

even things like LN doesnt need 20,000 sigops for one tx.

an LN tx is just a 2in 2out tx afterall

All core devs except one want to increase the blocksize to 2mb after segwit is activated, because raising the blocksize before activating segwit opens a can of worms we want to avoid.

Ultimately the real red pill is the fact that we need everything. We need segwit, we need a bigger blocksize, we need lightning network, we need EVERYTHING, or else we will FAIL.

Thanks for that! A useful summery.

below was a summary of the last years debates using actual numbers, stats and ideas admitted by core devs.
but wrote without their hiding the details under the carpet games, so yes it will have my biased comments

segwit
yep.. limit the transaction count.. dont expect more than 7tx/s
(same numbers suggested as expectations 2009/2013) but due to feature bloating we only get 3tx/s pre-segwit today..
meaning if 100% of users use segwit only expect 7tx/s again. if less than 100% use segwit expect less than 7tx/s but more than current 3tx/s

meaning a one time gesture of pretend growth. but in reality just resetting expectations back to normal of 2009-2013 temporarily again.
much like the pretend "fee discount". just resetting expectations of fee's back to 2015 average cost.. temporarily again

increase bandwidth,
although core believe 4mb is now "bandwidth safe" how that will be utilised is not 4x tx count, but...:
1mb txdata, 1.1mb witness, 1.9mb future extended features = 4mb weight
EG:(1 for input-output.. 1.1 for signature.. 1.9 for confidential commitments/other features)

yep we wont get 4x tx count.. only at best 2x CURRENT average. and only IF 100% use segwit.

user advantage/disadvantages
old transaction users (long term holders) wont benefit from it and infact penalised more because their old tx's would be treated as the cost of more than 1 segwit tx(based on bytes). and as described above only 7tx/s is achievable if EVERYONE moved across to the new transaction type.

meaning even though the maths of 2009-2013 suggested 1mb blocks and 250byte/tx yielded 7tx/s

current feature core estimates suggest 2.1mb blocks of todays 500byte average will yield 7tx/s, with 1.9mb spare area in weight for extended features later (but not extra transactions beyond 7tx/s when future features enabled)
couple months ago stats: feature core estimates suggest 1.8mb blocks of todays 400byte average will yield 7tx/s, with 2.2mb spare features area in weight for extended features later (but not extra transactions beyond 7tx/s when future features enabled)
or later on
full bloat/feature heavy core estimations suggest 4mb blocks of 1kb/tx will yield 7tx/s

yet the community have instead asked for a compromise
2mb blocks yielding 7tx/s (no segwit, no extended features)
or
4mb (2mb base 4mb weight segwit, but no confidential commitment features) of 7tx's - as a compromise to allow segwit
but with a dynamic block consensus utility to not depend on dev spoonfeeding.
so that the community can later. say 2018-2020 have:
4mb blocks 14tx/s
or
6mb (3mb base 6mb weight segwit, but no confidential commitment features) of 10tx's - as a compromise to allow segwit

...
but nah
core dont want 4mb blocks for 14tx's, heck they dont even want to allow more than 7tx's even if they think 4mb or even 2mb is ok

they prefer 4mb blocks of 7tx's and bloated features raising the average tx to 1kb each.. but having a bit of grace/gesture period of a possible 2.1mb bandwidth of 7tx's.. before the extended feature bloating begins.. which will happen before 100% of users switched to segwit, thus users wont get to see/benefit the one time boost potential gesture, before bandwidth increases to 4mb but tx numbers remain at best 7tx's.

above was a summary of the last years debates using actual numbers, stats and ideas admitted by core devs.