to correct the above

SegWit was originally hoped to fix transaction malleability (a data manipulation bug allowing transactions you send to be invalidated) and not even designed as a block size fix. Stopping transaction malleability meant moving signatures out of the middle of a transaction and append to the end of a transaction. thus also enforcing how the transaction data was signed with less chance of manipulation.
but this requires people moving their funds to a new keypair type not ever used yet to achieve this, and only works for those specific users using the new keys to not be able to manipulate the transaction data of their own funds.

then a dev (luke JR) realised it could implement it using a backdoor trick in a way that can avoid a full node and pool consensus and just need pool recognition.

This trick moves the signature to a separate area outside of the block, which means the new keypairs can snip off the signature from the end and fool old nodes into not rejecting the no-signature transaction because of the backdoor method.

which means it saves a few bytes transactions would have had inside the block.. to allow more transactions into the main block
which would (for new nodes that keep the signatures of segwit tx key users) increase the overall and combined data in and outside the main block to be (upto 4mb, but in reality well under)
most people think that the network is most likely to settle at about 2MB combined data (for new nodes that keep the signatures of segwit tx key users) but only if SegWit is ever implemented AND only if users move their funds to segwit keys..(emphasis on the need to move funds to segwit keys to achieve anything).

The other thing SegWit could do is allow other soft backdoor changes in easier, things like even newer keypair types like schnorr, LN keys and other things at later dates.

there are many flaws and drawbacks of this though.

i count three mentions.. we are no longer in 2009-2011 of solo mining

1. pools are not pushing the fee's up. blockstreams fee mechanisms coding is and the issue of block size is. so dont make it a drama about pools
2. at the moment think of it as the same as xapo, changetip, coinbase where people trade offchain daily anyway. LN is no different.
yep for emphasis
LN does no more harm to pools future bonus/income as what xapo is and has been doing for years. so relax

now with that said as long as LN stays as a voluntary side service for the niche users like faucet raiders and day traders. and we also get onchain scaling too then there can be a symbiotic relationship of under 10cent tx's onchain that grow in user capacity naturally over years so that fees remain low per users, but add up and combine to cover long term pool costs.. and off chain sub penny voluntary side services for the high yield multispenders to take the pressure off of onchain utility. thus everyone gets the best of both.

the only concern this year is to get onchain scaling made dynamically so that we can organically/naturally grow onchain scaling to user defined limits that nodes can cope with to reduce the pressure of onchain fee's ruining bitcoin utility/desire. WITHOUT needing to endlessly/repeatedly appeal to dev-kings to spoonfeed setting and debate for years.

segwit does not fix these things. segwits features are only temporary gestures that skirt around the utopian promises. and after a few years people will look back and laugh at all the 2 merkle segwit drama of wasted time, once people wake up to reality.

REAL onchain scaling is whats really needed now and then LN is. and the whole drama of what pools need in 20-120 years will look after itself as the years pass.

pools are not voting against LN. they are voting against/abstaining from voting for/against segwits 2 merkle tier netwok of control and cesspit. for multiple reasons.

pools DO NOT CARE about LN

the tx fee's are not needed income. its just a bonus and will remain a bonus for decades. so pools dont care right now and no reason to push for $1 onchain tx last or this or next year..

its blockstream that have done all the code changes that result in highr fee's not the pools.
blockstream devs (most fee based code changes done by gmax himself) all because he wants rusty russels LN to be the money earner hub to repay blockstream debts

pools would prefer
2200 tx last year with $0.10 per tx = $220 bonus
4400 tx this year with $0.10 per tx = $440 bonus
xxx00 tx in near future year with $0.10 per tx = $1x00 bonus
xxx00 tx in near further year with $0.10 per tx = $2x00 bonus
xxx00 tx in near later year with $0.10 per tx = $4x00 bonus

that way utility remains and eventually in 20-120 years when the income:bonus(reward:fee) flip to income:bonus(fee:reward) bitcoin remains popular, usable and not expensive for users.

yes LN as a side service will be ok for those spending more than once a day..
.. but onchain for people that may only transact once a week or month without having to pay $1 each time

in short LN = PERMISSIONED tx's.. (it needs other parties signature of agreement)
in short LN = reinventing chargeback risks(CSV) and 3-5 business day funds unavailable(CLTV)
in short LN = only good for small spending $60ish with 2week lockin-ish

thus dont think of it as the end solution to scaling. think of it like a side service like Xapo

i laugh at that statement
along with 'core are the best team'

if everything is perfect and core are the best team.. then there is no need for segwit, there would be no debate
because there are no problems and bitcoin is already in utopia.. right (sarcasm)

oh an the other laugh
core are independent..

after all if independent then when devs do something independently they why would they be subject to REKT campaigns. or fear peer reviewing and helping out independently of other implementations.

the only way they can end up helping is by pretending to attack by publicising the issues of other peer implementations. that way they wont get pigeon holed into other implementations be acting like they are attacking it. when realy they are saying something needs to be fixed at line x,y,z

even gmax is keping his head low by hiring samson mow to be the face of UASF so that gmax doesnt get the face smack talk about Uasf issues and thrown the BIP's moderation over to luke JR and trying to make it look lik achow is the cencorship master of the tech discussion of this forum.. although the puppet strings are visible

you keep saying you want segwit.
what part of segwit can you prove is a 100% fix. that you desire about segwit
what part of segwit can you prove is a 100% guarantee promise. that you desire about segwit

can you even explain HOW the parts of segwit that you desire actually get the promise/fix

so before just pasting off another daily reddit script stats page..

i want you to actually do the segwit research and show you understand segwit, and can convince me that segwit will 100% get the promise you desire to show why you are sooo devoted into wanting it.

im guessing its going to be a reply about 'who' coded it not what they coded.

now lets see your reply.
please
no insults.
no 'cant be arsed'
no 'why should i tell you'
no 'if you dont know why ask me' word twisting..

i have done the research so lets see if you really understand segwit beyond the 30 second utopian sales pitch.

multisigs have been around years and doing 'bidirectional offchain payments' have been done for just as long..

but to translate Nagadota
blockstreams version of 'bidirectional offchain payments' (LN) is not ready and buggy and wont be ready because it relies on half baked segwit, and keypairs that are not even ready yet

we should not force half baked segwit in just for hopes of the half baked features. and then hope that forcing it in speeds up LN. and definetly not continue pushing it all the way to 2019 if there is still doubt in november 2017..

instead we need to push to get the puppet masters blockstream to do a plan B of a proper community uniting release that does more then halfbaked segwit. (1merkle segwitkeys, plus LN keys, plus dynamic blocks, plus low under 4k maxtxsigops, etc).. and have that as the active by 2019 backup plan.

im laughing at billybob
trying to mix litecoin with bitcoin results to confuse the numbers.. funny

trying to say there are actually 100k nodes when a more reliable metric is bitnodes which has ~7000
and sipa (segwit main guys) block stats http://bitcoin.sipa.be/ver9-2k.png ~68% say no/abstain

1. bitcoin: 68% of blocks and 36% of nodes say no/abstain
where by even then you dont know if the 'yays' are explicit 'yays' or fabricated 'yays' just to avoid DDoS/hacks by hiding as 'yays'

2. assuming that its all down to 1-2 guys causing it...... (facepalm)

if you think that DDoSing isnt happening

its about knowing that 8mb is network safe. blockstream know it.
but blockstream want to control things by spoonfeeding.
since 2015 there has been
2017-03-08 - Bitcoin Core version 0.14.0 released
2017-01-03 - Bitcoin Core version 0.13.2 released
2016-10-27 - Bitcoin Core version 0.13.1 released
2016-08-23 - Bitcoin Core version 0.13.0 released
2016-04-15 - Bitcoin Core version 0.12.1 released
2016-02-23 - Bitcoin Core version 0.12.0 released

and even then there is a v0.14.1 coming soon.
and even if segwit gets activated. EVERYONE wanting segwit needs to download yet another version after activation just to get to 'opt-in' to the new keypairs just to get the voluntary disarming themself feature that blockstream used to call a 'fix'.
yep its not a network wide fix its just a voluntary dis-armourment/amnesty, which funnily enough only the innocent people not spamming would opt-in for anyway. thus solving nothing.

if blockstream just recognised in 2015 what the community wanted and done a 8mb single merkle version(consensus.h) where by the nodes could voluntarily say 'i prefer 2mb'(policy.h and useragent display)
then the pools follow the voluntary blocksize preference..

we would have a true single merkle block that was most definetly under 8mb size and dynamically growing at what the majority preferred of say 2mb and grows based on user settings at runtime. without the need of wasting 3 years and atleast 7 different downloads required

get it yet
7 downloads with unachievable hopes of 100% of people move the 46m UTXO to segwit keys to get the estimated upto 2mb 2merkle klusterf*ck of a tier network. which is going to be kept pushing right up until 2019

vs
something that could have been done properly last year that by now would have got high percentage community united around for a healthy peer network

1. proof or racial speculation starting from reddit?
2. what if the proof is a firmware update to remove asicboost facility so that bitmains own customers cant asicboost. (which was last weeks desire that bitmain should do something to not be able to asic boost)
3. what if the proof is a firmware update to ensure all asics sold had asicboost facility so everyone, even those outside of bitmain had the efficiency gain

lol keep fingers in your ear and lips on blockstreams cheeks..

or

think about bitcoin as a diverse decentralised network and ask yourself, 'hmm maybe blockstream could do something better'

if your first reaction is.. no just bomb them until the end of 2018. then please bite your lip
if your first reaction is.. find out what would work for the whole community to unite around that wont have wasted 3 years for a soft half gesture. then your on the right path.

segwits half gesture is only 6 months publicly released and not even ready for users to use.. the keypairs that are needed for the 'opt-in' features blockstream have previous called 'fixes' are still not finalised.

yep. the fixes are no longer network wide promises but admitted as 'opt-in features'
are not even ready

yet people still think blockstreams current half baked code is the only route and should be followed through, even if objected/abstained this year, to continue pushing it until 2019.

it just make logical sense for blockstream to do a plan B of something that the community can unite around

classic, xt, bcoin, bitcoinec, bu and other diverse nodes do not want to "take over" (only blockstream(core) want a take over)
blockstream have offered and demanded a few times for anything not core to split away, but that was not taken up because the community does not want a civil war but a real consensus choice of something the whole community can unite around.

hence no deadline, hence to threats, hence no hardware bombs.

blockstream are the ones that bypassed node consensus.
blockstream are the ones that gave only pools the vote.

but blockstream are not getting the pool vote they were hoping for. so now blockstream are looking for blaming everyone. rather than listening to everyone and programming something that the community want..

all of you blockstreamists are forgetting one small thing.

blockstream can code things differently to a way the whole community would be happy.
but no.. its a blockstream short cut or kill every opposer in the community and blame the opposers

all of you blockstreamists are forgetting one small thing.

blockstream can code things differently to a way the whole community would be happy.
but no.. its a blockstream short cut or kill every opposer in the community and blame the opposers

a version of LN can run now

but.
blockstreams version wants to use a new address style never used before, that starts
BC1
rather than use normal multisig that starts
3

this is all about making LN possible to easily swap coins from different chains in an LN channel between different coins


its got nothing to do with miners holding things up
its all about the new keypairs that are still being developed which wont be available until a later date and only acceptable to the network once blockstream have added new backdoors to slide in changes that nodes wont object to instantly

blockstream have sooo much invested in doing things only one way or no way at all that they are the ones holding it up

tl:dr;
LN can function today using native keypairs but blockstream want to do things differently, thus everyones ending up waiting on blockstream

the gpu days
there was Geforce (GPU) and ATi(GPU)
saying ATi should not mine because they were using openCL on thier GPU's simply because its unfair to Geforce. and arguing that ATi are exploiting and attacking bitcoin... now that would have been FUD

its was better to have ATi on our side to make blocks quicker to then increase the difficulty. to secure the blockchain. rather then throw them under the bus and say geforce only.. to later have some outsider grab all the ATi cards and over power the network.

yea Geforce didnt get many sales in the bitcoin market but we certainly secured the bitcoin network better because of ATi..

same is for ASICS.
so, which is more important? let btcc get more sales. or have a network with upto 20% more difficulty effect (security) working for us instead of against us.

all because some 6 month software that tried bypassing node consensus hit a hurdle in that bypass, with such hardware+software that has existed for years.


you keep thinking its 'pretending to do work'
the hashes match. they do the work they just do it in a way thats quicker than others

im laughing that in a restaurant. you would rather have the chef make customers wait an hour instead of 48 minutes. just to say ' its taking longer because there is only one way to cook a steak. the chef is rubbing it against his butcheeks to ensure it stays tender while having the steak being warm enough to not 'moo' at customers if they stuck a fork in it.

so here goes.

an exploit is where you find a way that MD5 becomes accepted hash instead of sha (giving a customer a mincemeat patty instead of steak)

an efficiency gain is where the end result is an actual sha as expected (an actual steak) that passes the sha test(cooked to customers request) and has simply done it in less time due to a technique that can help strengthen the network(cooked on a grill instead of rubbed on buttcheeks)...

whats next gmax proclaim bitcoin should only be sha'd using raspberry pi's. and let the difficulty become easily attackable by outsiders that choose to use asics..
or.. critically allow asics to do things most efficiently and the devs do a proper job by recoding their new unactivated software that wont hit hurdles

or

sit down with them and ask them how about re-code segwit to still do the same thing. but in a way that makes the community as a whole happy.
(1 merkle full node+pool consensus with segwit and dynamic blocks and limited txsigops and compact blocks and schnorr and anything else)

..

get passed the 30 second utopian sales pitch of the dreamland of 2 merkle segwit requiring tier networks, feature opt-ins(their word twisting way of hiding the non 100% guarantee of network benefit). and instead look at the flaws and ask yourself is there another way to code it and do the other things the community want to make everyone happy. rather than a half baked gesture.

why bomb/get rid of a huge industry based on a few months old code, which functionally is not a 100% promise of feature and only temporarily kicking the can down the road. when a proper full community happy version could have been done.

afterall.. UASF is suggesting to continue the 2merkle segwit kick the can down the road until late 2018(3 years of delays/waiting)...
so isnt it time to say just get on with a proper job version as plan B instead of sitting on hands and shouting bomb them until 2019

im laughing..

imagine it this way.
imagine if gmax refused to let ATI and asic boost use their efficiency gains..
then some hacker group or government decided to use it instead...

would you prefer that pools within bitcoin were using the best efficiency to secure bitcoin against outsiders. or
tell OUR pools to slowdown or  F off so that:
1 gmax can use backdoor exploits(the going soft has been admitted as a backdoor) to push in features without needing node consensus
and
2. allow outsiders to then use asic boost and previously openCL to be 20% more efficient, than pools that have been running for years.

would you actually be happy if 2011-2013 was just Geforce mined and then asic mined using a method that was 20% less efficient then some outside group could do it.

in my eyes
dont let gmax get away with excuses of why his 6 month old software just isnt up to par... just because they wasted a year building it that way.

instead he should have just done a single merkle full node+pool consensus back at the end of 2015 and close the options of going soft, aswell as adding in the other community feature desires in 18 months so that by now we would have had a happy united network of over 90%+ of nodes ready..

im still laughing at how he wants to make it so the network allows changes in 'softly' even easier in future.. come on atleast that should wake you up to the critical thinking of it being used by outsiders to trojan horse in bad features..

even if you are a blockstream devotee, you have to see the risks of 'if X can be implemented without changing nodes' it's a trojan risk even if blockstream are not the ones doing it.
wake up.

other word twisting from gmax

about how 3 year old hardware is causing issues for his 6month old software.. (im laughing at the illogic of gmaxwels time travel theory of going back in time to create hardware to attack software)

.. its much like blaming aTI's opencL for having efficiency gains vs geforce in the gpu mining days.. but then some dev makes some code years later and realises that the software wont work with open CL so would blame openCL

look at the word twisting..

1.
" a block that has even 1 segwit tx takes less time to verify then the worse case block with no segwit"
- no sh*t sherlock but what about BEST case block with no segwit,
- i could also hint at asking you to also factor in the extra time needed to strip the block ready to relay to a downstream non-segwit node but ill bite my lip and laugh at the one error in your word twisting for now

2. The consensus rule for non-segwit signature operations is 20k before segwit
- hmm.. thats BLOCK consensus before segwit...  but tx sigops is policy not consensus... but anyways.. but what about AFTER segwit activates
  for both block and tx.. as i said TXsigops is 16k

3. spammers are not going to voluntarily move their funds to use segwit keypairs to stupidly disarm themselves from quadratics.
so even if say 99.9% of people do move (the innocent crowd).. spammers only need to create 5 tx's to cause issues..
put it this way would you walk into the ganglands of some new york 'hood and ask the 'gangsta's to use flowers and not guns, thinking they would happily comply.
wake up, spammers want to spam so they wont disarm themselves. but you G1megmax have not helped the situation