 Show Posts
|
|
Pages: [1] 2 3 »
|
It seems is the problem of my editor or something
Seems like it just read the eof so do not execute the port and rpcport command
Hi, What is your OS ? Where is located your conf file ? I use Ubuntu in virtual box like you. Make sure that your .bitcoin directory is in /home/<os_username>. Otherwise if it not here specify it with : bitcoind -datadir=<data_directory> For the editor I'm not sure but try it with gedit which is on Ubuntu. There are way better editors but test with it if you think the problem is because of your editor. |
|
|
|
thanks but still not work
still get
tcp6 0 0 ::1:18332 :::* LISTEN 27578/bitcoind
tcp6 0 0 :::18444 :::* LISTEN 27578/bitcoind
though i can make it work by typing command bitcoind -daemon -port=8333
I did the same way but got : Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:8335 0.0.0.0:* LISTEN 2452/bitcoind
tcp 0 0 127.0.0.1:8336 0.0.0.0:* LISTEN 2452/bitcoind
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:16443 0.0.0.0:* LISTEN 15741/bitcoind
tcp 0 0 0.0.0.0:16444 0.0.0.0:* LISTEN 15741/bitcoind
tcp6 0 0 :::8335 :::* LISTEN 2452/bitcoind
tcp6 0 0 ::1:8336 :::* LISTEN 2452/bitcoind
tcp6 0 0 ::1:631 :::* LISTEN -
tcp6 0 0 ::1:16443 :::* LISTEN 15741/bitcoind
tcp6 0 0 :::16444 :::* LISTEN 15741/bitcoind
in my bitcoin.conf : dns=0
dnsseed=0
regtest=1
port=8335
rpcport=8336
It worked fine. Which version you're using? Mine is 0.17.1. I disabled DNS for some reasons but It doesn't play a part here. By the way, I changed some default port numbers but the two that I set in bitcoin.conf work fine. |
|
|
|
|
Hi,
Thank you for all your amazing guides. I read all that and do exactly as you said. Great guides in every way.
|
|
|
|
But the testnet has a lower hashrate of 62 TH/s, which requires just 2 or 3 ASIC mining rigs to take control and perform the 51% attack on the testnet successfully.
In fact I reduced difficulty of whole network and created my private chain. I'm currently mining on that which is good enough to implement 51% attack quickly, and also uses all main net functions. But you could try using regtest mode in the bitcoind application to test your own local blockchain with such kind of attacks.
yes, I know but simulating these attacks require creating two blocks at the same time which the fake chain is longer that the true chain. Since for test I mine with bitcoin built-in miner I have no idea how to create two blocks at the same time. There is always a delay(at least in timestamp). Son the step by step scenario seemed a bit confusing at first sight. I don't get your point. Why should you disconnect your node to carry out 51% attack? Am I missing something here Huh
Because I thought I couldn't generate blocks simultaneously, It crossed my mind that I can develop a fake chain offline by disconnecting that node from chain, then by reconnecting to the main chain. The fake chain which is longer is accepted. I'm not sure about it. Just an idea. |
|
|
|
|
Just for scientific reasons!
How 51% attack is implemented on testnet. I want to see the results visually ?
Is disconnecting one node from chain for some time will do the it properly or other nodes recognize it once it is added to the chain ?
|
|
|
|
Indeed.. Can you post a getrawtransaction decoded so we can check if this is the locktime again (if this is still the same function which returns false) ? Yes, getrawtransaction 828bc6179345284921e70d393efe14cb42e0f9413752b126fb031a8f5a9c29ff 1
{
"txid": "828bc6179345284921e70d393efe14cb42e0f9413752b126fb031a8f5a9c29ff",
"hash": "9c6e3b45d40c4740180e16412e2d1861a1f94085f697ce42b7ffcbdd8086ec5a",
"version": 2,
"size": 247,
"vsize": 166,
"weight": 661,
"locktime": 12,
"vin": [
{
"txid": "2ca69f469e0b461c546e151441ba8537ef4a00615f9ae87ce5c97b72f7a76114",
"vout": 0,
"scriptSig": {
"asm": "00147ff93bf12b29683c2c918f890f98cd19eb2c23b2",
"hex": "1600147ff93bf12b29683c2c918f890f98cd19eb2c23b2"
},
"txinwitness": [
"30440220629eb58313c3d6e95c7e22d5d130cb55e6ec7e288bfefdaf8ef4d7be5e908626022065805fbcd3dbb2cb859cb83f9164d3e39f929025c847546dd0552d595a641c6801",
"038259d51458e3063ed5b9dc1fb8030fc6371cef44c674cf44e8ca2127f4110902"
],
"sequence": 4294967293
}
],
"vout": [
{
"value": 45.99894100,
"n": 0,
"scriptPubKey": {
"asm": "OP_HASH160 c0daf191bc75d4bd94b87590762005081b9ab71a OP_EQUAL",
"hex": "a914c0daf191bc75d4bd94b87590762005081b9ab71a87",
"reqSigs": 1,
"type": "scripthash",
"addresses": [
"3KGjwqyqo6nnvzAcTCyAVTgdKJ3DwyPTXF"
]
}
},
{
"value": 2.00000000,
"n": 1,
"scriptPubKey": {
"asm": "OP_HASH160 37fdd042f4dfad0e52fa932291a1cfafa7704892 OP_EQUAL",
"hex": "a91437fdd042f4dfad0e52fa932291a1cfafa770489287",
"reqSigs": 1,
"type": "scripthash",
"addresses": [
"36o59NF7NbtWoLrAXBBtcGTSQ6wTiVRthV"
]
}
}
],
"hex": "020000000001011461a7f7727bc9e57ce89a5f61004aef3785ba4114156e541c460b9e469fa62c00000000171600147ff93bf12b29683c2c918f890f98cd19eb2c23b2fdffffff0254d02c120100000017a914c0daf191bc75d4bd94b87590762005081b9ab71a8700c2eb0b0000000017a91437fdd042f4dfad0e52fa932291a1cfafa770489287024730440220629eb58313c3d6e95c7e22d5d130cb55e6ec7e288bfefdaf8ef4d7be5e908626022065805fbcd3dbb2cb859cb83f9164d3e39f929025c847546dd0552d595a641c680121038259d51458e3063ed5b9dc1fb8030fc6371cef44c674cf44e8ca2127f41109020c000000"
}
The problem is still with sequence number which is fffffffd. |
|
|
|
Finally I got the answer!
As I previously said you can use legacy addresses but it is not a long term viable solution. You should fork 0.17+. Thank you for all the help. I truly appreciate it.
No problem  But It's still ambiguous to me why segwit address would fail creating block....
Because Segwit was not activated yet so you could not add Segwit transactions in a block. "segwit address would fail creating block" : this is not the address which creates a block, it is the software. Block generation is (almost) unrelated to addresses. I forked 0.17.1 and applied all my changes again(segwit activated by default), still didn't work with segwit addresses. This is strange! |
|
|
|
which version of bitcoin-core did you fork ? First, thank you so much for the help. I forked 16.2 from branch master. I mined coinbase transactions till 12 blocks further also but didn't work. I try to use legacy addresses and let you know ASAP. Thanks again! Ah ! I think in 0.16, this is when Segwit had to be voted, and was treated as always active in 0.17. It should work with legacy addresses, and you should fork 0.17(.1) if you want to have it activated by default. Finally I got the answer! Thank you for all the help. I truly appreciate it. But It's still ambiguous to me why segwit address would fail creating block.... |
|
|
|
Legacy start with 1 segwit starts with 3. You should be able to launch the client with legacy addressing. add this to your .conf file. It should then launch with legacy addressing. Thank you so much!!! |
|
|
|
which version of bitcoin-core did you fork ? First, thank you so much for the help. I forked 16.2 from branch master. I mined coinbase transactions till 12 blocks further also but didn't work. I try to use legacy addresses and let you know ASAP. Thanks again! Ah ! I think in 0.16, this is when Segwit had to be voted, and was treated as always active in 0.17. It should work with legacy addresses, and you should fork 0.17(.1) if you want to have it activated by default. I did exactly as you said, forked from 0.17.1 . Same thing in the same place happened.  By legacy addresses do you mean the ones that starts with 3.. or 1... ? . Bitcoin core wallet doesn't generate the ones that start with 1... . Is there any online generators ? I searched and found nothing. |
|
|
|
which version of bitcoin-core did you fork ? First, thank you so much for the help. I forked 16.2 from branch master. I mined coinbase transactions till 12 blocks further also but didn't work. I try to use legacy addresses and let you know ASAP. Thanks again! |
|
|
|
What are peer magic values ? I don't know anything about them.
They are also called "magic bytes", these are bytes set that every message will start with so we can see that the data on the wire is a Bitcoin message. They are set to : pchMessageStart[0] = 0xf9;
pchMessageStart[1] = 0xbe;
pchMessageStart[2] = 0xb4;
pchMessageStart[3] = 0xd9; What is weird is that your nodes are connected, you can mine and blocks are transmitted. However when mining tx from the mempool are not added to the bloc the software is generating. I would recommend that you add some "LogPrintf()" in the mining code ( which is located here) and then you do everything again, after having compiled. Then you would see informations about what is going on in "~/.bitcoin/debug.log". I don't have time to help you right now but I will if you haven't achieved it till then. Thanks for the hint. I did as you said and found something! The problem rises when "TestPackageTransactions()" in miner.cpp returns false in this line : https://github.com/bitcoin/bitcoin/blob/c6806ee8694e9c864a29ef260c87b9fed77de84f/src/miner.cpp#L217I tried to comment it so that it could accept my block but then "TestBlockValidity()" in validation.cpp threw an error in https://github.com/bitcoin/bitcoin/blob/c6806ee8694e9c864a29ef260c87b9fed77de84f/src/validation.cpp#L3594. Then I tried to comment where this function was used. Then I got error in mining.cpp here : https://github.com/bitcoin/bitcoin/blob/master/src/rpc/mining.cpp#L144If I comment this line as well I won't be able to mine anything and my balance doesn't not change. It seems the network doesn't accept my block as a valid block. I wonder why,It may have something to do with witness but it's all ambiguous to me !!!! Link to my project with logs and without commenting those functions mentioned above : https://github.com/chameleon1239/bitcoin.gitThe most weird thing is that it works for first transaction, then doesn't work for the second one. Then it works for third one and so on. Please if you find some time take a look at it. I'll appreciate it so much. |
|
|
|
What are peer magic values ? I don't know anything about them.
They are also called "magic bytes", these are bytes set that every message will start with so we can see that the data on the wire is a Bitcoin message. They are set to : pchMessageStart[0] = 0xf9;
pchMessageStart[1] = 0xbe;
pchMessageStart[2] = 0xb4;
pchMessageStart[3] = 0xd9; What is weird is that your nodes are connected, you can mine and blocks are transmitted. However when mining tx from the mempool are not added to the bloc the software is generating. I would recommend that you add some "LogPrintf()" in the mining code ( which is located here) and then you do everything again, after having compiled. Then you would see informations about what is going on in "~/.bitcoin/debug.log". I don't have time to help you right now but I will if you haven't achieved it till then. Thanks a lot for all the help. I will certainly do that and let you know.Do you think I can solve it in two days? I have a deadline by that time. |
|
|
|
You will want to change the values to random non common ascii in chainparams.cpp $ python
>>> import random
>>> hex(random.randint(127,255))
'0xd9'
pchMessageStart[0] = 0xf9;
pchMessageStart[1] = 0xbe;
pchMessageStart[2] = 0xb4;
pchMessageStart[3] = 0xd9; <---- do all 4 Try this recompile and test again. I already did that. I f you look at my code there are randome generated values for these parameters. |
|
|
|
Are you sure your transaction is in the mempool ? Try Hi, yes. I'm pretty sure. I used the command(It works without 1) and I got that transaction ID. If you run it too, you can see it. Very strange! The `1` parameter was in order to get more details http://chainquery.com/bitcoin-api/getrawmempool . It is indeed very strange, don't you modify any part of the code ? How did you set up the network ? I just changed some things according to https://bitcointalk.org/index.php?topic=3345808.msg35016844#msg35016844 guide.Created a new genesis block according to my new difficulty(nBits) which was 0x1f0fffff and powLimit in chainparams.cpp was changed to 0x000ffff...f .Also commented this line in mining.cpp : if (IsInitialBlockDownload())
throw JSONRPCError(RPC_CLIENT_IN_INITIAL_DOWNLOAD, "Bitcoin is downloading blocks...");
Finally changed coinbase maturity to 10. I guess you changed the peer magic values? If your running in VM's on the same machine you may have firewall issues? Post the outputs of the following in code tags from both consoles. getmininginfo getpeerinfo getrawtransaction <TXIDHERE> I guess you changed the peer magic values?
What are peer magic values ? I don't know anything about them. If your running in VM's on the same machine you may have firewall issues?
As far as I know, No. I tested this scenario on another machine too but got same results. [/quote] Post the outputs of the following in code tags from both consoles. getmininginfo getpeerinfo getrawtransaction <TXIDHERE> [/quote] For first node the out puts are : getmininginfo {
"blocks": 13,
"currentblockweight": 4000,
"currentblocktx": 0,
"difficulty": 1,
"networkhashps": 0.009866452320361751,
"pooledtx": 1,
"chain": "main",
"warnings": "This is a pre-release test build - use at your own risk - do not use for mining or merchant applications"
}
getpeerinfo

[
{
"id": 0,
"addr": "127.0.0.1:58886",
"addrbind": "127.0.0.1:6333",
"services": "000000000000040d",
"relaytxes": true,
"lastsend": 1547002445,
"lastrecv": 1547002445,
"bytessent": 4939,
"bytesrecv": 1080,
"conntime": 1547001965,
"timeoffset": 0,
"pingtime": 0.000418,
"minping": 0.000316,
"version": 70015,
"subver": "/Satoshi:0.17.99/",
"inbound": true,
"addnode": false,
"startingheight": 0,
"banscore": 0,
"synced_headers": -1,
"synced_blocks": -1,
"inflight": [
],
"whitelisted": false,
"minfeefilter": 0.00001000,
"bytessent_per_msg": {
"block": 250,
"cmpctblock": 3126,
"feefilter": 32,
"getheaders": 93,
"headers": 212,
"inv": 183,
"ping": 160,
"pong": 160,
"sendcmpct": 66,
"sendheaders": 24,
"tx": 482,
"verack": 24,
"version": 127
},
"bytesrecv_per_msg": {
"feefilter": 32,
"getaddr": 24,
"getdata": 244,
"getheaders": 186,
"ping": 160,
"pong": 160,
"sendcmpct": 99,
"sendheaders": 24,
"verack": 24,
"version": 127
}
}
]
getrawtransaction 9df617feddf83c2eee4cb6c15b57471ad8f5070c46a8685a2984f463419adbf1 0200000000010175a55043385a47f725e5a4a6a11f987f51f43fb0b09832c9bc16d22b15db4e980000000017160014e62e2ee223556551100d9e999d2bc334dac83f42fdffffff0254d02c120100000017a9147e92ec13bb97a74588e11a7f9d33a9e68314044e8700c2eb0b0000000017a914184e89e76e84cc73561ff4920561ab038b058542870247304402203c28d4d768495fe8721fe17154dbc0ba8492a19790a4193aaaec28c75d4559b5022012e1c81d1c9d55fbc5d4b6b33e0e0a45d190d7d800d61c06e12feb75b46f51290121039dfb7a582ba7fd851d6ef4f9bf0092efafcad9f2fddd0b7d333cf11bd01e05460c000000
For second node : getminiginfo {
"blocks": 13,
"currentblockweight": 0,
"currentblocktx": 0,
"difficulty": 1,
"networkhashps": 0.009866452320361751,
"pooledtx": 1,
"chain": "main",
"warnings": "This is a pre-release test build - use at your own risk - do not use for mining or merchant applications"
}
getpeerinfo
21:48:42

{
"blocks": 12,
"currentblockweight": 0,
"currentblocktx": 0,
"difficulty": 1,
"networkhashps": 0.009107671645756934,
"pooledtx": 0,
"chain": "main",
"warnings": "This is a pre-release test build - use at your own risk - do not use for mining or merchant applications"
}
22:00:52

getmininginfo
22:00:52

{
"blocks": 13,
"currentblockweight": 0,
"currentblocktx": 0,
"difficulty": 1,
"networkhashps": 0.009866452320361751,
"pooledtx": 1,
"chain": "main",
"warnings": "This is a pre-release test build - use at your own risk - do not use for mining or merchant applications"
}
22:01:49

getpeerinfo
22:01:49

[
{
"id": 0,
"addr": "127.0.0.1:6333",
"addrbind": "127.0.0.1:58886",
"services": "000000000000040d",
"relaytxes": true,
"lastsend": 1547002805,
"lastrecv": 1547002805,
"bytessent": 1272,
"bytesrecv": 5131,
"conntime": 1547001965,
"timeoffset": 0,
"pingtime": 0.000399,
"minping": 0.00024,
"version": 70015,
"subver": "/Satoshi:0.17.99/",
"inbound": false,
"addnode": true,
"startingheight": 0,
"banscore": 0,
"synced_headers": 13,
"synced_blocks": 13,
"inflight": [
],
"whitelisted": false,
"minfeefilter": 0.00001000,
"bytessent_per_msg": {
"feefilter": 32,
"getaddr": 24,
"getdata": 244,
"getheaders": 186,
"ping": 256,
"pong": 256,
"sendcmpct": 99,
"sendheaders": 24,
"verack": 24,
"version": 127
},
"bytesrecv_per_msg": {
"block": 250,
"cmpctblock": 3126,
"feefilter": 32,
"getheaders": 93,
"headers": 212,
"inv": 183,
"ping": 256,
"pong": 256,
"sendcmpct": 66,
"sendheaders": 24,
"tx": 482,
"verack": 24,
"version": 127
}
}
]
getrawtransaction 9df617feddf83c2eee4cb6c15b57471ad8f5070c46a8685a2984f463419adbf1 0200000000010175a55043385a47f725e5a4a6a11f987f51f43fb0b09832c9bc16d22b15db4e980000000017160014e62e2ee223556551100d9e999d2bc334dac83f42fdffffff0254d02c120100000017a9147e92ec13bb97a74588e11a7f9d33a9e68314044e8700c2eb0b0000000017a914184e89e76e84cc73561ff4920561ab038b058542870247304402203c28d4d768495fe8721fe17154dbc0ba8492a19790a4193aaaec28c75d4559b5022012e1c81d1c9d55fbc5d4b6b33e0e0a45d190d7d800d61c06e12feb75b46f51290121039dfb7a582ba7fd851d6ef4f9bf0092efafcad9f2fddd0b7d333cf11bd01e05460c000000 Ports of first node are 6333 and 6332 for rpc. Ports for second node are 13500 and 13501 for rpc. |
|
|
|
Are you sure your transaction is in the mempool ? Try Hi, yes. I'm pretty sure. I used the command(It works without 1) and I got that transaction ID. If you run it too, you can see it. Very strange! The `1` parameter was in order to get more details http://chainquery.com/bitcoin-api/getrawmempool . It is indeed very strange, don't you modify any part of the code ? How did you set up the network ? I just changed some things according to https://bitcointalk.org/index.php?topic=3345808.msg35016844#msg35016844 guide.Created a new genesis block according to my new difficulty(nBits) which was 0x1f0fffff and powLimit in chainparams.cpp was changed to 0x000ffff...f .Also commented this line in mining.cpp : if (IsInitialBlockDownload())
throw JSONRPCError(RPC_CLIENT_IN_INITIAL_DOWNLOAD, "Bitcoin is downloading blocks...");
Finally changed coinbase maturity to 10. |
|
|
|
Several weeks ago I asked same question. I created my private chain with a very low difficulty (for implementing some tests) and when testing the network and creating transactions they get lost some how!!! Here's a scenario with images attached: 1. I created two node s on same machine, mined one of them till my custom coinbase maturity (I changed it to 10 blocks). 2. I made a transaction from first node to second node (2 btcs), then mined it with second node using command "generate 1". Till this stage it worked fine. See the image for results (first node is in the left and second node is in the right):  3.In this stage no matter from which side I create transactions. It gets stuck in memory pool. No matter how hard i try to mine it, no peer would add it to the chain. I created another transaction from first node to second node. See the picture.  I don't this the problem is with fee because with enough fee I still have the problem. The link to my repository is : https://github.com/chameleon1239/bitcoin.gitAny one has any idea? I didn't change the source code for confirming transactions or memory pool. |
|
|
|
Stuck in what way? Is the transaction in the mempool but not being mined? Or is it in one node's mempool but not the other's?
I solved it somehow . The only problem that I have now is that imagine I have only two peers on my machine and I send several bitcoins to the other in two separate transactions. but the I mine them manually. Only the last one gets confirmed and the other one remains in mempool, even If I mine several blocks, It would be still in mempool. Why is that happening ? Sencondly, fallbackfee estimation is not working for my chain, I have to set it manually. What could be the reason? Link to my repository : https://github.com/chameleon1239/bitcoin.gitThanks a lot |
|
|
|
Just two more questions. 1.What exactly is the use of "IsInitialBloackDownlaod()" in mining.cpp. For my chain which is pretty new, If I want to check the block template, the functions returns true and I get error -10 : Bitcoin is downloading blocks. Is it same for This is to prevent people from mining when they are out of sync. If you mine when out of sync, then you can cause a chain fork. 2. What is nMinimumChainWork and how it is calculated initially ?
ChainWork is the sum of all of the difficulties of all of the blocks in the blockchain. nMinimumChainWork is the chainwork for a specific block and is used during the initial sync as a safety check. 3. When Bicoin gui starts up, It says I'm 5 weeks behind.I forked bitcoin completely disabled DNS seeds. There's no reason for it. Why I get the message?
DNS is completely unrelated to this whatsoever. DNS seeds are used for finding nodes to connect to. It has nothing to do with you being behind. The message appears because the software thinks you are out of sync. The most recent block is 5 weeks old and the software is expecting there to be more recent blocks. It has no way of knowing that there are not more recent blocks, but it assumes that there is because in Bitcoin, blocks are still being produced when you are offline. Thanks a lot. It was very helpful. Do you know why transactions between nodes get stuck in memory pool? It's like they are never sent to receiver. |
|
|
|
What version are you testing with.
In v0.5.1 there is the above line in main.cpp might be helpful.
I'm using 0.16.2. I reduced coinbase maturity to 10 blocks for testing. |
|
|
|
|
