About windows 64/32 compilation, you can use make -i to ignore the errors. There will be errors due to one sha flavor compilation error, but it does not affect the result since other sha algorithms will compile fine and this one is optionnal, but without the -i it will stop the compilation. Also when you say "mine 100 blocks" but how? Bitcoin 0.17.1 is not mining with Yiimp without stratum modification (due to changes in how the address verification is done with RPC) And about DWG and Midas I have experienced both, they are falling with ccminer and the coin reject the mined block with an unexpected difficulty match error. I ended up continuing to use the basic Bitcoin reajustment code - which is working fine but reajusting every block. Another solution is to check verification.cpp from the different version of Bitcoin (cash, sv etc...) and see how they dealed with reajustment. Good guide! A couple of updates for Bitcoin release 0.17.1 which I wanted to use. Also if you want to build a Windows GUI wallet, you will have to git clone and add --branch v.0.17.1 (it accepts a tag) so you get the /depends directory and all the stuff inside needed for cross-compile dependencies. That way you can cross-compile for Win 64 on Ubuntu and get a slick Bitcoin Core wallet. If you know how to get gitian up and running, you can make a setup .exe. If you have Mac libs, you can cross-compile for a Mac wallet, too. So first swap out the RPC port step and instead change it here in src/chainparamsbase.cpp: std::unique_ptr<CBaseChainParams> CreateBaseChainParams(const std::string& chain)
{
if (chain == CBaseChainParams::MAIN)
return MakeUnique<CBaseChainParams>("", 10332); // I set my port to 10332, Bitcoin's is 8332, I left the rest alone
else if (chain == CBaseChainParams::TESTNET)
return MakeUnique<CBaseChainParams>("testnet3", 18332);
else if (chain == CBaseChainParams::REGTEST)
return MakeUnique<CBaseChainParams>("regtest", 18443);
else
throw std::runtime_error(strprintf("%s: Unknown chain %s.", __func__, chain));
}
In chainparams.cpp, set the P2P port under the pchMessageStart lines: nDefaultPort = 10333; // Bitcoin's is 8333, I set mine to a thousand above Litecoin's P2P port (9333)
Not long after that, when you create a genesis block with genesisgen or GenesisH0's Python tool, this line should look familiar: genesis = CreateGenesisBlock(1553416095, 2546245826, 0x1d00ffff, 1, 50 * COIN);
That was mine, but now do the same thing for testnet, otherwise the daemon will fail with the assert on the genesis hash for it. So in chainparams.cpp set your genesis block again. Look for the Testnet (v3) comment and the process is the same for main-net For bech32_hrp, I left mine as "bc" but you can change that. Litecoin's is "ltc". Note that with miners, I found they failed to mine to older style addresses, so you will probably have to bitcoin-cli getnewaddress, then bitcoin-cli getaddressinfo "addr" and find the bech32 address in there, and set that as your --coinbase-addr parameter with cpuminer, then it works. with chainTxData in chainparams.cpp, set nTime to the UNIX timestamp of your genesis block and the nTxCount and dTxRate both to 0. An important step to take if you publish your source on github is to mine say 100 blocks and have them confirmed, and adjust your nPowTargetTimespan as a minimum to try and prevent instamining. People will find it and instamine it immediately, if it looks like a new alt-coin to them, leaving you with the likely situation that they out-gun you with a higher hashrate, and trying to catch up means you could get blocks, but they will all probably get orphaned. And then leave your blockchain in a mess and your coin stalling. I set mine to: consensus.nPowTargetTimespan = 3 * 60 * 60; // three hours
consensus.nPowTargetSpacing = 2 * 60; // two minutes
to begin with. It probably still isn't good enough in comparison to implementing DGW v3 or MIDAS or something of your own invention, in particular you might like to have difficulty readjustments done less than every 3 hours as above. This works out for me just in a test environment, and I usually get my block every two minutes although sometimes a few will pop through every minute then it will slow down again and not find a few blocks for longer than the target of 2 minutes that I wanted. You can also premine coins for yourself if you want to with the GetBlockSubsidy function in validation.cpp. Please note I haven't tested this at all, but for example: CAmount GetBlockSubsidy(int nHeight, const Consensus::Params& consensusParams)
{
int halvings = nHeight / consensusParams.nSubsidyHalvingInterval;
// Force block reward to zero when right shift is undefined.
if (halvings >= 64)
return 0;
// Premine in first ten blocks, the simple approach
// Start with 5000 coins per block after genesis, but otherwise leave default subsidy unchanged
CAmount nSubsidy = 50 * COIN;
// First 10 blocks after genesis, up the subsidy to 5000 coins
if (nHeight > 0 && nHeight <= 10) {
nSubsidy = 5000 * COIN;
// You may wish to leave out the halvings below and just
return nSubsidy;
// especially if you just premine in block #1 and leave it at that, but check
// to make sure it doesn't get all screwed up...
}
// otherwise leave nSubsidy in its default state
// Subsidy is cut in half every 210,000 blocks which will occur approximately every 4 years. (Not true for my adjustments, pay attention here)
nSubsidy >>= halvings;
return nSubsidy;
}
I left the coin supply and subsidy halving for the moment because it doesn't matter, it's not an alt-coin but a learn-by-doing exercise, trying to retrofit in the bare minimum of difficulty adjustments, experimenting with scripts in transactions (enabling some, trying new ones, going a bit crazy there but the programmable money part is a lot of fun for me), and looking at how more privacy of transactions could be implemented. I expect I'm a couple of years away from that, but I hope to get there some day, otherwise it's worth trying to clone ZCash or another coin. I think I've covered the bare basic bits as a follow-on to this guide if you want Bitcoin 0.17.1, you might run into make issues after changing everything from Bitcoin to NewCoin and so on. So for example if the build process fails in doc/man (a situation I ran into before) saying it has no rule to make newcoind.1. Stop., then just rename bitcoind.1 to newcoind.1 (and same for 3 other files there) then run make again and it will continue where it left off. For a Windows QT wallet, cross-compiling on Ubuntu 18.04 LTS: sudo apt-get update
sudo apt-get upgrade
sudo apt-get install build-essential libtool autotools-dev automake pkg-config libssl-dev libevent-dev bsdmainutils python3 libboost-system-dev libboost-filesystem-dev libboost-chrono-dev libboost-test-dev libboost-thread-dev libboost-all-dev libboost-program-options-dev
sudo apt-get install libminiupnpc-dev libzmq3-dev libqt5gui5 libqt5core5a libqt5dbus5 qttools5-dev qttools5-dev-tools libprotobuf-dev protobuf-compiler libqrencode-dev unzip
// Get into your src directory, e.g.
cd ~/bitcoin-0.17.1
// For a 64-bit Windows wallet
sudo apt install g++-mingw-w64-x86-64
// Set mode to POSIX when it asks after running
sudo update-alternatives --config x86_64-w64-mingw32-g++
// Get ready and change into depends directory
PATH=$(echo "$PATH" | sed -e 's/:\/mnt.*//g')
cd depends
// This will take a while
make HOST=x86_64-w64-mingw32
// Up one level to your top level src dir (not in /src, up from there to configure and make)
cd ..
// I use the latest Berkeley DB, so if like me you don't need "compatible" wallets,
// always configure with the latest Berkeley DB and pass in --with-incompatible-bdb
// This will also take a while...
./autogen.sh
CONFIG_SITE=$PWD/depends/x86_64-w64-mingw32/share/config.site ./configure --with-incompatible-bdb --prefix=/
make
If all goes well, the 64-bit Windos GUI wallet e.g. newcoin-qt.exe will be in the folder src/qt when compiled. The other tools newcoin-cli.exe, newcoin-tx.exe and the daemon newcoind.exe will be in the src folder. So I think that's all for now for a quick and dirty Bitcoin 0.17.1 based on last year's Christmas Day release. |
|
|
|
I have followed this project and invested too, I have sold when I realized it was mostly a scam. The problem with the ERC Tokens is that anyone can make one and do a pretty website, then pretent anything. Trust only the real blockchains, and the one that forks the latest version of Bitcoin core... .these at least ask some real work to fork and maintain, and if the developper can make his coin functionnal with Bitcoin core 0.17+, then he knows C++ enough. Otherwise, deception is always the end of the story. I remember trying to help dev out with the project but he never replied which means a tacit no no. He already lost faith in the project. So sad that me and some other guys have to lose a lot of money on this. Reason why I don't go all out on projects with hidden ID dev team. The decided to move out of ERC20 blockchain just about when the ethereum blockchain soared. So sad!
|
|
|
|
I will answer to my own question. What is blocking the transactions is segwit...check /rpc/mining.cpp
throw JSONRPCError(RPC_INVALID_PARAMETER, "getblocktemplate must be called with the segwit
/validation.cpp
return (VersionBitsState(pindexPrev, params, Consensus::DEPLOYMENT_SEGWIT, versionbitscache) == ThresholdState::ACTIVE);
and remove the seqwit security check at the early stage of the blockchain. |
|
|
|
This is the mask for the minimum difficulty, at starting your coin might need FFFFFfffffffffffffffffffffffffffffffffffffffffffffffffffffffffff to allow mining at difficulty 1 consensus.powLimit = uint256S("00000fffffffffffffffffffffffffffffffffffffffffffffffffffffffffff"); This is the window allowed for a consensus to be installed. In order to give the time to the blockchain to spreadthe new consensus rule to all nodes, there is a window in term of blocs so that it is done progressively. consensus.nRuleChangeActivationThreshold = 6048;
All the consensus are related to the forks specific to bitcoin. You don't need to change anything here, if you do your coin will probably fail to mine or transactions will be rejected. This is the total work minimum for the blockchain. It is calculated by adding all the transaction work. If you are starting a new coin keep to low, (use the difficulty of your genesis-1) so that you can mine, otherwise mining will fail. consensus.nMinimumChainWork This is typical to Bitcoin, your altcoin does not need it, so you can keep it that way. consensus.defaultAssumeValid consensus.powLimit = uint256S("00000fffffffffffffffffffffffffffffffffffffffffffffffffffffffffff");
consensus.nRuleChangeActivationThreshold = 6048; // 75% of 8064
consensus.nMinerConfirmationWindow = 8064; // nPowTargetTimespan / nPowTargetSpacing * 4
consensus.vDeployments[Consensus::DEPLOYMENT_TESTDUMMY].bit = 28;
consensus.vDeployments[Consensus::DEPLOYMENT_TESTDUMMY].nStartTime = 1199145601; // January 1, 2008
consensus.vDeployments[Consensus::DEPLOYMENT_TESTDUMMY].nTimeout = 1230767999; // December 31, 2008
// Deployment of BIP68, BIP112, and BIP113.
consensus.vDeployments[Consensus::DEPLOYMENT_CSV].bit = 0;
consensus.vDeployments[Consensus::DEPLOYMENT_CSV].nStartTime = 1485561600; // January 28, 2017
consensus.vDeployments[Consensus::DEPLOYMENT_CSV].nTimeout = 1517356801; // January 31st, 2018
// Deployment of SegWit (BIP141, BIP143, and BIP147)
consensus.vDeployments[Consensus::DEPLOYMENT_SEGWIT].bit = 1;
consensus.vDeployments[Consensus::DEPLOYMENT_SEGWIT].nStartTime = 1485561600; // January 28, 2017
consensus.vDeployments[Consensus::DEPLOYMENT_SEGWIT].nTimeout = 1517356801; // January 31st, 2018
// The best chain should have at least this much work.
consensus.nMinimumChainWork = uint256S("0x000000000000000000000000000000000000000000000006805c7318ce2736c0");
// By default assume that the signatures in ancestors of this block are valid.
consensus.defaultAssumeValid = uint256S("0x1673fa904a93848eca83d5ca82c7af974511a7e640e22edc2976420744f2e56a"); //1155631
What do these parameters and what put in there. I try find any info about this parameter's but dint find. I update the altcoin from old sources to new, but stuck on this segwit params. |
|
|
|
The problem is simple, I mine a couple of blocks after the genesis, then I do a transaction (send let say 20KYF to another address), the transaction is showing in the mining wallet, the transaction is showing in the receiving wallet. I mine 2000 blocks more, but the transaction stay pending. nDepth=0 shows that the transaction is never added to a block. I try to change the fees and resent the transaction everything is working normally except that again the transaction stay in Pending and I never get it confirmed. I have changed the code to show it confirmed in the wallet, and also fake the confirmation, but the real issue is that the transaction is only in mempool and not added to a block. Even if I use a huge amount for the fee. I have 5 nodes running, but I guess only one node could confirm 1 time. But in my case nothing happen. I try to understand how the whole confirmation stuff is working, specially at the early stage of a blockchain. I have the feeling that there are some test or some condition that prevent my transactions to be confirmed, because it is at a very starting, or maybe because the chain work is not big enough, something like this. Note: I use Bitcoin Core 0.18 for my tests. These problem might not happen with a Litecoin or Dash fork, but the latest (0.17+) Bitcoin Core have an insane number of tests in validation.cpp, wallet.cpp, etc... that these "old" coins didn't had. Maybe it is a normal behavior if you have only one node that is mining? Or the blockchain needs to have a minimum of blocks mined to be "mature"? I don't really understand fully what you are trying to talk about, what do you mean by you mined thousands of block and it's still showing unconfirmed.
Please you should be more detailed about the problem you are facing so that we can help you properly, id you ran the miner and it mines a lot of block without you getting confirmation, then I think you should check to see how many blocks it would take to get one confirmation because some of the blockchain were actually fixed to 20 block mined before the a transaction is included in a block.
|
|
|
|
Replying to my own question. in transactionrecord.cpp in TransactionRecord::updateStatus I can see that all my transactions are passing through this code and because the status.depth == 0 they are always flagged unconfirmed. I mined thousands of blocks so why the depth is still at 0? if (status.depth < 0)
{
status.status = TransactionStatus::Conflicted;
}
else if (status.depth == 0)
{
status.status = TransactionStatus::Unconfirmed;
if (wtx.is_abandoned)
status.status = TransactionStatus::Abandoned;
}
else if (status.depth < RecommendedNumConfirmations)
{
status.status = TransactionStatus::Confirming;
}
else
{
status.status = TransactionStatus::Confirmed;
}
|
|
|
|
I have a problem with the transactions of my altcoin. When I send a transaction in to another wallet (full node) the transaction is working correclty but end up in Pending forever. I have tried to change the fees and rebroadcast, and I get the same result. Periodically, the wallet rebroadcast the transaction to the network like this: 2019-03-17T18:40:42Z [default wallet] Relaying wtx 52b4b7dcb2f2e70fb18a6bf5403e8cf9fb0e5c9f2998575f308cf36829b08ec4
2019-03-17T18:40:42Z [default wallet] Relaying wtx d49a010079caa2471cdd07cc26396b6dd93ac9c05c4e2058768aeac09b03f5fd
2019-03-17T18:40:42Z [default wallet] Relaying wtx a952070a5d43d8d73fcf0608b858c673a7a94d9997ef246267267f23f269e451
2019-03-17T18:40:42Z [default wallet] ResendWalletTransactions: rebroadcast 3 unconfirmed transactions
Here is an example of transaction Status: 0/unconfirmed, in memory pool
Date: 3/17/19 01:07
To: k7NFieCa6MBeTumzqnPMS9x9wocEhYBszj
Debit: -1287.86680000 KYF
Transaction fee: -0.10000000 KYF
Net amount: -1287.96680000 KYF
Transaction ID: a952070a5d43d8d73fcf0608b858c673a7a94d9997ef246267267f23f269e451
Transaction total size: 24699 bytes
Transaction virtual size: 13143 bytes
Output index: 1
Any clue about what could be the issue in the configuration of the coin?  Thanks |
|
|
|
|
Market is volatile because 80% of the investments in Crypto are made by bankers, funds and other whales.
They are applying the same rules as in other market to maximize their revenues, which is basically buying a lot then crash teh market to trigger the sales of the small investors, buy at low price then artificially bubble the market and do it again.
Because there are no rules in the cryto market, they can do what they want with their bots and the result is a lot of volatility.
|
|
|
|
You can fork and create an altcoin by only changing the name of the coin (search all occurence of Bitcoin and BTC and replace them with yours), and change the RPC port. It would do a fork of Bitcoin, and use the bitcoin blockchain. If you want to solomine to get your premine without a headache and have your own blockchain, you don't need to change the public key (while it is advised, it is not not mendatory). In that case you have 3 solutions: 1) keep the bitcoin values and start over a new blockchain by only doing a new genesis as explained in the tutorial. This will make a new functionnal blockchain but you will be stuck with POW for mining and will have to add some kind of protection like DGW to avoid having big miners canibilizing your mining. You will have to setup a stratum server to mine. 2) start from Litecoin or Dash that were designed from Bitcoin 0.14 and still have the solo mining features. Doing the genesis is identical for these as explained in this tutorial. 3) start from Bytecoin and use Cryptonight. It is a fairly different version of bitcoin, based on Bitcoin 0.12 I think but highly modified. The 2) and 3) are not developed as actively as Bitcoin core, but are easy to get started. Bitcoin Core will not run out of the box unless you modify the stratum code from Yiimp, and remove many checks from validation.cpp, /qt/bicoingui.cpp, mining.cpp etc... you need to be a sharp C++ coder to choose the Bitcoin core forking way. So I feel like there's piece of simple info that is probably just known and expected that we know if we're interested in starting an Alt, but sadly it's not lol
Basically in this tutorial it's optional to rename BTC or bitcoin, so I guess the question is; is the symbol or name not actually assigned in the code it self? Obviously in a wallet you can label it what ever you want and that asset has an address and network where you interact with it, and exchanges likewise are running nodes and in their displays can label blockchain "X" as what ever they want when it's displayed.
So is the public key and/or network identifier the actual identifier for the coin and the coin name/symbol not actually dictated by the code?
|
|
|
|
There are so many things missing from this tutorial (as of Bitcoin 0.18) that you should not worry about that. I just think about all the verifcation.cpp stuff or using stratum and a pool to mine... jezz this tutorial is good for starting but there is so much work that is not explained here (or anywhere). If you are not a very good experienced C++ dev and you have a lot of time, better use bitcoin 0.14 like most coins are using (zCash, Dash, Litecoin etc...) latest version of Bitcoin has a lot of security enhancements that you need to remove to start mining at height=1 This is such a nice tutorial, but doesn't this would means that it will increase the number of low quality coins to be increase even more if more and more people able to create one for them self.
|
|
|
|
Is it possible to mine 21 000 billion coins in the first block and then let it mine 1 coin per minute? Is this possible?
Avoir premine in the genesis block (first block). Rather pre-min on 100 blocks or more so that all the BIP and Segwith can kick in othewerwise if you premine too much at a low height the block will fail to meet the minimum work consensus and your nodes will flag your mining wallet for Misbehavor or wrong block header's errors. Just do it spread on time, and don't forget to change the STALE_CHECK_INTERVAL to a value higher than the time between your genesis creation (1st block) and your first premined block. |
|
|
|
Another help for the altcoin developers. When this article was posted, it was possible to mine without using stratum, but now it is not possible. Mining your altcoin involve more work than before (blame the Bitcoin core dev for that!). Satoshi made the first Bitcoin wallet with 3 main functions, sending/receiving and mining. The fact that the solo mining code is removed make it very complicated for the altcoin designers to use Bitcoin core as a fork, reason why they are mostly using Dash/Litecoin which are based from Bitcoin 0.14 to develop new altcoin. I think it is a shame, but I am not in a position to change anything in Bitcoin core so we can only try to find solutions. How to mine your coin if you want to use Bitcoin core 0.18?First you need to run your mining wallet using by the command line yourcoind -deprecatedrpc=accounts Otherwise, getblocktemplate will not answer to stratum and mining will be impossible (message to the Bitcoin core developers, how are we going to mine if you remove getblocktemplate?) Right now, since getblocktemplate is not yet deprecated, we can use Yiimp to mine. 1) get an Ubuntu 0.18 server and use the script here https://github.com/NicolasChoukroun/yiimp_install_scrypt_ubuntu18.04 or https://github.com/xavatar/yiimp_install_scrypt_ubuntu18.04and follow the instructions. To run stratum go in the /var/stratum directory and run ./run.sh sha Careful to change the path of blocknotify to /var/stratum/blocknotify or it will not mine. 2) add your coin to Yiimp by using a second server that has its IP authorized to use the backend as explained in the instructions when you installed yiimp. a good tutorial is here https://coinguides.org/yiimp-mining-pool/3) compile your coin for PC and Unix, run the mining wallet where your installed Yiimp get an address (yourcoin-cli getnewaddress) and use it as main wallet and wallet in the coin configuration. 4) run yourcoin-qt -deprecatedrpc=account on a windows machine. Get ccminer-230 and edit one of the cmd file, enter the commands suggested by Yiimp (and do not forget to change the block notify address to /var/stratum/blocknotify) Use the address of your windows wallet (getnewaddress) as parameter too ccminer230.exe as per instruction on how to use ccminer Now you are ready to mine... run the cmd to get ccminer mining, it should work. As you can see, the bitcoin core dev have made it really complicated to fork the latest Bitcoin core to do an altcoin. |
|
|
|
A couple of information to help doing an altcoin from latest version of bitcoin. Lot of people are stuck because bitcoin 0.18 + have a lot of verification that are not taking in account the case of when you are at genesis (nheight=1) with one transaction. The loading screen is blocking and you cannot mine without removing it. Getblocktemplate send an error "Loading blocks" Latest version of Bitcoin (0.18) is adding a define in chain.h, this value is used in /qt/bitcoingui.cpp to show the blocking form or not. MAX_BLOCK_TIME_GAP = 90 * 60
This value is too small for the first transactions, the genesis first tx is most of the time older than 90*60 seconds and that's what is blocking the wallet. If you change this value to 3600*365, you will remove the loading screen and get the coin to mine. Once your blockchain has more transactions (let say 1000 for example) and you are mining a block like a swiss clock every x minutes, you can reverse this parameter to a value close to x |
|
|
|
I agree that the fact that this part of the transaction process is located in the qt/ directory is somehow confusing, since as you mentionned, we can compile without the wallet. This means that a node running without the wallet would not have the code to change the transaction status. Two more interesting bit of code are located in /primitives/ and are worth reading and understanding. They are small but essential. /primitives/block.cpp is what creates the block, block.h has the block structure header, which is one of the most important part of the blockchain, less than 200 lines of code, but very interesting. /primitives/transactions.cpp is even more critical, it is where the transactions are serialized and broacasted to the network. I would point out that there is almost no comments in these source and that's is lacking to to their abstract nature. The transactions, and transaction NumConfirmations = 6; is located in src/qt/transaction.cpp for a long time, Bitcoin 14.0 has it, and even Dash version 10 (first version have it in the same place). I guess it is there forever. When you are doing an altcoin or playing with the Bitcoin source, it is essential to change this value to something like 1 or 2, otherwise the transactions never change status. As for a mature coin, of course 6+ confirmation is as you demonstrated a bare minimum to insure the security of the blockchain. But when you are playing with the core, it is a pita to have 6 node running  The number of confirmation is coded in /src/qt/transactionrecord.h
I am completely unaware of this, anyway thanks for pointing it out. I am confused right now! Is qt code related to the bitcoin network? What is the use of coding number of confirmations in the wallet code? AFAIK, we can create our own bitcoin client which is not at all related to qt wallet! I believe this code is like a safe limit for accepting transactions and has nothing to do with confirmations. We also need to note that, satoshi in his whitepaper has clearly said that these 6 confirmations are enough to prevent the double spending, that's the reason why this isn't present in the main code and wouldn't make sense if it is present so. Let me quote the lines from his paper P < 0.001
q=0.10 z=5
q=0.15 z=8
q=0.20 z=11
q=0.25 z=15
q=0.30 z=24
q=0.35 z=41
q=0.40 z=89
q=0.45 z=340
Here p is the chance of an attacker leading the longest chain and trying to double spend. q is the hashing power that a miner controls z is the number of blocks required by miner to overtake the chain and double spend the tx. When a miner for instance controls 10% of total hashing power, he needs to overtake 5 blocks for him to reverse. Even though he passes then the probability is just 0.1% So for safe terms, the 6 confirmations should be coded in the qt client. It has nothing to do with bitcoin network as far as I know. |
|
|
|
I am giving the answer of my own question, if someone with programing knowledge get stuck as I was (which is a mendatory step toward doing an altcoin) here are the answers. The number of confirmation is coded in /src/qt/transactionrecord.h /** Number of confirmation recommended for accepting a transaction */
static const int RecommendedNumConfirmations = 6;
Where the confirmation process is taking place is in /src/qt/transactionrecord.cpp void TransactionRecord::updateStatus(const interfaces::WalletTxStatus& wtx, int numBlocks, int64_t adjustedTime)
It is quite surprising to find this piece of code inside the qt directory since it is not related to qt at all and should be in the main directory. |
|
|
|
In Theory... 1) what is the maximum value for a transaction. https://en.bitcoin.it/wiki/Transaction I see in the Wiki that the transactions are stored in a 9 Byte space, which is really large but in reality, if the supply of Bitcoin changed to say the same of Bytecoin for example (180 Billion) would the Bitcoin core would allow a 1 Billion BTC transaction (that's a lot of Satoshi!)? Or there are limits fixed by the blockchain storage? 2) how much max a Wallet can hold. I have made tests and I could store up to 16 Billion and then it turned to negative. It is an empiric test but in reality what is the maximum limit of Bitcoin that can be holded in a wallet du to storage limitation. |
|
|
|
I need the source code because I want to modify it. I am not asking how it works, I know that, I am asking where in the Bitcoin core source code it is programmed. The answer I am expecting is a .cpp file and a line where to search for. Thanks for your help You don't need the source code to know how confirmation process is being done in the blockchain all you need to do is to read about it online i guess that's why you have the internet.
Anyways, your transaction has to be included in a block by a miner, including your transaction in a block is called confirmation, the first block it is included gives you one confirmation and so on. This inclusion is actually based on the fee you used in carrying out that transaction, lower fee will take slower process, and higher fee will take faster process. This is just the simple explanation.
|
|
|
|
That's what I was looking for! Thanks for the detailed answer, it is a good start for me to investigate  Sorry if the question was a bit confused, I was really looking for the location in the Bitcoin source code where the transactions are confirmed (where confirmations++ is done). So that I can study why my transactions are not passing through. I have made a lot of modifications in the source by now, so I don't think it is a transaction fee issue, if it was, I would have a warning in the logs. Your question is pretty vague to be answered and doesn't seem to make sense actually. For the qt wallet to show the balances, you need to configure minconf option in the configuration file since those are the options which makes the wallet to show the balances. If you set the minconf=1 then the wallet will show the transaction which has got 1 confirmation from the network in the balances. If you set it to 0, you will see transactions with 0 confirmations. Unconfirmed transactions cannot be spent by qt wallet. If your transaction is a coinbase tx, then you need 100 confirmations from the network and here is the relevant code for that present in consensus.h /** Coinbase transaction outputs can only be spent after this number of new blocks (network rule) */
static const int COINBASE_MATURITY = 100;
I have read somewhere an attacker can build a raw transaction for unconfirmed transactions, but if you do so and other nodes find that out, your node's IP address will get banned from using the network (in simple terms it would be blacklisted). I assume This code is present in the validations.cpp and can be seen here. for (CTxMemPool::txiter ancestorIt : setAncestors)
{
const uint256 &hashAncestor = ancestorIt->GetTx().GetHash();
if (setConflicts.count(hashAncestor))
{
return state.DoS(10, false,
strprintf("%s spends conflicting transaction %s",
hash.ToString(),
hashAncestor.ToString()));
}
}
Here the double spend transaction will be included in setConflict and the node which relayed them will be banned. In my case, I have the transaction stuck in my altcoin wallet, but the transactions never get confirmed, they are staying in pending stage.
If you didn't specify enough higher fees, the transaction should be staying in the mempool which would be picked up by miner later to add to the block. Pretty much bad idea. Do you think this would be answered in the Altcoin board? The spammers present there doesn't even know what a confirmation is! A single question present there about pre-mining is solely being answered by me for past 2 days and there isn't even one guy jumped in to learn what the OP is saying. Also I believe the question is based on a bitcoin fork, so asking questions here is probably right in my opinion. |
|
|
|
I need to know where these tasks are handled (sorry I am French). I know how to build a transaction, but I need to find where this is done in C++ in the Bitcoin source code. Thanks for your answer though. Why you need the source code? I think you just need here is the transaction ID and use that transaction ID to check your transaction if it's under being process or to check if the transaction is confirmed. You don't need to program or become a coder to solve or confirm the transaction it depends on the network and it can be confirm if the miners found the blocks that includes your transaction. Can you put your transaction ID here and let me know what altcoin you are talking about? Also, move this thread to altcoin section to get better answer here https://bitcointalk.org/index.php?board=67.0 |
|
|
|
This question is for the developers. I know that you need 1 confirmation for small amount and up to six for larger amount, but where in the source code this is programmed? I mean where in the source code the pending transactions are moved from pending to available (condirmation = confirmation +1) In my case, I have the transaction stuck in my altcoin wallet, but the transactions never get confirmed, they are staying in pending stage. I want to know where is the code and understand how the confirmation process is done in programming. There must be some kind of validation (but I do not find that in validation.cpp or in mining.cpp). The problem I have is that the transactions are not confirmed regardless of what fees I apply, and there is no warning or error messages, so I have no choice than studying how the confirmation is programmed to find what is incompatible with my modifications. Thanks |
|
|
|
|
Show Posts
