text:
Trust Wallet Watch Only Wallet
I have been doing bitcoin trading using a trader and they have sent me my profits to my Trust Wallet. But when I try to send the cryptocurrencies that I have received from my wallet it says it is watch only wallet.
I dont understand what it means by watch only wallet as I am new to this and also how can I send cryptocurrency from my wallet to someone else.

Ishan

Does this answer your question? Reg: Watch only Address

you can't move these coins since you don't have the private keys. If this trader created a watch-only wallet and gave it to you then looks like a scam. Sorry to say that, only this guy can spend these coins.

Watch-only wallet means the wallet only has access to its public key (usually "extended public key" or "xpub"). This allows the wallet software to monitor any activity in that wallet (receiving and sending) without being able to spend the funds.
What this warning is saying is that unless you have the private key to that wallet somewhere else, it isn't actually your wallet. If this public key was given to you by your "trader", I'm sorry to say that you have been scammed. They're only trying to make it seem like you have access to your funds. You should probably check out this question.
If you do have your private key somewhere else – in a different wallet that you used to generate this public key and then imported the public key into Trust Wallet – then there's nothing to worry about. Your funds are still accessible from the previous wallet as long as you have it.


text:
bitcoind not sending index nor blocks to inbound connections
Currently, I am following the recommendation of running a full node on my desktop with bitcoind; it has most of the blockchain downloaded (~680000 blocks) and is not pruned. Then I have two laptops that I will be running bitcoin-qt on that will only connect to my full node. Unfortunately, I am having trouble with bitcoind sending the index and blocks to the inbound connections from the bitcoin-qt laptops. My configuration files, node info, and peer info are included below. Thanks for your suggestions.
desktop bitcoind /etc/bitcoin.conf
rpcauth=root:******
rpcauth=_bitcoind:******
[main]
[test]
[signet]
[regtest]

laptop bitcoin-qt ~/.bitcoin/bitcoin.conf
connect=192.168.1.197:8333

desktop bitcoind daemon control script /etc/rc.d/bitcoind
#!/bin/ksh
#
# $OpenBSD: bitcoind.rc,v 1.2 2018/07/15 22:03:50 bentley Exp $

daemon="/usr/local/bin/bitcoind"
daemon_timeout="300"
daemon_user="_bitcoind"

datadir="/home/bitcoin"
conf="/etc/bitcoin.conf"
daemon_flags="-daemon -conf=$conf -datadir=${datadir}"

. /etc/rc.d/rc.subr

rc_reload=NO

rc_cmd $1

bitcoin-cli -getinfo to bitcoind on the desktop, it returns:
{
  "version": 210100,
  "blocks": 684628,
  "headers": 718323,
  "verificationprogress": 0.90065025371744,
  "timeoffset": -1,
  "connections": {
    "in": 2,
    "out": 1,
    "total": 3
  },
  "proxy": "",
  "difficulty": 25046487590083.27,
  "chain": "main",
  "relayfee": 0.00001000,
  "warnings": ""
}

When I run getpeerinfo in the bitcoin-qt console, I get:
[
  {
    "id": 0,
    "addr": "192.168.1.197:8333",
    "addrbind": "192.168.1.174:58377",
    "network": "not_publicly_routable",
    "services": "0000000000000409",
    "servicesnames": [
      "NETWORK",
      "WITNESS",
      "NETWORK_LIMITED"
    ],
    "relaytxes": true,
    "lastsend": 1642006419,
    "lastrecv": 1642006299,
    "last_transaction": 0,
    "last_block": 0,
    "bytessent": 693,
    "bytesrecv": 18317,
    "conntime": 1642005880,
    "timeoffset": 0,
    "pingtime": 0.002229,
    "minping": 0.001617,
    "pingwait": 6.439448,
    "version": 70016,
    "subver": "/Satoshi:0.21.1/",
    "inbound": false,
    "bip152_hb_to": false,
    "bip152_hb_from": false,
    "startingheight": 684595,
    "synced_headers": -1,
    "synced_blocks": -1,
    "inflight": [
    ],
    "addr_processed": 1003,
    "addr_rate_limited": 0,
    "permissions": [
    ],
    "minfeefilter": 0.09170997,
    "bytessent_per_msg": {
      "feefilter": 32,
      "getaddr": 24,
      "getheaders": 93,
      "ping": 160,
      "pong": 96,
      "sendaddrv2": 24,
      "sendcmpct": 66,
      "sendheaders": 24,
      "verack": 24,
      "version": 126,
      "wtxidrelay": 24
    },
    "bytesrecv_per_msg": {
      "addrv2": 17773,
      "feefilter": 32,
      "ping": 96,
      "pong": 128,
      "sendaddrv2": 24,
      "sendcmpct": 66,
      "sendheaders": 24,
      "verack": 24,
      "version": 126,
      "wtxidrelay": 24
    },
    "connection_type": "manual"
  }
]

It seems that the whole blockchain has to be synced before it will send the index and blocks to inbound requests.
Explained in this issue: https://github.com/bitcoin/bitcoin/issues/6971

source: Stack Exchange

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

sort: votes


text:
Prioritize whitelist LAN Connections
With bitcoind I have whitelisted local connections with whitelist=10.0.0.0/8 in bitcoin.conf on my server. When I launch bitcoin-qt on my laptop (only has one peer the server) it does not sync any blocks unless I block all incoming connections from the WAN to the server.
I have used bitcoin-cli -netinfo and seen that my client 10.0.0.10 is listed as npr so I know it is connected.
I have seen the suggestion to use whitebind but that requires more effort to implement than just using whitelist. Reserve the connection for local wallets
Is there a way to give priority to whitelisted clients so they can sync immediately or is whitebind the only option?

How do you connect the local client? Addnode?

connect=10.0.0.1:8333

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


text:
Is it safe to use the same BTC address for an ongoing exchange DCA?
I'd like to ask a question about re-using an address for a DCA. I've searched the forum and found some similar answers but nothing exactly which describes my situation.
I have an auto DCA set up from an exchange to a bitcoin address generated from my hardware wallet. This address was generated specifically for this purpose and has never received coins from anywhere else. Does it still compromise privacy if I use this address for regular DCAs from this exchange, but only this exchange and nowhere else?
I've set up an auto buy with this exchange but am trying to find the best way to do this while protecting privacy. The exchange does not support generating unique addresses from my XPUB.
Any tips on this would be appreciated.
Thank you friends.

The exchange you are using will obviously know all the addresses that you withdraw coins to. You won't have any immediate privacy against them, whether or not you reuse addresses.
However, if you reuse the same address, then in the future when you want to spend those coins, whoever you send them to will be able to see all of your past transactions to that address, including your past, present, and future balance. On the other hand, if you used a new address for every withdrawal, then whoever you send coins to in the future would only be aware of some subset of your addresses (ie, the UTXOs that were used to make the payment, and no more).
Think of it like this: when you pay for a $26 lunch with $30 cash and ask for change, then the waiter will know you have at least $4 left. If you paid for a $26 lunch with your entire account balance of $12,000 and asked for change, well then the waiter will know that you have at least $11,974 left. Obviously, there is no reason to give the waiter that information. When using bitcoin, you can protect this information by not reusing addresses.
Further, if you send some coins from your re-used address to the publicly-known address of some service/person/etc, then everyone else you transact with will be able to see that you transacted with said publicly-known service/person/etc. This hurts your privacy, but also potentially the privacy of others you are transacting with.
If you really must use one address to receive DCA funds from an exchange, you could perhaps make a habit of transferring those funds into another wallet from time to time, using a new address for each new transfer. Each transaction you make adds some plausible deniability to the history of funds, so while this technique is very far from a perfect privacy fix that will thwart a well-provisioned blockchain spy, you could at least use it overcome the most basic of privacy-eroding analysis.

Thanks so much for your thoughtful and detailed answer on this. I can see your suggestion in the last paragraph may be a solution of sorts. I like to auto DCA so I don't have to think about it but see that tradeoff of using the same address. I could update the address in the DCA every few months too I guess.
Thank you!


text:
Is the Bitcoin Blockchain aware of time?
I recently learned about how the lightning network works, and one particular thing that I found interesting is that, to prevent fraud, the output for each commitment transaction contains a clause for the revocation secret. If a bad actor broadcasts a prior state of the payment channel to the blockchain, the other party can use the revocation secret within 24 hours to claim all the money held by the multi-sig address.
My question is, how does the bitcoin blockchain know how to "count" 24 hours? Is there anything programmed in the blockchain for tracking time (e.g. UNIX time)?

The Lightning Network's timeout to broadcast a justice transaction is measured in blocks, not a specific time. As the Bitcoin network regulates its block interval to approximately 10 minutes, setting a timeout of 144 blocks will give the Lightning user about 24h to react, give or take.
The Bitcoin network itself is not really aware of time, however, every block has a timestamp that generally must be within a couple hours of the actual time for other nodes to accept it. While blocks could have inaccurate timestamps theoretically, most blocks tend to be labeled fairly accurately.
There is another way to specify timelocks in transactions that is not height based, but refers to actual time. For that use, the set time is considered to have passed when the median timestamp of the last 11 blocks exceeds it.


text:
What is a block-relay-only connection? What is it used for?
Modern versions of bitcoin core establish a fixed number of outbound connections: 8 outbound-full-relay connections and 2 block-relay-only connections. What is the purpose of block-relay-only connections and how are they used?
Here are two example log entries of a node establishing these connections:
2022-03-10T14:50:36Z New outbound peer connected: version: 70015, blocks=726709, peer=1566 (outbound-full-relay)
2022-03-10T14:55:28Z New outbound peer connected: version: 70016, blocks=726710, peer=1576 (block-relay-only)

Here is an example CLI query showing all connected peers:
$ bitcoin-cli -netinfo
Bitcoin Core v22.0.0 - 70016/Satoshi:22.0.0/

            ipv4    ipv6   onion   total   block  manual
    in         0       0      24      24
    out        2       0       9      11       2       1
    total      2       0      33      35

Local addresses
REDACTED     port   8333    score      4

Note: this node has one addnode entry in its bitcoin.conf file. Nodes connected to in this fashion do not count against the 8 and 2 outbound connection limits so this adds an additional 11th outbound peer.

Block relay connections were added to bitcoin core in v0.19.0.1 in November 2019. Their purpose is to harden the peer-to-peer network against partition attacks. They do this through a clever combination of factors:
Protection from Network Topology Information Leaks
A bitcoind node will not gossip address or transaction information over a block-relay-only connection. This prevents the node from leaking network topology information. A network topology map can be dangerous for two reasons:

It can be used to trace the origin IP of a bitcoin transaction.
It can be used to perform an eclipse attack.

Increase Outbound Connections Without Significantly Increasing Network Traffic
Address and transaction gossip messages make up the majority of a node's network bandwidth consumption. So adding additional outbound connections that do not gossip these messages allows for a more tightly integrated network graph with a very limited impact on the bandwidth required to run a node.
Anchor Nodes
Normally, a bitcoin node will connect to random peers upon startup. An anchor connection is an outbound node connection that persists across a restart. Block-relay-only connections were converted to anchor connections in v0.21.0 released in January 2021.
Anchor connections protect from a remote restart attack, which is the most likely vector of an eclipse attack. The attack works like this:

Flood the target node's address manager with malicious node addresses.
Use some other exploit to force the target node to restart (or wait for a software upgrade). This tricks the target node into clearing its outbound connections and connecting only to malicious nodes.

Too many anchor nodes can be a bad thing because it will entrench a malicious node connection and make it difficult for a node to defend or recover from an eclipse attack. They can also make the network topology graph more static, and therefore easier to map and easier to partition. But you definitely want to have a few anchor nodes to protect from remote restart eclipse attacks with some redundancy. Using block-relay-only connections as anchor connections strikes a nice balance in this regard. This configuration also benefits from the fact that block-relay-only connections are difficult for an attacker to detect due to their lack of ADDR and TX messages.
Anchor connections harden the peer-to-peer network using the "one honest peer" principle. As long as a bitcoin node is connected to one honest peer it will be able to stay informed about the chain of valid blocks with the greatest total proof of work. The node is able to rely on the unforgeable costliness of proof of work as the ultimate security guarantee. This, in turn, depends on an attacker not gaining control of a majority of the hashpower on the network. To put it succinctly, block-only-relay nodes bind the peer-to-peer security model more closely to the proof of work security model.
Additional Resources

block-relay-only PR
anchor node PR
sipa comment on block-relay connections


text:
What is the prior work or inspiration for the new/tried table design?
In Eclipse Attacks on Bitcoin’s Peer-to-Peer Network section 8 Related Work, the authors describe how some of the countermeasures to eclipse attacks were inspired by botnets. What inspired the design of the address sharing mechanism between full nodes? Were the new and tried tables included in bitcoin from the beginning or added at a later date? What is the "Related Work" for this design?

Were the new and tried tables included in bitcoin from the beginning or added at a later date?

new/tried table were introduced in #787. Counter measure 6 in the paper suggested more buckets and was implemented in this commit.

What inspired the design of the address sharing mechanism between full nodes? / What is the "Related Work" for this design?

addresses in the earlier clients (before v0.6.0) were directly stored inside BDB managed addr.dat.

simple implementation wherein new addresses were added into addr.dat when ADDR message was received and old addresses periodically cleared.

v0.6.0 implemented #787 which introduced the address manager/AddrMan along with new and tried tables for better control/management of peer addresses.

v0.7.0 implemented #1198 which replaced BDB managedaddr.dat with flat filepeers.dat. (because AddrMan could read/write it's own serialized data now.)

Design goals for the new/tried table design are mentioned here. I'm not sure what inspired this design though.


text:
How do bitcoin nodes agree who first mined ablock?
Once transactions are broadcast and a node starts working on a proof of work, and finds it, it broadcasts it to all other nodes for that block to be verified and added onto their blockchain. All nodes agree to add another transaction that mints a certain amount of bitcoins to the miner.
However, I am confused about what protections there are against a bitcoin node receiving a proof of work for a new block that it did not find itself, and then sending the that block around as though it mined it!
How do bitcoin nodes who originally mined a block and how does the bitcoin system prevent tampering with this?

All nodes agree to add another transaction that mints a certain amount of bitcoins to the miner.

No, every miner already includes the transaction that pays them in their own block template. Whatever miner succeeds pays themselves by means of their block being the winner.

However, I am confused about what protections there are against a bitcoin node receiving a proof of work for a new block that it did not find itself, and then sending the that block around as though it mined it!

All data in the block is committed to cryptographically via hashes and signatures. The proof of work is based on the hash of the block header, which in turn commits to all transactions via the Merkle root. To claim the reward, one would need to change the output of the Coinbase transaction to send the reward to someone else instead of the miner. This would make the Merkle root that commits to all transactions invalid. So they'd have to change the Merkle root. Well, that would change the block header and make the proof of work invalid. This means that another user can't redirect the block reward, because the instruction to pay out the block reward is protected by the proof of work. If you change a single byte in the block, it's no longer valid.


text:
Authentication error with Blockchain Wallet API
I successfully integrated the blockchain-wallet-api into an application which is currently on production. The challenge I'm having is that even though I was able to disable email login authentication from my wallet settings and added the shared hosting ip to ip whitelist, I still get the error
Array ( [error] => Wallets that require email authorization are currently not supported in the Wallet API. Please disable this in your wallet settings, or add the IP address of this server to your wallet IP whitelist. )

I don't know what else to do.


text:
Impossible to restore Copay wallet on new phone
I just changed my phone and reinstalled Copay.
I'm trying to restore my BTC Wallet from the 12 words key phrase i saved, but copay keeps telling me "impossible to import.Wallet Recovery sentence is invalid".
Anyone has an idea?

Thank you for reaching out. You can import or restore your Bitcoin or Bitcoin Cash wallet to your device by using the 12 word backup phrase for your wallet.
Please see the following article for steps on restoring your wallet using the recovery phrase: https://support.bitpay.com/hc/en-us/articles/115003004363-I-lost-my-wallet-or-changed-my-phone-What-can-I-do-to-restore-my-wallet-
If you are experiencing an issue, here are some things that you can check:

Are you sure that the recovery phrase was written in the correct order?
Did you use all lowercase letters and no punctuation?
Did you add a password to your recovery phrase?
[Do you have the QR code or text/file backup?]

(https://support.bitpay.com/hc/en-us/articles/115003004363-I-lost-my-wallet-or-changed-my-phone-What-can-I-do-to-restore-my-wallet-)
- Did you separate each word with a single space (no commas or any other punctuation)?
Please also ensure that your words are all contained in the following list of possible words:
https://github.com/bitcoin/bips/blob/master/bip-0039/english.txt

Anyone has an idea?
Use a spelling checker on your twelve-word recovery phrase.
Even better, use a tool to check the phrase against the appropriate BIP39 dictionary for your language.

Example
>wordcheck able moose zoo
able                           - OK
moose                          - Not in bip39 dictionary
zoo                            - OK

Source: https://github.com/redgrittybrick/wordcheck
Compiler: https://golang.org/


text:
Please help - Bitcoin Conf file in the wrong directory
I am running a full node using Bitcoin Core GUI on Windows 10. The conf file is in my bitcoin data directory, instead of being in the appdata/roaming folder. But Bitcoin-qt points to it by default and seems to work fine.
But bitcoind and bitcoin-cli are looking for the conf file in the appdata/roaming folder, which I guess is the reason the bitcoind server never appears to start. How do I start bitcoind and check if it is running or not? I need bitcoind to run so that I can use json-rpc commands.
If I run bitcoind on cmd, it appears to start downloading the whole blockchain again, which is unnecessary because I already have all of it.

You can use the --datadir parameter to specify the exact location of your blockchain data, and --conf to specify the location of your configuration file.
From the wiki:

If you want to store the data in D:\BitcoinData then click on "Properties" of a shortcut to bitcoin-qt.exe and add -datadir=D:\BitcoinData at the end as an example:
"C:\Program Files (x86)\Bitcoin\bitcoin-qt.exe" -datadir=d:\BitcoinData
Start Bitcoin, now you will see all the files are created in the new data directory.

If you have a custom config, do the same with the added parameter:

"C:\Program Files (x86)\Bitcoin\bitcoin-qt.exe" -datadir=d:\BitcoinData -conf d:\Bitcoin\bitcoin.conf

Thanks @KappaDev - quick question:
When you say "click on "Properties" of a shortcut to bitcoin-qt.exe and add -datadir=D:\BitcoinData at the end as an example:"
Actually, I wanted to update the conf file location for bitcoind and not bitcoin-qt. When I right click on Properties for the bitcoind exe file, it doesn't give me any place to enter any such commands. Which tab of the properties should I look under, please?
I am able to run bitcoind on cmd using --datadir=d:\BitcoinData as a one-time thing, but I want bitcoind to remember the location every time.

@oktested No problem. The actual .EXE file won't have the same properties tab, you need to right click the EXE and press "Create Shortcut". Once you have created the shortcut, right click it and go to properties and modify the "Target" option. It will look something like this. Just modify the line the same way you would run from the command prompt. If you have your BTC automatically on startup, check the startup folder of your operating system and edit that shortcut too.


text:
Setting keypool size in the conf file
I used keypool=10000 in the conf file but bitcoin-cli -getinfo shows "keypoolsize":1000. Why?

Try running keypoolrefill

But that will just refill it back to 1000 in case I use a couple of addresses and bring it down to 998, right? I need the size to be expanded.

This sort of thing is almost totally irrelevant with HD wallets.

keypoolsize only shows how many keys are currently in the keypool. It does not reflect the maximum size of the keypool. The keypool=<n> option does not automatically fill the keypool to that size, you will need to refill it by using keypoolrefill.
If after keypoolrefill you still do not see a larger keypool, then that means your bitcoin.conf file is either named incorrectly, located in the wrong location, or formatted incorrectly.


text:
Is it okay to run regtest for dev purposes while simultaneously running a node on mainnet (bitcoind)?
Hope it won't mess anything up on my mainnet node.

As long as your nodes are running on separate ports and using separate data directories, you should have no issues running multiple networks.
Note that you may run into resource issues, especially with regular spinning HDDs, if both networks have high requirements for disk writes and reads at any point.


text:
Bitcoin walletnotify doesn't pass the txid as %s
Thoroughly searched this online but haven't found an answer yet. Basically I'm using the below line in my conf file:

walletnotify=C:\pathname\filename.py %s

It is supposed to run my python file and pass the txid to it as the argument sys.argv[1]. But I get "IndexError: list index out of range" and upon investigating, it is merely opening the python file without passing anything to it, so there are no arguments.
I am using Anaconda for python 3 and I've set the python.exe file in my Appdata\local\conda\conda...subfolders as the default program to open .py files with. This might be relevant because earlier there was a python 2.7 installed on my computer that I wasn't really using, but somehow walletnotify seemed to be working fine at that time. I uninstalled python 2.7 just to clean up my computer and since then I've been facing this issue. I'm using Windows 10 FYI.
I'm a bit frustrated as I've been trying to crack this for about 6 hours now without much success. Please help.

Try putting double quotes around the entire command that you want to run, i.e. walletnotify="C:\pathname\filename.py %s"

Thanks for the reply - this didn't work, but when I tried walletnotify= C:\pythonpath\python.exe C:\pathname\filename.py %s then it worked. I don't know why this worked, but if you have any idea, please do tell. Would love to learn. FYI, the txid was passed as sys.argv[1].

In Windows, python file needs to be run within the python path. You can refer https://stackoverflow.com/questions/3701646/how-to-add-to-the-pythonpath-in-windows for more details as to how to change the python path. As a workaround, you can also use walletnotify= py C:\pathname\filename.py %s

Thanks @BlockGuru - but if I'm calling a .py file from command line, and I've already set the python.exe program as the default program to open all .py files on Windows, then I wonder why it still requires me to add the pythonpath or the prefix "py " before the command. Anyway, all's well that ends well. Thanks and have a wonderful day!


text:
python-bitcoinrpc: modulenotfounderror no module named 'bitcoinrpc'
I'm running bitcoind/ bitcoind -regtest on Windows 10 and am already able to use bitcoin-cli -regtest along with json-rpc methods to perform basic operations and get balances etc. When I try to do this programmatically on python 3 using Jeff Garzik's python-bitcoinrpc package (https://github.com/jgarzik/python-bitcoinrpc) I get a modulenotfounderror. However, my pip3 freeze shows python-bitcoinlib==0.10.1 and also python-bitcoinrpc==1.0.
My code is below (18443 is the regtest port):

from bitcoinrpc.authproxy import AuthServiceProxy, JSONRPCException
rpc_connection = AuthServiceProxy("http://%s:%s@127.0.0.1:18443"%("myrpcuser","myrpcpassword"))
best_block_hash = rpc_connection.getbestblockhash()
  print(rpc_connection.getblock(best_block_hash))

What am I doing wrong?
Separately, is there a way to make the json-rpc calls into bitcoind directly from python3 instead of using this library, since it seems really old and out of use? Very grateful for your kind help!

Are you sure your script is running with python3 an not python2? On many OS's, the default python is still python2.

Yes sir, I downloaded and used python3. I installed the package using pip3 install python-bitcoinrpc. Is there something else I should be doing? Appreciate your help to a noob.


text:
What bitcoin address has the most amount of UTXOS available for it to spend?
I'm not asking what the richest bitcoin address is. That information is easy to find. I'm asking what address has the most amount of UTXOS/inputs available for it to use (whether said inputs are just a few hundred satoshis, doesn't matter). This is just for fun but i'm curious and would like to know this (and also how this information would be found in the first place)

I did not find anyone who did this already so did it myself, but used to signet to have a much smaller data set (signet utxos are 41M, mainnet utxos are 4.6G now)
I used https://github.com/in3rsha/bitcoin-utxo-dump to get the utxos from the ldb to csv format and used some javascript to count the amount of utxos per address
results (addresses are in mainnet format so have to converted first):
top 10 most UTXOs by address on signet
address                                    UTXOs
bc1qfwsnqles0ptp6rmwm4nun4q48yd64uedkve4zy 26928
bc1qp0rz5ek3vyj2ahyypjpxj5lhnrg85kcc62hsh2 22296
bc1q6m9uassy9ha3g45d6xdlp3wrpjffhdkfmdn2yw 18292
bc1qsygnet2jdqm8n2p7wmmklp9yel3k7agpezrlw6 17342
bc1qq2mfy24rkf9ddpz2m56rqf2kpsca5wgyvzn39s 14686
bc1qspqw7uvc7qtqlcfu49qr2v6fwp8f3rqke2ctpa 13274
bc1q9s28zh2pu7rk943gmaal6dc7e5gm4kljk45kss 12011
bc1qgwdjvpnw6yhgw2vfmh9kt6xmm66xaphfrpp3sc 11896
bc1qm7tvlpv00x3q3l2ea3zlksy3xqp78ptx0wv2c9 11223
bc1q4q2c7s3gg6tl7m40layvnhep3j2qc7ucq78yum 10984

to convert a bech32 address from mainnet to signet (testnet) from:
 > bitcoin.address.toBech32(bitcoin.address.fromBech32(v).data, 0, 'tb')
'tb1qfwsnqles0ptp6rmwm4nun4q48yd64uedu2zxeh'

you can see on a block explorer that this address has 26928 transactions and 0.00000000 sBTC sent (so all TXOs here are UTXOs)
https://mempool.space/signet/address/tb1qfwsnqles0ptp6rmwm4nun4q48yd64uedu2zxeh

I'm confused by this answer. You demonstrate that you have all the tools to answer the actual question, but then you instead provide the answer for a different network.

its an example, everything would take way longer on the mainnet, so i used the way lighter signet as an example


text:
Why tx informations of a specific transfer in BITCOIN protocol will send to many IP addresses?
Recently I send a specific value from a wallet to another wallet and Simultaneously I caputred the related traffics in source and destination.
after that, I found that value and it's related address in different packets which their difference was just in source and destination IP addresses.
Why these information(transferred value and it's output address) where distribute to different addresses and which address is main?

are you asking about funds being sent to change addresses?

@UgamKamat I just know that when I extract tx informations from this pcap, I see different packets which their value and output addresses are the same and their IP addresses are different. How I know that which is fund and which is not? and my assumption is that I see a specefic value and it's address in just one packet.

This is gossip protocol. When you are connected to the bitcoin network, you are usually connected to some random nodes. When you want to send transaction, ultimately your goal is for the transaction to appear in a block. The blocks are created by miners who operate few network nodes. Usually you don't even know which nodes belong to such miners. Therefore you just send the transaction to some or all your of the nodes you are connected to. And they do the same thing. Eventually, the transaction propagates to the whole network – meaning to every connected node. And some of those nodes are miners and one of those miners will include it in their new block.


text:
How do I download specific blocks directly from peers, without downloading the entire chain?
My dev environment is quite limited in terms of bandwidth and storage. I need to make a database out of transactions containing opcode 0x6a since a given epoch.
[Scan blocks, going backwards from the latest, until a given blockheight]
[If the transaction outputs contain OP_RETURN, save it with associated metadata]
Is there a way I can do this with bitcoind without having to store the entire chain?

Currently-released version of Bitcoin Core will only process blocks sequentially starting from the beginning of the chain.  If that happens to be the beginning of your epoch, you can start recent versions of bitcoind with the -stopatheight parameter to specify the end of your epoch and bitcoind will stop downloading blocks at that point.
Alternatively, a pending Bitcoin Core pull request (PR) provides the behavior you want where you can tell Bitcoin Core not to download any blocks automatically and then manually specify which blocks you want.  See PR#10794 for details.
Note that if you operate in this mode connected directly to the peer-to-peer network, your node will only have SPV-level security, meaning someone could theoretically give your node an invalid block with a valid amount of proof of work.  If you require a high degree of security, it would be recommend that you exclusively connect your bitcoind running PR#10794 to one of your own fully-validating (regular) bitcoind nodes so that will ensure you only receive valid blocks.  To do that, see the -connect option to bitcoind.

You could use the pruning mode to only store blocks after the height you are interested in. I think you'll still have to download it to verify the past history, but you won't have to store it all on disk.
See this RPC call for more information.

This is implemented with pull request "rpc: getblockfrompeer" #20295, merged into master on Dec 8, 2021:

getblockfrompeer "blockhash" peer_id
Attempt to fetch block from a given peer.
We must have the header for this block, e.g. using submitheader.
Subsequent calls for the same block may cause the response from the
previous peer to be ignored. Peers generally ignore requests for a
stale block that they never fully verified, or one that is more than a
month old. When a peer does not respond with a block, we will
disconnect. Note: The block could be re-pruned as soon as it is
received.
Returns an empty JSON object if the request was successfully
scheduled.
Arguments:

blockhash    (string, required) The block hash to try to fetch
peer_id      (numeric, required) The peer to fetch it from (see getpeerinfo for peer IDs)

Result: {}    (empty JSON object)
Examples:

> bitcoin-cli getblockfrompeer "00000000c937983704a73af28acdec37b049d214adbda81d7e2a3dd146f6ed09" 0
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id": "curltest", "method": "getblockfrompeer", "params":
["00000000c937983704a73af28acdec37b049d214adbda81d7e2a3dd146f6ed09"
0]}' -H 'content-type: text/plain;' http://127.0.0.1:8332/


text:
Crypto currencies and internet dependence
Ive a problem with the concept of crypto in one aspect. What about "cyber safety"? Given that there will be more online malicious activity in the future, isnt cryptos dependence on the internet a weakness?

On the contrary! Computer security is necessary, even without cryptocurrencies. The current economy is very much dependent on the internet, nothing can reverse that. Besides, you can receive the bitcoin blockchain from satellite, so strictly speaking, internet is not needed for bitcoin, it is just a medium of distribution. You could, for example use a mesh network.
If you sum up all the code used for VISA/Stripe/etc, it will probably be mode code that what Bitcoin contains. Assuming a similar bug count per line, you would then have more security issues with fiat infrastructure! And Bitcoin is open source, which has been proven to improve code quality. So in reality, you have less code, and you have less bugs per line.
What cryptocurrencies do, is that they replace authentication based on fuzzy methods like your bank asking your social security number on the phone with authentication based on cryptography. If you can't keep your data secret, you will lose your Bitcoin very quickly, while it might take some time with the fiat systems.
Do you want a world in which you are dependent on broken methods of authentication? I would encourage you just to understand how to keep your data safe, instead.
So while Bitcoin users may lose money often because of lacking security, that is not the fault of Bitcoin. Bitcoin is an incentive to learn about security, therefore it is good.

thanks alot,great info.

@Nocturnal hand me an upvote then, please :)

cant upvote to few pts

aah, ok, thanks anyway :)

Is money in your bank account or locker safe?
Moreover is the money in your wallet right now safe?
Cryptocurrencies are not safer. They are prone to be stolen because you would not have taken your digital security seriously.

great last point


text:
How many numbers to try to solve the proof-of-work problem
I'm preparing for a lecture on blockchain, where I'm going to briefly explain the proof-of-work mechanism and the hashcash challenge.
To illustrate the difficulty, I want to give the maximum amount of numbers one has to try in order to find a solution, given a specific difficulty target (at this time, 18,670,168,558,400).
I believe it's a simple formula, but I can't find it again. Can someone please refresh my memory?
Thanks!
R.

There's no maximum. Instead you can find the formula linking the target and the required number of initial zeroes. Then the average number of hashes you need to calculate is 2^(target number of initial bits). Then you could input the current target to find the average number of hashes.
I don't know the formula for that but for example the block 661657, a recent one, had the target bits as many as about 76, which means it took about 2^76 hashes.

Ah, yes, that's it! That gives me a nice illustration of the computing difficulty of the proof of work! Thanks!


text:
Question about Arbitrage
So I just happen to know that arbitrage is possible yesterday and found a way to detect an arbitrage opportunity across all exchanges through all markets. But the thing that sucked is that exchanges disable the deposit and withdrawal whenever a coin is feasible for an arbitrage. My question is that, would it be possible to send coins to an exchange that disabled the deposit to that coin? I

You could send it, but they are under no obligation to process that deposit, and it might take you a while/battle with the customer support to eventually get them back

You should never deposit your coin to an exchange when the deposit function is disabled, your transaction will either be delayed or just gone.


text:
Bitcoin Cash to CoPay Bitcoin Wallet - How to Recover?
We have an eCommerce website and a customer is purchasing an item using Bitcoin.
We provided the customer with our business Copay Wallet address, however the customer sent "Bitcoin Cash" - how can he, or we, recover his payment?  The Copay wallet is of course Bitcoin only.

You can export the private key for that address from copay and import it into a wallet such as Electron Cash.

Out of interest, did he/she send the correct amount in FIAT worth, or just 1-for-1 coins in BCH?  Sounds like either (a) scammer trying to get you to accept BCH (1/6th the value) as bitcoin, (b) sneaky attempt to get you to consider accepting BCH (if you don't already), or (c) clueless, probably cause by the "bch is bitcoin" movement.  They should thank you for being so accommodating, if you were using SegWit (I don't think Copay supports it) their funds wouldn't be recoverable at all.

To recover Bitcoin Cash (BCH) from a Bitpay/Copay BTC wallet, please follow the steps below:

Within the Bitpay/Copay app, navigate to Settings.
Under Preferences, tap on Bitcoin Cash.
Tap on Scan wallets for BCH, and to the right of the BTC wallet you want to duplicate, and tap on Duplicate.

Duplicating the BTC wallet will create a BCH wallet in your BitPay or Copay app with the BCH balance.
The option above to duplicate is not available for multi-sig BTC wallets, and you will need to use the recovery tool to recover BCH funds sent to a multi-sig BTC wallet.

how can he recover his payment?

He can't. Bitcoin Cash transactions are not reversible and generally cannot be cancelled.

how can we recover his payment?

Create a Bitcoin Cash wallet using your Bitcoin private keys. Then refund him (less transactions fees, agreed handling fees etc)
Given that this involves putting your private keys into an unfamiliar piece of software, there are security issues (you need to be sure you trust it and obtained it from the right place and know how to use it properly etc) there may be significant man-time costs that some businesses may be reluctant to commit to help a small one-time customer.


text:
Blockchains beyond bitcoins
There are suggestions that blockchains concept can go beyond crypto currency such as votings etc.  My question is that in those cases how could a “proof of work” is enforced? I guess adding any new blocks to the chains always require various kind of “independent” check. Without any incentives how could pow be done fairly?

Most current such systems (Ethereum, Neo, WAVES, etc.) rely on proof of work to secure the blockchain and issue the native token (ether and waves are issued, Neo was all generated at genesis).
The incentives in these cases are:

Transaction fees gained by executing contract transactions
Block reward, if it exists

There are also a number of private blockchain systems, such as Hyperledger, where the incentive is that the businesses maintaining the network will presumably reap some benefit from its continued functioning.

Thanks for the answer. I agree that for bitcoins, there always ways to collect fees. My question is for something not relating to bitcoins, for example votings, or health cares. As the blockchains grows, especially for health cares, proof of work may require significant resources —-  and to be fair and accurate it will need to have many minners to work independently—- who will be paying the fees? (Patient?, hospitals?)

Using a proof of work system for a healthcare blockchain is beyond ridiculous. Proof of work is a (partial solution) to the consensus problem, which instead turns it into an economic incentive. If you can't reward miners with valuable tokens, you get no solution. Furthermore, healthcare doesn't need a consensus system.

Enterprise blockchains do not rely on Proof-of-Work (PoW).  For example, Hyperledger Sawtooth uses Proof-of-Elapsed Time (PoET), which is a Nakamoto-style consensus algorithm without the energy-wasteful "mining" PoW algorithm and without miners or digital currency.


text:
How would you recommend parsing a private bitcoin core node with nodeJS?
I just need to parse a private node and lookup one bitcoin address and get all transactions going in or out of the address preferably using nodeJS within the last 200 or so blocks. Any recommendations?

This question is pretty broad as parsing a node involves decoding every transaction within a block(which would require txindex to be enabled), and recording each output and input until you end up with a list of all outputs that have not been used as an input aka an unspent output.
With a fully synced node and txindex=1 you can begin iterating through each block of the last 200 blocks with loops using the rpc calls getblockhash getblock getrawtransaction and decoderawtransaction, storing the outputs in a database. On each new block you should check every input to see if there is a transaction id matching an output in your existing output database, if there is that output has been spent. The node-bitcoin JSON-RPC wrapper should work fine for implementing these calls to your node. As you can imagine this would take some time.

Can you explain what "parsing a node" means here?  Sounds like you mean something like parsing every block in the blockchain?


text:
Want to verify previous block hash and prove of work
I want to verify several random blocks and check if there was prove of work really found. I need it for some reasearch reasons. I have downloaded the blocks historical info and there are only hashes with number of zeroes in the block headers in the ladder I have downloded. This means the prove of work was alredy found. Is there any way to get initial block hash and the prove of work which was found, so I could calculate their hash by myself?
There is an exaple:
SHA256 hash of the current block hash = 000000000000000000044F29DB8B3388FD4E4CF400420B2AA8DA008E9891250B
How can I find what was the initial hash number and prove of work?
Thank you in advance.

you cant verify the proof-of-work with only the block hash. you also need the bits part of the header

How can I find what was the initial hash number ...

There's no such thing. Every miner assembles their own choice of transactions and makes their own choice of initial nonce value. There's no way to find out which combinations and values each miner tried first - they simply discard ones that don't hash less than the target, there's no record of failed attempts.

... and prove of work?

The hash being less than the target appropriate for that block height is the proof of work. Your example number is the proof of work for that block.
To validate that proof you just need to recalculate the hash and see that it agrees with the one you posted and then calculate the current network target for that block height based on prior block targets and times.

Useful links

How is difficulty calculated?
Can a smart mind explain block difficulty calculation in lay terms?
What is most efficient way to validate bitcoin target (difficulty) value in C++
How is the difficulty of bitcoin mining propagated?

Thank so much for your fast response.
Can you please enlight me little bit further? How can I recalculate the hash using the historical info of a block? If it is possible of course.
Thank you in advance for your answers.


text:
SegWit signing algorithm and its improvement
I was reading about Segregated Witness upgrade from the book Mastering Bitcoin by Andreas and there were some questions I have not figured out. I am appreciated to get some of your help!
A) There was a passage of the book talking about SegWit helps reduce the complexity of the signing algorithm.

Segregated Witness upgrades the signature functions (CHECKSIG, CHECKMULTISIG,
etc.) to reduce the algorithm’s computational complexity. Before segwit, the algorithm used to produce a signature required a number of hash operations that was
proportional to the size of the transaction. Data-hashing computations increased
in O(n^2) with respect to the number of signature operations, introducing a substantial computational burden on all nodes verifying the signature. With segwit,
the algorithm is changed to reduce the complexity to O(n).

What is the original algorithm here whose complexity is O(n^2) (is it ECDSA or something else)? And also what is the new SegWit signing algorithm, and how it got the complexity of O(n)?
B)  There was also a passage talking about SegWit improvement.

Segregated Witness signatures incorporate the value (amount) referenced by each
input in the hash that is signed. Previously, an offline signing device, such as a
hardware wallet, would have to verify the amount of each input before signing a
transaction. This was usually accomplished by streaming a large amount of data
about the previous transactions referenced as inputs. Since the amount is now
part of the commitment hash that is signed, an offline device does not need the
previous transactions. If the amounts do not match (are misrepresented by a
compromised online system), the signature will be invalid

What does it mean by saying Segregated Witness signatures incorporate the value (amount) referenced by each input in the hash that is signed. and Since the amount is now part of the commitment hash that is signed, an offline device does not need the previous transactions.? Does it mean that in Legacy block, the variable transfer value is not included in the hash, and now SegWit includes it?  And I cant understand how this make offline device not to need previous transactions' info (although I do understand that every offline devices need previous utxo to sign a transaction)

To be clear, this is talking about the way the message that is signed is computed. It is unrelated to transaction or block hashes and the signature algorithm itself, just how Bitcoin determines what data is actually covered by the signature and how that is serialized. This data is hashed in order to be used in the signature algorithm. This is referred to as the sighash algorithm. This sighash is generated by the signer and verifiers, so both signers and verifiers need to be able to generate the exact same sighash, otherwise signatures will be invalid.
Prior to segwit, the sighash algorithm would take the entire spending transaction, remove all of the scriptSigs from every input, and then fill in the input that the signature will go in with either the scriptPubKey or the redeemScript (for P2SH) and sign that. This ends up being O(n^2) because as the number of inputs grows, the amount of data hashed by for each input also grows. So the total amount of data hashes grows quadratically. The amount of data being hashed can have a large effect on how quickly transactions are validated.
For example, a transaction with 2 inputs will require 2 sighashes to be computed, in which 2 inputs of data will need to be hashed in each sighash. The total amount of data hashed is 4 inputs of data. If a transaction has 4 inputs, there will be 3 sighashes computed, with 3 inputs of data in each sighash, for a total of 9 inputs hashed.
Segwit solves this problem by defining a new sighash algorithm used when spending segwit inputs only. It instead precomputes the hash of the inputs that is then used in the sighashes for each input. As this is only done once for the entire transaction, the amount of data hashed only grows linearly - each additional input is a bit more data to be hashed in the precomputed hash, and one additional sighash to be computed.
As Segwit defines a new sighash algorithm for segwit inputs only, this algorithm can also include new information that was not previously covered by the sighash. So it also includes the amount of the input being spent, not just the scriptPubKey. This allows offline signers to be sure that some kinds of attacks where they are lied to about the value of an input.
Offline signers need to know the value of an input in order to run checks on the amounts and be sure that the transaction does not do something unexpected with the amounts. If the offline signer were just told the amount by the online wallet, it cannot be sure that the amount is actually correct. So for non-segwit inputs, they ask for the entire previous transaction. This way they can check the amount in the output itself and make sure that the transaction id matches.
With Segwit, the amount is directly included in the sighash itself. This means that if the offline signer were given the wrong amount, its sighash would contain the wrong amount. When a verifier checks the transaction, they would compute a different sighash containing the correct amount, and this would result in a failed signature, and thus a failed transaction. Because offline signers know that a wrong amount will just result in an invalid transaction, they don't need the entire previous transaction in order to trust that the amount they are given is correct.
Except there are a few other attacks that still require the full previous transaction. Unfortunately these were not theorized when segwit was being implemented. So offline signers should still ask for full previous transactions when signing segwit inputs.  https://bitcoin.stackexchange.com/a/113785/48884 has a more detailed answer on the attacks that including the amounts mitigates, and the attacks that are still possible.

Where can I read more about this SigHash stuff? The only signature-related thing I know is ECDSA which combines the transaction data + sender's private key and some maths. Based on your answer, I visualize that a pre-SegWit signature depends on its input's referenced transaction's certain components -> the more pre-Segwit signature the more work for those "certain components" stack up quadratically, is that right? If so,   I still cant visualize how SegWit version can improve this.

@JohnPham https://bitcoin.stackexchange.com/a/5241/48884 describes the sighash algorithm for non-segwit inputs. BIP 143 specifies the sighash algorithm for segwit v0 inputs. BIP 341 specifies the sighash algorithm used for segwit v1 inputs (taproot).

Thank you for your material, although I have tried digesting the BIP documents and they are currently quite technical for me. I am surprised that there are not many websites talking about this SegWit Sighash.


text:
What is the purpose of the different types of extended keys, as well as some of its other elements?
I have a few questions about the extended public/private key, i.e. the purpose of its elements.
Namely, according to the BIP32 standard, the "format" of the extended key is as follows:
[ magic ][ depth ][ parent fingerprint ][ key index ][ chain code ][ key ]

However, what we actually need when generating new child keys is only the chain code and the key (private or public). What is the role of other elements within a given format. I understand that the magic gives the ability to recognize that it is an extended key after encoding with Base58, but even in that case exists a different types of extended keys (zpub/zpriv, ypub/ypriv). I can understand that all those "properties" can help people understand where that key is potentially located within the tree and what we can use it for. For example, if it is XPUB, then we know that we should use BIP44 and how to derive all other keys from it. Since the derivation path according to BIP44 is as follows:
m / purpose' / coin_type' / account' / change / address_index

... if the depth is 2, then we would know that we should use a hardened derivation and that we cannot use XPUB of this key to derive the child public keys since they are hardened. Also, since it is XPUB, we know that all keys derived from this key will only be used for P2PKH. On the other hand, if it was ZPUB/ZPRIV, we would know that we should follow BIP84 as well as the purpose of those keys. And so on...
So, it is clear to me how we, as humans, would use all the elements from the extended key (although it is not clear to me what the parent fingerprint will do for us). Do wallets also interpret extended keys this way? For example, if XPUB/XPUB gets to them, they will know that they follow the BIP44 standard and what the leaf nodes of its derivation path are for (P2PKH), if ZPUB/ZPRIV comes they follow BIP88 and so on. Is that the purpose of the different types of extended keys (different "values" for magic)?
Can someone tell me something more on this topic? What are all those fields for (different forms of magic, depth, etc.)? Is it so that the wallets know how to generate all the other keys, what are the keys for, and so on, or do they also have some other purpose?

For example, if it is XPUB, then we know that we should use BIP44 and how to derive all other keys from it.

That's not correct. An xpub just identifies a extended public key and its ancestry. It says nothing about how to derive further elements.

Also, since it is XPUB, we know that all keys derived from this key will only be used for P2PKH.

That's not correct either. xpubs (as defined in BIP32) say nothing about the address type to use. ypub/zpub were defined independently, later, in unrelated standards, for a different purpose, and are only supported by some software. At some point, there was a perceived need to convey address type information in the same string as the public key, so people defined ypub/zpub/... and various other variations which (ab)use the magic value to try to convey that.
I believe this was, and is, a mistake; it is the wrong place to put this information, for two reasons:

With Bitcoin script technology evolving, we need ever new formats, despite the keys being the same (resulting in a plethora of magic bytes today).
In the context of multisig, you inherently need multiple public keys anyway, as they come from distinct sources, so a "higher" level of information "around" the keys is needed regardless.

Output descriptors serve this purpose of metadata about how keys are to be used now, but are a lot more recent. For example, addresses for receiving would be written as descriptors which just list the derivation paths explicitly:

For BIP44, pkh(xpub.../44'/0'/0'/0/*)
For BIP49, sh(pkh(xpub.../49'/0'/0'/0/*))
For BIP84, wpkh(xpub.../84'/0'/0'/0/*)
For a 2-of-2 P2WSH multisig, wsh(multi(2,xpub1/.../*,xpub2/.../*))
etc

(Disclaimer: I authored BIP32 which defines xpubs, and contributed to the output descriptor format, so I am possibly biased on this topic)

Is that the purpose of the different types of extended keys (different "values" for magic)?

The parent fingerprint and the level is there so wallets can recognize implicit derivation steps.
Say you have a wallet which knows the private key to m/a/b. If it is given an xpub for m/a/b/c (which contains the fingerprint for m/a/b and the index c), it can derive the xprv for m/a/b/c by looking up the xprv for m/a/b using the fingerprint as lookup key, and computing its child c.
In retrospect, I'm not sure it was necessary to put this information in the xpub, and I don't know if it's actually used for this purpose. BIP32 was written in 2012-2013, and the Bitcoin world has changed a lot since then.

So if a wallet gets, for example, a ZPUB, it won't recognize that it's BIP84 and should use a certain type of derivation path and use those keys for a certain purpose?

That depends on the wallet. Most wallets don't support zpubs at all, AFAIK.

Yes, but it should be some behavior? Let's also say that the answer to the previous question is correct (that it is such a wallet), although XPUB is defined according to the BIP32 standard, if the wallet receives XPUB, should it follow BIP44? According to all this, it turns out that all this is only for people to better understand the given key...

Wallets (and software in general) chooses which standards to support; these things are not absolute. Just because someone wrote a document somewhere saying that "xpub" means this or that, does not mean every piece of software is obliged to follow that. Bitcoin Core for example supports BIP32, but not any of the ypub/zpub/... things, so it makes absolutely no assumptions about key paths or address types when an xpub is imported. You need to tell it what to do with it (see the output descriptor examples in my answer).

So if most wallets don't support ZPUB, YPUB... we'll just give them XPUB (XPRV) (magic will be 0x0488B21E for public key) and then "tell" them to use, for example, BIP84 if it's ZPUB. So then they will know that for that XPUB they should use the derivation path from BIP84 and for what purpose will the keys derived from that extended key be used? If the wallets support ZPUB, then we shouldn't "tell" them to use BIP84 because they will recognize it by giving them ZPUB (magic will be 0x04b24746 for public key) and not XPUB? Did I get it right?

Maybe, I don't know how exactly the zpub standard works.

Apparently they are defined in SLIP-0132 (https://github.com/satoshilabs/slips/blob/master/slip-0132.md), which indeed specifies which derivation paths to use as well.

It is defined in BIP84 (https://github.com/bitcoin/bips/blob/master/bip-0084.mediawiki#extended-key-version). But the point is: if a wallet doesn't support anything other than XPUB/XPRIV, I give it to the wallets and define the standard they should follow (BIP44/BIP84...); on the other hand, if the wallet supports anything other than XPUB/XPRIV, it should recognize the standard from the value in the magic word?

That depends on what they support.


text:
What is the difference between a 'hot' and 'cold' wallet
Problem
I don't understand the difference between a 'hot' crypto wallet, and a 'cold' crypto wallet.
Assumptions

My understanding of blockchains is that they use public/private cryptography in order to transact.

A wallet address is a public key.

A private key allows a user to send transactions.

Technically all wallet addresses already exist (defined by a hash function that generates a public/private key pair) and therefore are just waiting for someone to use these keys to start transacting.

Blockchains are essentially a distributed database which have data relating to the balances of cryptocurrencies (among other things)

Question
I've read that 'hot' wallets are connected to the internet and therefore less secure, whilst 'cold' wallets are not connected to the internet and therefore more secure.
I want to know if this is actually fundamentally wrong - because public keys are neither connected or disconnected to the internet - they are generated using an algorithm and then used to sign transactions. When crypto is sent to some wallet address in a 'cold' wallet - the cryptocurrency is not moved off the blockchain, it is just associated with some public/private key pair.
Is my understanding wrong - or is there just a huge misconception about what a cold/hot wallet is.

Does this answer your question? What kinds of wallets are there?

Whilst that post does cover what wallets are - it does not really discuss them in terms of my assumptions listed above. I was trying to understand what 'being connected to the Internet' had to do with the use of public and private keys.

TL;DR: hot / cold wallets refers to whether or not the private keys are on Internet-connected systems or not.
I think this is closest to your misconception:

A wallet address is a public key.

While a wallet address is (mostly) a public key, that doesn't mean a wallet itself is. A wallet can mean a number of things, but they all involve (multiple) private keys:

A wallet can be a piece of software that implements a Bitcoin client, allowing the user to receive and send funds, by managing transactions and private keys.
A wallet can be a hardware device that is used in conjunction with a software wallet (previous point) to manage private key material more securely (the private keys never leave the device). This would better be called a "hardware signing device", perhaps.
A wallet can be a computer file containing private keys and/or transactions.
A wallet can be a sequence of words, called a seed phrase, that can be written down ("paper wallet") or even just remembered by a human ("brainwallet"; generally considered a bad idea), which allows a piece of software to recreate a set of private keys.

Importantly, wallets (of all shapes and forms) generally have multiple addresses, as best practices dictate constructing a new address for every payment one wants to receive (privacy reasons).
The distinction hot / cold refers to how the private keys to these addresses are managed. The colder the wallet, the further away from a network-connected device they are, and thus presumably the more assurance there is it cannot be broken into without physical access.

In theory, it would be possible to just use a single key pair as a 'wallet' though right? A wallet with multiple key pairs would be considered hierarchical deterministic (HD Wallet)

Yes, you could in theory have wallet software that only uses a single key/address; it would be devastating for privacy though. HD wallets are one way to manage multiple keys, and while that approach is essentially universal now (and the basis for several other standards), that wasn't always the case. Early Bitcoin software (before 2012-2013 somewhere) would just generate every key at random, independently.

My answer will never be better that the provided before but I would add that the term wallet has been very unfortunate because a wallet, cold or hot, is not actually containing any coins like traditional wallets made of fur and cloth do.  The purpose of those widely called wallets, if we insist to name them this way, is to keep ´securely guarded´ the private keys associated with the infinite set of public keys that can be generated from the seed phrase obtained when that wallet was first generated (Obviously after BIP 39 was widely understood, implemented and used).
A hot wallet will be less secure because the hardware that contains the seed phrase and individual private keys, is connected to the internet and some bug or any malicious observer could grant himself access and steal those credentials that would allow him to sign valid transactions and thus empty your UTXOs.
A cold wallet, instead, never goes online, and the signing of the preformatted transaction happens offline, so the private keys will never be online and will be used offline to sign the transaction properly.
As a caveat, if the cold wallet is not well configured and does not generate randomness properly and there is address reuse, that cold wallet is deemed useless as well.


text:
BitcoinLib SignRawTransaction JSON-RPC returns false when using private key
This is a repost of (JSON-RPC signrawtransaction returns false when using private keys) but I could not comment because of my reputation (new user).
I've been using BitcoinLib via Litecoin Testnet for a week now and I got stuck with SignRawTransaction. It returns false but when I use the RPC call via litecoin-cli
litecoin-cli.exe signrawtransaction 020000000152cf5e76f1ac0fd42e97ec60db30406b019621da497601b430e7adf5642e1fa20000000000ffffffff02e09c4100000000001976a914fbb4b6ef02914490e99f899cb8538b03105331df88acc095a905000000001976a91471efff92af2740dd4fe088fc3de98ceebaa4c13488ac00000000 "[]" "[\"cQ3HSi45qrfGGZjYAci22gATWfhb1QhWR8JGBHBbzbPsD8Uuu2n2\"]"

the result is OK.
This is how I use the SignRawTransaction (Sample):
SignRawTransactionRequest signRawRequest = new SignRawTransactionRequest("020000000152cf5e76f1ac0fd42e97ec60db30406b019621da497601b430e7adf5642e1fa20000000000ffffffff02e09c4100000000001976a914fbb4b6ef02914490e99f899cb8538b03105331df88acc095a905000000001976a91471efff92af2740dd4fe088fc3de98ceebaa4c13488ac00000000");
signRawRequest.AddKey("cQ3HSi45qrfGGZjYAci22gATWfhb1QhWR8JGBHBbzbPsD8Uuu2n2");

SignRawTransactionResponse signRawResponse = coinService.SignRawTransaction(signRawRequest);

Has anyone encountered this problem before?

Which version of BitcoinLib are you using?

BitcoinLib Version 1.7.1

How do you create the coinService instance? Can you provide a Minimal, Complete, and Verifiable example?

Since I'm using the testnet this is how I created the instance.
ICoinService coinService = new LitecoinService(true);

It could be a bug in the LitecoinService. I assume it works fine with the other implementations(?)

I can't reproduce this on my local. Can you provide a sample? It could be a .ZIP file, a GitHub repo, a Gist or whatever.

I'm sorry but there were missing inputs when I created my Raw transaction. This error has nothing to do with BitcoinLib.


text:
Why does Blockchain (the company) open source their code but not license it?
I'm very curious as to why Blockchain (the company) doesn't license their open source software. Also, does this mean we (the public) can just use their software and license it using Apache's 2.0 license?
David

What specific code are you talking about?

Well, I'm trying to create my own wallet and I now reallize that the V3-Frontend, calls back to the V3-Wallet (core) code. I want to modify and reduce the wallet's functionality and have it's look-feel be my UI changes. I do however want to use the bitcoin core wallet code (V3-Wallet) for whatever I produce as a wallet for the public to use with BTC. I'm really just curious why the company (Blockchain) would host their code openly without an open source license.

They do. For example, here you can see that this piece uses an ISC license. Without a license, you couldn't even creatively modify the code.

If they haven't put a license, it means it is "All rights reserved" You can refer to these questions about it:
https://stackoverflow.com/questions/4007674/whats-the-default-license-of-code-published-at-github
https://softwareengineering.stackexchange.com/questions/148146/open-source-code-with-no-license-can-i-fork-it
https://opensource.stackexchange.com/questions/1720/what-can-i-assume-if-a-publicly-published-project-has-no-license
It probably means "You can use it for yourself, and for small projects. However, if we want, we may shut down all your projects containing our code."


text:
multiple outputs, address forking
i did read up some stuff about bitcoin but never used it until today. i might be asking something very obvious, but how can i get rid of address forking? that is, after several transactions my address list grown and each has a tiny amount of btc(its a mess now, and it was unexpected for me). i would like to send further transactions without implicit generation of new addresses, how can that be achieved? i use bitcoin-qt or bitcoind.
should i be using createrawtransaction to reassemble my btc to one address and avoid forking in the future?

That's how it's supposed to work. Why don't you want your funds to be split between several addresses?

I think that I at least on a conceptual level answered your questions (of which I counted three). If you feel that I have not answered your question completely, it might help if you improved your question to have a clearer aim. I.e. pose each question by itself. If you feel that I have answered your question, please accept my answer.

If you have not seen this yet, here is a diagram by zerohedge.com I found enlightening in order to understand how transactions fit into the Bitcoin concept.
The wiki at bitcoin.it has a more in detail overview of the inner works of Transactions and the inner workings of Raw Transactions.
From what I understand inputs to Bitcoin addresses are always spent completely in a transaction, so whatever you don't assign to a recipient will be available to be collected by a miner as transaction fee. So you'd need to set your client software to use the same address as source as well as for the recipient address of the transaction's change.
You could create a transaction that collects the complete balance from your wallet and sends them to a single output address. However, it is beneficial to use more than one address in order to make it more difficult to connect different transactions as belonging to the same identity. The bitcoin.it wiki has more information on privacy concerns
Additionally, Gavin Andresen, the lead developer of the reference client explained in this question, why change is sent to another address.

I'd say that diagram shows more of miner part rather than transactions core. and there's no such thing as total privacy, you should have known that... anyway it's not my concern now, i'm just learning how to use bitcoins the different ways. thank you for pointing out the nature of spending and fees. i should go ask about createrawtransaction next.

Of course there is no total privacy, which I haven't claimed either. :)

Just a small error in your explanation. It's not addresses that are spent as a whole, rather it's inputs to a given address. Inputs can be seen as the individual amounts that were transferred in one go to an address. So if you received two payments of 1 BTC to an address, and then send 0.7 BTC from that address, then one of the 1 BTC inputs is spent. 0.7 BTC are sent to the destination and the 0.3 BTC in change are going to another address (usually a new one) that you own.

i understand it entirely now. those inputs, otherwise known as parts of transactions are spent. address(technically, pubkey) is just used to allow only an owner of a certain inputs to spend them, having them signed with his privkey. address does not store anything. it's just an identifier of a person(s) on the bitcoin network.

You can modify bitcoin client source a bit, so that it doesn't generate new addresses after using previous one. You actually need to set sth like keyUsed = false in getaddress and compile.
For consolidating use raw transactions, however bear in mind that creating a transaction from lots of previous outputs requires a lot of copy & paste, or some fun with pywallet to export all transactions.

i would have rather refrain from modifying cryptographic software unless i'm a hero like ones who write it. but creating raw transactions is sorta interesting, at least, at the beginning, or useful, at some point. and at least you know what you're doing.

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


text:
what is the different between bitcoin network and the bitcoin protocol
protocol and network seem like two separate things. When peeps refer to bitcoin then it could mean protocol, software (what do they mean by that) or the network (what exactly do they mean by that ?) or currency ?

The Bitcoin protocol defines the rules that software must follow in order to be a part of the bitcoin network. A user can run software to create what is called a ‘ bitcoin node’, and it is the collection of all of these nodes that creates a network.
If the software does not follow the protocol rules, then that node will be banned from the network by the other nodes.
Users can also interact with the network in other ways beyond running a node, for example there are many options for ‘light wallets’ that can be run on a mobile phone.
The native asset of the network is a cryptocurrency called bitcoin.

Bitcoin Network is a network of computers connected to each other in peer-to-peer fashion whereas a Bitcoin Protocol is/are the rules that govern this network.
Now, this computer that is a part of the Bitcoin network run a software which makes this Bitcoin Network and its functionalities possible, this software follows some rule/protocol which is nothing but Bitcoin Protocol.


text:
Looking to getting my money back from a scam
I was recently scammed by a company promising large returns using Bitcoin/FX trading. I hired someone to recoup my losses and they told me they had and sent photo proof that the money was in a cryptocurrency wallet. When I tried to withdraw the money, I was told I would have to deposit $300 worth of Bitcoin before I could withdraw my money. Is this a policy with cryptocurrency wallets or are they just trying to get more of my money? Thank you.


text:
Bitcoin node setup through Proton vpn possible?
Anyone able to get a bitcoin node to communicate through proton vpn?
Protonvpn does offer port forwarding. but i had no luck. bitnodes.io isnt finding it.
https://protonvpn.com/support/port-forwarding/

I got it working but I didn't use port-forwarding. I used split-tunneling.
This excludes Bitcoin Core from going through the vpn and opens up port 8333 to the internet.
If you'd like the details for this, let me know, I'll be happy to post them.

Hello, it would be appropriate for you to post the solution if you have found it. Basic details / steps are fine. This will ensure that any future visitors with the same question may be able to use your answer as a guide.


text:
Setting up lndk and need lnd to use http/2
Does anyone know how to get an lnd node to use http/2? I didn't see any parameters to use in the lnd conf file.
Basically lndk is returning this for me.
2024-09-11T20:52:09.129688888-04:00 WARN hyper::client::client - Connection is HTTP/1, but request requires HTTP/2

I figured it out. I'm not sure why but i had to add rpclisten=localhost:10009
I didnt have it defined cause i thought that was the default value.


text:
Why my bitcoin-cli getpeerinfo return an empty list?
I am running bitcoind and it is updating blocks as follows:

However, when I have run bitcoin-cli getpeerinfo, it only returns an empty list, but not peers connected. So if there is no peer connected to my node, how can my bitcoind node update and download blocks from internet?

Is it possible that at the time you issued the RPC command you accidentally had no connections, but at other times you do?

Was this call made at the same time the log lines were produced? Is your bitcoin-cli connected to the same instance of bitcoind that you were reading the logs of?

Yes, my bitcoin-cli is connected to the same instance of bitcoind, and when I restarted bitcoind after several days, rerunning getpeerinfo command shows the peer information. I think @PieterWuille was right that maybe it had accidentally no connections at that time.


text:
btcdeb and OP_CHECKLOCKTIMEVERIFY
I create a transaction with OP_CHECKLOCKTIMEVERIFY. The median time is not greater than my date that I set in my witness script, for that reason if I try to send it I receive:
error code: -26
error message:
non-final (code 64)

I'd like to understand how stack works, and I tried with btcdeb. Below my stack
script                                                             |                                                             stack
-------------------------------------------------------------------+-------------------------------------------------------------------
0439c55e                                                           | 3044022031b0e07db908a1b208551aa66b40350e84493677d05ea90fc6ac23f...
OP_CHECKLOCKTIMEVERIFY                                             | 0x
OP_DROP                                                            |
1                                                                  |
02930f63741e00c95a713ecdf3b8b9e0e87881381cba69541ba8a483eb30c8ba94 |
03c9e8dd40cc9fc523823171a603197857a5f9718f679bd5c1a0cf68c06db10435 |
02c70779c5685e46e6fb098d6ccc3ae040a85c6e19a3890cc255504edf87d98936 |
3                                                                  |
OP_CHECKMULTISIG                                                   |
#0000 0439c55e
btcdeb> step
        <> PUSH stack 0439c55e
script                                                             |                                                             stack
-------------------------------------------------------------------+-------------------------------------------------------------------
OP_CHECKLOCKTIMEVERIFY                                             |                                                           0439c55e
OP_DROP                                                            | 3044022031b0e07db908a1b208551aa66b40350e84493677d05ea90fc6ac23f...
1                                                                  | 0x
02930f63741e00c95a713ecdf3b8b9e0e87881381cba69541ba8a483eb30c8ba94 |
03c9e8dd40cc9fc523823171a603197857a5f9718f679bd5c1a0cf68c06db10435 |
02c70779c5685e46e6fb098d6ccc3ae040a85c6e19a3890cc255504edf87d98936 |
3                                                                  |
OP_CHECKMULTISIG                                                   |
#0001 OP_CHECKLOCKTIMEVERIFY
btcdeb> step
script                                                             |                                                             stack
-------------------------------------------------------------------+-------------------------------------------------------------------
OP_DROP                                                            |                                                           0439c55e
1                                                                  | 3044022031b0e07db908a1b208551aa66b40350e84493677d05ea90fc6ac23f...
02930f63741e00c95a713ecdf3b8b9e0e87881381cba69541ba8a483eb30c8ba94 | 0x
03c9e8dd40cc9fc523823171a603197857a5f9718f679bd5c1a0cf68c06db10435 |
02c70779c5685e46e6fb098d6ccc3ae040a85c6e19a3890cc255504edf87d98936 |
3                                                                  |
OP_CHECKMULTISIG                                                   |
#0002 OP_DROP
btcdeb> step
        <> POP  stack
script                                                             |                                                             stack
-------------------------------------------------------------------+-------------------------------------------------------------------
1                                                                  | 3044022031b0e07db908a1b208551aa66b40350e84493677d05ea90fc6ac23f...
02930f63741e00c95a713ecdf3b8b9e0e87881381cba69541ba8a483eb30c8ba94 | 0x
03c9e8dd40cc9fc523823171a603197857a5f9718f679bd5c1a0cf68c06db10435 |
02c70779c5685e46e6fb098d6ccc3ae040a85c6e19a3890cc255504edf87d98936 |
3                                                                  |
OP_CHECKMULTISIG                                                   |
#0003 1

OP_CHECKLOCKTIMEVERIFY is not satisfied but the stack is still valid. I thought that when OP_CHECKLOCKTIMEVERIFY check 0439c55e, mark the transaction invalid and exit form the stack

The non-final error has nothing to do with script. It means you have a locktime or nsequence value in that prevents the transaction from being included in the next block.

@PieterWuille thanks, in that case in impossible to execute the stack, because the transaction halts before it?

Indeed. The script isn't even executed or looked at.

How can I replicate a scenario where CLTV fails inside the stack?

@PieterWuille Ok , I need to set locktime lower than OP_CLTV in oder to get error: Locktime requirement not satisfied during execute the stack.

That sounds like what you wanted?

@PieterWuille yes. First step check locktime with median time, after that check OP_CHECKLOCKTIMEVERIFY with nlocktime. the date value of OP_CHECKLOCKTIMEVERIFY must be equal locktime and greater than median time, right?


text:
Error opening block database Full node
For some reason my node shutdown and now I get when restart it
Error opening block database

here my bitcoin.conf
txindex=1
reindex=1
reindex-chainstate=1
# Accept command line and JSON-RPC commands.
server=1
# Options only for mainnet
[main]
# Options only for testnet
[test]
# Options only for regtest
[regtest]

this is my debug.log
2020-08-29T07:17:24Z Bitcoin Core version v0.19.1 (release build)
2020-08-29T07:17:24Z Assuming ancestors of block 00000000000000000005f8920febd3925f8272a6a71237563d78c2edfdd09ddf have valid signatures.
2020-08-29T07:17:24Z Setting nMinimumChainWork=000000000000000000000000000000000000000008ea3cf107ae0dec57f03fe8
2020-08-29T07:17:24Z Using the 'standard' SHA256 implementation
2020-08-29T07:17:24Z Default data directory /home/bitcoin/.bitcoin
2020-08-29T07:17:24Z Using data directory /home/bitcoin/.bitcoin
2020-08-29T07:17:24Z Config file: /home/bitcoin/.bitcoin/bitcoin.conf
2020-08-29T07:17:24Z Using at most 125 automatic connections (1024 file descriptors available)
2020-08-29T07:17:24Z Using 16 MiB out of 32/2 requested for signature cache, able to store 524288 elements
2020-08-29T07:17:24Z Using 16 MiB out of 32/2 requested for script execution cache, able to store 524288 elements
2020-08-29T07:17:24Z Using 4 threads for script verification
2020-08-29T07:17:24Z HTTP: creating work queue of depth 16
2020-08-29T07:17:24Z No rpcpassword set - using random cookie authentication.
2020-08-29T07:17:24Z scheduler thread start
2020-08-29T07:17:24Z Generated RPC authentication cookie /home/bitcoin/.bitcoin/.cookie
2020-08-29T07:17:24Z HTTP: starting 4 worker threads
2020-08-29T07:17:24Z Using wallet directory /home/bitcoin/.bitcoin
2020-08-29T07:17:24Z init message: Verifying wallet(s)...
2020-08-29T07:17:24Z Using BerkeleyDB version Berkeley DB 4.8.30: (April  9, 2010)
2020-08-29T07:17:24Z Using wallet /home/bitcoin/.bitcoin
2020-08-29T07:17:24Z BerkeleyEnvironment::Open: LogDir=/home/bitcoin/.bitcoin/database ErrorFile=/home/bitcoin/.bitcoin/db.log
2020-08-29T07:17:24Z init message: Loading banlist...
2020-08-29T07:17:24Z Cache configuration:
2020-08-29T07:17:24Z * Using 2.0 MiB for block index database
2020-08-29T07:17:24Z * Using 56.0 MiB for transaction index database
2020-08-29T07:17:24Z * Using 8.0 MiB for chain state database
2020-08-29T07:17:24Z * Using 384.0 MiB for in-memory UTXO set (plus up to 286.1 MiB of unused mempool space)
2020-08-29T07:17:24Z init message: Loading block index...
2020-08-29T07:17:24Z LevelDB using max_open_files=64 (default=1000)
2020-08-29T07:17:24Z Wiping LevelDB in /home/bitcoin/.bitcoin/blocks/index
2020-08-29T07:17:24Z Opening LevelDB in /home/bitcoin/.bitcoin/blocks/index
2020-08-29T07:17:24Z leveldb: Delete type=3 #1
2020-08-29T07:17:24Z Opened LevelDB successfully
2020-08-29T07:17:24Z Using obfuscation key for /home/bitcoin/.bitcoin/blocks/index: 0000000000000000
2020-08-29T07:17:24Z WriteBatch memory usage: db=index, before=0.0MiB, after=0.0MiB
2020-08-29T07:17:24Z Initializing databases...
2020-08-29T07:17:24Z LevelDB using max_open_files=64 (default=1000)
2020-08-29T07:17:24Z Wiping LevelDB in /home/bitcoin/.bitcoin/chainstate
2020-08-29T07:17:24Z Fatal LevelDB error: IO error: /home/bitcoin/.bitcoin/chainstate/449175.ldb: Bad message
2020-08-29T07:17:24Z You can use -debug=leveldb to get more complete diagnostic messages
2020-08-29T07:17:24Z Fatal LevelDB error: IO error: /home/bitcoin/.bitcoin/chainstate/449175.ldb: Bad message
2020-08-29T07:17:24Z Error: Error opening block database
Error: Error opening block database
2020-08-29T07:17:24Z Shutdown: In progress...
2020-08-29T07:17:24Z scheduler thread interrupt
2020-08-29T07:17:24Z Shutdown: done

As said in the log, "You can use -debug=leveldb to get more complete diagnostic messages".. Also, an IO error is very likely hardware-related.

@darosior thanks for the reply, with -debug=leveldb I don't have more information. I Can access and write without problem on my HDD


text:
Is there a subgroup of order 2^n (for large n) of the prime field that secp256k1 is defined over?
the curve secp256k1 is defined over the prime finite field F_p with p = 2^256 - 2^32 - 2^9 - 2^8 - 2^7 - 2^6 - 2^4 - 1.
Is there any known cyclic subgroup of order 2^n of F_p?

No, there cannot be.
There are two groups defined by the secp256k1 field, the addition group, and the group of multiplication of its non-zero elements.
Neither has a large 2n subgroup, because the order of a subgroup of a finite group must be a divisor of the order of that group.

The order of the additive group must divide the size of the field, namely p, the modulus itself, which is prime, and thus only has itself and the trivial group as subgroups.

The order of the multiplicative group of a field is one less than the size of the field, so p-1, which factors as 2 * 3 * 7 * 13441 * 205115282021455665897114700593932402728804164701536103180137503955397371. Thus, it only has C2 (the cyclic group with two elements) as subgroup whose order is a power of two. Specifically, in the embedding in the secp256k1 multiplicative group, that subgroup consists of the elements 1 and p-1, and the multiplication between them.

@user108963: the answer is correct. The question is about the prime field of order p that secp256k1 is defined over, independent of other parameters of secp256k1 (like b=7, and the curve order n). If we change the question to make it about a subgroup of the elliptic curve group secp256k1, the answer remains NO, because the order of a subgroup divides the order of the group, which for secp256k1 is the prime n, thus any subgroup of secp256k1 has order 1 or n, and none of 1 or n is a large power of 2.

@fgrieu okey, that's true.


text:
Secp256k1: Does there exist an identity public key for combinations of public keys?
I am aware that the identity on elliptic curves is the infinity element.
Long shot (as it would be very useful to me): with that being said, does there exist a public key, pk, on secp256k1 such that, combine(pk, x) = x for all x?
combine is via (https://github.com/bitcoin-core/secp256k1/blob/cd470333351bd6d90296352f2a957f38bbdaf014/src/secp256k1.c#L725)

As you pointed out, the identity is the point at infinity. It is also the only identity for addition over the elliptic curve.
But infinity is not a valid public key, for a number of reasons, and thus also not a valid input to combine.


text:
createrawtransaction, multiple outputs, single input?
following the manual on https://bitcointalk.org/index.php?topic=101525.0 , i would like to merge multiple fractions of BTC from multiple addresses i own, to another single address i own(reassemble, sort of, organize stuff). how will my approach look like? i still don't get what does "vout" value mean in the createrawtransaction? i think it's about this:
# assume i would like to merge transactions "aaaa..." and "bbbb..." to address "1mainaddr..."
# "aaaa..." has 0.01  btc unspent
# "bbbb..." has 0.0105 btc unspent
# "1mainaddr..." is emtpy
# i would like to pay 0.0005 btc as a fee

createrawtransaction [{txid:aaaa...,vout=0},{txid:bbbb...,vout=1}] {1mainaddr...=0.02}

is that correct?
i would like to first test this on testnet but still waiting on block confirmations. i'd appreciate 1-2 testnet BTC on moBHB5euzHyKtcabpD3UND9PYB994cisqb and will return it to you once block 101602 is confirmed.

i'm feeling like i should rephrase that to "what is vout". specifying all vout:0 works just fine.

I agree, "What is the 'vout' parameter and what value should it for createrawtransaction?" would be a much better title for this question. :)

The answer to "In getrawtransaction, what is the vout integer in the vin list?" might be helpful to answer this question.

ok, i figured it out. the correct answer to the following example will look this way:
# get your unspent transactions
listunspent
# select the ones you want to pour BTC from, please also note their 'vout', it is an output of a transaction you own a private key to and therefore able to spend.
createrawtransaction '[{"txid":"aaaa...","vout":0},{"txid":"bbbb...","vout":0}]' '{"1mainaddr...":0.02}'
# explained: you are using two outputs, of total 0.0205 BTC. you give away 0.0005 fee and you keep 0.02 at your 1mainaddr...
# you can dump the resulting transaction draft to see how it'll look like
decoderawtransaction <...result_from_createrawtransaction...>
# sign it with your private keys
signrawtransaction <...result_from_createrawtransaction...>
# if it returns you a hex with "complete" : true, you can now send it off to network
# if it returns "complete" : false, you either don't have a private key for signing, or you might have specified invalid 'vout'. google for more possible problems, those were two i experienced.
sendrawtransaction <...result_from_signrawtransaction_hex...>

references:

people.xiph.org/~greg/signdemo.txt
bitcointalk.org/index.php?topic=101525.0

thanks:

@Murch

this is a manual for original satoshi client.

From the command line, you need to add commas around the parameters and format the JSON correctly.
For example:
bitcoind createrawtransaction '[{"txid":"aaaa"...,"vout"=0},{"txid":"bbbb"...,"vout"=1}]' '{"1mainaddr"...=0.02}'

vout is the serial number of the output you're redeeming in its transaction.
For example, if you want to redeem the first output in the transaction with hash X, you specify X for txid and 0 for vout. If you want the second output in that transaction, you specify 1 for vout instead, etc.

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


text:
What is the best bitcoin software wallet where I can import my mnemonic seed phrase?
I have BTC mnemonic seed phrase and I want to import to my wallet.
I'm not a fan of online bitcoin wallets, and I want to install a software wallet.
What is the best software wallet for this?
I'm not sure but can I import the BTC mnemonic seed phrase to MetaMask?
Thanks

MetaMask ist not a bitcoin wallet, but almost all wallets use BIP-39 mnemonic phrases. You can import a (12 word) mnemonic in MetaMask, but you cannot use MetaMask to send or receive bitcoin.
You should also be mindful where you import your mnemonic. Browser based wallets such as MetaMask are naturally not as secure as wallets natively installed on your system.
There is no "best software wallet" as this question is completely subjective. My recommendations would be Sparrow Wallet (Desktop) or if you are looking for a more beginner friendly mobile wallet check out BlueWallet. The latter will make it easier for you to "find" your bitcoin if you do not know what derivation path or script type you used.

Never digitise your Seed Recovery information, except to a hardware wallet or other dedicated airgapped device. Certainly never on anything capable of connecting to the internet.
Etched onto steel plates, stored in multiple secure locations far from home, secure passphrase separately from 24-word mnemonic.
The HWW is irrelevant if lost or stolen NP.


text:
What is a functional infrastructure required to run a Bitcoin blockchain?
I need to understand what type of functional infrastructure required to run a Bitcoin. I found following article on the topic but I'm still not clear what is a "functional infrastructure" for bitcoin. I would appreciate an easy to understand explanation.
https://imiblockchain.com/blockchain-infrastructure-requirements/

What is a functional infrastructure required to run a Bitcoin blockchain?

To run the whole Bitcoin blockchain:

A bunch of participants, each with

A computer device
Internet access
Bitcoin application software (e.g. Bitcoin Core)
Sufficient storage

Several participants with mining hardware and software.

To Participate

Any device for which there exists a Bitcoin wallet application


text:
Retrieve extended private key from child keys or sibling keys
I've looked through the various questions and answers regarding this topic but I can't find the answers to mine.
I lost access to my wallet since calling encryptwallet which crashed the bitcoin software.
I did many scans with all the tools available on github and also some that I wrote.
My wallet contains 4 masterkeys (m path) of which 2 can be decrypted with the password of the wallet and contains more than 1500 addresses. Only around 200 can be decrypted with the password.
I found the xpriv for these two decrypted masterkeys by importing them into bitcoin core with the sethdseed function.
I found in the hexadecimal chains of the portfolio 20 addresses which have not been encrypted and of which I therefore know the private key, the encrypted key, the pub key, the derivation.
I can't find any way to find the xpub of the other two mastrkeys which will have allowed me to find all the other private keys. The Chaincode is missing and can't find it in wallet.dat.
I tried to modify the Bitcoin code to convert according to the same logic as for the WIF key import but without success.
My questions are:

Is there a way to convert the public key like I did for the private key?
Can I find the sibling keys with the amount of private keys that I have recovered?
Do you see another way to recover my funds?

I anticipate a generous reward.
Thank You

You seem to know what you are doing but don't mention backups. Is there some problem with backup recovery we need to know about to avoid the same issue?

I only have the wallet.dat and the end of the debug.log, to avoid the same problem, never start encryptwallet without having a local copy of your wallet. Also the crash occurs when a large number of keys are present in the wallet. I don't know this so well, I've been trying to recover my wallet for 1 year, I've read a lot of subject since all this time. Thanks for your help

how would finding the xpub allow you find all other private keys?

I invite you to consult this post where everything is much better explained than I could do. https://bitcoin.stackexchange.com/questions/56916/derivation-of-parent-private-key-from-non-hardened-child?noredirect=1&lq=1

From what you've stated, there is no way to recover those private keys.
Bitcoin Core's wallet does not store xpubs, or even xprvs. It derives the private keys as needed from the seed. Furthermore, for the type of wallet you are using, Bitcoin Core uses exclusively hardened derivation, so the vulnerability you are referring to does not apply.
Additionally, it sounds like your wallet is in a state that should not occur. The wallet encryption for Bitcoin Core was specifically written to avoid having both encrypted and unencrypted data in the wallet. If encryption fails, it's supposed to crash which should force the database to revert to its previous state with nothing encrypted. It may be that you are looking at only the database file and not also with the database journal which can contain additional data (although it's supposed to be that the journal contains the encrypted data and the db only what is committed, and if it crashed, then the data was not committed).
However if you are looking at the database with it's journal, then you might also be looking at it in the uncommitted state and unencrypted keys are not actually deleted, just hidden as they are marked for deletion, but not yet actually deleted.

Thank you Andrew for taking the time to answer my questions so precisely, I do not have the database of this wallet having no knowledge of cryptographic blockchain at the time. The branch paths are m/0'/0'/n+'. The software version was 0.18. The wallet crashed because there was a maxrpctime argument of 10 seconds I think. I found the tool https://gist.github.com/fivepiece/e3293733d99c4935332f8c5959d7472b

I had another wallet.bak in the directory, and the encrypted mkey matches that wallet in my main wallet.dat. It is as if the two wallets had merged. I will look for another solution and try to find out why some keys are not uncrypred. I saw that it was impossible to find the masterkey (Key) with all the other informations (IV, cipher, plain text) in AES-256-CBC. I am not optimistic about recovering the wallet. But again thank you for answering with all your knowledge


text:
How to run bitcoind and lnd on separate machines on the same network
I have a bitcoin full node running on a raspberry pi 3b but it doesn't have enough memory to also run lnd at the same time so I'm trying to do that on a separate machine connected to the same network. I've read that this is possible but when I try to get it going I get this error:

It seems that the problem is when lnd tries to run getblockhash it can't talk to the machine running bitcoind. Any ideas how to make this work would be appreciated!

According to the logs, your lnd is trying to access the bitcoind RPC interface at the default http://localhost:8332, which only works if you have bitcoind running on the same machine. For a remote instance you will need to set the config option bitcoind.rpchost in your lnd.conf file to the IP address of the machine running bitcoind (see sample-lnd.conf). Additionally, if you haven't already, you will need to setup RPC authentication (options bitcoind.rpcuser and bitcoind.rpcpass).

This seems to have solved the error that was coming up so thank you, but now it just gets stuck at 2022-08-29 17:08:00.596 [INF] CHRE: Primary chain is set to: bitcoin and then eventually times out. Any more ideas?