text:
Are transactions included in a block or is only the Merkle-root hash included in a block
Before broadcasting block into bitcoin blockchain, Does a Block transactions are included in a block or only the hash of them are included in a block. While I am surfing through net, I came across two images which are very ambiguity because in picture-1 transactions are out of block and in picture-2 transactions are included in block and the images are as shown below:
Picture -1:

Picture -2

in picture-1 transactions are out of block and in picture-2 transactions are included in block

In your picture-1, the transactions are NOT shown as outside the block. They are shown as outside the "block header"
Your picture-1 has the caption "Simplified Bitcoin Block Chain". You should take care not to interpret a simplified diagram as if it were completely accurate. The second diagram is also simplified and not a complete specification of data in a block.
Both these diagrams have misleading elements. For example the direction of arrows in the first diagram. The inclusion of "proof of work" in the second diagram as if that were a data item stored in the block structure. It isn't.

Are transactions included in a block or is only the Merkle-root hash included in a block

The cause of this confusion is that

The block hash includes the block header only†.
The block data includes a block-header and all transaction data.

†The hash of the block does not directly include the transaction data. The transaction data is included indirectly.
One of the items in the block header is the Merkle root. The Merkle root is a hash resulting from repeated pairwise hashing of transaction data. A consequence of this is that altering any transaction would result in a different block hash.

See

Block structure
Transaction structure
What are the components of the raw block shown in this image?
In what format does a block store the transaction data?

I believe the field "proof of work" referred to is actually the nonce; that is sometimes referred to as the proof.

@Pieter: In Picture-2, "proof of work" is pointed to by "previous block" in the next block and it starts with many zeroes. Aren't both rather suggestive of block hash?

Oh, yes, I guess that's an attempt at referring to the block hash. Strange that it's not hexadecimal though.

Merkle tree root exists and is stored inside Block header.
Transactions are themselves the leafs of the merkle tree.
The merkle tree is used to attach Transactions to the Block header.
Therefore, in Bitcoin, Block is Block header and Transactions


text:
Did the P2SH BIP-0016 make some Bitcoin unspendable?
The P2SH feature currently in use was introduced to Bitcoin in 2012 with BIP-0016.
It was successfully activated on 2012-04-01 with block 173805.
The BIP turned a particular "hashlock" locking script pattern (OP_HASH160 OP_DATA_20 20-byte-value OP_EQUAL) into a "magical" bytecode pattern which, after authenticating an input's top stack element against the hash then also executes it using Script VM.
The BIP references 1 historical transaction that spent from an output that matched the pattern:

These new rules should only be applied when validating transactions in blocks with timestamps >= 1333238400 (Apr 1 2012) [1]. There are transactions earlier than 1333238400 in the block chain that fail these new validation rules. [2]. Older transactions must be validated under the old rules. (see the Backwards Compatibility section for details).

which made me wonder - are there other, unspent, historical hashlock outputs which may have been made unspendable (if they weren't already) by introduction of the P2SH feature?

Even before BIP-0016 activation, there were some outputs that matched the P2SH pattern.
Only one of them was spent before activation, and the rest have likely been made unspendable by the BIP-0016 upgrade since spending them would have to satisfy consensus rules not enforced when they were created.
Total amount locked in those outputs was 0.044 BTC.
Table 1: Outputs matching the locking script pattern OP_HASH160 OP_DATA_20 value_20 OP_EQUAL, extracted from blocks 0 to 173805.

Block Height
TXID
Output Index
Satoshi Amount
Locking Script
Status

170052
9C08A4D78931342B37FD5F72900FB9983087E6F46C4A097D8A1F52C74E28EAF6
1
400000
a91419a7d869032368fd1f1e26e5e73a4ad0e474960e87
Spent

170054
B0539A45DE13B3E0403909B8BD1A555B8CBE45FD4E3F3FDA76F3A5F52835C29D
1
400000
a914e8c300c87986efa84c37c0519929019ef86eb5b487
Unspent

170434
D0636198EA55FADEE5B4CCC07C85012DB7D07C2D25790B3AEC770C86617801C0
1
1000000
a91484b8ee2ee2970e4a5c3a18e73a9e251ad5c1df1c87
Unspent

170442
9AB59E2D4BE16C470160EB9B9A9D9799EAF29AF0461AEA131E748659D806FA1A
0
1000000
a91484b8ee2ee2970e4a5c3a18e73a9e251ad5c1df1c87
Unspent

170442
658FC92061F1C4125D5CD1034EB8A1F09BFEBD32A988D855EB7EE63689759A21
0
1000000
a91484b8ee2ee2970e4a5c3a18e73a9e251ad5c1df1c87
Unspent

170556
510B5A44935109E249A704C2900AA9D8303166062E81D2AC852C965B6266DCEE
0
1000000
a91484b8ee2ee2970e4a5c3a18e73a9e251ad5c1df1c87
Unspent

@Schmidty I saw your edit request and link to the BIP. Note that the BIP talks about processing the one historical transaction when validating the blockchain from scratch and only makes reference to that 1 TX. It doesn't talk about these historic UTXOs, and possibility of spending them post-activation.

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

sort: votes


text:
Why does Bitcoin Core verify already verified blocks?
I have observed that when I restart my Raspberry Pi, which I had left at a specific height (for example, 800,000), the software starts verifying the last x blocks, beginning from a point prior to height 800,000. Why does this occur since it had already verified those prior to 800,000?

It does that as a consistency check to be more sure that the data stored on disk was not modified or otherwise corrupted in the time the node was offline.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Don't understand fees on a particular bitcoin block
I am comparing and contrasting blocks 200000 and 164246 of the bitcoin blockchain (looking via the bitcoind api or https://www.blockchain.com/explorer?utm_campaign=expnav_explorer is fine).
Looking at the coinbase transaction in 200000, the output amount (of 50.635...) is clearly the sum of the mining fee (50) and the sum of the transaction fees.
Looking at 164246, the coinbase output amount is exactly 50. Yet there are clearly fees in the 100 transactions in the block. Where have the fees gone? Have they not been collected by the miner?

Yes, according to the Bitcoin protocol rules, miners can claim up to the maximum block reward (subsidy + fees). This answer goes into more detail into this and other ways bitcoins can be lost.
Using a block explorer like blockchair.com you can construct a query for blocks that have non-zero fees but nevertheless have claimed exactly 50 BTC: https://blockchair.com/bitcoin/blocks?s=fee_total(desc)&q=fee_total(1..),reward(5000000000)#f=id,time,guessed_miner,fee_total,reward
As you can see it returns around 200 blocks in total. If you sort them by total fee, block 164246 is right on top, having failed to collect around 1.76 BTC in fees. You can try the same thing for other block subsidies (25, 12.5 and 6.25 BTC).

Thank you that's clear (and for the references). Yes, I highlighted 164246 because it was the most prominent difference I had come across.

Bitcoin's consensus rules only stipulate that the miner can not claim more than the subsidy + fees in their coinbase transaction. There is no requirement that they clain the full amount, so it is possible for a miner to claim less than the amount that they are entitled to. The unclaimed coins are thus lost forever.
Of course it is in a miner's best interest to claim as much of the reward as they can. They are financially incentivized to do so. However there have been bugs in mining software which have resulted in several blocks failing to claim the full amount, and that has resulted in those coins being permanently burnt.

I can't upvote this question (no reputation :) ) but thank you that was clear and helpful


text:
Is this script a non-standard script?
I am currently reviewing a computer science conference paper. The authors in the paper mention that the following is a non-standard script.
OP_DUP
OP_HASH160
OP_0
OP_EQUALVERIFY
OP_CHECKSIG
But when I checked the transaction on the explorer, its output script has NULL_DATA https://btc.com/btc/transaction/03acfae47d1e0b7674f1193237099d1553d3d8a93ecc85c18c4bec37544fe386
Which is the above two is true? Thank you

This script is almost exactly the same as the standard Pay-To-Public-Key-Hash (P2PKH) script, except instead of pushing the hash onto the stack it pushes an empty vector.
As a reminder, a P2PKH script locks an output with the hash of a public key. To spend this output one must provide both the public key and a signature generated from its corresponding private key. Since the hash function always produces a 20-byte hash and never an empty vector, there is no public key to satisfy this script, making the output forever unspendable.
Why this output exists I can't tell you, but a bitcointalk.org message mentions there are 23 of these. Most likely it's the result of a software bug.
NULL_DATA is probably just that specific blockchain explorer's label used for non-standard outputs. mempool.space marks this as UNKNOWN.


text:
Scripthash from bitcoin address with Golang
I broke my head looking for a solution.
I want use bitcoin address for electrumx
Take bitcoin address from docs example: 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa
And i need convert to 8b01df4e368ea28f8dc0423bcf7a4923e3a12d307c875e47a0cfbf90b5c39161
Example from docs https://electrumx.readthedocs.io/en/latest/protocol-basics.html#script-hashes
For example, the legacy Bitcoin address from the genesis block:
1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa

has P2PKH script:
76a91462e907b15cbf27d5425399ebf6f0fb50ebb88f1888ac

with SHA256 hash:
6191c3b590bfcfa0475e877c302da1e323497acf3b42c08d8fa28e364edf018b

which is sent to the server reversed as:
8b01df4e368ea28f8dc0423bcf7a4923e3a12d307c875e47a0cfbf90b5c39161

By subscribing to this hash you can find P2PKH payments to that address.

my code:
func AddressToScriptHex(addressStr string) string {
    address, err := btcutil.DecodeAddress(addressStr, &chaincfg.MainNetParams)
    if err != nil {
        return ""
    }
    script, err := txscript.PayToAddrScript(address)
    if err != nil {
        return ""
    }
    return fmt.Sprintf("%x", script)
}

func TestBtcUtil_AddressToScriptHex(t *testing.T) {
    addressStr := "1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa"
    scriptHex := "76a91462e907b15cbf27d5425399ebf6f0fb50ebb88f1888ac"

    assert.Equal(t, AddressToScriptHex(addressStr), scriptHex)
}

func TestBtcUtil_ScriptHexToSHA256(t *testing.T) {
    scriptHex := "76a91462e907b15cbf27d5425399ebf6f0fb50ebb88f1888ac"
    exampleHash := "6191c3b590bfcfa0475e877c302da1e323497acf3b42c08d8fa28e364edf018b"
    sha256 := sha256.New()
    sha256.Write([]byte(scriptHex))

    actual := fmt.Sprintf("%x", sha256.Sum(nil))

    assert.Equal(t, exampleHash, actual) // ERROR
}

why actual != example

i was find other question, but they use other language
ScriptHash from bitcoin address with BitcoinJS
Help me please

Change
sha256.Write([]byte(scriptHex))

to
s, err := hex.DecodeString(scriptHex)
if err != nil {
    log.Fatal(err) // or t.Fatalf(...) in unit test
}
sha256.Write(s)

You must hash the binary data, not the hex string representation of it
See https://go.dev/play/p/iKHNKy118zd

You saved my head from an explosion. Thanks, this is exactly what I need! I gave you the status of the correct answer, but I can not give you a plus, due to the lack of 15 reputation units. Thank you.


text:
Why does a single expired HTLC with an unresponsive peer cause automatic force closure of the whole channel?
As far as I understand: the expiration of a single HTLC in a payment channel with an unresponsive partner causes the whole payment channel to force close (Behaviour A). This has been discussed, for example, in this question; the addition of covenants to bitcoin would allow a participant to only settle on-chain the expired HTLC, without the need to close the entire channel (Behaviour B).
First of all, is my understanding correct? If it is, then why is not possible today to implement, using pre-signed transactions, the behaviour B?
I would like to understand what is preventing parties to have multiple pre-signed transactions to settle a channel on-chain, one that closes the whole channel (just as it is today), and another one that keeps the channel open (i.e. it has a 2-of-2 multisig output) and just settles the HTLC on the blockchain. Is it just technically difficult or theoretically impossible without covenants?


text:
Recreating bitcoin core signature
I am trying to recreate the exact same signature as Bitcoin Core. I have installed bitcoin-core/secp256k1, but I get sometimes different signature as Bitcoin Core (which are valid). I read that since v0.17 there is an additional entropy (32 bit little endian unsigned integer with a counter). Due to my limiting experience I am not able to fully understand and implement it.
Could someone please give me some hints how to implement this counter in my code to produce the exact same signatures as Bitcoin Core.
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <secp256k1.h>

// Function to convert hex string to byte array
void hex_to_bytes(const char *hex_str, unsigned char *byte_array, int byte_array_length) {
    for (int i = 0; i < byte_array_length; i++) {
        sscanf(hex_str + 2 * i, "%2hhx", &byte_array[i]);
    }
}

int main(void) {
    // Initialize secp256k1 context
    secp256k1_context *ctx = secp256k1_context_create(SECP256K1_CONTEXT_SIGN);

    // Provided private key and message hash in hex
    const char *priv_key_hex = "a8188b5621448098ae66fec001acff97b7b5dcfbe371b433455135794daec37a";
    const char *msg_hash_hex = "81fdf78421e2395807c9e41fa0b5ef2b587e5096d5eec43605fd669be824a872";

    unsigned char priv_key[32];
    unsigned char msg_hash[32];
    hex_to_bytes(priv_key_hex, priv_key, sizeof(priv_key));
    hex_to_bytes(msg_hash_hex, msg_hash, sizeof(msg_hash));

    // Sign the transaction hash
    secp256k1_ecdsa_signature signature;
    secp256k1_ecdsa_sign(ctx, &signature, msg_hash, priv_key, NULL, NULL);

    // Serialize the signature in DER format
    unsigned char der_signature[72];
    size_t der_sig_len = sizeof(der_signature);
    secp256k1_ecdsa_signature_serialize_der(ctx, der_signature, &der_sig_len, &signature);

    // Print the DER-encoded signature in hexadecimal
    printf("DER-encoded Signature: ");
    for (size_t i = 0; i < der_sig_len; i++) {
        printf("%02x", der_signature[i]);
    }
    printf("\n");

    // Free the secp256k1 context
    secp256k1_context_destroy(ctx);

    return 0;
}

Data:
tx_hash: 81fdf78421e2395807c9e41fa0b5ef2b587e5096d5eec43605fd669be824a872
key1_hex: a8188b5621448098ae66fec001acff97b7b5dcfbe371b433455135794daec37a
key2_hex: 9c1fa27bdf0e6d06ab451375aa4c29ca4298af28b97ac8773200054e98a2e215
Bitcoin core signatures:
304402203688862c2e94573a43e66305358aa74e84ace947ce080667e31265787f3738c10220380fa99f9507ae2dee832d19a7ee8fb2307708ff30e7a1532eb30a17877fa7fe
304402204647371d0957d5456484337ff9860ab86026f05e0e97533f09126635c35a4a1302200ee59f53f4e25f2b5f2239547a8719ea58b90d98a4afcc42fe1e55dbc70debc8
Signatures with my code:
3045022100803388608a707cf1cab202a3bd758af2d42dafaf1c07ee45283b8fb478953b5002205a132280324832637d5082b8c6e42af74236647b893effe47f72472ad277a073
3045022100a3378d3c142daead02c00d14ca69de55bcb1415e8df34173f891e7af5a7d78660220334a57a745e10d92cb007f7ddc905f3a2aa2ce72dad7b065fff339e461fa2260

Related: https://bitcoin.stackexchange.com/q/111660/5406

I have implemented the counter and can reproduce the exact same signature as bitcoin core. Use with caution)
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <secp256k1.h>
#include <assert.h>

// Function to write a 32-bit unsigned int to a byte array in little-endian format
static inline void WriteLE32(unsigned char* ptr, uint32_t x) {
    uint8_t data[4] = {
        (uint8_t)(x & 0xFF),
        (uint8_t)((x >> 8) & 0xFF),
        (uint8_t)((x >> 16) & 0xFF),
        (uint8_t)((x >> 24) & 0xFF)
    };
    memcpy(ptr, data, 4);
}

void hex_to_bytes(const char *hex_str, unsigned char *byte_array, int byte_array_length) {
    for (int i = 0; i < byte_array_length; i++) {
        sscanf(hex_str + 2 * i, "%2hhx", &byte_array[i]);
    }
}

int is_low_r(const secp256k1_ecdsa_signature *sig, secp256k1_context *ctx) {
    unsigned char compact_sig[64];
    secp256k1_ecdsa_signature_serialize_compact(ctx, compact_sig, sig);
    return compact_sig[0] < 0x80;
}

void print_signature(const secp256k1_ecdsa_signature *sig, secp256k1_context *ctx, const char* label) {
    unsigned char der_signature[72];
    size_t der_sig_len = sizeof(der_signature);
    secp256k1_ecdsa_signature_serialize_der(ctx, der_signature, &der_sig_len, sig);

    printf("%s Signature: ", label);
    for (size_t i = 0; i < der_sig_len; i++) {
        printf("%02x", der_signature[i]);
    }
    printf("\n");
}

// Function to print extra entropy
void print_extra_entropy(const unsigned char* extra_entropy, const char* label) {
    printf("%s Extra Entropy: ", label);
    for (int i = 0; i < 32; i++) {
        printf("%02x", extra_entropy[i]);
    }
    printf("\n");
}

int main(void) {
    secp256k1_context *ctx = secp256k1_context_create(SECP256K1_CONTEXT_SIGN);
    const char *priv_key_hex = "79ae83f3ad0768dc7285f5b3b04e1a4277b791f1c262fea3152dc3cacbcc48f0";
    const char *msg_hash_hex = "496e448e4ddc9e493f165d900e604fd6f04bd4a7db99638947994ceac15519a1";

    unsigned char priv_key[32];
    unsigned char msg_hash[32];
    hex_to_bytes(priv_key_hex, priv_key, sizeof(priv_key));
    hex_to_bytes(msg_hash_hex, msg_hash, sizeof(msg_hash));

    secp256k1_ecdsa_signature signature;
    unsigned char extra_entropy[32] = {0};
    uint32_t test_case = 0; // Example test case initialization
    uint32_t counter = 0;
    int ret;

    // Enable grinding
    int grind = 1;

    // Initial signature generation with conditional extra entropy
    WriteLE32(extra_entropy, test_case);

    // In the ini run entropy is not NULL. Will not work correctly if just 32 bytes of 0s are passed in. Dont know why.
    ret = secp256k1_ecdsa_sign(ctx, &signature, msg_hash, priv_key, secp256k1_nonce_function_rfc6979, (!grind && test_case) ? extra_entropy : NULL);
    assert(ret);
    if (!is_low_r(&signature, ctx)) {
        print_signature(&signature, ctx, "Initial High R");
    } else {
        print_signature(&signature, ctx, "Initial Low R");
    }

    // Grinding for low R signatures, if necessary
    while (grind && !is_low_r(&signature, ctx)) {
        WriteLE32(extra_entropy, ++counter);
        print_extra_entropy(extra_entropy, "Grinding");
        ret = secp256k1_ecdsa_sign(ctx, &signature, msg_hash, priv_key, secp256k1_nonce_function_rfc6979, extra_entropy);
        assert(ret);
        if (is_low_r(&signature, ctx)) {
            print_signature(&signature, ctx, "Low R");
        } else {
            print_signature(&signature, ctx, "High R");
        }
    }

    secp256k1_context_destroy(ctx);
    return 0;
}

// gcc sign.c -lsecp256k1 -o sign
// ./sign


text:
In a bitcoin multi-sig wallet, can i determine which of the m of n keys were used to send bitcoin?
I'm particularly interested in this for large n multi-sig wallets. For example, if m-of-n is 4-of-6, and 6 different people (e.g. 6 non-profit co-directors) hold each of the n keys. If one day all of the wallet is emptied just using 4 (m) keys, will the 2 (n-m) people be able to determine which were the 4 keys and thereby the 4 co-directors that emptied the wallet?

The signatures and public keys have to be supplied to spend the coins so yes you can tell by looking at the spending transaction on the blockchain.

So then I would need to know which individuals hold which public keys from the beginning, when the wallet is created?

Yes, that's correct

This mechanism is also only generally available to the participants in the multisig construction, if the common advice of no key reuse is followed.

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
Funds disapprearance
I stored 0.0154 BTC in my blockchain for mining purposes and next morning I found my balance to be 000, what does that mean? Are my coins lost or stored somewhere else?

What do you mean by "Mining purposes"? Did someone tell you to deposit it?

This question makes no sense.

I STORED 0.0154 BTC IN MY BLOCKCHAIN WALLET FOR MINING PURPOSE

Mining bitcoin does not require putting bitcoin into a wallet you own.
Asking people to link their wallets to a miner is a favourite trick of conmen / scammers.

IN THE NEXT MORNING I FOUND MY BALANCE TO BE 000 , WHAT DOES THAT MEAN?

If someone else knows the password to your online wallet, they can extract from it the "private key" which gives control over any bitcoin already sent to addresses in that wallet as well as any future amounts sent to addresses in that wallet (even after you change wallet passwords).
It is likely you are the victim of a conman and your money has been stolen.

Related questions with useful answers:

BTC Stolen from Blockchain

A guy ... told me that I can mine for bitcoin ... Within half an hour my wallet was empty.

Bitcoin Mining as a Newbie (link wallet to another person's miner)
I've been asked to share wallet credentials to participate in mining. Is that a scam?
I NEED YOUR HELP URGENTLY Bitcoins


text:
crypto password copay
I want to recover my wallet since I forget my encryption password, for this I am trying to import the wallet with the 12 words and the system gives me an "error" and the message "already this wallet exists". What should I do?

First, use your 12 words to import the wallet to another device. Once you have successfully done this, you should be able to delete the wallet from your original device, then re-import it.
I always recommend importing to another device first before deleting the original wallet, just in case the import has issues.


text:
Reg: Watch only Address
I have been given " Watch only Address" by one of my friends.
To make the funds credited into my account or to use the BTC, what is way to get the private key?
Do we need to pay anything to blockchain.info for releasing? Is the from my friend who is hiding the private key?

If someone is asking you to pay to release funds in a watch-only address, they are trying to scam you. You do not need to pay to unlock keys. Keys can be used straight away, provided you have them.

I have been given " Watch only Address" by one of my friend

This is a scam often used by online con-men posing as your friend.
A watch only address lets you watch a bitcoin wallet owned by someone else. They can move their bitcoins away at any time. You cannot spend their bitcoins.

Do we need to pay anything for the blockchain.info for releasing

No. If your "friend" claims to have earlier set up an online wallet for you and that the online service now need paying to release the private-key - your "friend" is lying to you in order to cheat you out of your money.
The Blockchain.info website has a link "Get a Free wallet". If your "friend" used that, they got a private-key for free. Note that this wallet belongs to them, not to you. That applies even if it appears to contain money that you gave to your "friend" or which they claimed to earned on your behalf by mining or trading.
blockchain.info's terms of services paragraph 10.2 says

When you create a Wallet, the Services generate and store a cryptographic private and public key pair that you may use to send and receive any supported Virtual Currency

So there is no cost to obtaining the private key when you create a free wallet.
See these similar questions from other victims of scams:

How can I get a private key for this address
Unlocking a Private Key from watch status
Recovering the private key from a blockchain wallet address


text:
Where do mined bitcoins go?
I am running a bitcoin node with the following bitcoind.conf
# bitcoind.conf
bind=127.0.0.1

# use minimum disk space
prune=550

# Pare down traffic to bare minimum
blocksonly=1
maxconnections=20
maxuploadtarget=150

# Use only tor
proxy=127.0.0.1:9050
listenonion=1
onlynet=onion

torcontrol=127.0.0.1:9051
torpassword=Not_Posting_Here
##############################
addnode=gyn2vguc35viks2b.onion
addnode=kvd44sw7skb5folw.onion
addnode=nkf5e6b7pl4jfd4a.onion
# more onion nodes elided

I have pared down the disk usage and bandwidth as much as possible.  I want to run a node that will allow me to spend coins anonymously - small purchases like 4chan passes etc.  Not too concerned with being robbed as my wallet would never have more than 50 dollars worth in it but want to be able to spend anonymously.
It's in the process of downloading enough of the blockchain to be ready to spend now ( I think - not too much traffic over tor according to nyx ) and I tail the debug log and see this sort of thing:
6b756b2d2cb7db97f39c7bd2 height=14835 version=0x00000001 log2_work=45.75637 tx=13952 date='2009-05-09 05:00:57' progress=0.000044 cache=3.0MiB(15823txo)
2018-04-17 13:11:31 UpdateTip: new best=00000000349ad71b516db92e4799a7bad2dc8976ca6b3cd2d894167011d51b92 height=13836 version=0x00000001 log2_work=45.756474 tx=17956 date='2009-05-09 05:44:46' progress=0.000044 cache=3.0MiB(14829txo)

and it keeps spitting these out
bitcoind is using like 1-3% of cpu according to top.
Is bitcoind  mining?  I don't want it to mine.
Is there a way to shut this off?
Also if it is mining, and if I can't stop it from mining, where would coins I'd mine go?  I search for this, but it says the miner gets them. BUT WHERE?  If I am the miner, how does bitcoind know what my bitcoin address is?
I have not created any addresses in my wallet. So where would the coins go?
The mining question is moot if I can find a way to shut off mining anyway.
I have run a node once and deposited some coins in the wallet, and then later spent them.  But I want to do this all over tor without hogging all my bandwidth or disk space.

Bitcoin Core no longer contains any mining code, so it's definitely not mining.  (If it were, you'd see 100% CPU usage.)  Mining has nothing to do with the behavior you are seeing.
You're downloading the entire block chain (150+ GB) and checking it for validity, which explains the CPU usage.   The UpdateTip message simply records that you've received a new block, and you've checked it and determined that it is a valid addition to the blockchain.  This is normal behavior for Bitcoin Core or any other full node, and is inherent to its operation.
I see you have enabled pruning, so that will save disk space.  It won't save bandwidth or CPU though.  If you don't want to use that much bandwidth, don't use Bitcoin Core.  There are other "thin" wallet clients that don't need to download the entire blockchain - the tradeoff is that you have to trust other nodes to tell you that transactions are valid, instead of being able to check it for yourself.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
Why is concatenating scriptPubKeys and scriptSigs unsafe?
Around the 5:00 timestamp in this talk, John Newbery states that running the concatenation of scriptPubKey and scriptSig is unsafe, since it can result in someone using a carefully crafted scriptSig in order to spend any output.
What would such a scriptSig look like?

It was possible (see the infamous "1 RETURN bug") because the RETURN operand used to stop the execution of the Script. So simply pushing 1 in the scriptSig and RETURNing would make the execution of the catenated scriptSig || scriptPubKey successful no matter the content of the scriptPubKey.
Separating both certainly makes it easier to reason about and therefore be certain it's safe from this failure mode.

I initially posted this answer with an assertion that once the RETURN operand was fixed it was unclear how you would bypass the scriptPubKey. I didn't think hard enough! Actually you could simply include a PUSHDATA, which would interpret the scriptPubKey as a data array pushed on the stack, which would then make the execution successful since it would be casted to true as long as it's not all 0x00s.
So it's true that catenating the scriptSig and the scriptPubKey is always unsafe.

Thanks! I was under the impression that RETURN always implied the execution failed, since it is typically used to burn BTC. Is that what you meant by "fixing the RETURN operand"?

@CosmikDebris Currently it is the case that OP_RETURN immediately marks the transaction invalid, but the the bug under discussion is exactly that its semantics used to  simply be "stop execution" (which only resulted in failure if there was a false on top of the stack at that point). The practice of using OP_RETURN for burning funds came only years after this bug was fixed.


text:
Would it work just fine if "bits" was set to "1cd86a52" instead of "1d00d86a" at the first difficulty adjustment?
The first difficulty adjustment on the network happened at block 32256. The time for block 32255 (one block before the adjustment) is 1262152739 and the time for block 30239 (2016 blocks before the adjustment is 1261130161.
The bits for all blocks up until 32255 is 1d00ffff, which gives the target 00000000FFFF0000000000000000000000000000000000000000000000000000. For reference, I arrived at it by doing the following:
% echo "ibase=16; 00FFFF" |bc
65535
% echo "ibase=16; 1D" |bc
29
% echo "ibase=10; 65535 * 2 ^ (8 * (29 - 3))" | bc
26959535291011309493156476344723991336010898738574164086137773096960
% echo "obase=16; 26959535291011309493156476344723991336010898738574164086137773096960" |bc
FFFF0000000000000000000000000000000000000000000000000000

After arriving at the current target, I multiplied it by 1022578 (time it took to mine the blocks from 30239 to 32255) and then divided by 1209600 (2 weeks in seconds):
% echo "obase=16; 26959535291011309493156476344723991336010898738574164086137773096960 * 1022578 / 1209600" | bc
D86A528BC8BC8BC8BC8BC8BC8BC8BC8BC8BC8BC8BC8BC8BC8BC8BC8B

Now here is where things get confusing for me: from my understanding, the "bits" should be generated by picking up the first three significant bytes from the target, which would be D86A52 and then add the size of the target as the prefix, which would be 1C (28 in base 10), but
when I retrieve the block 32256 using Bitcoin Core, I get 1d00d86a for the bits field.
The difference between the targets would be pretty much irrelevant:
% echo "ibase=10; obase=16; 14182994 * 2 ^ (8 * (28 - 3))" | bc
D86A5200000000000000000000000000000000000000000000000000
% echo "ibase=10; obase=16; 55402 * 2 ^ (8 * (29 - 3))" | bc
D86A0000000000000000000000000000000000000000000000000000

I imagine these types of things happen because there's not a single source of truth for the target value of the network, meaning each node calculates the target independently and as such, these small differences can occur, but because the difference is so small the nodes would just have accepted it if I mined block 32256 using 1cd86a52 as the bits, but I don't know if this reasoning is correct.

The consensus rules control exactly which difficulty a block needs to have (except on testnet3, where in certain circumstances a difficulty=1 block is allowed, in addition to the normally computed value).
In this case, 1cd86a52 is incorrect because it represents a negative number. The "compact format" used consists of 8 exponent bits, 1 sign bits, and 23 mantissa bits. The high bit of the d is the sign bit.
The rules require that the minimal exponent (which represents a power of 256, not of 2) is used for which the mantissa does not overflow.

Thank you for the answer. Okay, so I understand that 1cd86a52 is invalid because it represents a negative number, but then how do I get to 1d00d86a?

I think I understand it by looking at https://bitcoin.stackexchange.com/a/2926/139641. If I understood it correctly, because the first digit of the target I calculated is higher than 0x7f, I should prepend a zero digit and then the compact form would be 1d00d86a

It's the mantissa you end up with by picking the next higher exponent.


text:
Is it correct to say that "each transaction input is signed independently"?
On Chapter 6 - Transactions of Mastering Bitcoin it is said:

Note that each transaction input is signed independently. This is critical, as neither the signatures nor the inputs have to belong to or be applied by the same "owners." In fact, a specific transaction scheme called "CoinJoin" uses this fact to create multi-party transactions for privacy.

and also

Each transaction input and any signature it may contain is completely independent of any other input or signature. Multiple parties can collaborate to construct transactions and sign only one input each.

I understand the fact that all signatures are independent from each other and therefore can be computed separately, but I always had the impression that the signatures are calculated from the transaction hash, and therefore this would make them dependent on the inputs, meaning one would need to know all the inputs included on the transaction in order to generate the correct signature.
If my understanding is correct, I believe a better wording of this statement should be something like:

the signatures needed to spend each UTXO referenced by each transaction input are computed independently

What did I got wrong here?

You are correct, and the text is misleading.
In general, every transaction input signature signs information from all over the transaction, including other inputs. This does not actually involve the transaction hash, but a separate hash which does leave a few things out. It is possible to only include data from your own input and not others (through SIGHASH_ANYONECANPAY specifically) , but the default and most common signing mode does involve signing other inputs.
What I assume the text is aiming to point out is that if multiple parties jointly produce a transaction, and each provides one input, then they can construct a signature for their own input without needing to see or know about the others' keys or signatures, but they still need to know about the other parties' inputs.

Thank you for this answer! Yeah, I got the idea of the text, I imagined it was just omitting the fact that each party still needs to know about the other parties' inputs. Just wanted to make sure I wasn't missing anything


text:
which is the relationship between ouput adresses and their value in a specific transaction?
Some days ago, I write a program to extract output addresses and its value in tx messages of a sample bitcoin pcap.
extracted addresses are all valid and we can find them in block explorers.
after that, just for testing, I send a specific value from one wallet to another wallet and capture all input/output packets during this transfer.
When I test my program with this sample traffic, some addresses and values are generated, one of those addresses was my own address and its value was the same value which I transferred, but some other addresses are generated which are all valid addresses and valid values but I don't know their value.
I guess that these values are UTXOs, but how I can sure about that?
Also, I see same value and same address which i sent in my wallet, in multiple packets with different source and destination IP addresses. for example I send A bitcoin from one wallet to another one, and beside that B bitcoin sent to

Possible duplicate of How does change work in a bitcoin transaction?

When a Bitcoin transaction is created, unspent transaction outputs (UTXOs) are used in the inputs of the transaction. Your wallet will use as many UTXOs (and therefore create as many inputs) as necessary to achieve the value you're trying to send in your transaction.
UTXOs have to be spent completely, so most likely the total value achieved by the sum of the inputs will be greater than the amount you wanted to transfer. There's where change outputs come into play (the additional outputs you're getting). In order to avoid having to send more value than you wanted to the destination address (addr_dst), the difference between the sum of the inputs (vi) and the value to be sent (vo) is sent to a change address (addr_chng), i.e:
vo - fee is sent to addr_dst
vi - vo - fee is sent to addr_chng
That change address is usually owned by you.

Actually I think all vo is sent to addr_dst and fee just reduced from our input(vi), so if i send A bitcoin to my friend with a specific address, he receives all A bitcoin in his wallet.

Well, it depends on the implementation, but sure, it's also possible.

Bitcoin transactions do not spend from addresses, and addresses do not have balances
Every transaction has one or more inputs and one or more outputs
An output is an address and an amount
An input is a reference pointer to the output it is spending - the reference is a unique identifier for a single output: txID and output number (eg. 0, 1, 2, 3)
An output which has not been spent is a coin
To spend a coin, create a transaction with an input which points to the coin
Bitcoin does not have partial spends
A coin can only be spent completely
A coin can only be spent once

I send a specific value from one wallet to another wallet

You spent one or more coins. The value of those coins was greater than the amount you needed to pay. You transaction has 2 outputs (new coins). One of the outputs is the address and amount you were sending. The other output is the difference between your input coins and the amount you were spending - referred to as "change". The change address is your address. The change coin belongs to you, to spend in a future transaction
* This explanation omits the transaction fee, for simplification. The other answer is more complete because it mentions fees


text:
Any man-in-the-middle (MITM) hashrate theft examples
One benefit  of Stratum V1 to Stratum V2 is protection from man-in-the-middle (MITM) hashrate theft.
Are there any documented examples of man-in-the-middle (MITM) hashrate theft in practice ?
Like some paper, document, article ? I am not interested in theoretical, just practical documented examples. Understand it is not easy to detect, especially is only 1-2% hashrate is stole, but in 10+ years, if it is happening in practice, I would expect some documented examples.


text:
Is there any known 80-bit collision attack?
Regarding [bitcoin-dev] Time to worry about 80-bit collision attacks or not?
considering that it is from July 2016, is there any known instance of this attack in practice?
Also what addresses are valid to use if a person wants to avoid 80-bit collision attacks?
From my understanding only P2WSH and P2TR.

is there any known instance of attack in practice ?

No. In cryptography, we try to stop using constructions/protocols long before they're realistic to perform.
And while no 80-bit collision attack is known to have been performed, we do have evidence of a computation that performed a multiple of the amount of work needed for one: the totality of Bitcoin's proof of work as of May 1st 2023 is estimated to be over 294 SHA256 hashes. The hardware produced and used for Bitcoin mining cannot be used for collision attacks on Bitcoin address creation, but it does show that amount of computation is theoretically within reach of humanity.

Also what addresses are valid to use, if person what to avoid 80-bit collision attacks ?

First of all, this attack is one on the creation of multiparty addresses. For example, when you're constructing a multisig address together with someone else, that other party may try to give you a key such that when combined with your key yields an address that they can spend on their own. It is not applicable to addresses which only involve a single party for spending. In fact, for such single-party addresses, 160-bit addresses are overkill even and 128-bit addresses would suffice.
For multi-party addresses, in settings where the collision attack actually applies, P2WSH and P2TR have sufficiently large (in bits) commitments to the keys/script used to make this attack infeasible.

Conclusion, SegWit and Taproot are fine. Do not use other, bur not just because of this issue. Correct ?


text:
Is FIBRE still in use in 2023?
I have read Can someone please explain FIBRE to me like I'm 5 and why is it useful? then https://bitcoinfibre.org/ and https://github.com/bitcoinfibre/bitcoinfibre.
But I still do not understand, is it in use today in 2023 and where, how?
My understanding is that it is not because https://github.com/bitcoinfibre/bitcoinfibre has had no commits since 16/01/2019 and it was set to read-only on 15/01/2020.
If it is not in use, what happend to it?

The public Bitcoin FIBRE network was shut down “a year or two” before May 2022. Some of the reasons were that block propagation became a lot faster after compact block relay (BIP152) was deployed to the network, and the cost and effort of operating FIBRE was mostly borne by one individual.

just few follow up questions. You say "public Bitcoin FIBRE network was shut down". Does that mean that there is/are some private ones ? If there are for what use are they used ?

Since it is an open-source project, it would be possible that e.g. some miners continue to run one. I don’t know whether that is actually the case.


text:
What is considered witness data in SegWit?
What fields in a transaction are considered witness data? I need this to calculate the vsize for fee.
My understanding is these are marker, flag and witness (from 1 and 2).
Or is it just witness, without marker and flag?
Did try to look in source code, but because still new was unsuccessful. Source code references appreciated.

This is defined in BIP141, section "Block size":

Blocks are currently limited to 1,000,000 bytes (1MB) total size. We
change this restriction as follows:
Block weight is defined as Base size * 3 + Total size. (rationale[3])
Base size is the block size in bytes with the original transaction
serialization without any witness-related data, as seen by a
non-upgraded node.
Total size is the block size in bytes with transactions serialized as
described in BIP144, including base data and witness data.

From this it follows that marker, flag and witness are all considered witness data for weight (and therefore fee) calculation, because these are exactly the fields not present in the original serialization.


text:
What is the advantage of running a Ripple masternode?
There is one thing that I cannot stop wondering about:
Why would someone run a Ripple masternode?
Before you mark this as a duplicate, I understand how the transaction fees work in Ripple and also the mechanism of distributed consensus.
The point is - for other currency types, the usual rewards for providing services keeping them alive are transaction fees. If the masternodes don't collect any fees, what is the reason to operate one and bear the associated costs?

There are two types of ripple nodes:
Stock Server-Basically just follows along with the network with a local copy of the ledger.
Validators-Nodes which participate in the consensus.
Neither of these have any rewards but if you run your own stock server you can have a local copy of the ledger and therefore have admin rights, you will not have to trust anyone elses server and you can control your workload.
Likewise if you run your own validator you can have your say in how the Ripple network evolves because changes to the protocols at devoted on by validators.
Sources:
https://ripple.com/build/rippled-setup/
https://www.xrpchat.com/topic/3772-ripple-validator-profits/

The same reason someone would run a bitcoin full node. If you want to transact on the network, you either have to run your own node or use someone else's. If you choose to use someone else's, you are relying on them to give you a proper view of the network and run their server reliably. If you run your own, you are independent. You also help improve the stability and reliability of the network for everyone.
Strictly speaking, you could just run a node that's not a validator. But there is almost no additional effort to running a validator -- it's literally just one extra command you enter once. It's nothing like mining.
If nobody is using the XRP Ledger or deriving any value from it, then it makes no difference who validates or, for that matter, whether anyone validates at all. If there are people using the XRP Ledger and deriving value from it, then they have a stake in ensuring that the network continues to operate reliably and that its rules continue to be the rules that make the network useful to them. This acts as incentive to run a validator, considering that there is no additional cost.


text:
Transaction fees with Dogecoin or Ripple for small amounts
We are a company which sells low priced items online ($0.05 - $0.50). Due to the crypto currency hype, we also would like to accept payments through at least one crypto currency.
I have analyzed a couple of crypto currencies by their average transaction fees, market cap, avg. transaction confirmation, etc.
I found out that Dogecoin and Ripple have currently cheap fees, less than $0.01 cents average.
Question: Can we hire the company that integrates this in our E-Commerce backend or is there anything else important to know beside the exchange fees? Are our transactions too small?
So far I have taken following into account

Transaction fees are not fixed, but as of writing this question the fees are acceptable for my case
Exchange fees (mostly a bit higher since traded through BTC from USD/EUR)
Average fees are less than $0.01, but theoretically they can be higher (if not average)

For most transactions I would assume the fees are <= $0.02. This would be okay for us, but which crypto currency should we choose?

Fully understanding where you come from, IHMO you should choose the crypto currency which most of your potential customers keep in their wallets anyway. Especially when it comes to small amounts (as you say) hardly anyone will be willing to go to an exchange first and trade 0.0005 BTC into a different coin only to pay you.
I would suggest to take a look at the Lightning Network (https://en.wikipedia.org/wiki/Lightning_Network).

You need to understand that all this stuff is pretty beta; nevertheless, it works on the main network, i.e. with real world transactions. One kind of ready to use implementation for a kind of "crypto PayPal" seems to be https://strike.acinq.co/ though there maybe others.


text:
Can you help me with a puzzle transaction?
I am hoping there is someone out there that can help me with probably a simple bit coin scripting question...but maybe there is something more to it. I am trying to fully test a custom script on a regtest bitcoind node network. I have worked through some online tutorials and I can create the custom locking script, transform it into a P2SH, and send coin to it. The issue is when I try to unlock the script. I am trying to write the unlocking transaction by hand since this is a basic puzzle transaction...with no luck. Here is the detailed info:

Bitcoin Version: 16.0
Network: RegTest
Locking Script Hex: 0x93016387 (OP_ADD 99 OP_EQUAL)

Here is the base transaction serialized, please note this does reference a previous transaction that sends 1.0 coin to that wallet's address.
0200000001f5bbd0f99f94380cdff45f3eb689e62437df6e6519554a99ae4042b6499afee0000000006b483045022100e2382837f540c03bde1d3aafea0706c358db61b65d85aef9ea29350ecfb7c8dd02204244642b7166529085238527771ead376e1fa69d20dd23b49762014543d407ea0121036397e0c5c226797a1244f5c0736d7874b756cbc11fe39866c2c380403ca5bcdaffffffff0180c6ef050000000017a9143f58b4f7b14847a9083694b9b3b52a4cea2569ed8700000000
If you decode this, you will see a vout to the p2sh address:
 2My2ApqGcoNXYceZC4d7fipBu4GodkbefHD
The next transaction I generated is:
02000000014192c46838cfe8296c9189b7d7e51a57aad2ee31f931d5b9721908f13f87594b0000000000ffffffff0140b9ec05000000001976a914351ef68a632b634cdb63d0e2b58b7f795ba1233f88ac00000000
Which references the previous transaction but does not have a signature and it decodes properly. Then I try to insert the solution to the locking script, by adding: 3e5101620493016387a9143f58b4f7b14847a9083694b9b3b52a4cea2569ed87 in the correct spot...which it might not be makes this transaction:
02000000014192c46838cfe8296c9189b7d7e51a57aad2ee31f931d5b9721908f13f87594b00000000003e5101620493016387a9143f58b4f7b14847a9083694b9b3b52a4cea2569ed87ffffffff0140b9ec05000000001976a914351ef68a632b634cdb63d0e2b58b7f795ba1233f88ac00000000
And that is where it breaks, I try to decode it...doesn't work...I try to send it...doesn't work...I believe the hex is correct and I believe it is in the right spot...but any ideas or help you can provide will be helpful.

What transaction have you created that fails?

It is not clear, what you have done so far, and how you tried to create your transaction. From a high level perspective I answered a similar question here: https://bitcoin.stackexchange.com/questions/74753/htlc-hash-time-lock-contract-using-bitcoin-qt/74953#74953 - you’d just need to replace „my“ sha256/ripemd160 against your simple expertise. If you can show what you have done, we might be able to provide better help...

Thank you, I will definitely share what I have done shortly. I was walking through the top part and partially uncovered an issue. I want to make sure that I don't send you guys down the wrong path. I appreciate the help, and will follow up shortly with the missing pieces.

So I have resolved the issue, first a huge thanks to pebwindkraft for the direction and link to look at. Based on his breakdown of a transaction I was able to figure out where I was going wrong. I was missing the correct hex to unlock the previous transaction, once that was entered in the correct spot of the serialized transaction, it was broadcasted successfully. The breakdown of the transaction there, plus the bitcoin reference pages were huge helps in figuring this out.
Thanks again,
Dave


text:
How to use BIP39 test vectors?
On the page of BIP39 specs there's test vector array from Trezor link. It looks like this:
["ffffffffffffffffffffffffffffffff",

 "zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo wrong",

 "ac27495480225222079d7be181583751e86f571027b0497b5b5d11218e0a8a13332572917f0f8e5a589620c6f15b11c61dee327651a14c34e18231052e48c069",

 "xprv9s21ZrQH143K2V4oox4M8Zmhi2Fjx5XK4Lf7GKRvPSgydU3mjZuKGCTg7UPiBUD7ydVPvSLtg9hjp7MQTYsW67rZHAXeccqYqrsx8LcXnyd"
],

When I try to use any of these mnemonic phrases I can't get matching xpriv... form any of these samples using Bip39 JS lib.
For example:
const MNEMONIC = "zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo wrong";
const seed = Bip39.mnemonicToSeed(MNEMONIC);
console.log("Seed =", seed.toString("hex"));

const rootNode = Bip32.fromSeed(seed, Bitcoin.networks.bitcoin);
console.log("Bip32 Root key =", rootNode.toBase58());

returns totally different results
Seed = b6a6d8921942dd9806607ebc2750416b289adea669198769f2e15ed926c3aa92bf88ece232317b4ea463e84b0fcd3b53577812ee449ccc448eb45e6f544e25b6
Bip32 Root key = xprv9s21ZrQH143K2PfMvkNViFc1fgumGqBew45JD8SxA59Jc5M66n3diqb92JjvaR61zT9P89Grys12kdtV4EFVo6tMwER7U2hcUmZ9VfMYPLC

How can I get these c5525... and xpriv... and what is it exactly?
UPDATE:
as user3074620 suggested, I tried to use 'TREZOR' password, as it's works!
here's code to play someone is interested.

You must add 'TREZOR' to your second line:
const seed = Bip39.mnemonicToSeed(MNEMONIC, 'TREZOR');
Then it should work.
You can see this in the BIP39 test cases in the BitcoinJS repo:
https://github.com/bitcoinjs/bip39/blob/4fce199e73f7ab68bdf9f7382dc10f7e1adaa499/test/index.js#L13-L33
function testVector (description, wordlist, password, v, i) {
  var ventropy = v[0]
  var vmnemonic = v[1]
  var vseedHex = v[2]

  test('for ' + description + '(' + i + '), ' + ventropy, function (t) {
    t.plan(5)

    t.equal(bip39.mnemonicToEntropy(vmnemonic, wordlist), ventropy, 'mnemonicToEntropy returns ' + ventropy.slice(0, 40) + '...')
    t.equal(bip39.mnemonicToSeedHex(vmnemonic, password), vseedHex, 'mnemonicToSeedHex returns ' + vseedHex.slice(0, 40) + '...')
    t.equal(bip39.entropyToMnemonic(ventropy, wordlist), vmnemonic, 'entropyToMnemonic returns ' + vmnemonic.slice(0, 40) + '...')

    function rng () { return Buffer.from(ventropy, 'hex') }
    t.equal(bip39.generateMnemonic(undefined, rng, wordlist), vmnemonic, 'generateMnemonic returns RNG entropy unmodified')
    t.equal(bip39.validateMnemonic(vmnemonic, wordlist), true, 'validateMnemonic returns true')
  })
}

vectors.english.forEach(function (v, i) { testVector('English', undefined, 'TREZOR', v, i) })
vectors.japanese.forEach(function (v, i) { testVector('Japanese', WORDLISTS.japanese, '㍍ガバヴァぱばぐゞちぢ十人十色', v, i) })
vectors.custom.forEach(function (v, i) { testVector('Custom', WORDLISTS.custom, undefined, v, i) })

Could not resist providing the even more succinct results below that uses simple UNIX and bitcoin-explorer commands:
% echo "ffffffffffffffffffffffffffffffff" | bx mnemonic-new
zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo wrong
% echo "ffffffffffffffffffffffffffffffff" | bx mnemonic-new | bx mnemonic-to-seed -p "TREZOR"
ac27495480225222079d7be181583751e86f571027b0497b5b5d11218e0a8a13332572917f0f8e5a589620c6f15b11c61dee327651a14c34e18231052e48c069
% echo "ffffffffffffffffffffffffffffffff" | bx mnemonic-new | bx mnemonic-to-seed -p "TREZOR" | bx hd-new
xprv9s21ZrQH143K2V4oox4M8Zmhi2Fjx5XK4Lf7GKRvPSgydU3mjZuKGCTg7UPiBUD7ydVPvSLtg9hjp7MQTYsW67rZHAXeccqYqrsx8LcXnyd


text:
Cant understand how share difficulty affects my chances in solo mining with a pool
So obviously I am not solo mining bitcoin but I think the underlying principles are the same so you guys could help me out here.
I am solo mining ergo on a solo pool (herominers solo pool)
What I do not understand exactly is what share difficulty is (not to be mistaken with ergo network difficulty which I understand)
I mean I hash with 2GH/s on ergo I am able to switch between varying share difficulty/vardif(which I have noticed goes up to like 80GH difficulty)  or choose a constant share difficulty.
What I noticed is that if I set that difficulty to 8GH  I get more solo valid shares...
But does this mean that the probability of me finding a block decreases because finding a block needs a higher GH share or something like that ?
I assume that the greater the share difficulty the longer the hash I have to process (so maybe the better changes to solving a correct block? )
Could you explain in detail what share difficulty is and maybe advise me if I should use varying difficulty in my case or a constant (and at which value? )  ?

Shares are only defined as concept in relation between your hasher and your pool. It has no relation on the probability of your pool as a whole to mine a block; that is controlled by the difficulty.

@PieterWuille yes but I am solo mining in a solo pool (sounds bizzar I know but it exists) we dont share the blocks we find in other words. The thing is though that manipulating share difficulty I essentially manipulate how many valid shares I submit but how does this affect my chances of finding a block? E.g at 8GH I submit many more shares compared to at e.g 54GH which means many more chances (like submitting more lottery tickets)  but does that maybe mean that because its a smaller hash (8GH) the chance of "getting it right" or find a block decreases?

It has absolutely nothing to do with your probability of finding a block. It only changes how accurate the pool's idea of your hashrate (and thus affects your share of payout in case it finds something) is.

Does this answer your question? Mining pool hashrate effect on a miner's income


text:
Why can't I participate on bitcointalk.org?
I just created an account and spend a frustrating hour reading help menus and trying to figure out how to post or reply to posts.
None of the buttons -- New Topic, Reply, Quote -- seem to be showing up.  Is there a verification step that I skipped?
I'm logged it.  I get the "hello [user]" message on top.

See this for an answer

You should first make some posts on the Newbies forum. This post explains the restrictions.

Newbie Restrictions You can only post in the Newbie and Local
  sub-forums till you have 5 posts and at least 4 hours on the forum.
  The other two restrictions are you need 1 post to be able to send a PM
  and 10 posts to put a link in your sig.

You beat me to answering this one. Argh low hanging points....


text:
HTLC routing issues in custom LN plugin (c-lightning) on regtest network
I am working on a custom routing plugin for CLN on a regtest network. My goal is to compare its performance against the classical rebalancing plugin provided by the CLN community.
Now I am trying to test it with zero fees routing. However, I am encountering issues with HTLC execution (even in a classical plugin, so I assume I have some problems in a setup), and payments are failing with various errors like "WIRE_FEE_INSUFFICIENT," "WIRE_INCORRECT_OR_UNKNOWN_PAYMENT_DETAILS," and "WIRE_TEMPORARY_CHANNEL_FAILURE." I have already set cltv-delta to 6, fee-base to 0, and htlc-minimum-msat to 0 in my nodes' configuration and ensured that nodes have sufficient liquidity in its channels for routing.
However, the errors persist. I suspect there might be other factors influencing the HTLC routing process or issues with my plugin's logic.
Can someone help me troubleshoot this problem and suggest potential reasons for these errors? Is there anything else I should be considering in my custom plugin to ensure smooth HTLC execution?
Thank you in advance!

it is hard without taking a look at your code, but WIRE_FEE_INSUFFICIENT is a pretty clear error, there is no enough fee to route the payment. WIRE_INCORRECT_OR_UNKNOWN_PAYMENT_DETAILS are you building your payment in the wrong way? WIRE_TEMPORARY_CHANNEL_FAILURE the channel is not responsive or somethings happens. Take a look to your log, they should contain the workflow that you lightning node did before the error

Ok I move my comment to an answer
It is hard without taking a look at your code, but WIRE_FEE_INSUFFICIENT is a pretty clear error, there is no enough fee to route the payment.
WIRE_INCORRECT_OR_UNKNOWN_PAYMENT_DETAILS Are you building your payment in the wrong way? WIRE_TEMPORARY_CHANNEL_FAILURE The channel is not responsive or something happens. Take a look at your log, it should contain the workflow that your lightning node did before the error
In addition, core lightning was not good when there was a single channel between two nodes. Because the pay command will split the implementation in multiple ones.
However, in core lightning v23.08 this was improved as the release notes mention https://github.com/ElementsProject/lightning/releases/tag/v23.08
So I will retry with the new version too :)


text:
Bitcoin core sync stuck with an error "peer=X is stalling block download"
I have installed bitcoin core (23.0) on a virtual machine (Debian GNU/Linux 10, x86_64) and tried to start the testnet initial block download. Unfortunately,a few days ago blockchain sync is stuck on a particular block 4032 and constantly reports following lines
2022-08-03T18:58:26Z Synchronizing blockheaders, height: 2262031 (~99.69%)
2022-08-03T18:58:26Z Peer=6 is stalling block download, disconnecting
2022-08-03T18:58:26Z Synchronizing blockheaders, height: 2264031 (~99.69%)
2022-08-03T18:58:32Z New outbound peer connected: version: 70015, blocks=2314713, peer=16 (outbound-full-relay)

This problem is not present on mainnet and my bitcoin.conf currently looks simply this way
testnet=1
prune=550

What I've already tried:

Run bitcoind with -maxconnections=1
Run bitcoind with -reindex
Tried different configurations of bitcoin.conf
Delete .bitcoin data directory and restart bitcoind
invalidate block

all steps were unsuccessful :'(

I am ready to provide further information and would appreciate if someone could help with this issue! Also, I am quite a newbie, so I could be missing something obvious.
With listen=0 and after removing datadir testnet3:
2022-08-05T17:33:57Z   - Connect postprocess: 0.88ms [3.43s (0.85ms/blk)]
2022-08-05T17:33:57Z - Connect block: 1.65ms [6.09s (1.51ms/blk)]
2022-08-05T17:33:57Z Enqueuing BlockConnected: block hash=000000001af3b22a7598b10574deb6b3e2d596f36d62b0a49cb89a1f99ab81eb block height=4032
2022-08-05T17:33:57Z Enqueuing UpdatedBlockTip: new block hash=000000001af3b22a7598b10574deb6b3e2d596f36d62b0a49cb89a1f99ab81eb fork block hash=000000002e9ccffc999166ccf8d72129e1b2e9c754f6c90ad2f77cab0d9fb4c7 (in IBD=true)
2022-08-05T17:33:57Z Requesting block 0000000001b8c862bc9d5bcb0b15695bef9eafaf31d39678d08f8cbbba6f041b (4096) peer=0
2022-08-05T17:33:57Z sending getdata (37 bytes) peer=0
2022-08-05T17:33:57Z UpdatedBlockTip: new block hash=000000004b072849e63b49f209cf966847569e9ae5aa0a5e83e7847c143168b0 fork block hash=000000009577b19248f3c4bebddb6b6ca2105e1f700b63a045057f74fee18687 (in IBD=true)
2022-08-05T17:33:57Z BlockConnected: block hash=000000002e9ccffc999166ccf8d72129e1b2e9c754f6c90ad2f77cab0d9fb4c7 block height=4031
2022-08-05T17:33:57Z UpdatedBlockTip: new block hash=000000002e9ccffc999166ccf8d72129e1b2e9c754f6c90ad2f77cab0d9fb4c7 fork block hash=000000004b072849e63b49f209cf966847569e9ae5aa0a5e83e7847c143168b0 (in IBD=true)
2022-08-05T17:33:57Z BlockConnected: block hash=000000001af3b22a7598b10574deb6b3e2d596f36d62b0a49cb89a1f99ab81eb block height=4032
2022-08-05T17:33:57Z UpdatedBlockTip: new block hash=000000001af3b22a7598b10574deb6b3e2d596f36d62b0a49cb89a1f99ab81eb fork block hash=000000002e9ccffc999166ccf8d72129e1b2e9c754f6c90ad2f77cab0d9fb4c7 (in IBD=true)
2022-08-05T17:33:57Z received: headers (162003 bytes) peer=2
2022-08-05T17:33:57Z more getheaders (2061999) to end to peer=2 (startheight:2315040)
2022-08-05T17:33:57Z sending getheaders (1061 bytes) peer=2
2022-08-05T17:33:57Z received: headers (162003 bytes) peer=3
2022-08-05T17:33:57Z more getheaders (2057999) to end to peer=3 (startheight:2315040)
2022-08-05T17:33:57Z sending getheaders (1061 bytes) peer=3
2022-08-05T17:33:57Z received: headers (162003 bytes) peer=8
2022-08-05T17:33:57Z more getheaders (1975999) to end to peer=8 (startheight:2315040)
2022-08-05T17:33:57Z sending getheaders (1061 bytes) peer=8
2022-08-05T17:33:57Z received: headers (162003 bytes) peer=1
2022-08-05T17:33:57Z more getheaders (1979999) to end to peer=1 (startheight:2315040)
2022-08-05T17:33:57Z sending getheaders (1061 bytes) peer=1
2022-08-05T17:33:57Z received: headers (162003 bytes) peer=6
2022-08-05T17:33:57Z more getheaders (1693999) to end to peer=6 (startheight:2315040)
2022-08-05T17:33:57Z sending getheaders (1061 bytes) peer=6
2022-08-05T17:33:57Z received: headers (162003 bytes) peer=4
2022-08-05T17:33:57Z more getheaders (1837999) to end to peer=4 (startheight:2315040)
2022-08-05T17:33:57Z sending getheaders (1061 bytes) peer=4
2022-08-05T17:33:57Z received: headers (162003 bytes) peer=1
2022-08-05T17:33:57Z more getheaders (1981999) to end to peer=1 (startheight:2315040)
2022-08-05T17:33:57Z sending getheaders (1061 bytes) peer=1
2022-08-05T17:33:57Z received: headers (162003 bytes) peer=4
2022-08-05T17:33:57Z more getheaders (1839999) to end to peer=4 (startheight:2315040)
2022-08-05T17:33:57Z sending getheaders (1061 bytes) peer=4
2022-08-05T17:33:57Z received: headers (162003 bytes) peer=2
2022-08-05T17:33:57Z more getheaders (2063999) to end to peer=2 (startheight:2315040)
2022-08-05T17:33:57Z sending getheaders (1061 bytes) peer=2
2022-08-05T17:33:57Z received: headers (162003 bytes) peer=3
2022-08-05T17:33:57Z more getheaders (2059999) to end to peer=3 (startheight:2315040)
2022-08-05T17:33:57Z sending getheaders (1061 bytes) peer=3
2022-08-05T17:33:57Z received: headers (162003 bytes) peer=8
2022-08-05T17:33:57Z more getheaders (1977999) to end to peer=8 (startheight:2315040)
2022-08-05T17:33:57Z sending getheaders (1061 bytes) peer=8
2022-08-05T17:33:57Z received: headers (162003 bytes) peer=4
2022-08-05T17:33:57Z more getheaders (1841999) to end to peer=4 (startheight:2315040)
2022-08-05T17:33:57Z sending getheaders (1061 bytes) peer=4
2022-08-05T17:33:57Z received: headers (162003 bytes) peer=1
2022-08-05T17:33:57Z more getheaders (1983999) to end to peer=1 (startheight:2315040)
2022-08-05T17:33:57Z sending getheaders (1061 bytes) peer=1
2022-08-05T17:33:57Z received: headers (162003 bytes) peer=8
2022-08-05T17:33:57Z more getheaders (1979999) to end to peer=8 (startheight:2315040)
2022-08-05T17:33:57Z sending getheaders (1061 bytes) peer=8
2022-08-05T17:33:57Z received: headers (162003 bytes) peer=4
2022-08-05T17:33:57Z more getheaders (1843999) to end to peer=4 (startheight:2315040)
2022-08-05T17:33:57Z sending getheaders (1061 bytes) peer=4
2022-08-05T17:33:57Z received: headers (162003 bytes) peer=3
2022-08-05T17:33:57Z more getheaders (2061999) to end to peer=3 (startheight:2315040)
2022-08-05T17:33:57Z sending getheaders (1061 bytes) peer=3
2022-08-05T17:33:57Z received: headers (162003 bytes) peer=2
2022-08-05T17:33:57Z more getheaders (2065999) to end to peer=2 (startheight:2315040)
2022-08-05T17:33:57Z sending getheaders (1061 bytes) peer=2
2022-08-05T17:33:57Z received: headers (162003 bytes) peer=1
2022-08-05T17:33:57Z more getheaders (1985999) to end to peer=1 (startheight:2315040)
2022-08-05T17:33:57Z sending getheaders (1061 bytes) peer=1
2022-08-05T17:33:57Z received: headers (162003 bytes) peer=4
2022-08-05T17:33:57Z more getheaders (1845999) to end to peer=4 (startheight:2315040)
2022-08-05T17:33:57Z sending getheaders (1061 bytes) peer=4
2022-08-05T17:33:57Z received: headers (162003 bytes) peer=6
2022-08-05T17:33:57Z more getheaders (1695999) to end to peer=6 (startheight:2315040)
2022-08-05T17:33:57Z sending getheaders (1061 bytes) peer=6
2022-08-05T17:33:57Z received: headers (162003 bytes) peer=8
2022-08-05T17:33:57Z more getheaders (1981999) to end to peer=8 (startheight:2315040)
2022-08-05T17:33:57Z sending getheaders (1061 bytes) peer=8
2022-08-05T17:33:57Z received: headers (162003 bytes) peer=1
2022-08-05T17:33:57Z more getheaders (1987999) to end to peer=1 (startheight:2315040)
2022-08-05T17:33:57Z sending getheaders (1061 bytes) peer=1
2022-08-05T17:33:57Z received: headers (162003 bytes) peer=4
2022-08-05T17:33:57Z more getheaders (1847999) to end to peer=4 (startheight:2315040)

... and ...
2022-08-05T17:51:25Z Added 172.76.167.210:18333 mapped to AS0 to new[118][47]
2022-08-05T17:51:25Z Added 44.234.48.207:3000 mapped to AS0 to new[377][51]
2022-08-05T17:51:25Z Added 95.217.106.33:16666 mapped to AS0 to new[764][36]
2022-08-05T17:51:25Z Added 102.91.5.163:18333 mapped to AS0 to new[53][32]
2022-08-05T17:51:25Z Added 18.237.199.30:18333 mapped to AS0 to new[893][12]
2022-08-05T17:51:25Z Added 45.90.211.106:18333 mapped to AS0 to new[632][36]
2022-08-05T17:51:25Z Added 89.145.164.141:18333 mapped to AS0 to new[380][12]
2022-08-05T17:51:25Z Added 181.90.78.167:18333 mapped to AS0 to new[202][8]
2022-08-05T17:51:25Z Added 35.176.160.196:18333 mapped to AS0 to new[410][35]
2022-08-05T17:51:25Z Added 147.182.228.171:18333 mapped to AS0 to new[964][4]
2022-08-05T17:51:25Z Added 195.206.2.235:18333 mapped to AS0 to new[242][42]
2022-08-05T17:51:25Z Added [2001:861:3dc3:2670:b8d9:59c5:e41a:4e7d]:18333 mapped to AS0 to new[1000][54]
2022-08-05T17:51:25Z Added 185.220.101.156:18333 mapped to AS0 to new[729][5]
2022-08-05T17:51:25Z Added 3.212.1.199:18333 mapped to AS0 to new[959][51]
2022-08-05T17:51:25Z Added 94.231.253.18:18333 mapped to AS0 to new[722][26]
2022-08-05T17:51:25Z Added 192.145.119.170:18333 mapped to AS0 to new[775][17]
2022-08-05T17:51:25Z Added 46.158.72.210:18333 mapped to AS0 to new[190][58]
2022-08-05T17:51:25Z Added 163.172.140.222:18333 mapped to AS0 to new[689][17]
2022-08-05T17:51:25Z Removed 5.14.213.154:18445 from new[242][57]
2022-08-05T17:51:25Z Added 46.243.25.106:18333 mapped to AS0 to new[242][57]
2022-08-05T17:51:25Z Added 196.178.74.11:18333 mapped to AS0 to new[309][18]
2022-08-05T17:51:25Z Added 91.225.142.178:18333 mapped to AS0 to new[722][33]
2022-08-05T17:51:25Z Added 13.215.108.60:18333 mapped to AS0 to new[53][15]
2022-08-05T17:51:25Z Added 54.64.59.249:18333 mapped to AS0 to new[53][48]
2022-08-05T17:51:25Z Added 174.127.250.4:18333 mapped to AS0 to new[764][13]
2022-08-05T17:51:25Z Added 154.204.24.234:18333 mapped to AS0 to new[116][33]
2022-08-05T17:51:25Z Added [2a01:5ec0:1802:3354:799e:13dd:45a:b738]:18333 mapped to AS0 to new[71][21]
2022-08-05T17:51:25Z Added 45.32.110.61:18333 mapped to AS0 to new[729][51]
2022-08-05T17:51:25Z Removed 192.46.234.64:18333 from new[932][36]
2022-08-05T17:51:25Z Added 92.115.99.159:18333 mapped to AS0 to new[932][36]
2022-08-05T17:51:25Z Removed [2404:7a80:30e0:3800:70e6:98b5:da5:10fa]:18333 from new[775][14]
2022-08-05T17:51:25Z Added 101.224.16.240:18333 mapped to AS0 to new[775][14]
2022-08-05T17:51:25Z Removed 187.109.87.182:18333 from new[544][30]
2022-08-05T17:51:25Z Added 198.8.92.88:18333 mapped to AS0 to new[544][30]
2022-08-05T17:51:25Z Added 189.147.148.39:18333 mapped to AS0 to new[323][54]
2022-08-05T17:51:25Z Added 176.232.63.113:18333 mapped to AS0 to new[616][57]
2022-08-05T17:51:25Z Added 172.105.84.158:18333 mapped to AS0 to new[334][57]
2022-08-05T17:51:25Z Added [2a01:4f8:151:30c9::2]:18333 mapped to AS0 to new[435][38]
2022-08-05T17:51:25Z Added 103.55.11.35:18333 mapped to AS0 to new[53][39]
2022-08-05T17:51:25Z Added 54.215.35.252:18333 mapped to AS0 to new[309][41]
2022-08-05T17:51:25Z Added 3.73.44.141:18333 mapped to AS0 to new[306][43]
2022-08-05T17:51:25Z Added [2a02:a210:2041:34f0:31f6:deaa:7d6b:d08]:18333 mapped to AS0 to new[616][46]
2022-08-05T17:51:25Z Added 131.94.186.110:18333 mapped to AS0 to new[118][13]
2022-08-05T17:51:25Z Added 80.49.50.192:18333 mapped to AS0 to new[245][35]
2022-08-05T17:51:25Z Removed 142.147.89.228:18333 from new[377][39]
2022-08-05T17:51:25Z Added 34.105.113.80:18333 mapped to AS0 to new[377][39]
2022-08-05T17:51:25Z Added 195.154.200.157:8333 mapped to AS0 to new[435][39]
2022-08-05T17:51:25Z Added 18.237.26.158:18333 mapped to AS0 to new[893][56]
2022-08-05T17:51:25Z Added 88.118.15.170:18333 mapped to AS0 to new[964][49]
2022-08-05T17:51:25Z Added [2a01:4f8:10b:a85::2]:18333 mapped to AS0 to new[435][54]
2022-08-05T17:51:25Z Added 41.147.0.51:18333 mapped to AS0 to new[53][53]
2022-08-05T17:51:25Z Added 3.121.218.237:18333 mapped to AS0 to new[190][15]
2022-08-05T17:51:25Z Added 161.97.146.5:18333 mapped to AS0 to new[466][59]
2022-08-05T17:51:25Z Added 180.123.22.114:18333 mapped to AS0 to new[995][11]
2022-08-05T17:51:25Z Added 93.173.235.84:18333 mapped to AS0 to new[662][34]
2022-08-05T17:51:25Z Added 176.63.24.73:18333 mapped to AS0 to new[380][44]
2022-08-05T17:51:25Z Added 45.20.115.208:18333 mapped to AS0 to new[765][29]
2022-08-05T17:51:25Z Added 31.61.238.243:18333 mapped to AS0 to new[334][44]
2022-08-05T17:51:25Z Added 34.139.188.226:18333 mapped to AS0 to new[1002][40]
2022-08-05T17:51:25Z Added 54.169.102.36:18333 mapped to AS0 to new[153][1]
2022-08-05T17:51:25Z Added 45.33.48.32:18333 mapped to AS0 to new[806][57]
2022-08-05T17:51:25Z Added 178.239.173.192:18333 mapped to AS0 to new[410][24]
2022-08-05T17:51:25Z Removed 194.105.137.123:18333 from new[997][40]
2022-08-05T17:51:25Z Added 63.248.86.232:18333 mapped to AS0 to new[997][40]
2022-08-05T17:51:25Z Removed 197.210.71.117:18333 from new[194][50]
2022-08-05T17:51:25Z Added 85.221.228.98:18333 mapped to AS0 to new[194][50]
2022-08-05T17:51:25Z Removed 95.102.215.12:8333 from new[205][45]
2022-08-05T17:51:25Z Added [2001:0:9d38:6abd:242e:1556:b98f:a440]:18333 mapped to AS0 to new[205][45]
2022-08-05T17:51:25Z Added 52.56.40.174:18333 mapped to AS0 to new[921][38]
2022-08-05T17:51:25Z Added 118.78.39.4:18333 mapped to AS0 to new[729][61]
2022-08-05T17:51:25Z Added [2405:6583:9300:6f00:411f:4bc1:a3ba:c44e]:18333 mapped to AS0 to new[53][41]
2022-08-05T17:51:25Z Added 177.39.33.46:18333 mapped to AS0 to new[242][46]
2022-08-05T17:51:25Z Added 47.75.136.114:18333 mapped to AS0 to new[197][42]
2022-08-05T17:51:25Z Added 18.208.195.121:18333 mapped to AS0 to new[944][58]
2022-08-05T17:51:25Z Added 3.235.199.140:18333 mapped to AS0 to new[1000][44]
2022-08-05T17:51:25Z Added 45.76.27.11:18333 mapped to AS0 to new[334][54]
2022-08-05T17:51:25Z Added 59.40.141.29:18333 mapped to AS0 to new[209][53]
2022-08-05T17:51:25Z Added [2603:7080:ec40:1b00::17dd]:18333 mapped to AS0 to new[886][32]
2022-08-05T17:51:25Z Added 62.23.155.50:18333 mapped to AS0 to new[678][28]
2022-08-05T17:51:25Z Added 203.189.252.172:20020 mapped to AS0 to new[1002][0]
2022-08-05T17:51:25Z Added 52.3.226.5:30000 mapped to AS0 to new[190][12]
2022-08-05T17:51:25Z Added 219.152.31.241:18333 mapped to AS0 to new[944][9]
2022-08-05T17:51:25Z Removed [2a0e:1d40:805:3700:85d9:ab91:63f9:61ba]:18333 from new[306][38]
2022-08-05T17:51:25Z Added [2601:647:5680:5440:dbb:af47:d5c3:c913]:18333 mapped to AS0 to new[306][38]
2022-08-05T17:51:25Z Added 3.20.168.21:18333 mapped to AS0 to new[118][39]
2022-08-05T17:51:25Z Removed 54.198.73.12:18333 from new[765][53]
2022-08-05T17:51:25Z Added [2a01:4ff:f0:4456::1]:18333 mapped to AS0 to new[765][53]
2022-08-05T17:51:25Z Added 20.76.160.107:39388 mapped to AS0 to new[194][26]
2022-08-05T17:51:25Z Added 114.255.110.130:39388 mapped to AS0 to new[678][58]
2022-08-05T17:51:25Z Added 50.2.13.165:18333 mapped to AS0 to new[202][57]
2022-08-05T17:51:25Z Added 181.45.24.195:18333 mapped to AS0 to new[194][12]
2022-08-05T17:51:25Z Added 81.148.223.188:18333 mapped to AS0 to new[431][8]
2022-08-05T17:51:25Z Added 31.22.203.42:18333 mapped to AS0 to new[921][59]
2022-08-05T17:51:25Z Added 185.220.101.182:18333 mapped to AS0 to new[729][48]
2022-08-05T17:51:25Z Added 172.76.174.137:18333 mapped to AS0 to new[118][35]
2022-08-05T17:51:25Z Removed 161.97.88.150:18333 from new[466][26]
2022-08-05T17:51:25Z Added 142.132.252.156:18333 mapped to AS0 to new[466][26]
2022-08-05T17:51:25Z Added 40.91.196.213:18333 mapped to AS0 to new[205][54]
2022-08-05T17:51:25Z Added [2601:646:9c00:a9d0:b5d0:28f1:ec9e:c7c9]:18333 mapped to AS0 to new[194][57]
2022-08-05T17:51:25Z Added 207.244.177.107:18333 mapped to AS0 to new[334][14]
2022-08-05T17:51:25Z Added 494 addresses (of 881) from 3.18.26.129: 30 tried, 8326 new
2022-08-05T17:51:25Z received: pong (8 bytes) peer=39
2022-08-05T17:51:26Z Selected 34.207.108.183:18333 from tried
2022-08-05T17:51:26Z Selected 91.214.220.136:18333 from new
2022-08-05T17:51:26Z Selected 34.207.108.183:18333 from tried
2022-08-05T17:51:27Z Selected [2603:6080:6a03:c300:c104:8a1d:5a25:e7c6]:18333 from new
2022-08-05T17:51:27Z trying connection [2603:6080:6a03:c300:c104:8a1d:5a25:e7c6]:18333 lastseen=331.5hrs

... and ...
2022-08-05T18:13:09Z connection attempt to 217.138.199.93:18333 timed out
2022-08-05T18:13:10Z Selected 35.78.193.194:18333 from new
2022-08-05T18:13:10Z trying connection 35.78.193.194:18333 lastseen=286.2hrs
2022-08-05T18:13:10Z sending ping (8 bytes) peer=114
2022-08-05T18:13:15Z connection attempt to 35.78.193.194:18333 timed out
2022-08-05T18:13:15Z Selected 51.77.119.85:18333 from tried
2022-08-05T18:13:15Z Selected 172.81.180.110:18333 from new
2022-08-05T18:13:15Z trying connection 172.81.180.110:18333 lastseen=10.7hrs
2022-08-05T18:13:20Z connection attempt to 172.81.180.110:18333 timed out
2022-08-05T18:13:21Z Selected 80.133.96.162:18333 from new
2022-08-05T18:13:21Z trying connection 80.133.96.162:18333 lastseen=644.4hrs
2022-08-05T18:13:22Z sending ping (8 bytes) peer=115
2022-08-05T18:13:23Z sending ping (8 bytes) peer=116
2022-08-05T18:13:26Z connection attempt to 80.133.96.162:18333 timed out
2022-08-05T18:13:26Z Selected 52.0.54.100:18333 from tried
2022-08-05T18:13:26Z trying connection 52.0.54.100:18333 lastseen=0.5hrs
2022-08-05T18:13:26Z Added connection peer=128
2022-08-05T18:13:26Z sending version (102 bytes) peer=128
2022-08-05T18:13:26Z send version message: version 70016, blocks=4032, txrelay=1, peer=128
2022-08-05T18:13:27Z received: version (102 bytes) peer=128
2022-08-05T18:13:27Z sending wtxidrelay (0 bytes) peer=128
2022-08-05T18:13:27Z sending sendaddrv2 (0 bytes) peer=128
2022-08-05T18:13:27Z sending verack (0 bytes) peer=128
2022-08-05T18:13:27Z sending getaddr (0 bytes) peer=128
2022-08-05T18:13:27Z receive version message: /Satoshi:0.21.0/: version 70016, blocks=2315045, us=130.149.221.147:59312, txrelay=1, peer=128
2022-08-05T18:13:27Z received: wtxidrelay (0 bytes) peer=128
2022-08-05T18:13:27Z received: sendaddrv2 (0 bytes) peer=128
2022-08-05T18:13:27Z received: verack (0 bytes) peer=128
2022-08-05T18:13:27Z New outbound peer connected: version: 70016, blocks=2315045, peer=128 (outbound-full-relay)
2022-08-05T18:13:27Z sending sendheaders (0 bytes) peer=128
2022-08-05T18:13:27Z sending sendcmpct (9 bytes) peer=128
2022-08-05T18:13:27Z sending sendcmpct (9 bytes) peer=128
2022-08-05T18:13:27Z sending ping (8 bytes) peer=128
2022-08-05T18:13:27Z initial getheaders (2315044) to peer=128 (startheight:2315045)
2022-08-05T18:13:27Z sending getheaders (1093 bytes) peer=128
2022-08-05T18:13:27Z sending feefilter (8 bytes) peer=128
2022-08-05T18:13:27Z received: sendheaders (0 bytes) peer=128
2022-08-05T18:13:27Z received: sendcmpct (9 bytes) peer=128
2022-08-05T18:13:27Z received: sendcmpct (9 bytes) peer=128
2022-08-05T18:13:27Z received: ping (8 bytes) peer=128
2022-08-05T18:13:27Z sending pong (8 bytes) peer=128
2022-08-05T18:13:27Z received: addrv2 (16 bytes) peer=128
2022-08-05T18:13:27Z Received addr: 1 addresses (1 processed, 0 rate-limited) from peer=128
2022-08-05T18:13:27Z received: getheaders (1093 bytes) peer=128
2022-08-05T18:13:27Z Ignoring getheaders from peer=128 because node is in initial block download
2022-08-05T18:13:27Z received: feefilter (8 bytes) peer=128
2022-08-05T18:13:27Z received: feefilter of 0.00001000 BTC/kvB from peer=128
2022-08-05T18:13:27Z received: pong (8 bytes) peer=128
2022-08-05T18:13:27Z received: headers (82 bytes) peer=128
2022-08-05T18:13:27Z Protecting outbound peer=128 from eviction
2022-08-05T18:13:27Z Stall started peer=127
2022-08-05T18:13:27Z Selected 94.23.33.130:18333 from tried
2022-08-05T18:13:27Z trying connection 94.23.33.130:18333 lastseen=0.2hrs
2022-08-05T18:13:27Z Added connection peer=129
2022-08-05T18:13:27Z sending version (102 bytes) peer=129
2022-08-05T18:13:27Z send version message: version 70016, blocks=4032, txrelay=0, peer=129
2022-08-05T18:13:27Z received: version (103 bytes) peer=129
2022-08-05T18:13:27Z sending wtxidrelay (0 bytes) peer=129
2022-08-05T18:13:27Z sending sendaddrv2 (0 bytes) peer=129
2022-08-05T18:13:27Z sending verack (0 bytes) peer=129
2022-08-05T18:13:27Z receive version message: /Satoshi:21.99.0/: version 70016, blocks=2315045, us=130.149.221.147:46822, txrelay=1, peer=129
2022-08-05T18:13:27Z received: wtxidrelay (0 bytes) peer=129
2022-08-05T18:13:27Z received: sendaddrv2 (0 bytes) peer=129
2022-08-05T18:13:27Z received: verack (0 bytes) peer=129
2022-08-05T18:13:27Z New outbound peer connected: version: 70016, blocks=2315045, peer=129 (block-relay-only)
2022-08-05T18:13:27Z sending sendheaders (0 bytes) peer=129
2022-08-05T18:13:27Z sending sendcmpct (9 bytes) peer=129
2022-08-05T18:13:27Z sending sendcmpct (9 bytes) peer=129
2022-08-05T18:13:27Z sending ping (8 bytes) peer=129
2022-08-05T18:13:27Z initial getheaders (2315044) to peer=129 (startheight:2315045)
2022-08-05T18:13:27Z sending getheaders (1093 bytes) peer=129
2022-08-05T18:13:27Z received: sendheaders (0 bytes) peer=129
2022-08-05T18:13:27Z received: sendcmpct (9 bytes) peer=129
2022-08-05T18:13:27Z received: sendcmpct (9 bytes) peer=129
2022-08-05T18:13:27Z received: ping (8 bytes) peer=129
2022-08-05T18:13:27Z sending pong (8 bytes) peer=129
2022-08-05T18:13:27Z received: addrv2 (16 bytes) peer=129
2022-08-05T18:13:27Z ignoring addrv2 message from block-relay-only peer=129
2022-08-05T18:13:27Z received: getheaders (1093 bytes) peer=129
2022-08-05T18:13:27Z Ignoring getheaders from peer=129 because node is in initial block download
2022-08-05T18:13:27Z received: feefilter (8 bytes) peer=129
2022-08-05T18:13:27Z received: feefilter of 0.00001000 BTC/kvB from peer=129
2022-08-05T18:13:27Z received: pong (8 bytes) peer=129
2022-08-05T18:13:27Z received: headers (82 bytes) peer=129
2022-08-05T18:13:28Z Selected 201.213.139.40:18333 from new
2022-08-05T18:13:28Z Making feeler connection to 201.213.139.40:18333
2022-08-05T18:13:28Z trying connection 201.213.139.40:18333 lastseen=39.8hrs
2022-08-05T18:13:29Z Peer=127 is stalling block download, disconnecting
2022-08-05T18:13:29Z disconnecting peer=127
2022-08-05T18:13:29Z Cleared nodestate for peer=127
2022-08-05T18:13:29Z Requesting block 00000000db623a1752143f2f805c4527573570d9b4ca0a3cfe371e703ac429aa (4033) peer=129
2022-08-05T18:13:29Z Requesting block 0000000073d8b2f92be7a94ee567f07fb0bead01364a68afe11e1fe2a03f9448 (4036) peer=129
2022-08-05T18:13:29Z Requesting block 00000000ff0106750519cd7b545f639e9bae958183792c5f34e95e1a490630d1 (4041) peer=129
2022-08-05T18:13:29Z Requesting block 00000000cee0b413b827d1f0ced850d8b69cf591b8304b49e7ca263e3aea0f38 (4045) peer=129
2022-08-05T18:13:29Z Requesting block 0000000037352c5bef9447da95603add1bb14bac64619894a50d78ff7c394cd1 (4047) peer=129
2022-08-05T18:13:29Z Requesting block 00000000581a124da37e9c16ea43e0725962a31f68430be749e21bd1902101b8 (4053) peer=129
2022-08-05T18:13:29Z Requesting block 00000000691dadb3705b7b8a0902bcf893292b454b809e12924a71e20c341a41 (4057) peer=129
2022-08-05T18:13:29Z Requesting block 000000004e7c05621db9cdcf62d362efb914721c4094dc8b8c6677db56c3d489 (4064) peer=129
2022-08-05T18:13:29Z Requesting block 00000000988a45071d7cf0a9aa61ba1ede22df9dce2ffe5e79607f4d7e936a40 (4065) peer=129
2022-08-05T18:13:29Z Requesting block 00000000678ffa59dd961b372173196f0713eb36f7ec8a3324d78cfcb19c7c7a (4070) peer=129
2022-08-05T18:13:29Z Requesting block 0000000030beedda39a27dd825f0ee83ba06f537be9a3dd621ba0baa2fc91b82 (4073) peer=129
2022-08-05T18:13:29Z Requesting block 000000007a78cdc2bb51b2058bb20f1921250abbbf564d16511b805428d56054 (4079) peer=129
2022-08-05T18:13:29Z Requesting block 0000000067570ed3aed985b70372b3e7be7dfb265d348b803977a40774ca057c (4080) peer=129
2022-08-05T18:13:29Z Requesting block 000000006464a1f36a0a4076a193913b5f24b9bb435925f111c23c66c975615d (4086) peer=129
2022-08-05T18:13:29Z Requesting block 00000000ce8084c04d41ea5b1650424414ebb6a2e9544be32d79923bab7a5eef (4087) peer=129
2022-08-05T18:13:29Z Requesting block 000000005225db12742b41070a0239c708cae1cfee79caa65560cb8a4ee2d090 (4091) peer=129
2022-08-05T18:13:29Z sending getdata (577 bytes) peer=129
2022-08-05T18:13:29Z Stall started peer=129
2022-08-05T18:13:31Z Peer=129 is stalling block download, disconnecting
2022-08-05T18:13:31Z disconnecting peer=129
2022-08-05T18:13:31Z Cleared nodestate for peer=129
2022-08-05T18:13:31Z Requesting block 00000000db623a1752143f2f805c4527573570d9b4ca0a3cfe371e703ac429aa (4033) peer=128
2022-08-05T18:13:31Z Requesting block 0000000073d8b2f92be7a94ee567f07fb0bead01364a68afe11e1fe2a03f9448 (4036) peer=128
2022-08-05T18:13:31Z Requesting block 00000000ff0106750519cd7b545f639e9bae958183792c5f34e95e1a490630d1 (4041) peer=128
2022-08-05T18:13:31Z Requesting block 00000000cee0b413b827d1f0ced850d8b69cf591b8304b49e7ca263e3aea0f38 (4045) peer=128
2022-08-05T18:13:31Z Requesting block 0000000037352c5bef9447da95603add1bb14bac64619894a50d78ff7c394cd1 (4047) peer=128
2022-08-05T18:13:31Z Requesting block 00000000581a124da37e9c16ea43e0725962a31f68430be749e21bd1902101b8 (4053) peer=128
2022-08-05T18:13:31Z Requesting block 00000000691dadb3705b7b8a0902bcf893292b454b809e12924a71e20c341a41 (4057) peer=128
2022-08-05T18:13:31Z Requesting block 000000004e7c05621db9cdcf62d362efb914721c4094dc8b8c6677db56c3d489 (4064) peer=128
2022-08-05T18:13:31Z Requesting block 00000000988a45071d7cf0a9aa61ba1ede22df9dce2ffe5e79607f4d7e936a40 (4065) peer=128
2022-08-05T18:13:31Z Requesting block 00000000678ffa59dd961b372173196f0713eb36f7ec8a3324d78cfcb19c7c7a (4070) peer=128
2022-08-05T18:13:31Z Requesting block 0000000030beedda39a27dd825f0ee83ba06f537be9a3dd621ba0baa2fc91b82 (4073) peer=128
2022-08-05T18:13:31Z Requesting block 000000007a78cdc2bb51b2058bb20f1921250abbbf564d16511b805428d56054 (4079) peer=128
2022-08-05T18:13:31Z Requesting block 0000000067570ed3aed985b70372b3e7be7dfb265d348b803977a40774ca057c (4080) peer=128
2022-08-05T18:13:31Z Requesting block 000000006464a1f36a0a4076a193913b5f24b9bb435925f111c23c66c975615d (4086) peer=128
2022-08-05T18:13:31Z Requesting block 00000000ce8084c04d41ea5b1650424414ebb6a2e9544be32d79923bab7a5eef (4087) peer=128
2022-08-05T18:13:31Z Requesting block 000000005225db12742b41070a0239c708cae1cfee79caa65560cb8a4ee2d090 (4091) peer=128
2022-08-05T18:13:31Z sending getdata (577 bytes) peer=128
2022-08-05T18:13:33Z connection attempt to 201.213.139.40:18333 timed out
2022-08-05T18:13:34Z Selected 107.189.31.134:18333 from new
2022-08-05T18:13:34Z trying connection 107.189.31.134:18333 lastseen=114.7hrs
2022-08-05T18:13:35Z received: headers (82 bytes) peer=122
2022-08-05T18:13:35Z Stall started peer=128

I appreciate everyone's helpful comments, but I have had no luck solving this problem in a "clean" way. Since I tried to run the nodes on the university's virtual machines, I suspect the problem could be related to networking (firewall or router settings). Also important to note is that on the mainnet the initial block download went smoothly (explanation is possible here).
So my hotfix was to run the test nodes via Tor.  With this set-up, the initial block download continued and succeeded.

I can't reproduce this, I can sync fine on testnet beyond this point.
Did you delete the correct datadir (.bitcoin/testnet3) in step 4? And did it then start syncing headers from 0% (you can check debug.log in the datadir folder) and get stuck at the same point again?
What does bitcoin-cli -testnet getchaintips say when you are stuck?

Yes, I removed .bitcoin/testnet3, and then the sync stuck on the exact same block again. I even reimaged the virtual machine, but that didn't help either. The download has stopped at the same point again, and I'm getting these stall messages.

If you run with -debug, do you get more relevant messages in debug.log?

I noticed from your screenshot that you have 1 inbound peer, which may be doing something weird. Maybe you could check if deleting the datadir and temporarily disabling inbound peers (listen=0 in your bitcoin.conf) changes anything?

Stuck again at 4032

Can you see in the logs (with -debug enabled) if you get block 4033 ("00000000db623a1752143f2f805c4527573570d9b4ca0a3cfe371e703ac429aa") but fail to validate it for some reason? Otherwise, I'm out of ideas, sorry.

I am requesting it but apparently, I don't get it. Sorry for the dumb question but how can I check it?

I got version, verack, sendheaders, sendcmpct, addr, feefilter.

As far I understand, then the stalling begins and the same behavior happens with the other peers

I wonder if maybe there is a problem with the firewall. I am running bitcoin core on the university VM's


text:
Is it common for mining effort to be lost?
If many parties are mining to try to establish a block, and one succeeds, does that mean the efforts of the other miners (whose blocks have at least some common transactions) are lost; the time and energy spent to create their blocks must be discarded?
[I have read some of the links, and some of the links of the links, and am still a bit confused.]
Here is an example using a simplified coin.  Imagine there are only 1000 possible choices to complete the block.  And only one miner, Alice.  Since she has to guess which one of the 1000 choices will complete the block, she will make, on average, 500 tries to complete the block. It could be more or less, but 500 would be the average.
Now add another miner, Bill. Alice and Bill start mining at the same time and at the same rate.  Since there are now two miners, and only one needs to succeed to complete the block, together, they need to each try only about 293 times before, on average, the block will be complete.  That is quite a bit faster, because only 293 tries-times have elapsed, but the total number of tries to complete the block is larger, 586 instead of 500.  The 86 tries seem wasted because a single miner would only need, on average, 500 tries.
UPDATE:
I now realize that each miner (or at least each mining group) is working on their own, unique block.  The block is unique if only because of the miner designation (who gets the bitcoin reward) that is part of the block.  So, in general, no two miners, outside of a mining group, are ever working on the same block.

Mining is a 'memory-less process', which means that each and every attempt at solving the block is unrelated to how many past attempts you've taken. It is like rolling dice: no matter what you rolled previously, your chance of rolling a 6 is still just 1 in 6.
The network difficulty automatically adjusts according to the recent rate of block production, and as the difficulty increases, so too does the average number of hash attempts needed in order to find a new block. So each previous attempt is not 'wasted', it is simply expected that the vast majority of attempts will not be valid. And when considering all of the miners en masse, the sheer number of guesses required to find each new block is what allows the bitcoin network to be considered secure.

I understand a single miner must make many attempts to solving their block.  But are many miners working at the same time to solve the same (or largely similar) block?  Unless they are sharing their attempt results (which would be meaningless unless the two blocks were identical) then the two miners are expending effort to solve the same or similar block and the efforts of one are discarded when the other succeeds.

@user253751 Nice analogy, that's exactly it: no, the unsuccessful rolls/hashes aren't wasted because they could have been successful.

@user253751 Yes, if Alice and Bob both rolled a 3 then one of them duplicated work unnecessarily.

@Jiminion: Miners never repeat work done by other miners because they all work on unique block templates: https://bitcoin.stackexchange.com/a/36194/5406

If there are two blocks created nearly simultaneously, and the blockchain forks, eventually only one will be considered valid, and one of the blocks has to be discarded.  And if the bad side of the fork grows to some extent before failing, then all of the blocks added to the failed chain also need to be discarded.  That seems like lost effort to me.

@Jiminion That scenario is actually lost effort indeed, and it is the primary reason why the inter block time is that long: giving (honest) miners time to learn about each others blocks (see https://bitcoin.stackexchange.com/a/113506/208). But that's a different case than what you are asking about, I think? Hash attempts that just never beat the target value are not wasted - they're just a byproduct of the process of creating hashes that do beat the target, at a fixed (expected) ratio.

@PieterWuille Yes, it was a different case.  I edited the question to present a better (simplistic) example.  My thinking now is that the tries are not wasted from the perspective of the miners, but they can be wasted from the perspective of the effort needed to secure the blockchain.  Effort is wasted to preserve the capitalist incentive to pursue bitcoins, so miners do not work in concert. [I am not anti-capitalist, but it is unclear how this effort is directly beneficial to blockchain security.]

@Jiminion There is a fixed ratio between winning hash and losing hash attempts. You cannot create one without the other. You can see the winning ones just as an approximate way to measure how many hashes are actually performed. But it is the hashes that secure the network - more hashes (even losing ones) performed means attackers also need to perform more.

All miners create and discard billions of blocks every second. This work, including the discarded work, acts to benefit the entire Bitcoin community by securing the network. This is the work that is an essential basis of the "Proof of Work" on which Bitcoin is based.
In the long term, miners are rewarded fairly for their share of all work done.


text:
How to add bitcoin wallet to Mt. Gox?
I am fairly new to this and I am worried I just wasted 300. It just says out of sync. How do I add my bitcoin wallet to Mt. Gox?

While you can keep your funds on Mt. Gox, it is not advisable to do so, for the reasons listed here. So you would better find an e-wallet you like (I suggest blockchain.info), and send your funds there.
Always keep a backup, and never forget your passphrase!

Sorry to hear you accidentally 300 - we've all been there at one point or another. To answer your questions:
I sent bitcoins to a bitcoin client that hadn't fully synced - are my bitcoins lost?

How do I add my bitcoin wallet to Mt. Gox?

Click "Add Funds", choose Bitcoins

Thanks for the reply. I tried adding funds by using bitcoins, and it did not give me an option to add my bitcoin wallet.

-1 while this answers the exact question asked, I think it would have been much better to explain to the OP what was he doing wrong and dissuade him (sorry)


text:
How do I withdraw USD from Mt. Gox through SEPA?
Can Mt. Gox convert USD to EUR or do I have to convert it through Bitcoin myself?

If you're willing to pay more trade fees, you can convert your funds from USD back to BTC and then from BTC to EUR (both can be done on MtGox), then withdraw.

Mt. Gox has a BTC/EUR market so you can sell your bitcoins for EUR and withdraw them.
But you mention that you already have a USD balance at Mt. Gox.  The cost to convert them to EUR within Mt. Gox will vary based on the ask price on the BTC/USD market and the bid price on the BTC/EUR market.  It is possible you can buy BTCs with your USDs, then sell them on the BTC/EUR market and even after fees still end up paying less than any other conversion method (based on the forex EUR/USD exchange rate).
However, if you simply want to do an international withdrawal, you can withdraw USDs to your bank and your bank will charge you a conversion fee to change those funds into EUR.  Wire fees from Mt. Gox apply.
For smaller amounts (e.g., less than $1K USD or so), you will likely find it more affordable to buy bitcoins and sell them for EUR then withdraw as an inexpensive SEPA transfer.

MtGox doesn't convert funds. The only way to obtain USD would be to open a USD wallet, transfer the bitcoins there, and sell them. But then you have to figure out how best to withdraw the funds, which may be tricky.
If you're converting to obtain local currency for travel, consider using http://localbitcoins.com upon arrival. You'll receive cash instantly and can avoid dealing with any banks or trading firms.


text:
Is there a limit for bitcoin withdrawal at Mt.Gox?
Their page states (https://support.mtgox.com/entries/20490576-Withdrawals-and-Deposits):

All methods below are subject to a withdrawal limit of 1000 USD per 24hr period and 10000 USD per 30 Day period

They include bitcoin in the list below this statement too. Does that mean they will allow me to withdraw only number of bitcoins that currently has a value of 1000 USD?

"They include bitcoin in the list below this statement too. Does that mean they will allow me to withdraw only number of bitcoins that currently has a value of 1000 USD?"

No, it means exactly what it says, that you can only withdraw $1000 a day.
That being said there is an entirely separate limit that they place on bitcoins. On my account under funding options and withdrawals it reads

BTC : You can still withdraw up to 100.00000000 BTC provided you have enough on your account (your limit is 100.00000000 BTC per 24 hours )

When you sign up for Mt. Gox, the user agreement says that Mt. Gox can suspend your account at any time for any reason and then will require that you provide verification to regain access to your account.
Anyone accessing their account through Tor will usually trigger this.


text:
Can I use same bitcoin address for Mt.Gox deposit multiple times?
They say they will generate new address for each deposit. If I want to split my bitcoin transaction in multiple parts but send one after another, can I use the same address more often?

Of course you can. The reason for using different address every time is:

to provide you more anonymity. It will be harder for people to
associate your with your other addresses (but not impossible)

But if you need to make many transactions, it might be a little bit tedious. So it is up to you to decide what exactly do you want.


text:
Bitcoin RPC Call
I want to monitoring 3000 address continuously for BTC. So I am using third party API for get BTC balance. but all API has limitations for access. Can I get an API reference where I can call API continuously without any limitations?
If I will call API continuously then they will block my IP. So is there any way to short out this issue ? Please help

You should run your own server and don't use a third party in such a case.
Take a look on "insight" of bitpay.

Thank you @Adam. I am also thinking for that. I am familiar with NEO blockchain. I have never use Bitcoin node in my current project. I have use only Bitcoin and Ethereum's API. So please can you guide me that how should I setup bitcoin node on my system.

see: https://insight.is/ and https://github.com/bitpay/insight