Topic: [50 BTC total bounty] for Groupcoin development and help - page 8. (Read 26230 times)

I have a few questions.

How did you get the idea to do this? Did you get the idea yourself, or was it after extended talks with other people? Which other people? Are any of them related to bitcoin development? How did you come up with the 50% percentage? Why did you only include bitcoin open source developers, if you specified "general" open source developers?

Why do you think this idea will be successful, when so many have failed? What are your insights on why would this be a good project? What is your ideal ratio of bitcoin:groupcoin miners? Why the name Groupcoin?

Why would you "incorporate code that would keep the whitelist updated from the web every two weeks", but not incorporate code that would automatically donate 50% of the 50 BTC bounty to the group of open source developers? Do you think that if miners mine every 10 minutes on average, hundreds and potentially thousands of small transactions will generate unnnecessary work for the network? Wouldn't it be maybe more efficient to create a central site/location where miners would donate the 50% as a single transaction and then the site would store the balances of the developers, which they could then somehow access and transfer when they want (or maybe once daily, or at least 0.1btc, etc.)? Do you plan on keeping the currency as BTC? 1 Groupcoin BTC = 1 Bitcoin BTC? How will that work, anyway? I don't think a Groupcoin BTC will be able to be sent to the Bitcoin network since this is a separate blockchain, right?

If setting a single master groupcoin/bitcoin address (see the confusion?) is a potential security risk, there could be a master list of addresses which would rotate on every new block found, or every few dozen blocks, or a similar criterion. They could be fetched from a trusted location.

This project seems to be rather centralized, with lots of trusted individuals, as opposed to the main Bitcoin project.

Thanks!

I have received the 5 BTC, thank you.

The specific DB exception problem seemed to be that neither of the two machines I was running it on had been able to download a blockchain from the other.

Both expected to initially download the blockchain but neither actually had any blocks to offer as both had only the genesis block.

I hoped this problem would solve itself once at least one block had been generated by one or the other of the two machines.

However I have now found that not only did that not happen but in fact once a block had been generated stopping and trying to restart resulted in a core dump instead of the DB exception thing.

If each client makes up a new address to generate coins to, presumably that means each client is trying to generate invalid blocks until such time as they arrange to have that address added to the database of valid miner's addresses?

I doubt I can merge your version with the version I have been deriving from the original bitcoin-qt, for example doing a diff of your db.cpp and the db.cpp currently in bitcoin-qt there is much much more change than just your vchGenerateKey stuff.

-MarkM-

The experts on bitcoin-qt, and Qt in general, are at:
http://forum.bitcoin.org/index.php?topic=15276.0

I can compile bitcoin-qt and groupcoin, but I do not have their knowledge and can not help anyone else with compiling qt.

There is only one generation address per client.  The client creates it on the first start up.  The creation code starts with:
if (mapKeys.count(vchGenerationKey))

in the file:
https://github.com/Unthinkingbit/groupcoin/blob/master/src/db.cpp


When you buy, trade, give and hold GRP, you help boost the groupcoin currency, which boosts the value of all the open source developers coins.

You would prefer it to fiat currencies primarily for a moral reason, when you use GRP you help developers, when you use fiat currencies, you help banks.


Please post how you fixed the exception.  If it's a general problem I'll update groupcoin, if it's a specific problem, posting might help someone else who runs into the same problem.

Also, I just sent 5 BTC to the address you posted, please confirm that you received it.

Okay, I think I have figured out that DB exception.

I have also created myself an account on github and forked bitcoin and groupcoin so I'll be ready to publish any changes ("pull requests" I guess they are called).

I have not actually published any changes yet though.

I cannot figure out how/where you are setting the actual value of the vchGenerationKey.

You seem to be storing them in the wallet, so you are presumably also loading them out of the wallet, but I do not see any place where an actual value is assigned that isn't simply another variable (where does 8that* variable get it from?)

So I do not see any example of how to put an actual string - a copy/paste of an actual address - into vchGenerateKey.

I can run the thing, generating blocks and thereby generating addresses that will have to be regarded as valid eventually since they are in the blockchain. I was going to paste the first one thus created into vchGenerateBlock so that I could have that same address continue to be used for subsequent blocks until such time as we get more addresses to plug in and some kind of database that can be used to validate the blockchain against the set of addresses that were valid at each point along the blockchain.

(You do realise, don't you, that if you want to invalidate an address from a certain block number forward you will need to record along with each address the first block at which it started being valid and the last block that it was valid?)

-MarkM-

I now have the thing running initially, but after I exit the next time I try to run it a popup comes up complaining about blkindex.dat

At the commandline it output:

terminate called after throwing an instance of 'DbException'
  what():  DbEnv::close: Invalid argument
Aborted (core dumped)

I saw that you added code to plug in addresses for coins generated to be sent to, but, I didn't see you initialise that, where is it supposed to get those addresses from?

You seemed to be putting them into the wallet?

I don't see what if anything that would have to do with blkindex.dat though so i don't know what you did that might be messing up the block index.

Guess it is time to go through these same steps (firing it up on two machines, connecting them with -addnode, using -gen=1 to try to get them to mine) with the original bitcoin-qt just to make sure it is in fact something you or I did that is causing the problem...

-MarkM-

PP: even if I did prefer GRP to BTC, why would I prefer it to MBC, NKL, CDN or UKB?

Why anyone should prefer Grupcoin instead of Bitcoin?

Thanks, that .pro file might be the magic bullet.

Thanks denominated in BTC can be sent to the BTC address 1E5RcwrLGpKSSEELyg5ZbqzJaQ3XyqgULp

-MarkM

well I'm not able to figure out the details needed to compile your groupcoin or bitcoin-qt,  I just get warnings and nothing seems to build.  I think I have all the needed libs installed on Ubuntu 10.04.  Other than that you can take a look at the configs for Multicoin that you can use as a reference or just use as a  branch point  to continue development.  I think I prefer Qt as a user so eather way is cool for me.  the link to a posible config can be found at: http://exchange.beertokens.info/docs/multicoin/bitcoin.conf.groupcoin  that I have tested with MultiCoin https://github.com/sacarlson/MultiCoin  I have test mined it and am now at block 54.  If you want to try link into it and try it you can addnode=www.beertokens.info, and dns=1.  I don't have the IRC active at this time.

I looked for the IRC channel, but could not find it.  What do I have to replace with (s/bit/group).


For validation code to work, all clients have to have identical whitelists.  If the whitelist is only updated when people downloaded the next client version, there will be different whitelists on different computers, which would break validation.


The point is that somehow the keys have to be changed on a schedule in order to prevent damage from stolen keys.  The complexity is necessary because updating is necessary.

The complexity is manageable, pluribusunum.py is already tested, the client just has to somehow link to it to get the bounty.  Later, the code can be incorporated into the client.


Thank you for testing the bitcoin-qt branch and groupcoin.  I did not know that it was necessary to include the .pro file so I've added that to the latest groupcoin.  Please try the latest groupcoin, and see if there are still problems.

Thanks in general for the testing you've done and sharing your knowledge.  If you send me or post a bitcoin donation address, I'll send you 5 BTC from the general help bounty.

Actual bitcoin-qt was not hard to compile, mostly I just had to tell it about ../deps/include and ../deps/lib so it could find the openssl I compiled with the parts bitcoin uses that Fedora prefers not to include in their distributions.

Maybe you could do whatever clever git thing it is that git users do to bring their branch up to date with the latest main branch or something, as yours seems rather nastily broken.

For example your Makefile wants there to be a .pro file but you have not provided that .pro file.

Also qmake-qt4 just works with the main branch, but in your branch it spews a whole bunch of help about things like having a -project mode and a -makefile mode, evidently it is confused as to which to use. Only by doing both a few times in various sequences did I get a Makefile that even attempted to compile, whereupon i am back at the unexplained Error 1 again.

Backburnered for now pending fixing of your branch I guess.

-MarkM-

If it is from miners that thieves are to obtain keys, keeping keys out of the hands of miners seems like a good idea.

It would not only be more code, but also more points of failure and a larger attack surface, while also being un-necessary.

If we hard-code addresses that minted coins must go to, anyone who does manage to obtain the private key of one of those addresses will be able to reward miners, or anyone else, based on any criteria they choose to use, including basing it on completed work shares in mining pools.

We can update the clients anyway in the normal way: making new versions available from official distribution sources which people are free to download and use if they choose to.

If a key does get stolen, next official version of the client can have the address associated with the stolen key removed.

Making things more complex just so that more attack surfaces will be exposed doesn't seem right, somehow.

To minimise damage from stolen keys we could change the keys on a schedule, such as each time the difficulty adjustment time comes the key(s) also change. They could change based on a hard-coded pre-generated list, and the client could even be set to die when it runs out of pre-generated keys in order to phase out old clients on a schedule too so people will have reason to come looking for updated versions from time to time.

-MarkM-

Actually it is a big deal, because with a stolen generation key a thief can make a huge stolen profit and eventually take over the network; this is why:

Mining is a competitive free market, with relatively low barriers to entry, so the typical profit is small.  Assume, for the sake of argument, that the typical miner revenue is 110%/month of cost, giving a profit of 10%/month, so in a market at equilibrium, the typical miner takes home 10%/month (10/110 * revenue).

Now, a thief hacks into a whitelisted miner and gets a generation key.  That thief keeps all the generation instead of sharing half, so the thief's revenue is double that of the sharing miners, so the thief's miner revenue is 220%/month of cost, giving a profit of 120%/month, which minus the take home 10/110 * revenue of 220%/month = 20%/month, gives a growth rate of 100%/month.  Say the thief starts with a mining operation which has 1% of the hash power, this is the hash power growth:

Time, Thief Hash Power
Month 1, 1%
Month 2, 2%
Month 3, 4%
Month 4, 8%
Month 5, 16%
Month 6, 32%
Month 7, 64% --> big trouble

A different profit ratio and/or take home percentage will change the time for big trouble to come; but the point is, if a thief gets a generation key and there is no way of shutting down that key, the thief will make a huge and growing profit and on top of that eventually big trouble will come.


There is no single update key.

The update would be handled by the client grabbing text files from several web sites.  If more than 60% of them are identical, then the client would update its whitelist with the identical files.  The prototype of this is implemented at:
https://github.com/Unthinkingbit/charity/blob/master/pluribusunum.py

This method also gives resistance to DDOS attacks, because an attacker would have to shut down at least 40% of the web sites to stop the clients.

The web sites would be managed by administrators, who get paid for their work out of the 10% administration portion.


I compiled bitcoin-qt and the derived groupcoin on Ubuntu 10.04 LTS (Lucid).

You could try compiling the original bitcoin-qt at:
https://github.com/laanwj/bitcoin-qt

The thread for which is at:
http://forum.bitcoin.org/index.php?topic=15276.0

If there are still problems, ask for help there, that's where the bitcoin-qt developers are.

The changes I made to bitcoin-qt to derive groupcoin were minor, so if you can get the original to work, the derived groupcoin should work also.  If you can get the original to work and for some reason you can not compile groupcoin, then please post the error with the derived groupcoin on this thread.

If a generation key is stolen, the thief can make some groupcoins, whoopie sheet, big deal, at least they cannot update all the clients.

If on the other hand the update key is stolen...

If you cannot keep keys safe widening the scope of the damage inappropriate access could do doesn't sound very wise to me.

...

Oh was it github not gitorius, I hardly even remembered those are two different sites.

I dont think doing the create remote archive from what is on my local disk is quite what I would be doing even though what is on my local disk is the bundle from the remote site.

I seem to recall having figured some kind of clone type command might be what they use instead of checkout but never did get it puzzled out, being usually more interested in getting compile to work.

Fedora 15 seems to have both qt and qt4, but then also it seems as if the qt is qt4. There is no qmake, but there is a qmake-qt4.

Compiling ends at an error 1 without any apparent explanation of what error has been encountered, getting rid of the -Wall in case it is merely some limit on the number of warnings allowed before sheer number of warnings counts as an error doesn't help.

I am installing qt-creator now to attempt to use project instead of makefile...

...Ouch, a GUI so stupid that it wont even let me mouse-sweep its error messages to paste. so that I have to try to hand type them from memory: "_ was not declared in this scope" or some such thing - is truly ghastly-pathetic-gross. A development tool for people who want to make sure they won't be getting any detailed error reports or something?

Presumably (_( manages to be as unlikely a construct as it at first blush might appear to someone more used to C than whatever this stuff manages to rewrite itself into. Is _ a primitive of C# or C++ or gosh knows how preprocessed by q q-code or whatever this stuff is meant to end up as or is it maybe just a macro that isn't being defined as expected, I wonder... Hey might it even be a "translate-able string follows" signal like in WML? Maybe even the very thing WML inherits that "put an underline before strings if they are to be translate-able" quirk from?

Is the localisation stuff that does that maybe some other dependency not mentioned in the README ?

Die, GUI. Lets try qmake-qt4 followed by make, again, at least mousesweep-into-pastebuffer works in text mode:


I see a warning but not an error other than "Error 1", which make tends in past experience to seem to expect whatever died to have provided some explanation of prior to dying...

-MarkM-

Thanks for the offer, when the groupcoin net is started I'll post the stuff in this thread.  You would be the second miner, so you'd get a bitcoin.

The contribution list for sharing 50% of your mining will be up shortly after the net is working.


An extra validation step would be added in the groupcoin clients.  It would check that the coinbase address in on the whitelist.  As Markm pointed out, that extra step would be somewhere around here:


In pseudo code it would look like:



Yup, that's where the list would start.  Once the groupcoin net is running, I'll ask contributors if they'd like to be administrators.  When a new contributor is nominated, if there are no objections they're added to the list.  If there is an objection, three administrators are chosen at random to see if the contributor should be added.  If the answer is no, the candidate can't ask again to be added for at least a month.

The adminstrators would get a share of the 10% administration fee.  So 50% would go to miners, 10% to administrators and 40% to the contributors.


If your system works, you'll get 3 BTC.  I can not judge whether it works or not, so if there are no objections within 3 days I'll assume it's good.


I decided on the periodically updated whitelist because if a generation key is stolen, all the clients would have to be updated.  Then if you have updating capability, you may as well make it periodic.

For the first validation bounty, you just need to validate against a file in the client directory.

The second bounty requires the client to periodically check for updates.


I found gitorious hard to use and github easy to use.  The best git guide I found is:
http://www.kernel.org/pub/software/scm/git/docs/everyday.html

To add groupcoin to my github account I followed the github instructions made when I registered.  Then to not upload the backup files, object files and QT Creatir files, I set the .gitignore file to the following:
*~
*.o
*.pro
*.pro.user

added the entire directory recursively with:
git add .

commited with:
git commmit -a -m first

then uploaded with:
git push -u origin master


Thanks for pointing that out, I'll change that in groupcoin.


If someone wants to deny themselves 25 BTC to collect crumbs, they may be able to, but I'm not worried about it.

I am interested in the criteria for the genesis block, because I have run several alternative blockchains for months using a ridiculously simple hack of the part of the code that creates the genesis block.

I think all I did was change the newspaper headline.

Either it seemed to me that all the math to make things add up right or hash right or whatever was in the code, or just possibly I might have moved something just a little bit to make sure the calculation did happen.

All the hints I have seen in various places about what one does to make a genesis block have caused me to be amazed that my simple hack seems to have actually worked.

A cost though is the fact that I left Satoshi his 50 coins - his ownership of the genesis block. I figured what the heck, so he gets 50 coins out of each batch of 21,000,000 that I make, am I going to begrudge him that?

Gosh I could have made an extra 50 coins by usurping Satoshi's 50 coins per blockchain. Was I a fool not to do so?

As to approved miners, since pools seem to be the wave of the future anyway why bother retrofitting approval into the daemon?

You could simply make it part of the protocol that only one or more specific hard-coded addresses can be given the generated coins, and have one pool per each such approved address. The daemons and clients need not care who the pools pay to mine, so long as the mined coins go to the designated addresses that could be all the daemons and clients need to know?

To unapprove a miner simply delete their login at the pools. They are still free to mine, they just won't be paid to.

Now about git... Sourceforge back in the day showed me exactly what command to use to suck back an svn snapshot and svn up was easy to remember ever since to stay up to date.

Can someone translate "svn co" and "svn up" into gittish, that gitorious place doesn't seem to be getting that info through to me somehow.

Sourceforge makes it clear to me how to grab a tarball made right then and there for me of the latest/current state. Sometimes the downloads button at gitorious offers more than just do you want tgz or zip but today that was all the choice I saw so I picked tgz.

Standard three-hack new currency...

1) You already changed the ports.

2) You didn't change the IRC channel so I have.  (s/bit/group/).

3) A glance at freecoin (now known as multicoin) seemed to hint one need not preserve the string length of the headline, but what the heck I always have so might as well do so again:

const char* pszTimestamp =   "For Satoshi. http://forum.bitcoin.org/index.php?topic=24813.msg312224"

That would be it, except for this new feature about restricting where minted coins go, lets grep -i validate, aha looks like actually we want CheckBlock:

main.cpp line 1699/4062


I am guessing there will turn out to be a vtc[0].something which is the address the minted coins went to. That would be what we'd want to check. Once we figure out where it gets set of course so we can set it to what our check is going to check for.

If we really wanted to deny unapproved miners every crumb of solace we could worry about the checking of the rest of the transactions if possibly transaction fees might not be bundled into the coinbase transaction but hey, you want minting forever anyway so how vindictive need we be toward people who choose to mine "for free"? (As in do you want to worry about them maybe getting a transaction fee now and then?)

-MarkM-

It is whoever controls this page.

Who decides whether or not a miner has broken the rules?

I'm happy to put one of my miners on this once it's up and running... will only be around 300MHash.. but should be enough to help kick off the project :-)

That would be great.


Actually, I forgot to mention that I changed the generation to be constant, 50 BTC per block forever.  This change was made to give perpetual income to developers.  The change is already made in main.cpp so I don't think anything else need be changed.


Indeed, the group coin is licensed mining.  Once it's made, people could fork it in turn to make stuff like a town coin or project coin.