although running a node without reward (I'm correct in thinking there are no tx fees?) will presumably only be of interest to those who partook in the crowdsale.
Bitcoin nodes don't get tx fees but there are still plenty of them.
Topic: IOTA - page 712. (Read 1473233 times)
Guys, we need more public nodes, so far only 5 entities have declared their willingness to run them...
a broadcast on https://www.reddit.com/r/IOTAtoken/ + @iotatoken + https://www.iotatoken.com/ should help; although running a node without reward (I'm correct in thinking there are no tx fees?) will presumably only be of interest to those who partook in the crowdsale.
Well, the idea is that storage isn't cheap if the device is an IoT device. Imagine a low-end chip that only has less than 1GB of on board memory cause this functionality is only secondary to the device. 1GB won't go far in a couple years, especially if that 1GB is used to manage other systems on the simplistic device.
Bandwidth, however, could be "cheap" if all the machine needs is a wifi connection to a local connection.
Bandwidth, however, could be "cheap" if all the machine needs is a wifi connection to a local connection.
If you are an IoT device you'd better load tangle from young transactions to old.
We discussed this issue and decided to change the plans regarding pruning. The original plan was to start without pruning to see how popular on-tangle messaging will be. This plan has such a drawback as necessity to make non-compatible changes in the future. Recently we were contacted by a couple of hardware manufacturers which had become interested in Iota. If they adopt Iota protocol then non-compatible changes may break their solutions, so pruning support from the very beginning seems to be the only right step. This will require to change some code and add more pieces, so expect that the test will be delayed. Also, we are still discussing if we should allow testnet to be run before the mainnet.
Guys, we need more public nodes, so far only 5 entities have declared their willingness to run them...
I could help with Android TV stick with static IP, running linux, but don't know it will not explode as I also run NXT public node on it
Add me to the list. I'll try to keep one consistently going until the network picks up.
PM me with node IP/domain, please.
Just curious, but will there be a "Find the 3 logical bugs" type of reward for IOTA like Nxt? I know this isn't Nxt, but IMHO that was a great way to have everyone knit-pick the code AND market the coin.
Nothing like that is planned AFAIK.
Calling all IOTA users:
Every IOTA enthusiast that want to be part of the Ryver for IOTA, where we will discuss future steps and work on getting adoption, development, branding, marketing etc, send me a PM with your e-mail as well as a brief description of what your talents are.
Every IOTA enthusiast that want to be part of the Ryver for IOTA, where we will discuss future steps and work on getting adoption, development, branding, marketing etc, send me a PM with your e-mail as well as a brief description of what your talents are.
Well, the idea is that storage isn't cheap if the device is an IoT device. Imagine a low-end chip that only has less than 1GB of on board memory cause this functionality is only secondary to the device. 1GB won't go far in a couple years, especially if that 1GB is used to manage other systems on the simplistic device.
Bandwidth, however, could be "cheap" if all the machine needs is a wifi connection to a local connection.
Bandwidth, however, could be "cheap" if all the machine needs is a wifi connection to a local connection.
If you are an IoT device you'd better load tangle from young transactions to old.
Well, the idea is that storage isn't cheap if the device is an IoT device. Imagine a low-end chip that only has less than 1GB of on board memory cause this functionality is only secondary to the device. 1GB won't go far in a couple years, especially if that 1GB is used to manage other systems on the simplistic device.
Bandwidth, however, could be "cheap" if all the machine needs is a wifi connection to a local connection.
Bandwidth, however, could be "cheap" if all the machine needs is a wifi connection to a local connection.
For myself, and others, can you verify if this assumption is true.
For a person to post a payment, they must verify (sign?) two previous transactions. For the signer to approve the transaction, they simply need to download/check the full transaction chain of these two transactions, back to the genesis block.
For efficiency, once any edge-node transactions have been verified, simpler nodes can "throw out" all earlier transactions that have been verified. If an former transaction is needed for verification (e.g. if it is linked by a new transaction, referencing a much older transaction) then all the node has to do is re-download the chain of the old transaction, back to the genesis transaction from other other nodes, and can then accept the new transaction.
This means that the transaction database can be somewhat light-weight for simple nodes and only the BIG servers that may want quick-reference to all transactions may want to keep all transactions and never trim their databases.
Are these assumptions correct?
For a person to post a payment, they must verify (sign?) two previous transactions. For the signer to approve the transaction, they simply need to download/check the full transaction chain of these two transactions, back to the genesis block.
For efficiency, once any edge-node transactions have been verified, simpler nodes can "throw out" all earlier transactions that have been verified. If an former transaction is needed for verification (e.g. if it is linked by a new transaction, referencing a much older transaction) then all the node has to do is re-download the chain of the old transaction, back to the genesis transaction from other other nodes, and can then accept the new transaction.
This means that the transaction database can be somewhat light-weight for simple nodes and only the BIG servers that may want quick-reference to all transactions may want to keep all transactions and never trim their databases.
Are these assumptions correct?
Well, you could rely on PoW weight to throw out old transactions but storage is much cheaper than bandwidth in unicast mode (not true for broadcast and for multicast to some degree), so I don't see a benefit in pruning.
Also note, that nodes accept and share all transactions that pass PoW verification, even if they conflict with each other. Payment graph is analyzed only when a node sends or receives iotas.
@CfB: Can you ELI5 how consensus works in IOTA without blockchain? I mean, how do nodes know who owns which tokens?
It's similar to blockchain.
For myself, and others, can you verify if these assumption is true.
For a person to post a payment, they must verify (sign?) two previous transactions. For the signer to approve the transaction, they simply need to download/check the full transaction chain of these two transactions, back to the genesis block.
For efficiency, once any edge-node transactions have been verified, simpler nodes can "throw out" all earlier transactions that have been verified. If a former transaction is needed for verification of a newly incoming tx (e.g. if it is linked by a new transaction, referencing a much older transaction) then all the node has to do is re-download the chain of the old transaction, back to the genesis transaction from other nodes, and can then accept the new transaction (assuming the tx chain is valid.)
This means that the transaction database can be somewhat light-weight for simple nodes and only the BIG servers that may want quick-reference to all transactions may want to keep all transactions and never trim their databases.
Are these assumptions correct?
@CfB: Can you ELI5 how consensus works in IOTA without blockchain? I mean, how do nodes know who owns which tokens?
It's similar to blockchain.
Is anyone going to create another Iota implementation? If not, think of it. Iota protocol is very simple - there is only one transaction type and only one packet type for UDP transport. A lightweight node doesn't even need to validate payment graph, it can fetch all required data from full nodes with the help of that single UDP packet type.
Jump to: