Coming back to the trusted node system for the mesh payment network, would it not be feasible to convince shops in crowded areas to be seed nodes if they can get paid for sharing their bandwidth to the mesh network and at the same time be sure they have a very reliable link to the payment network. Use greed and fear at the same time, that's a tried and true tactic which has worked wonders since time in memoriam.

I think the trick for a lot of these distributed models is to find a way to piggy back onto other beneficial things and provide freebee services that way. My favorite analogy is trying to latch a couple of passenger cars onto a freight train and let the freight transport provide free public transport.

Yeah I'd love to see distributed internet and maybe some people here can figure out a model that could align the incentives just right to make it feasible. But you'll be up against some big aggressive players.

I was following the OLPC-project very  closely and liked their solution, unfortunately, because that project did not run a certain operating system and did not need a certain manufacturers expensive cpu, a lot of time and effort went into diversion tactics in the shape of netbooks and forcing said bloated os on a system it was not suited for. The meshnetworking or any other concepts were not integrated into the netbooks and the bloated os helped kill  the project. The diversion was a succes and besides making some ripples in the industry, real disruption had been halted. But who cares, why would anyone want a screen you could use in direct sunlight anyways?

Anyways I'm a big fan of the concept of mesh-networks and I've been trying to think up ways and combinations with cryptocurrencies that would make it feasible. This looked promising but I have not seen an update or sign of life from them for close to a year now. My current line of thought is that there might be a way to get several services to essentially piggy back ride on each other and with their combined utility value be able to foster and sustain a mesh network.

As for blocktimes, I agree with bytemaster that that is not a concern at all. You only need to transmit a valid signed message, the message itself does not to be confirmed several blocks deep. Even with bitcoin that is actually not a requirement. If you can do a quick check if the paying account has the funds and if you can be certain that enough nodes have seen the payment, then why would you need to wait for the transaction to be confirmed several blocks deep?

Oops, sorry about forgetting to update the submodules.

Still can't manage to compile a working binary outside of ubuntu however, I'm now stuck on a linking error with an undefined reference to 'main' with bitshares_client_tests and deterministic_signature_test.

Any steps I could take to figure out what's going wrong there?

Has anyone managed to get the client to compile on a different linux distribution?

On both OpenSuse and Gentoo I get stuck in the same place,  apparently because of a problem in time.hpp/cpp. I've quoted the error message below. Any clues on how to get beyond this point would be appreciated, because I'm personally not a big fan of Ubuntu.

[ 95%] Building CXX object libraries/client/CMakeFiles/bts_client.dir/client.cpp.o
/home/joey/bitshares_toolkit/libraries/client/client.cpp: In member function 'virtual fc::variant_object bts::client::detail::client_impl::get_info() const':
/home/joey/bitshares_toolkit/libraries/client/client.cpp:1954:149: error: no matching function for call to 'get_approximate_relative_time_string(fc::time_point_sec, fc::time_point_sec, const char [5])'
       info["blockchain_head_block_time_rel"]             = fc::get_approximate_relative_time_string(_chain_db->now(), bts::blockchain::now(), " old");
                                                                                                                                                     ^
/home/joey/bitshares_toolkit/libraries/client/client.cpp:1954:149: note: candidates are:
In file included from /home/joey/bitshares_toolkit/libraries/fc/include/fc/log/logger.hpp:3:0,
                 from /home/joey/bitshares_toolkit/libraries/fc/include/fc/exception/exception.hpp:6,
                 from /home/joey/bitshares_toolkit/libraries/blockchain/include/bts/blockchain/types.hpp:6,
                 from /home/joey/bitshares_toolkit/libraries/blockchain/include/bts/blockchain/chain_database.hpp:2,
                 from /home/joey/bitshares_toolkit/libraries/client/include/bts/client/client.hpp:2,
                 from /home/joey/bitshares_toolkit/libraries/client/client.cpp:1:
/home/joey/bitshares_toolkit/libraries/fc/include/fc/time.hpp:120:10: note: fc::string fc::get_approximate_relative_time_string(const fc::time_point_sec&)
   string get_approximate_relative_time_string(const time_point_sec& event_time);
          ^
/home/joey/bitshares_toolkit/libraries/fc/include/fc/time.hpp:120:10: note:   candidate expects 1 argument, 3 provided
/home/joey/bitshares_toolkit/libraries/fc/include/fc/time.hpp:121:10: note: fc::string fc::get_approximate_relative_time_string(const fc::time_point&)
   string get_approximate_relative_time_string(const time_point& event_time);
          ^
/home/joey/bitshares_toolkit/libraries/fc/include/fc/time.hpp:121:10: note:   candidate expects 1 argument, 3 provided
libraries/client/CMakeFiles/bts_client.dir/build.make:57: recipe for target 'libraries/client/CMakeFiles/bts_client.dir/client.cpp.o' failed
make[2]: *** [libraries/client/CMakeFiles/bts_client.dir/client.cpp.o] Error 1
CMakeFiles/Makefile2:685: recipe for target 'libraries/client/CMakeFiles/bts_client.dir/all' failed
make[1]: *** [libraries/client/CMakeFiles/bts_client.dir/all] Error 2
Makefile:116: recipe for target 'all' failed
make: *** [all] Error 2

he means in this test net...

they are all filled, but hopefully we will have delegate voting later in this round

Yeah I meant to help with the testnet. I'll only setup a non-testnet delegate to help bootstrap the system and if I don't get penalized for getting voted out later on, when I make way for people who want to do this as a job. I'm unable to guarantee a 24/7 full uptime for years to come and eventhough I'm not in it purely for the money, that doesn't mean I can just afford to lose the little stake I have.

In the meantime if the net is still up, would someone be so kind to send some testXTS to XTS8dQUhrQt45ovDRkXU18dag5Mpktu83N58sGfxpUKRjJcYp5W2V?

Drat I just missed the key-registering window when I finally was able to access my pc late last night. Are there still open spots for registering as a delegate or are those locked down now?

Also.  If there are any nix masters out there.  What is the purpose of splitting the screen -S and the running gdb?

It seems like I can get similar results from running
screen -S Bitshares ./bitshares_client
without the step of running gdb
from a theoretical viewpoint, I'd like to understand the difference.

**this is purely for my educational purposes, and is not at all important**

gdb is the debugger, so in case of an error, the codemasters know what to work on. Apparently it is a lot more useful than the ubiquitous "It doesn' t work" bug report.

I can confirm a very big boost in performance from the 14.6 Catalyst on ubuntu linux, last I checked I was getting over 5900 c/m for each 280X with -a 0, it still hasn't stabilized yet, while I was averaging around 5200 c/m with the 14.4 catalyst version.