IOTA

[lordoliver]

http://www.iot-a.eu/public

Something interesting.

wtf. seems like a name change is advisable...

Haha, no. While interesting, this is not an issue at all IMO. They don't even seem active.

its dangerous, if you share the same name within the same field. you can run easily into law issues...
Would be something else if they sell cola...

[1714277744]

1714277744

[1714277744]

1714277744

[1714277744]

1714277744

[1714277744]

1714277744

[iotatoken]

http://www.iot-a.eu/public

Something interesting.

wtf. seems like a name change is advisable...

Haha, no. While interesting, this is not an issue at all IMO. They don't even seem active.

its dangerous, if you share the same name within the same field. you can run easily into right issues...
Would be something else if they sell cola...

Given that IoT is the universal abbreviation for Internet-of-Things, this is kind of inevitable, but does not matter at all. IOTA is not IoT-A. And IOTA is a token and payment protocol for IoT, this IoT-A project is a lot more vague.
More importantly I can't find any info that they are still active, not to mention their insanely outdated website look. The IOTA brand is ours.

[lordoliver]

The IOTA brand is ours.

The world is not that easy...

[Komputor]

Question for CFB -

I've been trying to visualize the way the DAG would evolve in real world usage and how the transaction confirmation times would behave.
So if i understand correctly, the tips with the highest weights are encouraged to be approved first by incoming fresh transactions. In such a case, if there are is a sudden surge of new transactions followed immediately by a period of very low transactions, then many of the transactions in the first wave would end up waiting longer than usual for approval/confirmation, correct?

I then understand that the confirmation times may actually be very unpredictable in the initial stages of the network when there is a sporadic rate of new incoming transactions.
If true, then do you expect these uneven transaction confirmation times to even out as the volume of transactions eventually increases?

I'm no tech expert, but would like to understand this a little.

 **Still reading the whitepaper**

Edit: Another question - So a strategy for devices stuck with unconfirmed transactions would be to send another blank transaction referencing the original unapproved transaction. Since this network will be used primarily by non-humans, such a behavior would need to be coded into the IOT device itself right? For example: If transaction does not confirm withing x time, then resend a blank transaction with reference to first one.
How would this work out in a larger simulation where many devices would use such a strategy? Could this cause a spam of blank transactions in the network where many devices are trying to promote their own transactions for faster confirmation times? Or is this a non-issue?

[Come-from-Beyond]

Question for CFB -

I've been trying to visualize the way the DAG would evolve in real world usage and how the transaction confirmation times would behave.
So if i understand correctly, the tips with the highest weights are encouraged to be approved first by incoming fresh transactions. In such a case, if there are is a sudden surge of new transactions followed immediately by a period of very low transactions, then many of the transactions in the first wave would end up waiting longer than usual for approval/confirmation, correct?

I then understand that the confirmation times may actually be very unpredictable in the initial stages of the network when there is a sporadic rate of new incoming transactions.
If true, then do you expect these uneven transaction confirmation times to even out as the volume of transactions eventually increases?

I'm no tech expert, but would like to understand this a little.

 **Still reading the whitepaper**

It's a question to mthcl, I think. Simulation shows that Tangle pulses: its width, tx confirmation time and other parameters have clear cosine pattern.

[Komputor]

Question for CFB -

I've been trying to visualize the way the DAG would evolve in real world usage and how the transaction confirmation times would behave.
So if i understand correctly, the tips with the highest weights are encouraged to be approved first by incoming fresh transactions. In such a case, if there are is a sudden surge of new transactions followed immediately by a period of very low transactions, then many of the transactions in the first wave would end up waiting longer than usual for approval/confirmation, correct?

I then understand that the confirmation times may actually be very unpredictable in the initial stages of the network when there is a sporadic rate of new incoming transactions.
If true, then do you expect these uneven transaction confirmation times to even out as the volume of transactions eventually increases?

I'm no tech expert, but would like to understand this a little.

 **Still reading the whitepaper**

It's a question to mthcl, I think. Simulation shows that Tangle pulses: its width, tx confirmation time and other parameters have clear cosine pattern.

Interesting, maybe mthcl can comment more on this. Thanks.

Also if you could clarify my second set of questions: So a strategy for devices stuck with unconfirmed transactions would be to send another blank transaction referencing the original unapproved transaction. Since this network will be used primarily by non-humans, such a behavior would need to be coded into the IOT device itself right? For example: If transaction does not confirm withing x time, then resend a blank transaction with reference to first one.
How would this work out in a larger simulation where many devices would use such a strategy? Could this cause a spam of blank transactions in the network where many devices are trying to promote their own transactions for faster confirmation times? Or is this a non-issue?

[Come-from-Beyond]

So a strategy for devices stuck with unconfirmed transactions would be to send another blank transaction referencing the original unapproved transaction. Since this network will be used primarily by non-humans, such a behavior would need to be coded into the IOT device itself right? For example: If transaction does not confirm withing x time, then resend a blank transaction with reference to first one.
How would this work out in a larger simulation where many devices would use such a strategy? Could this cause a spam of blank transactions in the network where many devices are trying to promote their own transactions for faster confirmation times? Or is this a non-issue?

If a device paid to a merchant then the marchant himself can confirm all pending transactions sent to him by organizing these transactions into few subtrees and confirming the roots.

"Dumb" reconfirmation increases amplitude of cosine pulses making some devices to generate 2-3 extra blank transactions which increases security of the system.

[Komputor]

So a strategy for devices stuck with unconfirmed transactions would be to send another blank transaction referencing the original unapproved transaction. Since this network will be used primarily by non-humans, such a behavior would need to be coded into the IOT device itself right? For example: If transaction does not confirm withing x time, then resend a blank transaction with reference to first one.
How would this work out in a larger simulation where many devices would use such a strategy? Could this cause a spam of blank transactions in the network where many devices are trying to promote their own transactions for faster confirmation times? Or is this a non-issue?

If a device paid to a merchant then the marchant himself can confirm all pending transactions sent to him by organizing these transactions into few subtrees and confirming the roots.

"Dumb" reconfirmation increases amplitude of cosine pulses making some devices to generate 2-3 extra blank transactions which increases security of the system.

Ah yes, so in the merchant example, he can improve his transaction confirmation rate by running his own "off-tangle" train of transactions, which eventually will get merged onto the main net tangle if he is being an honest merchant lol.

As for dumb reconfirmations, you mean to say that this is really a non-issue and would in-fact just lead to greater security and higher cumulative transaction weights. Makes sense.. the spam is not exactly coming at free cost from a node since there is POW invested in each transaction (electricity costs i guess). However, i guess I'll probably understand this better in time.

Very fascinating tech i must say, looking forward to the launch. Good luck to you and team.

[rlh]

I read the white paper on the first day this IOTA post was made.  Has it been significantly updated since 10/21?

In other words, should I re-read the white paper?  I want to stay abreast of this tech. B-)

[Come-from-Beyond]

I read the white paper on the first day this IOTA post was made.  Has it been significantly updated since 10/21?

In other words, should I re-read the white paper?  I want to stay abreast of this tech. B-)

No.

[azwccc]

I saw you are approaching some other projects, looking for collaboration. Would you mind to provide a list and also the progress?

Also, do you have any detailed plan in hardware side? It will require more capital investment, right? Any partnership yet?

Thank you

[iotatoken]

Also, do you have any detailed plan in hardware side? It will require more capital investment, right? Any partnership yet?

Thank you

Yes, we're 13 months into the hardware development. As for requiring more capital investment, do you mean to get prototype or production run? If latter, yes certainly. We'll eventually have to take the 'traditional VC route', but so far we're doing quite good. Re: partnerships on the hardware side, can't disclose anything due to NDA and the fact that it's still preliminary stages.

[tolstoy]

Call for papers IoT DevCon 2016
Deadline for submission of titles and abstracts - January 29, 2016
Notification of acceptance - February 19, 2016

http://www.iot-devcon.com/callforpaper.php

IoT Developers Conference 2016
May 25-26, 2016
Santa Clara, CA

http://www.iot-devcon.com/

[Come-from-Beyond]

Regarding the client software:
We are planning to release reference software with as little non-essential code as possible to make it easier to do the security audit. After that I'll start working on a project powered by Iota.

[P-Funk]

In regards to the software, what stage of development is it in? Is it ready for a basic no-frills release soon? I took this quote from the sale thread to mean that:

Step 2: After the sale ends you can collect your iotas from collect.iotatoken.com (goes live on 22nd of December)

but please correct me if I'm wrong.

[Come-from-Beyond]

In regards to the software, what stage of development is it in? Is it ready for a basic no-frills release soon? I took this quote from the sale thread to mean that:

Step 2: After the sale ends you can collect your iotas from collect.iotatoken.com (goes live on 22nd of December)

but please correct me if I'm wrong.

I'm optimizing already written code and run simulations testing changes in the consensus algorithm that were introduced after a flaw was found in the old one. This is related only to the core part, client part (HTML5) is not ready yet, I'm still thinking what layout to choose.

[achimsmile]

I'll start working on a project powered by Iota.

Any hints on what that project will be about?

[Come-from-Beyond]

Any hints on what that project will be about?

Chat/forum/email hybrid.

[WorldCoiner]

In regards to the software, what stage of development is it in? Is it ready for a basic no-frills release soon? I took this quote from the sale thread to mean that:

Step 2: After the sale ends you can collect your iotas from collect.iotatoken.com (goes live on 22nd of December)

but please correct me if I'm wrong.

I'm optimizing already written code and run simulations testing changes in the consensus algorithm that were introduced after a flaw was found in the old one. This is related only to the core part, client part (HTML5) is not ready yet, I'm still thinking what layout to choose.

So Tuesday the 22nd as delivery date is in jeopardy? Thanks for clarification.

[Come-from-Beyond]

So Tuesday the 22nd as delivery date is in jeopardy? Thanks for clarification.

For now the plan is to have beta version of the client ready by that date.