Bitcoin Cash will implement Schnorr signatures to solve transaction malleability.
Might come in the May 15th upgrade.
Core will also implement Schnorr signatures.
@peerchemist Yes, but they only do softforks and keep all the old transaction formats for maximum confusion.
Cash (which one, lol) will do hf? That doesnât stop us from doing the same.
It will be a hardfork yes, and there is only one Bitcoin Cash. Bitcoin SV is another coin if you donât know.
Yes, but why would we want to poison the blockchain and code base with SegWit before scrapping that and going with Schnorr?
Why do you think schorr sigs are incompatible with segwit?
They are not, but SegWit is not needed to solve transaction malleability when Schnorr signatures are implemented. Schnorr fixes transaction malleability without SegWit and this makes SegWit just an added complexity not needed at all.
Segwit is much more than a simple malleability fix. And yes itâs needed.
Agree to disagree I guess.
Segwit is the doom of this project. PPC used to be a cool alternative to BTC back in 2013 but seeing it step into the same holes as bitcoin core stepped into and having the arrogance to see it as a good thing is what will ultimately contribute to the total demise of Peercoin (as if things werenât already bad to begin with).
I proposed a trivial opt-in fix to TX malleability 2 years ago. If we wanted to pretend that we indeed need such a fix right now (which we donât) then it can be easily achieved with child-pays-for-parent (CPFP) TXs, as the child TX locks in the parent TXâs hash. A malleated version of the parent would never confirm because there would be no child to pay for it. If anyone is interested I can explain it more in detail but SegWit is the absolute worst amongst the proposed solutions. So much so that we will see in 2019 a public release of a recently discovered vulnerability in SegWit that cannot be fixed. Whether that vulnerability is a real thing or not, it is a risk that should make it clear that whatever we do, we must not implement SegWit in 2019 when the said vulnerability is supposed to be made public.
thank you for voicing your concerns and spending time suggesting alternatives, can you please elaborate on your idea of malleability fix?
I am so glad you asked 
Opt-in CPFP based Malleability fix goes like this:
You establish a consensus rule that a zero fee TX is only valid if there exists a child-pays-for-parent (CPFP) TX that pays a non-zero fee. This means that miners are supposed to orphan any block that contains such a zero-fee TX without the respective CPFP TX within the same block.
Under these rules, Alice crafts a TX that cannot be malleated by first making a zero-fee TX which pays X amount to Bob and also Y amount back to herself. Now, without broadcasting this TX to the network, Alice makes a child TX that donates Y amount of coins to the miners ( CPFP, this is the actual TX fee ). Finally, Alice broadcast the crafted TXs to the network in reverse order. First she broadcasts the child TX and then the parent TX. The network receives the child TX to their mempools and since its parent is unknown, they are willing to wait for the parent to arrive. When the zero-fee parent arrives, the network is willing to accept it because the CPFP TX is already present in the orphan pool.
If a malicious miner malleates the child TX, then no harm is done, because it is the parent TX that actually sends X amount of coins to Bob.
If a malicious miner malleates the parent TX, then the malleated parent becomes invalid and will never confirm, because it has zero fee and no CPFP TX that pays the fee.
i donât think that accepting transactions that have no known input into mempool is a good idea, you can exhaust memory of the node pretty quick.
itâs old news, thereâs a special mempool for txs like such, itâs called orphan pool. it can happen and itâs a valid scenario. a node that is vulnerable to this as an attack has serious design flaws and shouldnât be used in the first place 
Iâm not a fan of a opt-in malleability fix, but @Hyenaâs proposal is better than SegWit. Personally I would like to see a forced new transaction format that solves malleability. The reason for this is to not add extra complexity.
Why do you need to âfixâ TX malleability in the first place? Mt Gox is not a great example because it was their own incompetency (or perhaps deliberately planted vulnerability) that lead to the catastrophe. Lightning Network is not a good excuse either because itâs a dead-on-arrival tech. In terms of law, LN hubs are money transmitters and would have to start doing KYC and conform to rules and regulations, this will shoot down the whole idea of a LN eventually. Combine it with the fact that in LN merchant would have to be constantly online in order not to miss payments and you have a giant mess that is really not worth the effort in the first place. Better just increase that block size and be done with it. People trying to fix things that arenât broken, thatâs the real problem.
Indeed. LN is a mess, but I donât see why we shouldnât fix transaction malleability. There are few reasons not to, but I agree that itâs no rush.
I see LN as âfirst of the manyâ, a pioneer in applying stretched payment channel tech to serve as global payment platform. LN can be understood as âBitcoinâ, a blanket term and a prototype for so called level two network. Alternatives to LN will show up eventually and problems will be solved. Itâs simply the next step in the crypto evolution.
Blockchains canât scale and keep decentralized and trust-less, going level two is the only way forward.