Bitcoin Forum
July 24, 2017, 12:54:58 AM *
News: Due to BIP91, it would starting now be prudent to require 5 times more confirmations than usual before trusting transactions.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 [7] 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 ... 508 »
  Print  
Author Topic: IOTA  (Read 821262 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
Ratatosk
Full Member
***
Offline Offline

Activity: 232


View Profile
October 22, 2015, 01:19:33 PM
 #121

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 :-)
1500857698
Hero Member
*
Offline Offline

Posts: 1500857698

View Profile Personal Message (Offline)

Ignore
1500857698
Reply with quote  #2

1500857698
Report to moderator
1500857698
Hero Member
*
Offline Offline

Posts: 1500857698

View Profile Personal Message (Offline)

Ignore
1500857698
Reply with quote  #2

1500857698
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1500857698
Hero Member
*
Offline Offline

Posts: 1500857698

View Profile Personal Message (Offline)

Ignore
1500857698
Reply with quote  #2

1500857698
Report to moderator
1500857698
Hero Member
*
Offline Offline

Posts: 1500857698

View Profile Personal Message (Offline)

Ignore
1500857698
Reply with quote  #2

1500857698
Report to moderator
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 1652

Newbie


View Profile
October 22, 2015, 01:56:29 PM
 #122

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 :-)

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.
superresistant
Legendary
*
Offline Offline

Activity: 1540



View Profile
October 22, 2015, 02:06:03 PM
 #123

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.

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.

Here's my bag so you don't ask : BTC, iexec, byteball and pepecash
jcksteve
Hero Member
*****
Offline Offline

Activity: 559


ICASH Addict !!


View Profile WWW
October 22, 2015, 02:14:06 PM
 #124

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

Where have you seen "50 billion"?
ouchh..i'm wrong..??

To join #ICASH slack, please send PM your email to get invite !
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 1652

Newbie


View Profile
October 22, 2015, 02:23:13 PM
 #125

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

Yes.
Ratatosk
Full Member
***
Offline Offline

Activity: 232


View Profile
October 22, 2015, 02:29:48 PM
 #126

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

Yes.

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.
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 1652

Newbie


View Profile
October 22, 2015, 02:39:47 PM
 #127

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.

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.
50cent_rapper
Legendary
*
Offline Offline

Activity: 1218



View Profile
October 22, 2015, 02:45:54 PM
 #128

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 ?
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 1652

Newbie


View Profile
October 22, 2015, 02:55:56 PM
 #129

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 ?

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

Activity: 462


View Profile WWW
October 22, 2015, 04:04:15 PM
 #130

Minimal PoW is enough, we assume that there exist a constant flow of new transactions which is a pretty reasonable assumption.
Got it. But I still doubt it is secure. With roughly constant flow of transactions, we have roughly constant PoW generated on the legit branch.
In Bitcoin, we always have better, more power efficient ASICs. The miner who is first to install a new ASIC, obtains temporary advantage over other miners (assuming all other variables equal). A new ASIC basically redistributes the constant flow of wealth (25BTC/block) among miners, ordinary users don't care. And it was one of design goals of Bitcoin that mining is more profitable than attacking.
In Iota, I'm afraid, it'll be profitable to use ASICs against users. If minimal PoW per transaction is small enough then a small battery of ASICs might be enough to outPoW the whole legitimate network armed with CPU PoW.

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.
Thanks, terminology definitely helped.
So you allow to duplicate a transaction as long as PoW is also duplicated.
What about attempts to rewrite history by rewriting the envelopes?



In this example from the whitepaper, if I wanted to censor envelope F and the corresponding transaction (because e.g. it contained a spend that I want to roll back), could I "route around" it by spending some electricity and rewriting references in envelopes of E and B so that they no longer point to F but somewhere else? Then there are no references to F in the graph any more, I can safely delete it and share my version of the history with other nodes. How will they know which history is right?

Simplicity is beauty
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 1652

Newbie


View Profile
October 22, 2015, 04:33:44 PM
 #131

Got it. But I still doubt it is secure. With roughly constant flow of transactions, we have roughly constant PoW generated on the legit branch.
In Bitcoin, we always have better, more power efficient ASICs. The miner who is first to install a new ASIC, obtains temporary advantage over other miners (assuming all other variables equal). A new ASIC basically redistributes the constant flow of wealth (25BTC/block) among miners, ordinary users don't care.
In Iota, I'm afraid, it'll be profitable to use ASICs against users. If minimal PoW per transaction is small enough then a small battery of ASICs might be enough to outPoW the whole legitimate network armed with CPU PoW.

Bitcoin has constant PoW during a week too, I don't see how constant PoW leads to an insecure state. Would anyone create ASICs for Bitcoin mining if there was no subsidy (25 BTC) nor transaction fees?
Security of Iota relies on assumption that an adversary controls less than 50% of hashing power. This is a standard assumption in cryptoindustry. Bootstrapping period will be protected by checkpoints.


Thanks, terminology definitely helped.
So you allow to duplicate a transaction as long as PoW is also duplicated.
What about attempts to rewrite history by rewriting the envelopes?



In this example from the whitepaper, if I wanted to censor envelope F and the corresponding transaction (because e.g. it contained a spend that I want to roll back), could I "route around" it by spending some electricity and rewriting references in envelopes of E and B so that they no longer point to F but somewhere else? Then there are no references to F in the graph any more, I can safely delete it and share my version of the history with other nodes. How will they know which history is right?

The history with the heaviest tangle is right. To rewrite the history you need to control most of the hashing power.
rlh
Hero Member
*****
Offline Offline

Activity: 775


View Profile
October 22, 2015, 05:11:31 PM
 #132

Ok, I just skimmed the white paper (a little better than reading just the conclusions, but not fully digesting the formulas.)

I have a question about a type of attack.  Since this is an IoT coin, it is my understanding that in order to fully confirm a transaction, you should validate the full chain from the TX to the genesis transaction correct?  Over time this shouldn't be a problem because a node should only have to download transactions that are missing from any tip.  For example, if I get a Transaction F, and I already have transactions A->B->C in the F's chain, I only need to download transactions D->E, and validate the associated signatures for these transactions, in order to fully validate F.  Once F is fully validated in this manner, I can validate/sign F to post with my transaction G.

Now, what's to prevent someone from accepting a payment and creating a massive, off-chain tangle?  Maybe I spend 1-2 days, generating really long, off-net tangles.

I then submit a single transaction that relies on gigabytes of transnational details that only my Sybil nodes hold.  Wouldn't the network flood with requests for information on these transactions?  This may not seem like a big deal, but if IOTA is to be used with small(ish) IoT devices that can benefit from micro-payments, can't such information requests overload such devices?

Solution: When confirming a transaction, if you have to back-search a constant number of transactions, toss out the transaction.  In other words, if I have to request 5 transaction generations and I'm still not on the main-chain, I can toss out the transaction.

Is my scenario even a problem?

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
Legendary
*
Offline Offline

Activity: 1652

Newbie


View Profile
October 22, 2015, 05:51:54 PM
 #133

Ok, I just skimmed the white paper (a little better than reading just the conclusions, but not fully digesting the formulas.)

I have a question about a type of attack.  Since this is an IoT coin, it is my understanding that in order to fully confirm a transaction, you should validate the full chain from the TX to the genesis transaction correct?  Over time this shouldn't be a problem because a node should only have to download transactions that are missing from any tip.  For example, if I get a Transaction F, and I already have transactions A->B->C in the F's chain, I only need to download transactions D->E, and validate the associated signatures for these transactions, in order to fully validate F.  Once F is fully validated in this manner, I can validate/sign F to post with my transaction G.

Now, what's to prevent someone from accepting a payment and creating a massive, off-chain tangle?  Maybe I spend 1-2 days, generating really long, off-net tangles.

I then submit a single transaction that relies on gigabytes of transnational details that only my Sybil nodes hold.  Wouldn't the network flood with requests for information on these transactions?  This may not seem like a big deal, but if IOTA is to be used with small(ish) IoT devices that can benefit from micro-payments, can't such information requests overload such devices?

Solution: When confirming a transaction, if you have to back-search a constant number of transactions, toss out the transaction.  In other words, if I have to request 5 transaction generations and I'm still not on the main-chain, I can toss out the transaction.

Is my scenario even a problem?

A low-end device may be unable to process gigabytes of data within a short period of time, but it can cooperate with other low-end devices and split the burden by using techniques like https://en.wikipedia.org/wiki/MapReduce. A M-of-N multisignature with virtually unlimited M and N will make elements of such swarms to behave honestly (otherwise they will lose money or won't get their transactions accepted). Luckily for devices which don't have "friends", it's not necessary to "see" the whole tangle if they spend money, they can reference old transactions and wait a little longer. If they accept money then they can explicitly warn their customers that a payment may take very long time for verification. On the other hand, if they provide a service they may spend a lot of time and create off-tangle payment channels (or even ask their owner to do it for them by using his computer) and then accept payments without worrying about the size of the tangle.
rlh
Hero Member
*****
Offline Offline

Activity: 775


View Profile
October 22, 2015, 06:01:18 PM
 #134

Using MapReduce is an interesting approach and would certainly make sense.  However, if it's not implemented (say, in a tech product by a company that didn't think to integrate it) this is a viable form of a spam attack.

I certainly understand that IOTA will initially be what the initial client software provides, but if you are planning on a robust IoT use-case, there should be a standardized communications protocol so that people companies can roll their client-code for their hardware. 

Providing pre-existing implementations of MapReduce logic could help encourage responsible development.  Otherwise, it might not be even an after-thought and once products and nodes exist, this type of attack would be considerably easy to implement.

These are just some additional thoughts on the matter.

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
Legendary
*
Offline Offline

Activity: 1652

Newbie


View Profile
October 22, 2015, 06:14:16 PM
 #135

Using MapReduce is an interesting approach and would certainly make sense.  However, if it's not implemented (say, in a tech product by a company that didn't think to integrate it) this is a viable form of a spam attack.

I certainly understand that IOTA will initially be what the initial client software provides, but if you are planning on a robust IoT use-case, there should be a standardized communications protocol so that people companies can roll their client-code for their hardware. 

Providing pre-existing implementations of MapReduce logic could help encourage responsible development.  Otherwise, it might not be even an after-thought and once products and nodes exist, this type of attack would be considerably easy to implement.

These are just some additional thoughts on the matter.

Valid point, we just need to make sure that we won't fit too much into the standard making Iota lose its lightweightness.
petko
Newbie
*
Offline Offline

Activity: 11


View Profile
October 22, 2015, 09:27:01 PM
 #136

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

Security of Iota relies on assumption that an adversary controls less than 50% of hashing power. This is a standard assumption in cryptoindustry. Bootstrapping period will be protected by checkpoints.

So for a transaction to be considered confirmed, the number of approving transactions multiplied by the minimal PoW must exceed the maximal possible adversary's PoW?
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 1652

Newbie


View Profile
October 22, 2015, 09:32:05 PM
 #137

So for a transaction to be considered confirmed, the number of approving transactions multiplied by the minimal PoW must exceed the maximal possible adversary's PoW?

No, it's not that easy, if transaction flow drops then an adversary can catch up and double-spend. It's a never ending race.
tobeaj2mer01
Legendary
*
Offline Offline

Activity: 1025


Angel investor.


View Profile
October 23, 2015, 06:53:48 AM
 #138

How can we get IOTA? Can we mine it or buy it?
petko
Newbie
*
Offline Offline

Activity: 11


View Profile
October 23, 2015, 06:56:27 AM
 #139

No, it's not that easy, if transaction flow drops then an adversary can catch up and double-spend. It's a never ending race.

Indeed, right. Another try:

To consider the system secure, the average number of transactions per second, multiplied by the minimal PoW, must exceed the maximal hash power per second of a probable attacker
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 1652

Newbie


View Profile
October 23, 2015, 07:15:29 AM
 #140

Indeed, right. Another try:

To consider the system secure, the average number of transactions per second, multiplied by the minimal PoW, must exceed the maximal hash power per second of a probable attacker

This looks good for the edge case of a tangle degenerated to a chain. It should be the same for a tangle with arbitrary topology for transactions that have already been considered confirmed, but intuition says that it's incorrect for transactions that haven't passed their adaptation period (i.e. there are a lot of tips not referencing them) yet.
Pages: « 1 2 3 4 5 6 [7] 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 ... 508 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!