Some interesting reddit comments that are crosspost worthy:
Fluffypony explaining libraryzing in response to my comment:
GUI will probably be released after libraryzing is done (devs are currently working on it, see design goals ->
https://getmonero.org/design-goals/), without libraryzing it makes no sense to "wire up" the GUI.
The design is already done, see following link for some sneak peaks ->
http://imgur.com/a/ERheR It's just fun terminology we adopted after the "daemonize" effort:)
No, it's not merely "modularising" it, it is a separation of concerns into actual libraries that can be implemented into any Monero-related project (including the binaries). This was the initial spec I wrote up a little while ago:
The code should provide 4 libraries, binaries should be built using these statically by default. libs only needs to be a build target / cmake switch.
No app logic / core / verification / p2p / consensus functions should exist outside of these libraries. Binaries implementing this can layer whatever they want on top, but all essential functionality should be provided in these libraries
libMoneroStorage
BlockchainDB for blockchain storage/validation, as well as a class to handle wallet data. TODO: need to figure out blocking during reorgs, and prioritising data requests from the daemon over anything else.
libMoneroAccount
All other wallet (account) functions. Create accounts, recover, mnemonic seeds, etc. etc. Uses libMoneroStorage for wallet cache / key data.
libMonero
Connection to the network (effectively the daemon), uses libMoneroStorage for blockchain storage. Unless explicitly specified via a flag of some sort, there should only be one instance of libMonero running. In other words, if I'm running the daemon, and then a fire up another daemon, all it should do is hook into the already running libMonero one via IPC. The instantiated libMonero should only shut down when there are no longer active handles to it (or when a controlled shut down is requested). Binaries tapping into that functionality should also know and expect that they may receive a controlled shutdown signal, and should be able to either terminate or hang around waiting for the library instance to be available again.
libMoneroRPC
Provides JSON HTTP(S) RPC interface to libMonero and libMoneroAccount. This is effectively a standalone server that feeds commands back to libMonero or libMoneroAccount via 0MQ IPC. Can provide a single port with /daemon and /account endpoints, or multiple ports.
https://www.reddit.com/r/Monero/comments/3ltrxt/its_happening_stepbystep_every_month_since_i/cv9hix0?context=3smooth's comment about disclosing individual payments on a case by case basis:
The white paper says:
In case Alice wants to prove she sent a transaction to Bob’s address she can either disclose r or use any kind of zero-knowledge protocol to prove she knows r (for example by signing the transaction with r).
If you disclose r (a random number chosen per-transaction) then anyone can perform P = Hs(rA)G+ B to determine the one time address (which in turn is stored on the blockchain) being used to send to Bob. (A,B) is Bob's public (stealth address) key. G is a constant, and Hs() is a hash function. This has no connection to other transactions you may have performed. The ability to retrieve r was not implemented in the original cryptonote code, but we added it recently in github.
https://www.reddit.com/r/Monero/comments/3lvjw1/eli5_how_can_a_monero_transaction_be_publicly/cv9x3dv