We'll just be continuing our work at our own pace
Topic: [ANN] the Internet of Coins - page 7. (Read 24752 times)
Like I stated at another website; each of the current integrating projects has their own advantages (and as it seems, their own enthusiastic following) which is fine. Previous examples of inventions in crypto have shown that it is not uncommon for multiple initiatives to coexist. It is after all possible to be part of multiple networks -increasing liquidity even further.
We'll just be continuing our work at our own pace
We'll just be continuing our work at our own pace
Some interesting developments indeed.
Next to our project there is the SuperNET (James Lee) and the BlockNET (Dan Metcalf). I certainly hope both of them are legit. They are big IPO/ITO runners, and I don't want to see people scammed like what is happening with many alt-coins.
In any case, we are focusing on making integration happen. Where possible, we want to collaborate with these other projects. Working open source means that the code we will commit to Github is free to use for others.
We hope this will help all serious contenders to develop solutions that will work for everyone. I think, instead of competition, collaboration is what we should be aiming for.
Next to our project there is the SuperNET (James Lee) and the BlockNET (Dan Metcalf). I certainly hope both of them are legit. They are big IPO/ITO runners, and I don't want to see people scammed like what is happening with many alt-coins.
In any case, we are focusing on making integration happen. Where possible, we want to collaborate with these other projects. Working open source means that the code we will commit to Github is free to use for others.
We hope this will help all serious contenders to develop solutions that will work for everyone. I think, instead of competition, collaboration is what we should be aiming for.
I think the XC currency Blocknet just try to monetize on the trends.
Domain was registered: 2014-10-15 15:42:33 (WHOIS) and they throw already an ITO end of this month?! Bigtime scam alerts to me!
Do you also think so, Agent?
Domain was registered: 2014-10-15 15:42:33 (WHOIS) and they throw already an ITO end of this month?! Bigtime scam alerts to me!
Do you also think so, Agent?
Agent 725
One of my fellow board members at EMC2 told me about http://theblocknet.com/, after a cursory view of the material it reminded me of your project, perhaps it might be of interest to you.
One of my fellow board members at EMC2 told me about http://theblocknet.com/, after a cursory view of the material it reminded me of your project, perhaps it might be of interest to you.
You got more of those gramen? 
Yesterday I've been working on the mathematics of our whitepaper with wires. He pointed out we need some more time to work out the notation and we'll probably be doing this in LateX. (Right now the document is a simple .odt, but that doesn't really suffice.)
Yesterday I've been working on the mathematics of our whitepaper with wires. He pointed out we need some more time to work out the notation and we'll probably be doing this in LateX. (Right now the document is a simple .odt, but that doesn't really suffice.)
inkscape works a bit weird, but good!
Way to go Agent 725! Your reputation and experience in the world of coin and crypto is hard to match. Kudo's for your pioneering work. Seems to be attracting followers like IoB?!?
But it is the way to go and the future of the cryptosphere. I fully support you in your endeavour.
This internet of coins thing is going to make crypto happening! Can't wait to get on the bandwagon and get cracking! Awesome stuff there, we are kinda hoping on the release of a whitepaper preview. Would you care to work together with us on that? If so, contact me via the usual channels.
AmmO
CIYAM, Will go through this to see if we dare to take a shot at it.
George, Have you also tried using the GIMP for pictures or Inkscape for vectors/logo's?
George, Have you also tried using the GIMP for pictures or Inkscape for vectors/logo's?
I think that your article reads reasonably well - also note that I will be publishing the AT *API* specification tomorrow (and raising the bounty - if you guys are able to add to that bounty or - better still - try and collect it then that would be great).
The AT API spec combined with this http://ciyam.org/at/at_script.html should make the job of integrating AT with a Bitcoin clone fairly straight forward (if I wasn't so busy working on other things I'd give it a go myself).
The actual atomic cross-chain transfer AT will be provided by CIYAM either later this month or early next month but in short it will work in the same manner as the published nLockTime approach for Bitcoin (but rather than needing nLockTime to be implemented in both "mainnets" you will just need AT to be supported in both).
The new AT will be somewhat like the Dormant Funds Transfer (this is the refund part) but each AT will also contain a SHA256 hash value (whoever publishes their AT first is the one who knows the "secret"). Provided a message "that is the secret" is received by the AT (checked by hashing and comparing to the hard-coded expected hash) and that this occurs before the refund has happened then the AT will store the secret (making it now publicly visible in the ATs state) and of course transfer the funds.
The other AT on the other block chain then just needs to be sent the same secret in order for it to do the other part (again before it refunds). The AT will most likely be designed for re-use as well (so each trader would have their own).
As in the nLockTime approach the refund times need to have a reasonably large difference (say 1 hour for person going 1st and 3 hours for person going second).
Note that to send "messages" for Bitcoin clones OP_RETURN would be used.
The AT API spec combined with this http://ciyam.org/at/at_script.html should make the job of integrating AT with a Bitcoin clone fairly straight forward (if I wasn't so busy working on other things I'd give it a go myself).
The actual atomic cross-chain transfer AT will be provided by CIYAM either later this month or early next month but in short it will work in the same manner as the published nLockTime approach for Bitcoin (but rather than needing nLockTime to be implemented in both "mainnets" you will just need AT to be supported in both).
The new AT will be somewhat like the Dormant Funds Transfer (this is the refund part) but each AT will also contain a SHA256 hash value (whoever publishes their AT first is the one who knows the "secret"). Provided a message "that is the secret" is received by the AT (checked by hashing and comparing to the hard-coded expected hash) and that this occurs before the refund has happened then the AT will store the secret (making it now publicly visible in the ATs state) and of course transfer the funds.
The other AT on the other block chain then just needs to be sent the same secret in order for it to do the other part (again before it refunds). The AT will most likely be designed for re-use as well (so each trader would have their own).
As in the nLockTime approach the refund times need to have a reasonably large difference (say 1 hour for person going 1st and 3 hours for person going second).
Note that to send "messages" for Bitcoin clones OP_RETURN would be used.
CIYAM, I took a look at your link. Good stuff there! We'll study your method and share it with a developer who may be helping us out on this. We also are looking at high-level approaches, and I think we should combine both. I.e., first try to transact atomically, and where that cannot be done, fallback to multisig., RPC controlled hacks. At the BTC2B in Brussels Vitalik Buterin told me to look into threshold cryptography, which I am doing, and looking to see what the pro's and con's are of utilizing it.
Yesterday I wrote this article, which Armis also published. If you have technical knowledge, please don't hesitate to correct me where I'm wrong. Also, if you are not technical, any other feedback is also much appreciated.
/// TITLE: Building Interconnection, We Need Eclectic Methodology
There are mainly two contrasting approaches when it comes to inter-blockchain connectivity; high-level and low-level. Both are equally important, but approach either the fundamentals or numerics of blockchain conglomeration. To create something like an Internet of Coins, we need to use both approaches concurrently and eclectically.
It could be compared to the way Michaelangelo worked to create one of his artful statues. Some of the chipping of the stone had to be done with large chisels and firm blows of the hammer. A high level approach to result in the basic and recognizable shapes of the rock being hewn. Yet simultaneously, he had to work with the utmost caution, scraping out the tiniest details to accentuate the shape of muscles and hair. The results of this combination are an artwork.
High-level connectivity focuses mainly on the controlling aspect of value trading. To make sure that one transaction finishes before sharing the access keys to another initiation for transaction can essentially be done from a high-level protocol. For example, it could be an RPC calling script that controls two daemons for different cryptocurrencies to make an allocated trade between them possible.
Low-level connectivity delves down to byte-level transactions to make atomic cross-chain trades possible. In this case two transactions are meticulously crafted using advanced cryptographic programming, by which an atomic script ensures instantaneous escrow between blockchain constructs. Assembly-like language is used to describe this process.
Both approaches contain very useful and some deterring aspects, and thus must both be held up to scrutiny. Combining them in tandem is even more of a challenge, as it requires an eclectic overview and understanding of different technologies, their strengths and weaknesses, and how they may by combined most securely and efficiently.
In another comparison it is creating a thing of architectural beauty, like for example the Obuda Synagogue, St. Nicholas Cathedral Kronstadt, or the Taj Mahal. Any one of these three architectural beauties has taken great skill in prestigious, high-level architecture as well as patiently crafted, low-level ornamental detail.
Many high-level solutions are potentially compatible even towards systems that very much differ in their underlying implementation. However, the high-level approach is difficult to properly secure, and needs a parallel cryptographic network to function safely. It also leaves open security holes in every gap between the high-level construct itself and its controlled daemon subject. Perhaps it is also easier to infuse with malware, as high-level programming is often more easily understood, and agile to work with.
The low-level approach is most robust when applied properly, besides being light weight, and can outlast high-level systemic changes. Even so, it requires very skilled programmers and presents tough cryptographic puzzles to solve. In some cases it can lead to a quest for a holy grail that is most difficult, if not near-impossible to reach in a timely manner. And if a vulnerability is ever found at a later stage, it may be very difficult to find those qualified to repair such a weakness.
To make an internet of coins possible, we need both approaches, and we must patiently find the way for us as craftsmen to all build it together.
Yesterday I wrote this article, which Armis also published. If you have technical knowledge, please don't hesitate to correct me where I'm wrong. Also, if you are not technical, any other feedback is also much appreciated.
/// TITLE: Building Interconnection, We Need Eclectic Methodology
There are mainly two contrasting approaches when it comes to inter-blockchain connectivity; high-level and low-level. Both are equally important, but approach either the fundamentals or numerics of blockchain conglomeration. To create something like an Internet of Coins, we need to use both approaches concurrently and eclectically.
It could be compared to the way Michaelangelo worked to create one of his artful statues. Some of the chipping of the stone had to be done with large chisels and firm blows of the hammer. A high level approach to result in the basic and recognizable shapes of the rock being hewn. Yet simultaneously, he had to work with the utmost caution, scraping out the tiniest details to accentuate the shape of muscles and hair. The results of this combination are an artwork.
High-level connectivity focuses mainly on the controlling aspect of value trading. To make sure that one transaction finishes before sharing the access keys to another initiation for transaction can essentially be done from a high-level protocol. For example, it could be an RPC calling script that controls two daemons for different cryptocurrencies to make an allocated trade between them possible.
Low-level connectivity delves down to byte-level transactions to make atomic cross-chain trades possible. In this case two transactions are meticulously crafted using advanced cryptographic programming, by which an atomic script ensures instantaneous escrow between blockchain constructs. Assembly-like language is used to describe this process.
Both approaches contain very useful and some deterring aspects, and thus must both be held up to scrutiny. Combining them in tandem is even more of a challenge, as it requires an eclectic overview and understanding of different technologies, their strengths and weaknesses, and how they may by combined most securely and efficiently.
In another comparison it is creating a thing of architectural beauty, like for example the Obuda Synagogue, St. Nicholas Cathedral Kronstadt, or the Taj Mahal. Any one of these three architectural beauties has taken great skill in prestigious, high-level architecture as well as patiently crafted, low-level ornamental detail.
Many high-level solutions are potentially compatible even towards systems that very much differ in their underlying implementation. However, the high-level approach is difficult to properly secure, and needs a parallel cryptographic network to function safely. It also leaves open security holes in every gap between the high-level construct itself and its controlled daemon subject. Perhaps it is also easier to infuse with malware, as high-level programming is often more easily understood, and agile to work with.
The low-level approach is most robust when applied properly, besides being light weight, and can outlast high-level systemic changes. Even so, it requires very skilled programmers and presents tough cryptographic puzzles to solve. In some cases it can lead to a quest for a holy grail that is most difficult, if not near-impossible to reach in a timely manner. And if a vulnerability is ever found at a later stage, it may be very difficult to find those qualified to repair such a weakness.
To make an internet of coins possible, we need both approaches, and we must patiently find the way for us as craftsmen to all build it together.
As long as they're not hurtful to others...
For anyone looking for more information, I posted a video of a presentation at the beginning of September where Joachim explains the concept in more detail. We like to use tangible examples:
http://internetofcoins.org/blog/2014-09-03-bitcoinference-summer-2014-the-internet-of-coins-in-pictures
For anyone looking for more information, I posted a video of a presentation at the beginning of September where Joachim explains the concept in more detail. We like to use tangible examples:
http://internetofcoins.org/blog/2014-09-03-bitcoinference-summer-2014-the-internet-of-coins-in-pictures
Hey devs!! Shall I make some nice pictures for the project? Working with photoshop is fun!
interesting, keeping watch.
You would be most welcome to use this: http://ciyam.org/at
(a bounty to get an atomic cross-chain transfer between Qora and a Bitcoin/Litecoin clone has been created and it is hoped this will be achieved before the end of 2014)
(a bounty to get an atomic cross-chain transfer between Qora and a Bitcoin/Litecoin clone has been created and it is hoped this will be achieved before the end of 2014)
Sent you a PM.
agent725, I'm surprised I haven't heard from you.
Updated our initial post with some more information.
Thanks George, very kind of you. Looks like a nice list.
An IPO will not be done until the project has some investment as a basis to ensure continuity. The reason we are currently aiming for institutional investors (entrepreneurs & companies) is that we would prefer to limit exposing individual users to the initial risk of a new venture.
An IPO will not be done until the project has some investment as a basis to ensure continuity. The reason we are currently aiming for institutional investors (entrepreneurs & companies) is that we would prefer to limit exposing individual users to the initial risk of a new venture.
You are my favorite project and I added u to the list of favorite projects on the proj.dev board!
Yes, I also want to know if where you are doing IPO, or only investors you pick 'n choose?!
and I added u to the list of favorite projects on the proj.dev board!Yes, I also want to know if where you are doing IPO, or only investors you pick 'n choose?!
do you know what platform the asset IPO will be listed on?
Jump to: