getblocktemplate stopped working on the testnet. I get this error message error: {"code":-1,"message":"CreateNewBlock() : ConnectBlock failed"} Any idea what's going on? BTW, I'm working on masternode support for p2pool. This is fixed, just download the new client or recompile
|
|
|
Think about an update feature for the wallet please. Yeah that would be nice.
|
|
|
When trying to do a transfer with DarkSend I get the following error: darkSend Satus => ERROR : masternode switched, please resubmit
After that I try it again and I get errors: Couldn't find a confirmed unspend output equal to 10DRK. This shouldn't happen, please report to developers.
and Error: Transaction creation failed! Am I doing something wrong or is this is a bug? Please PM eduffield. In case it's a bug, he needs to know This means the masternode switched while you were waiting for a match (it happens every 25 minutes on average). Currently the client isn't smart enough to retry, but I'll have this fixed in RC3, plus lots of more neat stuff that I'm keeping secret
|
|
|
getblocktemplate stopped working on the testnet. I get this error message error: {"code":-1,"message":"CreateNewBlock() : ConnectBlock failed"} Any idea what's going on? BTW, I'm working on masternode support for p2pool. Looking into it. Something is up
|
|
|
Have you noticed this ? Timed Hadrfork Set ntp https://github.com/darkcoinproject/darkcoin/blob/master/src/protocol.cpp#L16-L35// The message start string is designed to be unlikely to occur in normal data. // The characters are rarely used upper ascii, not valid as UTF-8, and produce // a large 4-byte int at any alignment. // Public testnet message start static unsigned char pchMessageStartTestOld[4] = { 0xfc, 0xc1, 0xb7, 0xdc }; static unsigned char pchMessageStartTestNew[4] = { 0xce, 0xe2, 0xca, 0xff }; static unsigned int nMessageStartTestSwitchTime = 1398869551+(60*5);
// Darkcoin message start (switch from Litecoin's) static unsigned char pchMessageStartLitecoin[4] = { 0xfb, 0xc0, 0xb6, 0xdb }; static unsigned char pchMessageStartDarkcoin[4] = { 0xbf, 0x0c, 0x6b, 0xbd }; static unsigned int nMessageStartSwitchTime = 1400094580; //Wed, 14 May 2014 19:09:40 GMT
void GetMessageStart(unsigned char pchMessageStart[], bool fPersistent) { if (fTestNet) memcpy(pchMessageStart, (fPersistent || GetAdjustedTime() > nMessageStartTestSwitchTime)? pchMessageStartTestNew : pchMessageStartTestOld, sizeof(pchMessageStartTestNew)); else memcpy(pchMessageStart, (fPersistent || GetAdjustedTime() > nMessageStartSwitchTime)? pchMessageStartDarkcoin : pchMessageStartLitecoin, sizeof(pchMessageStartDarkcoin)); }
From Litecoin { 0xfb, 0xc0, 0xb6, 0xdb } to Darkcoin { 0xbf, 0x0c, 0x6b, 0xbd }
|
|
|
Masternode question: When I start the masternode with darkcoind masternode start mypassphrase can I then shut the terminal window? I am worried about the wallet passphrase being there in plain sight. Plus what happens if/when my local box goes offline for whatever reason, does the masternode persist? Apologies for noobness at this. And is there a site that lists masternodes, so I can see from elsewhere that it's up and running? Thanks. This works on linux: darkcoind masternode start `head -1` Type your password on the next line. If you do it this way the history will show 'head -1' instead of your password.
|
|
|
In regards to the pools of 10, 100 and 1000DRK, I believe the best solution is to get rid of the pools altogether and just require than the inputs to the pool be larger than the outputs.
For example: - John adds 102DRK to the pool, sends 101DRK to Lisa and receives back 1DRK as change. - Joe adds 153DRK to the pool, sends 73DRK to Mary and receives back 80DRK as change.
Change will still be denominated, so the 80 DRK would come back as 50,20 and 10DRK.
|
|
|
We were just contacted (again) by Wired.com, they're going to call this weekend to review quotes then the article is set to go out Monday!
|
|
|
Remember this article about Dark Wallet? http://www.wired.com/2014/04/dark-wallet/
Andy Greenberg kept seeing "Darkcoin" mentioned over and over again in all of the comments, so he gave me a ring yesterday to see what all of the fuss was about. He's writing up another article about Dark Wallet and he's going to include some info about us as well. Should go out tonight!
|
|
|
Here's the new schedule for development:
- RC2 (masternode payments, DGW3) : May 14th - RC3 (1000 DRK limit and denominated change) : May 21st - After this, I'll find someone to vet the code and open source. - RC4 (Bugs, security issues) - Testing, then opensource
|
|
|
I spent a fair amount of time thinking about the discussion with dime, humanitee, luigi1111, camosoul and others yesterday about the anonymity of Darksend. I suspected that the logic behind darksend as currently implemented was not sound, and I thought it would be best to determine how exactly darksend was working, and do an in-depth analysis of a mixing cycle and the transactions that follow mixing.
...
Best, Sim
Wow! This is great. About 400+ pages ago I talked about having a different kind of pool for change outputs only. Put in all of your change outputs and you'll get new fresh clean inputs of 10DRK. The client could automatically do this after each darksend, which would also get you new inputs for the next round. I'm currently embedded in patching stratum and p2pool to support the masternode payments, which is why I haven't been around. It takes a lot of work to make something so different from anything else out there, dare I say, revolutionary? On second thought, I'm not sure this solves the problem. My understanding is that you want to accumulate the dirty change in the wallet until it breaches a certain amount (say 10 for example), then it is washed in a "change only" wash with a bunch of "10" transactions. The problem I see is that even the clean coins could be linked to the original transaction. Just to explain: John darksends 2 coins from A to C, gets 8 back as change on address X a few days later.. John darksends 8 coins from B to D, gets 2 back as change on address Y Y+X are submitted to the change mixing pool (10 coins), and come out "clean" at address Z. The problem is that the coins at address Z are not clean really, they are "suspect", they could have possibly participated in any darksends that generated the dirty coins that composed the "change washing" pool. Now when Johns wants to spend coins from A, B, and Z in the same transaction. So if John wants to send coins from A+B+Z in one transaction, the fact that Z participated in a pool that contained X and Y is enough to expose A and B as the original participants in the darksend transaction. Really it leaves us at the same position that we were at previously after the original darksends. I hope that made sense. I came up with a way better solution to this issue than my previous idea. Plus it's already supported by DarkSend, I'll just enforce it in RC3 John darksends 2.5 coins from A to C, gets 7.5 back as change on address X, Y, V, Z (X = 5DRK, Y = 1DRK, V = 1DRK, Z=0.5DRK ) Joe darksends 3 coins from E to G, gets 7 back as change on address W, K, J (W = 5DRK, K = 1DRK, J = 1DRK) Suzie darksends 3.5 coins from K to Q, gets 6.5 back as change on address F, G, H (F = 5DRK, G = 1DRK, H = 0.5DRK) Change is denominated into units of 5, 1, 0.5, 0.25, 0.1, 0.05, and 0.01 DRK. I'll introduce the precision limitation back again of 0.01DRK. So if you get 7.5 DRK of change back, you'll end up with 5DRK+1DRK+1DRK+0.5DRK. You could still possible do taint analysis on denominations only used once, but this would be solved with multiple rounds in DarkSend.
|
|
|
John darksends 2 coins from A to C, gets 8 back as change on address X a few days later.. John darksends 8 coins from B to D, gets 2 back as change on address Y
Joe darksends 3 coins from E to G, gets 7 back as change on address W a few days later.. Joe darksends 1 coins from F to H, gets 9 back as change on address Z
Suzie darksends 3 coins from K to Q, gets 7 back as change on address S a few days later.. Suzie darksends 1 coins from J to R, gets 9 back as change on address T
Now, we make a pool with X+Y+X1+W+Z+W1+S+T+S1.
Pool total output == 60DRK
X+Y+X1 = 10DRK + 10DRK W+Z+W1 = 10DRK + 10DRK S+T+S1 = 10DRK + 10DRK
Make sense?
My mind just exploded. What are X1, S1, and W1? X will always be less than 10DRK, therefore we need another input to bring it to 10DRK total. This way no one can tell who is receiving which inputs, thus cleaning them in the inverse way DarkSend works. Checkout my post above again, I modified it a bit. Make sense?
|
|
|
I spent a fair amount of time thinking about the discussion with dime, humanitee, luigi1111, camosoul and others yesterday about the anonymity of Darksend. I suspected that the logic behind darksend as currently implemented was not sound, and I thought it would be best to determine how exactly darksend was working, and do an in-depth analysis of a mixing cycle and the transactions that follow mixing.
...
Best, Sim
Wow! This is great. About 400+ pages ago I talked about having a different kind of pool for change outputs only. Put in all of your change outputs and you'll get new fresh clean inputs of 10DRK. The client could automatically do this after each darksend, which would also get you new inputs for the next round. I'm currently embedded in patching stratum and p2pool to support the masternode payments, which is why I haven't been around. It takes a lot of work to make something so different from anything else out there, dare I say, revolutionary? On second thought, I'm not sure this solves the problem. My understanding is that you want to accumulate the dirty change in the wallet until it breaches a certain amount (say 10 for example), then it is washed in a "change only" wash with a bunch of "10" transactions. The problem I see is that even the clean coins could be linked to the original transaction. Just to explain: John darksends 2 coins from A to C, gets 8 back as change on address X a few days later.. John darksends 8 coins from B to D, gets 2 back as change on address Y Y+X are submitted to the change mixing pool (10 coins), and come out "clean" at address Z. The problem is that the coins at address Z are not clean really, they are "suspect", they could have possibly participated in any darksends that generated the dirty coins that composed the "change washing" pool. Now when Johns wants to spend coins from A, B, and Z in the same transaction. So if John wants to send coins from A+B+Z in one transaction, the fact that Z participated in a pool that contained X and Y is enough to expose A and B as the original participants in the darksend transaction. Really it leaves us at the same position that we were at previously after the original darksends. I hope that made sense. John darksends 2 coins from A to C, gets 8 back as change on address X Joe darksends 3 coins from E to G, gets 7 back as change on address W Suzie darksends 3 coins from K to Q, gets 7 back as change on address S Now, we make a pool with X+X1+W+W1+S+S1. Pool total output == 30DRK X+X1 = 10DRK W+W1 = 10DRK S+S1 = 10DRK X will always be less than 10DRK, there for we need another input to bring it to 10DRK total. This way no one can tell who is receiving which inputs, thus cleaning them in the inverse way DarkSend works. Make sense?
|
|
|
I spent a fair amount of time thinking about the discussion with dime, humanitee, luigi1111, camosoul and others yesterday about the anonymity of Darksend. I suspected that the logic behind darksend as currently implemented was not sound, and I thought it would be best to determine how exactly darksend was working, and do an in-depth analysis of a mixing cycle and the transactions that follow mixing.
...
Best, Sim
Wow! This is great. About 400+ pages ago I talked about having a different kind of pool for change outputs only. Put in all of your change outputs and you'll get new fresh clean inputs of 10DRK. The client could automatically do this after each darksend, which would also get you new inputs for the next round. I'm currently embedded in patching stratum and p2pool to support the masternode payments, which is why I haven't been around. It takes a lot of work to make something so different from anything else out there, dare I say, revolutionary?
|
|
|
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
|
|
|
Nope, they don't need to communicate. The masternode with the money just needs to sign a message with it. That node broadcasts it to the whole network. After than the secondary masternode is good to go.
Could you disconnect the masternode with the money from the network and even send it to cold storage once the secondary masternode is in the network? that's the whole point of it Yeah, I basically wanted an official confirmation Nope, both need to be online. At least for now.
|
|
|
|