CREDITS [CRE] | SHA256 | SIDECHAIN | NEW BLOCK-DEPOSIT FEATURE | OFFICIAL THREAD

[Gabriel Eiger]

Nodes? After a half dozen tries, I successfull transplanted the BTC chain, but the Credits chain isn't coming.

Have you tried:
a) checking the log via Help > Credits debug window > Information > Debug log file > Open. If there is output coming there the Credits blockchain is probably downloading.
b) Restarting the client. I've seen situations where the Credits blocks doesn't start to download until a restart, probably due to timeout of the Credit nodes waiting for the Bitcoin blockchain download.

You could also check Help > Credits Debug Window > Peers and see if you are connected to peers.

Restarted it loads of times, and I am connected to peers, but I don't seem to be exchanging more than a few KB from them.

EDIT: Also, an IRC channel would be quite nice - I'm on IRC far more than I'm on here.

Good point about IRC. I'll see if we can arrange something in the coming days.

[1715652106]

1715652106

[1715652106]

1715652106

[1715652106]

1715652106

[MRKLYE]

Hey wolf did you make sure your copy of the blockchains had the read only attribute off?

Not sure if that's the fix but I'd check it out. Gab is the expert here, I'm just a lowly miner.

[Gabriel Eiger]

Nodes? After a half dozen tries, I successfull transplanted the BTC chain, but the Credits chain isn't coming.

Have you tried:
a) checking the log via Help > Credits debug window > Information > Debug log file > Open. If there is output coming there the Credits blockchain is probably downloading.
b) Restarting the client. I've seen situations where the Credits blocks doesn't start to download until a restart, probably due to timeout of the Credit nodes waiting for the Bitcoin blockchain download.

You could also check Help > Credits Debug Window > Peers and see if you are connected to peers.

Restarted it loads of times, and I am connected to peers, but I don't seem to be exchanging more than a few KB from them.

Strange, have you checked the debug.log output? If there are log output coming it is probably synching the Credits blockchain. Unfortunately the ui seems to be lagging quite a bit on the initial blockchain download. debug.log is where to look if you want to know what is really happening. Do you know where to find it and could you send me a sample of the end of it?

Near the top is of interest:

Code:

2015-04-27 21:15:58 ERROR: Bitcredit: ConnectTip() : ConnectBlock 000000005fc6f4b75a16b644bc1bd975ec71e7bdfab3144d84915d0efae490d2 failed
2015-04-27 21:15:58 ERROR: Bitcredit: AcceptBlock() : ReceivedBlockTransactions failed
2015-04-27 21:15:58 ERROR: Bitcredit: ProcessBlock() : AcceptBlock FAILED
2015-04-27 21:15:58 Bitcredit: ConnectTip() : No tmp db created, in fast forward state, claim tip is -335816 bitcoin blocks ahead
2015-04-27 21:15:58 ERROR: Bitcredit: Bitcoin block to check for claiming 0000000000000000000000000000000000000000000000000000000000000000 not found in bitcoin blockchain!

Also, for those who were asking, yes, this coin is SHA256d, no, ASICs cannot mine it, and nor can any current GPU mining implementation used with Bitcoin.

There appears to be inconsistencies in the internal state between the blockchains. That's a problem.

There is no way to correct that, without restarting the client with the argument -reindex, and that reindex is going to take a long time.

If you didn't do that before, I suggest you initialise from this pre-updated torrent.
http://credits-currency.org/viewtopic.php?f=18&t=517

And which version are you running?

[Gabriel Eiger]

"Also, for those who were asking, yes, this coin is SHA256d, no, ASICs cannot mine it, and nor can any current GPU mining implementation used with Bitcoin."

To add to that, I am not aware of the implementation details of GPU miners and ASICs but have a feeling that they are only moving one specific part of the mining process to specialised hardware. If that is the case, it shouldn't be to difficult to retrofit the Credits source code to run with a GPU/ASIC.

[Gabriel Eiger]

"Also, for those who were asking, yes, this coin is SHA256d, no, ASICs cannot mine it, and nor can any current GPU mining implementation used with Bitcoin."

To add to that, I am not aware of the implementation details of GPU miners and ASICs but have a feeling that they are only moving one specific part of the mining process to specialised hardware. If that is the case, it shouldn't be to difficult to retrofit the Credits source code to run with a GPU/ASIC.

I have studied pretty much every GPU mining OpenCL kernel out there, and improved almost all of them - believe me, SHA256d is EXTREMELY well done, and it takes full advantage of the known 80-byte input. ASICs I don't work with often, but I do know that they accept data and a target, then return nonces. For the hardware to be better optimized, the hardware implementation would have to take advantage of the known input size as well - I'm almost certain this is the case.

When you are saying the 80-byte input, are you saying that they take the whole header of a block and hash over that? I assumed that only the final sha256, after the midstate has been calculated, was input to the GPU. The header of a Credits block is rather different from a header of a Bitcoin block. BUT, it does the same rounds of midstate calculations, but some more of them, since the header is larger in size.
http://credits-currency.org/viewtopic.php?f=24&t=635

[Gabriel Eiger]

Nodes? After a half dozen tries, I successfull transplanted the BTC chain, but the Credits chain isn't coming.

Have you tried:
a) checking the log via Help > Credits debug window > Information > Debug log file > Open. If there is output coming there the Credits blockchain is probably downloading.
b) Restarting the client. I've seen situations where the Credits blocks doesn't start to download until a restart, probably due to timeout of the Credit nodes waiting for the Bitcoin blockchain download.

You could also check Help > Credits Debug Window > Peers and see if you are connected to peers.

Restarted it loads of times, and I am connected to peers, but I don't seem to be exchanging more than a few KB from them.

Strange, have you checked the debug.log output? If there are log output coming it is probably synching the Credits blockchain. Unfortunately the ui seems to be lagging quite a bit on the initial blockchain download. debug.log is where to look if you want to know what is really happening. Do you know where to find it and could you send me a sample of the end of it?

Near the top is of interest:

Code:

2015-04-27 21:15:58 ERROR: Bitcredit: ConnectTip() : ConnectBlock 000000005fc6f4b75a16b644bc1bd975ec71e7bdfab3144d84915d0efae490d2 failed
2015-04-27 21:15:58 ERROR: Bitcredit: AcceptBlock() : ReceivedBlockTransactions failed
2015-04-27 21:15:58 ERROR: Bitcredit: ProcessBlock() : AcceptBlock FAILED
2015-04-27 21:15:58 Bitcredit: ConnectTip() : No tmp db created, in fast forward state, claim tip is -335816 bitcoin blocks ahead
2015-04-27 21:15:58 ERROR: Bitcredit: Bitcoin block to check for claiming 0000000000000000000000000000000000000000000000000000000000000000 not found in bitcoin blockchain!

Also, for those who were asking, yes, this coin is SHA256d, no, ASICs cannot mine it, and nor can any current GPU mining implementation used with Bitcoin.

There appears to be inconsistencies in the internal state between the blockchains. That's a problem.

There is no way to correct that, without restarting the client with the argument -reindex, and that reindex is going to take a long time.

If you didn't do that before, I suggest you initialise from this pre-updated torrent.
http://credits-currency.org/viewtopic.php?f=18&t=517

And which version are you running?

I ran latest git, when that didn't work, compiled v0.9.1.30-g7605e64-beta and went with that. I'll reindex.

Ok, you are a bit out on a ledge here since running from the builds hasn't been very thoroughly tested. I would still recommend the torrent file, but go ahead and try a reindex if you want to. I'll give any support I can.

[Gabriel Eiger]

Ok, you are a bit out on a ledge here since running from the builds hasn't been very thoroughly tested. I would still recommend the torrent file, but go ahead and try a reindex if you want to. I'll give any support I can.

Reindex appears to be working. Just... you know, slowly.

Yeah, hope so. The critical part is (unfortunately) when you change from Bitcoin blockchain reindex to Credits blockchain reindex. That's when the chainstate keeping track of the in-between Credits and Bitcoin state might get messed up.

Still not reconsidering dl'ing the torrent?

[Gabriel Eiger]

When you are saying the 80-byte input, are you saying that they take the whole header of a block and hash over that? I assumed that only the final sha256, after the midstate has been calculated, was input to the GPU. The header of a Credits block is rather different from a header of a Bitcoin block. BUT, it does the same rounds of midstate calculations, but some more of them, since the header is larger in size.
http://credits-currency.org/viewtopic.php?f=24&t=635

You're right, I was actually thinking of other algos when I said that - the midstate is what they use... meaning... GPU implementations may be adaptable, but I don't think ASICs will be. However, those GPU implementations are optimized for VLIW5/VLIW4 last I checked.

I am pretty much convinced that a GPU miner can be adapted in a straightforward way if one's familiar with the GPU code being adapted.

[Gabriel Eiger]

Ok, you are a bit out on a ledge here since running from the builds hasn't been very thoroughly tested. I would still recommend the torrent file, but go ahead and try a reindex if you want to. I'll give any support I can.

Reindex appears to be working. Just... you know, slowly.

Yeah, hope so. The critical part is (unfortunately) when you change from Bitcoin blockchain reindex to Credits blockchain reindex. That's when the chainstate keeping track of the in-between Credits and Bitcoin state might get messed up.

Still not reconsidering dl'ing the torrent?

I AM downloading the torrent, I just want it done faster. If I don't need the torrent, I'll finish the DL and seed anyways.

I get it! Would like to get you started with the client/mining, so just write here or PM with any questions.

[Gabriel Eiger]

Well, while I'm sitting here waiting, it'd be great if you'd give me the output of getwork to look over. Works from the debug console.

{
"midstate" : "c25d21dfba0c7ddff059ec94ca5b04b1982845ff5c1a48f9fa98f1f6c2653ea8",
"data" : "000000016f05e1c9f096b3fbe2cd3d8b8deda68a76e90391d63f41d70852a3aa00000000a9c1fef 85cb9855993d257d2215609c3bfef14ed6c56f152a37782c3ff528d0bc68abbc4952d5b1f15cff4 80435a25667375de69037bec410000000000000000ced3fa32fe3b8f390c2687ce3a9728a999654 95fecf077eb08d854f5",
"hash1" : "0000000000000000000000000000000000000000000000000000000000000000000000800000000 0000000000000000000000000000000000000000000010000",
"target" : "0000000000000000000000000000000000000000000000000005850b00000000"
}

I would take the info in here with a LARGE grain of salt because getwork hasn't been updated or verified to work after release. Coin still to young and other areas have had more focus. There are comments specifically for this function in the code that it will be reviewed and probably not work for the moment.

But if you want some other specifics I could probably give it to you.

[Gabriel Eiger]

All I want is a correct data parameter from getwork - I couldn't care less about the midstate at this point. If you've got the correct hash for it, making it a test vector, that'd be even better.

Ok, problem is that the buffer right now is too small, have a look in rpcmining.cpp

Code:

        // Pre-build hash buffers
        char pmidstate[32];
        char pdata[128];
        char phash1[64];
        FormatHashBuffers(pblock, pmidstate, pdata, phash1);

I would have to recompile the client and verify that the values coming out are indeed correct. Probably won't be able to do that until you are finished with your dl/reindex.

[Gabriel Eiger]

I'm totally not sure about this, but there may be a bug - I think the code is looking for Bitcoin block 0... isn't the genesis block not stored? I remember reading something about it must be manually input in Abe because it's not in the copy of the chain on disk.

The genesis block is stored BUT NOT in the chainstate db. This is probably what you are referring to. Did you get the same problem again?

In that case, there may be a bug. I actually think I know what the problem is in that case - the genesis block of Credits has the genesis block of Bitcoin as it's linked Bitcoin block. Adding the Credits block may therefore be an exceptional case. It's just strange that this hasn't occurred when I've done test syncs. The error could possibly have been added in the last release.

[Gabriel Eiger]

I'm totally not sure about this, but there may be a bug - I think the code is looking for Bitcoin block 0... isn't the genesis block not stored? I remember reading something about it must be manually input in Abe because it's not in the copy of the chain on disk.

The genesis block is stored BUT NOT in the chainstate db. This is probably what you are referring to. Did you get the same problem again?

In that case, there may be a bug. I actually think I know what the problem is in that case - the genesis block of Credits has the genesis block of Bitcoin as it's linked Bitcoin block. Adding the Credits block may therefore be an exceptional case. It's just strange that this hasn't occurred when I've done test syncs. The error could possibly have been added in the last release.

Could you send me the first Credits block, or the Credits chain, if it's small? This bootstrap torrent is stalling a lot, slow when it does work, and I don't need the BTC chain.

Sure, I can send you the blocks directory only for Credits, it's probably doable by mail. Address?

My apologies for the extra work you've been having.

[MRKLYE]

Credits (CRE) official chat

Just letting everyone know that the IRC channel #CreditsCurrency has been setup on freenode.net to be the Credits (CRE) Official Chat.
This has been set up with Gabriel's permission and is to be used for matter related to Credits (CRE) and its development and use.

If you have any questions or would like to get involved please stop in and say hello.
(If anyone knows how I can link a web based IRC client configured to go there please let me know!)

[striker7334 2.0]

Well Im seeding away for you guys, too bad i couldn't upload this to sharecash it would be faster for everyone and I would make a few $ on the side.

[Gabriel Eiger]

Well Im seeding away for you guys, too bad i couldn't upload this to sharecash it would be faster for everyone and I would make a few $ on the side.

Up and running with a miner?

[striker7334 2.0]

The Bitcredit chain is taking forever, I went to sleep for four hours and it only downloaded about maybe 60 blocks since then. Anyway to speed it up?

[Gabriel Eiger]

The Bitcredit chain is taking forever, I went to sleep for four hours and it only downloaded about maybe 60 blocks since then. Anyway to speed it up?

That sounds strange. Are you saying that you have unpacked the directory from the torrent and synching the last part that wasn't included in the torrent? That should happen in, 20 minutes or so.

Could you send me a sample of the end of your debug.log file from your working directory? Here or as a PM.

[Gabriel Eiger]

Rules of engagement - how deposits work

This is a description of the functionality of deposits and their role in the block creation process.
It can also be found at: http://credits-currency.org/viewtopic.php?f=24&t=755

In this description there are two roles that acts to create a block, miner and depositor. In many cases both roles are the same entity. But as time passes they will probably separate into two distinct roles.

Every block must have between one and ten deposits added to it. A deposit is a transaction, holding an amount of CRE, usually sent to an address that the depositor controls. One specific functionality separates a deposit transaction from a normal transaction, namely an extra public key that is used by the depositor to approve the inclusion in a block, when the block is assembled.

A miner creates a block in the normal way. Each block has a requirement for deposits that should be added to the block. Depositors can offer up deposits for inclusion in a block. The miner selects a number of deposits that they want to include.

Once a block has been assembled, the miner informs the depositors that their deposit has been selected for inclusion in a block that the miner is about to create. If the depositor approves of the inclusion in the block, they use their private key to sign the whole block, thereby approving it. This is what the extra public key that is included in a deposit transaction is for.

When all signatures have been gathered the miner can start hashing the block to find a solution to the normal hashing challenge. Eventually a block is found.

When the block is found and announced, all deposits will be locked into the block until they are released 15 000 blocks later.

Where do the deposit requirement come from?
 - The rules are actually quite simple. The required deposit for each block is 1 / 30 000 of the total monetary base. The total monetary base is all coins that have been created up until that block, plus all coins that have been claimed from Bitcoin up until that block. So for example, if 100 000 Bitcoins have been claimed and we are at block 18 000 where all blocks have given a reward of 40 CRE, the total monetary base will be 18 000 * 40 + 100 000 = 820 000 CRE.
The required deposit for next block will then be 820 000 / 30 000 = 27.33 CRE.
Yes, this means that the deposit requirement will continue to rise when new blocks are mined. For example when 18 000 000 of all CRE have been mined or obtained through claiming, the required deposit will be 18 000 000 / 30 000 = 600 CRE per block.

What happens if the full required deposit isn’t added?
A block must have at least one deposit transaction with a non zero output. If the deposit isn’t fulfilled, the difficulty for the block for that individual miner will raise with a factor calculated from the amount of missing deposits. If the requirement is 50 CRE and only 25 CRE have been added as deposit, the difficulty will double.
For example, if the difficulty is 120, and only 25 CRE of the required 50 CRE are added to the block, the difficulty for that specific miner will double to 240.

One extra effect will also occur when half of all coins (15 000 000) have been mined. On top of the higher difficulty, the reward will also be lowered in the same way. With a reward of 80 CRE, requirements for 50 CRE as deposit, and only 25 CRE given, the maximum reward that can be gained from the block is 80 * (25 / 50) = 40 CRE.

But I’m already mining and I haven’t created any deposits?
Actually you have, its just the software that is taking care of it automatically for you. The reward (coinbase) that is added to each block can be spent directly by a deposit transaction in the same block. As long as the reward for a block is higher than the required deposit, all miners can use the reward and add it to cover the full deposit. There’s a tipping point at approximately block 33 000 when the deposit requirement will become larger than the reward. At first, it doesn’t really make much of a difference, since the difficulty will only be marginally higher for miners without extra deposits. But as the blockchain progresses, the requirement to add extra deposits will grow larger and larger.

Must I lockup the whole reward in deposit if I use it as input to a deposit transaction?
No. A deposit can send coins to two outputs. The first output, which always must exist, is the deposit output. Once included in a block, it can not be used in any way for 15 000 blocks.
The other output, which is optional, is the deposit change output. To this output all extra coins can be sent. The deposit change can be used after the same time as it takes rewards to mature, that is, after 101 blocks.

[SpiryGolden]

Looks interesting

Any online exchange for it ?