|
dotnetmin
|
 |
April 28, 2014, 12:48:02 PM |
|
So what's everyone's predictions for the near future? Waiting to see some movement due to RC2 release? Going to try and short DRK?
If you have enough, try to short and buy back later. I had no luck with playing these games. |
|
|
|
|
|
|
|
|
|
|
|
There are several different types of Bitcoin clients. The most secure are full nodes like Bitcoin Core, but full nodes are more resource-heavy, and they must do a lengthy initial syncing process. As a result, lightweight clients with somewhat less security are commonly used.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
dotnetmin
|
|
April 28, 2014, 12:52:02 PM |
|
I think people are selling darkcoin to move into dogecoin because of the halvening!
Not really. The last halving didn't do anything. Halving could result a lost of nethash. As WC has halved one hour later Nethash also halved. Doge nethash won´t half, but where to go with you scrypt rig ? |
|
|
|
|
eduffield (OP)
Legendary
 Offline
Activity: 1176
Merit: 1036
Dash Developer
|
|
April 28, 2014, 12:56:11 PM |
|
I think it was mentioned, in the discussion between evan/anonymint that by darksending it multiple times through a number of nodes it reduces the bad-actor probabilities to a statistically safe degree to solve the issue that the darksend node knows who sends what.
I think I have a better solution than that, I want to turn the masternodes into I2P relays for darkcoin. So your client will pick one when you start, then relay any messages through that one. It encrypts all of the traffic, removes the connection between IP and address and it the blockchain is still a complete fog. Plus it'll be a private I2P, so it'll be super fast. Masternodes are going to be awesome  |
Dash - Digital Cash | dash.org | dashfoundation.io | dashgo.io
|
|
|
|
LimLims
|
|
April 28, 2014, 01:25:05 PM |
|
I think it was mentioned, in the discussion between evan/anonymint that by darksending it multiple times through a number of nodes it reduces the bad-actor probabilities to a statistically safe degree to solve the issue that the darksend node knows who sends what.
I think I have a better solution than that, I want to turn the masternodes into I2P relays for darkcoin. So your client will pick one when you start, then relay any messages through that one. It encrypts all of the traffic, removes the connection between IP and address and it the blockchain is still a complete fog. Plus it'll be a private I2P, so it'll be super fast. Masternodes are going to be awesome I2P is good, but if it's a replacement for chained pooling, that implies that it solves the problem of sybil masternodes (since that was the reason why chained pooling was needed). Is that the case, and if so, how does it solve the problem? |
|
|
|
GhostPlayer
Legendary
Offline
Activity: 1092
Merit: 1000
|
|
April 28, 2014, 01:29:33 PM
Last edit: April 28, 2014, 01:52:33 PM by GhostPlayer |
|
Very interesting talk between A.A. and Peter Todd in the latest LTB. Side-chains, tree-chains, merged mining, etc etc http://letstalkbitcoin.com |
|
|
|
|
nanard
Member
Offline
Activity: 80
Merit: 10
|
|
April 28, 2014, 01:32:15 PM |
|
I think people are selling darkcoin to move into dogecoin because of the halvening!
Not really. The last halving didn't do anything. Halving could result a lost of nethash. As WC has halved one hour later Nethash also halved. Doge nethash won´t half, but where to go with you scrypt rig ? Or the dogecoin value doubles and you earn as much with half the hashrate  |
|
|
|
|
|
Simcom
|
|
April 28, 2014, 01:32:31 PM |
|
Btw, I got an idea just now: It would be an interesting twist if one could send to two addresses instead of one, in a single transaction, with the sent amount being broken into two randomly sized parts. For example I send you 16 DRK and you get 5.4 DRK in one address and 10.6 DRK in another. You still got 16 but it's in two addresses so noone can corelate my 16 output and your receiving of ..5.4 and 10.6. If a further layer is added (for practical purposes) to treat these addresses as one (for the sender and receiver) it could also be quite easy to use. Kind of meta-addresses that overlap/include the sending/receiving addresses.
ok -- but with a timing analysis, the number of transactions in (let's say) a 60 second window will be relatively few, so it's not too hard to reconstruct what really happened, especially with uncommon amounts (e.g. I send you 16.023957). [Note- i don't know what is chain pooling that you mentioned...] When someone here ran a script to calculate the rich-list (many pages back), I remember he/she managed to correlate between different addresses as being part of the same wallet. So if I understand correct, what AlexGR suggested sounds intriguing, but 'hackable'. My question is- what if we take it further and instead of having the transactions divided between several addresses, it ius divided into several 'wallets' that reside on the same qt, feed from the same blackchain dat, but each having a separate wallet.dat file/keys ? As far as the network is concerned, wallets do not exist, only addresses. Your wallet just holds all of your addresses and the private keys associated with them. Back to your original question about timing analysis, look at the bottom figure on page 3 of the whitepaper. Each user will be placing the same # of coins into the pool (100 for example) - they will also provide a "spare change" address - coins that they don't want to spend but will come back to them. This is a NEW address that has not been associated with them up to this point. So lets say 3 people each put in 100 coins A -> 100 sending 2 coins to D B -> 100 sending 24 coins to E C -> 100 sending 56 coins to F The outputs will be 2 coins to D 98 coins to G 24 coins to E 76 coins to H 56 coins to F 46 coins to I Now from this we can determine that the current holder of address G sent two coins to D, but it's impossible to determine whether G belongs to the same person as A, B, or C. A new problem arises though, in that the coins are now sitting on address G, and it can be determined that the holder of those coins sent 2 coins to address D. There would need to be another level of mixing to ensure that those 98 coins are washed another time - maybe Evan can clarify whether this mixing step happens or if I am misunderstanding something. The risk is if address G sends money to something like coinbase (or some other site that has your personal info) -> that would expose them as the sender of 2 coins to address D. Evan can you clarify? |
|
|
|
|
|
Kai Proctor
|
|
April 28, 2014, 01:58:49 PM |
|
Btw, I got an idea just now: It would be an interesting twist if one could send to two addresses instead of one, in a single transaction, with the sent amount being broken into two randomly sized parts. For example I send you 16 DRK and you get 5.4 DRK in one address and 10.6 DRK in another. You still got 16 but it's in two addresses so noone can corelate my 16 output and your receiving of ..5.4 and 10.6. If a further layer is added (for practical purposes) to treat these addresses as one (for the sender and receiver) it could also be quite easy to use. Kind of meta-addresses that overlap/include the sending/receiving addresses.
ok -- but with a timing analysis, the number of transactions in (let's say) a 60 second window will be relatively few, so it's not too hard to reconstruct what really happened, especially with uncommon amounts (e.g. I send you 16.023957). [Note- i don't know what is chain pooling that you mentioned...] When someone here ran a script to calculate the rich-list (many pages back), I remember he/she managed to correlate between different addresses as being part of the same wallet. So if I understand correct, what AlexGR suggested sounds intriguing, but 'hackable'. My question is- what if we take it further and instead of having the transactions divided between several addresses, it ius divided into several 'wallets' that reside on the same qt, feed from the same blackchain dat, but each having a separate wallet.dat file/keys ? As far as the network is concerned, wallets do not exist, only addresses. Your wallet just holds all of your addresses and the private keys associated with them. Back to your original question about timing analysis, look at the bottom figure on page 3 of the whitepaper. Each user will be placing the same # of coins into the pool (100 for example) - they will also provide a "spare change" address - coins that they don't want to spend but will come back to them. This is a NEW address that has not been associated with them up to this point. So lets say 3 people each put in 100 coins A -> 100 sending 2 coins to D B -> 100 sending 24 coins to E C -> 100 sending 56 coins to F The outputs will be 2 coins to D 98 coins to G 24 coins to E 76 coins to H 56 coins to F 46 coins to I Now from this we can determine that the current holder of address G sent two coins to D, but it's impossible to determine whether G belongs to the same person as A, B, or C. A new problem arises though, in that the coins are now sitting on address G, and it can be determined that the holder of those coins sent 2 coins to address D. There would need to be another level of mixing to ensure that those 98 coins are washed another time - maybe Evan can clarify whether this mixing step happens or if I am misunderstanding something. The risk is if address G sends money to something like coinbase (or some other site that has your personal info) -> that would expose them as the sender of 2 coins to address D. Evan can you clarify? It doesn't work like this, it's far more complex. It seems when I follow a transaction that all the address' balance is spent including 10 DRK which is used for the mixing. |
|
|
|
|
|
coinpool_de
|
|
April 28, 2014, 02:05:35 PM |
|
Hello, this week we started a new Service called CoinMonitor.de User can see a Live Trading Chart for Cryptsy and Mintpal Orders. Fully dynamic refreshing. Mintpal and Crypts realtime refreshing orderbook and charts  http://drk.coinmonitor.deHope you Like it !!! |
|
|
|
|
|
|
|
Simcom
|
|
April 28, 2014, 02:10:43 PM |
|
As far as the network is concerned, wallets do not exist, only addresses. Your wallet just holds all of your addresses and the private keys associated with them.
Back to your original question about timing analysis, look at the bottom figure on page 3 of the whitepaper. Each user will be placing the same # of coins into the pool (100 for example) - they will also provide a "spare change" address - coins that they don't want to spend but will come back to them. This is a NEW address that has not been associated with them up to this point.
So lets say 3 people each put in 100 coins
A -> 100 sending 2 coins to D
B -> 100 sending 24 coins to E
C -> 100 sending 56 coins to F
The outputs will be
2 coins to D
98 coins to G
24 coins to E
76 coins to H
56 coins to F
46 coins to I
Now from this we can determine that the current holder of address G sent two coins to D, but it's impossible to determine whether G belongs to the same person as A, B, or C.
A new problem arises though, in that the coins are now sitting on address G, and it can be determined that the holder of those coins sent 2 coins to address D. There would need to be another level of mixing to ensure that those 98 coins are washed another time - maybe Evan can clarify whether this mixing step happens or if I am misunderstanding something.
The risk is if address G sends money to something like coinbase (or some other site that has your personal info) -> that would expose them as the sender of 2 coins to address D.
Evan can you clarify?
It doesn't work like this, it's far more complex. It seems when I follow a transaction that all the address' balance is spent including 10 DRK which is used for the mixing. I guess I don't follow. According to the whitepaper it works as I describe above (as far as I can tell). Do you have a link to the blockchain so I can take a look? |
|
|
|
|
|
Simcom
|
|
April 28, 2014, 02:16:10 PM |
|
He probably just takes note of when coins are sent from address A to B then back to A, he assumes A and B are the same person. |
|
|
|
|
GhostPlayer
Legendary
Offline
Activity: 1092
Merit: 1000
|
|
April 28, 2014, 02:16:58 PM |
|
Hello, this week we started a new Service called CoinMonitor.de User can see a Live Trading Chart for Cryptsy and Mintpal Orders. Fully dynamic refreshing. Mintpal and Crypts realtime refreshing orderbook and charts http://drk.coinmonitor.deHope you Like it !!! front-end shows up but no market feed. Osx 10.9 Safari |
|
|
|
|
|
Kai Proctor
|
|
April 28, 2014, 02:37:23 PM |
|
As far as the network is concerned, wallets do not exist, only addresses. Your wallet just holds all of your addresses and the private keys associated with them.
Back to your original question about timing analysis, look at the bottom figure on page 3 of the whitepaper. Each user will be placing the same # of coins into the pool (100 for example) - they will also provide a "spare change" address - coins that they don't want to spend but will come back to them. This is a NEW address that has not been associated with them up to this point.
So lets say 3 people each put in 100 coins
A -> 100 sending 2 coins to D
B -> 100 sending 24 coins to E
C -> 100 sending 56 coins to F
The outputs will be
2 coins to D
98 coins to G
24 coins to E
76 coins to H
56 coins to F
46 coins to I
Now from this we can determine that the current holder of address G sent two coins to D, but it's impossible to determine whether G belongs to the same person as A, B, or C.
A new problem arises though, in that the coins are now sitting on address G, and it can be determined that the holder of those coins sent 2 coins to address D. There would need to be another level of mixing to ensure that those 98 coins are washed another time - maybe Evan can clarify whether this mixing step happens or if I am misunderstanding something.
The risk is if address G sends money to something like coinbase (or some other site that has your personal info) -> that would expose them as the sender of 2 coins to address D.
Evan can you clarify?
It doesn't work like this, it's far more complex. It seems when I follow a transaction that all the address' balance is spent including 10 DRK which is used for the mixing. I guess I don't follow. According to the whitepaper it works as I describe above (as far as I can tell). Do you have a link to the blockchain so I can take a look? Send 1 DRK to an other wallet via DarkSend and try to follow the money using http://chainz.cryptoid.info/drk/The whitepaper talks about 100 DRK (10 DRK now) to the pool but it never says if 100 is the total output from the wallet  |
|
|
|
|
|
falsealarm_bf
|
|
April 28, 2014, 02:38:02 PM |
|
Hello, this week we started a new Service called CoinMonitor.de User can see a Live Trading Chart for Cryptsy and Mintpal Orders. Fully dynamic refreshing. Mintpal and Crypts realtime refreshing orderbook and charts http://drk.coinmonitor.deHope you Like it !!! front-end shows up but no market feed. Osx 10.9 Safari Same here on Win7 + Chrome |
|
|
|
|
|
coinpool_de
|
|
April 28, 2014, 02:40:07 PM |
|
Hello, this week we started a new Service called CoinMonitor.de User can see a Live Trading Chart for Cryptsy and Mintpal Orders. Fully dynamic refreshing. Mintpal and Crypts realtime refreshing orderbook and charts http://drk.coinmonitor.deHope you Like it !!! front-end shows up but no market feed. Osx 10.9 Safari Same here on Win7 + Chrome Now it works !!! |
|
|
|
|
GhostPlayer
Legendary
Offline
Activity: 1092
Merit: 1000
|
|
April 28, 2014, 02:49:05 PM |
|
so it is. Good job! Looks great!
EDIT: Order book is not updating, only trades ... working
|
|
|
|
|
|
falsealarm_bf
|
|
April 28, 2014, 02:59:45 PM |
|
Hello, this week we started a new Service called CoinMonitor.de User can see a Live Trading Chart for Cryptsy and Mintpal Orders. Fully dynamic refreshing. Mintpal and Crypts realtime refreshing orderbook and charts http://drk.coinmonitor.deHope you Like it !!! front-end shows up but no market feed. Osx 10.9 Safari Same here on Win7 + Chrome Now it works !!! Can you add Fib fans and retracements to this? |
|
|
|
|
TanteStefana
Full Member
Offline
Activity: 280
Merit: 100
The Future Of Work
|
|
April 28, 2014, 03:11:16 PM |
|
Wasn't meant to be... This is why I avoid humans. They'd rather get mad and call names. I don't know how to communicate with anyone who talks backwards and upside down, which is most people. So I generally jsut keep to myself.
LOL, welcome to the world of Autism Spectrum  That's my entire family! Ok, to answer: None of the things are recorded in the block chain. If you send from address X to address Y, you send the same amount as anyone else in the pool, then get "change" back with a completely new address A. Meanwhile, Address Y is informed to come pick up his money, but he picks it up with address B. And finally, since the blockchain doesn't know address B is the same wallet as address Y, the coin can't be found with getbalance. All the information that was used to make this transaction happen within the MasterNode's hosting computer is never saved to the blockchain, it is erased (never having been recorded) Eventually, if people want it this way, their account balance from any publicly used address will be 0 and only their wallet will know the real balance. Did that make any sense? |
|
|
|
TanteStefana
Full Member
Offline
Activity: 280
Merit: 100
The Future Of Work
|
|
April 28, 2014, 03:17:55 PM |
|
Try focusing on what isn't instead of what is, since my what is will not be seen in your perspective
Nah, I was foolish. I should know better than to try. Sometimes my optimism gets the best of me, but the hate of humanity is always right there to teach me the lesson, again... This is why I don't contribute; always get attacked for doing it. Fuck humans. Ah, come on, it's not so bad! Humans also forget easily, and you can just ignore those that got their panties in a bunch Hell, come on, crypto? Most of us are geeks if not aspies, LOL. Hell, even the "attacks" are probably from another aspie, LOL. You can talk to us Besides, NT's are so boring! (neurotypicals = "normal people") ROFL |
|
|
|
|
