nice work Gabriel.
Thank you.
Topic: [ANN] Bitcredit/CRE - first sidechain, claimable from Bitcoin, pow/pod - page 6. (Read 12967 times)
April 19, 2015, 03:24:27 PM
April 19, 2015, 02:11:57 PM
nice work Gabriel.
April 19, 2015, 02:11:09 PM
Bitcredit source code released soon
The Bitcredit source code will be released as soon as possible, hopefully within a week.
Announcements will be made here and in the newly created subreddit http://www.reddit.com/r/Bitcredit/.
If you want to get involved in the development, just write a reply in this thread.
The Bitcredit source code will be released as soon as possible, hopefully within a week.
Announcements will be made here and in the newly created subreddit http://www.reddit.com/r/Bitcredit/.
If you want to get involved in the development, just write a reply in this thread.
April 19, 2015, 02:07:55 PM
On demand, an initial description of the Bitcredit block structure can be found here:
http://bitcredit-currency.org/viewtopic.php?f=24&t=635
----------------------------------------------------------------
The Bitcredit protocol differs from the Bitcoin protocol in several aspects but there are also a lot of similarities.
The protocol documentation of Bitcoin is a good starting place, since most of the concepts described in there are applicable to Bitcredit as well, for example hashes, merkle trees, transaction signatures, verifications and more.
https://en.bitcoin.it/wiki/Protocol_documentation
The major differences in the Bitcredit protocol is a more extensive header for each block, a signature section, different formats for the transactions, plus a new transaction type, deposit.
Basic structure of a block
A block consists of:
1. A block header
2. Signatures
3. One coinbase transaction
4. One to ten deposit transactions
5. All other transactions
The block header
The block header has several similarities with Bitcoin. The header has the following fields, in the order listed:
- int nVersion - Block version information. Same as Bitcoin.
- uint256 hashPrevBlock - The hash value of the previous block this particular block references. Same as Bitcoin.
- uint256 hashMerkleRoot - The reference to a Merkle tree collection which is a hash of all transactions related to this block. Same as Bitcoin.
- uint256 hashLinkedBitcoinBlock - A reference to the Bitcoin block that this block is linked to.
- uint256 hashSigMerkleRoot - The reference to a Merkle tree collection which is a hash of all signatures related to this block.
- unsigned int nTime - A timestamp recording when this block was created. Same as Bitcoin.
- unsigned int nBits - The calculated difficulty target being used for this block. Not used the same as in Bitcoin, but also affected by the deposits added to this block.
- unsigned int nNonce - The nonce used to generate this block… to allow variations of the header and compute different hashes. Same as Bitcoin.
- uint64_t nTotalMonetaryBase - The sum of all rewards given plus all bitcoins that have been claimed up to and including this block.
- uint64_t nTotalDepositBase - The same value as above, with the difference that coins that hasn't moved for a very long time gets subtracted.
- uint64_t nDepositAmount - The deposit amount added to this block. This number must correspond to the sum of all deposits in this block.
Signatures
- std::vector vsig - the signatures do not correspond to anything in a Bitcoin block. The signature list is a list of signatures given from each deposit that is included in this block. The signature corresponds to a key that is included in each deposit transaction and is a signature from the creator of the deposit that approves the inclusion of the deposit in this specific block.
The signatures will also be used for other purposes in the future, for example as a security measure where a receiver of a transaction can sign a trasnaction to show that the transaction is in fact correct and addressed to the correct receiver before it can be included in a block.
Transactions, general structure
All transactions conforms to mostly the same format, with certain minor differences, depending on the type.
The following fields makes up a transaction in Bitcredit:
- int nVersion - Transaction data format version. Same as Bitcoin.
- unsigned int nTxType - The type of the transaction. This does not exist in Bitcoin. For the moment the types COINBASE, DEPOSIT and STANDARD exists, but more types are planned for inclusion, for extended transaction functionality.
- std::vector vin - All transaction inputs. Different data type than Bitcoin. See description below.
- std::vector vout - All transaction outputs. Same as Bitcoin.
- CKeyID signingKeyId - A signing key id. This field only exists for deposits for the moment.
- unsigned int nLockTime - The transaction may not be added to a block until after nLockTime. Same as Bitcoin.
Transaction inputs
Transaction inputs differs from Bitcoin transaction inputs in that the nSequence field does not exist. The sequence field is (probably) an experimental feature that never have been implemented. The removal of this unimplemented field is twofold, first and foremost, to make transactions more compact. With a rising transaction rate it is important that the transaction byte size can be kept as small as possible. A standard transaction should really ideally be possible to compress even more since some bytes appear to be unnecessary large and can be compacted more. The second reason is security and complexity, since the removed field is intended for a replacement functionality. That replacement functionality could potentially cause security issues.
The following fields makes up a transaction input in Bitcredit:
- COutPoint prevout - The previous output transaction reference, as an OutPoint structure. Same as Bitcoin.
- CScript scriptSig - Computational Script for confirming transaction authorization. Same as Bitcoin.
The coinbase transaction
The coinbase transaction has the same function as in Bitcoin, for distributing rewards to miners. There are however some implementation differences between Bitcoin and Bitcredit.
- A coinbase transaction must have its nTxType field set to type COINBASE.
- A Bitcoin coinbase can not be spent until 101 blocks have been generated after the block containing the coinbase. It is the same in Bitcredit but with one exception, a deposit in the same block as the coinbase can spend the coinbase directly, thereby moving the newly created coins directly to deposit. This can be done to make it possible for new miners to get hold of coins to use as deposit directly, instead of trying to buy it from elsewhere. It also solves the problem of providing deposit for the genesis block, since before the genesis block there exists no bitcredits at all.
- The Bitcoin coinbase transaction enforces that the single input that it cointains references nothing. In Bitcredit this input is instead used for two purposes. The first is to provide a place for the so called extranonce. The extranonce is added into the CScript in Bitcoin, where in Bitcredit it is instead using the n field in the prevout member. The second purpose is that the hash field in the prevout member is used to store a hash of most of the fields in the Bitcredit block header. This makes sure that all coinbase transactions are unique and cannot be reused in other blocks, or by other miners mining on a separate chain.
The deposit transactions
The deposit transactions are the functionality in Bitcredit that makes it possible to add deposits to a block.
- The deposit transaction must have its nTxType field set to type DEPOSIT.
- The deposit transactions must follow directly after the coinbase transaction.
- There can be between one and ten deposit transactions in a block.
- A deposit transaction can only have one single input and a maximum of two outputs. The first output is the coins that are sent to deposit. This output can not be spent until 15 000 blocks have been added after the current block. The second, optional, output is the deposit change. This output can be spent after 101 blocks. This mechanism allows a depositor to add just the correct amount of coins as deposit.
- For the moment it is only the deposit transaction that has the extra field signingKeyId. This key must sign the whole block once it has been assembled. The signatures are stored in the signatures section of the block. This mechanism enables a depositor to pre-create a deposit ahead of block creation. Once the block has been created, the depositor verifies that he approves the inclusion of the deposit in the block by signing it. This depositor may or may not be the same entity as the miner. By allowing deposits to be created ahead of the block a market where depositors offer up deposits for block creators can be established.
All other transactions
- All other transactions must have its nTxType field set to type STANDARD.
The transactions following the deposit transactions are regular transactions that are handled in the same way that they are handled in Bitcoin. For comparing the difference in transaction structure as compared to Bitcoin, see the section "Transactions, general structure" above.
http://bitcredit-currency.org/viewtopic.php?f=24&t=635
----------------------------------------------------------------
The Bitcredit protocol differs from the Bitcoin protocol in several aspects but there are also a lot of similarities.
The protocol documentation of Bitcoin is a good starting place, since most of the concepts described in there are applicable to Bitcredit as well, for example hashes, merkle trees, transaction signatures, verifications and more.
https://en.bitcoin.it/wiki/Protocol_documentation
The major differences in the Bitcredit protocol is a more extensive header for each block, a signature section, different formats for the transactions, plus a new transaction type, deposit.
Basic structure of a block
A block consists of:
1. A block header
2. Signatures
3. One coinbase transaction
4. One to ten deposit transactions
5. All other transactions
The block header
The block header has several similarities with Bitcoin. The header has the following fields, in the order listed:
- int nVersion - Block version information. Same as Bitcoin.
- uint256 hashPrevBlock - The hash value of the previous block this particular block references. Same as Bitcoin.
- uint256 hashMerkleRoot - The reference to a Merkle tree collection which is a hash of all transactions related to this block. Same as Bitcoin.
- uint256 hashLinkedBitcoinBlock - A reference to the Bitcoin block that this block is linked to.
- uint256 hashSigMerkleRoot - The reference to a Merkle tree collection which is a hash of all signatures related to this block.
- unsigned int nTime - A timestamp recording when this block was created. Same as Bitcoin.
- unsigned int nBits - The calculated difficulty target being used for this block. Not used the same as in Bitcoin, but also affected by the deposits added to this block.
- unsigned int nNonce - The nonce used to generate this block… to allow variations of the header and compute different hashes. Same as Bitcoin.
- uint64_t nTotalMonetaryBase - The sum of all rewards given plus all bitcoins that have been claimed up to and including this block.
- uint64_t nTotalDepositBase - The same value as above, with the difference that coins that hasn't moved for a very long time gets subtracted.
- uint64_t nDepositAmount - The deposit amount added to this block. This number must correspond to the sum of all deposits in this block.
Signatures
- std::vector
The signatures will also be used for other purposes in the future, for example as a security measure where a receiver of a transaction can sign a trasnaction to show that the transaction is in fact correct and addressed to the correct receiver before it can be included in a block.
Transactions, general structure
All transactions conforms to mostly the same format, with certain minor differences, depending on the type.
The following fields makes up a transaction in Bitcredit:
- int nVersion - Transaction data format version. Same as Bitcoin.
- unsigned int nTxType - The type of the transaction. This does not exist in Bitcoin. For the moment the types COINBASE, DEPOSIT and STANDARD exists, but more types are planned for inclusion, for extended transaction functionality.
- std::vector
- std::vector
- CKeyID signingKeyId - A signing key id. This field only exists for deposits for the moment.
- unsigned int nLockTime - The transaction may not be added to a block until after nLockTime. Same as Bitcoin.
Transaction inputs
Transaction inputs differs from Bitcoin transaction inputs in that the nSequence field does not exist. The sequence field is (probably) an experimental feature that never have been implemented. The removal of this unimplemented field is twofold, first and foremost, to make transactions more compact. With a rising transaction rate it is important that the transaction byte size can be kept as small as possible. A standard transaction should really ideally be possible to compress even more since some bytes appear to be unnecessary large and can be compacted more. The second reason is security and complexity, since the removed field is intended for a replacement functionality. That replacement functionality could potentially cause security issues.
The following fields makes up a transaction input in Bitcredit:
- COutPoint prevout - The previous output transaction reference, as an OutPoint structure. Same as Bitcoin.
- CScript scriptSig - Computational Script for confirming transaction authorization. Same as Bitcoin.
The coinbase transaction
The coinbase transaction has the same function as in Bitcoin, for distributing rewards to miners. There are however some implementation differences between Bitcoin and Bitcredit.
- A coinbase transaction must have its nTxType field set to type COINBASE.
- A Bitcoin coinbase can not be spent until 101 blocks have been generated after the block containing the coinbase. It is the same in Bitcredit but with one exception, a deposit in the same block as the coinbase can spend the coinbase directly, thereby moving the newly created coins directly to deposit. This can be done to make it possible for new miners to get hold of coins to use as deposit directly, instead of trying to buy it from elsewhere. It also solves the problem of providing deposit for the genesis block, since before the genesis block there exists no bitcredits at all.
- The Bitcoin coinbase transaction enforces that the single input that it cointains references nothing. In Bitcredit this input is instead used for two purposes. The first is to provide a place for the so called extranonce. The extranonce is added into the CScript in Bitcoin, where in Bitcredit it is instead using the n field in the prevout member. The second purpose is that the hash field in the prevout member is used to store a hash of most of the fields in the Bitcredit block header. This makes sure that all coinbase transactions are unique and cannot be reused in other blocks, or by other miners mining on a separate chain.
The deposit transactions
The deposit transactions are the functionality in Bitcredit that makes it possible to add deposits to a block.
- The deposit transaction must have its nTxType field set to type DEPOSIT.
- The deposit transactions must follow directly after the coinbase transaction.
- There can be between one and ten deposit transactions in a block.
- A deposit transaction can only have one single input and a maximum of two outputs. The first output is the coins that are sent to deposit. This output can not be spent until 15 000 blocks have been added after the current block. The second, optional, output is the deposit change. This output can be spent after 101 blocks. This mechanism allows a depositor to add just the correct amount of coins as deposit.
- For the moment it is only the deposit transaction that has the extra field signingKeyId. This key must sign the whole block once it has been assembled. The signatures are stored in the signatures section of the block. This mechanism enables a depositor to pre-create a deposit ahead of block creation. Once the block has been created, the depositor verifies that he approves the inclusion of the deposit in the block by signing it. This depositor may or may not be the same entity as the miner. By allowing deposits to be created ahead of the block a market where depositors offer up deposits for block creators can be established.
All other transactions
- All other transactions must have its nTxType field set to type STANDARD.
The transactions following the deposit transactions are regular transactions that are handled in the same way that they are handled in Bitcoin. For comparing the difference in transaction structure as compared to Bitcoin, see the section "Transactions, general structure" above.
April 19, 2015, 03:56:07 AM
It seems a long time to sync my wallet.
can i mine it with my pc ?
can i mine it with my pc ?
The download time should (with the latest released version) be on par with the time it takes to download the Bitcoin blockchain. As mentioned in another reply, the best way to get started quickly is downloading the torrent provided:
http://bitcredit-currency.org/viewtopic.php?f=18&t=517
Once that is done, make sure the client is in sync:
http://bitcredit-currency.org/viewtopic.php?f=18&t=17
Once that is done, enable the miner with:
"setgenerate true 2"
See this description for further details:
http://bitcredit-currency.org/viewtopic.php?f=18&t=18
April 19, 2015, 02:53:32 AM
Just wanted to let everyone know I've got a Bitcredit faucet on my site.
Once every 24 hours it pays out a small amount of Bitcredit.
Get yours here: kingklye.com Bitcredit faucet
Once every 24 hours it pays out a small amount of Bitcredit.
Get yours here: kingklye.com Bitcredit faucet
April 19, 2015, 02:19:49 AM
It seems a long time to sync my wallet.
can i mine it with my pc ?
yes.can i mine it with my pc ?
The best is to download torrent, extract it, then sync, and mine with "setgenerate true".
April 19, 2015, 02:17:26 AM
It seems a long time to sync my wallet.
can i mine it with my pc ?
can i mine it with my pc ?
April 19, 2015, 12:54:40 AM
I have made bitcredit qt wallet to work.
Can I mine without deposit now?
Some experience from other, please?
thanks
Yes, you can mine without adding a deposit for the moment, or rather, you can use the reward for each block as deposit. This is done automatically by the miner once it is started.Can I mine without deposit now?
Some experience from other, please?
thanks
First, make sure the client is in sync:
http://bitcredit-currency.org/viewtopic.php?f=18&t=17
Once that is done, enable the miner with:
"setgenerate true 2"
See this description for further details:
http://bitcredit-currency.org/viewtopic.php?f=18&t=18
Thanks.
Now is all clear.
Was mining 12 hours, and there are cca 250 CRE in wallet.
April 18, 2015, 04:59:04 PM
I have made bitcredit qt wallet to work.
Can I mine without deposit now?
Some experience from other, please?
thanks
Can I mine without deposit now?
Some experience from other, please?
thanks
Yes, you can mine without adding a deposit for the moment, or rather, you can use the reward for each block as deposit. This is done automatically by the miner once it is started.
First, make sure the client is in sync:
http://bitcredit-currency.org/viewtopic.php?f=18&t=17
Once that is done, enable the miner with:
"setgenerate true 2"
See this description for further details:
http://bitcredit-currency.org/viewtopic.php?f=18&t=18
April 18, 2015, 02:06:57 PM
I have made bitcredit qt wallet to work.
Can I mine without deposit now?
Some experience from other, please?
thanks
Can I mine without deposit now?
Some experience from other, please?
thanks
April 18, 2015, 12:16:35 PM
ok, i'll check back with the next version.
April 18, 2015, 11:34:52 AM
when I click on Claim bitcoins -> Select Coins the wallet freezes..
Which version are you running?
currently the latest, but I had the same problem before. If I understood that correctly, 1 btc = 1 CRE when claiming, so I already mined more coins than I would get claiming from my old btc wallet.
edit: bitcredit-0.9.1.10-win64-binaries
Ok thanks for the input.
The claiming part is a very important functionality for coin distribution and acceptance from Bitcoin holders, so it should of course work as intended. This problem will be addressed as a top priority but I can not give any estimates on when it will be solved. Hopefully in a few days.
I'll keep you posted and would appreciate feedback on if the problem has been solved or not.
April 18, 2015, 08:43:23 AM
when I click on Claim bitcoins -> Select Coins the wallet freezes..
Which version are you running?
currently the latest, but I had the same problem before. If I understood that correctly, 1 btc = 1 CRE when claiming, so I already mined more coins than I would get claiming from my old btc wallet.
edit: bitcredit-0.9.1.10-win64-binaries
April 18, 2015, 08:26:33 AM
when I click on Claim bitcoins -> Select Coins the wallet freezes..
Which version are you running?
April 18, 2015, 08:21:48 AM
when I click on Claim bitcoins -> Select Coins the wallet freezes..
Ok, that is not good. Will try to reproduce. I've seen the behaviour under some circumstances.
April 18, 2015, 04:20:57 AM
when I click on Claim bitcoins -> Select Coins the wallet freezes..
April 18, 2015, 03:38:27 AM
We suppose to favour this wonderful currency....... 
April 18, 2015, 03:33:07 AM
Version 0.9.1.10 of Bitcredit client released
A new version of the Bitcredit client has been released. It solves the problem with long and problematic initial startup and sync times, among other things.
0.9.1.10 is a larger update with:
- Improved time for startup and initial syncing of blockhains.
- Bug fixes with regards to inconsistency problems in the chainstate.
- UI freeze problems handled.
- Several other bug fixes.
The sync process when starting from scratch now takes about 20-28 hours if you have a decent internet connection. Test done on a Lenovo laptop with a physical quad core i7 processor.
It is highly recommended that all users upgrade as soon as possible.
Make a copy your existing versions and try to start the new version instead. The transition should be seamless.
http://bitcredit-currency.org/viewforum.php?f=5
A new version of the Bitcredit client has been released. It solves the problem with long and problematic initial startup and sync times, among other things.
0.9.1.10 is a larger update with:
- Improved time for startup and initial syncing of blockhains.
- Bug fixes with regards to inconsistency problems in the chainstate.
- UI freeze problems handled.
- Several other bug fixes.
The sync process when starting from scratch now takes about 20-28 hours if you have a decent internet connection. Test done on a Lenovo laptop with a physical quad core i7 processor.
It is highly recommended that all users upgrade as soon as possible.
Make a copy your existing versions and try to start the new version instead. The transition should be seamless.
http://bitcredit-currency.org/viewforum.php?f=5
April 18, 2015, 02:56:33 AM
New version of init torrent file released
A new up-to-date version of the torrent for quick startup has been released. This is in preparation for the new version of Bitcredit that will be released in a few hours.
http://bitcredit-currency.org/viewtopic.php?f=18&t=517&p=766#p766
A new up-to-date version of the torrent for quick startup has been released. This is in preparation for the new version of Bitcredit that will be released in a few hours.
http://bitcredit-currency.org/viewtopic.php?f=18&t=517&p=766#p766
Jump to: