BTCD is no more

[PondSea]

For those wanting to build the QT wallet on linux, please make sure to read down to the part about build configuration options....
https://github.com/laowais/bitcoindark/blob/master/doc/readme-qt.rst

If you don't have miniupnp installed then you will have to build without UPNP support or it wont compile..
qmake USE_UPNP=-

Alternatively you can install miniupnp before building.  On Ubuntu this can be done by installing the libminiupnpc-dev package...
sudo apt-get install libminiupnpc-dev

Thank you Paul.

I have BitcoinDark-qt now but how do i run it? 

[1713433210]

1713433210

[1713433210]

1713433210

[1713433210]

1713433210

[1713433210]

1713433210

[1713433210]

1713433210

[1713433210]

1713433210

[jl777]

Some good progress. Along the way we made a few bugs, but now all is testing well with the existing blockchain.

There are 4 changes I have asked for that will complete the core work needed from BTCDdev and now the builds should be much easier with Mac and even Windows, so the BTCD daemon is looking very close.

I drastically simplified the internal complexity by gutting the TCP totally and switching to a UDP only statemachine approach. Each node will have a separate state machine relative to every other node. So all the complexity will be the specific state differences. As long as each state machine is solid, then the entire peer to peer set of states will be solid.

The removal of TCP removes a Dos attack vector of tying up the sockets on a node. With UDP you will need to saturate its entire connection with junk traffic. Due to the strong nested onion encryption, this is really the only practical attack vector that I can think of. [Other than swat teams confiscating all the nodes!]

I also realized that since it is not possible to know when the final layer of the onion has been peeled, the fact that you are even talking to a specific privacyServer is actually the bigger info leak than anything the privacyServer can determine about you! So, I am switching to routing via randomly selected privacyServer for all traffic.

Over the months I had scrubbed all the info that can be gleaned from the privacyServer, so this actually simplifies things even more as there are no special privacyServers for each node.

James

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

[paulthetafy]

For those wanting to build the QT wallet on linux, please make sure to read down to the part about build configuration options....
https://github.com/laowais/bitcoindark/blob/master/doc/readme-qt.rst

If you don't have miniupnp installed then you will have to build without UPNP support or it wont compile..
qmake USE_UPNP=-

Alternatively you can install miniupnp before building.  On Ubuntu this can be done by installing the libminiupnpc-dev package...
sudo apt-get install libminiupnpc-dev

Thank you Paul.

I have BitcoinDark-qt now but how do i run it? 

The easy bit!  from your shell you can run
./BitcoinDark-qt &
(the & means that it runs in a new process so you dont need to leave the shell open afterwards)

[PondSea]

Man this is harder than i thought lol.

root@Server:~/bitcoindark# ./BitcoinDark-qt &
[1] 13045
root@Server:~/bitcoindark# QXcbConnection: Could not connect to display

I will take you up on your offer in irc Paul

#dumbass123

[futurist]

Man this is harder than i thought lol.

root@Server:~/bitcoindark# ./BitcoinDark-qt &
[1] 13045
root@Server:~/bitcoindark# QXcbConnection: Could not connect to display

I will take you up on your offer in irc Paul

#dumbass123

No centralized organization can provide this level of support. 

[cloudboy]

Man this is harder than i thought lol.

root@Server:~/bitcoindark# ./BitcoinDark-qt &
[1] 13045
root@Server:~/bitcoindark# QXcbConnection: Could not connect to display

I will take you up on your offer in irc Paul

#dumbass123

Are you on a server with gui support?

If you are on a command line only, use BitcoinDarkd

[PondSea]

Man this is harder than i thought lol.

root@Server:~/bitcoindark# ./BitcoinDark-qt &
[1] 13045
root@Server:~/bitcoindark# QXcbConnection: Could not connect to display

I will take you up on your offer in irc Paul

#dumbass123

Are you on a server with gui support?

If you are on a command line only, use BitcoinDarkd

Only on command line but i cannot see that file, I think i may just install a GUI on this server but security wise not very good

[cloudboy]

Man this is harder than i thought lol.

root@Server:~/bitcoindark# ./BitcoinDark-qt &
[1] 13045
root@Server:~/bitcoindark# QXcbConnection: Could not connect to display

I will take you up on your offer in irc Paul

#dumbass123

Are you on a server with gui support?

If you are on a command line only, use BitcoinDarkd

Only on command line but i cannot see that file, I think i may just install a GUI on this server but security wise not very good

If you are only on a command line, then you cannot run a BitcoinDark-qt. Run BitcoinDarkd, it runs just as well.

cd src/
make -f makefile.unix

[paulthetafy]

Note to self:  When building a new trading bot, do not let it loose with all of your coins until it is fully tested!!

I now have even more BTCD.  not a terrible thing.

[jl777]

Would the community be willing to run 100+ privacyServer VPS?

I think I figured out how to delink the IP address from the account even to the privacyServer!

What that means is that it could be possible to be communicate with any other node on the SuperNET, but neither knowing the IP address of the other, nor would any privacyServer know this either.

Sounds crazy, but using probabilistic routing (just thought of this while rewriting the UDP code) for each layer of the onion route it is not even known which of the N nodes you send the packet to is the one that will forward it on. This does increase the overall UDP packet traffic by something like 4, but maybe it can be reduced to 1.5 if we accept some delays and retries.

I didnt think I could remove even the knowledge of the IPaddress/account linkage between a node and its privacyServer, but I think it will work and with actually a much simpler internal structure and making everything symmetrical.

So, with the IP details not even required this allows random selection of the privacyServers to use without worry that they are controlled by an attacker. Even if it is, they wont know the packet originated from your node.

This however would require about 100 VPS to handle the expected load and their IP addresses need to be published as otherwise nobody would know who to contact in the first place without some large overhead of random discovery packet sendings.

James

P.S. we can certainly start with a smaller number like 10 and see how it handles the load.

[jl777]

Would the community be willing to run 100+ privacyServer VPS?
P.S. we can certainly start with a smaller number like 10 and see how it handles the load.

Whatever is necessary. A lot of hosting companies offer a free trial. What are the minimum requirements (CPU, RAM) and how long do you need them (3 days, 2 weeks, 1 month)?

CPU is not so important, the bandwidth would probably be the most important and this is dependent on the number of nodes. it would be an indefinite need assuming it works. These nodes could also be sources for aged telepods and other handy things to have a community run set of servers that is not tied to any specific person

James

[PondSea]

Would the community be willing to run 100+ privacyServer VPS?
P.S. we can certainly start with a smaller number like 10 and see how it handles the load.

Whatever is necessary. A lot of hosting companies offer a free trial. What are the minimum requirements (CPU, RAM) and how long do you need them (3 days, 2 weeks, 1 month)?

CPU is not so important, the bandwidth would probably be the most important and this is dependent on the number of nodes. it would be an indefinite need assuming it works. These nodes could also be sources for aged telepods and other handy things to have a community run set of servers that is not tied to any specific person

James

Given say $10 a month per server, $1000 is peanuts.

[DaiBoyCookie]

Hi Guys
First time poster on this thread.
I'm trying to find a forum for bitcoindark multipool mining, does one exist?
 

[cryptillian]

Hi Guys
First time poster on this thread.
I'm trying to find a forum for bitcoindark multipool mining, does one exist?
 

on page 1 there are multipool listings enjoy

[BTCDDev]

Would the community be willing to run 100+ privacyServer VPS?
P.S. we can certainly start with a smaller number like 10 and see how it handles the load.

Whatever is necessary. A lot of hosting companies offer a free trial. What are the minimum requirements (CPU, RAM) and how long do you need them (3 days, 2 weeks, 1 month)?

CPU is not so important, the bandwidth would probably be the most important and this is dependent on the number of nodes. it would be an indefinite need assuming it works. These nodes could also be sources for aged telepods and other handy things to have a community run set of servers that is not tied to any specific person

James

I'm sure the dev team can use our continuing donation fund to pay for a large amount of VPS systems.

[id10tothe9]

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

[crackfoo]

Hi Guys
First time poster on this thread.
I'm trying to find a forum for bitcoindark multipool mining, does one exist?
 

You can find the BTCD multipool links in my signature as well as a link to the thread on this forum.

[crackfoo]

Would the community be willing to run 100+ privacyServer VPS?
P.S. we can certainly start with a smaller number like 10 and see how it handles the load.

Whatever is necessary. A lot of hosting companies offer a free trial. What are the minimum requirements (CPU, RAM) and how long do you need them (3 days, 2 weeks, 1 month)?

CPU is not so important, the bandwidth would probably be the most important and this is dependent on the number of nodes. it would be an indefinite need assuming it works. These nodes could also be sources for aged telepods and other handy things to have a community run set of servers that is not tied to any specific person

James

I can provide a VPS worth ~$100 month. Unsure how many privacyServer would be able to run on it but willing to load it up.

[id10tothe9]

Would the community be willing to run 100+ privacyServer VPS?
P.S. we can certainly start with a smaller number like 10 and see how it handles the load.

Whatever is necessary. A lot of hosting companies offer a free trial. What are the minimum requirements (CPU, RAM) and how long do you need them (3 days, 2 weeks, 1 month)?

CPU is not so important, the bandwidth would probably be the most important and this is dependent on the number of nodes. it would be an indefinite need assuming it works. These nodes could also be sources for aged telepods and other handy things to have a community run set of servers that is not tied to any specific person

James

is this something that can be done on a laptop from home? I have a pretty decent connection but would need some instructions on what to do.

[crackfoo]

Would the community be willing to run 100+ privacyServer VPS?

I think I figured out how to delink the IP address from the account even to the privacyServer!

What that means is that it could be possible to be communicate with any other node on the SuperNET, but neither knowing the IP address of the other, nor would any privacyServer know this either.

Sounds crazy, but using probabilistic routing (just thought of this while rewriting the UDP code) for each layer of the onion route it is not even known which of the N nodes you send the packet to is the one that will forward it on. This does increase the overall UDP packet traffic by something like 4, but maybe it can be reduced to 1.5 if we accept some delays and retries.

I didnt think I could remove even the knowledge of the IPaddress/account linkage between a node and its privacyServer, but I think it will work and with actually a much simpler internal structure and making everything symmetrical.

So, with the IP details not even required this allows random selection of the privacyServers to use without worry that they are controlled by an attacker. Even if it is, they wont know the packet originated from your node.

This however would require about 100 VPS to handle the expected load and their IP addresses need to be published as otherwise nobody would know who to contact in the first place without some large overhead of random discovery packet sendings.

James

P.S. we can certainly start with a smaller number like 10 and see how it handles the load.

I could provide up to 6 or 7 VPS instances for initial testing and if feasible, longterm as well.