SegWit yay or nay? come vote here.

[Red-Apple]

I personally have never seen anyone asking the community or the bitcoin users what they think about Segregated Witness. (apart from Nodes, and Hashrate i have never seen any other way.)

so here is an opportunity to anonymously vote. obviously this is just for curiosity purposes and the result are just results.

please don't randomly vote.
if you don't know what SegWit is or don't know whether you should want it or not, then Vote for 3rd option I don't know
Vote Yes if you know what it is and want it to be activated.
Vote No if you know what it is and don't want it.

[1714724068]

1714724068

[Vlad2Vlad]

This should be interesting.

[franky1]

put in another option.

"yes but only with real consensus onchain scaling beyond the one time boost"

[Red-Apple]

put in another option.

"yes but only with real consensus onchain scaling beyond the one time boost"

I think i'll keep it simple as is. and for YES i mean, the current proposal anything other than that means you vote NO and can explain here in the comments.
shared on reddit too.
https://www.reddit.com/r/Bitcoin/comments/5pb2sd/vote_on_bitcointalk_segwit_yay_or_nay/?ref=share&ref_source=link

[franky1]

put in another option.

"yes but only with real consensus onchain scaling beyond the one time boost"

I think i'll keep it simple as is. and for YES i mean, the current proposal anything other than that means you vote NO and can explain here in the comments.
shared on reddit too.
https://www.reddit.com/r/Bitcoin/comments/5pb2sd/vote_on_bitcointalk_segwit_yay_or_nay/?ref=share&ref_source=link

there could be a lot of people that want both or undecided because people are stupidly dividing the communiity by thinking consensus should be ignored and it should only be a one or other decision..

your pool is just going to be a biased civil war whos on whos side vote. rather than a community consensus open choice.

[Red-Apple]

there could be a lot of people that want both or undecided because people are stupidly dividing the communiity by thinking consensus should be ignored and it should only be a one or other decision..

your pool is just going to be a biased civil war whos on whos side vote. rather than a community consensus open choice.

i disagree. it is not a civil war unless we make it one.

currently we are waiting for the miners to decide on the acceptance or denial of SegWit (the proposal they are signalling- BIP141 IIRC)

and users have only nodes to voice their opinion and there are only ~5000 nodes and lot more users. so i want to know out of the 929828 members on bitcointalk and ~2 million daily visits and more other places how many want, don't want or even have no idea about BIP141

and as i said in OP, this the results will just be results.

(so far 126 times read and only 7 votes!)

[digaran]

I'll vote later, but I suggested this before and I know the newbies army can easily manipulate the results and wish there was a way to count only full members+ votes.
I'd go with whatever is best for bitcoin and it's future of course miner's profit is one of the important priorities, we should see what will keep the community united and even stronger than before.
If activating the way they intend to do is going to cause 2 different sides as to dividing the whole system and community then a big NO.
If doing so will alter the purpose and meaning of "open source" "publicly distributed" and "decentralization" in any possible way a big NO.
If not doing so is going to favor individuals all over the world and wont slow down and cripple the network then YES, meaning NO to segwit.

[Slark]

There is no point in discussing SegWit in its current state as it lately became clear that miners won't support this update.Something must change for SegWit to become real alternative.
We have miners agenda, Blockstream agenda, community agenda, Roger Ver with bitcoin unlimited etc. Simple users like me who want so have better bitcoin are confused and dazed by all this mess.

[dothebeats]

I voted no, simply because I'm not even sure how would this turn in the long run. The implementation might be a-ok, but seeing that votes on this matter could only be voiced using nodes (which is more or less 5000 as of today) is kinda concerning and might divide the network's interest.
If it benefits the protocol, the network and the community in the long run, I would vote yes, but as for now I don't really see how would this lead us into something better "community-wise."

[franky1]

i disagree. it is not a civil war unless we make it one.

currently we are waiting for the miners to decide on the acceptance or denial of SegWit (the proposal they are signalling- BIP141 IIRC)

and users have only nodes to voice their opinion and there are only ~5000 nodes and lot more users. so i want to know out of the 929828 members on bitcointalk and ~2 million daily visits and more other places how many want, don't want or even have no idea about BIP141

and as i said in OP, this the results will just be results.

(so far 126 times read and only 7 votes!)

you do understand segwit right??

you understand that although when confirmed in a block old nodes dont fully validate the tx. but instead blindly look passed it..('compatible backwards' cough cough)
BUT before confirmation because it appears as signatureless tx (anyonecanspend) old nodes can cause issues.

this is why 0.14(the implementation with p2wpkh and p2wsh key generation wallets) wont be released before activation.

and then after activation, 0.14 wont connect with non-segwit nodes for relaying unconfirmed transactions to avoid the silly things that happen at unconfirmed relay level.
they could connect to old nodes and just relay old transactions. but lets be honest segwit-node users wont bother doing all the setting changes to mix and match tx's. so will just connect to segwit nodes to make things simple

yes after tx are passed by segwit nodes to a segwit accepting pool, they will then relay block data out to all nodes new and old.. but due to the unconfirmed tx relay part. segwit will divide the network at unconfirmed tx relay level

segwit done as non network consensus node activation is going to cause issues.. but core wont tell you about this until after its activated as a strongarm motive for everyone to jump onboard at a rapid pace to join their nodes. or be left ignored. (changing the network)

technically its all the 'same network' (due to all nodes connecting to a pool), but the nodes become more biased to only communicate with their own kind. where it becomes more work for a pool to send out 2 different variants of a block. --witness



again core will try to advertise the need to get nodes to upgrade to gain more connections and be more part of their side of the network (although in their half truth twisting of words is one network)

this is why it should have been a proper network consensus rather than a emulated consensus of just the pools, so that by being a full network consensus before pools, allows the nodes to be ready and fully compatible rather than just SPV compatible to segwit

as you can see by segwits own guide. if not upgrading they want you to set up another node to 'filter' your unupgraded node through a segwit node (facepalm) when sending old tx's but you wont receive new tx's. it also allows segwit nodes to be the controller of what becomes a 'valid block' or not. rather than the old node doing independent checks

https://bitcoincore.org/en/2016/10/27/segwit-upgrade-guide/

In this configuration, you set your current Bitcoin Core node (which we’ll call the “older node”) to connect exclusively to a node running Bitcoin Core 0.13.1 or later (which we’ll call the “newer node”). The newer node is connected to the Bitcoin P2P network as usual. Because the newer node knows about the segwit changes to the consensus rules, it won’t relay invalid blocks or transactions to the older node—but it will relay everything else.

When using this configuration, please note that the older node, if it uses Bitcoin Core defaults, will not see transactions using segwit features until those transactions are included in a block.

Configuration:

For the newer node, start it normally and let it sync the blockchain. At present, you cannot use a pruned node for this purpose because pruned nodes will not act as relay nodes. You may optionally start the newer node with either or both of the following command line parameters so that it treats the older node as special (these options may also be placed in Bitcoin Core’s configuration file):

  -whitebind=<addr>
       Bind to given address and whitelist peers connecting to it. Use
       [host]:port notation for IPv6

  -whitelist=<netmask>
       Whitelist peers connecting from the given netmask or IP address. Can be
       specified multiple times. Whitelisted peers cannot be DoS banned
       and their transactions are always relayed, even if they are
       already in the mempool, useful e.g. for a gateway

For the older node, first wait for the newer node to finish syncing the blockchain and then restart the older node with the following command line parameter (this may also be placed in the Bitcoin Core configuration file):

-connect=<IP_address_or_DNS_name_of_newer_node>

[d5000]

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.

[franky1]

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.

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

[Vaccinus]

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

[franky1]

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

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

[unamis76]

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.

We have miners agenda, Blockstream agenda, community agenda, Roger Ver with bitcoin unlimited etc. Simple users like me who want so have better bitcoin are confused and dazed by all this mess.

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...

https://lists.linuxfoundation.org/pipermail/lightning-dev/2016-November/000648.html

Interesting read...

[d5000]

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.

[franky1]

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.

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

upstream(segwit) <-> pool<-> downstream(old)

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)

[waxwing]

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

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

[waxwing]

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).

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.

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.

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).

[franky1]

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

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).

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