Fixing transaction malleability on peercoin


#110

You can see that in the scaling column here: The Bitcoin Cash Roadmap


#111

Some people still think this is a Bitcoin forum.


#112

At 500 billion txns/day, we would run out of peercoin to burn in ~7 minutes. Assuming block spacing doesn’t change, what application could ever require a block big enough to burn the entire Peercoin supply?


#113

We can hardfork the fee down, but that’s not the point. Bitcoin Core has serious issues handling just moderately sized blocks (8 - 32MB). The reason for this is that no developer in Bitcoin Core sees any reason to optimize the software for base blocks bigger than 1MB. This makes sense in Bitcoin Core since the base blocksize limit never will be increased.


#114

I was under the impression the average block size was ~.5MB on Peercoin


#115

Plan for the future. You could spam-lock Peercoin currently for a cost of ~1 PPC/min. 32 MB blocks would cost ~32 PPC/min to spam lock. Just to remind, spam locking is not a hard lockout of ppls txns, just makes it much less user friendly as you have to start participating in a fee market.


#116

Yes. Bigger blocksize limit will make spamming much more expensive. It is also needed if we actually want people to use the chain. That’s why I think it is sad that we lean on a code base (Bitcoin Core) that will not optimize for base blocks bigger than 1MB.


#117

Why increase the blocksize if we want most of transactions to happen off-chain?


#118

Because we want the fee to determine the size of the blocks and not an artificial production quota like the blocksize limit. 1MB is also a ridiculously small limit for a world wide financial system and there is a limit to how many transactions that can take place off-chain. At some point you have to settle on-chain.


#119

But fees are fixed on the Peercoin network, we’ve made this choice already back in 2012. Peercoin has no fee market so technically we can increase the block size to n Mb, and economic system will remain the same. I agree that 1MB is low, but seeing how nobody uses crypto except in cases of mass hysteria (2017 bubble), it’s obvious that 1MB can serve us just fine for years to come.


#120

I agree that 1MB most likely will be fine for many years, but the problem is that it will be very hard to turn around to a new code base when we go over 1MB. I prefer to plan for success. All the complexity added by SegWit will also be a major pain we have to carry for eternity.


#121

No it’s not hard as you make it out to be. Beside we’re not a bloody Litecoin and we can’t have a new rebase with 6 lines changed, it took us months to port Peercoin to new base. We run quite a bit different code. We are kinda used to re implementation and refactoring. Also segwit is optional and bolted on, it can be stripped of at any moment (in case your camps wild claims come true).


#122

Problem is that if you start doing SegWit transactions on the blockchain you have to continue supporting it. Bitcoin Core supports SegWit, but not bigger blocks than 8MB. Bitcoin ABC supports bigger blocks, but not SegWit. So just doing a simple rebase will not be an option with SegWit implemented.


#123

Segwit is fine, it’s a bit too complex and “clumsy” but it’s fine. My biggest plus of it is actually HTLC contract schema actually, not fixing the txn malleability.

I want to position Peercoin in a place where we can cherry pick what we like and need from both Bitcoin camps, while leaning a bit more onto Core as it’s far more politically stable and less in danger of implosion. I see nothing which would stop us from cherry picking whatever we like from ABC and Unlimited.

Ever since I’ve made a call to lean onto core for reference implementation rebase, Cash camp has split further into two (or more, IDK), which corroborates that my decision was rational.


#124

SegWit is not “fine”. Most of the developers stayed on Bitcoin ABC, so BSV does not have much of an impact.


#125

Well nothing is fine if you will view it from certain angle.
For example: having a transaction timestamp is not fine, yet we have it and will sink remarkable resources into it’s removal from the protocol.

In a ideal world we’d implement a 100% new codebase tailored for the needs of Peercoin, and Peercoin alone. We’d also start the chain from scratch with a modernized protocol so we don’t have to think about backward compatibility.

However world is not ideal and we can’t afford to do all the stuff we wanted to so we sometimes have to cherry pick from what is offered out there.


#126

Why not wait for a simple tx mal fix showing up?


#127

As I explained before we started moving in this direction, we don’t have the luxury of waiting around for the perfect solution. We must show the community and investors that we are making progress. We can’t afford to be stagnant. Simply waiting around and making no progress at all will stall the project, which will lead to its death. Continuing to move forward (even if circumstances are less than ideal) will ensure Peercoin keeps up with the latest tech advancements, which will help attract attention and investors.


#128

I would not describe SegWit as progress. Quite the contrary.


#129

I believe that if you’ve invested as much time in inventing and implementing a Segwit alternative which fits our needs as you’ve invested in writing posts here you’d be just about done by now.