Of course not. But if pushed to make a decision I would say follow the BCH team. However, if it was possible I would try to stay as neutral as possible for as long as possible.
Segwit is a special case since it caused such a large fragmentation of the bitcoin community. Every fork is not important but certain ones are i.e. when big players in the community break rank.
Already answered this but I would add that adding features doesn’t mean you’re getting ahead, sometimes saying no is a million times more powerful.
Peercoin is also the oldest running pos chain so in some ways it’s always ahead - for example the community has had time to shake out the opportunists and has left a very solid group.
This right here is what I don’t understand. We have established that marketcap is the criteria by which we make this decision, then you turn around and make the exact opposite decision that the very criteria you established dictates. This implies to me that your opinion must be biased by something other than market dominance.
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 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.
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.
