Blockchain immutable - modifying blocks

ABCbits

legendary

Activity: 2870

Merit: 7490

Crypto Swap Exchange

Quote from: redigaffi on May 16, 2018, 03:22:59 AM

Quote from: ?? on ??

Quote from: bob123 on May 15, 2018, 04:35:39 AM

Quote from: redigaffi on May 15, 2018, 04:21:08 AM

Quote from: innovator256 on May 15, 2018, 04:08:43 AM

you would be creating a problem rather than a solution in the long run. Such data could be stored on ipfs anchored to the actual chain

Could you elaborate your answer a little bit more please?

I can't follow this statement either..

Surely he means such idea/project better done with InterPlanetary File System where node don't need to store each data. On high-level, it's similar with Torrent file distribution.

Quote from: redigaffi on May 15, 2018, 03:38:37 AM

Would that be a good fit for this problem?

Not bad idea, but IMO it would be better if :
* the type of the changes is "updated_post" or "edited_post", not "post". It's even shorter if we use type_id instead to lower the size.
* Only input the info/post changes to lower the size. Similar with Git commit where git only save the different part to save storage space and make commit process faster.

Good idea, surely that would save a lot of space/memory in the long run, but that would add an extra layer of complexity.

True, but that would make scaling easier even though there's higher computation power needed to make and verify the differences.
IMHO longer development time or higher complexity is bigger than sacrifice decentralization.

redigaffi

member

Activity: 142

Merit: 13

Quote from: ?? on ??

Quote from: bob123 on May 15, 2018, 04:35:39 AM

Quote from: redigaffi on May 15, 2018, 04:21:08 AM

Quote from: innovator256 on May 15, 2018, 04:08:43 AM

you would be creating a problem rather than a solution in the long run. Such data could be stored on ipfs anchored to the actual chain

Could you elaborate your answer a little bit more please?

I can't follow this statement either..

Surely he means such idea/project better done with InterPlanetary File System where node don't need to store each data. On high-level, it's similar with Torrent file distribution.

Quote from: redigaffi on May 15, 2018, 03:38:37 AM

Would that be a good fit for this problem?

Not bad idea, but IMO it would be better if :
* the type of the changes is "updated_post" or "edited_post", not "post". It's even shorter if we use type_id instead to lower the size.
* Only input the info/post changes to lower the size. Similar with Git commit where git only save the different part to save storage space and make commit process faster.

Good idea, surely that would save a lot of space/memory in the long run, but that would add an extra layer of complexity.

redigaffi

member

Activity: 142

Merit: 13

Quote from: bob123 on May 15, 2018, 04:35:39 AM

Quote from: redigaffi on May 15, 2018, 04:21:08 AM

Quote from: innovator256 on May 15, 2018, 04:08:43 AM

you would be creating a problem rather than a solution in the long run. Such data could be stored on ipfs anchored to the actual chain

Could you elaborate your answer a little bit more please?

I can't follow this statement either..

Quote from: redigaffi on May 15, 2018, 04:21:08 AM

Thanks for the answers, so the idea would have a web platform that will be always keep on sync with the blockchain, so this problem would be solved, since the user has no client and he doesn't needs to update it.

This would work.
But if this web platform is only running on your server (without being open source), then what is the reason to use a blockchain?
You would create a centralised platform utilizing an inefficient data structure.

If you want to build a centralised platform, use another form of storage. A simple databse would be way more efficient.
If you want to build a decentralised platform, other people need the ability to connect to your network (without relying on your server/web application).

Well no, because for example, CryptoKitties is on Blockchain, but the application is running on a private server. So the idea is to have the web application using the Blockchain and having the Blockchain with full access open to the world with an api so everybody who want can build stuff and mess around, so i don't think that's correct, because CryptoKitties is using the same approach, right?

bob123

legendary

Activity: 1624

Merit: 2481

Quote from: redigaffi on May 15, 2018, 04:21:08 AM

Quote from: innovator256 on May 15, 2018, 04:08:43 AM

you would be creating a problem rather than a solution in the long run. Such data could be stored on ipfs anchored to the actual chain

Could you elaborate your answer a little bit more please?

I can't follow this statement either..

Quote from: redigaffi on May 15, 2018, 04:21:08 AM

Thanks for the answers, so the idea would have a web platform that will be always keep on sync with the blockchain, so this problem would be solved, since the user has no client and he doesn't needs to update it.

This would work.
But if this web platform is only running on your server (without being open source), then what is the reason to use a blockchain?
You would create a centralised platform utilizing an inefficient data structure.

If you want to build a centralised platform, use another form of storage. A simple databse would be way more efficient.
If you want to build a decentralised platform, other people need the ability to connect to your network (without relying on your server/web application).

redigaffi

member

Activity: 142

Merit: 13

Quote from: innovator256 on May 15, 2018, 04:08:43 AM

you would be creating a problem rather than a solution in the long run. Such data could be stored on ipfs anchored to the actual chain

Could you elaborate your answer a little bit more please?

Quote from: bob123 on May 15, 2018, 04:06:24 AM

Quote from: redigaffi on May 15, 2018, 03:38:37 AM

Would that be a good fit for this problem?

Since you are working on an immutable data structure the only way of accomplishing such an 'update' would be to reference to the old block/tx/message.
You approach should just work fine. That would have been my first approach too.

You just have to keep in mind that you still need verification (only poster of the first message can 'update' this message).

But note that the displaying of those messages (especially the updated messages) is done client-side.
It is definetely possible to see all old messages. The client has to be set up correctly and needs to have the blockchain synced and verified to display all messages/posts correctly.

Lets pretend the following:
Alice does post some text at block X.
Alice does edit this post at block X+10.

If Bob opens his clients and syncs, the moment he reaches block X, he will see the first post by Alice.
This will be the only message bob will see until he has synced up to block X+10.

Short answer: Yes, i think so.

Thanks for the answers, so the idea would have a web platform that will be always keep on sync with the blockchain, so this problem would be solved, since the user has no client and he doesn't needs to update it.

innovator256

member

Activity: 97

Merit: 10

you would be creating a problem rather than a solution in the long run. Such data could be stored on ipfs anchored to the actual chain

bob123

legendary

Activity: 1624

Merit: 2481

Quote from: redigaffi on May 15, 2018, 03:38:37 AM

Would that be a good fit for this problem?

Since you are working on an immutable data structure the only way of accomplishing such an 'update' would be to reference to the old block/tx/message.
You approach should just work fine. That would have been my first approach too.

You just have to keep in mind that you still need verification (only poster of the first message can 'update' this message).

But note that the displaying of those messages (especially the updated messages) is done client-side.
It is definetely possible to see all old messages. The client has to be set up correctly and needs to have the blockchain synced and verified to display all messages/posts correctly.

Lets pretend the following:
Alice does post some text at block X.
Alice does edit this post at block X+10.

If Bob opens his clients and syncs, the moment he reaches block X, he will see the first post by Alice.
This will be the only message bob will see until he has synced up to block X+10.

Short answer: Yes, i think so.

redigaffi

member

Activity: 142

Merit: 13

Hello, this is not related to cryptocurrency, it's more about Blockchain.

This is the scenario: Social network built on top of blockchain.

Imagine that a users publish a post. And later he noticed a wrong part in his message and want to edit that part, but since it's already in the Blockchain and it's immutable, how would you proceed in this scenario. I have a way to go, but not sure if it's the best:

Block1:
- id: 1
- type: "post"
- Message: "Hello world"

Block2:
- id: 2
- parent_id: 1
- type: "post"
- Message: "Hello world v2"

So in the users profile would be displayed block1, so the first message unless another block with parent_id pointing to the old block is pointing, then I would use the last "version" of the block.

The idea would be like creating different "versions" of a same block.

Would that be a good fit for this problem?

Topic: Blockchain immutable - modifying blocks (Read 223 times)