New answers tagged

2

Your input txid output index is 5 bytes, when it should be 4 bytes. Just remove the extra 00 byte and the transaction will not pop an error. However, you might need to sign this transaction again as signature involves signing the entire serialized transaction as a message and by changing the txid outpoint you will change the message that is signed.


1

What you are referring to are stale blocks. Orphaned blocks are one for which the previous (parent) hash field points to an unknown block or to a block not yet processed by the local node. Since Bitcoin Core follows headers first approach, block headers are downloaded and validated first before downloading the block data. As a result, full nodes will never ...


0

P2SH According to the Bitcoin Wiki: Pay to script hash (P2SH) transactions were standardised in BIP 16. BIP 16 describes the construction of this transaction type and has links to a reference implementation. VIN Googling Bitcoin-Cli P2SH VIN leads to Bitcoin basics: what are vout, vin, scriptPubKey? which seems to be a useful overview.


1

As Ugam Kamat commented: 20 in decimal is equal to 14 in hexadecimal (Community-Wiki answer to remove Q from unanswered list)


0

To run two full nodes on the same machine, they'll need to be bound to different ports. Luckily, bitcoind and bcoin run regtest on different ports already by default (18444 and 48444 respectively). Just note this wouldn't be the case for testnet or main net. Launch bitcoind $ bitcoind -daemon -regtest Launch bcoin in SPV mode $ bcoin --spv --daemon --...


1

You are allocating far too much dbcache. If you allocate 4000 MB to the dbcache, you will use up all of your RAM and it will crash. Your operating system needs RAM, Bitcoin Core itself needs RAM outside of the dbcache. I would highly recommend that you do not set a dbcache at all as 4 GB is really not enough RAM to handle a larger dbcache, Bitcoin Core's ...


1

Or is is possible to allocate multiple cores(not threads) to JSON rpc No. The problem is not to do with thread or core allocation. Rather Bitcoin Core makes use of locks to keep the chain state consistent when multiple threads may access it. In this case, you will need to access the chain state to get transactions so multiple getrawtransaction calls cannot ...


2

Yes, you can sign with that. Hardware wallets don't care about your gap limit, they aren't deriving individual keys when you setup the wallet. Rather they just store the master private key (or the seed used to derive the master private key) and then derive the individual keys needed on-the-fly. So if you tell it to sign with the 999,999th key, by giving it ...


0

If anyone got problem with reaching bitcoin-rpc server located on vps, the best way in my opinion would be port redirecting over shh. By this command: ssh [user]@[host] -p [port] -L 18332:127.0.0.1:18332 You will be able to send comands to testnet rpc-server via your computer terminal as localhost.


0

Please keep in mind that exposing your node's RPC interface to the entire internet is considered to be unsafe. RPCs are not encrypted so anything that you send to your node will be in cleartext for any man in the middle to see. This includes things such as your RPC username, RPC password, and wallet password. If an attacker were to see any of this ...


1

The account API has been deprecated for a while, and was completely removed in Bitcoin Core 0.18.0. You should be using the new mutliwallet API, or handling account based labelling externally.


1

This is mentioned in the Bitcoin Core 0.17 (which introduced network sections) release notes: https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.17.0.md#configuration-sections-for-testnet-and-regtest. Certain options must be prefixed with a network, or they'll only apply to mainnet (addnode, connect, port, bind, rpcport, ...


0

I still have no idea as to WHY this is happening. But changing config to this: [main] # Allow JSON-RPC connections from, by default only localhost are allowed rpcbind=127.0.0.1 rpcbind=10.18.0.1 rpcallowip=127.0.0.1 rpcallowip=10.18.0.0/24 [test] # Use the test chain testnet=1 rpcbind=127.0.0.1 rpcbind=10.18.0.1 rpcallowip=127.0.0.1 rpcallowip=10.18.0.0/...


2

which, as I understand it, makes some data (until 2017?) real without verification. You understand incorrectly. Firstly, the assumevalid blocks is updated at every major release, so it is at most a couple of months out of date for the most recent release. For Bitcoin Core 0.18.0, the assumevalid block is ...


1

You can't just give Bitcoin Core the redeemScript, it won't know what to do with it. The only valid thing to give it is an address, but you have not given it an address. You need to convert your redeemScript into a P2SH address first, then you give it that address. You can use the decodescript command to get both the p2sh and p2wsh addresses for your ...


0

Based on @hiding_ninja response here's my masterpiece and assuming you have the configs in ~/.btcd/btcctl.conf #!/bin/bash count=$(btcctl -C ~/.btcd/btcctl.conf getblockcount); echo "block count: $count"; hash=$(btcctl -C ~/.btcd/btcctl.conf getblockhash $count); echo "block hash: $hash"; t=$(btcctl -C ~/.btcd/btcctl.conf getblock "$hash" | grep '"time"' ...


0

the issue is now tracked on https://github.com/bitcoin/bitcoin/issues/16275...


0

Updating the ColdCard to the latest (unreleased) firmware shows the xpub that is compatible with my above code and works flawlessly with the above example. The same ColdCard with the new dump summary outputs: # Coldcard Wallet Summary File ## For wallet with master key fingerprint: 18734CBE Wallet operates on blockchain: Bitcoin Testnet For BIP44, this ...


0

The best way to implement accounts is to insource Address database Private key database Transaction signing and leave only transaction relaying and checking for transactions to Bitcoin Core.


Top 50 recent answers are included