Fixing transaction malleability on peercoin

sandakersmann · February 23, 2019, 7:16pm

I disagree. Sharding can make a blockchain do this.

Hyena · February 23, 2019, 8:46pm

And I disagree even more. Modern networking hardware and proper parallelization can make a block chain scale even without sharding. Decentralization is a buzz word often thrown around without fully understanding it. Everyone always defining it exactly the way that it supports their argument and theirs alone (whatever that may be).

Nagalim · February 23, 2019, 11:55pm

Im not a fan of sharding. It places a distributed consensus mechanism on top of a distributed consensus mechanism.

nohea · February 24, 2019, 2:01am

Peercoin is intended to be a drop-in replacement for Bitcoin with hybrid PoW/PoS. It shares the decentralized model and has always stuck to that, even when it could have centralized more for performance and feature reasons. That is worth keeping.

Everyone has something to hate on SegWit, but no one except Bitcoin Core has a bitcoin tx malleability fix tested in production (SegWit). Peercoin has limited developer resources and needs to use a widely-deployed solution to be secure and compatible.

Hyena · February 24, 2019, 11:07am

Peercoin does NOT need to fix malleability. It’s a unicorn issue. Everyone likes to talk about it while in the real world no one needs a fix. It’s like devs these days don’t have any real work to do so they waste their time on solving pseudo-issues and fixing things that aren’t broken.

The reason Core went for SegWit was to avoid increasing the block size limit. SegWit was pushed as a soft fork solution to prevent a contentious hard fork. It was a very exceptional “fix” that was only “justified” by the great divide in the Bitcoin community. Technically speaking, SegWit is the nightmare of all software architects. It’s a mess to the extent where anyone who recognizes it also recognizes that Bitcoin Core (Blockstream) was created to destroy Bitcoin.

Wanting to fix malleability is one thing. Wanting to fix it the worst way possible (the SegWit way) is a recipe for disaster. If Peercoin implemented SegWit it could no longer say it is based on Bitcoin because in the Bitcoin whitepaper an electronic coin is defined as a chain of linked signatures. SegWit breaks that chain of linked signatures by separating the signature data from the block chain, screwing up all the economic incentives of the whole system (with the use of anyone-can-spend addresses). Proof-of-Stake alone has the ability of corrupting the whole network (as rich get richer without having to do anything) so Peercoin already is on a thin ice. In such a position, it simply cannot afford to take unnecessary risks.

peerchemist · February 24, 2019, 11:22am

We’re done here.

Nagalim · February 24, 2019, 1:25pm

I think you’re missing the important piece here that it is much less work to accept segwit when rebasing to a modern code base than it is to derive an alternative solution or rip out the solution that has already been implemented.

sandakersmann · February 24, 2019, 3:06pm

That’s why we should have done the rebasing with Bitcoin ABC.

nohea · February 25, 2019, 5:15pm

BitcoinABC project still has no consensus or accepted code on a non-segwit transaction malleability fix. Same with Zcash. They are not running “simple malfix” or FlexTrans.

So its purely an academic argument. The maligned SegWit is the only (production) game in town for the foreseeable future. Code talks.

sandakersmann · February 25, 2019, 6:25pm

The reason that Bitcoin ABC does not have a malleability fix is that it’s not needed yet.

Nagalim · February 25, 2019, 6:49pm

If you wait to push solutions until they are needed, you end up with untested code in vital production situations.

sandakersmann · February 25, 2019, 9:24pm

Fixing malleability does not need complex code like the SegWit Rube Goldberg machine.

nohea · February 25, 2019, 10:28pm

True, tx mal fix can be simpler than segwit. But all the wallet code libs, rpc interfaces, tools would need updates too. Who’s going to do that?

Also trust money with the new untested code.

sandakersmann · February 26, 2019, 12:03am

The Bitcoin ABC developers can do that.

nohea · February 26, 2019, 3:05am

Great, you can lobby them over here:

sandakersmann · February 26, 2019, 6:46pm

Any Bitcoin Core developers here now?

Nagalim · February 26, 2019, 10:27pm

Why would we need to lobby core devs for a mal fix? They already implemented one.

sandakersmann · February 27, 2019, 12:00am

You need to lobby them to implement all the tech needed for bigger blocks, because this is not added to Bitcoin Core since it is not needed.

Nagalim · February 27, 2019, 12:51am

What tech is needed for bigger blocks, other than just increasing the max block size?

Buckkets · February 27, 2019, 3:46am

Its a simple code line change attached to billions worth of politics. I’ve asked Chemist a lot about this issue as it relates to Peercoin because I am not a fan of LN/Segwit. Arguably will be the death of BTC because there is no reason to take settlements off first layer. That being said, LN/Segwit seems better fit to Peercoin over all other projects. This is the exception where it will certainly kill other projects. We are already majority verified by stakers, not miners therefore they are not damaged like PoW projects. No reason to change block size because we were born with the fixed transaction size to a) give predictable fees b) to discourage spam. Allowing unlimited blocks effectively undoes this and is only to blindly follow CSW over corecucks. Peercoin needs to catch up before we can start leading the tech market and if this is the best and easiest implementation to get us on their level, then so be it. As far as I can tell, it does not damage the economics in any way.