stdset
|
|
October 28, 2015, 01:52:19 PM |
|
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.
|
|
|
|
|
|
|
|
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.
|
|
|
|
Come-from-Beyond (OP)
Legendary
Offline
Activity: 2142
Merit: 1009
Newbie
|
|
October 28, 2015, 02:23:35 PM |
|
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
|
|
October 28, 2015, 02:40:10 PM |
|
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 (OP)
Legendary
Offline
Activity: 2142
Merit: 1009
Newbie
|
|
October 28, 2015, 02:56:05 PM |
|
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
|
|
October 28, 2015, 03:09:31 PM |
|
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 (OP)
Legendary
Offline
Activity: 2142
Merit: 1009
Newbie
|
|
October 28, 2015, 03:16:02 PM |
|
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
|
|
October 28, 2015, 03:22:39 PM |
|
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 (OP)
Legendary
Offline
Activity: 2142
Merit: 1009
Newbie
|
|
October 28, 2015, 03:45:49 PM |
|
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
|
|
October 28, 2015, 05:23:29 PM |
|
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 (OP)
Legendary
Offline
Activity: 2142
Merit: 1009
Newbie
|
|
October 28, 2015, 05:24:01 PM |
|
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
|
|
October 28, 2015, 05:52:45 PM |
|
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
|
|
October 28, 2015, 06:07:03 PM |
|
Amount of tips is supposed to be small
This is not necessarily the case, in the heavy load regime.
|
|
|
|
stdset
|
|
October 28, 2015, 06:33:39 PM |
|
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
|
|
October 28, 2015, 06:40:26 PM |
|
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
Activity: 1386
Merit: 1000
Fucker of "the system"
|
|
October 28, 2015, 06:51:22 PM |
|
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 (OP)
Legendary
Offline
Activity: 2142
Merit: 1009
Newbie
|
|
October 28, 2015, 07:03:22 PM |
|
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
|
|
October 28, 2015, 07:07:55 PM Last edit: October 28, 2015, 09:58:31 PM by mthcl |
|
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
|
|
October 28, 2015, 07:22:08 PM |
|
ill keep watching on this project
|
|
|
|
nzminer
Legendary
Offline
Activity: 1918
Merit: 1001
|
|
October 28, 2015, 08:09:53 PM |
|
reserved
|
NEM, THE SECURE, SCALABLE BLOCKCHAIN [NEM.IO] [T.ME/NEMRED]
|
|
|
stdset
|
|
October 28, 2015, 08:48:41 PM |
|
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.
|
|
|
|
|