Topic: NEM (XEM) Official Thread - 100% New Code - Easy To Use APIs - page 1405. (Read 2985369 times)

We need to represent somehow the combine in the client when harvesting is started.
Here the approximate picture as it has to be represented in the client of NEM.

NEM Rocket

no offense, but god in heaven, please no!

no offense, but god in heaven, please no!

By the time NEM exists banking will be done with lasers implanted in your eyeballs on Mars.

2 mins to create and send a nem multisig tx(one block to create and one to confirm) vrs 10mins for bitcoin(0 blocks to create 1 block to confirm. Based on absolute min amount of blocks and thus time, nem is 5 Times faster(assuming all signers sign in the same block as the tx was initiated)

That is doable even now, just set nem folder to i.e. c:\dropbox.

But I think this won't work, as I guess dropbox (or anything else for that matter) will most likely try to sync whole db file, and that would be painful...

patmast3r. Exactly. Synchronization through cloudy services will be much faster and we won't need long hours to be synchronized. And the hard drive will be free from base of blocks. But it everything has to be at will. Who wants that let at himself stores the blockchain base. And who wants that let stores base of blockchain blocks on cloudy Dropbox, Google disk, Yunpan 360 servers, @mail.ru, Yandex disk, etc.

Cloudy storages of blockchain. That there the base of blocks was stored and there downloads. In the client it is necessary to give the chance of a choice where the blockchain base will be stored. For example Dropbox, Google disk, @mail.ru, Yandex disk, Yunpan360, etc.

I don't understand what you are trying to say.

For anyone who questions why "blockchain based multisig" is so much better than "client side"...


https://www.youtube.com/watch?v=Jd-ZIbiFuOg

compare the video posted above to this one:

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

That is the most user friendly example of a bitcoin multisig wallet i could find. Notice the massive difference. That is the difference between client based(which as far as i can tell from the copay video is centralized) and blockchain based(which is decentralized).

Notice also, that a "secret" must be given to the co-signers so they can add themselves to the multisig address rather than making them co-signers via a blockchain transaction simply by selecting addresses in your contacts and sending a particular type of transaction to them to make them a co-signer. This means the same wallet must be used(Copay) by all co-signers. If one of those guys preferred say, electrum, he could not use his preferred client AND be a co-signer on a copay multisig account. This is bad because not only now will there be centralization of mining, but now, centralization and monopolization of clients which would stifle competition and ultimately innovation among clients once one client has the monopoly(visa?). The fact that a "secret" must be sent over the internet just seems very insecure to me also.

Blockchain based multisig is more secure, more decentralised, discourages monopolies, its faster, more user friendly and compatible across all variations of third party clients and making someone a co-signatory, and requesting a signature from them, can be seen on the blockchain which cant be done when utilizing client side multisig because co-signers are made co-signers, and are requested to sign transactions, off chain.

This is why i define Nems multisig as "blockchain" based, and (so far that i know of) all other released versions of multisig "client side". Saying there is not much difference is doing the devs an injustice imo.