Topic: I/O Coin - Ticker: IOC - Stealth Blockchain Ecosystem - Dions - Chameleon - page 72. (Read 719184 times)

Hey Gavrilo77,

I see your signature is empty, would love to see you wearing an I/OCoin one.  Very easy to do, send me a PM if you need help with it.   

Sell wall at 60k gone...

Good news!!! When we can expect it in the public?

How do you know they are using mingw ? No mention of that anywhere.

PS: Wondering how IOC will help people all over the world, take a look at this outstanding video.  "The future of Money" (best i have ever watched!)

https://www.ted.com/talks/neha_narula_the_future_of_money#t-124775

You shouldnt be using mingw to build release targets because static builds are not only hard to do but its way more efficient to cross compile. If you are using new bitcoin core its literally 5 mins to figure out how to build for windows and then reconfigure for linux...

Now only if it were as easy to mac cross compile

Good Morning Everyone, this is a DIONS technical update:


A few minutes ago we completed our first full compile for Dions in Windows 10 64bit and have our exe file ready for first test, We are going to take a small break and will try to deploy in Windows later on today. This is big for us, windows was giving us some challenges, so we took a different route and technique through linux cross compiling. If this works well, it will all be worth the effort and extra time we spent, this technique can help us churn out windows exes from linux, way much easier and more efficient. This will also speed up compiling specially after any incremental changes during our beta run. This was a very important step as windows is the most difficult barrier. Will update again but for now we are looking great.

Thanks Everyone

Joel

Going to see BIG GAINS on Augur, then what shall i do with all that Bitcoin 

Hey ~ MrwhiteBites ~

I know you are the one of the big IOC supporter. (Sometime too strong supporters )

So let's easy ! : )

We have been waiting over 2 years and we already get incredible reward.

The dev will continously develop the IOC blockchain like as they have done last 2 years.

SO ! Let's easy and enjoy the value growing price graph of IOC ( not hype , not pump & dump )


P.S and I am sure IOC will be on dollar level not pennys
     And thanks for nice signature !

Plus. The augur is online soon. Easy man! right?

From the post above.  So Beta not far away.  Nice whale trap.  Dump the coin, pull buy support and make people panic sell.  Do not fall for it!
IOC will hit 100k in 30-60 days.

? Can you drop any info here?

Very hard not to be jaded with all the games out there.

It is funny how many of the questions are coming at this moment, normally from the people who "did not invested", and the people who knows the things better.

Nobody objected to questions, just presentation.  Anyhow, he got a response from devs and they can talk.  Works out for everyone in the end. 

I have been a long term investor in both Syscoin and IOC and I can vouch for Sidhujag (Don't agree with his copy paste remark before asking relevant questions). He isn't trolling or fudding IOC. If he is here and asking questions it to learn and research and give feedback which he has done. There is nothing wrong in asking questions and critiquing any coins. Nobody is perfect and it is a new field where we are learning and growing.

Azure doesn't own any of the work its open source, anyone can clone it and do whatever they want that jargon you read about is trolling based on a few coins that decided not to go for Azure partnership which was bs because that person(s) didn't understand in context. It was moderated because of the noob posters that would sign up and flood the thread with nonsense one word messages to get their rep up... the OB thing is fair we are blockchain based they are P2P.... I dont see how it makes anyone look stupid if you want to read my writeup on a more in depth comparison between the 2 check this one out: http://syscoin.org/in-depth-look-at-the-syscoins-decentralized-marketplace-and-comparing-it-to-the-competition/.

Thread was moved once we did SYS 2.0 which was a brand new platform and we share dropped onto SYS 1.0 holders.. sys 2.0 was basically my work after taking over sys 1 which was bare bones and basic... It had to be a hard fork because I changed consensus code quite a bit... now sys 2.1 will continue on the same thread because its vision is inline with sys 2.0... the old thread was simply moved and we updated our OP with the vision of sys 2.0 and all the stuff that becomes possible with it.. besides in sys 1.0 we had that whole ICO fiasco hanging over us where Ryan Kennedy stole 75% of our startup funds and we were forced to use the rest to buy up a chunk of SYS at market to shore up confidence so we basically worked for free for over 2 years to get to this point... I remember there was no activity and even the team meetings weren't held anymore but I kept coding and we got together again and kept it going... good thing we did, we actually came up with a pretty good set of features and a system that actually works!

Anyways i dont want to clutter it up here, its cool we can talk tech stuff so we can learn from each other... thats what is really valuable to me, and not some nonsense troll behavior that pushes people like me away from good projects.

Congrats on your work on SYScoin you must of been gutted when Azure came over and took all your work, when a coin goes to Azure, they own your ass.  All that hard work you done and yet you let microsoft AKA Evil Corp take it all from you, one thing is for sure, IOC aint going to sell out to them.

i did look at syscoin a few times, (moderated thread stopped me from investing and the number of times it has moved threads, all shady stuff) then i seen the comparison against open bazaar and i LOL'd nd vowed never to buy it  because of such comparisons, trying to say syscoin is a better project than Openbazaar is laughable and really makes syscoin look stupid. You know the guys there ask them to remove that crap, it will do them good long term.


Maybe you might be of some help for #iocoin i know they are always looking for talented developers.

Cool sounds identical to the Syscoin alias system I implemented (https://github.com/syscoin/syscoin2/blob/dev/src/alias.cpp). Seems like you also started with namecoins initial implementation but you kept with the txData field inside of CTransaction? I advise against this as my later question about custom field and use OPRETURN because it is not stored in the UTXO database and will later solve your issues with bloat (you can look at my code to see how I did that: https://github.com/syscoin/syscoin2/blob/dev/src/primitives/transaction.h#L124)

again it helps if it was open source as I can point you to what to change and how to do it quickly as our alias implemenations are pretty similar... im assuming you added a check in CBitcoinAddress which translates the address to an alias as well to be able to send/recv to aliases natively? this will make any RPC call work with aliases instead of public key hashes.

For private aliases I simply add an option to make it private and just encrypt the data using public key encryption to the alias owners key so only he can read/write and on transfer I decrypt and encrypt to the new owners key... so that allows for stuff like public and private alias profiles for later things like sending addresses around for purchasing goods on the decentralized marketplace I use aliases in... or for coolt hings like perhaps an OAuth connector which will let you sign in to websites using your alias providing your private or public profile data to the website to generate your website profile and log you in automatically... something like this: https://github.com/bitshares/bitshares-0.x/wiki/BitShares-XT-Login becomes possible and feasible.

We've moved more to an alias system that mocks the domain system on the internet allowing people to renew or extend for flexible amount of time like domains, and allow transfer of things attached to that alias such as certificates, offers and messages. So essentially you can make your store and transfer it to another person and all of the services using that alias (owned by) become usable by the new person... this is what i meant by the other question about transfer aliases and things that it owns. All of this is released and working although the pruning we are going to release in 2.1 coming soon... im sure you will find alot of the stuff I did valuable in your R&D research. Im looking forward for things that I may learn from you guys and perhaps extend the way I do aliases... the only way to make things better is to look at others implementations and discuss tradeoffs etc... doing so will achieve optimal results for average users.

Good luck to you.

FYI: Scholarly discussions are seldom started with insults for future reference.

Thank you, good luck to you!

Answers for sidhujag,

1.

Question: How does data sharing work?

Answer: Data is attached to transactions in base64 encoded form (maximum 1MB). These transactions are then sent to wallets/addresses/aliases via the Blockchain.

2.

Question: Are you building blockchain services to use your aliases? (if so how would transfer work in conjunction with things that those aliases "own")

Answer: The aliases can be arbitrary not just ours, transfer work by sending the alias from one user's wallet to another. If you are referring to the purchase/sale of an existing aliases in DIONS V.1. The two parties would make an agreement on the sale and would have to either trust each other or use some form of escrow for payment and transfer of the alias.

3.

Question: What are stealth aliases all about? Zero-knowledge transactions or something else?

Answer: All aliases are initially encrypted for a fixed number of blocks when created as measure to protect against attempts by malicious users to copy the aliases. Therefore the aliases are encrypted by default for (at least 12 blocks) before being 'activated' (decrypted and made public) by the user.

In our original code, a user had to 'activate' as above his aliases before he could attach files or transfer them. We decided for our beta release to extend this by allowing users to keep their aliases encrypted while still operating on them as normal (attach data, transfer, update associated data). This way aliases e.g  brand names or whatever, can be established in encrypted form with the option to "publicize" the name later for example revealing brand ownership, at will when the time is considered appropriate by user, if ever.

So the “Private Aliases” for us means the possibility to encrypt using RSA the data or alias information that a user chooses. Private Aliases in terms stealth or of zero knowledge transactions has not been our aim at least for our initial release though we may include work in this direction later if their is community consensus on this direction, but again it's not our priority right now.

4.

Question: How do GPG file checks happen, is it part of consensus code?

Answer: We use RSA encryption for our messaging system. Signature verification is not an automated feature for our early beta releases but is planned for early on in our beta release cycle. File associated signatures can of course still be uploaded checked and verified manually, little clunky for initial beta, but the automation of this is not planned for our initial beta test release.

5.

Question: Are you using opreturn for your data(good) or a custom TX data field (bad), The data "field" is fixed and verified by consensus.

Answer: What do mean by custom?

What is essential is that the script structure is fixed so that the consensus checks can be applied.

6.

Question: How do you handle bloat with 1mb data fields?
          
Answer: The size is 1MB, not 1mb. For our initial DIONS release we decided to allow for relatively small data sizes. i.e. to keep it light weight; think twitter like messaging, avatars, copyright info. In a project following closely on the heels of DIONS, we plan to address the bloat issue, R&D work has already been carried out on this over the past year.

7.

Question: You obviously increased the max tx and block size because of this?
          
Answer: No.

8.

Question: if not how do you handle scalability if mass user acceptance happens?          

Answer: Our future plans of using side-chains connected via Chameleon to prevent bloat on the main chain.

9.

Question: Do aliases expire?

Answer: Yes aliases expire after a fixed set of blocks. For our initial release this is fixed so that expiry can be expected after approximately 12 months given the prevailing block generation rate.

10.

Question: Can they be extended?
          
Answer: Yes aliases can be extended even after expiry for another period with preference given to the current owner before becoming publicly available.

11.

Question: In section 6 of your DIONS white paper you go into a.b.c and how a can control b or c and b can control c ? Is this correct? How would that work?

Answer: Since that white paper we've decided to take the approach of * not * constraining the alias field to any particular format the fields are arbitrary.

12.

Question: Is that standard public key encryption messaging using the same curve used to sign transactions?
      
Answer: No, we use RSA encryption for sending encrypted messages as a built in feature.



PS. If we dont get to anyones questions in time, please be advised that we are currently extremely busy and pressed for time, as we are about to launch DIONS beta. We will do our best to answer questions as we get a break in.

Thanks Everyone

I/O Digital Dev Team