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

I don't care about "scaling" in SegWit as much as I care about the malleability fix. I'm not a big fan of coffee transactions on the chain anyway but I'm really interested to see Lightning in action which would work a little better with the fix.

SegWit yay!

If dynamic block has some problems, I think that the best option would be to overcome/fix them. An option would be to set an upper limit of the dynamic block, at least it would reduce the flood problem.


I would love to see this solution implemented. It could even get more miners adopt SegWit just because of the full package


About the vote: I see it as a good way to see "what ordinary people think", but it means nothing more. I voted here, but I use SPV wallet (and many of you do the same, I think) and our vote will never be visible in the network. That's why nodes and miners were asked and not the ordinary people.

Doesn't matter what the entire world thinks or votes, the community's opinion means nothing in this case.
All that matters and counts are miners/nodes, the option is on the table and is not mandatory, no one is forced to do anything as long as they are the majority and even if the minority decides to stick with being an old node then they are still a part of the network, we are not going to end up like ETH and ETC there is no conspiracy only an improvement and either will lead to bitcoin's success or continue to be as it was before.

i was also with dynamic block but i've heard there are some problems, first of all is if an attacker is abusing the network by flooding it and increase the dynamic block momentarily, this will lead to some sort of centralization toward strong node

the other thing is to follow the monero project with its dynamic block, but it will change a bit the fundamental economy of bitcoin, making it inflate for a small amount like monero did

Maybe if you do a pool like this, you should explain what these options do really mean?
I know you wrote "If you don't know - don't vote", but this is a perfect opportunity to spread the knowledge about the topic and get some more relevant results.
No offence - just saing.

PS: I know a bit about the problematics, but I'm too afraid to vote, because I don't think I have enough informations to make a decision.

if you read what gmaxwell wrote. not with a blind devotion of gmaxwell hat. but an methodical and open minded hat on you will see he avoided the critical context and was wishy washy about the critical stuff and just knit picked the stupidest things he can find.

EG arguing about version numbers.
EG arguing about how segwit nodes dont have to white list segwit nodes..

when my posts on previous page and even segwits own guide, were about whitelisting old nodes (downstream modules as gmaxwell wants to call them)

my post on previous page with the images explained how old (downstream) nodes wont accept segwit transactions. so segwit has to be the gate keeper(upstream) in the middle joining to the pool not randomly on the outside going through an old nodes.

but hey. i bet you just skimmed what he said and just thought "oh well its gmaxwell lets trust him"

gmaxwell has been known to slide around the truth and throw in buzzwords to make what one person says.

he tried to do it before when i said about his confidential payment codes CPC being upto 1kb+.. he said there was no such thing as a confidential payment code in confidential transactions,
but he soon shut up when i started using his buzzwords of his "confidential Pedersen commitments" CPC being 1kb+

so dont let him throw big words at you and make him side step the critical stuff. because he is known to sidestep issues and brush things under the carpet if you dont use his buzzwords

eg he will deny intentional splits but will agree if you call it a bilateral fork..

. in my reply to him you will see what i mean where he side steps the context of the critical stuff

OK, should I say then, they are "fuller"? According to this chart it was in November when the average block size passed the 900 kB size regularly. Since then the number of days/hours where we have more than 20.000 unconfirmed transactions in the waiting list is increasing.

In the current situation TX with lower fees mostly get eventually confirmed after a couple of hours, so it "seems" not urgent still, but my point is that in every price rally in the past the transaction volume grew at a higher rate than the normal one - so in the next rally we will probably have severe capacity problems (If the price manages to break the all time high this scenario could be only a couple of weeks ahead.).

PS: I consider it a good thing that Litecoin will enable Segwit before BTC, as I hope that in the case of success the Segwit adoption by miners and nodes could go up in BTC too.

We could debate all we want and I think even Satoshi could come here and vote but since this is an open source technology only the majority of nodes are going to be the victor party here. though if I'm gonna pay much higher fees after activation I'll do so as I don't have any other choice if I want to benefit from bitcoin, do whatever you want as long as I can wake up and see bitcoin is still around and people buy it from me I really don't care.

Freedom of money babe and freedom of choice is what brought me here and will keep me here until I die .

segwit in regards to real scaling, is a temporary gesture.. a one time boost/stopgap
lets say it was a full release last april and it got activated by june last year.. by this month now. all of its advantages would have been seen and we would still be needing dynamic blocks now.

the best solution is for core to just release a dynamic block version along with segwit. and join the level playing field.

late 2015 core devs agreed to a plan of segwit mid 2016 and dynamic blocks by mid 2017
but in spring 2016.. core started back tracking saying nothing was agreed and they were just independent devs and had no ability to put code into bitcoin core in regards to dynamic blocks... (luke jr received alot of backlash because of that).

pools are not going to break the rules and push for something if nodes are not ready for it..
which core knows. so they have prevented having a dynamic block release. and now done their own temporary feature as soft... but shot their self in the foot because again pools wont push forward with a big change unless there is a big node acceptance. even if devs feel that nodes dont deserve a vote. pools are smart to know for validation security nodes have a place in the network.
hense why segwit is holding at 75% pools undecided about segwit

I will vote for yes. If its for improvement of bitcoin. Lightning Network and adding block size are good for bitcoin. To be honest, i really dont know what they comment. Im not a tech nerd. But these two should be the major improvements should make.

you literally said it in the same reply.. they do not relay them.. meaning its an issue..
if a segwit node connected to a old node and then the old node connects to a pool... the pool wont get the tx.. because the old node drops it.

segwit node-old node- pool

so this is where segwit has to mess with what it connects to, to ensure its tx's get relayed to a pool
old node-segwit node- pool

or to get past your padantic sidestepping.. segwit by default looks to find segwits first and then after activation it will have to white list old nodes
edit: old nodes(downstream) of the segwit node(upstream/gatekeeper)

a malicious pool could include it in a block and then spend it. hence why you fear making transaction now with p2wpkh keys right now.. and have not included the p2wpkh key generation for mainnet use in the versions you have released so far.


fine you are releasing something unrelated in 0.14.0. but 0.14.X or 0.15.X... whatever the version number will be that includes MAINNET utility of p2wpkh and p2wsh key generation wallets, wont be released until after segwit activation.
im kind of thinking your just being knit picky about the version number rather then the fact of the p2wpkh and p2wsh key generation wallets available only AFTER activation, context.
again lets not play your version number knitpicky game (facepalm at ur fail)
the version with the p2wpkh and p2wsh key generation wallets, AFTER activation will ensure there is a path from a segwit node to a pool because as you yourself said old nodes have issues and wont relay segwit unconfirmed tx's (red text at top)

right now segwit is not activated so nothing now needs to change as there is only one varient of data being created right noe..
but in the context of after activation..

the context of it is instead of white listing OLD nodes as special and then send the blocks in a format old nodes understand. they will just connect to other segwit nodes and let the pools send whichever version block needs to go to whichever version node.
i even quoted the guide that says it too.. where messing with old nodes is a hassle(needing to white list old nodes.. so human psychology is that people wont whitelist old nodes but prefer segwit nodes.
you are really chomping hard at the bottom of the barrel of words.. rather then being honest of the context.


yes your segwit nodes are already avoiding connecting to older nodes(even when right now its not nessessary).. i hear many people shouting loudly how they are not white listing old nodes already.
oh im inaccurate because my image was a 50/50 but i bet your claim is that its not a 50/50 because you see 61%... (facepalm).. the context is that old nodes and new nodes are not going to interact as much..
again knick pick the numbers if you want... but atleast try to aim at being honest with the context. because it is a failure of your honesty and a failure of you actually making a point by side stepping the context with silly knitpicks.

you again are petty knitpicking.. i never said a node RECEIVES 2 variants.. i said a pool or a node that has been generous to white list old nodes. has to CREATE 2 varients (your buzzwords, stripped and unstripped). sending one varient to new and one variant to old..
petty knit picker. you have still not said anything that makes a point that differs. you are just swapping common speech for your buzzwords

so because you have enough gatekeepers old nodes are meaningless to you
if segwit activates and lets say nodes stayed at under XX%.. by looking at the context of your reply. seems you will just leave oldnodes reliant on the very few generous segwit nodes and pools that do white list old nodes. but not care much about old nodes being part of the network because segwit are the gate keepers


so your context is that old nodes are not important. and ok to ignore old nodes..
oh and as for bare minimum of segwit nodes.. shall we let you retry you explaining the relaying of unconfirmed transactions needed to ensure segwit transactions reach a pool (instead of your side stepping the concept to argue about the number version).

yes you can run a old node without changing. but ur relying on segwit nodes to do the gate keeper duties. and filtering data to an old node.
if you had integrity, you would actually inform people their old node is not full validating.
if you had integrity, you would actually inform people their old node is reliant on a sgwit node being the gate keeper.
you wouldnt just stroke peoples heads and tell them its ok to be treated as second class like its nothing.


a hard fork using consensus only activates with high majority. and i personally have been honest to say that old nodes not upgrading will be left unsynced.. yes its harsh. but atleast its honest.

side node.. "downstream modules".. is that what your buzzword is for the older nodes your segwit nodes have to whitelist. while segwit use the upstream modules buzzword i called the gatekeepers.. ill remember that.

Can someone please explain the meaning of segregated witnesses in simple English devoid of technical terminologies so those who are not computer geeks can understand why the whole community is so worked up

Your comment seems strange to me, virtually every block is full, and has been for most of the last year, barring some low times on weekends. This isn't in and of itself a problem.

And sure more capacity might be needed, but the lack of urgency from the broader community around segwit is pretty good evidence that it isn't currently.  Talk is cheap.

the average user of which i am one just want bitcoin to work well and not have all these arguments about blocksiaze, lets just get it done.  the whole blocksize debate is starting to hurt bitcoins cred, i have even started to see people on twitter talking about hardforks, which i think would be a disaster.

@franky1: Your post talks about the disadvantages of the soft fork, not about segwit itself. So you're not answering my question. For now, @waxwing is more convincing to me.

But I disagree with this statement:


Since November, we've had multiple days with full blocks. Many people already have complained about their transactions not getting confirmed. A higher fee would only solve the problem if a large part of the transactions could be considered spam (that means, transactions that would not be sent if the fee was higher).

But transaction volume is increasing steadily: Even if 30% of the current block size is made of spam, in a few months - given the actual growth rate - the blocks will be full of "legit" transactions. That's why I think it is somewhat urgent to do something. 2 MB (like with Segwit) will be enough for now. If there is nothing done, I fear if we have a boom or price rally in the next months transaction volume could explode and the scalability problems would be visible for everyone, bringing us a lot of bad news and disappointed users.

I wished both parties could "cool down" a bit, I don't want Bitcoin to die slowly because of shitstorms.

Honestly speaking, I voted " i don't know" since I don't really know what segwit is, its purpose, objective or what.
But, I am beginning to get interested with it now, I'll begin to study it really sounds interested with me now. Hope this thread will help me to know what segwit is.

I heard that LN will make bitcoin more centralized, and if with segwit you have this full potential, it make sense for miners to not want to activate segwit, they don't want a centralized bitcoin

SegWit provides improvements that allow to use the Lightning Network at its full potential

As I got it, without SegWit the payment channels you are talking about could get stuck (mutated or malleated), so we would have to either set timeouts limiting the efficiency of the channels or provide another fix for the malleability issue. Without the malleability fix that SegWit introduces, there can't be a trustless Lightning Network. Maybe, I'm missing something else here

actually you are wrong.
i am not an expect in this matter but from what i have read from experts, Lightning Network uses payment channels with Hashed TimeLock Contracts. Both of those things are currently usable on Bitcoin mainnet without segwit, so LN is possible without segwit.

what segwit does is (i think) making it easier and safer.

you can also read this: http://achow101.com/2016/04/Segwit-FUD-Clearup

edit: funny thing is when you search "lightning network without segwit" you see cryptocoinnews shitty article spreading false information once again!