Wow
4,928.1985 GH/s
Topic: Devcoin - page 95. (Read 412952 times)
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.
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.
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.
Quote
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.
Code:
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:
Code:
stepText = getInternetText("https://raw.github.com/Unthinkingbit/charity/master/receiver_0.csv");
to something like:
Code:
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.
Hello all.
First, I've set up a devcoin block explorer besides my seed node, it's accessable via http://d.evco.in/ and using code from ABE. I just spend several hours, so please tell me there's any mistake. (known: site a little slow, API may be unusable).
First, I've set up a devcoin block explorer besides my seed node, it's accessable via http://d.evco.in/ and using code from ABE. I just spend several hours, so please tell me there's any mistake. (known: site a little slow, API may be unusable).
Thanks! You got the third 2 share award for a devcoin block explorer:
https://bitcointalksearch.org/topic/m.937183
There is now one block explorer award remaining.
You'll also get 2/5 of a share as long as you maintain it. I added it to the list of devcoin block explorers at:
http://www.devtome.com/doku.php?id=devcoin_block_explorer
Also if hard-forking is the only concern we can put an extra field in 'recfile' to allow a pubkey change (newpubkey+signature by current pubkey)
Not good enough; once the current signer gets run over by a bus it is too late to get them to sign over to someone else.I agree, majority vote is being used to protect against the following:
1) The key holder being run over by a bus.
2) The key being stolen.
3) The key holder becoming corrupt.
Quote
We use majority right now, that seems more robust though also has its own potential weaknesses presumably.
It's weak when the tree is thin. To fix the fragility issue, when we make round 23 Fuzzy Bear is going to take my place in the peer list with devcoinpool.btc-music.com. Then we will make new receiver files 0 through 22 with the peer list replaced by:
Code:
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
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:
Code:
stepText = getInternetText("https://raw.github.com/Unthinkingbit/charity/master/receiver_0.csv");
to something like:
Code:
string peerText = string("_beginpeers\n");
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");
peerText += string("_beginpeers\n");
stepText = getCommonOutputByText(peerText, string("0"));
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");
peerText += string("_beginpeers\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.
Okay lets start with "convince me it is broken".
As in "if it ain't broke don't fix it"...
Seems to work pretty good as it is.
-MarkM-
As in "if it ain't broke don't fix it"...
Seems to work pretty good as it is.
-MarkM-
Proposition
- Hardcode current receiver files
- Hardcode an Unthinkingbit's signing address
- Create a new message type 'getrecfile', which only contains the height of the receiver file
- Create a new message type 'recfile'
- Height of receiver file -> var_int
- Pubkey that signs the receiver file -> var_str (because of compressed/uncompressed keys)
- Signature of the recever file by pubkey (signed message is Height+Receiver_file) -> var_str
- Receiver file -> var_str
I like this idea, but agree with Mark that having a single signing key is a bad idea. It seems like modifying this system so the majority determines which are the correct files to use (eg. someone sends a "getrecfile", all the nodes respond with a hash of the requested file, the client chooses to download from one of the nodes with a hash that matches the majority of hashes). I can see a few issues with this though: 1) What if you're only connected to one node and it's a malicious node? 2) What happens when a new receiver file is created - if there's only one copy how can we determine if it's from a legitimate source?
This is why I suggested storing this data in the blockchain. Even just storing the hashes of the receiver files would work. That way no one would be able to forge receiver files, at least the old receiver files. And I guess you could store the signing key of the person who is intended to be the next creator of a file, so if they suddenly disappear there just isn't a receiver for that round (or also store a fallback signing key). Then have some sort of democratic system to decide which signing key gets to create a receiver file in 4000 blocks.
2) That's the point of signatures
But we can't do just 'the majority'. It would be too easy to create tons of addresses that sign the same thing
We can do this though: each person has a set of signing pubkeys (possibly weighted) he will trust. His client will then ignore all recfiles from other people. Drawback: possible fork(s!)
I totally agree to store the hashes in the blockchain(*). Problem: someone needs to write in the blockchain, so:
- Who? Surely Unthinkingbit, then community chosen
- Can he mine himself special blocks? How can we know these blocks are really from him? His pubkey?
- If not, does he have to convince all miners to put the hash? How can he send that hash? Email?
- How can we make the client trust HIS blocks but not others without risking forks?
- What if there's no receiver file in the block chain until we need it?
(*) but we still need to download the files. So maybe a mixed solution can be used: getrecfile+recfile which we can make non secure and just provide the file (then maybe getdata can be tweaked instead), AND hashes are in the blockchain
Proposition
- Hardcode current receiver files
- Hardcode an Unthinkingbit's signing address
- Create a new message type 'getrecfile', which only contains the height of the receiver file
- Create a new message type 'recfile'
- Height of receiver file -> var_int
- Pubkey that signs the receiver file -> var_str (because of compressed/uncompressed keys)
- Signature of the recever file by pubkey (signed message is Height+Receiver_file) -> var_str
- Receiver file -> var_str
I like this idea, but agree with Mark that having a single signing key is a bad idea. It seems like modifying this system so the majority determines which are the correct files to use (eg. someone sends a "getrecfile", all the nodes respond with a hash of the requested file, the client chooses to download from one of the nodes with a hash that matches the majority of hashes). I can see a few issues with this though: 1) What if you're only connected to one node and it's a malicious node? 2) What happens when a new receiver file is created - if there's only one copy how can we determine if it's from a legitimate source?
This is why I suggested storing this data in the blockchain. Even just storing the hashes of the receiver files would work. That way no one would be able to forge receiver files, at least the old receiver files. And I guess you could store the signing key of the person who is intended to be the next creator of a file, so if they suddenly disappear there just isn't a receiver for that round (or also store a fallback signing key). Then have some sort of democratic system to decide which signing key gets to create a receiver file in 4000 blocks.
Hello all.
First, I've set up a devcoin block explorer besides my seed node, it's accessable via http://d.evco.in/ and using code from ABE. I just spend several hours, so please tell me there's any mistake. (known: site a little slow, API may be unusable).
Second as you have noticed, I reg a new domain name (a little geeky name
for my devcoin related stuffs (if there's any in the future). e.g. you could directly use http://block.d.evco.in/ to access the explorer, another example, for my personal convenience, I add a http://wallet.d.evco.in/ redirection to https://devda.ch/coins-wallet, and so on.
If you'd like to, please feel free to add your service to the subdomain, just send me a PM or an email.
Oh, forgot to mention, of course, the seed node also now accessable from d.evco.in:52333
First, I've set up a devcoin block explorer besides my seed node, it's accessable via http://d.evco.in/ and using code from ABE. I just spend several hours, so please tell me there's any mistake. (known: site a little slow, API may be unusable).
Second as you have noticed, I reg a new domain name (a little geeky name
for my devcoin related stuffs (if there's any in the future). e.g. you could directly use http://block.d.evco.in/ to access the explorer, another example, for my personal convenience, I add a http://wallet.d.evco.in/ redirection to https://devda.ch/coins-wallet, and so on.If you'd like to, please feel free to add your service to the subdomain, just send me a PM or an email.
Oh, forgot to mention, of course, the seed node also now accessable from d.evco.in:52333
gtz emfox, again nice work there
i may pester u a little if that ok as i'd like to setup a blockexplorer myself for devcoin and just not had enough time to play with ABE to get familiar enough with it... take it u running it off a linux box?Yes, a debian box. ABE has not so much documents, but fairy easy to install. You should run your own devcoind first, It's the relative harder part, and then next is database. I struggled for hours with MySQL ... lol
Hello all.
First, I've set up a devcoin block explorer besides my seed node, it's accessable via http://d.evco.in/ and using code from ABE. I just spend several hours, so please tell me there's any mistake. (known: site a little slow, API may be unusable).
Second as you have noticed, I reg a new domain name (a little geeky name for my devcoin related stuffs (if there's any in the future). e.g. you could directly use http://block.d.evco.in/ to access the explorer, another example, for my personal convenience, I add a http://wallet.d.evco.in/ redirection to https://devda.ch/coins-wallet, and so on.
If you'd like to, please feel free to add your service to the subdomain, just send me a PM or an email.
Oh, forgot to mention, of course, the seed node also now accessable from d.evco.in:52333
First, I've set up a devcoin block explorer besides my seed node, it's accessable via http://d.evco.in/ and using code from ABE. I just spend several hours, so please tell me there's any mistake. (known: site a little slow, API may be unusable).
Second as you have noticed, I reg a new domain name (a little geeky name
for my devcoin related stuffs (if there's any in the future). e.g. you could directly use http://block.d.evco.in/ to access the explorer, another example, for my personal convenience, I add a http://wallet.d.evco.in/ redirection to https://devda.ch/coins-wallet, and so on.If you'd like to, please feel free to add your service to the subdomain, just send me a PM or an email.
Oh, forgot to mention, of course, the seed node also now accessable from d.evco.in:52333
gtz emfox, again nice work there
i may pester u a little if that ok as i'd like to setup a blockexplorer myself for devcoin and just not had enough time to play with ABE to get familiar enough with it... take it u running it off a linux box?
Thanks for the clarifications guys
By the way you usually pronounce the ending d as a separate letter, instead of trying to figure out how to pronounce a word that happens to end in d: "mysql-dee", "system-dee", "bitcoin-dee", "devcoin-dee" etc.
-MarkM-
-MarkM-
Hello all.
First, I've set up a devcoin block explorer besides my seed node, it's accessable via http://d.evco.in/ and using code from ABE. I just spend several hours, so please tell me there's any mistake. (known: site a little slow, API may be unusable).
Second as you have noticed, I reg a new domain name (a little geeky name for my devcoin related stuffs (if there's any in the future). e.g. you could directly use http://block.d.evco.in/ to access the explorer, another example, for my personal convenience, I add a http://wallet.d.evco.in/ redirection to https://devda.ch/coins-wallet, and so on.
If you'd like to, please feel free to add your service to the subdomain, just send me a PM or an email.
Oh, forgot to mention, of course, the seed node also now accessable from d.evco.in:52333
First, I've set up a devcoin block explorer besides my seed node, it's accessable via http://d.evco.in/ and using code from ABE. I just spend several hours, so please tell me there's any mistake. (known: site a little slow, API may be unusable).
Second as you have noticed, I reg a new domain name (a little geeky name
for my devcoin related stuffs (if there's any in the future). e.g. you could directly use http://block.d.evco.in/ to access the explorer, another example, for my personal convenience, I add a http://wallet.d.evco.in/ redirection to https://devda.ch/coins-wallet, and so on.If you'd like to, please feel free to add your service to the subdomain, just send me a PM or an email.
Oh, forgot to mention, of course, the seed node also now accessable from d.evco.in:52333
A daemon is basically what windows would refer to as a system service.
Or what DOS used to call a Terminate and Stay Resident (TSR) program.
Basically a program that drops into the background, disconnecting from the input/output streams you invoked them from. So that once you run the command, you get your command-line input back to type another command instead of having to wait for that program to stop before you can enter some other command (such as to run another program).
Devcoin fires up a whole GUI, as well as still keeping hold of "standard out" (stdout) and "standard error" (stderr) output streams and the "standard input" (stdin) input stream. If you run it from a text mode (command-line_ console you will see the stuff it pours out to stdout and stderr, which is (at least mostly) the same stuff that it also sends to the debug.log file.
In unix one customarily puts a d at the end of the name of a program to indicate it is a daemon, thus the name devcoind for the daemon version. Devcoind actually acts not only like a daemon but also like a control-program used to send commands to a daemon. You run it with the -daemon switch to send it into daemon mode, or without the daemon switch to use it as a control-program for sending commands to the copy that you previously already sent into daemon mode.
Often, maybe usually, the control program for talking to a daemon is separate from the daemon program itself, for example the systemd daemon has a systemctl program used to send commands to it instead of including the control-program functionalisty into the systemd program itself.
Similarly, mysqld is the mysql daemon that is the actual resident database-system system-service whereas mysql is the client program used to send commands to the mysqld to actually create databases, look things up in databases and so on.
-MarkM-
Or what DOS used to call a Terminate and Stay Resident (TSR) program.
Basically a program that drops into the background, disconnecting from the input/output streams you invoked them from. So that once you run the command, you get your command-line input back to type another command instead of having to wait for that program to stop before you can enter some other command (such as to run another program).
Devcoin fires up a whole GUI, as well as still keeping hold of "standard out" (stdout) and "standard error" (stderr) output streams and the "standard input" (stdin) input stream. If you run it from a text mode (command-line_ console you will see the stuff it pours out to stdout and stderr, which is (at least mostly) the same stuff that it also sends to the debug.log file.
In unix one customarily puts a d at the end of the name of a program to indicate it is a daemon, thus the name devcoind for the daemon version. Devcoind actually acts not only like a daemon but also like a control-program used to send commands to a daemon. You run it with the -daemon switch to send it into daemon mode, or without the daemon switch to use it as a control-program for sending commands to the copy that you previously already sent into daemon mode.
Often, maybe usually, the control program for talking to a daemon is separate from the daemon program itself, for example the systemd daemon has a systemctl program used to send commands to it instead of including the control-program functionalisty into the systemd program itself.
Similarly, mysqld is the mysql daemon that is the actual resident database-system system-service whereas mysql is the client program used to send commands to the mysqld to actually create databases, look things up in databases and so on.
-MarkM-
So when you say "Daemon" is that similar to the mailer daemon for yahoo?
Yes, it is Fin.
A daemon is basically what windows would refer to as a system service.
Or what DOS used to call a Terminate and Stay Resident (TSR) program.
Basically a program that drops into the background, disconnecting from the input/output streams you invoked them from. So that once you run the command, you get your command-line input back to type another command instead of having to wait for that program to stop before you can enter some other command (such as to run another program).
Devcoin fires up a whole GUI, as well as still keeping hold of "standard out" (stdout) and "standard error" (stderr) output streams and the "standard input" (stdin) input stream. If you run it from a text mode (command-line_ console you will see the stuff it pours out to stdout and stderr, which is (at least mostly) the same stuff that it also sends to the debug.log file.
In unix one customarily puts a d at the end of the name of a program to indicate it is a daemon, thus the name devcoind for the daemon version. Devcoind actually acts not only like a daemon but also like a control-program used to send commands to a daemon. You run it with the -daemon switch to send it into daemon mode, or without the daemon switch to use it as a control-program for sending commands to the copy that you previously already sent into daemon mode.
Often, maybe usually, the control program for talking to a daemon is separate from the daemon program itself, for example the systemd daemon has a systemctl program used to send commands to it instead of including the control-program functionalisty into the systemd program itself.
Similarly, mysqld is the mysql daemon that is the actual resident database-system system-service whereas mysql is the client program used to send commands to the mysqld to actually create databases, look things up in databases and so on.
-MarkM-
Or what DOS used to call a Terminate and Stay Resident (TSR) program.
Basically a program that drops into the background, disconnecting from the input/output streams you invoked them from. So that once you run the command, you get your command-line input back to type another command instead of having to wait for that program to stop before you can enter some other command (such as to run another program).
Devcoin fires up a whole GUI, as well as still keeping hold of "standard out" (stdout) and "standard error" (stderr) output streams and the "standard input" (stdin) input stream. If you run it from a text mode (command-line_ console you will see the stuff it pours out to stdout and stderr, which is (at least mostly) the same stuff that it also sends to the debug.log file.
In unix one customarily puts a d at the end of the name of a program to indicate it is a daemon, thus the name devcoind for the daemon version. Devcoind actually acts not only like a daemon but also like a control-program used to send commands to a daemon. You run it with the -daemon switch to send it into daemon mode, or without the daemon switch to use it as a control-program for sending commands to the copy that you previously already sent into daemon mode.
Often, maybe usually, the control program for talking to a daemon is separate from the daemon program itself, for example the systemd daemon has a systemctl program used to send commands to it instead of including the control-program functionalisty into the systemd program itself.
Similarly, mysqld is the mysql daemon that is the actual resident database-system system-service whereas mysql is the client program used to send commands to the mysqld to actually create databases, look things up in databases and so on.
-MarkM-
So when you say "Daemon" is that similar to the mailer daemon for yahoo?
A daemon is basically what windows would refer to as a system service.
Or what DOS used to call a Terminate and Stay Resident (TSR) program.
Basically a program that drops into the background, disconnecting from the input/output streams you invoked them from. So that once you run the command, you get your command-line input back to type another command instead of having to wait for that program to stop before you can enter some other command (such as to run another program).
Devcoin fires up a whole GUI, as well as still keeping hold of "standard out" (stdout) and "standard error" (stderr) output streams and the "standard input" (stdin) input stream. If you run it from a text mode (command-line) console you will see the stuff it pours out to stdout and stderr, which is (at least mostly) the same stuff that it also sends to the debug.log file.
In unix one customarily puts a d at the end of the name of a program to indicate it is a daemon, thus the name devcoind for the daemon version. Devcoind actually acts not only like a daemon but also like a control-program used to send commands to a daemon. You run it with the -daemon switch to send it into daemon mode, or without the daemon switch to use it as a control-program for sending commands to the copy that you previously already sent into daemon mode.
Often, maybe usually, the control program for talking to a daemon is separate from the daemon program itself, for example the systemd daemon has a systemctl program used to send commands to it instead of including the control-program functionality into the systemd program itself.
Similarly, mysqld is the mysql daemon that is the actual resident database-system system-service whereas mysql is the client program used to send commands to the mysqld to actually create databases, look things up in databases and so on.
-MarkM-
Or what DOS used to call a Terminate and Stay Resident (TSR) program.
Basically a program that drops into the background, disconnecting from the input/output streams you invoked them from. So that once you run the command, you get your command-line input back to type another command instead of having to wait for that program to stop before you can enter some other command (such as to run another program).
Devcoin fires up a whole GUI, as well as still keeping hold of "standard out" (stdout) and "standard error" (stderr) output streams and the "standard input" (stdin) input stream. If you run it from a text mode (command-line) console you will see the stuff it pours out to stdout and stderr, which is (at least mostly) the same stuff that it also sends to the debug.log file.
In unix one customarily puts a d at the end of the name of a program to indicate it is a daemon, thus the name devcoind for the daemon version. Devcoind actually acts not only like a daemon but also like a control-program used to send commands to a daemon. You run it with the -daemon switch to send it into daemon mode, or without the daemon switch to use it as a control-program for sending commands to the copy that you previously already sent into daemon mode.
Often, maybe usually, the control program for talking to a daemon is separate from the daemon program itself, for example the systemd daemon has a systemctl program used to send commands to it instead of including the control-program functionality into the systemd program itself.
Similarly, mysqld is the mysql daemon that is the actual resident database-system system-service whereas mysql is the client program used to send commands to the mysqld to actually create databases, look things up in databases and so on.
-MarkM-
You didn't mention the receiver files. Maybe you simply happened to be in the same directory those files were in when you ran the devcoind? As one place they can be to work is wherever you are when you run the program. They then copy them over from there to their actual destination in a subdirectory of the data directrory. The other option is to specifically put them in that subdirectory yourself, which would usually mean you'd create the diata directrory create its subdirectory and put the receiver files there.
Obviously simplest, it is weren't for the difficulty of conveying to Windows users the concept of "current working directory" and how to put yourself in a particular directrory before running something, would be to make sure you are sitting where those files are when you first run the program.
-MarkM-
Obviously simplest, it is weren't for the difficulty of conveying to Windows users the concept of "current working directory" and how to put yourself in a particular directrory before running something, would be to make sure you are sitting where those files are when you first run the program.
-MarkM-
When I start to run devcoind, it reports that download from raw.github.com error, so I just copy receiver_0.csv (only this file) to ~/.devcoind/, remove the blk_* and __db* files from ~/.devcoind, restart devcoind and everything works. So I think it's just a temporily network problem of my own. you see, devcoind download all the other receiver_*.csv files, isn't it?
So I didn't even mention that ...
I've heard "Devcoind" is "Demon" coin or something like that. What is the difference between that (Devcoind) an Devcoin?
Very nice work
Majority can still work with that system: everybody signs and broadcasts his signature
See now that sounds better already.
-MarkM-
Jump to: