Fixing transaction malleability on peercoin

General RFCs
1

To all peercoin team members.

Transaction malleability has been a hot topic on bitcoin.
This design flaw has become common knowledge after the MtGox hack.

I want to use this thread to start an objective evaluation of all options for peercoin to fix transaction malleability.
This thread is not meant to come to consensus about the solution peercoin should adopt, this thread is meant to result in an objective summary of all the options.
Due to all politics bitcoin is involved with, it seems impossible to find an objective summary on the web, so let’s try to compile one ourselves.
Once we are happy with this summary we can publish it in a public RFC for the world to see it and comment on it.

The options

  • SegWit
  • Simple malleability fix
  • Original FlexTrans (with CMF)
  • Modified FlexTrans (with different serialization format)

SegWit

Pro

  • Block space savings (by moving the witness out, no total transaction size savings)
  • Co-exists with old format (which can be soft-forked out later)
  • Soft-fork
  • Hype
  • Code is ready and used in production

Contra

  • Complexity (technical debt)
  • A range of new transaction scripts (OP_CODES)
  • Does not fix malleability for all transactions (only for segwit transactions, so payment processors still need to handle malleable non-segwit transactions correctly)
  • Signature validation is optional
  • Most design effort went into making it a soft-forkable

Simple malleability fix

Pro

  • Simplest solution
  • Fixes malleability for all standard transactions
  • Does not introduce new transaction scripts
  • Code is ready

Contra

  • No block space savings
  • Cannot co-exist with old format (however, only the txid calculation changed)
  • (hard-fork)
  • Hard-fork: Missed chance to cleanup the transaction format
  • Hard-fork: Missed chance to switch to a more flexible transaction format that allows easier soft-forks in future

Original FlexTrans (with CMF)

Pro

  • Block & transaction space savings (skip optional fields, varints, repeated signatures, …)
  • Co-exists with old format (which can be soft-forked out later)
  • Does not introduce new transaction scripts
  • Allows cleaner future soft-forks
  • Code is ready (testnet available)
  • Does not depend on external libraries (ref. BIP66)

Contra

  • CMF is yet another serialization format
  • Does not fix malleability for all transactions (only for flextrans transactions, so payment processors still need to handle malleable non-flextranse transactions correctly)
  • (hard-fork)

Modified FlexTrans (with different serialization format)

Pro

  • Possible block & transaction space savings (depends on chosen format and implementation)
  • Co-exists with old format (which can be soft-forked out later)
  • Does not introduce new transaction scripts
  • Allows cleaner future soft-forks
  • Not “yet another serialization format”

Contra

  • Code is not ready
  • Does not fix malleability for all transactions (only for flextrans transactions, so payment processors still need to handle malleable non-flextranse transactions correctly)
  • Protocol dependency on external libraries, maintainability & consensus risk. (ref. BIP66)
  • Serialization format needs carefull selection to ensure no consensus rules can possibly get broken, e.g. strict ordering of properties.
  • (hard-fork)

Things to consider

  • Try to compile a piece of software released 10 years ago, if it has enough dependencies it will be hell to do. Stuff changes all the time. Bitcoin removed all dependencies from libconsensus, because of that.
  • ProtocolBuffers: protoc has a huge amount of features that are not needed and misuse of those features would lead to consensus rules being broken. Same problem with bugfixes or other upstream issues.

Debunking the myths

  • “FlexTrans requires a all infrastructure to upgrade”
    FlexTrans does not need to influence software connected through RPC.
    The RPC interface can still expose transaction data in the old JSON and old raw serialization format.
    Only signature and txid generating and validating code should upgrade.
    Mining pools can still mine old style coinbase transactions (no upgrade needed, other than their node)

  • “FlexTrans does not save much block space as signatures take up largest part of txn”
    FlexTrans introduces a “repeat previous signature” flag signing all inputs at once, multiple inputs form same address therefore only require one signature. This considerably reduces most transaction sizes saving over 100 bytes per input and improves validation performance.
    Other space savings are documented here: https://steemit.com/bitcoin/@tomz/the-simplicity-of-flexible-transactions.

8 Likes
2

I support a hardfork with a simple malleability fix.

3

Thing is LN depends on SegWit since release 0.4.

4

Guess we have to do some changes to that LN code then.

5

I am not sure if we are ready (read: manpower) to upkeep yet another fork which may end up diverging from the upstream.

1 Like
6

@peerchemist you should watch these videos on LN:

Rick Reacts to the Lightning Network
https://www.youtube.com/watch?v=DFZOrtlQXWc

Rick Reacts to Lightning (Again) and brings up a previously undiscussed flaw
https://www.youtube.com/watch?v=Ug8NH67_EfE

7

Yeah, I know.

8

And I still think it’s the future. I see LN just as the first step toward second layer solutions, much like Bitcoin is certainly flawed but it was a move in the right direction. Second layer solutions will be polished in 3-4y.
Blockchains do not scale.

1 Like
9

With sharding they do.

10

I’m more for not writing txns into chain but when actually needed over abolishing full nodes. Sharding suits platforms who don’t pursue decentralization and censorship resistance but not the coins.

11

What Peerchemist is saying is the same as what Sunny King has always said. Peercoin was always meant to be a backbone (base layer) upon which other 2nd and 3rd layer technologies run on top of. It is the best way to achieve scalability. Sharding can’t be the only solution. 2nd layer solutions are where our major focus needs to be as a project.

1 Like
12

I agree that we should not pursue sharding now. We should also NOT implement Segwit.

13

Bitcoin Cash will also support 2nd layer solutions. I think we should port their code instead.

14

Dr. Peter Rizun - SegWit Coins are not Bitcoins - Arnhem 2017

15

I’ve been in Peercoin since early 2013, but if Segwit goes live on the network then I’m out. That is coming from a guy that has this hanging on the wall of his apartment:

DnAJQer.jpg1688Ă—3000 680 KB

1 Like
16

@sandakersmann, for purpose of the discussion can you please state that you do understand that this is not our version of “scaling debate” but just about this specific technical solution called “segwit”.

Blockstream and core have turned Bitcoin into a “settlement layer”, ie. the “backbone” we are talking about since 2013. Peercoin was never a cash coin, it was always imagined as settlement layer. Core is now playing our game, and they are currently leading. It makes every strategic sense to keep track of it until we have strong reason to diverge.

P.S.

We have similar paintings <3.

2 Likes
17

@peerchemist yes this is not about scaling. It is about the false notion that the “backbone” that Core is building has any similarities with the Peercoin “backbone”. Here is one example:

The Bitcoin Core repo also removed the code that made miners prioritize transactions that burn a lot of coin days. This code was re-implemented by Bitcoin ABC. The reason why Core removed it, is that they are building a coin that they think will operate with full blocks and a massive backlog. This is not what Peercoin aims to do, so it will be really bad to implement code that has a totally different purpose.

18

What they have removed can easily be returned back, and what you are saying is not related to Segwit at all.
I’ve always wanted to put Peercoin between two Bitcoin camps and just cherry pick what we like.
We are in unique position where we do not care about politics and can just get the best technology.

1 Like
19

Yes I agree, but that is not what you have told that developer to do. You have told him to port to Core 0.16.1.

20

Yes, as 0.16.1 core gets native Segwit, native HD wallet, and a whole bunch of other improvements. Porting to 0.16.1 does not mean you get all the features of btc-core but you use it a base. We can add and deduct features as we like.