Thanks HammerHedd, I think you're right. But I think there is something to what watuba said as well.
eduffield, does our wallet also "collect" using one of it's pre-created addresses that sits in reserve? (colored hoping to catch his attention, LOL)
When it's in the first iteration it would be paying to the address pool, the unused addresses in that pool specifically. I'm hoping that's what you were asking?
|
|
|
Adding Complete Anonymity to DarkSend As most of you are aware, we're currently building the decentralized foundation that that the future DarkSend implementation will sit on. DarkSend provides some basic anonymity currently, but this implementation shown above can be very robust, providing no way to determine the source or destination of money traveling through Darkcoin. It'll use 2 separate stages in the pooling system, one to gather enough inputs to add a level of anonymity and one to merge them back together. So the pay-ins and pay-outs end up being the same? That seems traceable? I'm sure I'm not understanding something... help please? You pay into a bucket of 5's, 10's, 50's, etc. The bucket pays out exact amounts. So you can't tell who's money is who's between step 2 and step 3, so when they actually pay out the trail is gone. How about this example, six people empty their wallets into a bucket, that bucket now has $2460 in it. A new group of 6 people come in take out their amounts. Who paid who?
|
|
|
Adding Complete Anonymity to DarkSend As most of you are aware, we're currently building the decentralized foundation that that the future DarkSend implementation will sit on. DarkSend provides some basic anonymity currently, but this implementation shown above can be very robust, providing no way to determine the source or destination of money traveling through Darkcoin. It'll use 2 separate stages in the pooling system, one to gather enough inputs to add a level of anonymity and one to merge them back together.
|
|
|
Any idea why DRK is dropping in price?
Will it rebound? Why is it not rising relative to btc?
is darksend working at the moment? last thing i heard was there are some ddos problems... I'm working on the next version as we speak. I'm adding some DDOS protection, among other improvements to stop attacks. After that we can do some more private beta testing sometime later this week to make sure everything is in order, then we'll release.
|
|
|
The DarkSend beta doesn't fork the blockchain, correct? I can still safely send/receive DRK using the 0.8.9 Mac wallet?
No, it's backwards compatible
|
|
|
So, apparently we've attracted some unwanted attention and someone is already DDOSing darksend. So we recommend you not using it until we get some antiDDOS code in and do some penetration testing. Who knew we were this popular?
|
|
|
Could you put this in your config and try again?
addnode=23.23.186.131
{ "state" : 2, "session_id" : 1023, "pooled_inputs" : 2, "pooled_outputs" : 0, "pooled_signatures" : 0, "my_transactions" : 1 } ... { "state" : 2, "session_id" : 1024, "pooled_inputs" : 0, "pooled_outputs" : 0, "pooled_signatures" : 0, "my_transactions" : 0 } getdarksendtxid 1023unknown_session_id I'll look into this tomorrow, I have some ideas of what could be happening. Thanks for the feedback
|
|
|
Could you put this in your config and try again? addnode=23.23.186.131
|
|
|
Results on Ubuntu appear to be the same. Using .01 DRK:{ "state" : 2, "session_id" : 1020, "pooled_inputs" : 2, "pooled_outputs" : 2, "pooled_signatures" : 0, "my_transactions" : 1 } ... { "state" : 2, "session_id" : 1021, "pooled_inputs" : 0, "pooled_outputs" : 0, "pooled_signatures" : 0, "my_transactions" : 0 } getdarksendtxid 1020unknown_session_id Using .02 DRK.{ "state" : 2, "session_id" : 1021, "pooled_inputs" : 1, "pooled_outputs" : 0, "pooled_signatures" : 0, "my_transactions" : 1 } ... { "state" : 2, "session_id" : 1022, "pooled_inputs" : 0, "pooled_outputs" : 0, "pooled_signatures" : 0, "my_transactions" : 0 } getdarksendtxid 1021incomplete Is this yours? http://explorer.darkcoin.io/tx/b9d3850d62e0a6c460e220713710fda602d5daea4771af1bbb397b35e3b6eb5f
|
|
|
The way DarkSend is implemented currently requires an single input larger than the amount you want to send. I haven't had time to completely fix this issue yet and am aware of it. So, sorry about the inconvenience, but you'll need to try smaller amounts until it can locate a single input larger than that size. It's in my list of stuff to fix.
Trying again.
Sent the smallest amount, .01 DRK.{ "state" : 2, "session_id" : 1018, "pooled_inputs" : 2, "pooled_outputs" : 0, "pooled_signatures" : 0, "my_transactions" : 1 } Check the pool information again.{ "state" : 2, "session_id" : 1019, "pooled_inputs" : 0, "pooled_outputs" : 0, "pooled_signatures" : 0, "my_transactions" : 0 } Try to get the transaction ID.getdarksendtxid 1018 unknown_session_id Thoughts? I tried to send 0.01 and it worked for me. I'm not sure why it's not showing the session, I'll look into that. Did it appear in your transactions?
|
|
|
I can't get DarkSend to work, been trying for a while.
I added eduffield's node address directly. addnode 50.19.116.123 add
I wait until the pool session changes from 1001. { "state" : 2, "session_id" : 1001, "pooled_inputs" : 0, "pooled_outputs" : 0, "pooled_signatures" : 0, "my_transactions" : 0 }
...
{ "state" : 2, "session_id" : 1016, "pooled_inputs" : 0, "pooled_outputs" : 0, "pooled_signatures" : 0, "my_transactions" : 0 }
I send some amount with DarkSend checked. { "state" : 2, "session_id" : 1016, "pooled_inputs" : 1, "pooled_outputs" : 0, "pooled_signatures" : 0, "my_transactions" : 1 }
The session never completes.
Minutes later I try again, this time transactions from others are there: { "state" : 2, "session_id" : 1017, "pooled_inputs" : 2, "pooled_outputs" : 0, "pooled_signatures" : 0, "my_transactions" : 0 }
I send an amount. It tells me insufficient funds, even though I have more than enough. Transaction fails.
Anyone see what I'm doing wrong?
The way DarkSend is implemented currently requires an single input larger than the amount you want to send. I haven't had time to completely fix this issue yet and am aware of it. So, sorry about the inconvenience, but you'll need to try smaller amounts until it can locate a single input larger than that size. It's in my list of stuff to fix.
|
|
|
DarkSend BETA v1 begins NOW!
http://www.darkcoin.io/downloads/DarkSendDocumentation.pdf There aren't many nodes running BETA on the network and it takes a few seconds for it to find one to get the state from. Run "getpoolinfo" in the console, when the session_id changes from 1001 you can use DarkSend.
|
|
|
Any thing deterministic violates the Byzantine General's solution of proof-of-work and can be defrauded. What will happen is the fraudsters will game this deterministic selection to put themselves in control. Understand that the fundamental genius of Satoshi's invention is that nothing can be known about the next block winner a priori. I explained in great detail why all non-PoW systems, e.g. proof-of-stake, are thus not secure. If you introduce determinism (e.g. a pseudorandom number generator is controlled by whom ever controls the initial seed) then you've lost that key attribute of PoW w.r.t. to your use in controlling the denial-of-service of enjoining transactions in the CoinJoin algorithm.
Ah, you're replying to something completely 100% different than what I said. I suppose it's super complicated. How about this, I'll write the code for this into DarkSend in the next few days. We'll do a public beta test on testnet and you can try to break it. I'll document it and make flow charts and everything so you can see how it works.
|
|
|
I just noticed that there's a problem with the BETA executables I just released. I'm working on new ones, will release soon.
If you downloaded the beta, just go back to using the stable client for the moment.
|
|
|
It appears the technical design of this DarkCoin is fundamentally flawed and can't be fixed.
There must be some proof that senders sent transactions for all peers on the network to verify before they can accept the block and begin working on the next block solution. Such proof must exist otherwise balances could be stolen by rogue peers.
Thus I must assume you are doing a CoinJoin-like proof for all senders that in that block. And I assume these proofs are transmitted with the block, even if you purge them later (using a proof-of-work chain such as in the mini block chain design).
The problem is that CoinJoin is subject to denial-of-service attack in that if any sender fails to sign in the second step, then no senders can send.
Thus CoinJoin can't scale to a larger number of senders joined. It works best with a few senders and the probability of denial-of-service (rogue sender) is low.
My proposed solution to this issue is to have a deterministic master and slave node based on each block that is solved. When entering the pool, a user will be required to make out a multisig 2 of 2 payment to master and slave nodes. So for example, User A wants to pay User B 50DRK, to enter the pool the user must provide the 2 of 2 multisig transaction for $1 to the master and slave. Only in the case that the user doesn't provide outputs or sign will that check be cashed and it must be redeemed by both parties. This process would be deterministic and tamper proof and would add great cost to messing with the network. Did you even read the CoinJoin thread carefully? Of course. There is a second insoluble flaw that CoinJoin does nothing to obscure IP address and thus you have no anonymity against powerful entities. There is no reliable anonymity possible in Bitcoin against the NSA+GCHQ+G20 tax and law enforcement. Forget it. There is anonymity in Bitcoin against other less powerful entities. First off Darkcoin uses a peer-to-peer protocol layer for DarkSend, so the inputs/outputs/signatures are broadcast at different stages then relayed through the network. It’s impossible to tell if you’re getting the input/output/signature from the one who originated it. So you seem to be implying that some government would have packet sniffing technology recording everything happening in Darkcoin. That’s pretty crazy and far fetched and completely invalidated if your traffic is coming through encrypted channels. However, the goal of Darkcoin is not to do illegal things, the goal is to make a “dark blockchain” , that is less visible and improves privacy. I think you're taking this overboard. If you're wanting to do something and you're scared the government is going to put the pieces together then you shouldn't be doing it, that's not what this was designed for. This whole arguement is a false dichotomy, we're not talking black and white here but shades of grey. Darkcoin still adds 95% to the privacy of users and in the future that will only increase. I don't have the perfect solution, but I have the best one that currently exists. Darkcoin’s anonymity is still worlds ahead of every other crypto, so I’m not sure what you’re complaining about.
|
|
|
|