So does this custom DDNS server exist at all? And if so is it free open source?
-MarkM-
Yes it exits. No idea about the code availability.. I dont think all of it is publicly available , at least it was not last I checked. On the other hand, it would not be too hard to create, just a matter of programming as they say. Or in other words time. Also if we do this, we should probably also stash the location of the hosts to find receiver files into it. |
|
|
|
Here is the really cool part, you can use bitcoin offline wallets for devcoin. They use the same addresses/private keys. So you can send dvc to a btc address. Then recover them with the private key of that wallet on a devcoin client later. Attention, this function does not work properly, when you try to import a private key to devcoind from bitcoind you end up with an import error! Could be because bitcoin now supports compressed keys by default and devcoin does not have support for them. |
|
|
|
I do not know what exactly a DNS seed is, what exactly it is that I have to set up at the DNS-provider, in the zone-records of the domains I want to put DNS seeds into.
Once I have all those set up I can look into putting them into the code if our old caode even has DNS seed support in it.
(If it doesn't I can just find IP addresses to put into the last resort IP addresses list that is in the code.)
-MarkM-
The DNS seed is meant to talk to a custom DDNS server that keeps a list of active live seen nodes, and sends them on request to the clients, picking 10 or so to send. It is meant to replace the IRC peer finding. I already have put in the two valid hard coded seeds posted here so far into the code I am doing... so you can just pick that up. Now if we can only actually chat on irc sometime like I have been trying to for the past few days... seems we just dont keep the same schedule. |
|
|
|
I do not know what exactly a DNS seed is, what exactly it is that I have to set up at the DNS-provider, in the zone-records of the domains I want to put DNS seeds into.
Once I have all those set up I can look into putting them into the code if our old caode even has DNS seed support in it.
(If it doesn't I can just find IP addresses to put into the last resort IP addresses list that is in the code.)
-MarkM-
https://en.bitcoin.it/wiki/NetworkBootstrapping You choose which peers to connect to by sorting your address database by the time since you last saw the address and then adding a bit of randomization. Bitcoin has three methods of finding peers. Addr The addr messages described above create an effect similar to the IRC bootstrapping method. You know reasonably quickly whenever a peer joins, though you won't know for a while when they leave. Bitcoin comes with a list of addresses known as "seed nodes". If you are unable to connect to IRC and you've never connected to the network before, the client will update the address database by connecting to one of the nodes from this list. The -addnode command line option can be used to manually add a node. The -connect option can force bitcoin to connect only to a specific node. DNS Bitcoin looks up the IP Addresses of several host names and adds those to the list of potential addresses. This is the default seeding mechanism, as of v0.6.x and later. IRC As-of version 0.6.x of the Bitcoin client, IRC bootstrapping is no longer enabled by default. The information below is accurate for most versions prior. Bitcoin joins a random channel between #bitcoin00 and #bitcoin99 on irc.lfnet.org. Your nick is set to an encoded form of your IP address. By decoding all the nicks of all users on the channel, you get a list of all IP addresses currently connected to Bitcoin. For hosts that cannot make outbound connections on port 6667, the lfnet servers are also listening on port 7777. Now imagine all the words bitcoin, say devcoin  Except that does not match the code. Seed nodes are not round robin dns either btw. There are two types of seed nodes, one of which must be a fixed ip address, which is what we can easily support in the code right now. The other is a custom DDNS server (that is what the dns seeds code it meant to talk to, not round robin dns for a single node). |
|
|
|
The receiver files are cached, it only downloads new receiver files when it switches blocks. Assuming a bad case scenario, where two out of five files time out, wasting a minute each, that would be two minutes per block; this times 22 rounds would be 44 minutes. That is the bad case for the startup, for example if it is used once a month, that would be an extra 2 minutes per month.
If in future at say round 30 we had fifteen files, and say seven were down, that would be seven minutes per block, times 30 rounds would be a 210 minute (3.5 hours) start up. This bad case is still much less than the average bitcoin block chain download time today. The extra protection against nodes being down or ddosed is worth the extra time.
I am thinking about the start up time for a new user today, today I have been getting a 70 second time out on the irc , then after that there would be a 10 second time out on each bad site. People may quit and restart if they don't get some feedback sooner then this would allow for in worst cases. If we just added two more reliable nodes and kept your github we should be fine.
The issue is, which nodes will always be reliable? Github was reliable when we developed the program, and any node can be ddosed.
Indeed. That is why in an earlier message I was suggesting we consider moving the finding of the receiver_N.csv flie sources to dns. This would make it so the reciever files would have no need for the hardcoded sites that could become bad later. |
|
|
|
http://galaxies.mygamesonline.org/receiver.csv
http://devcoinpool.btc-music.com/receiver/receiver_22.csv
http://devcoinblockexplorer.info/receiver/receiver.csv
http://devtome.com/files/receiver.csv
http://devcoin.darkgamex.ch/receiver.csv
Then the file admins will upload all the replaced files to their sites. Then the code to get the first file in receiver.h will be changed from: stepText = getInternetText("https://raw.github.com/Unthinkingbit/charity/master/receiver_0.csv");
to something like: peerText = string("http://galaxies.mygamesonline.org/receiver.csv\n");
peerText += string("http://devcoinpool.btc-music.com/receiver/receiver.csv\n");
peerText += string("http://devcoinblockexplorer.info/receiver/receiver.csv\n");
peerText += string("http://devtome.com/files/receiver.csv\n");
peerText += string("http://devcoin.darkgamex.ch/receiver.csv\n");
stepText = getCommonOutputByText(peerText, string("0");
Once that is done, devcoin will be able to bootstrap even if 2 out of 5 sites are down. In future roughly every time we double the number of file administrators, we'll rewiden the tree. Unless/until the curl code is changed to use curl_multi, I think for the bootstrapping, we will get better results with 3 reliable servers listed and gain almost nothing but slower start up speed by adding more especially if one or more ever go down in the furture as we would then be waiting for each to time out. If we just added two more reliable nodes and kept your github we should be fine. |
|
|
|
I also dont get what is diff between tenebrix and ltc source code, seems its nearly same. Mark you want someone to restart tenebrix under some new name? tenebrix was the first scrypt coin. ltc copied it from tenebrix (sort of, could be said it copied it from fairbrix which in turn copied it from tenebrix). |
|
|
|
OK... thanks for that...
Just downloaded Armory.. It says I don't have the software? Oh, you mean the main client thing?
The thing that takes forever to try to catch up with the entire history of bitcoin, and then says there was an error and starts all over again? THAT software?
Oh boy..
I was starting to think I was the only one seeing this! I am getting real tempted to go back to an older version that did not have this problem of always needing to reindex the blockchain. https://bitcointalk.org/index.php?topic=184125.0 |
|
|
|
|
Hmm.. how does this raise the coins to pay the dividends? It sounds more like it is for giving out bounties? The first post just ore or less seems a writeup on devcoin itself, not the fund.
|
|
|
|
if you need a "node" always online then pm me, i can setup one node to stay 24/24 online
Please make one, you'll get devcoins for it for as long as you maintain it. If you have any questions about what is required, ask Mark. If someone is going to do this as a fresh install of devcoins, please pm me for my changes to help test it. It already has Mark's node coded in as a seed now, so it can run without irc on, which can be useful as a lot of places ban the use of IRC in their AUP. |
|
|
|
... We used to have a bounty for seed nodes, but it was closed because we thought there were enough seed nodes. Since there aren't I suggest a bounty of 1/5 of a share ongoing, for the next five seed nodes.
I have set up one at 174.34.170.240 It may be a bit flakey for the next few days as I am also using it for testing so stopping and restarting it often. It will however get hardcoded into the client as part of my changes and run 24/7 at that point. How much is 1/5 of a share anyway in terms of coins right now? the IRC is flakely
What could be done to fix that? Not sure off hand. Just having working seed nodes will at least stop that from being a showstopper. Long term, either add some more peer discovery methods and/or find another irc to use. and the fetching of the receiver_0 will not work in the existing code at all. Fixing that you still often get failure due to that error from github I was showing. Github has been flaky lately, so we'll switch away from github for at least receiver_0.
Ok.. |
|
|
|
The bounty for the windows installer?
You know I really need to write up a bounties considered harmful. I already commented that the bounty is even hunting the wrong target, not to mention the other problems with this type of bounty even if it was going after the right target.
Even after downloading the receiver files is improved, it would still be useful to make a windows installer that installs devcoin-qt, and devcoind with one click. Oh, I was not saying some people may not want an installer. It however looked like it was being pushed as the solution to the bootstrapping issues though. I was saying it was the wrong place to fix that. |
|
|
|
|
Ok... as a work around for the github server too busy message getting stored sometimes as receiver_0.csv which then borks
that installation until it is deleted I propose that I make the following two changes to the logic:
1: Only write out a fetched file that starts with the line 'Format,pluribusunum'.
2: Add some logic to not keep retrying the same url more often them some time period so we don't then try to DDoS github when
everyones client hits this type of result.
I am not sure this will be enough for it to recover yet, but it at least gives it a chance to do so on the next restart.
|
|
|
|
There is a bounty to correct this a couple pages back it was discussed.
The bounty for the windows installer? You know I really need to write up a bounties considered harmful. I already commented that the bounty is even hunting the wrong target, not to mention the other problems with this type of bounty even if it was going after the right target. |
|
|
|
What is the reason that all these receiver files are stored externally? Would it not be possible to store them directly in the block chain? There was a method to do this with the bitcoin blockchain (see here: https://bitcointalk.org/index.php?topic=47283.0) and it seems to be a problem already solved by Namecoin (you can link 1023 bytes of data to a certain name). It seems like getting all of these receiver files is big stumbling block for setting up the Devcoin wallet (I gave up setting mine after a few attempts, and just made one on devda.ch), and ideally it seems like it'd be better to have a solution that isn't dependent on people hosting the files. Thoughts? It would probably take a forking change to get them into the blockchain at this point? Even if you did so, I think the program needs the files to validate the existing blockchain and there is no way to go back and insert it. So, since I don't think we would want to do a relaunch, we are stuck with needing the information to bootstrap. I do think the way it is being done is way too fragile. Everything is dependant on github to bootstrap and that is failing right now. Also the irc that is used has ben failing alot lately. After not running the client for some months, it has been a real pain to be able to get it working again. I think the folks that have been running it all along, do not realize how fragile the current bootstrapping is right now. All the seed nodes are gone, the IRC is flakely, and the fetching of the receiver_0 will not work in the existing code at all. Fixing that you still often get failure due to that error from github I was showing. This process needs more recovery and robustness. I would even say we should use DNS txt records to not be stuck on only a hardcoded github url for bootstrapping. So, either way, this code needs to be improved, and once it is, I am not sure there is enough to gain from them putting it in the blockchain? |
|
|
|
I wanted to buy an Arbitridge fund on the Rock Trading but it's in SLL and I'm blocked by the risk API.
Where can I find the same thing but in BTC?
What is SLL and what is this risk API that can block you? Sounds interesting. |
|
|
|
BTW, the windows bounty for an installer is for the wrong thing. The bootstrapping issue is currently in all three platforms, not just windows. I should have something working in a day or so. Anyone want to test, if so pm me, and for what platform(s).
Ok. at this point I have made some changes that can allow a fresh install to bootstrap itself, with no receiver_ files. However it is fragile.. for example, earlier today I was getting https://www.box.com/s/3v8jahr8ge29dcfjvomb as the receive_0.csv from the github url. I have not yet been able to determine what http status code github is giving when this happens, nor can I get it to happen often enough to catch it with the command line curl yet. If anyone can capture that status headers for this result it would help. The code current can never recover once this happens. It also has other points that it will either never recover or 'attack' the host by trying to fetch the url many times a second when things fail to fetch cleanly the first time. There is also an odd bug that a space in the path to the receiver files gets stripped when the directory is first made, but not later when it tries to write to that locations, so it then fails again. What I have works much better then what the current release does but it still needs more error recovery and robustness... however no ones is interested anyway, I got zero replies or pms and people are more interested in writing and banners it seems then a sound fundamental client. I any case the code I have fails still in odd ways, but regression testing shows the original code failed the same way as well, so I am pretty sure what I have is better but still not great Edit: To see what is in the csv file, download it and rename it to end in .html and load it in your browser. Basically it is a fail that says "This page is taking way too long to load. Sorry about that. Please try refreshing and contact us if the problem persists." |
|
|
|
I can pay with Dwolla, paypal, or whatever I guess is the best for you.
Why 62? In any case you are below the current market price, and asking the seller to take more risk then just selling it at market. |
|
|
|
|
Show Posts
