[50 BTC total bounty] for Groupcoin development and help

[SeriousWorm]

183DMPnYWejo59A2P9SftbgfiQULjLHHry - thanks!

I sent 3 BTC to that address, please confirm receipt.

Confirmed - thanks!

[1715221872]

1715221872

[1715221872]

1715221872

[1715221872]

1715221872

[1715221872]

1715221872

[1715221872]

1715221872

[1715221872]

1715221872

[Shattienator]

Another "permanent" node is up and running at 50.19.210.139:51333 24/7/365 (I hope  ).
..

Thanks for setting up the node.  Please post your donation address and I'll send you the 1 BTC miner bounty.

1PtPbUJnjeCsD2dvTeKQLSttLg75G2k9Vb

[Unthinkingbit]

..
This seems to work in groupcoind:
..
Mind you, it seems to happen a lot more than just when a block is created. Hmm...

I believe that's because the CreateBlock function is called on every attempt to mine.  Even if the attempt is unsuccessful, the send transaction will still be made.  There might even be a set of send transactions per thread.

So to only make a send transaction in the mined block itself, I've copied over part of the SendMoney code, without the CommitTransaction part.  In theory, if this block is not mined, it shouldn't show up as a transaction.  The code follows:

Code:

    uint64 payAmount = 2000000;
    std::string payTo = "2hix2ZoA175cC1aF6fFwnyt3XuwqQMKPg9M";
    uint160 hash160 = 0;

    if(!AddressToHash160(payTo, hash160))
    {
     	return NULL;
    }

    CRITICAL_BLOCK(cs_main)
    {
        // Send to bitcoin address
     	CWalletTx wtx;
        CScript scriptPubKey;
        scriptPubKey << OP_DUP << OP_HASH160 << hash160 << OP_EQUALVERIFY << OP_CHECKSIG;


        // std::string strError = SendMoney(scriptPubKey, payAmount, wtx, true);
        // ..
        // is replaced by:
        CReserveKey reservekey(pwalletMain);
        int64 nFeeRequired;
        pwalletMain->CreateTransaction(scriptPubKey, payAmount, wtx, reservekey, nFeeRequired);
    }

A potential problem is that the "reservekey(pwalletMain)" part, because you didn't call the SendMoney function will a wallet.  If "reservekey(pwalletMain)" doesn't work, you could try:
reservekey.GetReservedKey();

[markm]

THe pwallet thing doesn't exist in groupcoind, it is part of the Qt GUI I guess.

Here is what I tried in groupcoind, might as well first get something working there before dealing with all the extra complicAtion of a GUI.

Code:

    int64 payAmount = 2000000;
    std::string payTo = "2hix2ZoA175cC1aF6fFwnyt3XuwqQMKPg9M";
    uint160 hash160 = 0;

    if(!AddressToHash160(payTo, hash160))
    {
        return NULL;
    }

    CRITICAL_BLOCK(cs_main)
    {
     	// Send to bitcoin address
        CWalletTx wtx;
        CScript scriptPubKey;
        scriptPubKey << OP_DUP << OP_HASH160 << hash160 << OP_EQUALVERIFY << OP_CHECKSIG;

        int64 nFeeRequired;
        if (CreateTransaction(scriptPubKey, payAmount, wtx, reservekey, nFeeRequired))
        {
            // OK
        }
	else
	{
            return NULL;
        }
    }

I mined a block, no sign of a transaction. I am letting it mine one more block in case maybe the transaction doesn't get to be in the block we were working when we initiated its creation... No, no luck. No sign of the transaction.

-MarkM-

[Unthinkingbit]

I mined a block, no sign of a transaction. I am letting it mine one more block in case maybe the transaction doesn't get to be in the block we were working when we initiated its creation... No, no luck. No sign of the transaction.

Could you try adding the CommitTransaction right before CheckWork is called in the miner.

Code:

    if (!CommitTransaction(wtx, reservekey))
        return _("Error: The transaction was rejected.  This might happen if some of the coins in your wallet were already spent..");

Because you would need wtx in the CommitTransaction scope, you'd have to move the create money code block:

Code:

    int64 payAmount = 2000000;
..
        if (CreateTransaction(scriptPubKey, payAmount, wtx, reservekey, nFeeRequired))
..

out of CreateBlock to just before it in the miner function.

Hopefully, the create money block would add the transaction to the block, then if the miner succeeds, the entire block would be committed to memory and relayed to the other nodes.  That's the hope anyways;)

[markm]

Since the list of beneficiaries is to be centralised anyway, you might as well just send all the coins to one central account. Include in the block some inidcation of who mined it so the central clearing-house can send them their cut.

That gets rid of all the complication of distributing the list, having to have the list avilable at the time you mine a block and so on.

If the checking of coinbase transactions would work even if all miners did like Satoshi and included arbtrary strings in their coinbase transaction there would be plenty of room to indentify themselves heck they could even list a few next of kin or somply like Satoshi make some commentary on day to day affairs.

If the normal coinbase checks don't in fact allow extra data like in the genesis block then some kind of transaction could be put in the block at some easy to find spot, such as the first transaction, showing in some way who the miner was.

We have to rely on the administrator of the list anyway, at least this way we not have to rely on the list to be online, just that some day the admin will run a batch job that will send us our cut of the coins we mined.

-MarkM-

[Unthinkingbit]

I just thought of why there was no sign of a transaction, and how to complete the transaction.  You could add right after:

    pblock->vtx.push_back(txNew);

the wallet transaction

    pblock->vtx.push_back(wtx);

Code:

CBlock* CreateNewBlock(CReserveKey& reservekey)
{
    int64 payAmount = 2000000;
    std::string payTo = "2hix2ZoA175cC1aF6fFwnyt3XuwqQMKPg9M";
    uint160 hash160 = 0;

    if(!AddressToHash160(payTo, hash160))
    {
        return NULL;
    }

    // Send to bitcoin address
    CWalletTx wtx;
    CRITICAL_BLOCK(cs_main)
    {
        CScript scriptPubKey;
        scriptPubKey << OP_DUP << OP_HASH160 << hash160 << OP_EQUALVERIFY << OP_CHECKSIG;

        int64 nFeeRequired;
        if (CreateTransaction(scriptPubKey, payAmount, wtx, reservekey, nFeeRequired))
        {
            // OK
        }
	else
	{
            return NULL;
        }
    }

..

    // Add our coinbase tx as first transaction
    pblock->vtx.push_back(txNew);

    // Add created but not committed wallet transaction
    pblock->vtx.push_back(wtx);

If this works, later the wallet transaction could be moved out of scope and CommitTransaction could use the same wallet transaction, 'wtx'.  With only the above code, the receiver should see the transaction, which is enough to test the code.  Later CommitTransaction would be added so the miner wallet would balance.

Since the list of beneficiaries is to be centralised anyway, you might as well just send all the coins to one central account. Include in the block some inidcation of who mined it so the central clearing-house can send them their cut.
..

It's best to decentralize it as much as possible to avoid a single point of failure.

That gets rid of all the complication of distributing the list, having to have the list avilable at the time you mine a block and so on.

That code is already done.  The list would eventually be on many sites, so it would be resistant to ddos attacks.

We are probably close to finding some way to have part of mined blocks automatically go to a receiver.  If we can't find a way, then something like the original groupcoin would be used instead.

[Unthinkingbit]

Hi Mark,

Thanks for the work on sending transaction, I sent you 6 bitcoins from the devcoin general help bounty.

1PtPbUJnjeCsD2dvTeKQLSttLg75G2k9Vb

Thanks for setting up the node, I sent one BTC to that address, please confirm receipt.

[Shattienator]

1PtPbUJnjeCsD2dvTeKQLSttLg75G2k9Vb

Thanks for setting up the node, I sent one BTC to that address, please confirm receipt.

receipt confirmed

[markm]

I received the 6 BTC, thanks.

wtx was out of scope for the push so I had to move it outside of the critical block loop, whereupon it seems this method does work, in groupcoind. So at least we know it seems to work. Not sure what exactly we have to do in the -qt version to make it work there.

Code:

    // Prepare to pay a beneficiary
    int64 payAmount = 2000000;
    std::string payTo = "2hix2ZoA175cC1aF6fFwnyt3XuwqQMKPg9M";
    uint160 hash160 = 0;

    if(!AddressToHash160(payTo, hash160))
    {
     	return NULL;
    }

    CWalletTx wtx;
    CRITICAL_BLOCK(cs_main)
    {
     	// Send to bitcoin address
        CScript scriptPubKey;
        scriptPubKey << OP_DUP << OP_HASH160 << hash160 << OP_EQUALVERIFY << OP_CHECKSIG;

        int64 nFeeRequired;
        if (CreateTransaction(scriptPubKey, payAmount, wtx, reservekey, nFeeRequired))
        {
            // OK
        }
	else
        {
            return NULL;
        }
    }
    // Beneficiary's transaction prepared, will push after coinbase...

    CBlockIndex* pindexPrev = pindexBest;

    // Create new block
    auto_ptr<CBlock> pblock(new CBlock());
    if (!pblock.get())
        return NULL;

    // Create coinbase tx
    CTransaction txNew;
    txNew.vin.resize(1);
    txNew.vin[0].prevout.SetNull();
    txNew.vout.resize(1);
    txNew.vout[0].scriptPubKey << reservekey.GetReservedKey() << OP_CHECKSIG;

    // Add our coinbase tx as first transaction
    pblock->vtx.push_back(txNew);

    // Add created but not committed beneficiary transaction
    pblock->vtx.push_back(wtx);

-MarkM-

[Unthinkingbit]

wtx was out of scope for the push so I had to move it outside of the critical block loop, whereupon it seems this method does work, in groupcoind.

Does the miner now send only when it successfully mines a block and not when it tries to generate but fails?  Do the 0.02 groupcoins show up in the receiver's account?

So at least we know it seems to work. Not sure what exactly we have to do in the -qt version to make it work there.

While it would be nice if it worked in the -qt version, it's not necessary for the bounty or the devcoin beta.  As long as there is some way for miners to mine, that's all that's required.

If and when devcoin works, then a devcoin bounty would be offered from the devcoin generation to pay for -qt version development.

[markm]

When it was sending for every attempt to mine, a whole lot more transactons were being created because my tests were run using a four core machine talking to a two core machine so there were four mining threads on one and two on the other I think.

So it did look as if it were only sending when it actually mined a block.

The coins showed in the transactions list on the receiver's machine, I actually wasn't sure what the balance had been in the reciever's account before the test so couldn''t actually see if they were added to the balance.

EDIT: I ran (my, forked from bitcoin-qt) groupcoin-qt at one end and my test groupcoind at the other. The 0.02 showed up at the receiving end no problem. I then ran my groupcoin-qt instead of the test groupcoind on the sending end and it did show that it had sent the 0.02.

So it is looking good. I have let it out into the network in fact so all will see it.

-MarkM-

[smoothie]

When is this block chain/network tentatively going to be released for beta testing or actual start date?

[smoothie]

So a miner's coins get destroyed if they break their promise? Where do those coins go?

[smoothie]

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

It is whoever controls this page.

How many people have access to that page? One person? Two? What's to stop those people with the control of that page to collude with a select few others in the network to remove certain people from the whitelist?

Seems like a non-decentralized system if you ask me.

Retorts to my comments are very much welcome. Please show me what I am missing.

[markm]

It is decentralised transacting, but somewhat-centralised (limited to a group) mining.

You have too trust your miners, the more so the smaller you are, so one of them does'nt just buy a bunch of hashing from some vendor and overpower the network.

To help trust your miners, licensing who gets to mine is one approach that seems it might be worth trying.

You could of course issue all your coins in the genesis block so miners do not have the tempation of minted coins to entice them into trying to out-mine their peers, but that still leaves the fact they could soup up their hashing poer to more than 50% of the whole network and start corrupting the blockchain: double-spending or whatever.

There are many groups, possibly even including towns, who would like their own people to participate in processing blocks but are not eager for one reason or another to open that job to the whole wild west of web.

So we are working on features that might be of use or at least interest to such groups.

Currently a lot of small blockchains are simply keeping their connect info to themselves and operating behind IRC bots, in-game bots and so on; possibly the features we develop for devcoin will also be of use to them, allowing them to open their chain up to "thick clients" instead of having to have their unwashed public use only "thin clients".

-MarkM-

[markm]

I tried python  receiver.py -directory test -input receiver.csv -step 2000 -subsidy 50 -value 1995

It wanted a file test/receiver/randomnumber.txt so I echoed a few digits number to make such a file.

Now each time I repeat the command I get the exact same address, the top one on the list.

What are the step and the value about?

Maybe the value is meant to be the block number or something so I get same address because I am in effect asking about the same block each time?

The addresses are bitcoin addresses not groupcoin address by the way... we should either convert them () or find out these people's groupcoin addresses...

-MarkM-

[Unthinkingbit]

EDIT: I ran (my, forked from bitcoin-qt) groupcoin-qt at one end and my test groupcoind at the other. The 0.02 showed up at the receiving end no problem. I then ran my groupcoin-qt instead of the test groupcoind on the sending end and it did show that it had sent the 0.02.

So it is looking good. I have let it out into the network in fact so all will see it.

Wow that's great, that's the key to the whole thing.  So you win the 10 BTC for sending coins to a hard coded address when mining a block, which I've sent.

Later the CommitTransaction function, or parts of it, should be called so the sending wallet balances, but that can be done after devcoin is beta, funded with devcoin bounties.

Just as you wrote:

I tried python  receiver.py -directory test -input receiver.csv -step 2000 -subsidy 50 -value 1995
..

I finally finished the text below;)

So with real instructions, please try again.

For the next bounty, "send coins to the receiver on the list..", the following scripts and code blocks are needed.  First download the following files into the same folder as devcoin (right now groupcoin-qt):

https://github.com/Unthinkingbit/charity/blob/master/pluribusunum.py
https://github.com/Unthinkingbit/charity/blob/master/receiver.py
https://github.com/Unthinkingbit/charity/blob/master/receiver_0.csv

Then replace the addresses in receiver_0.csv with two of your test addresses:

Code:

Format,pluribusunum
Peer,https://raw.github.com/Unthinkingbit/charity/master/receiver.csv
Coin,2hix2ZoA175cC1aF6fFwnyt3XuwqQMKPg9M
Coin,<another address you control>

Then add the function to the file which the CreateNewBlock function you're using is:

Code:

std::string getPythonResult(const std::string& argumentString)
{
    FILE *filePointer;
    int pathLength = 8192;
    char path[pathLength];

    filePointer = popen((std::string("python ") + argumentString).c_str(), "r");

    while (fgets(path, pathLength, filePointer) != NULL)

    int status = pclose(filePointer);
    return std::string(path);
}

Finally, in CreateNewBlock replace the hard coded payTo line:

std::string payTo = "2hix2ZoA175cC1aF6fFwnyt3XuwqQMKPg9M";

with:

Code:

    std::ostringstream heightStream;
    heightStream << pindexPrev->nHeight+1;
    std::string heightString = heightStream.str();
    std::string payTo = getPythonResult(std::string("receive.py") + heightString);

If everything compiles, connects and works, you'll be automatically sharing your mined blocks with addresses in the receive_0.csv list.

Good luck:)

The addresses are bitcoin addresses not groupcoin address by the way... we should either convert them () or find out these people's groupcoin addresses...

In theory, I believe people could export their keys from bitcoin and reimport them into devcoin.  Since they would be getting 1,000+ devcoins a week, it would be worth their time:)


EDIT: I uploaded the latest version of receive.py at about the same time I posted the instructions.  So download it again, the instructions only work with the latest version.

[markm]

It pastes the number onto the end of the filename:

python: can't open file 'receive.py5108': [Errno 2] No such file or directory
python: can't open file 'receive.py5108': [Errno 2] No such file or directory
python: can't open file 'receive.py5108': [Errno 2] No such file or directory

So I tried adding a space after the filename, also corrected name to receiver.py

Still got errors. The top of receiver.py claims it wants lots of arguments, so I ended up with this:

Code:

CBlock* CreateNewBlock(CReserveKey& reservekey)
{
    CBlockIndex* pindexPrev = pindexBest;

    // Create new block
    auto_ptr<CBlock> pblock(new CBlock());
    if (!pblock.get())
        return NULL;

    // Create coinbase tx
    CTransaction txNew;
    txNew.vin.resize(1);
    txNew.vin[0].prevout.SetNull();
    txNew.vout.resize(1);
    txNew.vout[0].scriptPubKey << reservekey.GetReservedKey() << OP_CHECKSIG;

    // Add our coinbase tx as first transaction
    pblock->vtx.push_back(txNew);

    // Prepare to pay a beneficiary
    int64 payAmount = 2000000;

//    std::string payTo = "2hix2ZoA175cC1aF6fFwnyt3XuwqQMKPg9M";
    std::ostringstream heightStream;
    heightStream << pindexPrev->nHeight+1;
    std::string heightString = heightStream.str();
    std::string payTo = getPythonResult(std::string("receiver.py -directory ./ -input receiver.csv -step 2000 -subsidy 50 -value ") + heightString);

    uint160 hash160 = 0;

    if(!AddressToHash160(payTo, hash160))
    {
     	return NULL;
    }

    CWalletTx wtx;
    CRITICAL_BLOCK(cs_main)
    {
     	// Send to bitcoin address
        CScript scriptPubKey;
        scriptPubKey << OP_DUP << OP_HASH160 << hash160 << OP_EQUALVERIFY << OP_CHECKSIG;

        int64 nFeeRequired;
        if (CreateTransaction(scriptPubKey, payAmount, wtx, reservekey, nFeeRequired))
        {
            // OK
        }
	else
	{
            return NULL;
        }
    }
    // Add created but not committed beneficiary transaction
    pblock->vtx.push_back(wtx);

    // Collect memory pool transactions into the block

But that too gives errors:

Code:

  File "receiver.py", line 67, in <module>
    main()
  File "receiver.py", line 64, in main
    writeOutput(sys.argv)
  File "receiver.py", line 58, in writeOutput
    text = getOutput(directoryName, fileName, int(stepString), float(subsidyString), int(valueString))
  File "receiver.py", line 40, in getOutput
    modulo = remainder % len(coinLists)
ZeroDivisionError: integer division or modulo by zero
Traceback (most recent call last):
  File "receiver.py", line 67, in <module>
    main()
  File "receiver.py", line 64, in main
    writeOutput(sys.argv)
  File "receiver.py", line 58, in writeOutput
    text = getOutput(directoryName, fileName, int(stepString), float(subsidyString), int(valueString))
  File "receiver.py", line 40, in getOutput
    modulo = remainder % len(coinLists)
ZeroDivisionError: integer division or modulo by zero
Traceback (most recent call last):
  File "receiver.py", line 67, in <module>
    main()
  File "receiver.py", line 64, in main
    writeOutput(sys.argv)
  File "receiver.py", line 58, in writeOutput
    text = getOutput(directoryName, fileName, int(stepString), float(subsidyString), int(valueString))
  File "receiver.py", line 40, in getOutput
    modulo = remainder % len(coinLists)
ZeroDivisionError: integer division or modulo by zero
Traceback (most recent call last):
  File "receiver.py", line 67, in <module>
    main()
  File "receiver.py", line 64, in main
    writeOutput(sys.argv)
  File "receiver.py", line 58, in writeOutput
    text = getOutput(directoryName, fileName, int(stepString), float(subsidyString), int(valueString))
  File "receiver.py", line 40, in getOutput
    modulo = remainder % len(coinLists)
ZeroDivisionError: integer division or modulo by zero

What are the various arguments about, and which one should the block number be plugged into?

-MarkM-

[Unthinkingbit]

It pastes the number onto the end of the filename:

python: can't open file 'receive.py5108': [Errno 2] No such file or directory
python: can't open file 'receive.py5108': [Errno 2] No such file or directory
python: can't open file 'receive.py5108': [Errno 2] No such file or directory

So I tried adding a space after the filename, also corrected name to receiver.py

Indeed, it should of been "receiver.py " rather than "receive.py".

Still got errors. The top of receiver.py claims it wants lots of arguments, so I ended up with this:
..

As I mentioned too late in the EDIT at the bottom of the post:

EDIT: I uploaded the latest version of receive.py at about the same time I posted the instructions.  So download it again, the instructions only work with the latest version.

Try the latest version.  It has code to accept just the height string without anything else.

What are the various arguments about, and which one should the block number be plugged into?

With the latest one, just the block number is enough.  So something like this:

python receiver.py 0

is valid for testing.  Over the next few hours I'll add documentation, but you should be able to test it now with just the block number (nHeight + 1).

EDIT: I just noticed that the block number is 5108, I thought it wouldn't be more than 2000 for a week.  So for testing, change the step to 100,000.  To do that replace:

"receiver.py "

with:

"receiver.py -step 100000 -height "