Just to add some notes about server side list and hacking control of the public server list.

We will have another private machine with the entire list updated, this machine will get the public server copy every one minute, and compare its own copy with the public server copy. If they are different, an alert will be trigged to us, allow us to rapid take the server down (avoiding propagation of the fake list), and easy get up a new instance of the server (virtual machines allow this to be done very quickly, and cheaper).

This private machine can actually be more than one, to avoid the possibility of the hacker find witch machine is this and take control of it before change the list. But because this machine it's private, can be full firewall protected (no inbound access allowed), because no services is provided to the world, so hacking its almost impossible. Also the delay between updates can be random, to avoid easy log reading and easy discovery of the IP address of those machines. Those machines must act and pass as a simple wallets updates. If the hacker block those updates, also block the delivery of fake lists to real wallets.

In that way the number of clients (wallets) that can be "infected" with a corrupted list by an hacker will be very small. That's also what justify the client list update to be more regular, and quick, (2 or 3 days) to allow rapid fix of the list in case of fake list update.

The wallet when compiled will include the most updated list, but to eliminate the need for client update (software installation) we will keep the list file updated via the public server, for rapid increment of the list on the client side. This is very important on the begging because we expect new social solidarity institution registrations every day. They must first be validated, to avoid fake registrations, but we must try to quick deliver the new validated registrations to the wallets so people can have more and more choices as soon as possible!

If wallet can not update, because, server is down, or server is too busy or some other technical problem at server side, there is no problem the wallet will try update later on, next day or so.

Another security feature, the wallet update list process, will only remove or add new social solidarity institution, will not update wallets address for institutions already presents on the list. So even if an hacker can add a fake institution to the list, that will have only impact on users that choose donate to that new institution, avoiding change the address, or destinations of the money donated to previous selected institutions on each wallet.

For all this, I am pretty sure that hacking impact, and donations deviation will always be a very small possibility. However I can not declare that can not happen, it can. But I can also do every thing to minimize hacking activities impact on the users community. And the only thing at risk will be on the donated part of the payment, users own money still have the same protection of a crypto-currency.