Fixing transaction malleability on peercoin

General RFCs
130

You are overestimating my abilities.

131

Amaury SĂ©chet on why SegWit as a softfork is bad:

132

We know it’s a bad softfork, we’ll hardfork because of that.

133

Won’t Peercoin 0.8 be a soft fork with flag-day activation?

We should not disable the old transaction format as long as there is no standard for signing messages with segwit addresses. Also, a hardfork is just an airdrop at block X unless everybody agrees with the new protocol rules.

134

No.

Nobody has mentioned disabling the “old transaction format”.

135

If it’s a hard fork, which new rule will be introduced that is not accepted by the old clients?
If old clients stay on the same chain, then it’s not a hard fork.
I don’t see how the Bitcoin 0.16.x codebase could be used to introduce Segwit as a hard fork.

136

That’s why we need to build on top of Bitcoin ABC.

137

Check the v0.8.0ppc.rc1 src/kernel.cpp

// Protocol switch time for 0.7 kernel protocol
const unsigned int nProtocolV07SwitchTime     = 1552392000; // Tue 12 Mar 12:00:00 UTC 2019
const unsigned int nProtocolV07TestSwitchTime = 1541505600; // Tue 06 Nov 12:00:00 UTC 2018

// Switch time for new BIPs from bitcoin 0.16.x
const uint32_t nBTC16BIPsSwitchTime = 1559260800; // Fri 31 May 00:00:00 UTC 2019

The hard fork time is checked through the codebase by IsBTC16BIPsEnabled():

$ grep -R IsBTC16BIPsEnabled src
src/kernel.cpp:bool IsBTC16BIPsEnabled(uint32_t nTimeTx)
src/rpc/mining.cpp:    const bool fPreSegWit = IsBTC16BIPsEnabled(chainActive.Tip()->nTime);
src/rpc/blockchain.cpp:            activated = IsBTC16BIPsEnabled(pindex->nTime);
src/validation.cpp:    if (pindex->pprev && IsBTC16BIPsEnabled(pindex->pprev->nTime)) {
src/validation.cpp:    if (pindex->pprev && IsBTC16BIPsEnabled(pindex->pprev->nTime)) {
src/validation.cpp:    if (pindex->pprev && IsBTC16BIPsEnabled(pindex->pprev->nTime)) {
src/validation.cpp:    return pindexPrev ? IsBTC16BIPsEnabled(pindexPrev->nTime) : false; // pindexPrev == null on genesis block
src/validation.cpp:    if (pindexPrev && IsBTC16BIPsEnabled(pindexPrev->nTime)) {
src/validation.cpp:    if (pindexPrev && IsBTC16BIPsEnabled(pindexPrev->nTime)) {
src/kernel.h:bool IsBTC16BIPsEnabled(uint32_t nTimeTx);

This is in contrast to the way Bitcoin core did the SegWit soft fork. The old tx format stays, but the new SegWit tx format and consensus rules can be activated at the time of our choosing.

138

There seem to be some misunderstandings here. Firstly, I am not against a soft fork, and secondly, I am also not against introducing Segwit. Segwit is not really needed for Peercoin, but it doesn’t do any harm either. Adopting a modern codebase is very good. It is much faster, offers more functions in the debug console etc. That’s the real benefit.

Now lets distinguish between hard fork and soft fork, and between miner-activation and flag-day activation.

Hard fork:
New clients may produce certain types of blocks that are rejected by old clients. There is a permanent split into two chains.

Soft fork:
Rules get stricter. Old clients accept all blocks that are produced by new clients, but new clients do no longer accept some of the blocks that are produced by old clients. There can be a temporary split into two chains, but the chain that is based on the old, less strict rules, can be wiped out at any time by the new chain, not vice versa.
In practice, old clients can still be used as wallets, but do no longer secure the network.

Miner-activation:
New rules come into effect once a certain percentage of miners/minters signal that they are ready. We did this with Checklocktimeverify etc. in Peercoin 0.6.

Flag-day activation:
New rules come into effect at a certain date.

With Segwit as a soft fork, the trick is that transactions from segwit-addresses are valid even for old clients since they do not need a signature according to the old rules (“Anyone can spend”). But for new clients, transactions from segwit-addresses are only valid if a signature is provided. This makes it possible to remove the signatures for segwit-transactions from the blocks and store them separately.

In Bitcoin, Segwit was introduced as a miner-activated soft fork. As far as I understand, what Peercoin 0.8 will do is a flag-day activated soft fork. I haven’t seen any evidence that we will do a hard fork. This means that old clients can still be used as wallets after the soft fork.

@Peerchemist and @Nohea
It seems to me that you are saying “hard fork” because of the flag-day, but it really is a flag-day activated soft fork.

140

Yeah you are correct.

1 Like
141

Great that we got this sorted out :grinning:

142
2 Likes
143

@peerchemist @sandakersmann Remove block size restriction , create SPV Wallet.
It may increase peercoin’s development opportunities
At the same time, further reduce transaction costs

144

This is completely wrong. Peercoin has fixed transaction costs. Changing the block size would do nothing to the current chain economics. It would be a symbolic move only.

1 Like
145

spv wallet is simply not feasible with our proof of stake, as verification of blocks requires knowing coinstake transactions.

1 Like
146

@Nagalim
Do you think the agreement is perfect now? Do you have any way to increase the usage rate, I have not seen any solutions you have proposed.

147

To genuinely increase usage, we should work on use cases. It is a long term thing, including getting listed places, getting more exposure, having merchants, and a part of it is PA and other fundamental usefulness upgrades. These are things that require long-term stability, which is indeed something we all have been working on.

148

Transaction malleability will be fixed in the Bitcoin Cash hardfork in November:

149
150

Achievement unlocked: Bitcoin Cash fixed all common third-party transaction malleation vectors

https://read.cash/@BigBlockIfTrue/achievement-unlocked-bitcoin-cash-fixed-all-common-third-party-transaction-malleation-vectors-bf5f1e41