I would like to give my though about it. Public and shared data can only be modified be the owner. The blockchain need to be modifiable be anyone I guess. And in private side, all blockchains are the same that should be easy. As long has you have the fee to cover storage. Which could be huge for everyone to start with. 50 GB so far…
If you just mean storing the blockchain file, then yes it is still valid.
The blockchain file would benefit of from de-duplication too, whether public or privately stored, thanks to self-encryption. This would mean that only one PUT of a valid block would need to be made, making storage attempts free for everyone else.
This should allow huge blockchains to be stored/accessed cheaply.
If you are talking about native safe net blockchain data structures, then that is a different question though.
1 Like
I changed my mind. Find a public copy of the blockchain if any. Copy the datamap to your private one. Make sure you have enough space available to append new block. Link the bitcoin core to it. And it’s all done. The cheapest way I found so far.
@Traktion, do you think the public can really work? I mean, the bitcoin core is not made like that. Sharing a public blockchain…
I don’t see why this can’t work.
Normally the bitcoin wallet starts by downloading the blockchain. It then runs over every block verifying it. If the blockchain is stored on SAFE, you would just point the wallet at the immutable public copy and it would verify every block in the chain as if it had downloaded it. Once it has done this it just has to handle new block in the normal way and ensure the public copies match and verify with the confirmed blocks received through the network. Only the node creating a new block needs to pay for storage, all the other nodes just check the new block is correct as normal.
1 Like
Anyone can make a public read-only share of their files, including blockchains. This would be useful to bootstrap your node from a trusted source (say, a day/week old to ensure consensus was successfully reached).
I wouldn’t recommend a public read/write share though, as it wouldn’t be a reliable mechanism to append to the blockchain. I would suggest people just write to their own copy and allow de-duplication to work its magic.
Ofc, this is all for non-native clients, which just need file system access. There is a whole separate debate over whether transaction sequences can be created natively using the REST API to write structured data types directly. We had a great debate about that here: Public Ledgers and Proof of Transparency on SAFE
1 Like
I understand what you mean. But is the SAFE Network really support that everyone can write on one public copy. I really dough about it, but if it’s the case, everyone is happy. But still again, I suspect a very big security issue about that.
It could but as @traktion notes it might not be the best way. However, it might well be made to work because all data is versioned and so it may be possible to ensure that once a new block is written and you’ve checked it you can never be fooled by someone over-writing it. Either way, I think a solution can be found which at the least means people no longer have to store an ever increasing blockchain locally, or rely on centralised copies that they can’t verify.
However, I think the uses of blockchains will be much limited once Safecoin is proven, because of their obvious problems with scaling, energy inefficiency and centralisation risks.
2 Likes
Right now (and it may be different tomorrow) I think there will always be a place for blockchain based cryptocoins as long as SAFEcoin is indivisible and hence is of little use as a trading token outside the SAFE network itself.
If that blockchain is hosted more securely and accessed faster on the SAFE network then all to the good.
Would a wallet for such a coin have to be paid for each time it was used though? I can certainly see it being a popular piece of code.
1 Like
With versioned that could be cool. But first the client have to verify the block validity before trusting any version for each block on first run but after that. I think that could be very optimal. For new block the client don’t trust it until it’s confirmed.
@Southside, that can be one of all other possibles solutions that could come later.
1 Like
who said safecoin is indivisible wtf
Back in August, lots of people said safecoin is indivisible.
Please point me now to a reference which explicitly states that safecoin IS divisible.
The safecoin will be divisible but not in the beginning.
Each safecoin is represented as a piece of data held by the group
closest to it’s ID. Safecoin data structure is defined as:
‘’‘rust
ID: 64 bytes
OWNER: 64 bytes
‘’’
The ID of a safecoin is 64Bytes long, with the most meaningful 32 bits
being sequenced index starts from 0 to 4294967295, and the left over
part to be fullfiled with all zeros or other pre-defined pattern (to
allow coin division).
So for all practical purposes, including writing apps that use micropayments - Safecoin is indivisible
2 Likes