wetube / bitcloud Goto Github PK

Hello
I was looking through the code, and noticed that the code does not compile on Windows
(I am using MingW). Upon further inquiry, it seems that sys/sockets.h will not compile on Windows unless it is a Cygwin build environment. This does seem a potential problem, as we have no assurity that the node runners will be running a BSD compatible environment.

Perhaps a configure.sh script or some other thing be created so that it can detect such a change and compile accordingly? As we could try and limit the socket code to a socket class, all we would need is to create a good wrapper around the class, so the rest of the code can safely ignore whether winsocks or sys/socket.h is being used, and let the socket class handle it based on the environment.

In "Monetizing a Meshnet" you have a typo.

"There have many different" should read "There have been many different"

+been

Log all tested actions/events in a standard format and enter each action/event to the nodepool logs table.

Test by outputing the full contents of the logs as a CSV file.

bitcloud -writelogs

@Dr-Syn says
Names are registered in the actual internet in a hierarchical fashion: ICANN issues TLDs to entities who then sell domain names under those TLDs to other entities. When an entity buys one of those TLDs, they can issue as many subdomain names as their little hearts choose.

Ultimately, every single one of those names is traceable up to a central authority: ICANN.

Even worse, right now, you have an internet name that is traceable up to ICANN. It's not going to be a human-friendly name unless you've taken special means for it to be so--it's going to be, essentially, a serial identifier from your ISP underneath one of your ISP's domains.

Trying to take a centralized heierarchy and then mapping it to a decentralized one is problematic; it's best to leave the centralization out of it and go with something that works better with decentralization.

That means that the least problematic way of addressing names is for everyone to have a UUID--not human-friendly--and give them the option of having whatever human-readable name they like on top of it. If you want a DNS-alike, then that can be linked in to the CA packages, as they're already in the right place to handle that kind of work.

@JavierRSobrino answer:

The fundamental problem with that is that we don't facilitate in any way the use of the system to the users. If each CA has its own DNS-alike hierarchy how can you help a user discriminate between publishers? There could be 100 CAs that call themselves "disney", are we going to impose to the user having to check every single non-human-readable UUID to see who is the authentic?

We are not centralizing the resolution of names by forcing the nodes to have to mine a name if they want it. On the contrary, we are approaching the problem in the same way that Namecoin does, but even better: mining.
There is not an ICANN that decides.

At the end, we also have to mine CAs. The same program can mine a name at the same time they mine the CA. In fact this program could be a sub-packages of the protocol itself. I'm not telling you to include in the protocol. We can just make a reference to it.

• Run the code with $node bitcloud.js . Exit and use command line SQLite interface to validate the resultant DB.
• Document the SQLite commands and validation process so this practice may be maintained throughout development.

Test: have one instance open a socket on a specific IP/port and have another node instance connect to that IP/port, outputting success or error

To be clear, we shall define what is the node pool and what it contains:

The nodepool is a synced file which contains all the signed statistics and verdicts of the actions of all the nodes.

For emitting a verdict, something like this is possible:

(verdict t :reward 1.23 :time 1234 :from 8NDchuk...)
(verdict f :penalization 1.23 :time 1234)

'reward' and 'penalization' are the reputation system.
A false verdict like the above could become into revocation of the CA if reputation reaches 0 or less.
The 'from' is the CA emitting the verdict.

And can be stored in sections and subsections, each one identifying a node by its public key:

(8NDchukUoqH1fjd82r9roqr5c6upCyf5n3
(statistics
(up-time 123)
(n-users 123)
(bandwidth-served 123)
(storage-used)
.....)
(verdicts
(bandwidth
(t :reward 1.23 :time 1234 :from 3jdn3...)
(f :penalization 1.23 :time 1234 :from d8sks....))
(storage
(t :reward.....))
(uptime
...))
(554chukUoqH1fjd82r9roqr5c6upCyfg64
.......)

Any ideas and improvements or rejections to this are welcomed.

It seems the Bitcloud system ensures trust and reliability by linking actions to identities (assoicated with a keypair and an IP address), and banning identities that do not obey the "laws". The blockchain is also based on the identity system by adding a block to the chain when 80% of the identities agree with it.

Using identities in a decentralized system opens up major vulnerabilities to Sybil attacks (where an attacker forges identities to appear as if they are many people on the network).

Bitcloud makes an attempt to prevent Sybil attacks by linking identities to IP addresses, but this is not a viable solution. If you must use a certain IP to spend the money associated with your identity, then when your ISP assigns you a new IP (which they frequently do), your money is suddenly unspendable. Also, if your ISP assigns you an IP that has been previously banned by the actions of some attacker, you temporarily cannot access the Bitcloud network.

Many other attacks are present, such as generating enough identities to be 80% of the network, and then having full control over what blocks are added to the chain and the rewards being paid out.

tl;dr: Bitcloud is broken.

Tahoe-LAFS has been suggested in the past as a cloud storage type system where storage nodes are paid based on bandwidth and how often it is accessed. All files stored on storage nodes are encrypted before they are even sent to storage nodes, so encryption is not a worry.

The scalability is the only thing I'd be concerned about here. I don't know if it has been overcome, was another project, or something else, but I seem to remember hearing that the system only supports 128 storage nodes. That is the only issue I can think of.

Test: transmit ASCII “Hello Bitcloud” connect message using basic UBJSON packing (log or output the result on the receiving node)

Have a minimum of 3 nodes {A, B, C}.
Have A and B connect and sync nodepool information (i.e., add each other to the nodes table).
Have node C connect to node B and sync nodepool information.
Node A should then (eventually or immediately during the synchronization cycle) be updated with the record for node C.
This may come from node B or by node C connecting directly to node A after discovery through the node B-C synchronization.

Ok, so I think that we should start by taking the Tahoe-LAFS source code from here:

https://github.com/tahoe-lafs/tahoe-lafs

And start applying the ideas of CA management and publishers to construct a functional demo that we can present, as defined here:

https://github.com/wetube/bitcloud/blob/master/bitcloud.org

We have 2 approachs now to decide:
1.- Do the demo in Python based on current Tahoe-LAFS source code.
2.- Rewrite it completely in C (or other language).

I'd like to know what do you think. Please don't stay silent!
Everyone watching the repo please answer.

• Pack some binary attachment with JSON and write full message to file system.
  ** Inspect the output
  ** Ensure the JSON is correct
  ** Hash the message and validate message is error free
• Open, unpack the entire message, and output the binary attachment as a file.
  ** Check output file to verify that it still works.

1. CA's are a mistake that we in the security community made. It was a big mistake. A huge mistake that everyone knows about, unfortunately bitcloud seems to think CA's are a good thing. Here are the issues with a CA. First off, the CA can legally be told to give out there code. Lavabit is a good example and bitcloud is no exemption, even though you want to approach it differently.
2. Expecting people to know what a CA is and which ones to trust is illogical. People have no idea what a CA is. They think if there is a lock on their screen and it says "Approved by verisign" that they're secure.
3. Stripping a CA is easy and I am sure it will be trivial to do this in bitcloud as well. I am so confident I am naming the attack the "Z-affect", since I know it will happen. History repeats itself, because we don't pay attention to history.
4. You don't need a new protocol. You will get very little adoption with a new protocol. Try the wickr approach. Wickr makes secure email as an app. Seriously, I am not saying you guys aren't smart, you are smart, but you have everything upsides down and backwards. You may think I am a nobody, and that's fine, but I encourage you to look at what my company focuses on and that's web security. The best way to sum it up is this tweet https://twitter.com/planetzuda/status/433839162697854976. You need to be careful when inventing something like this, because I can already tell you it's crackable and not that hard to crack. Let's compare this to a car. I don't have to know how your car ticks to be able to see it will be leaking oil and smoke coming out of the engine. This is the last thing I plan to contribute. The only reason I am contributing this is because a loyal follower of yours really wanted me too. Your followers need to understand that your project is broken and not fixable, unless you make huge changes.

◦ Test1: compare “nodes” table of one node with another (output/log results)
◦ Test2: update one node with other node's “nodes” table content (only new records) – DB should have results and be available for investigation
◦ Test3: have three nodes in serial connect to each other at different times, with end nodes discovering each other (e.g., N1 → N2 ← N3, N1 and N3 connect to N2 and discover each other through N2)

After a port is open:

• Trigger receive_connect on any socket connection event for the listening port
• Send a basic "Bitcloud.js 0.1 PoC" on connection as a fill-in for eventual handshake protocol
• Receive "Bitcloud.js 0.1 PoC" and confirm that the message is valid and compatible
• { just to test, close connection after handshake }
• Test by telnet at first.

one node requests dump of “nodes” table from transmitting node. Transmitting node sends a dump of “nodes” table as select all query output to test DB query transmission

this has a dependency on nodes running with an actual dataset of 2 or more records

The sync process is the one that syncs the nodepool and the blockchain.

1. It must propagate through the entire network. Every node must have a copy.
2. Each entrance in the node pool must be signed.
3. It should be easy to determine the missing parts when out of sync, perhaps using signed timestamps.
4. A garbage collection must happen for irrelevant past data.
5. There must be a way to avoid DDOS and spam to the nodepool (the law of service).
6. A proper integration with our Tahoe-lafs based system.
7. Fast real time propagation, ensured by the law of service.

transmit numbers (all applicable number types - e.g., floats, doubles, integers of various sizes, binary, etc.) using little endian (log or output results at the transmitting and receiving node to compare and ensure they are they same)

Currently, when bitcloud.js is run, the end result is a repl command-line interface bitcloud>

There is no command to exit. Exiting can be the first command that the repl interface supports.

• Produce and test code to add one or more exit command functionality to the repl interface.
• Document the method of adding the command within the code so that multiple exit command options can be made available, and other commands also easily written.

• Open a designated file (e.g., "Test1.ubjson") and read all packed contents.
• Unpack contents and output the string that was contained in the packed UBJSON file to validate unpacking.

Code currently only opens a port on localhost.

• Code discovery of network address(es)
• Open port on network address
• Test by telneting to the IP on the open port

add a new node to the nodepool table
remove a node from the nodepool table

Tests:

bitcloud -connect IP:PORT

the above should also add that node as a record to the nodes table

bitcloud -remove IP

the above removes that record (and disconnects that node, if connected)

bitcloud is retarded, a serious issue that can only be rectified by disbanding the project and contributing to useful projects such as freenet or gnunet.

I thought I already did this, but I guess not.

Ensure the core Bitcloud DB functions operate:

bitcloud -addrecord TABLE:COL1,COL2,COL3,....COLn

the above is an example of a basic command line interface to test whether the DB functions work.

bitcloud -updaterecord TABLE:PRIMARY_KEY_VALUE,COL2,COL3...COLn

the above assumes the first column is the primary key

bitcloud -deleterecord TABLE:PRIMARY_KEY

output the total table contents to the terminal after the above command runs to ensure the record was properly removed

complete and test the functions to pack UBJSON messages and parse them back into data.

command line interface test may look like:

bitcloud -ubjson FileName_to_pack new_file

this would open and read FileName as pure data, pack it into a UBJSON message, and output two files.

First file to output (e.g., "FileName.ubjson") would be a raw UBJSON output to prove that the function packs properly (hex editor required for analysis and validation). Second file would take the output from the UBJSON message packing function and output a New_File as the result to validate that unpacking works. (diff to compare)

Tests:

bitcloud -test1 example1

the above should then output something like: "test1 is example1"

bitcloud -test2 example2 example2.2 anotherexampele

the above may output something like "test2 - 1) example2, 2) example2.2, 3) anotherexample" to ensure that the spaces are parsed properly.

bitcloud -test3 NUMBER1:NUMBER2,NUMBER3,NUMBER4

the above may output "test3 - NUMBER1 with NUMBER2 NUMBER3 NUMBER4" to test parsing of colon and comma separated switch values.

transmit image file to test “blob” transmissions from one node to the other (recipient node should output the image file locally to confirm transmission success)

While reading and reviewing the paper on the Laws and the Proof of Bandwidth, I realized that there was a hole in the plan where there was no explanation for the system that would be used to monitor and facilitate people's reputation.

I have used StackExchange for a while and have always greatly admired their brilliant and seemingly perfectly implemented Reputation System. I have suggested that we use a similar system for monitoring people's actions and determining whether rewards or punishments should be carried out.

I am interested to hear what other people think about this idea and would be willing to further expand upon and develop it if people are interested and think that it would work.

In conclusion, the flaw is the lack of a defined system by which the network can tell how a person is doing in terms of following the Laws/Rules. I have a suggestion for a solution in a Reputation System much like the on used at StackExchange.

Tests to be determined, but likely will have dependencies upon reaching communication milestones. The best way to test the event loop may be to test and operate with network events.

Hi, as you know, @gnostication has recently published two videos in youtube:

https://www.youtube.com/watch?v=-j-UKU8JZ4o

https://www.youtube.com/watch?v=LYDHsovGHOo

I'd like to ask anyone who is interested in continuing helping, to include them in the main page of the project, and we'll upload the modified page when ready. If no one is interested, I can try to find the time these days.

We also need contributors for the blog, but please take the time to understand the architecture if you want to write there. Ask questions in this list or by IRC.

Thanks!

Use libuv
Create a basic event loop, initially for use by network communication operations.
Test by having a "Hello world" response sent as soon as an connect event occurs to the node's open socket.
Then, maybe have a response sent every minute thereafter that the socket connection remains.

Is this project still alive?

The first thing we need to address is the creation of CAs.
In order to avoid sybil attacks, the creation must by costly.

1. What CA algorithm or library to use. http://en.wikipedia.org/wiki/Certificate_authority#Open_source_implementations

2. How to create CA out of a mining process.

3. How to integrate that in our blockchain

Use libuv.
Test by telnetting to the node port that the socket was opened on.