Bitcoin Forum
July 02, 2020, 07:19:37 PM *
News: Latest Bitcoin Core release: 0.20.0 [Torrent]
 
   Home   Help Search Login Register More  
Warning: One or more bitcointalk.org users have reported that they believe that the creator of this topic displays some red flags which make them high-risk. (Login to see the detailed trust ratings.) While the bitcointalk.org administration does not verify such claims, you should proceed with extreme caution.
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 58 59 60 61 62 63 64 65 66 ... 758 »
  Print  
Author Topic: IOTA  (Read 1463323 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.
stdset
Hero Member
*****
Offline Offline

Activity: 572
Merit: 500



View Profile
October 28, 2015, 01:52:19 PM
 #301

A question on the whitepaper.
Why does h - the average time a device needs to do the calculations necessary to issue a transaction depend on L - the total number of tips and N - the total number of transactions? That "total number of transactions" is it the total number of transactions incorporated in the DAG (probably unknown to the device) or what?

It's a general case analysis, a special case (for a particular implementation) may give average time not dependent on some or all these parameters.
You should have some considerations, why could h depend on L and N. Otherwise, for broader generality you should also consider dependence on Moon phase, which btw is easier to know for the device than L and N.

1593717577
Hero Member
*
Offline Offline

Posts: 1593717577

View Profile Personal Message (Offline)

Ignore
1593717577
Reply with quote  #2

1593717577
Report to moderator
There are several different types of Bitcoin clients. The most secure are full nodes like Bitcoin Core, which will follow the rules of the network no matter what miners do. Even if every miner decided to create 1000 bitcoins per block, full nodes would stick to the rules and reject those blocks.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1593717577
Hero Member
*
Offline Offline

Posts: 1593717577

View Profile Personal Message (Offline)

Ignore
1593717577
Reply with quote  #2

1593717577
Report to moderator
1593717577
Hero Member
*
Offline Offline

Posts: 1593717577

View Profile Personal Message (Offline)

Ignore
1593717577
Reply with quote  #2

1593717577
Report to moderator
1593717577
Hero Member
*
Offline Offline

Posts: 1593717577

View Profile Personal Message (Offline)

Ignore
1593717577
Reply with quote  #2

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

Activity: 2128
Merit: 1009

Newbie


View Profile
October 28, 2015, 02:23:35 PM
 #302

You should have some considerations, why could h depend on L and N. Otherwise, for broader generality you should also consider dependence on Moon phase, which btw is easier to know for the device than L and N.

I don't know how to react to your post. It looks half-trollish, half-jokish. For a programmer the dependence between those 3 parameters is so obvious that it's impossible to explain to someone else (as most of obvious things).
stdset
Hero Member
*****
Offline Offline

Activity: 572
Merit: 500



View Profile
October 28, 2015, 02:40:10 PM
 #303

You should have some considerations, why could h depend on L and N. Otherwise, for broader generality you should also consider dependence on Moon phase, which btw is easier to know for the device than L and N.

I don't know how to react to your post. It looks half-trollish, half-jokish. For a programmer the dependence between those 3 parameters is so obvious that it's impossible to explain to someone else (as most of obvious things).
OK, maybe you'll try to explain. Let's first consider dependency on L. So PoW difficulty to generate an envelope depends on current number of tips. And the device probably doesn't even know that number. Why does it depend? In Bitcoin and its clones for example difficulty doesn't depend on tps rate or whatever parameter that could be comparable to the number of tips in the DAG.

Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2128
Merit: 1009

Newbie


View Profile
October 28, 2015, 02:56:05 PM
 #304

OK, maybe you'll try to explain. Let's first consider dependency on L. So PoW difficulty to generate an envelope depends on current number of tips. And the device probably doesn't even know that number. Why does it depend? In Bitcoin and its clones for example difficulty doesn't depend on tps rate or whatever parameter that could be comparable to the number of tips in the DAG.

It depends because some work on finding optimal 2 tips is done.
stdset
Hero Member
*****
Offline Offline

Activity: 572
Merit: 500



View Profile
October 28, 2015, 03:09:31 PM
 #305

OK, maybe you'll try to explain. Let's first consider dependency on L. So PoW difficulty to generate an envelope depends on current number of tips. And the device probably doesn't even know that number. Why does it depend? In Bitcoin and its clones for example difficulty doesn't depend on tps rate or whatever parameter that could be comparable to the number of tips in the DAG.

It depends because some work on finding optimal 2 tips is done.
Do you mean that a node should traverse more or less the whole DAG to detect doublespends and choose tips that confirm more confirmed doublespends?

Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2128
Merit: 1009

Newbie


View Profile
October 28, 2015, 03:16:02 PM
 #306

Do you mean that a node should traverse more or less the whole DAG to detect doublespends and choose tips that confirm more confirmed doublespends?

No, it should go through tips that it sees and pick 2 good ones.
stdset
Hero Member
*****
Offline Offline

Activity: 572
Merit: 500



View Profile
October 28, 2015, 03:22:39 PM
 #307

Do you mean that a node should traverse more or less the whole DAG to detect doublespends and choose tips that confirm more confirmed doublespends?

No, it should go through tips that it sees and pick 2 good ones.
Then time needed for such a search should be incomparable to time needed for generating PoW (intuitively microseconds vs seconds) and should be neglected.

Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2128
Merit: 1009

Newbie


View Profile
October 28, 2015, 03:45:49 PM
 #308

Then time needed for such a search should be incomparable to time needed for generating PoW (intuitively microseconds vs seconds) and should be neglected.

If it's an IoT-device asking peers from the swarm then times can be comparable.
stdset
Hero Member
*****
Offline Offline

Activity: 572
Merit: 500



View Profile
October 28, 2015, 05:23:29 PM
 #309

Then time needed for such a search should be incomparable to time needed for generating PoW (intuitively microseconds vs seconds) and should be neglected.

If it's an IoT-device asking peers from the swarm then times can be comparable.
In that case h rather depends on amount of peers polled or on the slowest peer to respond than on amount of tips.

Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2128
Merit: 1009

Newbie


View Profile
October 28, 2015, 05:24:01 PM
 #310

In that case h rather depends on amount of peers polled or on the slowest peer to respond than on amount of tips.

Why?
stdset
Hero Member
*****
Offline Offline

Activity: 572
Merit: 500



View Profile
October 28, 2015, 05:52:45 PM
 #311

In that case h rather depends on amount of peers polled or on the slowest peer to respond than on amount of tips.

Why?
Amount of tips is supposed to be small, so amount of data transfered is small. So the time to send a request and receive an answer should depend mostly on network and peers latency. If all requests are performed in parallel, than the slowest to respond peer determines the time. If requests are sent serially, then the time is roughly proportional to requests amount.

mthcl
Sr. Member
****
Offline Offline

Activity: 376
Merit: 300


View Profile
October 28, 2015, 06:07:03 PM
 #312


Amount of tips is supposed to be small

This is not necessarily the case, in the heavy load regime.
stdset
Hero Member
*****
Offline Offline

Activity: 572
Merit: 500



View Profile
October 28, 2015, 06:33:39 PM
 #313


Amount of tips is supposed to be small

This is not necessarily the case, in the heavy load regime.
That could help to conduct a doublespend btw. A hacker accumulates a lot of PoW in legit small transactions forming huge amount of new tips, but doesn't broadcast them. Then he sends a legit transaction, waits for it to be confirmed, gets his purchase sent to him. Then he creates a doublespend (for example sends the same money back to himself) and floods the network with his precomputed legit transactions. So network hashpower now is spread over his tips and he needs much less hashpower to create enough transactions confirming his doublespend to overtake the first transaction.

stdset
Hero Member
*****
Offline Offline

Activity: 572
Merit: 500



View Profile
October 28, 2015, 06:40:26 PM
 #314

Correct me if I'm wrong, but what prevents the following attack?
A hacker creates two transactions, one of them will be a legit transaction, used to purchase something, another is a doublespend. Then the hacker invests a lot of PoW in confirming the second transaction. In order to do that he just creates a lot of transactions sending money between his addresses, all his trnsactions refer directly or indirectly the doublespend, so his doublespend gets huge confirmation score. Then he broadcasts the first transaction, and when it gets confirmed he broadcasts the whole doublespend branch.
Do I miss something?

MickGhee
Legendary
*
Offline Offline

Activity: 1190
Merit: 1000

Fucker of "the system"


View Profile
October 28, 2015, 06:51:22 PM
 #315

Correct me if I'm wrong, but what prevents the following attack?
A hacker creates two transactions, one of them will be a legit transaction, used to purchase something, another is a doublespend. Then the hacker invests a lot of PoW in confirming the second transaction. In order to do that he just creates a lot of transactions sending money between his addresses, all his trnsactions refer directly or indirectly the doublespend, so his doublespend gets huge confirmation score. Then he broadcasts the first transaction, and when it gets confirmed he broadcasts the whole doublespend branch.
Do I miss something?

^^^^^^this guy right here this is why i love this place.. some smart mofos up in here.  

Last night, while you were sleeping. I fucked the system!
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2128
Merit: 1009

Newbie


View Profile
October 28, 2015, 07:03:22 PM
 #316

Correct me if I'm wrong, but what prevents the following attack?
A hacker creates two transactions, one of them will be a legit transaction, used to purchase something, another is a doublespend. Then the hacker invests a lot of PoW in confirming the second transaction. In order to do that he just creates a lot of transactions sending money between his addresses, all his trnsactions refer directly or indirectly the doublespend, so his doublespend gets huge confirmation score. Then he broadcasts the first transaction, and when it gets confirmed he broadcasts the whole doublespend branch.
Do I miss something?

Nothing is missed.

http://bitcoin.stackexchange.com/questions/4942/what-is-a-finney-attack
mthcl
Sr. Member
****
Offline Offline

Activity: 376
Merit: 300


View Profile
October 28, 2015, 07:07:55 PM
Last edit: October 28, 2015, 09:58:31 PM by mthcl
 #317


Amount of tips is supposed to be small

This is not necessarily the case, in the heavy load regime.
That could help to conduct a doublespend btw. A hacker accumulates a lot of PoW in legit small transactions forming huge amount of new tips, but doesn't broadcast them. Then he sends a legit transaction, waits for it to be confirmed, gets his purchase sent to him. Then he creates a doublespend (for example sends the same money back to himself) and floods the network with his precomputed legit transactions. So network hashpower now is spread over his tips and he needs much less hashpower to create enough transactions confirming his doublespend to overtake the first transaction.

The algorithm for choosing the tips to reference "prefers" tips with larger height. Those precomputed legit transactions will have much smaller cumulative weight (than other tips), and so they will probably not be referenced by others.

Correct me if I'm wrong, but what prevents the following attack?
A hacker creates two transactions, one of them will be a legit transaction, used to purchase something, another is a doublespend. Then the hacker invests a lot of PoW in confirming the second transaction. In order to do that he just creates a lot of transactions sending money between his addresses, all his trnsactions refer directly or indirectly the doublespend, so his doublespend gets huge confirmation score. Then he broadcasts the first transaction, and when it gets confirmed he broadcasts the whole doublespend branch.
Do I miss something?

If the attacker started to create his double-spending subtangle long time ago, then the initial tx's of this subtangle reference some rather old tx's, with not-so-big cumulative weight. While the attacker waits, the cumulative weight of the legit tangle continues to grow, so he won't be able to catch up.

Of course, this assumes that the attacker's max possible tx's rate is much less then the "usual" tx's rate of the rest of the network.
alicex
Sr. Member
****
Offline Offline

Activity: 365
Merit: 250


View Profile
October 28, 2015, 07:22:08 PM
 #318

ill keep watching on this project
nzminer
Legendary
*
Offline Offline

Activity: 1904
Merit: 1001



View Profile
October 28, 2015, 08:09:53 PM
 #319

reserved

NEM, THE SECURE, SCALABLE BLOCKCHAIN [NEM.IO] [T.ME/NEMRED]
stdset
Hero Member
*****
Offline Offline

Activity: 572
Merit: 500



View Profile
October 28, 2015, 08:48:41 PM
 #320

If the attacker started to create his double-spending subtangle long time ago, then the initial tx's of this subtangle reference some rather old tx's, with not-so-big cumulative weight. While the attacker waits, the cumulative weight of the legit tangle continues to grow, so he won't be able to catch up.

Of course, this assumes that the attacker's max possible tx's rate is much less then the "usual" tx's rate of the rest of the network.
The first (legit) transaction references the same old transactions as the doublespend. The attacker doesn't need to compete with the rest of network.

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 58 59 60 61 62 63 64 65 66 ... 758 »
  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!