Most people would not be able to make a redesigned Proof-of-concept Bitcoin clone, even if they happen to be a programmer, because the codebase is really vast and so you'd have to use one of the early versions that are small enough for a single person to successfully tweak.
the codebase may seem very vast. but it also has alot of cludgy code in it to seem vast
(usually developers purposefully make it cludgy and hard to read/follow to stop outsiders from competing/changing things)
there are simpler ways to add checks/rules for certain data types. far simpler then the cludge sipa implemented over the years
even things like checking block rewards.
todays code had the coin= units / 100000000 and then more code to then show a 50btc
and then more code to show a depreciation factor of 50% per 210k block and then counting them out
however simply by saying block reward starts at
binary: 100101010000001011111001000000000
(5000000000sat aka 50btc)and each halving is
binary: 10010101000000101111100100000000
0 (2500000000sat aka 25btc)binary: 1001010100000010111110010000000
00 (1250000000sat aka 12.5btc)binary: 100101010000001011111001000000
000 (625000000sat aka 6.25btc)and so on
can be done in code form far far far easier
Blockchain culling. After a certain period of time, old redundant transactions would be archived and removed from the active blockchain to keep its size relatively manageable. As there are no chargebacks, there is no reason to list every transaction on chain.
What? How is that even possible, without destroying full blockchain verification?
a method can be what has been theorised before as a 'ball and chain'
(ball is a unspent snapshot of a milestoned point dataset. then the normal chain updating from it)
imagine at block 210,000 a snapshot of the utxo is saved and a hash ID is created.
this hash id is put into an op return of coinbase of a block so that its hash is locked into the blockchain as a reference and then after another far later milestone when it shows acceptance and agreement of that snapshot by the masses, by not rejecting blocks containing it
meaning masses agree that their snapshot complies with the same hash as the one in the opreturn reference.. that then becomes the list of unspents from the standing point of block 209999
then instead of storing full blocks of 0-209999 it stores just the unspents of that milestone
then repeat at block 420k and 630k and 840k
as for what id change
all tx formats have rules.. with byte limits to keep tx as lean as possible
where a certain opcode has the anyonecanspend(no limit/format/check) but the opcode is disabled be default UNTIL good clean code is reviewed independantly and scrutinised for validation bugs. and then activating the opcode, which requires nodes to upgrade. then activates the new tx format with all checks and validation rules implace including byte length thats fits it sole purpose