You can see that in the scaling column here: The Bitcoin Cash Roadmap
Some people still think this is a Bitcoin forum.
1 Like
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?
1 Like
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.
I was under the impression the average block size was ~.5MB on Peercoin
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.
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.
Why increase the blocksize if we want most of transactions to happen off-chain?
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.
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.
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.
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).
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.
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.
2 Likes
SegWit is not âfineâ. Most of the developers stayed on Bitcoin ABC, so BSV does not have much of an impact.
1 Like
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.
4 Likes
Why not wait for a simple tx mal fix showing up?
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.
I would not describe SegWit as progress. Quite the contrary.
1 Like
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.
1 Like