Topic: [DTC] Datacoin - Brainstorming Giveaway - Get coins for sharing ideas! - page 3. (Read 9159 times)
November 21, 2013, 04:51:35 AM
Hopefully oocook5u comes to DTC threads today and answers some questions.
November 21, 2013, 02:49:19 AM
Should add PoS, PoS would encourage more nodes to stay up 24-7 and supply the needed bandwidth, it looks like this chain could be very very large. If would also encourage older cpus to run nodes for income.
and of course contact some of the torrent sites and work with them for easy implementation
D5kXcUMUTZ56ctCiRLBMd5w3JUviaMe3fP
and of course contact some of the torrent sites and work with them for easy implementation
D5kXcUMUTZ56ctCiRLBMd5w3JUviaMe3fP
It was obvious - why anyone didn't offer it yet?
(me too, lol)Additional DTC for you for this suggestion!
Thanks!
I also wonder if having some option to remove data at some point would be a good idea, if whomever added it so chooses. May help if this gets widely used at at some point and the burden becomes great as well. Not sure if this is feasible, but of course some data will become obsolete over time.
In regards to the data removal, what could be done, is that the DTC account that added would have to pay a subscription of sorts, to keep the data in the blockchain, such as 0.0000001 DTC per block or some other interval. This would ensure that it isn't just useless information being added. And to keep useful data in the chian there should be a lottery of sorts, for the most accessed/downloaded blocks, giving them a portion of the mined DTCs. I understand there may be potential abuse by the posters continually accessing a block to give themselves a higher chance of winning the lottery, but one could simply make a hashcheck of the ip looking to access the block, and only give them a point if it is the first access of the block.
DJ4gDVPkWNgRP1sGrFrwA5p7jdbRbHEFQZ
Very interesting, but seems to be difficult to implement
Sent coins!
I'd imagine that data removal would be possible by consensus of the network in the same way that data can be added. For example, data could be removed if a specially formed message was sent from the same address as the original data.. or perhaps the client could be designed so that data automatically expires after a time, requiring it to be re-inserted at intervals if you want to keep it there (similar to what I have heard about the blockchain used by Bitmessage). Perhaps there could even be different levels of fees for permanent or shorter-term storage, all regulated by the p2p nature of the software. I assume it would be possible in principle but difficult to implement any of this
While useful for some applications and keeping the blockchain size down, I kinda like the simplicity of the initial idea: that all data is kept for all time.Sent coins to everyone so far!
November 21, 2013, 02:33:55 AM
Should add PoS, PoS would encourage more nodes to stay up 24-7 and supply the needed bandwidth, it looks like this chain could be very very large. If would also encourage older cpus to run nodes for income.
and of course contact some of the torrent sites and work with them for easy implementation
D5kXcUMUTZ56ctCiRLBMd5w3JUviaMe3fP
and of course contact some of the torrent sites and work with them for easy implementation
D5kXcUMUTZ56ctCiRLBMd5w3JUviaMe3fP
It was obvious - why anyone didn't offer it yet?
(me too, lol)Additional DTC for you for this suggestion!
Thanks!
I also wonder if having some option to remove data at some point would be a good idea, if whomever added it so chooses. May help if this gets widely used at at some point and the burden becomes great as well. Not sure if this is feasible, but of course some data will become obsolete over time.
In regards to the data removal, what could be done, is that the DTC account that added would have to pay a subscription of sorts, to keep the data in the blockchain, such as 0.0000001 DTC per block or some other interval. This would ensure that it isn't just useless information being added. And to keep useful data in the chian there should be a lottery of sorts, for the most accessed/downloaded blocks, giving them a portion of the mined DTCs. I understand there may be potential abuse by the posters continually accessing a block to give themselves a higher chance of winning the lottery, but one could simply make a hashcheck of the ip looking to access the block, and only give them a point if it is the first access of the block.
DJ4gDVPkWNgRP1sGrFrwA5p7jdbRbHEFQZ
Very interesting, but seems to be difficult to implement
Sent coins!
November 20, 2013, 09:16:32 PM
Should add PoS, PoS would encourage more nodes to stay up 24-7 and supply the needed bandwidth, it looks like this chain could be very very large. If would also encourage older cpus to run nodes for income.
and of course contact some of the torrent sites and work with them for easy implementation
D5kXcUMUTZ56ctCiRLBMd5w3JUviaMe3fP
and of course contact some of the torrent sites and work with them for easy implementation
D5kXcUMUTZ56ctCiRLBMd5w3JUviaMe3fP
yeah pos with good interest , it is possible for the dev to add that feature at this stage?
November 20, 2013, 08:48:00 PM
To keep the local data size manageable, we can store the old data on like 100 servers & new clients given the option to download it, if they want to. There servers can be daisy-chained & intermittently checked for data consistency. Anyone willing to provide the server space can be added to the chain.
On client side, the client will be update whenever there is proposed moving to data server & choice if they want to keep the data locally.
Regards.
On client side, the client will be update whenever there is proposed moving to data server & choice if they want to keep the data locally.
Regards.
November 20, 2013, 07:58:39 PM
Should add PoS, PoS would encourage more nodes to stay up 24-7 and supply the needed bandwidth, it looks like this chain could be very very large. If would also encourage older cpus to run nodes for income.
and of course contact some of the torrent sites and work with them for easy implementation
D5kXcUMUTZ56ctCiRLBMd5w3JUviaMe3fP
and of course contact some of the torrent sites and work with them for easy implementation
D5kXcUMUTZ56ctCiRLBMd5w3JUviaMe3fP
It was obvious - why anyone didn't offer it yet?
(me too, lol)Additional DTC for you for this suggestion!
Thanks!
I also wonder if having some option to remove data at some point would be a good idea, if whomever added it so chooses. May help if this gets widely used at at some point and the burden becomes great as well. Not sure if this is feasible, but of course some data will become obsolete over time.
In regards to the data removal, what could be done, is that the DTC account that added would have to pay a subscription of sorts, to keep the data in the blockchain, such as 0.0000001 DTC per block or some other interval. This would ensure that it isn't just useless information being added. And to keep useful data in the chian there should be a lottery of sorts, for the most accessed/downloaded blocks, giving them a portion of the mined DTCs. I understand there may be potential abuse by the posters continually accessing a block to give themselves a higher chance of winning the lottery, but one could simply make a hashcheck of the ip looking to access the block, and only give them a point if it is the first access of the block.
DJ4gDVPkWNgRP1sGrFrwA5p7jdbRbHEFQZ
November 20, 2013, 07:56:50 PM
DKBkig9hykkqo7GLq6Vg7jEAwT9XLeNMUJ
thanks
i have no idea at the moment, but i'm working hard on it!
Thanks
thanks
i have no idea at the moment, but i'm working hard on it!
Thanks
November 20, 2013, 05:20:44 PM
I asked Cryptsy to add Datacoin (as a feature request on the support forums)
https://cryptsy.freshdesk.com/support/discussions/topics/41010
Perhaps others should go and support the request.
https://cryptsy.freshdesk.com/support/discussions/topics/41010
Perhaps others should go and support the request.
November 20, 2013, 04:32:16 PM
Should add PoS, PoS would encourage more nodes to stay up 24-7 and supply the needed bandwidth, it looks like this chain could be very very large. If would also encourage older cpus to run nodes for income.
and of course contact some of the torrent sites and work with them for easy implementation
D5kXcUMUTZ56ctCiRLBMd5w3JUviaMe3fP
and of course contact some of the torrent sites and work with them for easy implementation
D5kXcUMUTZ56ctCiRLBMd5w3JUviaMe3fP
It was obvious - why anyone didn't offer it yet?
(me too, lol)Additional DTC for you for this suggestion!
Thanks!
I also wonder if having some option to remove data at some point would be a good idea, if whomever added it so chooses. May help if this gets widely used at at some point and the burden becomes great as well. Not sure if this is feasible, but of course some data will become obsolete over time.
This is good idea, but I don't know if there is a possibility to delete any info from blockchain. Solution can be splitting it into smaller parts that will be stored on computers: 1000 copies of one part on 1000 computer, etc etc
November 20, 2013, 12:33:01 PM
Should add PoS, PoS would encourage more nodes to stay up 24-7 and supply the needed bandwidth, it looks like this chain could be very very large. If would also encourage older cpus to run nodes for income.
and of course contact some of the torrent sites and work with them for easy implementation
D5kXcUMUTZ56ctCiRLBMd5w3JUviaMe3fP
and of course contact some of the torrent sites and work with them for easy implementation
D5kXcUMUTZ56ctCiRLBMd5w3JUviaMe3fP
It was obvious - why anyone didn't offer it yet?
(me too, lol)Additional DTC for you for this suggestion!
Thanks!
I also wonder if having some option to remove data at some point would be a good idea, if whomever added it so chooses. May help if this gets widely used at at some point and the burden becomes great as well. Not sure if this is feasible, but of course some data will become obsolete over time.
November 20, 2013, 11:33:44 AM
Should add PoS, PoS would encourage more nodes to stay up 24-7 and supply the needed bandwidth, it looks like this chain could be very very large. If would also encourage older cpus to run nodes for income.
and of course contact some of the torrent sites and work with them for easy implementation
D5kXcUMUTZ56ctCiRLBMd5w3JUviaMe3fP
and of course contact some of the torrent sites and work with them for easy implementation
D5kXcUMUTZ56ctCiRLBMd5w3JUviaMe3fP
It was obvious - why anyone didn't offer it yet?
(me too, lol)Additional DTC for you for this suggestion!
November 20, 2013, 11:02:07 AM
Should add PoS, PoS would encourage more nodes to stay up 24-7 and supply the needed bandwidth, it looks like this chain could be very very large. If would also encourage older cpus to run nodes for income.
and of course contact some of the torrent sites and work with them for easy implementation
D5kXcUMUTZ56ctCiRLBMd5w3JUviaMe3fP
and of course contact some of the torrent sites and work with them for easy implementation
D5kXcUMUTZ56ctCiRLBMd5w3JUviaMe3fP
November 20, 2013, 10:59:52 AM
you could save websites as text only into the data stream to create something like archive.org
DS9bJD8qeBAdgS9xbTrYu4Pcqwjr4A1dyi
DS9bJD8qeBAdgS9xbTrYu4Pcqwjr4A1dyi
November 20, 2013, 10:19:01 AM
For larger data files, rather than increasing the size limit per block, have some sort of protocol that would allow 128kb divisions of the file to be made and spread over the blockchain that way. Of course something would need to be done to clearly order and connect those blocks of data. One could for example make several 128kb RAR divisions, but something at least needs to be implemented to connect the blocks.
One way would be to just include header data along with your payload. Eg. If you were to upload a 500kb file, the client could break it up into 127k chunks. Then attach a 1kb header along with each one. It's basically just a linked list where each data package is an item. The client can then get the address of the next message as it reads the current one. So like:
msg1:
header:
next_msg: {msg2_location}
data:
{127k_of_data}
msg2:
header:
next_msg: {msg3_location}
data:
{127k_of_data}
msg3:
header:
next_msg: {msg4_location}
data:
{127k_of_data}
msg4:
header:
next_msg: {NONE}
data:
{119k_of_data}
Ideally there should be some sort of standard so that different clients could understand how each other are adding data to the network. The system could support multiple data storage methods as long as info about which method was being used was also included in the header of a message.
Very good idea! Please post your wallet to receive your DTC (with some additional coins, not 5
)edited: found it at 1st page, sent coins.
Also thanks to lengfeng847, but can you explain point 2 ?
November 20, 2013, 09:47:03 AM
DFD4xTw59ssgaAgRAg5mxXSftHDE43nFGw thanks!
November 20, 2013, 09:14:26 AM
1. Develop an advertising system which the user can advertise their product or website
2.Client joins the trading function real-time transaction
DTLdhQvVfTTacDcpqe2wXWgFnrYdkDu5Qx
TRANKS
2.Client joins the trading function real-time transaction
DTLdhQvVfTTacDcpqe2wXWgFnrYdkDu5Qx
TRANKS
November 20, 2013, 08:00:53 AM
For larger data files, rather than increasing the size limit per block, have some sort of protocol that would allow 128kb divisions of the file to be made and spread over the blockchain that way. Of course something would need to be done to clearly order and connect those blocks of data. One could for example make several 128kb RAR divisions, but something at least needs to be implemented to connect the blocks.
One way would be to just include header data along with your payload. Eg. If you were to upload a 500kb file, the client could break it up into 127k chunks. Then attach a 1kb header along with each one. It's basically just a linked list where each data package is an item. The client can then get the address of the next message as it reads the current one. So like:
msg1:
header:
next_msg: {msg2_location}
data:
{127k_of_data}
msg2:
header:
next_msg: {msg3_location}
data:
{127k_of_data}
msg3:
header:
next_msg: {msg4_location}
data:
{127k_of_data}
msg4:
header:
next_msg: {NONE}
data:
{119k_of_data}
Ideally there should be some sort of standard so that different clients could understand how each other are adding data to the network. The system could support multiple data storage methods as long as info about which method was being used was also included in the header of a message.
November 20, 2013, 06:07:49 AM
For larger data files, rather than increasing the size limit per block, have some sort of protocol that would allow 128kb divisions of the file to be made and spread over the blockchain that way. Of course something would need to be done to clearly order and connect those blocks of data. One could for example make several 128kb RAR divisions, but something at least needs to be implemented to connect the blocks.
DJ4gDVPkWNgRP1sGrFrwA5p7jdbRbHEFQZ
DJ4gDVPkWNgRP1sGrFrwA5p7jdbRbHEFQZ
Yes, something like Datacoin Archiver
@slimbo: interesting..
November 20, 2013, 04:56:54 AM
Thanks. 
November 20, 2013, 04:46:59 AM
Not sure if it is possible to implement some kind of mini exchange feature into the client, like ripple gateway.
Adding some type of trusted distributed storage so that the client do not to hold full transaction log may be good too.
Adding some type of trusted distributed storage so that the client do not to hold full transaction log may be good too.
Jump to: