@icedquinn Yeah, I totally get that. But it seems like space concerns are going we way of hierarchical directory structures; that is, kids these days don't know anything about them.

@worldsendless you can avoid this with a "fractal cascade," ex. every thousand entries is put in a sub-chain (which in turn every thousand entries in that is a sub-sub-chain) which means the amount of data required to be stored grows significantly slower.

i'm not aware of anyone who does it though.

@icedquinn The idea being that you are only ever dealing with a smaller piece of the blockchain, rather than all of it?

@icedquinn

The reason this is generally not done is because the security of any one chain is only as large as the number of participants on that chain (depending on the type of validation done that may be PoW, PoS or whatever). Therefore the challenge is to ensure you dont partition your chains to the point that any one chain can be broken through a 51% attack. Regardless any partitioning at all of this nature will always be a trade off between some degree of security and efficiency (of which space efficiency is pat of that).

@worldsendless

@freemo @worldsendless they are the same chain. the fractal log is just a hash of the N-th checksum at that point in time which verifies that entire history from the point back (since any changes in the past would break the merkel dag etc)

@freemo @worldsendless ardor actually does a limited form of this where it has many independent chains that checkpoint themselves to the master ardor chain, but its genuinely doing sub-chains and not just fractally storing tree hashes.

@freemo @worldsendless ex. it’s always possible to retain the genesis block if you want to but you only have to store up to the latest checkpoint. which means lots of cheap nodes can exist with fixed-size storages.

also hi been a while

@icedquinn

Its not changes to the history im worried about. In a 51% attack you can effectively issue brand **new** transactionns on the side chain that can get validated when they shouldnt be. Though again there are solution.

@worldsendless

@freemo @worldsendless it's not really a side chain though. it's just a checkpoint of the master chain at reducing frequencies.

if you tried to shove new entries in the 1,000 log, anyone could still check that the master log actually hashes to that.

@freemo @worldsendless light nodes already do something like this IIRC where they store back to some arbitrary block and just assume everything older than that is still valid.

which is worse. lol

@icedquinn

Yes light nodes contribute **nothing** to the security of the network. Their main purpose is just so you can have a local wallet going without needing 100 TB hard drive :)

@worldsendless

@freemo @worldsendless i would disagree. they still increase the difficulty of attacks, since conning them to believing a deep history is not trivial

@icedquinn

Yea but conning them into bieving a fake history doesnt actually constitute an attack since they arent the ones validating the history. You might be able to convince them they have a balance they dont have if you overtake a majority of their peers, but since they arent validating transactions themselves that wont do anything useful since they will discover it was all a lie the second they try to act on it (Such as accepting or sending money that doesnt really exist).

@worldsendless

@icedquinn

Ahh, well in that case yea that could work.

@worldsendless

@freemo @worldsendless yeah. so NXT had the idea of prunable transactions which means the permanent log just proves some blob once existed, but that blob's data can be purged when the data is no longer important or if your node just doesn't care.

ardor brings in the idea of checkpointing side chains.

XTDB is somewhere around NXT but all entries are said prunable blocks. (although all bitemporality means is that there is a "created_at" and "valid_at" timer, which you can just add in any sql table )