whats new with BTCD? how are we hummin' along ?
~CfA~
Topic: BTCD is no more - page 224. (Read 1328507 times)
didnt check the thread 4 a long time.
whats new with BTCD? how are we hummin' along ?
~CfA~
whats new with BTCD? how are we hummin' along ?
~CfA~
the order in the .conf file doesnt matter
Good to know, but already found a better way to solve my problem 
.there should be different checksums for each binary download
if people are compiling their own, then the same version wont necessarily mean identical binaries due to differences in system build env
I used the version from the OP, as I haven't got a clue yet how to build it. Checksums were fine when I downloaded to a clean machine. Worked on the clean machine, and when finished created the SHA-256 checksum.if people are compiling their own, then the same version wont necessarily mean identical binaries due to differences in system build env
Uploaded on my main machine.
Downloaded on a 2nd clean machine, and still gave the same checksum. So I fugured all should be ok.
it is a good idea about the general version number. not sure of the best way to have that across all OS and daemon and wallets
I would say that every release should have the same version on all platforms. Usually the first 3 numbers are/should be used for external releases, the forth number for internal builds.
So everytime a version is released, update at least the 3rd number. Current version is 1.0.0.0, so next should be at least 1.0.1.0.
I might (but still need to test that a bit further) even need the 2nd one to go up to keep the updates working as intended. If so, I'll keep using a different version for the installer only, just like I did now.
Lets start with, please be carefull, only use at your own risk. I tried and used everything I could think of to keep this virus/malware free, but you never know.
Hopefully we'll see the version of the .exe of the wallet increase when a new version arrives. Until then I'll use a different version for the installer (0.1.0 for this first one).
This installer will:
- Backup the %appdata%\BitcoinDark to %appdata%\BitcoinDark__
Hopefully we'll see the version of the .exe of the wallet increase when a new version arrives. Until then I'll use a different version for the installer (0.1.0 for this first one).
This installer will:
- Backup the %appdata%\BitcoinDark to %appdata%\BitcoinDark_
So I featured BTCD as the "alt of the week" in the 1st episode of my show - Proof-of-Strip 
http://youtu.be/EQmKDP3tNOY
How'd I do? All feedback is welcomed
Now, if I could just get coinpayments to add it to their supported coin list...
http://youtu.be/EQmKDP3tNOY
How'd I do? All feedback is welcomed
Now, if I could just get coinpayments to add it to their supported coin list...
A few more questions about the wallet.
Is there a way to see if all lines of the BitcoinDark.conf are read without errors?
Is it ok to add a section head in the .conf like used in an ini file? [Settings] or something?
In the examples the .conf files all start with the rpcuser= and end with a list of the addnode=. Is it ok to mix up the sequence of the lines in the .conf? so start with a addnode= then the rpcuser= then another startnode= etc.
Is there a unique version number for each new version of the wallet?
if so, where can I find it?
if not, are you planning on doing that? It would be user friendly to have it, and I would like to try and use the same version numbers in the installer.
That's it for now.
Grtz,
Qwitnix
the order in the .conf file doesnt matterIs there a way to see if all lines of the BitcoinDark.conf are read without errors?
Is it ok to add a section head in the .conf like used in an ini file? [Settings] or something?
In the examples the .conf files all start with the rpcuser= and end with a list of the addnode=. Is it ok to mix up the sequence of the lines in the .conf? so start with a addnode= then the rpcuser= then another startnode= etc.
Is there a unique version number for each new version of the wallet?
if so, where can I find it?
if not, are you planning on doing that? It would be user friendly to have it, and I would like to try and use the same version numbers in the installer.
That's it for now.
Grtz,
Qwitnix
there should be different checksums for each binary download
if people are compiling their own, then the same version wont necessarily mean identical binaries due to differences in system build env
it is a good idea about the general version number. not sure of the best way to have that across all OS and daemon and wallets
Announcement
You can find on Google Play store my BitcoinDark Android price ticker app.
The app can be found by searching on the following:
- BTCD price
- BTCD price ticker
- BitcoinDark price
- BitcoinDark price ticker
- Price ticker
Or by going to the link: https://play.google.com/store/apps/details?id=nl.wiskunde.btcd&hl=nl
My BitcoinDark donation address: RPFLhFu2qCkNUs5UKKsjZJGFTWQaxeLLCv
Sincerely,
Wiskunde
You can find on Google Play store my BitcoinDark Android price ticker app.
The app can be found by searching on the following:
- BTCD price
- BTCD price ticker
- BitcoinDark price
- BitcoinDark price ticker
- Price ticker
Or by going to the link: https://play.google.com/store/apps/details?id=nl.wiskunde.btcd&hl=nl
My BitcoinDark donation address: RPFLhFu2qCkNUs5UKKsjZJGFTWQaxeLLCv
Sincerely,
Wiskunde
hello, please tell me where to download a working purse, wallet from the official site does not find an active network connection
It is working, but it takes about 30min or something to connect to network...
hello, please tell me where to download a working purse, wallet from the official site does not find an active network connection
https://mega.co.nz/#!ApVilbba!gO6mrhcvSdu-tOhjJ_8y39VhBzzuzSw-5ZMbbUDdVw0
From first post
hello, please tell me where to download a working purse, wallet from the official site does not find an active network connection
for anyone with wallet problem
copy your wallet file
cancel everything from the bitcoindark folder
C:\Users\\AppData\Roaming\BitcoinDark
redownload wallet and file conf in the first ann page
copy file conf and wallet file in bitcoindark
then start bitcoindark qt.exe
when is stuck at 64xxx or more block or something quit the program and restart it
copy your wallet file
cancel everything from the bitcoindark folder
C:\Users\
redownload wallet and file conf in the first ann page
copy file conf and wallet file in bitcoindark
then start bitcoindark qt.exe
when is stuck at 64xxx or more block or something quit the program and restart it
P.S. If anybody is on a Mac, can you try to build following the instructions on https://github.com/jl777/btcd
It is still a dev version and can be any state of bugginess, but the build process can be verified and this will help save time. So, the question is if it builds and links. you can run it too, but please dont keep it live as I am trying to keep a controlled test going
I'll try that, but might take me till the weekend since I'm short on time
I'm trying to build it now, but the first link in the readme-qt is not working: http://qt.nokia.com/downloads/sdk-mac-os-cpp
I'm guessing should be the same if I download this? http://qt-project.org/downloads
OK, got the new code debugged.
Now all three servers know each other's public privacyServer info and this is with minimal packet traffic, actually I think it is using the theoretical minimum. I am ignoring the IP leak for now, it will be much easier to scrub that when the system is more fully in place.
What is working now is that any public privacyServer will be able to contact any other and each such public privacyServer is actually a loopback server for a private node.
I will try to get the public to private comms working tomorrow and if all goes well, private to private. Once any private node can talk to any other, then I need to scrub or randomize the IP info leakage. have some ideas already, when I see all the private to private comm sequence I can verify if these ideas will work.
the hard part for tomorrow is to make an algo that allows private to private node comms without explicitly knowing any actual coinaddr<->ipaddr pairs
James
Now all three servers know each other's public privacyServer info and this is with minimal packet traffic, actually I think it is using the theoretical minimum. I am ignoring the IP leak for now, it will be much easier to scrub that when the system is more fully in place.
What is working now is that any public privacyServer will be able to contact any other and each such public privacyServer is actually a loopback server for a private node.
I will try to get the public to private comms working tomorrow and if all goes well, private to private. Once any private node can talk to any other, then I need to scrub or randomize the IP info leakage. have some ideas already, when I see all the private to private comm sequence I can verify if these ideas will work.
the hard part for tomorrow is to make an algo that allows private to private node comms without explicitly knowing any actual coinaddr<->ipaddr pairs
James
good job
+1! good to see you coding alot again
Good news. Do you need any additional help with testing remote nodes etc?
It's working now, but it appears that it needed some time to start syncing...
I'm trying to run a wallet on windows, but nothing is happening... where should bitcoindark.conf be located: in same folder as exe or in data folder..??
is there some specific network settings that should be done..?
is there some specific network settings that should be done..?
As far as I know, you should place the bitcoindark.conf in the C:\Users\
PS. I'm still working on the installer. Just need a bit more info and time.
I'm trying to run a wallet on windows, but nothing is happening... where should bitcoindark.conf be located: in same folder as exe or in data folder..??
is there some specific network settings that should be done..?
is there some specific network settings that should be done..?
is problem with withdrawing from cryptsy resolved? Or should I be prepared that my BTCD will stuck?
A few more questions about the wallet.
Is there a way to see if all lines of the BitcoinDark.conf are read without errors?
Is it ok to add a section head in the .conf like used in an ini file? [Settings] or something?
In the examples the .conf files all start with the rpcuser= and end with a list of the addnode=. Is it ok to mix up the sequence of the lines in the .conf? so start with a addnode= then the rpcuser= then another startnode= etc.
Is there a unique version number for each new version of the wallet?
if so, where can I find it?
if not, are you planning on doing that? It would be user friendly to have it, and I would like to try and use the same version numbers in the installer.
That's it for now.
Grtz,
Qwitnix
Is there a way to see if all lines of the BitcoinDark.conf are read without errors?
Is it ok to add a section head in the .conf like used in an ini file? [Settings] or something?
In the examples the .conf files all start with the rpcuser= and end with a list of the addnode=. Is it ok to mix up the sequence of the lines in the .conf? so start with a addnode= then the rpcuser= then another startnode= etc.
Is there a unique version number for each new version of the wallet?
if so, where can I find it?
if not, are you planning on doing that? It would be user friendly to have it, and I would like to try and use the same version numbers in the installer.
That's it for now.
Grtz,
Qwitnix
OK, got the new code debugged.
Now all three servers know each other's public privacyServer info and this is with minimal packet traffic, actually I think it is using the theoretical minimum. I am ignoring the IP leak for now, it will be much easier to scrub that when the system is more fully in place.
What is working now is that any public privacyServer will be able to contact any other and each such public privacyServer is actually a loopback server for a private node.
I will try to get the public to private comms working tomorrow and if all goes well, private to private. Once any private node can talk to any other, then I need to scrub or randomize the IP info leakage. have some ideas already, when I see all the private to private comm sequence I can verify if these ideas will work.
the hard part for tomorrow is to make an algo that allows private to private node comms without explicitly knowing any actual coinaddr<->ipaddr pairs
James
Now all three servers know each other's public privacyServer info and this is with minimal packet traffic, actually I think it is using the theoretical minimum. I am ignoring the IP leak for now, it will be much easier to scrub that when the system is more fully in place.
What is working now is that any public privacyServer will be able to contact any other and each such public privacyServer is actually a loopback server for a private node.
I will try to get the public to private comms working tomorrow and if all goes well, private to private. Once any private node can talk to any other, then I need to scrub or randomize the IP info leakage. have some ideas already, when I see all the private to private comm sequence I can verify if these ideas will work.
the hard part for tomorrow is to make an algo that allows private to private node comms without explicitly knowing any actual coinaddr<->ipaddr pairs
James
good job
+1! good to see you coding alot again
OK, got the new code debugged.
Now all three servers know each other's public privacyServer info and this is with minimal packet traffic, actually I think it is using the theoretical minimum. I am ignoring the IP leak for now, it will be much easier to scrub that when the system is more fully in place.
What is working now is that any public privacyServer will be able to contact any other and each such public privacyServer is actually a loopback server for a private node.
I will try to get the public to private comms working tomorrow and if all goes well, private to private. Once any private node can talk to any other, then I need to scrub or randomize the IP info leakage. have some ideas already, when I see all the private to private comm sequence I can verify if these ideas will work.
the hard part for tomorrow is to make an algo that allows private to private node comms without explicitly knowing any actual coinaddr<->ipaddr pairs
James
Now all three servers know each other's public privacyServer info and this is with minimal packet traffic, actually I think it is using the theoretical minimum. I am ignoring the IP leak for now, it will be much easier to scrub that when the system is more fully in place.
What is working now is that any public privacyServer will be able to contact any other and each such public privacyServer is actually a loopback server for a private node.
I will try to get the public to private comms working tomorrow and if all goes well, private to private. Once any private node can talk to any other, then I need to scrub or randomize the IP info leakage. have some ideas already, when I see all the private to private comm sequence I can verify if these ideas will work.
the hard part for tomorrow is to make an algo that allows private to private node comms without explicitly knowing any actual coinaddr<->ipaddr pairs
James
P.S. also today I got caught up in the whole BCX XMR thing which was quite distracting as I was in the loop of all the PMs
What happened with Monero? It just tanked.
Edit: found it. https://bitcointalksearch.org/topic/delete-789978
BBR affected too?
plz let me know.
at this point anybody that says they know, is wrong
my sense is that many things have to be done at once and CZ already fixed a key part of this whole attack vector, but anonymint's math stuff makes my head hurt, so I think it is unlikely even for XMR and even more unlikely for BBR, but it all depends on the undecipherable (to me) math
Jump to: