Bitcoin Forum
August 12, 2022, 08:51:27 AM *
News: Latest Bitcoin Core release: 23.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Bitcoin / Development & Technical Discussion / Enable support for NODE_GETUTXO on: March 01, 2019, 11:14:40 AM
I thought my full node support all services. But I just found out from https://en.bitcoin.it/wiki/Protocol_documentation#version that it does not support NODE_GETUTXO.

I have no clue at all about what it actually does though Grin . But according to https://github.com/bitcoin/bips/blob/master/bip-0064.mediawiki, it seems to be good to enable it to be able to further check double spending.

Could anyone explain what NODE_GETUTXO actually is, how to enable it on my full node and its impact (if any) on my full node that I need to consider?

Thanks a lot in advance.
2  Bitcoin / Development & Technical Discussion / [SOLVED] JSON-RPC query syntax in curl on: February 28, 2019, 10:15:12 PM
I would like to get only some parts of "getpeerinfo" output particularly the "addr", "services", "version" and "subver" of the peers, and put them into a list in text file. So far, I could not figure out the right JSON-RPC syntax to query that using curl.

I can get the entire output of "getpeerinfo" using curl command like below:
Code:
curl --user <rpcuser>:<rpcpassword> --data-binary '{"jsonrpc": "1.0", "id":"getpeerinfo", "method": "getpeerinfo", "params": []}' -H 'content-type: text/plain;' http://127.0.0.1:8332/

I assume that I have to put the right syntax on the "params" part, but I cannot find any information so far. I got errors when I tried for instance the following:
Code:
curl --user <rpcuser>:<rpcpassword> --data-binary '{"jsonrpc": "1.0", "id":"getpeerinfo", "method": "getpeerinfo", "params": [{"addr"}]}' -H 'content-type: text/plain;' http://127.0.0.1:8332/
{"result":null,"error":{"code":-32700,"message":"Parse error"},"id":null}

Could anyone give me hints please?

Thanks a lot in advance for your help.
3  Bitcoin / Development & Technical Discussion / Rules to manually ban misbehaving peers on: February 25, 2019, 12:56:39 PM
It happened once that a peer chocked the eth0 interface of my full node, because I forgot to add the hashlimit rule on my iptables to limit the outgoing traffic per peer to 1 Mbps. That peer kept continuously downloading blocks from my full node for more than 10 GB within an hour. That made even SSH session to my full node very slow. Everything went fine after I manually banned that peer.

Last week, I found a peer got banned by my script because of it kept downloading blocks for up to 6 GB within an hour. The ban score of the peers increased by 1 if they keep continuously downloading blocks up to 1 GB every 10 minutes. My script bans a peer that has a ban score more than 5 or continuously downloading up to 6 GB within a hour.

Perhaps I need to tighten the ban criteria, but I am afraid that I will ban legitimate peers. However, when I observe the behaviour of the bitcoin-qt on my PC in which my full node is its prefer peer,  it only downloads a few hundreds MB within an hour even after I didn't launch it for a week. So it does not keep downloading all blocks that it needs from my full node the whole time, as it also downloads some blocks from its other outgoing peers.

Do any of you know why peers keep continuously downloading blocks like that? Are they legitimate peers?

What are actually the criteria of illegitimate peers applied in bitcoin software, apart from the strange versions that they advertise and anything related to the obvious like that?

Thanks a lot in advance.
4  Bitcoin / Development & Technical Discussion / How to manually verify blk*.dat and rev*.dat files? on: February 20, 2019, 05:21:02 PM
I apologise if this had been asked and answered before, but I failed to find that on this forum.

Every time I found a new VPS provider offering cheaper and bigger resources, I move my full node to the new VPS. I make sure the integrity of blk*.dat and rev*.dat files by comparing their md5sum on the source and target VPS.

I recently decided not to renew the contract of one of my VPS'. Instead of letting it waiting for its contract expiry date and doing nothing, I configured another full node with pruning as it has only about 100 GB storage space.

When I compared the pruning full node with the main one, the most recent blk*.dat and rev*.dat files have different md5sum as below.

Code:
.
.
49d09f29e04dd8c91fea980a1978ee9c  blk01510.dat 49d09f29e04dd8c91fea980a1978ee9c  blk01510.dat
6bdeff13773a02b73b38a859b5f8a461  blk01511.dat 6bdeff13773a02b73b38a859b5f8a461  blk01511.dat
e419727a0b5a370256f623ccbac64e13  blk01512.dat e419727a0b5a370256f623ccbac64e13  blk01512.dat
802fa5848a9cb9fa4adc0b5e2b584207  blk01513.dat      | 3edb80b29dbb6b80c9fbe477d26b5edd  blk01513.dat
bb8f563889804ebce134f371cdd61213  blk01514.dat      | eb7642fcc1de5ff0825a23e23d991e71  blk01514.dat
eeedb8d91fe9fa7cc19021d142744b0f  blk01515.dat      | 08786174285354d992c730c14fb50edb  blk01515.dat
.
.
2e3c8f5cf0bfa1e9147390d238d71001  blk01533.dat      | 07e3d7f105cf504830afae31be5c9574  blk01533.dat
caf153aaf6433814b6579f0a531ae6b4  blk01534.dat      | 5f3021e57cfd4a97204bf25f38ef56a8  blk01534.dat
9a7d8d931540f64a06c7fce73db791cf  blk01535.dat      | 49ae0a801b7fd36ff22f578e521141a8  blk01535.dat
.
.
3a70613f860c242201f4f84d27524992  rev01510.dat 3a70613f860c242201f4f84d27524992  rev01510.dat
7dc17fc34d5ffe5dca1f4fccf0591641  rev01511.dat 7dc17fc34d5ffe5dca1f4fccf0591641  rev01511.dat
ac77bbefd85305fce50dfcc63e41cd1d  rev01512.dat ac77bbefd85305fce50dfcc63e41cd1d  rev01512.dat
95c0f5bc1b19ceee3ee7ba727e580fd3  rev01513.dat      | 0c861743a64dfa3b50002aee40e391b9  rev01513.dat
9d6d81f0429fc33f36ed7fb49cdfe1bd  rev01514.dat      | 74caa8ce3429ccb55e4fb50de0a23630  rev01514.dat
375cf8c1ffef33d6899981d09087205b  rev01515.dat      | 43c2a326b5c5c66da8172f924ba4357d  rev01515.dat
.
.
207ce7cc6b82f9dd0e514edfbfaa3332  rev01533.dat      | dd0dc8175770ea616dce3d7c4fb292fc  rev01533.dat
3a22716cecc8759d96545c8be7274c4a  rev01534.dat      | 167bce7ead5ee42fcdb7629fb86edb2e  rev01534.dat
befed144db33cd208be59bdedb360098  rev01535.dat      | 63fa05c946ad883797ed6053b3a87da5  rev01535.dat

That makes me wonder on the integrity of my blockchain files.

As far as I know, the only command to verify the blockchain database is "bitcoin-cli verifychain" as below

bitcoin-cli shell
Code:
anto@deeppurple:~$ bitcoin-cli verifychain 4 100
true
anto@deeppurple:~$

debug.log
Code:
.
.
2019-02-20T16:46:18Z Verifying last 100 blocks at level 4
2019-02-20T16:46:18Z [0%]...[10%]...[20%]...[30%]...[40%]...[50%]...[DONE].
2019-02-20T16:47:32Z No coin database inconsistencies in last 100 blocks (236944 transactions)
.
.

But I don't think that will tell me which blk*.dat and rev*.dat files that are corrupted (if any). And it will take quite a long time to verify the whole blockchain files.

Is there any better and faster way to manually verify those blk*.dat and rev*.dat?

What will happen if my full node sends corrupted data to its peers who asked very old blocks, due to the corrupted blk*.dat and rev*.dat files? Will my full node get notified so that it can automatically repair the relevant corrupted blk*.dat and rev*.dat files?

Thanks a lot in advance for your help.
5  Bitcoin / Development & Technical Discussion / Bitcoin Core tarball differences on: November 25, 2017, 08:43:14 AM
I always use the tarball from https://github.com/bitcoin/bitcoin/releases. My wallet and 2 nodes are on Bitcoin Core 0.15.0.1. Today I want to upgrade them to Bitcoin Core 0.15.1.

I usually ignore the notes on that github release page which says the following:

Quote
Preferably use the above download link, not the below links to download the source tarball, as the release tarballs are generated deterministically and GitHub's are not.

I always use the tarball on the "below links", not the "above download link". What is/are the differences between them actually?

Thanks a lot in advance.
6  Bitcoin / Bitcoin Discussion / Wallet addresses with small amount of BTC on: November 12, 2017, 07:37:20 PM
Perhaps I didn't use the right term so I found no similar question on this forum. So I am sorry if I repeat the question.

I have several addresses in my wallet containing very small amount of BTC ranging from 0.1 mBTC to 3 mBTC. I cannot practically use them to buy anything, because the fee becomes much higher than the total of them as the transaction size becomes quite big when I combine them.

I don't think we can merge them into a single address offline (assuming that is possible) as they have to be included into the block chain.

What should I do with them? Does anybody have any suggestions?

Thanks in advance for your help.

7  Bitcoin / Bitcoin Technical Support / Invalid IP addresses on "receive version message" on debug.log on: February 20, 2016, 10:21:53 PM
On my full nodes, I got a lot of "receive version message" on the debug.log with "us=0.0.0.0" and "us=127.0.0.1". There are only a few peers causing the messages with IP address 0.0.0.0 but hundreds of peers causing the messages with IP address 127.0.0.1.

The peers which cause the messages with 0.0.0.0 IP address are using the following User Agents:
Code:
/libbitcoin:2.11.0/: version 70001
/Satoshi:0.11.2/: version 70002

And the peers which cause the messages with 127.0.0.1 IP address are using the following User Agents:
Code:
/BitCoinJ:0.11.2/MultiBit:0.5.18/: version 70001
/bitcoinj:0.12.2/: version 70001
/BitCoinJ:0.12SNAPSHOT/Aegis Wallet:1.0/: version 70001
/bitcoinj:0.13.2/Bitcoin Wallet:4.39/: version 70001
/bitcoinj:0.13.3/Bitcoin:1.04/: version 70001
/bitcoinj:0.13.3/Bitcoin Wallet:4.42/: version 70001
/bitcoinj:0.13.3/Bitcoin Wallet:4.43/: version 70001
/bitcoinj:0.13.3/Bitcoin Wallet:4.44/: version 70001
/bitcoinj:0.13.3/MultiBitHD:0.2.0/: version 70001
/bitcoinj:0.13.4/Bitcoin Wallet:4.45/: version 70001
/bitcoinj:0.13.4/Bitcoin Wallet:4.46/: version 70001
/bitcoinj:0.13/GetGems:1.0/: version 70001
/bitcoinj:0.13-SNAPSHOT/DNSSeed:43/: version 70001
/bitcoinj:0.13SNAPSHOT/DNSSeed:43/: version 70001
/Bither1.4.3/: version 70001

I am really wondering what causes this and what the impact of letting the peers which cause that keep coming in. Do you think it is wise to block those peers on my iptables firewall using ipset for instance?

Thanks in advance for any answers and comments.
8  Bitcoin / Bitcoin Technical Support / Wrong implementation - Bitcoind does not use externalip for outgoing connection on: February 06, 2016, 09:49:21 AM
I have just raised this issue on github as below.

Quote
I have 4 IPv6 addresses on the eth0 interface of my VPS. I have set routings of all those IPv6 addresses using "ip -6 rule", "ip -6 route" and their corresponding fwmark label on ip6tables. I want all bitcoind packets for both outgoing and incoming connections to use one specific IPv6 address which is not the default outgoing IPv6 address. I set the externalip to that specific IPv6 address and the discover=0.

However, bitcoind keeps using the default IPv6 address for outgoing connection. I can force the outgoing packets from bitcoind to go out to its specific IPv6 address using ip6tables SNAT. But that is an ugly workaround. So I have no choice than to set the IPv6 address of bitcoind as the default outgoing IPv6 address.

What is the point to provide the possibility to set the external IP address, i.e. externalip parameter, if it is not being used for the outgoing connection? It does not really make sense if the externalip parameter is only being used for the incoming connection, because all peers only know how to connect to my full node base on the IP address that my full node uses for the outgoing connection. So if my full node is connecting to all peers with different IP address than the one it is expecting to receive the incoming connection, my full node will never have peers that can connect to it as the port 8333 is only opened on its specific IP address.

I saw similar issues on github, but I don't see any good answers for that. Does anybody have a workaround or a patch for bitcoind, so that bitcoind uses the externalip that we set for outgoing connection?
9  Bitcoin / Bitcoin Technical Support / Bitcoin full nodes with IPv4 and IPv6 - Why most peers are on IPv4? on: January 31, 2016, 03:34:53 PM
I have been running 2 Bitcoin full nodes for a few weeks using 0.11.2 version on Linux. On each node, I set to accept connections on both IPv4 and IPv6.

On the incoming connection, the number of peers connected to my nodes are mostly on IPv4, in the order above 80 peers while only about 3 peers connected on IPv6.

On the outgoing connection, my nodes always connect by itself to 7 different peers on IPv4 but only 1 peer on IPv6. I am using the default maxconnections, which I believe it is 125 connections for both outgoing and incoming connections.

I can force my nodes to connect to IPv6 peers using addnode command, but I am wondering why my nodes does not want to connect to more IPv6 peers by itself and why only a few IPv6 peers connected to them. Do you guys have any idea why this is happening?
10  Bitcoin / Bitcoin Technical Support / Suppressing useless messages from debug.log on: January 05, 2016, 11:21:21 PM
I have been running full nodes for quite sometime now. I have added another full node in the last few weeks and I have upgraded the bitcoind to version 0.11.2. Everything is running fine except that I cannot figure out how to suppress the useless messages like below from being inserted into the debug.log file.
Code:
.
2016-01-05 22:51:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2016-01-05 22:51:24 ERROR: AcceptToMemoryPool: free transaction rejected by rate limiter
2016-01-05 22:51:24 ERROR: AcceptToMemoryPool: free transaction rejected by rate limiter
2016-01-05 22:51:31 ERROR: AcceptToMemoryPool: free transaction rejected by rate limiter
2016-01-05 22:51:31 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2016-01-05 22:51:33 ERROR: AcceptToMemoryPool: free transaction rejected by rate limiter
2016-01-05 22:51:43 ERROR: AcceptToMemoryPool: free transaction rejected by rate limiter
2016-01-05 22:51:48 ERROR: AcceptToMemoryPool: free transaction rejected by rate limiter
.

The bitcoin documentation mention the following options, but I cannot find any more detail information about what each category does and how to set them.
Code:
-debug=<category>   Output debugging information (default: 0, supplying <category> is optional) 
                    If <category> is not supplied, output all debugging information. 
                    <category> can be: addrman, alert, bench, coindb, db, lock, rand, rpc, selectcoins, mempool, net.

Which category is related the above messages? And could I actually use multiple categories, e.g. debug=addrman,bench,coindb, except the category of the above messages?

As the type of the above messages is ERROR message and if I would suppress such messages, would that mean I will not see other ERROR messages that are important?

Thanks in advance for your help.
11  Bitcoin / Mining software (miners) / UNOMP - How to distribute the reward based on a list? on: December 05, 2015, 10:20:00 AM
According to UNOMP sample config on github, we can distribute the reward by setting it on the pool config like below
Code:
    "address": "mi4iBXbBsydtcc5yFmsff2zCFVX4XG7qJc", //Address to where block rewards are given

    /* Block rewards go to the configured pool wallet address to later be paid out to miners,
       except for a percentage that can go to, for examples, pool operator(s) as pool fees or
       or to donations address. Addresses or hashed public keys can be used. Here is an example
       of rewards going to the main pool op and a pool co-owner. Can also be set for mandatory
       donation coins like GRE and DMD. */
    "rewardRecipients": {
        "n37vuNFkXfk15uFnGoVyHZ6PYQxppD3QqK": 1.5, //1.5% goes to pool op
        "mirj3LtZxbSTharhtXvotqtJXUY7ki5qfx": 0.5 //0.5% goes to a pool co-owner
    },

I believe this setting is only being loaded once at the time we start the pool.

I would like to use only the "rewardRecipients", so no "address" setting. And I would like to maintain the list of addresses for the "rewardRecipients" outside UNOMP and I would like UNOMP to regularly load that list.

Does anybody have suggestion on how to achieve that?

Thanks in advance for your help.
12  Bitcoin / Mining software (miners) / Pool server software - CoiniumServ vs UNOMP on: November 29, 2015, 07:54:03 PM
I have been evaluating some pool server software, i.e. CoiniumServ, UNOMP, Eloipool, CKPool and some other smaller projects. It seems that only CoiniumServ and UNOMP offer a complete package including the web front end. However, the look of those web front ends are very similar to the Nexious scammer pool. But perhaps I could modify that. I have 2 small VPS' to test them, but I am not sure if they would be enough for running a public pool server.

Does anybody have any recommendations on CoiniumServ or UNOMP especially regarding the requirements of CPU and RAM on the server? For instance, how many user connections would be supported by running one of them on a VPS with 2 GHz CPU and 1 GB RAM?

Thanks in advance for your comments and recommendations.
13  Bitcoin / Pools / A dream of having a new pool on: November 28, 2015, 12:57:54 PM
I am a new hobbyist miner with only 150 Gh/s total hashrate. I have been searching for pool that can give me the highest payout in the last 5 months, but I still cannot find the right one for me. The pool that I have been mining on the longest is Eligius. But I still don't see it to be a fair pool for me as I cannot set my difficulty to below 512. So I am dreaming to have my own pool.

I am still not familiar with the terms in Bitcoin. And I still do not understand all about mining business. So I would like to get inputs from all of you on this.

If I would make a public pool with the objectives, requirements and payout scheme as below, do you think I would reach my objectives? Do you think the requirements and payout scheme make sense? And what do you think we could improve to reach the objectives?

Objectives:
- Decentralise Bitcoin network, so it will only support Bitcoin
- Attract miners with low hashrates and pool hoppers
- Provide more advantage to miners with low hashrates
- Transparent information on the reward payout
- The pool must not make any profit but it must not go bankrupt

Requirements:
- Miners do not need to register to the pool
- Miners can only use Bitcoin address to mine
- Bitcoin address of the miners will be validated
- Miners with invalid Bitcoin addresses will be rejected
- Minimum accepted hashrate per Bitcoin address is 100 Gh/s
- Maximum accepted hashrate per Bitcoin address is 1000 Gh/s
- Miners with hashrates lower than 100 Gh/s must join a group and mine with a single Bitcoin address
- The distribution of payout on the miners' group should be managed by the group
- Miners will submit approximately the same shares managed by vardiff
- The fee for the pool maintenance is 0.05% of the total reward
- All 99.95% of the reward must go to the miners
- The minimum payout for each Bitcoin address is 0.001 BTC
- The payout will be rounded down to the nearest 0.000001 BTC
- The remaining dust payout will go to the pool maintenance account

Payout scheme:
- All miners will get the payout based on their porpotional and bonus shares
- The coinbase transaction of the miners' Bitcoin addresses will be updated each hour
- The payout will be based on the total shares recorded on the previous hour
- The shares that have been paid out will be reset at the time the payout is being executed
- When the total shares of miners remain the same on previous 2 hours, they will be set as dormant miners
- The total share of each dormant miner will be deducted by 1% and they will be distributed to all active miners on the next hour as bonus share
- The dormant miners will be changed back as active miners when their total shares on previous 2 hours keep increasing
14  Bitcoin / Pools / mBTC on kano.is was Re: Nexious.com WARNING POOL OPERATOR IS NOT PAYING NOR RESPONDING on: November 27, 2015, 08:37:20 PM
Ok... now if we go back to my original statement, with Eligius, you can never, ever make more than that 0.064146152448BTC in those 12 weeks.  On kano, you can make more than that, or you can make less.  Kano's pool has, since inception, been running about 101% luck.  That has no bearing on future luck - it is just a metric of past performance.  However, it is a metric that shows had you been mining on Eligius for the past year and on kano for the past year, given identical hash rates on each pool, you would have made more on kano.

I have been mining on Kano's pool from 20/11/2015 until now or about 7 days and I have got only 1.5 mBTC in total from blocks 384498, 384724, 384805 and 385383. If I would have mined on Eligius, I would have made about 5 mBTC. On Antpool, I would have made about 4 mBTC. How would that be practically possible to make more BTC on Kano's pool than Eligius, even if I would mine on Kano's pool for a year?
Pages: [1]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!