Topic: IOTA - page 759. (Read 1471689 times)

We will provide software written in Java, its source code and executables for several popular OSes generated with http://www.jwrapper.com.

Will there be a software client/wallet for this, so people can send and receive tokens ? Or we must wait for IoT-devices to spend tokens ?

Frankly saying, this feature is not unique to Iota. It's based on the idea of payment channels (http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf) invented for Bitcoin. When Bitcoin adopts the changes required for payment channel realization is another question.

OK, thanks to you 2.

So, basically, IOTA "universe" doesn't offer more privacy or anonymity than Bitcoin by default, but if the users decide or ask for, some operations will not be "shared and recorded" excepted by some few specific nodes, interresting.

Yes.

ouchh..i'm wrong..??

What do you call a "transaction" here if it is not stored on the tangle ?
How is it off-tangle if few nodes are aware of the transaction ?

EDIT: I think I get it, off-transactions must be done by 2 nodes that doesn't broadcast the transaction.

Privacy level of Iota is not Bitcoin's nor Monero's. Transactions can be done off-tangle being seen only by few nodes, off-tangle transactions are not stored on the tangle.

Hi
As I understand (I'm far from a tech/dev guy), the anonymous and privacy level of IOTA universe is closer to the Bitcoin anon/priv level than to the Monero one ?
Or will/could it be some future options to improve or choose level of anon/priv ?
Great project, it seems :-)
Thanks :-)

Where have you seen "50 billion"?

Minimal PoW is enough, we assume that there exist a constant flow of new transactions which is a pretty reasonable assumption.



The change is not deterministic. No conflicts are created if there are several fixes, because the transaction data are not changed. It's just copied several times.



Several copies of a transaction increase security of the network, not decrease it. I think there is a confusion caused by different terminology. Let's call data required to be signed (amount, beneficiary, etc.) a transaction and the part that contains references and the transaction an envelope. Envelopes reference each other, their sole purpose is to help to achieve consensus, transactions do reference each other indirectly by using outputs of parent transactions as inputs of child transactions. An adversary can't change references inside transactions, anyone can change references inside envelopes but this will only create the 2nd envelope. To be able to censor transactions you need to conduct a successful global eclipse attack, if you only change envelope then you contribute to network security increase. Note, that references inside envelopes are secured by PoW. If you spend electricity on PoW you just make tangle more tangled, which is good.

What this... 50 billion TOKEN..??

Still I can't see why nodes would try to put more PoW into their transactions. Looks like it is enough to submit minimal PoW and have others confirm my transaction with their PoW. It is in the common interest of all users to have more PoW on the legit branch to secure the network against doublespends, but individual interest, it seems, is not aligned with the common one.

I hope the change is deterministic? Otherwise we'll end up having many conflicting "fixes" of references.

This raises another concern. What if a malicious node changes references of a third-party transaction before forwarding it to peers? Different nodes will receive different versions of the same transaction that differ only in references to parents. Also, if references are not secured by signatures, nor by anything else, is it possible to reorder and even censor old transactions, thus changing the graph structure?

Excellent! This is perfectly clear now.

Consider two situations:
1. You need to generate 1 block with 10 zeros in front,
2. You need to generate 1024 blocks with 1 zero.

Let T be the time you need in the 1st case, R is the time you need in the 2nd. T, R are random variables, of course. Now, it is true that T and R have the same expectation, but it is *not* true that their distributions are the same. In particular, the variance of T will be much bigger. What is even more important, is the difference in large deviation probabilities.


 Assume that you need to complete you task within time (expected time)/10. What would you choose, 1 or 2, to maximize your chances? Well, better choose 1. That's quite intuitive. What is not intuitive, is how different these chances are. In situation 1, you will succeed with probability around 10% or so. However, in situation 2, it will be *very* low. Don't want to calculate, but it will be smth like 0.0000000000001... anyhow, practically zero. That's why, if you want to beat the rest of the network, it's much better to bet on "heavy" tx's, and so we avoid this kind of attacks by putting an upper limit on the own weight.

That's exactly the point: if it succeeds. If the legit tx already got enough cumulative weight, then the probability of a successful attack will be very small. Exactly as in bitcoin and other cryptos.

The author of the whitepaper is in a location with a terrible Internet connection now, I'll try to answer instead of him but keep in mind that I may be wrong.

1. Imagine that you need to do N work to outbalance the rest of the network. A winning strategy is to do number crunching in hope to be lucky and find a solution much earlier than in average. If the network reaches the point where N is not enough to outbalance its work then you simply increase N by some value and keep doing hashing until you find a solution. You may need to move your goal again and again though.

2. Nodes don't need to continue to do hashing once their transaction is accepted, others will do that for them if the majority confirms those transactions that confirm others' ones.

3. If a transaction happens to reference double-spending transactions then anyone can change the references. More likely it will be the issuer themselves if they hasn't got the purchased item yet, or the merchant who has already delivered the item and now is interested in transaction confirmation because otherwise he will be unable to spend these coins. A DoS attack is possible but iota has inherent protection against it because every transaction needs to do some work (PoW) before it becomes valid. Every transaction has 2 parts - essential data signed by the owner and references to other transactions, - the latter can be changed without transaction resigning.

I'm working on a similar DAG based design and it was interesting to read your whitepaper. A few questions/concerns:

1. Could you explain in layman's terms, why capping the amount of work per transaction makes double-spend attacks less likely to succeed? It doesn't sound intuitive.

2. What is the incentive for honest nodes to keep PoW on the legit sub-tangle high enough, so that no single attacker (even ASIC-powered one) can create a fake sub-tangle that has higher cumulative weight and contains his doublespend?

3. The whitepaper says that the subtangle that contains a failed doublespend is discarded. Does it mean that all other transactions that happened to approve the doublespend transaction are also discarded? If so, an attacker would try to inject two conflicting transactions at nearly the same time. Since synchronization is not instantaneous, some users will unknowingly approve one of these two transactions before they learn about the other. If they were unlucky to approve the transaction that eventually dies, their own transactions are also discarded, correct? Then it sounds like poor user experience, since user's transaction can be effectively canceled for reasons that he doesn't control. Next, if the attacker continuously sends penny doublespend transactions, he will split the network into multiple branches, most of them will be discarded, and the network will be effectively stalled. This is DoS attack. Next, observe that when a subtangle is discarded, the PoW invested in its creation is also discarded. Then if the attacker tries to doublespend a more sizable amount at the same time, he will reduce the hashpower of the honest part of the network by DoSing it this way, and he will need less resources to produce a subtangle that overweighs this weak legitimate subtangle.

domob published a paper about "Game Channels for Trustless Off-Chain Interactions" the other day, and I think it is also interesting for tangle.

https://bitcointalksearch.org/topic/m.12737521
http://extra.domob.eu/gamechannels.pdf

They can cooperate on that. Every iota transaction has "attachment" field that can store up to 385.14 bits of data which can be used for checkpointing and other things. One of such thing is the root of a Merkle tree storing a complete snapshot of Nxt ledger at some block height.