Fixing transaction malleability on peercoin

General RFCs
50

Technically, i changed my mind after reviewing more on FlexTrans - it may be more simple that “Simple Malleability Fix” because it only changes the transaction format. It doesn’t add a second txid/utxid like SegWit and Simple Mal Fix, which would complicate node and client code in a different way.

Simple MalFix is not complete with the current code (see Tom Zander comment):

This introduction of a second ID for transactions seems to have a wide ranging set of effects, from your commit messages it seems that this means a node can no longer accept transactions it does not have the parents of, because it becomes impossible to ask the sending node for them like Bitcoin does today.

Basically the decision is to use 2 txids (txid + wtxid|utxid) (SegWit and Simple MalFix), or use a single txid + tx version (FlexTrans v4).

However, nothing uses it except Tom Zander’s abandoned Bitcoin Classic testnet code. That goes against the Peercoin objective to be a drop-in Bitcoin replacement.

I can see why Bitcoin Cash still hasn’t implemented Simple MalFix. Its weird cause i think they changed signatures already but no malfix.

I was happy that Peercoin is going to implement RFC #0004 Remove Transaction Timestamp, because the raw tx format would now match Bitcoin’s (as well as simplifying and fixing the code). The only wrinkle is that Peercoin uses 1e6 “satoshis” per coin vs. Bitcoin’s 1e8 satoshis per coin, which affects serialization of the raw tx outputs (by client apps, not so much the nodes).

Original Bitcoin raw tx format:
nVersion|txins|txouts|nLockTime

Original Peercoin raw tx format:
nVersion|txTimestamp|txins|txouts|nLockTime

SegWit raw tx format:
nVersion|marker|flag|txins|txouts|witness|nLockTime

Simple Mal Fix Bitcoin raw tx format (replaces inputs txid with utxid):
nVersion|txins|txouts|nLockTime

FlexTrans format with CMF (main sections, but token order is flexible)
Transaction|Signatures|TxEnd

Possible CMF Tokens (could be easily extended later):
TxEnd,TxInPrevHash,TxPrevIndex,TxInputStackItem,TxInputStackItemContinued,TxOutValue,TxOutScript,TxRelativeBlockLock,TxRelativeTimeLock,CoinbaseMessage,NOP_1x

I don’t know why i went into all this, i just wanted to dig deeper and document on the technical stuff, which was part of the original post point. We are in a decentralized network space, things are not just engineering matters, consensus matters, and people vote with their feet.

3 Likes
51

FlexTrans was our first choice as well, however it got abandoned.

52

Segregated Witness Removes One of Bitcoin’s Data Integrity Checks

https://www.yours.org/content/segregated-witness-removes-one-of-bitcoin-s-data-integrity-checks-cce11f4ee319

53

Is it possible to follow a non-segwit based project and then change later?

One of the strengths of not being the first-mover is we can wait until a lot of these “ifs” go away.

54

We started the discussion of segwit 2 years ago, with the ‘wait and see’ attitude that you are describing. The issue is that the farther we go down a path the more momentum we build against reverting. This is especially true for segwit, or a hardfork, but it is also true for any code change. If we follow one project for a while, then revert and follow the other, it triples the work over just following one path. 1. The initial work to follow the non-segwit project. 2. The work to revert back to the forking conditions. 3. The work to follow the segwit project. This is a highly inefficient use of our developers’ time. Almost no matter how you look at it, the crypto community is at a fork over segwit, and you either have to choose a direction and stick with it or flounder, stagnate, and disappear.

As a point of curiosity, would you be able to come up with any abstract criteria for when would be a better time to make this decision?

1 Like
55

Well, as you point out not making a decision is kind of decision in itself. If this was not the case I would say the right time would be to see whether BCH or BTC becomes the market leader and which layer 2 solution gets adoption.

At this point I would say that Bitcoin Cash will probably going to win and LN is not going to be useful for a numbers of years if ever.

56

How do you quantify this? BTC has had ~10x marketcap of BCH since inception, so clearly you are not measuring by that.

The last two years have given market dominance to BTC. It is almost unarguable that BTC is the current market leader. The argument to be made for BCH is that it may one day overtake BTC, but it is clear that right now BTC is on top. As far as second layer adoption, the BCH team has not implemented a malleability fix yet, so BTC is on top there too. So I’m unclear what your criteria is for when we decide who ‘won’.

57

Market cap would be fine. I’m not arguing that BCH is the leader as of now of course.

If BCH goes ahead in market cap at anytime, considering how much ground they had to make up, I would consider them the project to follow.

58

By that logic, since bitcoin core has an order of magnitude bigger marketcap than all other bitcoin forks, we should not hesitate to follow them.

59

Not really. Bitcoin gained that market cap lead pre-segwit pre-fork without a substantial competitor like BCH…

In other words, the battle has just begun we’ll have to wait for the dust to settle to see who is the winner.

60

How do you quantify this? It has been a year, and the market relationship between bch and btc has been rock steady around 0.12 btc/bch. It just seems like ‘dust to settle’ is equivalent to ‘when bch finally becomes worth more than btc’ which may never occur. If the market relationship that has existed thus far continues going forward, at what point would you throw in the bch towel? 1 year? (Well, clearly not) 2 years? 10 years? If in 50 years, the market relationship is still 0.12 btc/bch, would you agree to segwit then?

1 Like
61

10 years too long, 2 years too short

62

You want Peercoin to do nothing for more than 2 years?

Beyond this question, there is the question of how do we make these decisions going forward. Do we have to wait >2 years every time there is a fork before choosing a fork? Or is segwit special for some reason? Can we really afford to be permanently >2 years behind the curve in a space as fast moving as crypto?

1 Like
63

Nope.

1 Like
64

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.

1 Like
65

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.

66

I’m saying market cap is a good indicator 2+ years from now. It would not be fair to use it now as the projects just diverged.

My choice would be purely where I feel the momentum is and the culture of the teams involved

67

One Year Of Segwit, Where Does It Stand?

68
69

Do you know that guy is pushing for a split in BTC by Proof-of-Work change? Can’t really see why this is relevant.