lordoliver
Legendary
Offline
Activity: 1666
Merit: 1020
expect(brain).toHaveBeenUsed()
|
|
December 03, 2015, 12:06:05 PM |
|
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...
|
|
|
|
iotatoken
|
|
December 03, 2015, 12:07:31 PM |
|
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
Legendary
Offline
Activity: 1666
Merit: 1020
expect(brain).toHaveBeenUsed()
|
|
December 03, 2015, 12:12:39 PM |
|
The IOTA brand is ours.
The world is not that easy...
|
|
|
|
Komputor
Newbie
Offline
Activity: 26
Merit: 0
|
|
December 03, 2015, 12:55:41 PM Last edit: December 03, 2015, 01:06:45 PM by 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 (OP)
Legendary
Offline
Activity: 2142
Merit: 1010
Newbie
|
|
December 03, 2015, 01:06:44 PM |
|
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
Newbie
Offline
Activity: 26
Merit: 0
|
|
December 03, 2015, 01:11:09 PM |
|
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 (OP)
Legendary
Offline
Activity: 2142
Merit: 1010
Newbie
|
|
December 03, 2015, 01:19:25 PM |
|
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
Newbie
Offline
Activity: 26
Merit: 0
|
|
December 03, 2015, 01:29:15 PM |
|
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
|
|
December 03, 2015, 05:11:42 PM |
|
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-)
|
A Personal Quote on BTT from 2011: "I'd be willing to make a moderate "investment" if the value of the BTC went below $2.00. Otherwise I'll just have to live with my 5 BTC and be happy. :/" ...sigh. If only I knew.
|
|
|
Come-from-Beyond (OP)
Legendary
Offline
Activity: 2142
Merit: 1010
Newbie
|
|
December 03, 2015, 05:36:42 PM |
|
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
|
|
December 03, 2015, 10:40:16 PM |
|
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
|
Bitrated user: azwccc.
|
|
|
iotatoken
|
|
December 04, 2015, 04:51:16 AM |
|
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.
|
|
|
|
|
Come-from-Beyond (OP)
Legendary
Offline
Activity: 2142
Merit: 1010
Newbie
|
|
December 05, 2015, 12:03:20 PM |
|
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
Sr. Member
Offline
Activity: 360
Merit: 250
Token
|
|
December 05, 2015, 09:35:22 PM |
|
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 (OP)
Legendary
Offline
Activity: 2142
Merit: 1010
Newbie
|
|
December 05, 2015, 09:44:32 PM |
|
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
Legendary
Offline
Activity: 1225
Merit: 1000
|
|
December 06, 2015, 09:01:13 PM |
|
I'll start working on a project powered by Iota.
Any hints on what that project will be about?
|
|
|
|
Come-from-Beyond (OP)
Legendary
Offline
Activity: 2142
Merit: 1010
Newbie
|
|
December 06, 2015, 09:15:21 PM |
|
Any hints on what that project will be about?
Chat/forum/email hybrid.
|
|
|
|
WorldCoiner
|
|
December 07, 2015, 09:46:04 AM |
|
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 (OP)
Legendary
Offline
Activity: 2142
Merit: 1010
Newbie
|
|
December 07, 2015, 11:39:42 AM |
|
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.
|
|
|
|
|