Topic: SegWit yay or nay? come vote here. - page 5. (Read 7400 times)

we all know that only gmaxwell and those in r/bitcoin want the community divided.
they call anything not core an altcoin. they try to get anything not core to split off (bilateral fork)
funny part is that all the other 70 differ versions (dozen different brands) are all running on bitcoins mainnet now, and for a long time and not causing issues.
yep nodes with 8mb block buffer are running right now and are accepting blocks and not orphaning anything and not autobanning or black listing opposing buffer setting nodes.
not rejecting transactions not becoming gate keepers not doing any harm..

yep nodes with dynamic block buffer are running right now and are accepting blocks and not orphaning anything and not autobanning or black listing opposing buffer setting nodes.
not rejecting transactions not becoming gate keepers not doing any harm..

unlike core features

those in r/bitcoin point the finger in the other direction when saying a proposal they want.. to make them look like the victim and gain sympathy.
they are the ones playing the psychology games. they are the ones that want dominance not everyone on the same equal playing field.
they are the ones desiring centralised commercial services.

i feel sorry for those in r/bitcoin being handed scripts to follow and handed the same scripts by dozens of people to make it seem like its real because more then one person is saying it to them.

if only those at r/bitcoin didnt just play follow the leader games and instead actually read the code and looked passed all the buzzword games that are thrown at them by the script writers.

please if there is anything you can ever be advised to do, it would be... research.

research consensus
research the code
research the context
research scenarios of how rational and researched context plays out

dont copy and paste summaries scripted to you
dont throw boring repeated stuff that has been made a moot point years ago
dont just play the victim card that someone mentioned someones name. and instead look for why and what was said about them

seems more people are screaming im fud because i mention gmaxwells name. rather than about why or what im actually saying about his plans and desires.

atleast research bitcoin and understand it. otherwise all your doing is attacking a pseudonym, not the proposals or features of bitcoin

This sentence only disqualifies you from any serious discussion ... so dont talk shit about rational explanation,  logical and rational reasoning . You are a troll aswell.

Yeah im basicly fighting with /r/btc weapons ... Trump style, seems like its effective these days 

lol wow, your reply including so much proof, so much rational explanation, such much logical and rational reasoning to come to your assumption..

.. oh wait it didnt

@franky1  Lol you are really fudding full force. Your keyboard ist burning     Meanwile Segwit-Node Adoption is rising ...

nah, r/bitcoin trolls want to sybil attack a opinion poll by getting the blockstream trolls to all vote in favour of segwit even when the majority of thos voting dont even run a node or do mining.

polls like this are just keeping the civil war alive and avoiding "consensus" by only having 2 options and worded to make it sound like the options can only oppose each other.. rather than a mutual (consensus) agreement.

i stated this poll needed a third option of 'yes if both were included' (not verbatim) near the start of the topic. but the OP refused to be rational

its shared on r/btc ?

I was almost sure that this means a fork.
And it has to be supported by the majority, else we can end up like Ethereum.
I guess that this is the reason the devs do only changes that don't risk to trigger the Ethereum fiasco.

And then SegWit is the best we can get for now.

I would be tempted to say yes, as I have to this day never seen any convincing explication about why this is a bad idea. For this reason, and since I would like that we get out of this eternal drama about the blocksize, I start about a yes basis, that might change if anyone ever prove me this is a bad idea.

there are many ways to have a dynamic protocol

put short nodes FIRST have to accept a certain size for the network to happily accept without much/any orphan drama
next pools need to be rest assured that if pools made blocks bigger then current consensus it wont cause much/any orphan drama.

it is not as simple /silly as pools make bigger blocks if the mempool is overfilled due to an abuser flooding it..

firstly node need to flag their acceptance they can cope with Xmb.. then pools flag their intent to make anything upto xmb to give a prompt for the laggers to adjust to xmb or be left unsynced when pools deem it safe to move forward.

then when it meets a certain safe majority level pools dip their toe in the water.
EG imagine majority nodes flagged 2mb was ok.. pools then flagged a majority ok to make 2mb base blocks..
at a certain point pools 'test the water' by making a 1.001mb block to see the orphan risk, then the next block maybe 1.002mb and so on safely incrementing up, naturally with demand until whenever blocks get to be 2mb full due to demand.

its not going to be a 2 mb or a 1gigabyt by mindnight thing. nodes and pools will do it safely.

after all.. did pools and nodes jump from 0mb to 1mb overnight in 2009-2015.. nope.
after all.. did pools and nodes jump from 0.5mb to 1mb overnight in 2013-2015(after the sipa caused db fork event).. nope

it was natural and safe and orphan mitigating low risk movements.

Average blocksize is a pretty useless metric there, because it's highly distorted by miners that produce empty blocks  (or nearly empty blocks)-- which are still as full as they're going to get.  More useful is the n-th percentile size, which is ~1MB for most values of N... or the rolling maximum of the rolling minimum.

You can't just take and change some variable (or constant) in the code

In fact, you can but your blocks (if you are a miner) will be considered as invalid by other miners and thus discarded by the network, so you will be losing the mining reward every time you find a block and don't follow the "rules". That seems to be one of the reasons if not the primary one why changes, even vital changes are so hard to make in Bitcoin. On the one hand, this is good since it preserves Bitcoin from attempts at malicious changes, but on the other, in the times of change it will backfire and drag Bitcoin backward

actually it doesn't say anything.
because first of all it has only 68 votes (which is pretty disappointing because this topic was in the first page for the past 3 days and it has already 1400+ views) and you can not say anything with only 68 votes.

so far people seem to be more interested in "posting a comment about segwit" rather than "voting"!

Bitcoin will never reach its full potential without segwit. Without segwit we can't have a lot of cool features that will improve bitcoin later on, andreas recently wrote an article on why segwit is the way to go:

https://medium.com/segwit-co/segregated-witness-and-aligning-economic-incentives-with-resource-costs-7d987b135c00#.xy3j5m4i3

Time to activate segwit otherwise keep crying about why bitcoin sucks.

It would have had some reasons, like better parsing speed for the client or predictability for the future size of the blockchain.
However, I did a quick search and now I know that I was wrong and I should have researched before talking. Sorry.
I will leave my post as it is now, because others may have the same misconception and my learn something of it, especially if they are as lazy as I am.

So.. the block is already variable with upper limit so all I said was on the wrong assumption.
Now I am puzzled why there's so much debate on increasing the block size, since the "effort" of the blockchain would not be so big.

From what I've read and understood, even a completely dynamic blocksize is achievable without much of a change, since in the block, the bytes 4-7 (0-based) tell the total size of the block, which can be a 4 bytes = 32 bits number, so up to ~4GB (!).

~~~~~~~~~~~~~~~~

Now back to the original discussion:
1. If 100% dynamic block is an issue, then fix the issue or limit it (even if limiting it makes it work like now), but at least limit it to something a couple of levels higher than what we have now (much higher than 2MB).
2. Such move may need a fork and then SegWit can be even forced "in the same package".


I know that this kind of move would cause more debate, but.. we have it already and we can see that SegWit is not adopted by the ones that should

I voted Yes. I see good things in both SegWit and dynamic block, so I have no problems if one or the other is selected, but from what I have read, I prefer SegWit over dynamic block.

I was actually me who had raised this issue why there were blocks half-empty or just empty when literally many dozens of thousands of transactions had been queued and didn't get confirmed in time. Some guy (don't remember his name) who is behind some mining software came up with an explanation that it was due to misconfiguration on the miners' part as well as deliberate actions of rogue miners (allegedly for the sake of efficiency). Regarding fixed block sizes irrespective of the block content (i.e. how many transaction it includes), this simply makes no sense and creates useless or even detrimental overhead...

Really, what's the point of adding empty space to the block just to keep its size to 1Mb in all cases?

Over 60% voted for yes, I don't know how to calculate for bias, but this figure says alot about the different in opinion among the BTC users and the miners. I think the passage of SegWit depends on political solution to the issue of scaling.

Some people are bent on using divide and rule to promote their interest and both parties keep telling us half truth because they want to protect their interest

You do have a valid point. But I see it only partly valid.

An older discussion was that some miners cheat or something is defective and until that is fixed any other solution is only a lie. It happened at one of the first big spam attacks I know of.

From what I know, now the block size is fixed. So whether the miner includes 0 transactions or max possible, the block size will be the same.
I see the dynamic block ... dynamic. If it has an upper size, we will have the same problem as now sometimes, if there will be huge spam attacks (if the upper limit is 16 MB or 64 MB, you can imagine..)
In the normal days, the blocks will be like now, even smaller sometimes, leading to a not-so-big increase of the blockchain over time.
Does this sound ok or is there something extremely wrong in this logic?

Then blocks would be no longer dynamic

In other words, with the upper limit set on the block size the current implementation of Bitcoin can be thought of as dynamic too. Some rogue miners choose not to include any transactions in the block they find (apart from the block generating transaction), some include only the transactions with the highest fees, and the size of the blocks is only a few kilobytes (or even less than that). In this manner, blocks are as dynamic as they could possibly get