text:
Is there a working Open source implementation of litecoin mining application for Linux without GUI
Is there a working Open source implementation of litecoin mining application for Linux flavours without GUIs (think debian, ubuntu server etc.)
I found a couple of implementations by developers but all of them are closed source.

cgminer should work, it is open source, cross platform miner for bitcoins and litecoins (--scrypt key  used for scrypt based coins like litecoin.)

Looks like the litecoin.org client on github includes  litecoind which would be the non-GUI version.
https://github.com/litecoin-project/litecoin/blob/master-0.8/INSTALL
https://github.com/litecoin-project/litecoin/blob/master-0.8/doc/build-unix.md

there are many, googling "litecoin mining software" will find you some.
I've used:
https://github.com/cbuchner1/CudaMiner
https://github.com/ckolivas/cgminer/


text:
JSON-RPC problem with Bitcoin-Qt 0.8.5
I am running bitcoin-qt v0.8.5 on Linux/amd64 and I encounter a strange behaviour for account commands when using JSON-RPC.
My initial wallet looks like this:
Test-Account | 1PNU1vZbruMCZpVBFk3eKmKrfGKDugBsjB

After issuing the command
setaccount '1PNU1vZbruMCZpVBFk3eKmKrfGKDugBsjB' 'Renamed Account'

I just expected the old account to be renamed, but the wallet changes to:
Renamed Account | 1PNU1vZbruMCZpVBFk3eKmKrfGKDugBsjB
Test-Account    | 16jfcbLM9tGrkvXqGKnuC46j2jqKVMAe46

It created a new address for the old account (it is always the same new address for the same old address !?). Is that behaviour intended? The documentation I could find is unconclusive about that.
After this I issued the command
getaccountaddress 'Renamed Account'

and I expected to get the address "1PNU1vZbruMCZpVBFk3eKmKrfGKDugBsjB" as a result. But instead I got the single address "176uhGVRT8KxScvQqdA7Yh87qQ8F5LMMM6" - and the wallet now looks like:
Renamed Account | 1PNU1vZbruMCZpVBFk3eKmKrfGKDugBsjB
Renamed Account | 176uhGVRT8KxScvQqdA7Yh87qQ8F5LMMM6
Test-Account    | 16jfcbLM9tGrkvXqGKnuC46j2jqKVMAe46

What is happening here? What am I doing wrong?

From the Accounts wiki page:

getaccountaddress will return the same address until coins are received on that address; once coins have been received, it will generate and return a new address.
getnewaddress always generates and returns a new address.
setaccount changes the account associated with an existing address. Coins previously received on that address (if any) will be debited from the previous account's balance and credited to the address' new account. Note that doing so may make the previous account's balance negative.

Use the getaddressesbyaccount method to list all addresses associated with an account.

source: Stack Exchange

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

sort: votes


text:
Bitcoin Core RPC cURL - importdescriptors failing on loaded wallet
I am running the following request to load a wallet.
curl --location 'user:password@umbrel.local:8332/wallet/test_multisig"' \
--header 'Content-Type: text/plain' \
--data '{
    "jsonrpc": "2.0",
    "method":"loadwallet",
    "params": ["test_multisig"],
    "id": "test_multisig_wallet_load"
}'

It returns...
{"result":null,"error":{"code":-35,"message":"Wallet \"test_multisig\" is already loaded."},"id":"test_multisig_wallet_load"}
However I then run this exact request, and receive an error as if the wallet is not loaded.
curl --location 'user:password@umbrel.local:8332/wallet/test_multisig"' \
--header 'Content-Type: text/plain' \
--data '{
    "jsonrpc": "2.0",
    "method":"importdescriptors",
    "params":{
        "requests":[{
        "desc":"pkh(cSQPHDBwXGjVzWRqAHm6zfvQhaTuj1f2bFH58h55ghbjtFwvmeXR)",
        "active": false,
        "range": 20,
        "next_index": 0,
        "timestamp": "now",
        "internal": false,
        "label": "test_multisig_wallet"
        }]
    }
}'

Error...
{"result":null,"error":{"code":-18,"message":"Requested wallet does not exist or is not loaded"},"id":null}
How can I import descriptors into a wallet so the wallet has a sequence of addresses?

What is the output of listwallets?

That wallet and a few others are listed. @PieterWuille

@PieterWuille The full result for listwallets is {"result":["test_multisig","wallet2","wallet3"],"error":null,"id":"testWallet"}. I receive the same error when running importdescriptors on all of these wallets.

I feel your pain, I do think that these APIs need some more love at the level of usability. I am planning to spend some time on it because I had some problems too.
But before calling it a bug, we need to try to check if the workflow is the correct one.
Step 1: Create a wallet;
Step 1.1: Check if the wallet exists, if yes load it (in the URL you do not need to specify the /wallet/<name_wallet>)
Step 2: import your descriptors (you should work)
From the error that you gave, and from my experience I think
your wallet is not loaded, maybe because you are using the wrong URL (and here the question is why core is not failing?)
Keep us posted!

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


text:
Why does Bisq claim that my "native segwit" receive addresses are "invalid"?
Every time I'm transferring over the funds from Bisq to Bitcoin Core, I get the error:

Invalid address.

(Or something along those lines.)
Only after generating another receive address in Bitcoin Core, unchecking the "Generate native segwit (Bech32) address" checkbox, does it work.
Why does Bisq consider "native segwit (Bech32) addresses" (the default in Bitcoin Core) to be "invalid"? Is this some kind of internal war in the Bitcoin community where they refuse to even acknowledge the existence of this other "format"?
Every time it happens, I almost get a heart attack until I realize I forgot to uncheck that checkbox...

Many clients have not been updated to recognize native segwit addresses, and are unable to deal with the bech32.
There should be no real downside to sending to a non-native-segwit address, besides some minor fee increase when you spend the coins.

Bisq now does support extracting, withdrawing btc to Segwit addresses. They implemented this change back in Sept 2020 -> see https://github.com/bisq-network/bisq/releases/tag/v1.4.2
Part of their Release notes in that version include:

Use SegWit addresses to fund and withdraw from your Bisq wallet
NOTE: Although it's now finally possible to transfer out of Bisq to
Bech32 wallets, do not expect any fee savings just yet, because all
Bisq trading transactions still happen against P2PKH addresses. This
change will be shipped in one of the next releases.

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


text:
How to obfuscate public IP of Mining pool?
How to obfuscate the public IP address of a mining pool, to protect it against DDOS attacks?
I have a yiimp mining pool running on a cloud server.
I would like to secure it with HTTPS and anti-DDOS by obfuscating the public ip using Cloudflare, while still retaining stratum mining functionality from the yiimp pool.
The domain of my website is mycoin.io and I have set up the DNS to point to cloudflare. So now the website has HTTPs and DDOS protection.
My yiimp pool server is hosted on the cloud at 149.55.55.55 and I have setup cloudflare to redirect subdomain pool.mycoin.io to that ip address.
Now my mining script can look like this:
-o stratum+tcp://149.55.55.55:3747 -u WALLET_ADDRESS -p c=BUEN
or like this:
-o stratum+tcp://pool.mycoin.io:3747 -u WALLET_ADDRESS -p c=BUEN
But this does not provide any https or anti-ddos protection.
How can I obfuscate the public IP of my pool so that:
-o stratum+tcp://pool.mycoin.io:3747 -u WALLET_ADDRESS -p c=BUEN
still works?

pool.mycoin.io is currently NXDOMAIN - something is not setup right.

The Stratum Mining Protocol ist not based on HTTP, so you will not be able to mediate it through Cloudflare or a similar service, unfortunately. Cloudflare and the like are designed for web content as in web pages.

Use anti-ddos service like cloudflare and it should hide it as well as prevent ddos. I never tried it to mine so not guaranteed ill work but there is no other way to hide it


text:
BIP32 wallet sync with Bloom filters
I'm working on my SPV library and I still have a hard time figuring how to approach the BIP32 + Bloom filters combination. Here's how I currently sync an existing HD wallet (after fast catch-up):

Generate a number of watched look-ahead addresses (say 10).
Load a Bloom filter with all used addresses plus look-ahead (N used + 10 look-ahead).
Download filtered blocks with getdata.
Mark watched addresses as used if they're found in any block transaction.
Ensure that the last watched address wasn't used in a transaction.
If so, generate new look-ahead addresses, reload the Bloom filter and download last block again to rematch it. By using a new receive address for each transaction we may have missed other transactions in the same block.
Otherwise, go back to 4 and download new blocks.

Now this sounds quirky and overcomplicated to me. Several discussions on the web talk about "scanning keys" when coming to wallet sync and I don't really understand if they assume a full node or a lightweight SPV node, because I have no idea of how to "scan keys" without a global UTXO database. Also the gap limit only seems to make sense for a full node.
I'm stuck, thanks.

The reason you pre-generate some forward keys is to avoid the situation you describe, if you only looked ahead one you risk missing a transaction in the current block (the order of the transactions in the block are unrelated to the order of your keys).
The term "gap limit" refers to a parameter of non bloomfilter SPV clients which do look ups by querying an address based index on a remote peer. The gap limit is the end stop of the current wallet state, when the scanning wallet sees 10 empty address results in a row they decide that's probably the last used address in the wallet and give up generating further. If there wasn't a gap limit in place they would search unused addresses until the end of time (or 2**128, which ever came first).

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


text:
Possible to speed up reindex?
I just reindexed a node that was already synced (in order to enable txindex); it took around 9 hours. It's on a pretty good system: 16G RAM, i7 with 4 physical cores. Storage is a weak point, with LUKS on software RAID0 on spinning disks. dbcache is at the default 100M, though I'm running 0.11 so I gather this ends up smaller than the previous default due to more accurate accounting. By extrapolation from testing a subset, a sequential read of the full ~38G of blk files should take ~4 minutes.
I understand reindex includes rebuilding the chainstate db, so I'm guessing that's the bottleneck. Questions: 1) reindex doesn't also re-validate blocks, does it? 2) Any experience with speeding this up -- perhaps putting chainstate on a tmpfs and copying to permanent storage once complete?
Followup: by increasing dbcache as suggested, and adding a recent custom checkpoint to the code, I got another reindex done in about 3 hours.

I like the "custom checkpoint" idea.  It suggests that a feature could be added to allow any user to make one from the GUI, so, for example, if you want your client to keep running but you know you're doing something that might crash your machine, you could checkpoint right here and vastly speed up your recovery - or "replace last checkpoint with current state".  Have you made such a suggestion anywhere?

reindex doesn't also re-validate blocks, does it?

It does, but signature verification (the slowest bit) is skipped on most of the early blockchain. The command attempts to sync with the network by reusing as many blocks as possible that are already written to the disk, which may very well include damaged or partially written ones.

Any experience with speeding this up

Increasing the dbcache will speed up reindexing, putting it at 2G (dbcache=2048) would not be an unreasonable choice given you have the memory. This is about all you can do, until it gets to the point where you are validating signatures a reindex is heavily single threaded.

How is it determined which signatures are verified -- after the last checkpoint? Is there a technical reason this is necessary, as opposed to, say, just verifying block hashes and PoW until the last couple dozen/hundred?

All signatures after the last checkpoint. Optimally all signatures would always be verified but the sync time would just be extreme, not doing it at all would risk decentralization. It's a crutch for the fact that ECDSA is slow and there's a lot of transactions in the Bitcoin blockchain to verify.

Put more simply: reindez does exactly the same as redownloading the chain from scratch, except it reuses the blocks on disk you already have.

Ahh... and that explains why the first 295k blocks go so much faster, in both initial sync and reindex.

@PieterWuille Does this mean a bigger dbcache will not speed up?

@fossilet Sure it does. Read the answer above.

The behavior I noticed from a reindex on my node was that it ended up reloading the entire blockchain from the Internet. This is consistent with what the Bitcoin Meister Pieter Wuille indicated. Will have to remember the dbcache trick...

I know this is an older question, but I've found it now, so I think it can be good for others who will find this thread.
You should download the latest version of bitcoin QT (0.15.1 as of writing this)
which has some performance tweaks and it reindex on disk about 10 times faster than the 0.12 which i had before.
saying that, you could also download blockchain from torrents. Here is the official link to torrent
https://bitcoin.org/bin/block-chain/
After downloading it, you should call
bitcoin-qt.exe -datadir=<path to Bitcoin dir> -rescan

And the speed will come to you. ;)

Downloading through torrents is actually not faster than letting bitcoin-qt do the downloading. Used to be several years ago, but these days bitcoin itself does a better job than bittorrent and can then do validation in parallel to the downloading. The link you provided points to a 2014 torrent file. That shows how outdated this trick is.

Increasing dbcache is probably the most important thing you can do:
-dbcache=1000

Another thing to do is to disable all console output:
-printtoconsole=0

Apart from that, if your disk is the bottleneck, you can move parts of the blockchain data to a faster disk. The majority of the blockchain (the blocks themselves) can stay on a slow HDD, and you can move chainstate and index (inside blocks) folders to an SSD by creating symbolic links.


text:
Lower confirmation time schemes: any requirement between confirmation time and the probability to find a block during that confirmation time?
Bitcoin, the first blockchain-based cryptocurrency, set a 10 minute confirmation interval time; LiteCoin set a 2 minute confirmation interval time; DogeCoin set it at 1 minute; QuarkCoin set it at 30 seconds; Ethereum set it at 12 seconds.
Is there any serious analysis about the stability of the blockchain when the confirmation time is reduced?
To be more specific: any requirement between confirmation time and the probability to find a block during that confirmation time ( specially when confirmation time is going to zero) ?

@NickODell Thanks for your editing. Title is now a clear question.

The lower confirmation time schemes for mining a block will have a pronounced effect on orphaned blocks, with an inversely proportional relationship prevailing.
Generally this can be explained quite simply; because shorter confirmation times for blocks will mean numerous simultaneous competing chains lengths. Of these competing chains, one will eventually be integrated into the ledger when the block height is greater than the competing chains' heights. However, the chains which are rendered obsolete (ie the shorter chains not integrated into the ledger) will mean orphaned blocks are much more likely as confirmation time decreases.
Take an example where it's 1 minute confirmation times. If there's 4 competing chains each 5 blocks in height/length then all it takes is for one of the chains' blocks to be confirmed in, say, 10 seconds, followed by the next confirmation in 10 seconds (which is not a rare event) which will make the block height 7. Therefore, the other chains of height 5 (or perhaps 6 if a block was solved) will be rendered orphaned, and all Txns therein will be orphaned.
There is a balance that needs to be struck between confirmation time and orphaned blocks, and from my experience with altcoins, the 2 minute mark (as employed by Litecoin) is the functional limit. Ethereum has a much, much shorter confirmation time because it's a totally different kind of altcoin. However for POW coins like LTC/BTC, a ~20s confirmation time is infeasible.

Note that the confirmation time doesn't totally control how long blocks take to be generated - the average time between blocks in Bitcoin is 10 minutes, but that can be shorter or longer.

@nickodell I did try to cover that without the math using the 10s block eg but you've raised another good point; what variables should/could be considered to improve on Bitcoin's 2016 block/10 min (eg some altcoins employed Kimono Gravity Well for difficulty adjustment, but assessing the mining reward paradigm could provide far superior improvements, ie like Ethereum/sidechains promise)

Wizard, please can you elaborate more about Kimono Gravity Well and if any mathematical modeling of the difficulty will be close to Kimono Gravity Well equation?

I'm running off Android at the moment so I don't have the reference handy (I'll aim to do so once I've got access to my Ubuntu bookmarks) but there is definitely material available online for the equation KGW employs. Simply put it's a solution to quickly re targeting difficulty in proportion to hashrate. It is very efficient but extremely sensitive and hasn't seen much use beyond clones of litecoin

@efaysal: Perhaps you'll be interested in How does the Kimoto Gravity Well regulate difficulty?

@Murch, any step-by-step approach to build Kimoto Gravity Well formula? From assumptions to the model or formula?

@efaysal Actually the Sourcecode is linked right on the question I posted above as a comment on the question post.


text:
Mempool docker unable to connect to electrum server
I'm having a problem with "connecting" my mempool.space to electrumX server.
My bitcoin core is working fine, electrumX server is fine as well and up to chaintip. I've installed docker and docker-compose. Everything works fine, However when I try to docker-compose up it runs fine I guess, but at the end it pops this error and keeps repeating it:

docker-api-1  | Jan  6 11:38:12 [98] ERR: Electrum error: {"errno":-111,"code":"ECONNREFUSED","syscall":"connect","address":"0.0.0.0","port":50001}
docker-api-1  | Jan  6 11:38:12 [98] INFO: Disconnected from Electrum Server at 0.0.0.0:50001

My docker-compose.yml file:
version: "3.7"

services:
  web:
    environment:
      FRONTEND_HTTP_PORT: "8080"
      BACKEND_MAINNET_HTTP_HOST: "api"
    image: mempool/frontend:latest
    user: "1000:1000"
    restart: always
    stop_grace_period: 1m
    command: "./wait-for db:3306 --timeout=720 -- nginx -g 'daemon off;'"
    ports:
      - 4080:8080
  api:
    environment:
      ELECTRUM_HOST: "0.0.0.0"
      ELECTRUM_PORT: "50001"
      ELECTRUM_TLS_ENABLED: "true"
      MEMPOOL_BACKEND: "electrum"
      CORE_RPC_HOST: "0.0.0.0"
      CORE_RPC_PORT: "8332"
      CORE_RPC_USERNAME: "####"
      CORE_RPC_PASSWORD: "####"
      DATABASE_ENABLED: "true"
      DATABASE_HOST: "db"
      DATABASE_DATABASE: "mempool"
      DATABASE_USERNAME: "mempool"
      DATABASE_PASSWORD: "mempool"
      STATISTICS_ENABLED: "true"
    image: mempool/backend:latest
    user: "1000:1000"
    restart: always
    stop_grace_period: 1m
    command: "./wait-for-it.sh db:3306 --timeout=720 --strict -- ./start.sh"
    volumes:
      - ./data:/backend/cache
  db:
    environment:
      MYSQL_DATABASE: "mempool"
      MYSQL_USER: "mempool"
      MYSQL_PASSWORD: "mempool"
      MYSQL_ROOT_PASSWORD: "admin"
    image: mariadb:10.5.8
    user: "1000:1000"
    restart: always
    stop_grace_period: 1m
    volumes:
      - ./mysql/data:/var/lib/mysql

My electrumX.conf file:
# default /etc/electrumx.conf for systemd

# REQUIRED
DB_DIRECTORY = /home/qbr1ck/electrumx_db
# Bitcoin Node RPC Credentials
DAEMON_URL = ####:####@localhost

COIN = Bitcoin
SERVICES = tcp://0.0.0.0:50001
PEER_DISCOVERY = off
COST_SOFT_LIMIT = 0
COST_HARD_LIMIT = 0

User and Password are hashed out in both files, however they are the same.
This is the full output after running docker up, might give some clues
[+] Running 3/3
⠿ Container docker-db-1   Running                                         0.0s
⠿ Container docker-web-1  Running                                         0.0s
⠿ Container docker-api-1  Recreated                                      60.4s
Attaching to docker-api-1, docker-db-1, docker-web-1
docker-api-1  | wait-for-it.sh: waiting 720 seconds for db:3306
docker-api-1  | wait-for-it.sh: db:3306 is available after 0 seconds
docker-db-1   | 2023-01-08 13:49:36 6 [Warning] Aborted connection 6 to db: 'unconnected' user: 'unauthenticated' host: '172.16.57.2' (This connection closed normally without authentication)
docker-api-1  | Jan  8 13:49:37 [97] NOTICE: Starting Mempool Server... (a210a3f)
docker-api-1  | Jan  8 13:49:37 [97] INFO: Restoring mempool and blocks data from disk cache
docker-api-1  | Jan  8 13:49:37 [97] ERR: Electrum error: {"errno":-111,"code":"ECONNREFUSED","syscall":"connect","address":"127.0.0.1","port":50001}
docker-api-1  | Jan  8 13:49:37 [97] ERR: Error connecting to Electrum Server at localhost:50001
docker-api-1  | Jan  8 13:49:37 [97] INFO: Disconnected from Electrum Server at localhost:50001
docker-api-1  | Jan  8 13:49:37 [97] INFO: Database connection established.
docker-api-1  | Jan  8 13:49:37 [97] INFO: Starting statistics service
docker-api-1  | Jan  8 13:49:37 [97] INFO: Starting currency rates service
docker-api-1  | Jan  8 13:49:37 [97] INFO: Currency rates service will be queried over clearnet using https://price.bisq.wiz.biz/getAllMarketPrices
docker-api-1  | Jan  8 13:49:37 [97] NOTICE: Mempool Server is running on port 8999
docker-api-1  | Jan  8 13:49:37 [97] INFO: Updating latest mining pools from https://raw.githubusercontent.com/mempool/mining-pools/master/pools.json over clearnet
docker-api-1  | Jan  8 13:49:42 [97] WARN: runMainLoop error: connect ECONNREFUSED 127.0.0.1:8332. Retrying in 10 sec.
docker-api-1  | Jan  8 13:49:47 [97] ERR: Electrum error: {"errno":-111,"code":"ECONNREFUSED","syscall":"connect","address":"127.0.0.1","port":50001}
docker-api-1  | Jan  8 13:49:47 [97] ERR: Electrum error: {"errno":-111,"code":"ECONNREFUSED","syscall":"connect","address":"127.0.0.1","port":50001}
docker-api-1  | Jan  8 13:49:47 [97] INFO: Disconnected from Electrum Server at localhost:50001
docker-api-1  | Jan  8 13:49:52 [97] WARN: runMainLoop error: connect ECONNREFUSED 127.0.0.1:8332. Retrying in 20 sec.
docker-api-1  | Jan  8 13:49:57 [97] ERR: Electrum error: {"errno":-111,"code":"ECONNREFUSED","syscall":"connect","address":"127.0.0.1","port":50001}
docker-api-1  | Jan  8 13:49:57 [97] ERR: Electrum error: {"errno":-111,"code":"ECONNREFUSED","syscall":"connect","address":"127.0.0.1","port":50001}
docker-api-1  | Jan  8 13:49:57 [97] INFO: Disconnected from Electrum Server at localhost:50001

As far as I can see in your files, you have a problem whit your docker file:

ELECTRUM_HOST: "0.0.0.0" ---> should be the IP address from your electrumx server, some like 192.168.0.17, not 0.0.0.0
CORE_RPC_HOST: "0.0.0.0"---> same here the IP address should be the IP from your bitcoin core, some like 192.168.0.17, not 0.0.0.0

In my sparrow wallet I've used 0.0.0.0:50001 as my electrum server and it worked. I've used 0.0.0.0 as address for both my electrumx and core as bitcoin.conf and electrum.conf have it. Bitcoin.conf rpcport=8332  rpcbind=0.0.0.0       electrumx.conf   SERVICES = tcp://0.0.0.0:50001

Sparrow could be working because it does some sweep of all the addresses you have locally listening on port 50001 (in this case, bitcoin core or electrumX).
I don't think mempool is doing the same thing.
It's not usual to configure a server with the IP 0.0.0.0 for exposure to clients.
https://www.lifewire.com/four-zero-ip-address-818384

Thanks for that, I guess I should change those four zero addresses in all my conf files, i'll assign new adresses try to get electrum and sparrow to work and then try mempool. Let you know how it goes.

So I've tried swapping for localhost address but that didn't work, I thought localhost is the address of the computer I'm running core, electrum and docker on? Shouldn't 127.0.0.1, localhost and 192.168.1.## (## being that computer ip) be all the same?

I've tried changing to 192.168 address but then my bitcoin core doesn't work. If you don't mind can you please elaborate what exactly addresses I should have in my bitcoin.conf file, electrumx file and docker.yml file? And where I can find that address? Thanks!

That got me thinking is it possible that something else is not correct in that docker file? Maybe username pass, I've used the one that is in electrumX,conf, do both of those refer to the bitcoin core password? Thanks!

Typically, the Bitcoin Core address is the local one: 127.0.0.1 (for local use, you could create a Tor service)
The default port for listening to RPC calls is 8332, and the bitcoin port is 8333.
If you have rpcuser and rpcpassword configured, the same you should use them in Electrumx and sparrow.
Electrumx, if you have Electrumx in a docker, will have an IP address different from 127.0.0.1 and 192.168.X.XX, it is probably an IP that starts with 172.x.x.x.x, that is the one you should use to connect Sparrow and remember to use the rpcuser and rpcpassword of bitcoin.

I'm assuming that Bitcoin Core is not running in a Docker, if is running in docker, I think you should use the IP of the container that is running Bitcoin Core.


text:
What are the privacy implications of sharing or publishing the .onion address of a bitcoin node?
Some tutorials redact the .onion address of their nodes for privacy reasons: https://coldcard.com/docs/img/econoalch/Sparrow47.png
What are the attack vectors that they are defending themselves from? Could it be an attempt to avoid inviting eclipse attacks?
https://eprint.iacr.org/2015/263.pdf
What are the risks of sharing the .onion address of a self-hosted node with potentially careless people who need a trustworthy node?


text:
Where is the data directory from the initial Bitcoin Core Welcome prompt saved on a Mac?
When you start Bitcoin Core for the first time on a Mac, you are prompted to specify a custom data directory. However, it is not clear where this setting is stored and the "Welcome" screen does not pop-up again. If you go to Options > Open Configuration File, it is empty.
I checked for the default directory of /Users/username/Library/Application Support/Bitcoin, but it doesn't exist. So where is this configuration stored?

I want to know where the datadir configuration too.

The configuration is saved as key 'strDataDir' of /Users/xxx/Library/Preferences/org.bitcoin.Bitcoin-Qt.plist in Mac.


text:
LN-Channel: Do I have to use new private keys for each HTLCs out of security?
I have a question regarding the security of HTLCs in a LN-channel.
In a LN-transaction with multiple HTLCs (routings) to the destination one is using the signature of each node provider so that the first one who knows the secret "R" is not able to spend the other HTLCs in the channel.
That means for redemption of an HTLC the following criteria have to be presented:

Signature
Secret "R"

If I am participating in two LN-channels. Is it then necessary out of security reasons to use two private keys so that my signature for the two HTLCs are not identical?
Example:

LN-channel 1
LN-channel 2

1. Alice
1. Dina

2. Bob
2. Bob

3. Chan
3. Chan

4. Eve
4. Tom

Let's suppose Bob uses for both channels the same private key.

Chan receives the secret "R1" from Eve (channel 1) and "R2" from Tom (channel 2) after providing the respective funds to them.
Now Chan can provide the secret "R2" to Bob, who uses his signature to unlock the HTLC to Dina.
If Bob has used to same private key for both HTLCs, couldn't Chan now copy and paste the signature from Bob from channel 2 and use the known secret "R1" to unlock the HTLC between Bob and Alice?

Can someone verify or help me to correctly understand it?
Thank you very much in advance.

I have researched a little bit further. I assume the answer is that the signatures would be different even though using the same private key, because the signature is created with the private key and transaction data. So they would differ in the LN-Channel 1 and 2. Can someone confirm this? Thank you!

Digital signature algorithms take a “message” they are committing to as an input. In the case of Bitcoin transactions, this message is a digest of the transaction data specific to each input referred to as signed hash. Additionally, a random secret nonce k is used to create a signature (although some signing implementations pick this nonce deterministically).
So, when signing

inputs of different transactions with the same key
different inputs of the same transaction with the same key
the same input of the same transaction a second time

you will still always produce a new unique signature (with the exception of the last case which will produce exactly the same signature when performed with a deterministic nonce).
IIRC HTLCs always use a new key taken from a hierarchical deterministic chain of keys derived from a basepoint shared with their channel partner on channel opening. This construction allows for effective reconstruction of the relevant keys from a minimal backup while using distinct keys for each output ever added to the channel's commitment transactions. I suspect that always using the same key would still be secure but a bad privacy leak, but have not verified this theory.


text:
Transactions remain unconfirmed, even with 10X recommended 2 block BTC/kB
I have never been able to successfully send BTC from my wallet in Bitcoin Core.  I'm sure this question has been asked before, but I could not find a sufficient match to my problem, due to most problems involving the TX fees being too low, folks mixing up TX fee rates with static TX fee amount, etc.
In my case I have tried to send various amounts to various different wallets.  I have not only used the recommended 2 block rate that Bitcoin Core recommends, but I have also significantly increased that rate even to 10X the amount of BTC/kB that the UI recommends.  Even with extreme high rates, the transactions never get confirmed even after a few hours.
Note that I have successfully sent BTC between various other wallets (coinbase, coinme, exodus) at normal TX fee rates, including during the periods where the aforementioned high free transactions in Bitcoin Core were sitting unconfirmed.  Therefore, I believe the problem is not related to transaction fees (but if you have some specific test related to fees you think I should try, I'll do it).
Additional notes: I can receive funds in the wallet without issue, and those appear correctly in Bitcoin Core along with their confirmations.  The network indicator icon at the bottom of the window indicates a good connection to the Bitcoin network, with all four "arms" highlighted.
Some information about the system:

This is running on a Raspberry Pi 4B (2GB RAM model).
The OS is Raspbian 11 "Bullseye", armv7l (32 bit).
The version of Bitcoin Core is 24.0.1 (installed via snap).
The datadir is on an external SSD connected via one of the highspeed USB ports.
Connection to the internet is through Tor proxy (also running on the same system)

Let me know in the comments if you need any additional information or if there are some specific tests that I can try to help with troubleshooting the problem.  If this is a duplicate, I apologize (please link me to the solution if it is already answered)
EDIT #1: Some additional information from the comments:

None of the transactions sent from the wallet ever confirm, no matter how long I wait
Searching for the transaction IDs on a block explorer, they are not found
The node has been running since around December (never off more than a couple days at a time)
The block index stays up to date
I originally was only running it as a full node to contribute to decentralizing the network, and only in the last week have I started looking at using it for the wallet features

EDIT #2: Most recent attempted transaction:

98ec002df20d8a743d3c7288721b4c95941b7a51b5ef78d9b24dd1e84fd90918

Amount: 0.00200000 BTC

Tx fee (Custom): 0.00250000 BTC per kilobyte

Transaction fee (0.141 kB): 0.00035250 BTC

Total Amount: 0.00235250 BTC

Do the transactions confirm eventually or are they always unconfirmed? Are you able to find the transactions in a block explorer such as mempool.space or blockstream.info? How long had your node been running before you made the transactions?

@AndrewChow Thanks for the reply!  No, the transactions never confirm.  If I search the transaction IDs on a block explorer, they are not found.  The node has been running since around December (not continuously, but never off more than a couple days at a time), and the block index stays up to date.  The latest transaction that I put on there was around 24 hours ago, and it is unconfirmed still.  For all of the previous transactions, I went ahead and ran the "Abandon transaction" option (just in case having too many unconfirmed transactions in the queue might be a problem).

Also, forgot to mention, I originally was just running it as a full node, just to help with decentralizing the network.  I only recently, in the last week, have started looking at using it for the wallet features, so I wasn't aware of the problem prior to that.

Do incoming transactions show up as unconfirmed first? It sounds like your transactions are not propagating which could be caused by having few or no connections that relay transactions. Could you also post the contents of your bitcoin.conf?

I resolved the problem.  Thanks @AndrewChow for reminding me in the comments about the bitcoin.conf file.  I forgot that I had made some changes to that and never went back to revert them.
The problem turns out that I had set "walletbroadcast=0"
In case anyone is wondering why I had that option in there and forgot about it, I had originally fumbled around with trying to get EPS running when I first stood up the system.  My goal was to enable secure transactions from my Trezor cold wallet via the Electrum Wallet application through my own Electrum server and Bitcoin full node.  Disabling walletbroadcast came from the EPS readme on Github: https://github.com/chris-belcher/electrum-personal-server (according to "Pro Tip2", disabling that setting would prevent the node from rebroadcasting transactions without Tor)


text:
Can more than 1 block be solved per 10 mins on average (LONG TERM)?
I am wondering whether it is possible for a supercomputer to find the next 1000 blocks in a very short amount of time. Hypothetically, if a government agency concentrated a supercomputer on hashing, could they solve the next 2016 blocks in a few seconds?

The difficulty is adjusted every 2016 blocks based on the time it took to find the previous 2016 blocks. At the desired rate of one block each 10 minutes, 2016 blocks would take exactly two weeks to find.

From what I understand from the article on the bitcoin.wiki, the difficulty would scale until 1 block is found every 10 minutes. This leads me to believe that in the long-term no more than 2016 blocks can be found at a rate of more than 1 per 10 minutes.
I  hope I am being clear. I will check for replies tonight.
Thank you so much.

someone /could/ throw a lot of hash power into the system. and until such a time as the difficulty adjusts, they /could/ produce more blocks than one per 10 minutes on average. but difficulty will adjust after one or more 2016-block chunks (note that change in difficulty is capped at a factor of 4 for each 2016 block chunk), until once again even with the new hash power only one block per 10 minutes is produced on average.
so "in the short term" it is possible for someone to produce more blocks than 1 per 10 minutes, but "in the long term" unless they continue adding hash power perpetually, the difficulty will catch up to them.

The control mechanism for keeping blocks at a rate of 1 per 10 minutes is very simplistic. What can and will happen is that the mechanism will perpetually play catch-up to the gradual increase of difficulty due to Bitcoin adoption and hardware advances.
For example, if the network hashrate increases by 1% per week (which is reasonably sustainable long-term due to Moore's law), the difficulty will always have an average 2 week lag over the hashrate, and thus blocks will be found 2% faster than 1 per 10 minutes, long-term.
If there was a PI controller this wouldn't happen.

TL;DR: The scenario described in OP is utterly unrealistic. Even a short term increase of solved blocks per minute requires tremendous amount of resources.
Current Bitcoin Network power is approximately 108 petaFLOPS. We can't compare 13.5 Tera Hashes/s with Flops directly, but casascius calculated rough estimate, 450G (hash/s) equals to 3.6 PFLOPS.
According to Wikipedia: On June 18, 2012, IBM's Sequoia supercomputer system, based at the U.S. Lawrence Livermore National Laboratory (LLNL), reached 16 petaFLOPS, setting the world record and claiming first place in the latest TOP500 list.
To solve one block under one second with current difficulty you would need approximately 64800 petaFLOPS. Or 4050 most powerful supercomputers.

Note that petaFLOPS is a measure of floating point performance. The hash calculations make minimal if any use of floating point operations. Instead they make use of integer math and logical operations. Some of the most efficient mining technologies use custom processors (ASICs) which perform the hashing operations in hardware.

@Crispy , that is correct and I did explain it in my answer

Bitcoin does, by design, readjust difficulty every 2,016 blocks to a level that is based on how long the previous 2016 blocks took to be solved.  The adjustment is intended to bring block generation back to the rate of one block every ten minutes.
There is an upper limit however to the amount of the difficulty increase so that the new level is no more than four times the previous level.
This has occurred once in Bitcoin's history -- at block 68,544, which followed Bitcoin's first exposure to tech media -- it got Slashdotted in July, 2010.

https://docs.google.com/spreadsheet/ccc?key=0AmcTCtjBoRWUdHVRMHpqWUJValI1RlZiaEtCT1RrQmc#gid=0

The highest increase following that was a near doubling that occurred in May 2011, when a flurry of press and media buzz was happening.
The highest increase since June, 2011 has been a 15% increase.
Currently there is about 17 Thash/s of capacity.  To be able to cause per-block generation to occur at the rate of one every five minutes by adding only the 25 Ghash/s BFL Mini Rigs would be something that would require about $10 million of hardware.  (Actually, this is not possible as BFL doesn't have the capacity ship even a tiny fraction of that level.)
The hardware cost to get 2,016 blocks in "just a few seconds" (say, 60 seconds) using just BFL Mini Rigs would be something in the range of $181 billion dollars (yes, that's correct -- 181 billion.)

This has already happened. Bitcoin blocks have been mined 6.9% faster than the "10 minutes per block" rule.
There have been 1.88e8 seconds since the start of Bitcoin. Given this, you would expect there to be 314,000 blocks. However, there are actually 335721 blocks at the time of writing. This is a difference of 6.9%.

In theory, yes, more than one block can be solved per 10 minutes on average, although that would require a constant growth in the computing resources. The Bitcoin protocol is created in a way so as to adjust its difficulty and aim to create on average a 6 blocks per hour. Thus no matter how much hardware you throw at Bitcoin, it will readjust itself to handle it and function normally.
One can create more than 2016 blocks at a time at rate greater than 1 per 10 minutes, provided enough resources are available. Having enough computing resources to launch a 51% attack, essentially more than everyone else on the Bitcoin network, one can create blocks with arbitrary timestamps (as long as they follow the protocol). Thus instead of creating blocks that are spaced say, 5 minutes from one another and forcing the network to double the difficulty in one go, you can make multiple of 2016 blocks spaced at say, 9 minutes apart. You can continue to do this until you run out of hardware, essentially creating more than 2016 blocks with an average time between then being less than 10 minutes. This scenario, however, is essentially a 51% attack and would require enormous amount of hardware and electricity to perform.
I hope this answers your question.

Yes, definitely, and in fact in actuality blocks are mined faster than 1 every 10 minutes. As of this writing, over the life of Bitcoin, blocks have been mined on average about 1 every 9 minutes 35 seconds. This is due to the backward-looking nature of the rate-limiting mechanism and the fact that total hashing power keeps increasing. There are other flaws with the rate-limiting algorithm under extreme conditions.
In practice, though, anyone with enough hashing power to exploit the flaws in the rate-limiting algorithm would probably have an easier and more profitable time exploiting other flaws in the system available to miners that have a substantial fraction of the mining power.

This leads me to believe that in the long-term no more than 2016
  blocks can be found at a rate of more than 1 per 10 minutes. I hope I
  am being clear.

I think you are probably not being clear.
Every time the difficulty rises, it means that the last 2016 blocks were found at a rate of more than 1 per 10 minutes.  And so, each time the difficulty rises twice in a row it means that more than 2016 blocks were found at a rate of more than 1 per 10 minutes.
It's quite conceivable that the difficulty will rise two months in a row multiple times in the future, and so the assertion I quoted is incorrect.
But I guess I misunderstood what you were asking.

Shouldn't it be "difficulty rises"? (3 places)


text:
Giving bitcoins to people as gifts
I am interested in buying bitcoins and giving bitcoins to babies as "birth gifts" and birthday presents.
Assuming I've purchased the necessary bitcoins and they are in my wallet, how do I go about giving bitcoins to someone who doesn't have a wallet?

Probably the most appealing way to do that would be by using Physical Bitcoins - they look nice as coins, and since they can hold Bitcoins, it's another bonus. It's definitely better for casual people than giving them Bitcoins in a normal way - at least coins are something they can physically grasp, rather than trying to understand what a cryptocurrency is.

This would be most beneficial to people who don't actually intend to use bitcoins. But if those people are your target, you'd better not send them bitcoins in the first place. Instead, if your target are people who will likely use them, @Chris' suggestions are better.

ThePiachu, those prices are really high.... are you aware of cheaper physical bitcoins? They just need to be physical and don't need to look so high-class.

@Pacerier If you want to go really cheap, try using paper wallets - https://bitcoinpaperwallet.com/ for example.

Casascius is not currently accepting new orders, so this is no longer a good option.

@CarlZulauf You can still buy them from other people, so it is a good answer. There are also other physical bitcoin manufacturers out there.

You can use Brainwallet to generate a new private/public key pair. Click on the "recycle" symbol near "Secret Exponent", write down the private key and send bitcoins to the given address.
The private key is the only thing needed to recover the bitcoins. You can print it on some pretty support, but make sure it cannot be copied by a third party. You can even keep an encrypted backup in case the private key is later lost.

BitAddress now has a Brain Wallet option.

http://www.BitAddress.org

Why would you trust a website to generate your private key?

In addition to other options, you can just print out a cool Dr Evil (or custom) styled paper wallet.

Here are two sites which allow you to send bitcoins to an email address.  Perhaps try sending yourself tiny amounts with each site to see how they work:

http://coinapult.com/
https://cowcoin.com/

These seem like exchanges with an email feature. Meaning you put BTC into their wallet, then they send it to the recipient.

An additional option are bitcoin gift cards/vouchers. They have the advantage that your recipients are already familiar with the concept - everyone knows that plastic cards with an amount on them are a store of value, and they know that they can redeem it by scratching off the field on the back (similar to iTunes gift cards).
bit4coin.net is one of the services offering bitcoin gift vouchers:

They have a decent explanation on bitcoin as well.


text:
Write down bitcoins on a piece of paper
I am a newbie when it comes to bitcoin. I am using the default bitcoint client and I have some bitcoins in my wallet. How can i write them down and give it to some one and then the person how can they use them
Is this possible ?

Related question: How to save bitcoins as paper

Here's a simple way to do it:

On bitaddress.org, use the "Paper Wallet" tab and create 1 address
Using your Bitcoin client, send an amount of bitcoins to the Bitcoin Address on the paper wallet
Print the paper wallet and give it to your friend
Tell your friend to create a wallet at My Wallet. He can then use the "import from paper wallet" feature and simply scan the QR code to import the bitcoins.

Please note that when handing over a private key "offline" like this both you and the receiver will have access to the funds if you keep a copy of the private key. The receiver has to trust you to not take advantage of that before he has had the chance to move the funds.
bitaddress.org by the way is a client side tool so you are not trusting them with your money, though you might want to read this: Should I trust bitaddress.org?

You can give them the private keys associated with given Bitcoin Address, but it's generally not the best way of transferring Bitcoins over. You ought to just make a regular Bitcoin transfer. Both of you would need to be using those for handling Bitcoins anyway, so this way would be identical to what you will be doing anyway.

I don't like 3-d party services for handling my money. That's why I use bitcoin so your answer is the best. But you can be more specific for a newbie how can I print the private keys and how to import them in the bitcoin client?I thnik manny users will find this useful

You generally don't need to import private keys if you want to receive money. You just create a completely new key, tell your friend the associated address and have her send coins there.

@opc0de If you want to use only the Bitcoin client, you need to use dumpprivkey Bitcoin API command, and your friend would have to use importprivkey. The process of setting this up would be a lot more complicated than just your friend giving you an address to send the Bitcoins to. Unless one of you is a programmer or at least knows how to write and run some code, it might be quite hard. Explaining all of that would make the answer quite lengthy and detract from its message I guess.

Create an Instawallet, send the funds you wish to pass to the bitcoin address for that Instawallet, and then just give the Instawallet URL to the other person.
The transfer payment from your wallet will need to confirm before the Instawallet balance will reflect the payment but once it does, those funds are available to anyone who knows that Instawallet URL.
There is a nearly identical service called EasyWallet.


text:
Buy bitcoins using google checkout
I want to buy a small amount of bitcoins using google checkout. Any service provider ?
Thanks

If Google Checkout is not a hard requirement, LocalBitcoins.com lists tons of payment methods https://localbitcoins.com/buy-bitcoins-online/usd/

Not really.
Buying Bitcoin Through Google Checkout:

Unsurprisingly, [neither] Apple nor Google will ever allow for digital currencies to be exchanged through their systems as a part of their TOS.

btcnow.net used to, but apparently Google put the kibosh on that some time ago.
fireduck asked in the Google Checkout/Wallet forums, but never really received an answer.
HOWEVER
Bitcoin Keys does digital delivery of private keys tied to accounts which have been loaded with the desired amount of BTC.
In my ~30 minutes of research on this, it's the only site I could find that does it in any way.
I have not personally used any of these sites, so I cannot vouch for them.

Google Checkout does not allow their service to be used for the sale of virtual currencies.
See the Google Checkout Program Policies and Guidelines.  Item 6 has a link to a page of content policies listing prohibited items.  (Somewhat confusingly, the latter page only mentions Google Wallet for Business and not Google Checkout.)  Under the "Financial" category, the list of prohibited items includes "transfers involving any virtual currency".


text:
Calculate a transaction version 2 ID
Been writing a bitcoin library from scratch, which eventually involves calculating transaction IDs.
Version 1 transactions work fine when their hex data is being SHA256'd twice and then reversed.
Version 2 transactions ids don't seem to work that way, according to data I found on block explorers. The IDs I generate never match.
Why?

The algorithm for computing txids is the same for version 1 and version 2. But is it possible that the v2 transactions you're looking at are segwit transactions? Because those do have a different hashing algorithm, see BIP141 and BIP144.

Take any V1 transaction in mempool.space, click Transaction hex, and then double-sha256 what you get, then reverse it... matches the ID in the URL. The same doesn't seem to apply for any v2 transaction... no idea why.

Recent transactions are likely segwit transactions. For those you need to drop the witness before hashing to obtain the txid. It has nothing to do with v1 or v2 however; either can be segwit or not.

Invaluable information, Pieter... thank you so much! Will take a good look a that.

Sure does, @RedGrittyBrick !


text:
Bitcoin Core VM and hardware SHA256
It has come to my attention recently that linux machines store info about their cryptographic capabilities in /proc/crypto.
A baremetal machine I have shows sha256_ssse3 in the sha256 module parameter, which apparently means that some CPU instructions directly computes hashes... Turns out, a VM running on that same machine displays kernel. Seems that might slow things significantly cause now, some software is doing that same task instead.
Can someone attest that those flags impact Bitcoin Core's performance directly?


text:
Requirements of own cryptocurrency?
What are the requirements and technologies I need for creating my own cryptocurrency?
How to assign value for my own coin?
For example:

1 bitcoin  = 279627.91 INR,
1 Litecoin = 2863.13 INR

You will need a lot of experience and knowledge in many areas including cryptography, networking, programming, economics, and a lot of research into cryptocurrencies themselves before you'll be able to make one yourself.
Values are not assigned by the developers, just by the market, it is supply and demand which raises and lowers the price.

Don't forget that he needs to be able to convince people to use it. Sure, he can have his own currency all by himself, but if he wants any sort of value attached to it, he would need a market. No currency has any value if there is only one person in the world who wants to own it.

When creating a new cryptocurrency, you must decide whether it will be a coin or a token. A coin exists on its own blockchain, while a token exists on an existing blockchain. The blockchain makes cryptocurrencies secure and decentralized.
Creating a token requires less experience and knowledge than creating a coin. Creating a coin usually requires a team of developers and experts. Creating a token also requires technical knowledge, but it can be created in minutes using blockchains such as Ethereum, Binance Smart Chain, Solana, and Polygon.


text:
UAHF implementing sighash, specifically, how are scriptCodes serialized?
I have managed to get correct sighashes for situations in which there are no OP_CODESEPARATOR ops in the code.  However, I cannot figure out, based on the UAHF documentation nor on the C++ code in the Bitcoin-ABC repository, how I am supposed to serialize the scriptCodes with the codeseparator OP.  Here is my serialization function (from the Picocoin C library):
void uahf_ser_scriptCode(cstring *s, const cstring *scriptCode){

    if(scriptCode == NULL){
        cstr_append_c(s, 0);
        return;
    }
    struct const_buffer it = { scriptCode->str, scriptCode->len };

    struct const_buffer itBegin = it;
    struct bscript_op op;
    unsigned int nCodeSeparators = 0;
    struct bscript_parser bp;

    bsp_start(&bp, &it);
    while (bsp_getop(&op, &bp)) {
        if (op.op == OP_CODESEPARATOR){
            nCodeSeparators++;
            fprintf(stderr,"code separator\n");
        }

    }

    if(nCodeSeparators == 0){
        ser_varlen(s, scriptCode->len);
        ser_bytes(s, scriptCode->str, scriptCode->len);
        return;
    }

    //ser_varlen(s, scriptCode->len - nCodeSeparators);
    it = itBegin;
    bsp_start(&bp, &it);
    int count = 0;
    cstring *x = cstr_new_sz(1024*10);
    while (bsp_getop(&op, &bp) && count < nCodeSeparators) {
        if (op.op == OP_CODESEPARATOR) {
            count++;
            //ser_bytes(s, itBegin.p, it.p - itBegin.p - 1);
            /*if(count == nCodeSeparators){
                ser_bytes(x, itBegin.p, it.p - itBegin.p - 1);
            }*/
            itBegin  = it;
        }
    }

    if (itBegin.p != scriptCode->str + scriptCode->len)
        ser_bytes(x, itBegin.p, it.p - itBegin.p);

    ser_varlen(s,  x->len);
    cstr_append_buf(s,x->str,x->len);
    cstr_free(x, true);

}

Not a full answer, but perhaps it helps you already: bcash's sighash scheme is basically identical to BIP143.

I finally figured out what I was doing wrong.  I just needed to include the OP_SEPARATORS when using the BIP143 scheme.

I probably was too eager to ask this question, though perhaps someone can take a look at how I implemented the solution in this pull request.  Here is the relevant code:
// from bp_tx_sigserializer function
void uahf_ser_scriptCode(cstring *s, const cstring *scriptCode){

    if(scriptCode == NULL){
        cstr_append_c(s, 0);
        return;
    }
    /** Serialize the passed scriptCode, skipping OP_CODESEPARATORs */
    struct const_buffer it = { scriptCode->str, scriptCode->len };
    struct const_buffer itBegin = it;
    struct bscript_op op;
    unsigned int nCodeSeparators = 0;

    struct bscript_parser bp;
    bsp_start(&bp, &it);

    while (bsp_getop(&op, &bp)) {
        if (op.op == OP_CODESEPARATOR)
            nCodeSeparators++;
    }
    cstring *x = cstr_new_sz(1024*8);

    it = itBegin;
    bsp_start(&bp, &it);

    while (bsp_getop(&op, &bp)) {
        if (op.op == OP_CODESEPARATOR) {
            ser_bytes(x, itBegin.p, it.p - itBegin.p - 1);
            itBegin  = it;
        }
    }

    if (itBegin.p != scriptCode->str + scriptCode->len)
        ser_bytes(x, itBegin.p, it.p - itBegin.p);

    if(0 < nCodeSeparators){
        cstr_free(x, true);
        x = cstr_new_sz(1024*8);
        cstr_append_buf(x,scriptCode->str,scriptCode->len);
    }
    ser_varlen(s, x->len);
    cstr_append_buf(s,x->str,x->len);
    cstr_free(x, true);
}


text:
Bitcoin transaction as been unconfirmed for 9 days
Please what can I do? I received a transfer of 0.559btc and it has remained unconfirmed for 9 days, I can't even find it again on the blockchain.info but it was there for almost 4 days. I can see the transaction here on tradeblock. I have alerted the company that made the transfer to me but their customer service is horrible. Please any help? Can I still get this deposit?
Also why did it disappear from blockchain.info?

When transactions are published to the network, they first are mere payment promises. You have received notice of a transaction on the network to one of your addresses. However, for the money to actually become signed over to you, transactions need to be confirmed by being included in a block of the Bitcoin blockchain.
Most nodes on the network track unconfirmed transactions on the network only for a few days before they drop them from their memory pool. For example in Bitcoin Core this timelimit used to be three days previously and is now fourteen days. It seems that blockchain.info dropped the transaction because it timed out of their memory pool.
To speed up confirmation of the transaction, you could try to construct a child-pays-for-parent transaction: you would send another payment from your wallet and spend the money that you would receive from the unconfirmed transaction. If you use Bitcoin Core, you can specifically select inputs by enabling the "coin control features" in the settings. Otherwise, you can enforce spending the unconfirmed transfer by spending your complete balance. Many recent wallets will then automatically generate a new transaction with a higher fee that should get both the parent and the new transaction confirmed.
Unfortunately, the only other options are

to wait it out
to request that the sender updates their payment with a higher fee.

In this particular case, I think that your transaction should soon go through, as there are currently only about 3MB of transactions above 240 satoshi/byte and the one that you're waiting for pays ~239.18 sat/B.


text:
How can I use the Litecoin testnet?
Is there any Litecoin testnet explorer which records Litecoin testnet transactions? Where can a Litecoin testnet wallet be downloaded? Any reference or step by step explanation would be much appreciated.

Download Litecoin Core, install it,  and start it with the -testnet option.
I'm aware of two Litecoin testnet explorers:

http://testnet.litecointools.com/
https://chain.so/testnet/ltc

This is only good for users who have 25GB to spare on their hard drive...  If you want to play around with the testnet create a wallet on https://block.io

@palebone: That would be a great start of your own answer! :)

doesn't look like I can answer with just my starting bonus rep

https://chain.so/ltc
https://chain.so/testnet/ltc
Litecoin testnet block explorer

I'm confused that this answer was accepted. The main question appears to be about getting a testnet wallet, which doesn't get covered here.


text:
Blockchain Explorer says received but it's not received yet!
I sent some Bitcoin to my friends wallet since 2 days ago. It says approved and sent successfully on my end. And even on blockchain Explorer it says confirmed and received. But my friend says he hasn't received any Bitcoin yet??? This is the transaction ID on blockchain Explorer
https://www.blockchain.com/btc/tx/d350a1334d10e7693b56cc8fd8d11297080e1aebd9ffed97588a4b5f0929ca93

Blockchain Explorer says received but it's not received yet!

That's not how Bitcoin works.
All computer-based wallets, including your friend's, have a copy of the blockchain (or have indirect access to a copy). If the blockchain includes your transaction, then the money has been received. All copies of the blockchain are eventually identical, only the last block or two might very occasionally differ for a short while.
Note that you can receive Bitcoin even if your wallet exists only as a secret number written on a piece of paper. The blockchain is the true record of what has been received.
If your friend says their wallet has not received the money there are at least three possibilities

They are lying
Their wallet has not got an up-to-date copy of the blockchain (i.e. is not "synchronised")
You sent the money to the wrong address somehow.

The transaction is confirmed. Make sure that you have sent to the correct address (your friend's address 37ZyDkjmMEkTVjeuLcjH3p5AQEZF5tpr1E).
If you are sure then your friend is trying to scam you because in transaction https://blockstream.info/tx/cb2b8b9fe545ba2705f9831e33417cdf3c4c749eb738cb359d3c3af4834b2768 the UTXO you sent to your friend has been spent.


text:
Why CBlockIndex does not store a vector of next blocks for forward iteration?
CBlockIndex stores a pointer to previous block..
Is there any specific reason why it does not store a vector of "next" blocks for forward iteration?
If you think, a typical tree (as data structure) has "parent" (pprev) and a list of "children".

Memory usage. Adding a vector to each of the (now over 600000) CBlockIndex entries would be a significant memory usage increase (at least 48 bytes per entry, to be precise, on stdc++ 64-bit platforms).
For most operations it's also unnecessary. Instead, CChain stores a pointer to all CBlockIndex entries in the main chain, allowing O(1) access to any of those. Also, using the skiplist mechanism (see pskip) in CBlockIndex it's possible to efficiently find the height N ancestor of any given block (in O(log n) or O((log n)^2), IIRC).

Why is it 48 bytes per entry? Shouldn't it be 8 byte per entry? (sizeof(void*))

A vector has an overhead of 3 pointers (begin of memory block, end of memory block, end of used portion of memory block). The memory block itself is dynamically allocated, which has malloc() overhead (16 to 31 bytes on x86_64 Linux, depending on rounding).


text:
What is the difference between chainstate and blocks folder?
Is the blocks and chainstate folder store the same blocks data ?
How can we read those data using code and display that on the web frontend like the blockchain explorer websites

Is the blocks and chainstate folder store the same blocks data ?

No, the blocks directory contains the actual blocks. The chainstate directory contains the state as of the latest block (in simplified terms, it stores every spendable coin, who owns it, and how much it's worth).

How can we read those data using code and display that on the web frontend like the blockchain explorer websites

No, you need transaction and address indexes for that. Bitcoin Core is not designed to provide those.

===>No, you need transaction and address indexes for that. Bitcoin Core is not designed to provide those.
*** how can we get transaction and address indexes from those 2 folders ?
*** Is there is any python library that allow us to  show that blocks data in meaning full ways e.g blockchain explorer ?

No, you need different software than Bitcoin Core.

ok , then how the blockchain-explorer websites display blocks data ?

By using software they wrote themselves generally, to index the Bitcoin blockchain.

https://github.com/bitpay/insight-api , this code from the bitpay explore all the blockchain  transactions ,  I am searching for any other library in python that allow the same functionality

blk00000.dat  , is this file represent single block with transactions  ?

@Pieter Wuille  -  " (in simplified terms, it stores every spendable coin, who owns it, and how much it's worth)"  Not sure about the "and how much it's worth" part. Are you sure about that? To my knowledge the bitcoin block-chain does not include any prices related to any existing currencies. Rather is will store the amount of bitcoin each public key is currently holding, but not the value in dollar or yen or any other currency. Would you care elaborating on your assumption please.

By "how much it's worth" I of course meant the amount expressed in BTC (or really satoshi's), not what that value in any local fiat currency corresponds to.

How can we read those data using code and display that on the web frontend like the blockchain explorer websites

I am searching for any other library in python that allow the same functionality

See if the STATUS, mentioned in the Analysis of the Bitcoin UTXO set 2018, would help?
"We have created STATUS (STatistical Analysis Tool for Utxo Set), an open source code tool that provides an easy way to access, decode, and analyze data from the Bitcoin’s UTXO set. STATUS is coded in Python 2"


text:
Why there duplicated transactions on the blockchain? (with different hashes)
I just found a couple of transactions that looks very similar, they have different hashes, but are exactly equal in everything else:
3d69534a43b4396faac62e84ba6092d539335dd1c6601da626020f69082280c1 (mempool)
39956e4b81c8c2e8071839cb3d3c92ab2d0f566b0eba9b65474138eec214cd80 (mempool)
Both transactions are on the same block (816,015) and have the same details:

Size: 312
Coindays destroyed: 0
Weight: 561
Fee: 0.00000546BTC
Send from: bc1pl2sxa9fujpjk5km840jnqrp5xn57dxezfgsftnqsxaa39x7qkh5sn0k3w3 (0,00033681 BTC)
Received: 3Dvp6Vt5G2xZPP1DDUeSap9MXuLuXY2hpu (0,00000546 BTC)

Those addresses seems to be testing something weird, but I cannot understand what... can someone explain what could be happening there?
Obviously, the main question is how could we be sure that it is not creating new coins, as I cannot understand which output they are spending, as they are using taproot.

Transaction outputs (TXOs) are uniquely identified by their outpoint. Each TXO can only be spent once. While these two transactions spend funds received to the same output script, they are spending different transaction outputs. So, they do not create new bitcoins, they do appear to be creating some BRC20 tokens, though.
Tx 3d69…80c1 spends
txo 2821…fe1f:0.
Tx 3995…cd80 spends txo 2821…fe1f:1.
Both TXOs were created by the same preceding transaction 2821…fe1f, which in total created 24 outputs with the same output script (and one change output). The transactions all appear to be minting some BRC20 token.

For some reason, I cannot find any block explorer that shows the txo being spend (2821…fe1f:0 for example).

The one I linked to, Blockstream.info does: https://i.imgur.com/PwFOtzs.png

These are BRC-20 mint transactions.
If you look at any of the inputs, you can see it is a Taproot script path spend that includes an unexecuted branch with several data pushes, the first of which pushes the three bytes 6f7264 (UTF-8 for "ord"). This is what the Ordinals protocol uses for its so-called "Inscriptions", a way to add arbitrary data to the blockchain.
If you look even closer, you may try to decode the last data push as UTF-8:
{"p":"brc-20","op":"mint","tick":"piin","amt":"1000000"}

This is what the BRC-20 protocol uses. BRC-20 is a protocol for creating and transferring tokens on top of Bitcoin. Being as inefficient as it is, it requires a lot of onchain transactions for its operation, which is the main reason for the current spike in Bitcoin's transaction fees (and for the similar spike in May earlier this year).


text:
Programming a solution to know when a Bitcoin Address has stored a target amount
Sorry, I'm probably not going to use the correct terms here.
Does anyone know of, or how to use bitcoind (or of an external library) that can look at or even provide event driven mechanisms to monitor when an address has received equal to or more than a target amount.
I know of the websocket API available from blockchain but I'd ideally do it in house using my own systems if possible.

see also: Push deposit notification through HTTP requests

A rough solution:
If the account is in your wallet, you can use:
bitcoind getreceivedbyaddress "ADDRESS"
to get the amount of bitcoins received by ADDRESS. You can put that line inside an infinite loop. You could create a shell program which stores the result in a variable every 30 seconds (using sleep) and compare it to the previous value. If you subtract the values and find a difference above a threshold you can make the script alert you.
I can be more specific if you tell me your preferences (Python, Linux shell...)

I'm assuming that won't scale that well for a massive system though?

By massive do you mean with many addresses? In that case you might just check each new block for your addresses. You can use getblock and bitcointools https://github.com/gavinandresen/bitcointools. By the way, the 30 seconds wait time is overkill. If you want confirmed transactions (or transactions that are at least in one block), on average the changes take 10 minutes.

Well ideally I want to create a new address, wait until it has a set amount of bitcoins in that address and then transfer the coins and close the address down, doing this for hundreds if not thousands of addresses at a time

I would go for a script calling bitcoind. Or a custom program in Python with bitcointools. I don't think the operations are that complicated. A regular processor should be enough. In any case it seems you will need a bit of work.


text:
Bitcoin Transaction unknown address input and output!
During the Bitcoin transactions, there are one time use address are generated in order to handover change inside wallet that shift the change from lower blocks to higher blocks (According to some Bitcoin related articles). As far as I have understood that it is normal procedure like change payment in return!
We have implemented Bitcoin pay system for our Decentralized Autonomous Organization project. To be able to prove DAO members payment, I need to check per each members address and how much they paid. The unknown transaction which I have tried to explain above creates consequences to verify DAO transactions' overcome this problem to extract that address whether he/she is DAO members address or not!
in DAO mechanisms the theory; Third parties verifies the payment if the payee list get it or not. The transaction input and outputs; senders, receivers and the amount in the receiver list used as proof of payment.
In reality ; transaction input and outputs; senders, receivers and the amount in the receiver list used as proof of payment. But the unrecognized address which I mentioned above pays and receives appears from the senders list and receivers list too not belongs to DAO members addresses. So it creates a conflict and trust related problems in DAO. Despite the transaction not visible in Bitcoin ore wallet but visible in bitcoin block explorer services!
In conclusions; the our verification system spoiled by this unknown address which we did not ask it to do transaction!
Questions :

Is it possible to disable that process asset shifting procedure from lower blocks to higher blocks?
if possible, what could be the consequences the wallet face?
What are those internal change mechanisms serves for?
If not possible to disable the process, the automatically generated address control and verification is possible inside the bitcoin core?

Post the ChatGtp`s comment below; Could you verify if true and what could be the new method to identify those addresses by verifiers?
-----Relaying to my questions Chat GTP answer and descriptions -----
Based on your description, it sounds like the issue you're facing is related to change addresses in Bitcoin transactions. Change addresses are automatically generated by Bitcoin wallets as a way to handle the change that is generated when someone sends a Bitcoin transaction that is larger than the amount they actually want to send. The remaining funds are sent to a new address in the same wallet, which is usually generated on the fly and is used only once.
To answer your questions:
It is not possible to disable the process of using change addresses in Bitcoin transactions, as it is a fundamental part of how the Bitcoin protocol works. If change addresses were disabled, it would make it much more difficult to use Bitcoin as a currency, as it would be harder to handle transactions where the amount being sent is not an exact match for the funds available in a given address.
If change addresses were disabled, it could have significant consequences for the usability of the Bitcoin network. It would make it harder for people to use Bitcoin as a currency, and it would likely lead to a decrease in the number of transactions being processed on the network.
The internal change mechanisms that create change addresses are designed to help manage Bitcoin transactions more efficiently. By automatically generating a new address to handle the change in a transaction, it makes it easier for wallets to manage their funds and reduce the chances of errors or lost funds.
It is not possible to control the generation of change addresses within the Bitcoin Core software, as it is a fundamental part of how the Bitcoin protocol works. However, you may be able to use third-party tools or services to help you track and verify transactions that involve change addresses. You could also consider implementing additional verification processes within your DAO project to help ensure that only trusted addresses are used for transactions.

for those information's above I need to redesign verification process to identify the change per each transaction and prove the members. However we get information from Bitcoin Core wallet using RPC. It does not provide change address information, but can be seen sometime if change returns.
Many Thanks!

It's unclear what your question is, but it seems specific to the logic of your DAO and not specific to Bitcoin, which is off-topic for this forum. Can you provide a specific example and detail what part of the Bitcoin protocol you are having trouble understanding?

Hi Josie,
Thanks for your response, but it is not off the topic, but the way of my explanation might cause misunderstanding.  I will edit the main question, however.
The real question is, during the transactions using bitcoin core, one time use unknown address are created which is invisible to wallet owners but can be seen in bitcoin blockchain explorer. As I have learned it is sometimes happens is like to settle account, getting values from lower blocks to shift on higher levels. That's why it happens.

Those, unknown transactions causing misunderstanding by the clients if we use in pay processing or like our case, we have a member groups that they provide payments to be used in a pool in DAO. However those unknown random generated addresses per transaction confuses and creating doubts for members.
My Questions:

How to stop those unexplained wallet generation, if possible!
What could be consequences if we stop those process that I don`t know the name.
If it is indispensable process, how to identify or manually control them to explain in the system in transparency?

I'm still having trouble understanding your question, but generally, Bitcoin addresses should never be reused when transacting. Also, in most cases, a transaction will have two outputs: one for the recipient and the other for change sent back to the sender's wallet. Bitcoin has no concept of accounts and Bitcoin addresses should not be used as stable identifiers.

Thanks josie,
I have also asked ChatGTP the same question he summarize what my problem is:
"Based on description, it sounds like the issue you're facing is related to change addresses in Bitcoin transactions. Change addresses are automatically generated by Bitcoin wallets as a way to handle the change that is generated when someone sends a Bitcoin transaction that is larger than the amount they actually want to send. The remaining funds are sent to a new address in the same wallet, which is usually generated on the fly and is used only once."

As far as I know almost all cryptocurrency exchanges provides deposit wallets to reuse hundredths of times. Since we desire to have transparent transactions, each member would have unique address that should be reuse from the idea.
As I have seen in bitcoincore, also recommends per each transaction new address. But it makes harder to identify transactions in DAO and impossible to use bitcoin as payment system for us.

Since all transactions visible in blockchain and explorers, and all assets protected by simple passphrase in the wallet (unless the person expose his wallet.dat file)  I see them in the same level of security whether generate new address per each transaction or not! It might only reduce the risk of loss amount of someone able to success by brutal force to reveal our private keys!

It is not a matter of security, but of privacy. Address reuse is detrimental to user privacy and should be avoided.

TL;DR: Recipients should completely ignore change outputs of transactions.

Is it possible to disable that process asset shifting procedure from lower blocks to higher blocks?

I think you are probably describing the change output of a transaction. It isn't possible to disable change entirely and most wallets generate a new change "address" for each transaction. As a recipient you should not be concerned at all about change - you should ignore change.
A transaction output for returning change does not constitute a "process asset shifting procedure from lower blocks to higher blocks" -- That seems a bizarre view and a change transaction might occur in the same block that contains the earlier transaction which generated the input amount - so there is no explicit asset shifting between blocks of the blockchain by transactions.

if possible, what could be the consequences the wallet face?

No one would use a wallet which does not return change.
Fewer people would use a wallet that fails to protect their privacy in well-established ways such as avoiding address reuse.

What are those internal change mechanisms serves for?

If I use a $20 banknote to buy a $12 pizza I expect to get $8 back in change.
I don't want the pizza vendor to be able to work out how much money I have in my pocket, under my mattress and in the bank.

If not possible to disable the process, the automatically generated address control and verification is possible inside the bitcoin core?

I think the answer is yes but it is hard to be sure because the question looks a bit like word soup and so I find it hard to work out what it is you are asking.
Bitcoin core and other modern wallets do indeed automatically generate new change addresses for each transaction. This was a deliberate improvement
Bitcoin core and other wallets always verify/validate all blockchain data to the fullest extent possible.

Thank you very much for detailed explanation!


text:
Create and spend P2WSH that locks coins with OP_CHECKLOCKTIMEVERIFY
I'm attempting to create a P2SWH address with a script that locks the coins for some time. And then I want to spend those coins from that address.
I've read a lot, some of the most relevant:

BIP173
Segwit dev guide
Constructing a P2WSH address from the BIP173 spec
Generate P2SH-P2WSH

These are the steps I've taken. Where am I going wrong?

Create an address to be locked

bitcoin-cli -regtest -getnewaddress
bcrt1q45rq22tegkfu4sl9tfhty6svvkyaj6q4wu43fs

Get the pubkey

bitcoin-cli -regtest getaddressinfo bcrt1q45rq22tegkfu4sl9tfhty6svvkyaj6q4wu43fs
{
  "address": "bcrt1q45rq22tegkfu4sl9tfhty6svvkyaj6q4wu43fs",
  "scriptPubKey": "0014ad060529794593cac3e55a6eb26a0c6589d96815",
  "ismine": true,
  "solvable": true,
  "desc": "wpkh([10304ad5/84'/1'/0'/0/0]0340469e0bd5cca35c04bcee20e203f8fe601b69d73793b493fe92900e620b67d8)#52elxezw",
  "parent_desc": "wpkh([10304ad5/84'/1'/0']tpubDDr5yrdp9CqDy4qv2Waa1Z5aeQUzQh4Rxs84XyT8vHXTNKEaR6rDhTY56sSYC4vBdbKj1fHbwEPuimcu1yY3RSN8u1RvSREdyAUEDmfWzFv/0/*)#82xg44pv",
  "iswatchonly": false,
  "isscript": false,
  "iswitness": true,
  "witness_version": 0,
  "witness_program": "ad060529794593cac3e55a6eb26a0c6589d96815",
  "pubkey": "0340469e0bd5cca35c04bcee20e203f8fe601b69d73793b493fe92900e620b67d8",
  "ischange": false,
  "timestamp": 1679657480,
  "hdkeypath": "m/84'/1'/0'/0/0",
  "hdseedid": "0000000000000000000000000000000000000000",
  "hdmasterfingerprint": "10304ad5",
  "labels": [
    ""
  ]
}

Convert pubkey into pubkeyhash

echo -n 0340469e0bd5cca35c04bcee20e203f8fe601b69d73793b493fe92900e620b67d8 | xxd -r -p | openssl dgst -sha256 -binary | openssl dgst -rmd160
ad060529794593cac3e55a6eb26a0c6589d96815

Get little-endian hex of timestamp for 1 March 2023 (1677628800)

printf '%x\n' 1677628800 | fold -w2 | tac | tr -d "\n"
8095fe63

Create script using btcc from btcdeb

btcc 8095fe63 OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 ad060529794593cac3e55a6eb26a0c6589d96815 OP_EQUALVERIFY OP_CHECKSIG
048095fe63b17576a914ad060529794593cac3e55a6eb26a0c6589d9681588ac

Get ScriptHash

echo -n 048095fe63b17576a914ad060529794593cac3e55a6eb26a0c6589d9681588ac | xxd -r -p | openssl dgst -sha256
5ef75077ffb6e6d533f4245d1ece3c6034ea315db818906dfb49a643e27068fb

Decode script to check and get P2WSH (or could compute)

bitcoin-cli -regtest decodescript 048095fe63b17576a914ad060529794593cac3e55a6eb26a0c6589d9681588ac
{
  "asm": "1677628800 OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 ad060529794593cac3e55a6eb26a0c6589d96815 OP_EQUALVERIFY OP_CHECKSIG",
  "desc": "raw(048095fe63b17576a914ad060529794593cac3e55a6eb26a0c6589d9681588ac)#snjtcwv8",
  "type": "nonstandard",
  "p2sh": "2N6zwcmxWbwkcVRwY275T8UXJ9mR9AtFaQo",
  "segwit": {
    "asm": "0 5ef75077ffb6e6d533f4245d1ece3c6034ea315db818906dfb49a643e27068fb",
    "desc": "addr(bcrt1qtmm4qallkmnd2vl5y3w3an3uvq6w5v2ahqvfqm0mfxny8cnsdrashv8fsr)#afsheh6p",
    "hex": "00205ef75077ffb6e6d533f4245d1ece3c6034ea315db818906dfb49a643e27068fb",
    "address": "bcrt1qtmm4qallkmnd2vl5y3w3an3uvq6w5v2ahqvfqm0mfxny8cnsdrashv8fsr",
    "type": "witness_v0_scripthash",
    "p2sh-segwit": "2N5EceqhW9HtQxRnL8qRCscz8Udv9P3bvwT"
  }
}

Send some coins to address (and then generate some blocks to confirm txn)

bitcoin-cli -regtest -named sendtoaddress address="bcrt1qtmm4qallkmnd2vl5y3w3an3uvq6w5v2ahqvfqm0mfxny8cnsdrashv8fsr" amount="1.0" fee_rate=1.0
3259e33b721664a5aadae575a6870d1c26750cad789925f7df0282ac1a76f75c

Above txn decoded
{
  "txid": "3259e33b721664a5aadae575a6870d1c26750cad789925f7df0282ac1a76f75c",
  "hash": "30e06e1c9b41029638e2d4e8f3e7813193299840f2333d61a4ddf244201723cb",
  "version": 2,
  "size": 246,
  "vsize": 165,
  "weight": 657,
  "locktime": 241,
  "vin": [
    {
      "txid": "47495befacd402d9f73f6ba8148e434fa6bf1d1957b87524fef41d8fdea409e4",
      "vout": 0,
      "scriptSig": {
        "asm": "",
        "hex": ""
      },
      "txinwitness": [
        "30440220181c3f5b2144f4e11eb8fc6b4a996e530774936fb2de21f5d85db42928a003f002205065e3ccbf29978545bdf9088de8100f851f04026766c23a37b519a7fc104a4201",
        "022e6433df12239f3cce79c9260fa8394d53902f05d017e86ff430108cdfecc54e"
      ],
      "sequence": 4294967293
    }
  ],
  "vout": [
    {
      "value": 48.99999835,
      "n": 0,
      "scriptPubKey": {
        "asm": "1 063ae126ecdab401ee960d7431b0eff76c1c28986133f84d285c4ef988270552",
        "desc": "rawtr(063ae126ecdab401ee960d7431b0eff76c1c28986133f84d285c4ef988270552)#83pfucst",
        "hex": "5120063ae126ecdab401ee960d7431b0eff76c1c28986133f84d285c4ef988270552",
        "address": "bcrt1pqcawzfhvm26qrm5kp46rrv807akpc2ycvyelsnfgt380nzp8q4fqf67ehv",
        "type": "witness_v1_taproot"
      }
    },
    {
      "value": 1.00000000,
      "n": 1,
      "scriptPubKey": {
        "asm": "0 5ef75077ffb6e6d533f4245d1ece3c6034ea315db818906dfb49a643e27068fb",
        "desc": "addr(bcrt1qtmm4qallkmnd2vl5y3w3an3uvq6w5v2ahqvfqm0mfxny8cnsdrashv8fsr)#afsheh6p",
        "hex": "00205ef75077ffb6e6d533f4245d1ece3c6034ea315db818906dfb49a643e27068fb",
        "address": "bcrt1qtmm4qallkmnd2vl5y3w3an3uvq6w5v2ahqvfqm0mfxny8cnsdrashv8fsr",
        "type": "witness_v0_scripthash"
      }
    }
  ]
}

Create a new address to send to and define some variables, then create raw txn

LOCKTIME=247
OUT_ADDR=bcrt1qmydu04snguq9lrtg9rmenu4dvx0zzlefdtpe8p
OUT_AMNT="0.998"
IN_TXID=3259e33b721664a5aadae575a6870d1c26750cad789925f7df0282ac1a76f75c
IN_VOUT=1

bitcoin-cli -regtest -named createrawtransaction inputs='[{"txid":"'$IN_TXID'", "vout":'$IN_VOUT'}]' outputs='[{"'$OUT_ADDR'":'$OUT_AMNT'}]' locktime=$LOCKTIME replaceable=true
02000000015cf7761aac8202dff7259978ad0c75261c0d87a675e5daaaa56416723be359320100000000fdffffff01c0d3f20500000000160014d91bc7d61347005f8d6828f799f2ad619e217f297e022500

Create scriptpubky: OP_HASH160 hash160(redeemScript) OP_EQUAL
redeemScript is 0200 + scripthash (I'm not too sure about this step...)

echo -n 00205ef75077ffb6e6d533f4245d1ece3c6034ea315db818906dfb49a643e27068fb | xxd -r -p | openssl dgst -sha256 -binary | openssl dgst -rmd160
838403567aa049ada65f944d0a2a320d7b93e7ee
# combine rest of script hex
A914838403567aa049ada65f944d0a2a320d7b93e7ee87

More variables and attempt to sign raw txn

TX_DATA=02000000015cf7761aac8202dff7259978ad0c75261c0d87a675e5daaaa56416723be359320100000000fdffffff01c0d3f20500000000160014d91bc7d61347005f8d6828f799f2ad619e217f29f7000000
WITNESSCRIPT=048095fe63b17576a914ad060529794593cac3e55a6eb26a0c6589d9681588ac
SCRIPTHASH=5ef75077ffb6e6d533f4245d1ece3c6034ea315db818906dfb49a643e27068fb
REDEEMSCRIPT=00205ef75077ffb6e6d533f4245d1ece3c6034ea315db818906dfb49a643e27068fb
SCRIPTPUBKEY=A914838403567aa049ada65f944d0a2a320d7b93e7ee87

bitcoin-cli -regtest -named signrawtransactionwithwallet hexstring=$TX_DATA prevtxs='[{"txid":"'$IN_TXID'","vout":'$IN_VOUT',"redeemScript":"'$REDEEMSCRIPT'","scriptPubKey":"'$SCRIPTPUBKEY'","witnessScript":"'$WITNESSCRIPT'","amount":"'$OUT_AMNT'"}]'

error code: -22
error message:
Previous output scriptPubKey mismatch:
0 5ef75077ffb6e6d533f4245d1ece3c6034ea315db818906dfb49a643e27068fb
vs:
OP_HASH160 838403567aa049ada65f944d0a2a320d7b93e7ee OP_EQUAL

Based on that error, it seems to be expecting the redeemscript, so I give that a try and get a different error:
bitcoin-cli -regtest -named signrawtransactionwithwallet hexstring=$TX_DATA prevtxs='[{"txid":"'$IN_TXID'","vout":'$IN_VOUT',"redeemScript":"'$REDEEMSCRIPT'","scriptPubKey":"'$REDEEMSCRIPT'","witnessScript":"'$WITNESSCRIPT'","amount":"'$OUT_AMNT'"}]'
{
  "hex": "02000000015cf7761aac8202dff7259978ad0c75261c0d87a675e5daaaa56416723be359320100000000fdffffff01c0d3f20500000000160014d91bc7d61347005f8d6828f799f2ad619e217f29f7000000",
  "complete": false,
  "errors": [
    {
      "txid": "3259e33b721664a5aadae575a6870d1c26750cad789925f7df0282ac1a76f75c",
      "vout": 1,
      "witness": [
      ],
      "scriptSig": "",
      "sequence": 4294967293,
      "error": "Witness program was passed an empty witness"
    }
  ]
}

Looking at the decoded hex of this incomplete txn, I see there is no witness data. Am I supposed to be supplying that? I'm probably getting something wrong along the way, but not sure what.

It looks like you're trying to create and spend from a P2WSH (Pay-to-Witness-Script-Hash) address with a time-lock condition.  I'll highlight where there might be issues or confusion, as well as how to resolve them.
1. Script Construction
You correctly generated a P2WSH script that uses OP_CHECKLOCKTIMEVERIFY (CLTV) to lock the coins until a certain time.
The script you're using is:
048095fe63b17576a914ad060529794593cac3e55a6eb26a0c6589d9681588ac

This translates to:

8095fe63: The locktime (timestamp for 1 March 2023 in little-endian format).
b175: OP_CHECKLOCKTIMEVERIFY and OP_DROP.
76a914ad060529794593cac3e55a6eb26a0c6589d9681588ac: P2PKH part of the script (OP_DUP OP_HASH160 <pubkeyhash> OP_EQUALVERIFY OP_CHECKSIG).

This script seems correct for locking coins with a CLTV condition.
2. Generating the Address
You computed the correct witness script hash (P2WSH) for the locking script:

5ef75077ffb6e6d533f4245d1ece3c6034ea315db818906dfb49a643e27068fb.

This P2WSH can be verified by the output of the decodescript command and the address you generated:

bcrt1qtmm4qallkmnd2vl5y3w3an3uvq6w5v2ahqvfqm0mfxny8cnsdrashv8fsr is the correct P2WSH address.

So, this part of the process looks correct.
3. Sending Funds to the Address
You successfully sent 1 BTC to the P2WSH address (bcrt1qtmm4qallkmnd2vl5y3w3an3uvq6w5v2ahqvfqm0mfxny8cnsdrashv8fsr), and the transaction seems confirmed.
4. Spending from the Time-Locked Address
Here's where the complexity increases, as spending from a CLTV-locked P2WSH requires meeting specific conditions:

Locktime in Transaction: The nLocktime of the transaction must be set to a value greater than or equal to the locktime in the script (i.e., 1677628800).
Sequence Number: The input's sequence number must be less than 0xFFFFFFFF (which you correctly set to 4294967293), indicating that the input is allowed to be spent according to locktime rules.
Witness Stack: To spend the P2WSH output, the witness stack must include:

The signature for the public key.
The public key.
The locking script (048095fe63b17576a914ad060529794593cac3e55a6eb26a0c6589d9681588ac).

Key Areas to Check:

Locktime Mismatch: The nLocktime in your raw transaction is set to 247:
02000000015cf7761aac8202dff7259978ad0c75261c0d87a675e5daaaa56416723be359320100000000fdffffff01c0d3f20500000000160014d91bc7d61347005f8d6828f799f2ad619e217f297e022500

However, the locktime in your script is 1677628800, so you need to set the locktime of the transaction to at least 1677628800 (March 1, 2023). Without doing this, the transaction will be invalid because the nLocktime doesn’t meet the script's requirement.

Creating the Correct Witness Data: For spending from a P2WSH address, you need to provide the correct witness data:

The first element is the unlocking signature.
The second element is the public key.
The third element is the actual script itself (which includes the OP_CHECKLOCKTIMEVERIFY part).

Raw Transaction Creation:

When creating the raw transaction, make sure you include the witness program for the script and use the correct nLocktime in the transaction.

Redeem Script Confusion: You mention a redeem script (which is used in P2SH-P2WSH), but you're working directly with a P2WSH. If you were using P2SH-P2WSH, you would need a redeem script to "reveal" the P2WSH. Since you're using native P2WSH, you don't need a redeem script. The witness data directly includes the locking script.

Suggested Fixes:

Set Correct nLocktime: When creating the spending transaction, set nLocktime to 1677628800 or a later block.
Example:
bitcoin-cli -regtest -named createrawtransaction inputs='[{"txid":"'$IN_TXID'", "vout":'$IN_VOUT'}]' outputs='[{"'$OUT_ADDR'":'$OUT_AMNT'}]' locktime=1677628800 replaceable=true

Create Correct Witness:
Ensure the witness field contains the signature, public key, and locking script.

Include Locking Script: When constructing the witness for the spending transaction, use the full locking script (048095fe63b17576a914ad060529794593cac3e55a6eb26a0c6589d9681588ac) as the last element.

Summary of Process:

Locking Transaction: You correctly created a P2WSH address that locks coins with OP_CHECKLOCKTIMEVERIFY. The transaction that sent coins to this address is also correct.
Spending Transaction: Ensure the spending transaction’s nLocktime matches or exceeds the locktime in the locking script. Construct the witness correctly when spending, including the signature, public key, and the locking script.


text:
Can nodes that did not finish IBD import mempool using the importmempool rpc?
Sometimes you might want to experiment with the mainnet mempool but unfortunately  your node has to finish IBD up to the latest chaintip for you to fill up your mempool.

Looks like the answer is in the question?

I’m not sure. I think that nodes will not ask for unconfirmed transactions from peers until they’ve caught up to the chaintip, but they might be able to use importmempool. I think that’s what the question is about.

Yes using the importmempool rpc

Do you mean can a node which has not finished IBD import a current mempool with importmempool (as in a mempool from a point in time far in the past compared to what the node is synchronized to)? If so, no, because all the mempool's transactions will be invalid (the importmempool RPC will succeed, but it won't actually import anything).

Ah, that’s a good point. Only transactions for which your node already knows about the UTXOs that the inputs are spending and the timelock has been reached will be valid.

It seems to me that you should be able to make the importmempool call, but given that most transactions would probably be spending fairly young UTXOs, I would expect that almost all transactions would end up in the orphanage rather than the mempool due to spending unknown UTXOs.
I have not tried, it seems also possible that importmempool would just be outright disabled during IBD.


text:
How does one create a blockchain snapshot (vs a bootstrap)?
I have read How to create a blockchain snapshot for a hardfork? but it does not answer this question.  I understand the bootstrap.dat file is basically a concatenation of the blk000x.dat files, but the snapshot is integrated into a wallet faster.
I am surprised this question is not already asked and answered here as there are several mentions about the use of a snapshot in various answers  to other questions.


text:
Using Bitcore API for Escrow
Has anyone experience using the Bitcore API for Escrow purposes with node.js?
I assume, you'd need to create a new a address, then somehow create a new transaction using the newly created address, the probe that address for it's balance until its fulfilled.  I've had a look over the docs, but couldn't find anything.  Currently you can run bitcoind on a server and connect to this using RPC, but I'd like to try using Bitcore instead but achieve the same result.
Thanks.

Great question!
I'd take a look at multi-sig construction in Bitcore, and pair this with bitcore-wallet-service.  Some combination of these two items, with an agent to act as a signatory for a third key, would build a powerful escrow service in very short order.


text:
Bitcore Testnet API
Does anyone know if Bitcore offer a testnet API to play around with?
I'm implementing an Escrow system using the API and Node.js
Thanks.

I figured this out, you need to set the default network after you instantiate bitcore.
var bitcore = require('bitcore');

// Set the network to testnet
bitcore.Networks.defaultNetwork = bitcore.Networks.testnet;

It seams this does not work anymore. bitcore.Networks is now bitcore.networks and bitcore.networks.defaultNetwork = bitcore.networks.testnet throws Error: Cannot find module './build/Debug/buffertools.node'

This is no longer supported I think.

I had to mess around with this until I got it. Kinda silly it wasn't any where in the docs...
This is via Typescript
import * as bitcore from 'bitcore-lib'

bitcore.Networks['defaultNetwork'] = bitcore.Networks['testnet']

Close bitcoind and then start bitcoind in a terminal or bash shell like so:
"bitcoind -testnet" Using that should cause bitcoin to use a test network.
Although on windows you might need to find the bitcoind.exe and execute that if the command bitcoind is not added to the system path.
This information was retrieved from bitcoin's core using "bitcoind -help" and a quote from it says "-testnet   Use the test network"

Bitcore != Bitcoin core FWIW

I asked about Bitcore not bitcoind...


text:
Using bitcore to create a transaction with two addresses and change address
I'm playing around with bitcore transactions and multi-sig transactions and was wondering how to send a transaction to more than one address, and keep the change.
Currently when I try to send the transaction it is sent, but the fee is calculated as:
unspent - satoshis
An example of this transaction I've made in the block chain can be seen here:
Example Transaction
Ad you can see it's calculated like this:
Original unspent amount: 0.09000000
Fee: 0.08990000
Traded: 0.00010000
Transaction sum: 0.00010000
Now I understand that one must spend all of the unspent outputs in a transaction, but how can I stop the fee from being as above, the remaining unspent balance?
Basically I want to split the transaction for two addresses, and send the rest to a change address.
Code:
var utxo = new bitcore.Transaction.UnspentOutput({
  "txid" : "f42af6ab8b4dc3c636c5bfc6ce819063a55060c5619d31a6fa45a36413cb7953",
  "vout" : 0,
  "address" : "2MzuRYCXSHcBDEsSS4rziShvEzWSfoDe2zL",
  "scriptPubKey" : "OP_HASH160 20 0x54025426880aa847ec86f4d2488bbe260bfe0fcb OP_EQUAL",
  "satoshis" : 10000
});

var pubs = [
    "02758b89e56bfa8da41f2c1701aa5927bc026cc3b51bbeff399c53a15f2ae52e28",
    "02987ab3466118bd3fb5cb0c4fddbdd7ff8e21188314ffed4ecad83fb7689d57d7",
    "037b7f8cea06cfd5a96023341441b52431e31867c6f3716e5f20be24b709d023eb"
];

var multiSigTx = new bitcore.Transaction()
    .from(utxo, pubs, 2)
    .to("n1fqBkX6GtUsaV3EPqjpHcTuWhAQQgKXov", 10000)
    .fee(5430)
    .change("2MzuRYCXSHcBDEsSS4rziShvEzWSfoDe2zL")
    .sign(["083b63f9dbaa100c1714e05a04c20ab32f83f7726ba54a682013a13df6a92949" ,"5bef634cdcc7f9c2fd2b429d1ddf6cae56923433b6e8b2c5515cf87d84751e0a"]);

var txSerialized = multiSigTx.serialize(true);

// Broadcast

insight.broadcast(txSerialized, function(err, returnedTxId) {
  if (err) {
    console.log(err);
  } else {
    console.log("Sent coins, tx id is: ");
    console.log(returnedTxId);
  }
});

I figured this out, the new transaction code should look like this with the address generated using fromString() method using bitcore.
var address = bitcore.Address.fromString('2NEvGYDNxcVPZ2ThtmPKYoKBCEa3aJNjPL3');
var multiSigTx = new bitcore.Transaction()
    .from(utxo, pubs, 2)
    .to("mntnnj64W4po96m2ck4GXQJTAiKZQChpWB", 10000)
    .to("msR1bBwUWjTTNYFU5UTVNCXDUnEx1y2MMQ", 10000)
    .fee(5430)
    .change(address)
    .sign(["7e925007e09447fa6160597391d7a24f8f47e40222d6c94b06bd9cecee5eddff" ,"6b8adfd22b8dd3186ea5333602b39a59fc1c40c543dc3848ea88c6cd6b738594"]);

var txSerialized = multiSigTx.serialize(true);

This will then show the correct change output for the transaction.
console.log(multiSigTx.getChangeOutput());

with this you send 10000 Satoshis to each of the two different addresses? How could we send an amount (10000 Satoshis) to an Array of addresses?