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

Strictly speaking, I'm not very familiar with all the technical aspects and gory details of the SegWit update (apart from the increase in the block size if that could count as SegWit awareness), but I know that without SegWit there can't be the Lightning Network in the future since it seems to depend on this update (as far as I know). The latter should be a giant step ahead in the Bitcoin evolution (provided it delivers on its promises, of course)...

Therefore I'm all in (for SegWit activation)

what are the other solution now besides the hard fork to 2mb? if there are not any and we can not hard fork to 4mb/8mb because miners don't agree, and they either don't want to activate segwit, there is no solution in this

i rememer that the miners were in agreement(at least the majority) with hard forking to 2mb at least, they changed their mind?

i think that this consensus mechanics is brokern, it should be in this way, if you have not a better solution you should agree with the best available one

For those who don't know it, Franky1 appears to have a full time job lying about segwit on Bitcoin talk.  I see that he now has technobabble charts to match his technobable claims. The graphs look sciency but actually have nothing to do with Bitcoin at all-- no part of Bitcoin before of after segwit has any resemblance to either of those meshy graphs.  He's stuffing that stuff into his posts in order to make people who don't know much about the technology believe that he knows more than them.

I have him on ignore and I strongly recommend other people set him on ignore too.

I got asked to post some corrections here, so I am.

Pre-segwit nodes know they don't understand segwit transactions so they simply do not relay or mine them. They don't cause any issues.  The reason they do not relay or mine them is because segwit uses some intentionally constructed forward compatibility in the protocol, which was put in by Satoshi specifically to enable new signature systems.  They'll tolerate things using this forward extensibility when they show up in blocks, but because they can't completely judge the validity on their own, they don't mine them (or relay them) themselves.


Segwit has more hashrate than BIP66 did this many days after start.  Your opinion is possibly being manipulated by malicious people who are exploiting the fact that it often takes miners a long time to upgrade to try to convince you that segwit will not activate.

It will activate if people want it and make their preferences known, no more, no less.  Contrary to franky1's claims I nor any of the other developers get paid based on segwit activating. We did our part.

Personally, I'm happy that it hasn't activated yet (though not so happy about the people lying about it).  The lack of urgency in getting it going coupled with the continued health and success of Bitcoin without any capacity increase just shows what a big stinking liar people like franky1 have been with their hyper-aggressive doom and gloom claims that Bitcoin was going to fail unless it had a capacity increase ASAP.

There's a considerable split between the "yes" and "no" voting blocks, and I think it does tell a rather interesting tale that the community doesn't otherwise seem to be painting. Apparently, miners are just pushing it around 40% support, or that's the highest number I have heard so far, while this vote is probably looking at closer to 70% or 80% of the total vote, assuming everyone was forced to vote one way or another.

This is Theymos' territory so of course "Yes" will win here. Big blockers are only a small portion of the bitcointalk.org population because they either left or they are not as vocal. Another big portion are the people who do not care and have no clue what is going on as shown by the majority of posts here from people from countries like Indonesia or Philippines. Sorry but it is true.

Try the same poll in forum.bitcoin.com and see how skewed the results are towards "No". That forum is Roger Ver's territory.

I was voting the 3rd option. Where the SegWit will goes and anyone doesn't know about that. But totally Roger Ver is winning this round. And again this is not about the improvement elements or something like that. But it's about money.
They're going to the where it can give advantages.  

I voted "I don't know" because I literally did not know anything about this SegWit thing.
But still, I voted because I am interested in making this happen. Why not? It might help our community grow stronger.
I'll keep this in my watchlist.

those that want it, are mainly paid devs that NEED it to work due to their investment contracted future features needed to repay investors. or sheep that dont quite understand the exaggerations and over promises made. and dont understand how much has been swept under the carpet and not talked about.

the majority that dont care, undecided or dont want it. are risk averting such a change thats only a temporary gesture of temporary benefit.

If its for the better. Why not give it a try? Its for the improve of bitcoin. I dont really know what can be the effect of this when it happen. I saw many people agree to segwit. But some are not agree. Can anyone tell me why? Theres so much explanation from the comments but i really dont understand. So tell me in a simple.way.

but lets digress to LN seeing as u think its laughable and not what i said it would be

have you actually seen the penalties and fee's of LN
have you understood how LN multisig works (2 party authorisation) which can lead to hubs setting up to be the second party of everyones contract

have you done the maths, run scenarios,? if you ignore using a hub and instead go for the 'hop' idea of LN... the costs are even bigger and penalty risk is higher

eg
A<->B
B<->C
C<->D
D<->E
imagine A wanted to pay E using the 'hop' concept.
first A move funds to B..
B wont change his funds with C for free so A has to pay a fee to B to thank him for his involvement
next B move funds to C..
C wont change his funds with D for free so A has to pay a fee to C to thank him for his involvement
next C move funds to D..
D wont change his funds with E for free so A has to pay a fee to D to thank him for his involvement

so to pay E is 4x the fee compared to just trading with B
the risks are due to no previous interactions with other hops. all of their locktimes will differ which snowballs into some channels closing earlier than expected.

this is what blockstream are hoping for. so this is where they become X (a hub)

A - X - E
   / | \
 B  C  D

now everyone only has to pay 2x hop fee but everyone can trade with each other.
downside.
now X has 50% authorisation permission status with everyone.
now X has can be the deciding factor of how long they want to make customers funds mature for after settlements confirm (CLTV)
now X has can be the deciding factor of chargbacking their customers funds after settlements confirm (CSV revokes)

yea they may get some competition where starbucks or walmart become a hub. and offer a cheaper fee. but thinking that the 'hop' concept will be used dominantly is not a rational end result.

oh and its worth people really

IF 100% of people move funds to segwit p2wpkh/p2wsh keys..

if only 50% of people do it. then expect 1.3mb-1.5mb capacity increase.

oh and its a 1 time max possibiility.. you cant resegwit a segwit to get upto 3mb..

oh and once people start using different features like CSV CLTV (adding extra bytes) confidential payments(adding upto1kb) even if its the same 2in 2out tx...
that will add more data (mb weight) to a block.. but no increase in tx count..
EG we could see

1.0mb=2500tx today
2.1mb=4500tx after activation and IF 100% utility of keys being segwit.. and then
4.0mb=4500tx when using the new features

Franky is talking utter drivel. Whether LN is going to "work" is debatable, but the usual talking points against it (centralisation?! fees?!) are laughably far from reality.


The segwit *concept* itself, as you put it, has no drawbacks because it is a fix of a fairly serious design flaw in Bitcoin. Any particular implementation will always have risks and might have drawbacks; the soft-fork implementation chosen has tremendous benefits and some fairly minor risks, heavily ameliorated by a year of testing. There's no reason to assume it must have a reasonable share of benefits and drawbacks; you'd expect people to choose an implementation with a lot more of the former than the latter!

Everyone on here saying "well segwit is a bit crap but i guess i'll vote for it as the best for now" is for sure talking from a perspective of ignorance, and having listened to equally ill informed people. It's actually a brilliant piece of work and a huge step forward, and immediately gives us ~2MB blocks (whether that's a good idea is up for debate, but if that's what you want, you get it).

Segwit gives you 1.7-2MB blocks. People telling you otherwise are lying.

as you can see by the post i done with the couple images included up above.

say you made a transaction that used segwit keys.. P2WPKH...
if you relayed it to an old node. (while network is in current format) the old node see it as an anyonecanspend, which would get rejected and not relayed by an old node (while unconfirmed). but if a pool was to include it. even without segwit working. the pool could confirm it and then spend it.

this is why core need pool acceptance predominently and are willing to split off the opposing pools.
this is why core want segwit tx relays to be where segwit nodes are a separate layer to the old nodes. where segwit 'translates' the transactions into something old nodes cant mess with.

ok explaining the bit after the first picture in last post i made.

hopefully the color coding shows how core envision the node connections of the network will change. where the purple line is the "special white listed old nodes".. where the segwit nodes translate the block into standard 1mb block format

concentrating on left side below.. the red pool at the centre. going outwards

EDIT:gmaxwell buzzwords
downstream(old) <-> upstream(segwit) <-> pool

however not many people will manually want to white list those old nodes and will think 'the pool or someone else can do it', which obviously will be the pools because of them being a segwit node, is able to whitelist some old nodes
and so
the image on the right is more so what the network would look like by adding in some context of human psychy .. bar maybe a couple purple lines that might go between the segwit nodes and the old nodes from some people who may make the extra effort


all because sending a segwit transaction unconfirmed to old nodes and pools not segwit ready has issues.
like i said they have not even got intention to release a wallet with segwit keys (p2wpkh p2wsh). and wont release it until the pools are ready and they have some segwit nodes to act as the gate keepers and translate the data to old nodes(in the left utopia)

Thank you @franky1, I'll read it. I don't consider LN an ideal solution for Bitcoin to scale, too. I think it's over-complicated, but for micropayments it may work (I consider it appropiate for payments where you, using fiat, would use a prepaid/gift card).

What I was interested in, however, was an explanation in layman's terms if the Segwit concept itself (not LN and also not the "soft fork" itself as you point out in your other posting) had some negative impact on security or usability of Bitcoin. I know the Bitcoin Core page about Costs and Risks, but it doesn't seem like this list is really a list of "disadvantages" as most of it could be applied to all larger "jumps" in software development. If you or another participant of this discussion have a link for me, I'd be grateful if you share it.

I voted yes. We need something that scales Bitcoin now and SegWit is the one with most signaled support, thus being the one that's probably easier to achieve (although it might not really be the best solution). We risk having issues using Bitcoin if we wait too much to make a change.


It is indeed hard to go through all the mess surrounding discussions regarding SegWit and block size increases (but it's been worse previously). Maybe confusing normal users is an objective for some, who knows...


Interesting read...

and only core are holding proper SCALING consensus up, with their subverted half promise of a temporary one time boost to then a push for their commercial LN hubs to repay their investors the $90m debt via all the fee's and penalties they wish to charge people using LN.

they will only do onchain SCALING only when LN settlement lumpy tx's dominate and they need more room to fit in more LN settlements.. not due to any open sense of an open network for normal tx's to flow again

i'm with segwit as a temporary solution, but i want 2mb as additional solution, unless they come up with something better, but we cannot wait forever bitcoin need to scale asap the price is telling us that the adoption is ready to increase dramatically

hmm another guy using the latest script buzzword "conservative"

d5000
you do realise the 'fee's and penalties of LN..
you do realise the confirmed tx maturity after LN settlement.. (CLTV aka 3-5 business day funds unavailable)
you do realise the confirmed tx revokes after LN settlement.. (CSV aka chargeback penalty)

they have already estimated that to open a channel for 10 days requires 0.006btc fee to be deposits to cover all the costs/possib penalties of using LN $4 just to use the LN service.

LN has a niche for some users, but is not the solution for all users.
even the bitcoin usage stats of 'days destroyed' revealed not everyone is spamming the network multiple times a week.. but core got those stats removed from known public websites to hide that and pretend everyone is spending funds hourly to need LN


its techy but if anyone want to read.. scroll down on the link to the 'results' and see their excel sheet of all the penalties and costs of use they intend to have
https://lists.linuxfoundation.org/pipermail/lightning-dev/2016-November/000648.html

From a layman's point of view (I'm not a coder) I vote yes, because until now I can see only advantages. If someone of the anti-segwit faction can point me to a text where the disadvantages of Segwit are explained in layman's terms, be welcome!

But I am also in favour of a conservative block size increase which takes into account the worldwide average upstream internet bandwidth growth. Because I think while for real micropayments (<10 USD) off chain solutions like LN might be better, for payments with a little higher amounts I prefer the blockchain.