Bitcoin Forum

I wrote a post on my website to try to clear up the misunderstandings that people have and spread about Segregated Witness.

http://www.achow101.com/2016/04/Segwit-FUD-Clearup

If you think I missed something or made a mistake, please let me know and I will change it. Feel free to discuss what I have written however I ask that you keep the discussion more technically oriented and less politically.

If you have any additional questions about segwit, I will try to answer them. If I think it is something that many people will ask or misunderstand, I will add it to the post.

Local rule: no posts about blockstream or claims that blockstream controls core development.

*Disclaimer: I am not one of the developers of Segwit although I have done extensive research and am in the process of writing segwit code for Armory.

The segwit disaster:

https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/page-462#post-16802

nice writeup.   minor nits:



Better: Segwit is kludgy hacked together software that is not ready.

change to

Segwit deployed as a soft fork is sometimes safer than a hard fork. A soft fork means that backwards compatibility can still function even if they no longer know what they are processing. Old versions of Bitcoin software will be able to function but without fully checking new features when a soft fork is deployed.

In contrast, a hard fork and softfork both require that every single Bitcoin user upgrade their software to support the new consensus rules, but softforks can still function by just confusing the old clients into not bothering to check what they are processing, making the old node no longer full nodes. but 'compatible nodes'

the danger is that the majority do not upgrade because they have been lied to saying that there is not a problem, and basically passing a blind parcel of data around the network that they dont check.

hard forks with a small priority grace period to kick peoples ass into action can be safer. because by upgrading you regain full node status, and by making it a short priority grace period you wont run into the issues of lazy people avoiding the upgrade because they stupidly think there is no reason to do it straight away.

---

change to
The other difference is whether to include the witness data in the block size count, and to maintain backwards compatibility while also having the capacity increase, it was decided to not do so. meaning the point of the maxblocksize variable becomes useless because physical data will no longer be 1mb, but more

PS.
if you think the above is Fud. then i dare you to stick with 0.8 for the rest of your life and try to claim that you are still a full node. and pretend that for the next year every real data hitting your hard drive will continue to be less than 1mb.

please try not to play down the risks like a biased fanboy, pretending the world is made of candy floss clouds and everything is perfect.

Wanna post that here? Besides the fact that that post is full of incorrect statements, I don't want to post in that cesspool of a forum.

Thanks, I fixed those.

No (okay, maybe like three words of what you said I might include).

I agree that they are just "compatible nodes".

Not true. The standardness rules says that anyonecanspend outputs are non-standard and are thus not relayed. Thus non-upgraded nodes will consider segwit transactions as non-standard and refure to relay them. However, when it sees that the transactions are in a block, it will still be able to validate the block and accept it even though it contains non-standard transactions.

The physical data will be more than 1 Mb for segwit capable nodes. This has never been claimed otherwise.

The real data hitting the hard drive will be less than 1 Mb for a non-segwit capable node. Because it doesn't have the NODE_WITNESS service bit set, then it will not receive blocks and transactions with the witness serialization format. The data in the normal transaction format will still be less than 1 Mb.

You should do the same with playing up the benefits of hard forks.

= blindly accepting a block that contains data it cannot verify..

can you atleast wear your impartial hat for 1 minute to see how this can be abused..
EG someone makes a nonstandard tx to pay themselves alot of bitcoins and gets it added to pool that wont check it.
(yes its possible to push tx to pools you know of directly..)

please just take off the fanboy hat for 1 minute. and put on the sceptical, impartial, bug finding, risk analysing hat.. just once

Sure. This is my impartial view of various scenarios that could attempt to exploit this (also the impartial view that I try to post with).

Scenario 1:
A malicious node (not a miner) creates a transaction that is invalid under segwit rules but valid under old rules and broadcasts it to the network.

Result:
Non-upgraded nodes see the transaction and label it non-standard. They don't relay it and reject it. Segwit nodes see the transaction and they find it invalid. They don't relay it and reject it. Segwit miners do the same as the segwit nodes and the transaction is never included into the blockchain.

Scenario 2:
A malcious miner creates a transaction that is invalid under segwit rules but valid under old rules and includes it into a block he mines.

Result:
A non-upgraded node would validate the block and accept it because it is valid under the old rules. The segwit nodes and miners would see it and reject it because it includes an invalid transaction. If we assume that the segwit miners have a majority of the hash power (as it should be when segwit is deployed with a 95% threshold), then the malicious miner cannot keep up with the network and produce a longer blockchain. The rest of the miners would produce blocks that orphan the invalid one and non-upgraded nodes would go back to the correct blockchain after it grows longer than the malicious one.

If we assume that the malicious miner has a majority of the has power, then we have ourselves a 51% attack which we all know is a problem by itself. This attack is made worse since the old nodes could be tricked to believe that those malicious transactions are legit and that miner can basically trick that part of the network into thinking the miner has more money than he actually does.


Short of a 51% attack, I don't see a problem. Do you have any other scenarios you want me to examine?

ur assuming a pool cannot made a funky segwit without 95%.. if it was impossible.. then that blows apart your whole argument about backward compatibility accepting segwit.

so lets assume a pool got the code on day one and made a funky tx, added it to a block before any of the other pools upgraded. they would treat it as a valid block with a funky tx that they just blindly pass on.

EG lets say segwit is not publicly released for 2 weeks. but a pool grabbed the code from testnet today and made loads of transactions in their pools paying themselves. knowing they have 2 weeks of never being checked

hash power doesnt even come into the argument

What do you think about the using of segwit?
Let me explain.
Today almost nobody cares about the transaction size and the fees.
What will force the users like casino, exchanges, doublers, etc to abadon their currens software which accepts p2pkh addresses and move to segwit addresses?

exactly. its being falsely told that upgrading is not a priority and you can happily stay with old versions.... basically making yourself more impotent due to pure ignorance and lack of true information.

a hard fork with a short grace period emphasizes the priority and gets people to upgrade. its happened atleast 3 times before where loads of nodes upgraded in hours... its not a big deal to implement. if you highlight the priority of implementation

Clearly you don't know how segwit works. A segwit output is understood by old nodes as an anyonecanspend outputs. Spending a segwit output has a blank script sig and this is valid because the stack is not 0. So if anyone were to create a segwit transaction now, anyone could spend from the output. Segwit does not allow people to spend from normal p2pkh or p2sh outputs in a special way, they still have to spend from them in the old way. The change of segwit is the new output types and spending from those output types requires an empty script sig and a witness. I suggest that you read the BIPs for the full technical description of segwit and you should really understand how it works. I linked them in the bottom of the blog post.

The fees are lower. I'm pretty sure a lot of people care about the fees, especially if you are making many transactions. Those fees do add up. Since the size of the transaction that goes towards the block size count is less, the fees will thus be lower and that incentivises people to use segwit.

i do understand it. but your diverting away from a block containing transactions where the pool is paying themselves..  to talk about a different scenario about spending later....

because after the 2 weeks of the transactions being (kind of stuck) in a block.. when segwit becomes live for everyone else. the pool can then move the funds using segwit legitimately because they are moving funds from the confirmed blocks using the privkeys they own.

only way to prevent it is to roll back the chain two weeks orphaning off 2016 blocks just to make that malicious block disapear from being confirmed..

as for your newly elaborate scenario about anyone can spend.. those transactions wont be accepted in mempool of old clients. not until segwit is live.
so as i said. a malicious pool can create a block. with a 2 week headstart (2016 blocks) to secure their transaction. and then when live. they can spend the transaction.

Sorry, but I still don't understand your scenario. Can you describe it more specifically with reference to the output type that was used in the outputs?

You seem to prefer a theymos ruled forum over an uncensored one. No surprise.

1. malicious pool makes a segwit transaction to pay themselves lots of coins. from an address they dont own to an address they do own. BUT. because its 2 weeks before anyone else has segwit, it appears to others as a funky transaction. in a block.. so they blindly accept it as a block with funky transaction.

2. so now the receiving addresses is technically classed as having lots of funds.. but no one can spend them as they dont have the keys to do so. so the transaction is locked in the block unspendable becuse although people can try making an anyone can spend, it wont be accepted into other blocks as its not technically an anyone can spend..

3. weeks later when the malicious block has over 2000 confirmations. the owner of the privkey that received the funds can then move them because segwit is now live and segwit pools will see that the transaction is spending funds with 2000 confirmations(even though the tx before that is technically invalid)

The biggest property of segwit is that the more you talk about it, the more FUD you get  ;D

If changing 1 to 2 require 18 months of talk, then changing several thousand lines would require many decades of talk if not centuries

No, I prefer a forum where you can have a semi-intelligent discussion about the merits of the various software proposals instead of a forum where every single person has a bias towards one specific proposal and uses personal attacks and spreads misinformation about other proposals. Also, that thread is really freaking long and I don't want to read it and attempt to debunk all of the false information in one post.

---

This is simply not possible. Anyonecanspend is an output type, not an input type. It is not possible to spend from addresses (from now on I will refer to them as p2pkh and p2sh outputs) that you don't own the private keys for. If it were an anyonecanspend output (like an actual one or one in segwit format) then, as the name of the output suggests, anyone could spend from that output legitimately and create whatever outputs they want.

I don't see how that would even be the case. A segwit output would be able to be spent by everyone before segwit's activation because it is anyonecanspend.

See above.

LOL. You drive a personal attack against 'every single person' there by accusing all of them of using personal attacks. You are a joke.

you do realise that its not actually an anyonecanspend script. and as soon as someone without segwit tried to spend it in an anyonecanspend.. it wont get accepted by legit ethical pools...

for instance. lets assume that i knew someone else made a segwit next month. and i knew of 1 pool that had not upgraded. by saying that old clients can spend segwit. means that i can push the transaction to an old pool and spend someone segwit..

it is said it is LIKE an anyonecanspend and treated as an an anyonecanspend, for the sole laymen purpose and analogy purpose of a node not understanding what it is and blindly passing it on.. not because it actually is an anyonecanspend. otherwise thats another way of breaking bitcoin.. by old clients spending segwit transactions.(which u think is possible)

only a malicious miner can bend their rules and accept a malicious transaction into their block, to be treated as funky by everyone else blindly accepting it as funky. but if USERS tries to make a transaction and pushed it to a pool. unless the pool was malicious and wanted strangers to spend their previous tx, then it wouldnt get in a new block. so people cant spend the funky tx...

this is why i have used the word funky instead of anyonecanspend. because the anyonecanspend was for analogical reasons not technical

my scenario is about the block creation by a malicious pool. not the user creating transactions (which pools would dump)

Yes, I know. Maybe I wasn't clear, but I meant BEFORE segwit's deployment. Right now, you can create a transaction that has a segwit output. Right now that output is an anyonecanspend output.

Pools would not accept an attempt to spend a segwit output as anyonecanspend AFTER segwit's deployment.

They do not blindly pass on segwit transactions because those are considered non-standard and thus rejected.

See above.

AFTER segwit's activation, such malicious transactions spending segwit outputs as anyonecanspend are invalid.

Anyonecanspend is technical, not analogical. An OLD node validates segwit outputs as anyonecanspend because under the old rules they are anyonecanspend.

Miners won't mine an an invalid block.

maybe time you re-read it.

remember NON-segwit clients do not change. so all your fluffing around saying things will change means that you are assuming that old clients will some how understand things differently.. please think about that..

again. let this settle in
non upgraded clients do not change. they treat the transaction the same now as they would in a month. and so if you are saying that old clients can spend segwits now then you are saying that they can spend them later too... but they dont change..

my reading is that segwit transactions ARE NOT!!!! i repeat.. ARE NOT anyonecanspends. they would fail the test of anyonecanspend. HOWEVER for ONLY analogy purposes people say segwit transactions added to a block will be blindly accepted just like anyonecanspends are blindly accepted by old clients.

now onto the separate issue you keep meandering to..
please do not confuse the issue of block confirmed transactions with the relay of unconfirmed transactions.

so one more time

A POOL (not a user) a POOL adds a segwit transaction to its block, but because segwit is not activated by other POOLS the malicious pool can grab any input and pretend it is theirs becasue it knows the network wont be checking signatures yet. so it doesnt need to sign the input... and then give the the destination as a real privkey owned by them..

because the other pools dont understand segwit. they will blindly accept the block because they cannot check the signature of the input. and so it gets confirmed and the network accepts it. a confirmed transaction in a block where the originating funds do not belong.. but cannot be validated because the pools dont know what they are handling.

2000 blocks later. when segwit is activated the malicious pool can use the malicious block transaction as a valid input because it has 2000 confirmations and because the pool has the privkey to now sign (what was the old destination) as a new input for a new transaction to then send it out as a legitimate transaction to all the ethical pools

Good article on your blog, thanks for taking the time. I enjoyed the read.

The node itself does not change, but the context in which they are spending in does. Thus, if RIGHT NOW you were to create a transaction with a segwit output, it is an anyonecanspend output and anyone can spend from that output. However, after segwit activates, if you were to create a transaction with a segwit output, it is not an anyonecanspend output and only the recipient can spend from it. To a non-segwit node, in both cases, it could create a spending transaction treating the output as anyonecanspend. Before the deployment, the spending transaction would be accepted, but after, it would be rejected.

To new nodes, they are not anyonecanspends. To old nodes they are. It is not an analogy because old clients will validate it according to their rules and that is as an anyonecanspend output.

Okay, maybe I should stop use anyonecanspend outputs. Maybe this will help you understand it:

A p2wpkh (a type of segwit output) is as follows

The corresponding input scriptsig is then just

For a non upgraded node, it validates this by first pushing 0 bytes to the stack, then pushing OP_0, then pushing the 20 byte hash of the witness script. The stack will look like this:

Because the stack is not zero, it is true and thus validates. Anyone can produce a transaction which has a scriptsig of 00 and with a segwit output, it is considered anyonecanspend by old nodes because anyone can create that scriptsig.

However, segwit nodes will recognize that he OP_0 means it is a version 0 witness program and validates it as such.

Segwit only creates a new OUTPUT type that is spent in a specific way. It doesn't affect how other CURRENTLY USED OUTPUT TYPES are spent. If you have a p2pkh output, to spend it, no matter of when, you MUST spend it as it is currently done. This will not change. Segwit activation does not make p2pkh and p2sh outputs magically be spent differently. Because the pool cannot spend from a p2pkh output that isn't theirs, it can't do this.

The pool cannot grab any input and spend it as their because the way to spend the currently used output types are not going to change.

So the security is to make sure this output can never be spent by old nodes, how can you be sure of that?

Suppose two pools with 60% hash rate, and they are sitting on the side line watching the mined blocks, once 35% of blocks are mined as segwit support, they switch to mine segwit blocks and activate it, then there will be many segwit transactions out there, and then they switch back to original software

Now network are full of anyonecanspend transactions that is free for them to grab, and they have 60% of hash power so their chain become the longest, since majority of the nodes are still old style nodes (as in soft fork you don't need nodes to upgrade),  these nodes will build on their chain, and the rest of the segwit nodes will fork into a minority chain since now they reject old style blocks

So it is a mess after this accident, all the people who used segwit transaction will lose their money and they don't even understand what happened

op_true is used for anyone can spend.. and valid to be relayed and valid/accepted into blocks
currently op_0 does nothing.. so would get rejected when relayed but accepted(blindly ignored) in blocks

however after segwit is released op_0 can be treated similarly to op_true by upgraded nodes. but still rejected at relay and blindly ignored in blocks by older nodes.

there is a difference

And this one, replace the word "bitcoin" with "segwit"  ;D
https://www.youtube.com/watch?v=4APcgsRdW6w

Nope. It's all in the deployment. There is a lock in period (grace period) before the rules go in effect. See BIP 9: https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki for how the deployment actually works because they will be using versionbits.

Uh. No. OP_0 is currently treated as a counter, but basically as a NOP now. After segwit is released, it is treated as script versioning. The OP_0 isn't the part that matters, but rather the fact that the stack is not zero or empty and thus is true. That is what makes it anyonecanspend because if the scriptsig is empty then the stack will always evaluate to true.

LMAO!

i love how you try to remain disagreeing, but when you try to explain it you are actually explaining that the op_0 is like i said NOT anyone can spend. and so its not exactly like an anyone can spend transaction at all.. like i said. and that the use of the example of anyone can spend is only as an analogy comparison and not a technical duplicate..

so back to my point. if a malicious pool adds segwit transaction the OLD clients will look passed it. meaning that the pool could grab any input from anyone and make a transaction that has a destination of a privkey the pool owns..

once locked in the block. other pools and nodes will see it as a FUNKY tx to overlook and they themselves cannot spend it. but when segwit is released, the malicious pool can grab that now 2000 confirmed tx output, sign it as an input because they have the key of the funds that are now 2000 confirmed. and so when they send out the transaction it would then be verified properly and see that it says the funds are valid because they are confirmed. and a valid key was used on the new tx.

Fine, semantics, whatever. When I refer to an anyonecanspend output, I will be referring to a output that can be spent without knowledge of the private key for the address.

NOOO! The anyonecanspend output does not affect the input. What part of that do you not understand? If I take any UTXO and put that as my input, I HAVE TO SPEND FROM IT AS THE OUTPUT DICTATES. THE INPUT SCRIPT COMBINED WITH THE OUTPUT SCRIPT HAVE TO RESULT IN A NON-ZERO NON-EMPTY STACK!! The outputs of the SPENDING transaction can be anyonecanspend but THAT DOESN"T AFFECT HOW THE INPUTS OF THE TRANSACTION ARE VALIDATED!

Notice the activation happens after the grace period. What prevent miners from switching back to original version after the activation? If there are so many anyonecanspend transactions to grab. You must collude with miners, so that is the problem with segwit, without miners cooperate, this system will fail, and bitcoin by design should not need devs to collude with miners to implement a change, that is too large degree of central planning

Even if you can collude with miners, in case the segwit upgrade failed, e.g. lots of security problem in live traffic after the activation, because of these anyonecanspend transactions, miners can not roll back to old version, since all these transactions will be spendable if they revert. In that case bitcoin is dead either way: Keep running segwit, customer losing money, roll back, customer losing money

ok i think you are getting confused..
so pretend it is sunday the 3rd of april. the network is not using segwit.
BUT
on this same day a malicious miner makes a block paying a destination address he owns. dstination/output: 1MaliciouspoolAddress
he makes the block that has the transaction included to pay 1MaliciouspoolAddress
he owns the key for 1MaliciouspoolAddress

BUT is using inputs of funds he does not own. but knowing he is making a segwit transaction he doesnt need to worry about signatures because the old clients will ignore it they wont get to see the witness data so they couldnt even validate the inputs even if they tried. to them its just a funky transaction..

so he is makes the block.. and the network accepts it because although the transaction should be invalid.. the segwit bait and switch allows for transactions in a block to be overlooked.

and so it becomes part of the chain..

then LATER lets call it May 17th and segwit is available.
the block created on april 3rd now has 6336 confirmations with a transaction inside saying that 1MaliciouspoolAddress has coins.

to old clients they are thinking its a funky tx that is unspendable(its not a op_true like you thought but op-0).. but to the segwit clients they can see the 1MaliciouspoolAddress and they see the tx is confirmed with 6336 confirmations.

so a new tx is created in May and signed using the private key of 1MalicouspoolAddress and pushed out to the network.

remember old clients did not orphan the block on the 3rd of april..
remember the next transaction in May is using the output 1MalicouspoolAddress as a new input.. and a valid private key aswell

when segwit is available to all pools. then all the pools instead of ignoring shit, they would see a new transaction waiting to be added to a new block. where there is a signature to a valid publickey input because as i said many times the pool would have put the funds into a key they own. and that new transaction would go into that new block allowing the funds to be moved legitimately..

I think you're getting confused about how bitcoin works

What about a segwit transaction would make it so that he can ignore the signatures? Why would he be able to spend from an input he does not own?

The input does not dictate how the output is spent, the output does. If the output says that it needs a signature in the scriptsig (e.g. a p2pkh output), then it needs a signature in the scriptsig regardless of segwit activation.

I think I understand Franky1's sense of security here, let me make a simpler example:

As soon as segwit code is out, some malicious miner create an illegal segwit transaction and mined it into a old style block, for example block 420001. All the old nodes will accept this block since they can not verify if the transaction is correct. So this block containing illegal segwit transaction will be berried deep down until the day segwit activates, lets say 425000

After segwit activation, all segwit nodes detected this illegal transaction (because they could not find the witness part at all) and illegal blocks,  they have to abandon all the blocks after this block and build from block 420001, since that is the latest block they consider to be valid, so network split into two chains from 420000 and all the transactions after 420001 disappear in segwit nodes after the activation

1. because the block was made before other pools had segwit.. so they would blindly accept the block containing the funky transaction!!!!!!!!!
again. the malicious transaction would be put into a block by a malicious pool BEFORE others had segwit. knowing that old nodes would blindly not care about it because they dont understand it and wont check for signatures because they cant see the witness(signature) area

2. exactly.. the initial transaction in the malicious block has NO signed input. but is not checked because its a funky tx.

3. all the scriptsig crap is stored OUTSIDE of the tx, in the witness area.. old clients wont see it and blindly accept it without a signature.. thats the whole point of segwit.

now when a second transaction is made later it is grabbing the OUTPUT of the first transaction (not the input) which basically says 1MaliciouspoolAddress gets the coin. and uses the OUTPUT as an input for the second transaction.. and signs for it normally. because the pool owns the key for 1MaliciouspoolAddress and the confirmed block is saying that 1MaliciouspoolAddress now owns coins thanks to the funky tx before segwit

Thank you Knightdk.
This is a clear explanation of SegWit and I'm looking forward to its implementation. Because of your article I can clearly see why it makes total sense to implement SegWit before making the block size huger.

We don't need a larger block size if we are filling that block size with bloat.

You do present a valid flaw of a hypothetical one-time remotely possible transaction that may or may not exist. Do you have a solution that does not involve a hard fork? Because I am sure a hard fork also has many more hypothetical flaws.

no, because any solution involves people upgrading to have that solution.. and so the only real solution is to stop playing the "everything is ok" card, blindly turning old full nodes into less then full nodes.

but to instead say.. look everyone its time to upgrade, THIS MONTH

doing all the crap like saying its safe not to upgrade. or 12 month grace periods so no one hash to rush or bother right away does absolutely nothing to kick people up the ass to upgrade. meaning things can go wrong.

the only solution is to not have such lax policies.


but it this way. what would have happened if in 2010 peopler were told, dont worry about the millions of bitcoins created in 1 transaction.. we will give you 12 months to upgrade everything is fine

what would have happened in 2013 when the DB bug became apparent. and the devs told everyone.. dont worry you dont need to go above 500k limit we will give you 12 months to upgrade in your own time..

Here is the flaw in your logic. The scriptsig stuff is only stored outside of the transaction for the NEW SEGWIT OUTPUT TYPES. Segwit specified two new output types and only those two output types can have their signatures not in scriptsig. If you are spending from an OLD OUTPUT TYPE LIKE P2PKH and P2SH then you still have to have the signatures in the scriptsig.

Maybe the example here: https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#Example will help you understand it better. Because one input in that example is p2pk, IT MUST HAVE THE SIGNATURE IN THE SCRIPTSIG. The other input is a p2wpkh (new segwit output type) which requires that the signature is in the script witness.

He doesn't.

Even though the article is nice, I think that you're wasting your time with this thread. Initially, they were complaining that Segwit is complex and now they're making up scenarios in which it is supposed to be 'insecure'. I doubt that you're going to reach a point where they admit to being wrong.

This is false IMO.

you realise the whole point of segwit is that scriptsig is not part of the transaction right... you know to prevent people from tweaking it for malleability..

thus old clients wont see that area to be able to check it or not, so having a signature or no signature is meaningless as it would still be the same funky tx in a block..

then later after proper segwit is released the new block will have a separate transaction spending the pools funds. because the pool has the key to the funds

if your saying that old clients can read signatures of inputs of a segwit transaction. then that just defeats the whole malleability fix proposal. because segwit promises to not have signatures as part of the transaction. and its all put into a witness section that is not 'seen'
meaning old clients dont see the signatures and treat it as a funky tx.

remember the signatures are moved. to allow them to be processed differently. and old clients cant reject the transaction simply because it doesnt have a signature, if its locked into a confirmed block by a malicious miner. instead its just overlooked.

then later when they want to spend the funds they use the privkey to the public key they put as the destination(of previous transaction). and because the details of the destination are confirmed as holding funds. then the destination funds can be spent in a normal way.
(if it could reject a block with a funky tx. then that defeats the whole backward compatibility promise)

PS, lauda has no clue, he has just been handed a glossy image to look at and now thinks he is an expert. he has no clue about a single line of code.
maybe lauda cant admit that segwit is now on version 5 and still not proven to work, its not even publicly available so he has no proof its bug free or that people cannot abuse it.

i think his blind faith in something not yet released is clouding his judgement.
now i wait for him to link in his glossy images of what segwit proposes and say how everything is more perfect then a sunny day

To maintain compatibility, p2sh, p2pkh, and p2pk outputs are not change at all. There is nothing that changes how to spend from those outputs. So if you spend from p2pkh and p2pk outputs, you are still vulnerable to transaction malleability attacks (p2sh outputs are different because with segwit there will be p2wpkh and p2wsh outputs nested inside a p2sh outputs and those aren't malleable, but the old type are). The only way to not be able to have your transaction malleated is to use the segwit outputs types as your inputs.

Your right, SegWit might not be backward compatible if some pool today add 2 tansactions to the block today: Send bitcoin to SegWit address anyone can spend and spend it in second transaction without the signature to normal address. Because witness part where the signatures are stored does not exist today, this SegWit transaction wont be backward compatible after SegWit is activated. This means SegWit transaction signatures has to be just validated only after SegWit activation, so no need to make the block created today invalid if it contains SegWit transaction without the signature in witness part (which does not exist)




It is important to understand SegWit should be used only for low value transactions, because softfork rules can be changed anytime with 51% of hashpower and future block versions might not use SegWit withness data to check signatures anymore, so really anyone could spend SegWit transactions.

But you should be not surprised because you dont require the signature to be used to spend Bitcoins from SegWit transaction given today Bitcoin consensus rules (which requires hardfork to change) - so keep SegWit only to low valued transactions should be reccomended.

And indeed if SegWit transactions become used for high value transactions then if miners become unprofitable with lowering block rewards, they may use the hashpower to softwork again and get the SegWit transactions themselves legitimately (from anyone fool enought to send anyone can spend transactions by Bitcoin consensus rules).

You are horribly misunderstanding segwit just like franky is. You need to realize that segwit does not affect how p2pkh, p2sh, and p2pk outputs are spent so transactions spending those outputs are still malleable. The part about not including the signatures in the scriptsig is only for the segwit output types.

This I meant, use SegWit transactions for low valued transactions only, because they meant to be as anyone can spend and the signature is required only in withness data by certain block versions, but this signature  in withness data requiremet can be changed with future soft fork and new block version again.

They are not meant as anyonecanspend outputs after the activation because they aren't anyonecanspend outputs after segwit activates.

Literally anything can be changed with any kind of fork. This is not a valid argument.

I understand this, these SegWit transactions are meant as anyonecanspend outputs after the de-activation, the same way as today. The only thing what protects SegWit transactions from anyonecanspend after activation is just another Soft fork which deactivates use of withness part to check signatures, users should be well aware of this and act accordingly.



No, you can not spend normal transaction after any Soft fork without valid signature, but you can spend SegWit transaction without signature afer Soft fork, so "Literally anything can be changed with any kind of fork" is invalid statement.

What do you mean deactivation? There is no plan to deactivate segwit, why would there be? By that logic, we shouldn't have use p2sh or OP_CLTV because after activation another soft fork can be used to deactivate it and those features are gone. This is an unnecessary fear and is just spreading FUD to get people to not use segwit.


You can create a transaction with the segwit outputs before the fork right now and be able to spend that without a signature. you cannot do that after the fork because after the fork you will need a signature to have that transaction considered valid.

There are no plans for deactivation today, but it might change in future. Bitcoin is meant to be trustless, so Im not going to store Bitcoin long term with SegWit transaction, because I would need to trust another Soft Fork wont deactivate the use of withness part where signatures are checked. No FUD, just rational from my part as I will be using SegWit transactions only for hot wallet and low amounts, not for a cold longterm storage.



Yes, but after another Sof Fork you could spend SegWit transaction without signature. But you cant do it with normal transaction after Sof Fork. That was my point.

You can use the witness outputs nested in a p2sh output (the kind of address that segwit wallets will be creating). The witness output scripts act as the redeemscript of the p2sh address, and because that is hashed, no one will be able to spend your coins even if for some reason a soft fork happened which deactivates segwit.

This is an irrational fear and not a particularly valid one because segwit fixes the transaction malleability problem, and deactivating it would simply reintroduce the issue, something that no one wants to happen.

you are as naive and stck in the box as lauda..

its time you took off the fanboy hat and thought outside of the box.

i said the malicious pool will make a segwit!!!!!!!!!!!!!
a segwit transaction
a segwit transaction
a segwit transaction

why the F*ck are you talking about p2pkh... seriously..

so one more time.

malicious pool makes a segwit transaction.. that is using op_0.. not a op_true..(they are different things)
the transaction grabbed a random input from anyone. knowing that right now today the signature was not important. because current network wont see or care about signatures.(because of op_0)
again remember its a segwit transaction not a standard p2pkh.. so the arrangement of where the signature should exist would be different and thus old clients would just see it as funky
it puts it into a block.
so now its in a block, old clients cant just drop it. instead old clients look passed it not checking it because its set as op_0 so they will blindly say it the block seems ok even with the funky TX..
this funky Tx has a destination output of 1MaliciouspoolAddress (which the pool does own the privkey too, and will use later)
lets say this happens today.. long before segit is a thing

now.. have a coffee and let that part settle in.. do not confuse the part above with the part below.

ok, fast foward one month..
the pool has lots of confirmations accrued for that transaction and no chance of an orphan..
now all the pool needs to do is spend that 1MaliciouspoolAddress output in a new input the standard way signing it with the privkey they do have

It is time you actually think about what you are saying and realize you have no idea what the fuck you are talking about.

Define a segwit transaction. There are segwit outputs, p2wpkh and p2wsh. When these outputs are spent by the input of another transaction, the signature is not in the scriptsig. THAT IS ALL THAT THIS DOES!

How so? How can they grab any input from anyone if the output that they are spending requires a valid sig?

Let's simulate this using specific transactions and actual technical terms. Pick a random transaction and lay out exactly how this would work with the OP codes in the inputs and outputs.

---

This is what you are telling me:

Pick a random transaction output A. I chose the first output from https://blockchain.info/tx/eecd0da0ed0c5c6a633ff23c30591af798592f4b62d10a24e21739dde0270e7f
The output is
To spend it, I need to provide a valid signature in the scriptsig. The scriptsig in the spending transaction will look like

THIS DOESN"T CHANGE AT ALL!!  WITH SEGWIT I CANNOT SPEND THIS INPUT WITHOUT PROVIDING THAT SCRIPTSIG.

seriously you said it yourself but you are not realising what you are saying
read the part i quoted you.. and realise that because OLD clients wont see the signatures because of exactly what you said.. then there does not need to be a signature..

because old clients wont validate it.. they would blindly overlook it if they seen a funky transaction in a block that has no scriptsig where it suppose to be..
so a malicious miner can just not sign it. (because they dont even have that random inputs key), knowing the rest of the network would overlook it.

its only weeks later as a separate transaction that things will be signed. and what would be signed is what was the output address of that funky transaction that has been blindly confirmed by 3000+confirms.

But only the segwit output types can be spent like that. Only p2wpkh and p2wsh do not need the signatures in the scriptsig. And those outputs right now do not exist, or if they do, they are intentionally created to be able to be spent by anyone.

welcome to the conversation.. like i said pages ago. a MALICIOUS pool grabs the code from testnet/github. to do exactly that..

finally i think you are piecing it all together, bravo.

like i said. made today. intentionally. knowing its locked and unspendable until segwit is released in a few weeks.. it can spend the funds now confirmed to 1MaliciouspoolAddress

The code is different from actual transaction outputs. Actual transaction outputs do not exist that are the segwit output type that anyone can spend from. They can't just use that code and grab any random output to spend from like that because that isn't how it works.

why the F*ck are you talking about anyone can spends.. ur obsessed with trying to make op_0 sound like op_true..
please think outside of the spoonfd mantra of the glossy magazines you have been handed

i have no clue why you are trying to bring in op_true scenario's into this..

sit back, dont reply. make yourself a cup of coffee and in your head think only about op_0 transactions. repeat the words op_0 over and over until you forget about anyonecanspend.(op_true/op_1)

once you mind is clear. think about the lack of signatures seen by old clients and not validated by OLD CLIENTS due to op_0
take a breath. relax
take another sip of coffee..

then think about that transaction being locked and unspendable by old clients.
imagine time passes you by nothing happens. more confirmations pile up.. nothing happens..

then when segwit is released oh look there is an output that has 3000 confirmations that segwit clients understand. and the pool has a privley for that output. meaning it can happily make a new transaction to spend it legitimately using the release segwit

I'm not talking about OP_TRUE"s. Why the fuck do you think I am talking about those. When I refer to anyone can spend, I mean that the script is in such a way (doesn't matter how) that anyone is able to spend that output.

Why don't you do as I said above and give specific examples of how exactly your attack would work. And by specific I mean writing out what the input and output scripts would look like and taking a random transaction that currently exists and explain how that works with the attack.

"Before being added to Bitcoin Core, it will be tested very thoroughly over several days or even weeks to make sure that it is all ready."

Is that really enough?

It is also being tested right now and has been tested for the past couple of months since the first segnet went up.

With the amount of testing going on, it is enough.

Segwit is conceptually sound. When it comes to implementation, there can be bugs, and that is what the testing is for, finding the implementation bugs and making sure that it is implemented to spec in their software. It is up to the developers of the other software to follow the publicly available specs to properly implement segwit.

Also the segwit irc is #segwit-dev and that is where segwit discussion happens, not #bitcoin-dev or #bitcoin-core-dev

nooo
backward compatible soft fork means that segwit has be be sure to work with other implementations that already exist.. not the other way round

this is why a hard fork would be better. as it forces all implementations to be on the same level playing ground. rather then a handfull of coders just making sure their version works and blaming everyone else for not upgrading if it hard forks..

seriously are you that devoted that you can no longer think impartially

It is backwards compatible. If the current implementations that already exist chose not to use segwit, they would be fine and can continue to function. What I meant is that if those implementations want to support segwit, it is up to them to implement it in their own software without any bugs. They can follow the publicly available documents that specify the exact changes that segwit makes.

If I don't keep reading threads like this every week, then the new technical jargon being spouted out in these threads will leave me in the backwoods. I can imagine people who are not so tech savvy will get confused easily.
How is this supposed to become mainstream again?
Certainly, we are going to have to come up with easier explanations for the consumption of the general public.

Gold certainly isn't this complicated! ::)

but how do you know that.. like i said have they tried segwit on the testnet and then had other non-segwit implementations on the same chain to see how they react..

like i said unless they are going to try everything they cannot promise everything

If I sold you a car radio, and claimed that it was 'backwards compatible' with your car, and then later you read the manual and discovered that it causes your airbags to no longer work, and you'd have to buy some new airbags from me as well just to be safe and secure again - you wouldn't call my radio 'compatible' with your car, would you?

i know what you mean. i have tried to use the least technical jargon, EG saying how its funky tx as oppose to op_0.. but there are some that try to be technical by saying UTXO, instead of unspents.. yet they are so technically one-minded, they cant think outside of the box at the bigger picture.
it becomes even funnier when their use of buzzwords fail. it adds to the confusion because people blindly believe them because they have thrown in some buzzwords to seem technical.

by far the worsed culprit of this is Lauda. who pretends to be a know it all but thought that bitcoin-core wrote the code in java..

they have blind faith that things will work perfectly. when the mindset should be to treat it as always broken until you tried every single different possibility until its not broken anymore.

blindly saying something is perfect or works before its released is like bill gates saying that blue screens of death will never happen
even now many smart people do not instantly download the new versions of windows. but wait for a couple service packs to be released. and that is the mindset everyone should have

They will be. Prior to deployment on the mainnet, segwit will be deployed on the testnet. I do not know whether they have had non-segwit nodes on the segnet chain. It is fairly trivial though to implement a node to run on segnet and see if it works.

If you think that they aren't going to test everything, why don't you help out and test things yourself? It is all publicly available.

Clearly that isn't backwards compatible, but that is not an analogy for segwit.

That's the problem with current core's approach, they don't make things easier to understand, they make it more difficult to understand, thus any technical debate would easily extend to several thousand lines and just become TL'DR for average people, so no decisions can be made

In principle, changing the current way of signing the transaction is a simplification of the transaction format and can be considered an improvement towards simpler design (even that require months of discussion). However, by doing soft fork, it separate the signature and scripts into another block structure, that is a total complication of the bitcoin architecture and created many new added logic that make the system much more error prone

Of course you can make millions of tests and make the system work to a certain degree, but a slightest future change to the environment will make majority of those tests fail and certain parts have to be redesigned, but you can't do this when a financial system is on 24/7 live traffic. Complex system is fragile, you don't want to build a financial system on a rocket that can explode any time

The complex way of turning a page  ;D
https://www.youtube.com/watch?v=GOMIBdM6N7Q

knightdk - You really are one of the most knowledgable posters on this forum.

Ignore any pathetic trolling you get in this thread & keep up the good work.

lol knowledgable.
1. he does not know if segwit is fully backward compatible, as he doesnt even know if other implementations have been tested to ensure there are no bugs.
afterall if a v2 segwit can cause a bug with v3.. then obviously there is a chance that segwit can cause forks vs old clients

2. the anyonecanspend analogy is so much fail. NO ONE can spend because right now it would look like a funky transaction that is unspendable. because no one would see the sigops. and when segwit is released its already in a block covered by hundreds of confirmations so the other features like not revalidating old blocks before a checkpoint wont be done as its falsely presumed the checks must have been done by other nodes in the passed (yes thats right they actually added a feature to not re-validate blocks they are syncing to)

3. when segwit is released it shows to segwit the sigops because segwit understands the order of the tx. and so it sees the malicious address owns the funds now and then the malicious address then spends them using their privkey

the reason the anyonecanspend is so much fail. is because a real anyonecanspend is an op_true. where part of the transaction has the signature for the input included but the destination is funky.. segwit utilizes op_0 to make both input and output signatures funky. thus its not an anyonecanspend, but a no one can spend funky transaction locked into a block..(in the eyes of an old client)

he is working on blind faith of what has been proposed in a glossy leaflet(whitepaper to be more precise). he lacks the critical mind to examine everything and trust nothing until its proven, and you cant prove vapour is solid until you handle it and it has cooled down and settled

Your example is invalid because this "malicious miner" can't include an invalid tx in a block, otherwise the whole block would be invalid and hence rejected by the network.

The tx would be invalid, no matter how "funky" it is, because you have to correctly sign the inputs, and if you do not have the private keys of the inputs, you can't provide signatures.

No way to bypass that step, it's how Bitcoin works, and it's made expressly to avoid the attacks you are describing.

to a old client its not invalid.. its just funky.. just like old clients would treat transactions in the future after segwit is released.. still funky to old clients.
remember old clients WILL NOT see the signature area. so they wont validate the transaction. they will just blindly accept it.
if you think old clients wont accept blocks accepting segwit style tx's then segwit is not backward compatible.. (yet it is so that ends that debate)

its not an anyone can spend because of other consensus rules that prevent that too.. (otherwise old clients can abuse segwit later by pushing transactions to nonupgraded pools)

once you understand that segwit is not the exact same as an anyone can spend. but is similar only in the lack of validation part. you will start to see the bigger picture.

my scenario is that while funky in an old client.. its added before segwit clients exist. and so its accepted as funky (op_0). but unspendable due to being funky(different to a true anyonecanspend)

later. separately (please put the first scenario into a box and push it back in time by a month, no longer caring about it because its in the past confirmed into a block but no one can do anything with it back then..)

now new segwits put a checkmark in and dont bother checking the old blocks as they are deemed as pre-checked..
so again even the new segwits wont orphan off the block from a month ago. and if they did, well thats atleast 3000 other blocks they need to orphan off..
(think about it, have a cup of coffee and think about it).

so they havnt orphaned off the first scenario block from one month ago.

but now someone knowing that segwit hasnt checked the old block but has built up a list of utxo's and can see that the first scenario did actually have an output to an address because segwit can now see the sig-ops...

so the owner of the keys to that output now makes a new transaction using a private key to spend that..

Just to summ up / that attack would be like that:

A miner

1) modifies his own mining code to enter  already the SW link into the correct place

2) mines a BAD block NOW, Long time before SW goes live

3) Now he can do lots of real txs like spending BTC (but get back when)

4) SW goes live and all blocks down to his BAD block get orphaned and his spending from 3) are neglegted

? correct ?

franky went on irc to try to explain his scenario. this is the part of the exchange that matters because this is wher ethe flaw in his attack is explained (and i have been giving this explanation for the past couple of pages). Franky is testicools here.

I'm sorry, but you just don't understand how bitcoin works (and hence segwit): as many others have already explained to you, you are just confusing inputs with outputs.
While it's true that old clients will not verify segwit signatures, those signatures are for segwit outputs. Old transactions (like the one of satoshi you would suggest) are old-style transactions and hence, with new or old rules, needs normal signatures for their inputs.
So you can't spend them in both old or new network rules without having the relevant private keys, no matter how "funky" the outputs are (please understand this is the only part of the tx you can mess with).

Thread has mostly been one massive Where's Waldo - location troll cave, knightdk as Waldo ::)

Soft-forks are not enforced on the older parts of the chain. Only in blocks from two weeks after 95% of the hash-power had signaled their intent to enforce (counted over a 2016 block interval after the change start-time).

For prior soft-forks, like strictder, there are many historical violations before where it was enforced. It does not make the chain invalid, only violations after the point where the new rule's enforcement begins would do so.

Thanks & yes, I got that. But this soft fork happens at 4) or two weeks later.
The question is, whether the new coded miners (SW enabled) will orphane the non SW chain down two that BAD block made in 2)  because they will all agree that this BAD but old block is the last valid SW one since it contains the correct LAST  correct SW  entry?

The problem is that the bad block cannot exist in the first place. You cannot spend from an output that you do not own. Segwit does not change this behavior.

before segwit is released someone can make a segwit tx. where the witness data is not part of the transaction.

a better analogy than anyone can spend is that any signature data is treated as just a 'message'. that is overlooked and not checked or done anything to.
old clients will just see it as a funky tx.

again segwit tx is not a op-true so please look away from the anyonecanspend analogy and concentrate on op_0. and only op_0.. they are different things entirely.

so knowing old clients are backward compatible to blindly look passed segwits. it proves that old clients would not reject or orphan a block containing a segwit. otherwise segwit is not backward compatible. and blocks would get rejected all the time by old clients.(if the opposite to reality could occur)

its just basic logic/common sense.
old clients wont reject a segwit transaction

and nothing in the future when the real segwit it activated changes for old clients.. remember old clients wont upgrade so nothing changes for them. what they look blindly passed now they will look blindly passed in the future.

i think knightdb cannot get beyond the concept that segwit is not foolproof. so its best i leave him to wallow in his small box of bug free perfect code, cushioning himself with candyfloss clouds and pink unicorns. blissfully ignorant that the world is not the dream laid out on whitepapers, while he pretends it is

have a good month everyone

No, that block will not be invalid. The rule is not enforced for any blocks before the specific block where the activation starts, all at once for everyone upgraded (including the 95%+ hashpower that triggered it). The blockchain itself assures that the triggering is coordinated and that almost all the hashpower is running software that can enforce at that coordinated point.

Yes, but only for spending from an output of the type OP_0 <20 bytes> or anything similar. The witness data must still be in the transaction when you are spending from an output that has anything like OP_CHECKSIG in the output script.

I think franky1 cannot get beyond the concept of how bitcoin works and is just spouting bullshit to make himself seem better than anyone else. He simply doesn't know how bitcoin works or is trolling.


New local rule: franky1 is banned from this thread from this post onwards.

OP


I appreciate your efforts to help explain, however, your explanation is far from definitive.
I'm unmoved so far.

Segwit is all too vulnerable. It is too new.
And while it maybe "tested", effects cannot be fully understood.

And that begs the question: When is it not "too new"? If it is never deployed on such a scale as Bitcoin, then it will always be new to Bitcoin and the effects of it on the network the size of Bitcoin's cannot be known until it is tried on the Bitcoin network. No altcoin is at the same level as Bitcoin, a new altcoin certainly wouldn't. The testnet is most definitely not on the same level of Bitcoin. So sure, while we could test it on the testnet and get most of the technical bugs out (as they have been doing with segnet), it is not possible to fully understand the entirety of the effects that segwit, or any major change for that matter, on the economy and non-technical aspects of Bitcoin without actually doing it. By that logic then, Bitcoin would never be able to evolve and change in the future because the effects of any change cannot be fully understood.

Fair point, but some changes are more far reaching than others.
As in the situation of segwit being so new, if there is any risk of destroying Bitcoin, that is a risk to far.

The effects of a small block size increase is maybe more generally understood than the intricacy's of segwit.
I don't feel the same risk of destroying Bitcoin applies.

To all FUDsters and there FUD:

Just ley back, close your ayes, it will all be over soon. Squirming about only makes things worse, for everyJuan, Gee. Be glad you are only being soft forked, contention over consensus isn't even possible or relevant with feathery soft things... 

That is of course personal preference. You can think whatever you want of the risks, and form your own opinions, that's fine and up to you, I'm not going to try to sway you. The main point of this thread was to stop many misconceptions and misinformation that people spread and to present the facts about segwit. The opinions you make of it are completely up to you.

Good, this is the first if...then added to fix a specific logic flaw, and this will not be the last of them, keep adding if...then until all the code base become an ugly mess and you still might have missed some scenario ;)

You really don't need all these wasted efforts of patch making and testing if you just do a hard fork

That would be strictly harder not easier. The older behavior must be accommodated regardless or it will confiscate peoples coins.

I'm sorry you disagree with the method used by Bitcoin's creator-- as well as almost every technical expert to come after-- has fixed and maintained the system, perhaps you should use something else.

You sounds like a central planner/protector for all the people. This is experimental software and open source isn't it, no one is responsible for people's financial loss, thus everyone here knows how to protect themselves by only investing risk money. But they hate being centrally controlled, it seems you value money over freedom

old clients wont check whats after 0x00(op_0).. they automatically treat the transaction as valid.

again the signatures are not in the same expected area. segwit abuses 0x00 to achieve this. thats the whole point of how segwit can work as a softfork!
because the signatures are not where they are expected. old clients treat it as just a valid funky tx.

the 20 bytes after 0x00 (op_0) are not going to be what old clients expect to see. yet they would automatically look passed it, without care.

i think you are blindly trusting the dev's to make pretty code with zero bugs. instead of thinking with a critical mind that things can break and to think that its better to have a things might break mindset rather then a devoted faith that it will elegantly work. because blind faith is the mindset of people who wont bug check/hack it to its limits. they will just do a couple standard transactions and praise their lord that funds move.. rather than trying to break it

come on.. the code is not even released and ur already thinking its perfect..

real that last line 5 times. let it settle in your head. and think about the mindset you have.
even scientists who spend years developing space rockets, still end up with them blowing up.

hm - you can improve, debug and grow only with constructive critics, so I  wonder (but could understand as well)  that you lose patience here ...

You are a sience guy, so you know your theory fail once you cannot convince your critisizers .

If third parties make decisions to take away your funds, then Bitcoin isn't money. I find it amusing that you call avoiding that, "centrally controlled".

There is little point in arguing with a climate change denier or creationist whos positions are axioms and not based on the science. At some point all there is left to say is that this is what Bitcoin is, it's what it's been since the start-- the poster has already aggressively and insultingly disregarded the advice of virtually everyone with established expertise-- and promotes a vision, things like it being okay to make changes that confiscate people's funds, that in my opinion is practically and ethically incompatible with Bitcoin. I feel no shame in telling such a person that Bitcoin may not be what they seek.

If Bitcoin is to satisfy anyone it cannot satisfy _everyone_; some demands are mutually exclusive.

This is the property of the address, not the signature; if it were a property of the signature you could already simply steal any coin.

money is centrally controlled.. sorry but thats the truth.

bitcoin is not money.. its an asset..

both money and assets equally sit under the umbrella term of currency. so yes money is a currency and so is an asset. but trying to say bitcoin is money is playing right into the FIAT overlords mindset.

bitcoin is not money. pure and simple. nor should it ever be money.
being an asset is no worse than being money, but the benefits and positives are larger.

This form needs really a good AI filter for 'constructive critics / Feature requests' - rest put on ignore  :-)
In the end I guess 95% of memebers are trying to improve bitcoin, methods for that are mostly wrong.

Yes.

Paul C. Martin:

Private property as de iure institution needs a foregoing state to come into existence. The state needs foregoing power and foregoing power needs armed force. The ultimate “foundation of the economy” thus is the weapon, where possession and property are identical because the possession of it guarantees property of it. Armed force starts additional production (surplus, tribute). The first taxes are contributions of material for the production of attack weapons (copper, tin). Thus non-circulating money begins. Taxes as “census” and money are the same.

http://www.miprox.de/Wirtschaft_allgemein/Martin-Symp.pdf

Just found this thread. What is the 'consensus here' will 'segregated witness' deploy BEFORE halving..or will they put it off till after?

(I know they said before but seems kinda close to halving ...perhaps they are gonna wait)

anyway not up on this just wondering ...so chime in here

Based upon the discussion that the Core Devs have been having in the IRC, a release containing segwit will be out before the halving. Whether it is deployed before the halving is up to the miners.

it will be a huge mess. popcorn time  ::) ;D ;D ;D

Any links to those IRC discussions? We are talking about a potential release within the next 6 weeks.

No, it will not. It has been in testing for quite a long time now.

Somewhere around here: https://botbot.me/freenode/bitcoin-core-dev/2016-05-26/?msg=66783313&page=3

They want to get Segwit merged in before the 0.13 feature freeze which is scheduled for 6/16 (https://github.com/bitcoin/bitcoin/issues/7679). If that gets merged, the backport to 0.12 should be around the same time. The release should then be out just before the halving.