Bitcoin Forum
November 06, 2024, 09:49:50 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Data Chain Idea - by Mikhail  (Read 637 times)
snailbrain (OP)
Legendary
*
Offline Offline

Activity: 1807
Merit: 1020



View Profile
February 19, 2014, 01:58:31 AM
Last edit: February 19, 2014, 02:18:22 AM by snailbrain
 #1

I discussed with Mikhail the possibility of a Datacoin (not the altcoin that's been made.. a real one)..

Mikhail passed away a couple of days ago..

after some quick discussion he sent me this .. i'm sure he did not think on it properly so it may be flawed, and it was only a quick thought..
(was 7 months ago now)

maybe the information is useful to someone for some other "ideas":

Quote
Suppose we create multiple parallel blockchains. Lowest is very fast (a block each 10 sec, or even 1 sec), the next one is e.g. block per minute, then 10 min etc. The topmost can be a block per day, or even a block per week.

Together they form a Merkle tree. Also the chains form a skip-list, see http://en.wikipedia.org/wiki/Skiplist

All chains support merged mining with each other. Difficulties are locked together, as are the block rewards (proportional to the desired block frequency).

Merged mining: miners mine the topmost chain only. But if they fail to meet the difficulty target, they still can try submitting the block to lower levels.

The tricky part: how to properly construct the Merkle tree, so the block is insertable into any level without modification? I think it's possible, but not sure how.

Now we have useful properties: the lowest level can be used for sending messages, since it's very fast. Even file sharing may be possible.

Miners are obliged to store all levels. So they need large HDD and good network connection, not only fast GPUs. Otherwise they'll get stale blocks in the lowest level (but still can mine on higher levels with less profit). Hopefully, this may result in a good distributed data storage.

Casual users download only the topmost level (1 block per day - not much data). Then they can navigate deeper as necessary, to access only specific low-level blocks (by querying them from the network).

Though top-level blocks should somehow contain a digest of transactions (a list of spent outputs?) over the whole block range of lower levels. Essentially every higher level is an array of checkpoints for previous level.

Optional things:
1) low-level chain can die and reborn every 2.5 days. So not to waste lot of space. Like in BitMessage.
1a) this can be applied to every level except the topmost. Each level has a finite lifetime. Topmost level is eternal.
1b) users can send data (e.g. messages) to higher levels to keep it for longer time - but the fee is also higher.

2) transactions can be roaming between levels - but also we can use the concept of coloured coins instead. Coins propagate to upper levels by trading with them. Coins at higher levels are used for long-term savings. Coins at lower levels are used for paying fees when sending data, registering names etc.
(not sure if it's possible to reach a good balance between supply/demand though)


-- Mikhail

jl2012
Legendary
*
Offline Offline

Activity: 1792
Merit: 1111


View Profile
February 19, 2014, 04:42:08 AM
 #2

But why do we need consensus/timestamping for data storage? We may need consensus/timestamping for hash of data, but don't really need it for the data per se.

I discussed with Mikhail the possibility of a Datacoin (not the altcoin that's been made.. a real one)..

Mikhail passed away a couple of days ago..

after some quick discussion he sent me this .. i'm sure he did not think on it properly so it may be flawed, and it was only a quick thought..
(was 7 months ago now)

maybe the information is useful to someone for some other "ideas":

Quote
Suppose we create multiple parallel blockchains. Lowest is very fast (a block each 10 sec, or even 1 sec), the next one is e.g. block per minute, then 10 min etc. The topmost can be a block per day, or even a block per week.

Together they form a Merkle tree. Also the chains form a skip-list, see http://en.wikipedia.org/wiki/Skiplist

All chains support merged mining with each other. Difficulties are locked together, as are the block rewards (proportional to the desired block frequency).

Merged mining: miners mine the topmost chain only. But if they fail to meet the difficulty target, they still can try submitting the block to lower levels.

The tricky part: how to properly construct the Merkle tree, so the block is insertable into any level without modification? I think it's possible, but not sure how.

Now we have useful properties: the lowest level can be used for sending messages, since it's very fast. Even file sharing may be possible.

Miners are obliged to store all levels. So they need large HDD and good network connection, not only fast GPUs. Otherwise they'll get stale blocks in the lowest level (but still can mine on higher levels with less profit). Hopefully, this may result in a good distributed data storage.

Casual users download only the topmost level (1 block per day - not much data). Then they can navigate deeper as necessary, to access only specific low-level blocks (by querying them from the network).

Though top-level blocks should somehow contain a digest of transactions (a list of spent outputs?) over the whole block range of lower levels. Essentially every higher level is an array of checkpoints for previous level.

Optional things:
1) low-level chain can die and reborn every 2.5 days. So not to waste lot of space. Like in BitMessage.
1a) this can be applied to every level except the topmost. Each level has a finite lifetime. Topmost level is eternal.
1b) users can send data (e.g. messages) to higher levels to keep it for longer time - but the fee is also higher.

2) transactions can be roaming between levels - but also we can use the concept of coloured coins instead. Coins propagate to upper levels by trading with them. Coins at higher levels are used for long-term savings. Coins at lower levels are used for paying fees when sending data, registering names etc.
(not sure if it's possible to reach a good balance between supply/demand though)


-- Mikhail

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!