Fixing transaction malleability on peercoin


#21

The Segwit code is starting to be so intertwined with the rest of the code in 0.16.1 that it will be a real pain to disable it. So why don’t we just stop at 0.14 instead like me and others are advocating?


#22

0.14.1 does not get native segwit addresses but that ugly segwit in P2SH which I’ve always considered the worst part of this entire segwit drama. Also, HD wallet is a must have.

It will surely be easier to remove a few lines than add all this features.


#23

0.14 was where Bitcoin ABC was forked from. It will be easy to port their code for removing Segwit if LN goes nowhere. HD wallets are implemented in 0.14.


#24

Just a friendly reminder that this thread is public.


#25

I’m not sure how that happened, but it was supposed to be in the private development board. I moved it back.


#26

I’ve opened the thread, it should be public.


#27

Ok, I thought maybe I made a mistake when moving the thread last time.


#28

just out of curiosity - I am not a techy at all - is there any urgent need to get rid of transaction malleability in Peercoin? Is a fix needed for Peerassets?

If there is no urgent need, we could simply postpone the decision whether to use Segwit or not as a malleability fix for another several years, and watch the ecosystem evolve.
As a backbone currency, we should be very conservative, and better choose no path at all than the wrong one.


#29

The issue is two fold:

  1. Lightning Network and other industry standards rely on segwit. Whether we adopt or not, we will make a statement either way. Adopting makes the statement that ‘Peercoin is ready to modernize and be on the cutting edge again’. Not adopting makes the statement that ‘Peercoin does not support the questionable tech development that is segwit and we will find and follow alternative solutions’. Because we need updates like HD wallet UI, not choosing is not an option. We must either pull from currently existing code or make our own. To not choose is to stagnate and deprive Peercoin users of unquestionably desirable updates (like HD wallet).

  2. Segwit is becoming an integrated part of Bitcoin core protocol. If we choose not to support it, we will need to follow an alternative implementation like BitcoinABC. If our chosen project doesn’t survive, it puts Peercoin in a bad position. So the question of which implementation and developer group is the most long term stable becomes important to the discussion. This of course becomes a political debate.

Ultimately, we cannot afford to not chose. Projects are taking sides, and we lose our edge the longer we stagnate. We are at a crossroads and choosing neither means we sit idle as the world passes us by. Peercoin has always pulled from Bitcoin core to update, so the default is to adopt segwit. The question is if we have hit a point where we need to consider pulling from a different project.


#30

Excellent summary.


#31

This thread been open since November should have decided by now I agree with nagalim


#32

To be fair, we’ve been discussing segwit since around 2016. Here it is in June 2016, where @peerchemist took the ‘wait and see’ perspective.


#33

Also, I’d like to point out that the question seems to have changed since @hrobeers proposed it. It used to be a question of what tech we adopt. It has evolved (devolved?) into a question of what dev team to follow. Over all, this question is a very nuanced one and cannot be answered in a succinct fashion for all time. Instead, we must struggle with this general question until we take our own reins on the tech, which is unlikely as long as compatible, open-source projects like Bitcoin are still doing the heavy lifting. There is no universal answer to this question of leadership, but there must be an immediate answer to the question of segwit.


#35

I’m in favour of Segwit


#36

#38

#46

I’m glad for this original post by hrobeers. I’ve never seen the malfix options laid out so clearly.

As a developer, generally i think simpler is better, where possible. Simple Mal Fix would work on all transactions with hard fork. The change is with the txid calculation.

SegWit and the FlexTrans solutions only provide malfix for the new tx types.

Does anyone know of a *coin which has implemented the “Simple Malleability Fix” in production? I know bitcoin cash/bitcoin-abc hasn’t. It would be a tech and marketing win if Peercoin was able to do it, but i don’t think we have those dev resources.

So SegWit is the only one significant in the wild / in production now on Bitcoin core, Litecoin and others. Maybe this is a case where the technology has to stay on DC power for a generation before going to AC power infrastructure.


#47

I have moved some posts out of this thread as they were off-topic. Let’s stay on topic please.


#48

Here is a discussion of Simple Malleability Fix vs. FlexTrans in /r/btc which includes the devs


#49

I don’t know, at the end of this review, i feel like all the different fixes have some technical merits. But the only one tested in production is the SegWit code.