Topic: [XMR] Monero Speculation - page 1747. (Read 3313576 times)

I think the most convincing example of fungability necessity for me was when some bitcoin exchange did not accept bitcoins from someone, because allegedly those bitcoins was connected to some dark market activity.

It's not like money should be fungible for criminal operations, but its a good example when some bitcoins != usual bitcoins. This is impossible with monero.

They will certainly care when merchants stop accepting their non-fungible bitcoins because some algorithm determines they're tainted. Privacy is hardly the issue.

Money that isn't fungible will eventually cannibalize itself.

But those coins can go to mixer and come out a different ones.

Or, they will be glad they did not buy it. In 5 years, monero devs can be long gone and the coin be long dead.

It's amazing that Moneroj are selling for 0.47 cents. Anyone reading this post 5 years from now will be wishing so hard they were in our spot.

I think the most convincing example of fungability necessity for me was when some bitcoin exchange did not accept bitcoins from someone, because allegedly those bitcoins was connected to some dark market activity.

It's not like money should be fungible for criminal operations, but its a good example when some bitcoins != usual bitcoins. This is impossible with monero.

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.

The white paper says:
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.

I think the most convincing example of fungability necessity for me was when some bitcoin exchange did not accept bitcoins from someone, because allegedly those bitcoins was connected to some dark market activity.

It's not like money should be fungible for criminal operations, but its a good example when some bitcoins != usual bitcoins. This is impossible with monero.

But those coins can go to mixer and come out a different ones.

I think the most convincing example of fungability necessity for me was when some bitcoin exchange did not accept bitcoins from someone, because allegedly those bitcoins was connected to some dark market activity.

It's not like money should be fungible for criminal operations, but its a good example when some bitcoins != usual bitcoins. This is impossible with monero.

I think the most convincing example of fungability necessity for me was when some bitcoin exchange did not accept bitcoins from someone, because allegedly those bitcoins was connected to some dark market activity.

It's not like money should be fungible for criminal operations, but its a good example when some bitcoins != usual bitcoins. This is impossible with monero.

It hasnt stopped bitcoin to be #1 cryptocurrency. And most people even dont know what fungability means. I myself, for example, have never heard about such a term before getting interested in crypto. Good luck expalining this to people who just want to use crypto, rather than go and read bitcointalk forums, or r/monero or any other such website.

It hasnt stopped bitcoin to be #1 cryptocurrency. And most people even dont know what fungability means. I myself, for example, have never heard about such a term before getting interested in crypto. Good luck expalining this to people who just want to use crypto, rather than go and read bitcointalk forums, or r/monero or any other such website.