Devcoin

[jackjack]

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)

[markm]

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.

We use majority right now, that seems more robust though also has its own potential weaknesses presumably.

A majority of the files have to be identical. Its that simple.

-MarkM-

[jackjack]

Majority can still work with that system: everybody signs and broadcasts his signature

[markm]

Majority can still work with that system: everybody signs and broadcasts his signature

See now that sounds better already.

-MarkM-

[grc]

Another button design to add to the mix:

https://i.imgur.com/2oxYgw2.png

Larger version

[FuzzyBear]

Another button design to add to the mix:



Larger version

Very nice work

[FinShaggy]

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-

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?

[markm]

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-

[FinShaggy]

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-

So when you say "Daemon" is that similar to the mailer daemon for yahoo?

[Balthozar]

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-

So when you say "Daemon" is that similar to the mailer daemon for yahoo?

Yes, it is Fin.

[emfox]

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

[markm]

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-

[FinShaggy]

Thanks for the clarifications guys

[FuzzyBear]

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

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?

[emfox]

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

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

[metazilla]

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.

[jackjack]

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.

1) If you're connected to only one node, you know you are vulnerable anyway so ignore the recfiles
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

[markm]

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-

[Unthinkingbit]

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.

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

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"));

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.

[Unthinkingbit]

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).

Thanks! You got the third 2 share award for a devcoin block explorer:
https://bitcointalk.org/index.php?topic=34586.msg937183#msg937183

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