text:
Can I lose my Bitcoin.com wallet if the company and the website database are destroyed?
I am planning to convert a part of my fiat currencies into BTC. I see that web wallet are a good balance between ease of use and security as it prevents breaking a device, being robbed physically, etc.
However I still have a question that the website support could not clearly answer: what if the website and the associated company are completely destroyed (bankrupt, whatever...) ?
Will my 12-word pass phrase still be useful to recover my BTC into another web-wallet ?
Thanks

bitcoin(dot)com is operated by scammers, best to stop using their malware asap.

@Jannes Why do you say they are scammer ?!

I have performed a few tests and it seems that the 12 word phrase is able to recover the wallet from any wallet client that supports this 12 word phrase method.
The 12-word is a human readable alias for a master key that links to each private key of a set of wallet.
I have installed Electrum which is a local client installed on Windows and it did successfully gain access to my Bitcoin.com wallet by using the 12-word phrase.
I deduce that these words are enough to recover my wallet even if Bitcoin.com falls down.
@Toomakesense: the question is not whether or not it is likely to happen but what would happen in case it is. Everything is possible even if it is unlikely!
Anyway thanks for your help


text:
What is a Bitcoin node?
There’s a lot of reference of "bitcoin node" in official FAQ or elsewhere.
But, what is exactly a bitcoin node ?
Is it a client like Bitcoin-qt or is it only a miner ? Or both ?

related: https://bitcoin.stackexchange.com/a/48441/5406

Bitcoin node refers to a "full" client. A "full" client is a client that owns the block chain and that is sharing blocks and transaction across the network. In opposite a Lightweight client can not be considered as a node because he doesn't share the block chain with the network.
Bitcoin network uses a client to client network infrastructure so there is no difference between a mining client and a non-mining client, they don't have any privileges.

Miner doesn’t need the full blockchain to operate, does they ? (I’ve mined bitcoin/litecoin in a pool without running a client)

When you are mining for a pool with a software like cgminer you are getting 'work' from the pool that is running a Bitcoin client.
The pool is sending you a partial header for a new block and you'll try a lot of nonces (random numbers) in order to find one that generates a very low block header hash with a lot of zeros. Cgminer is not a client at all it is just a program that is just doing basic calculations for the pool. I edited my answer to avoid any confusion between mining client and miner.

Mining without the full blockchain is only possible if you trust someone to tell you what the legitimate blockchain is. In the case of pooled mining, you're trusting the pool to not be evil (and, say, have you work on an alternate blockchain so that the pool's operators can do double-spends; only a major risk if they're >50% of Bitcoin's power).

"Node" refers to any computer that's running Bitcoin client software and participating in the peer-to-peer network by relaying transactions and blocks. It could also be mining, but it doesn't  have to.

source: Stack Exchange

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

sort: votes


text:
How to manually throttle CPU to make computer run cooler?
I am experimenting with Bitcoin initial block downloads.
One of my tests is running on a ThinkPad X1 Yoga and computer is getting pretty hot.
It it possible to manually throttle CPU to make computer run cooler?
It it possible to configure bitcoind to use less CPU?
Thanks for helping out!

@Prayank IBD only

You could perhaps try:
bitcoind -par=<n>

Where <n> is the number of script verification threads (-4 to 15, 0 = auto, <0 = leave that many cores free, default: 0)
The script verification thread is heavily used during the Initial Block Download, so limiting the cores it uses during IBD may help.
This flag and other flags that could potentially help can be looked up with bitcoind --help.

Thanks for sharing! I tried that, but even par=1 lead to overheating… I believe par is intended to free resources for other processes rather than mitigate overheating. That said, my use case is perhaps hardware-specific. Great answer though… it will likely help others.

Thanks for trying. Hopefully someone else can shed some wisdom on this, as I am curious and a bit surprised to hear that that doesn't work. It seems par was designed to limit core use and to me it is implicit that that should also mitigate overheating. I am not exactly sure how to actually check how many threads run, but if all threads still run on all cores even after flagging it, it may mean that par is not/no longer working as intended and it may need to be reported as an issue in the repo. To limit CPU use is a reasonable functionality to ask for to prevent machines from cooking.

I was able to solve overheating problem by disabling Intel Turbo Boost.
ThinkPad X1 Yoga now runs 20°C cooler and fans are quiet… slower IBD, but I’m no longer worried about cooking my hardware.
echo "1" | sudo tee /sys/devices/system/cpu/intel_pstate/no_turbo

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


text:
How to configure Electrum to open explorer in Tor Browser?
Is it possible to configure Electrum to open explorer in Tor Browser?
I would like to use Blockstream’s http://explorerzydxu5ecjrkwceayqybizmpjjznk5izmitf2modhcusuqlid.onion/.
Thanks!

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


text:
Are generated public/private keypair the most random possible?
The number of possible Bitcoin private/public keypair is very strong (2^160 which is 1,461501637×10⁴⁸).
However, if the random generator is not good enough, only a subset of all that "space" could be used which would considerably break the security of Bitcoin.
That kind of problem has already happened, like that Debian bug in the OpenSSL package.
How can we be sure that random generation is done so it could generated all private/public keypair from the possible "space" ?

Thanks to maschuett’s answer, I looked at the source code and CWallet::GenerateNewKey function calls CKey.MakeNewKey which uses OpenSSL RAND_bytes to generate random number.
Trusting OpenSSL, I think random number generation is secure enough. :-)

The source code is open take a look for yourself. I am no expert on cryptography though so I will leave the explanation of this to someone who is. This is the file that you would want to look over https://github.com/bitcoin/bitcoin/blob/master/src/key.h

There is a dirt simple, decades old, extremely fast, random number generator that is around ten lines of C code that is extremely random. Orders of magnitude more random and faster than any of the "Numerical Recipes in C". The problem is the technology is export controlled, and thus can't be legally incorporated into an open source code base...

What is that dirt simple extremely fast random number generator that you’re talking about ? How can that be ? The best random number source are when getting entropy from physical world : number of photons, number of electron, temperature variation and so on. I can’t believe 10 lines of code can do better.

No doubt that sensitive Analog to Digital measurements devices measuring white noise KTBW*NF voltages provide a great source for very random numbers, but how much readily available hardware supports that capability?  10 lines of code can't beat that, but it can beat about all the academic so called pseudo random number generators based upon causality.

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


text:
How can someone participate in Bitcoin reliably without a bank account?
If banks are what one wants to escape, as the banking system is corrupt. Therefore seeking an alternative currency, aka Bitcoin. How do you detach your life from the bankers? How is Bitcoin private? Isn't this what Bitcoin was supposed to do is provide an alternative to the money masters that have reigned supreme since 1913?

Hello jim, welcome to Bitcoin.SE!  Unfortunately, I don't really understand what you're asking.  Are you asking about how to buy and sell bitcoins without a bank account, or about some privacy issue, or what?  Also, as it stands your question is off-putting to those who may not accept your premeses about the banking system, but may still be able to answer your questions.  You can use the "edit" button to make changes if you wish.

The questions are all followed by question marks. I'm sorry if I was off-putting to you and people who do not understand the banking system as I have done much research into. You can use the edit button if you wish.

"How do you detach your life from bankers" is not a question about Bitcoin.  "How is Bitcoin private" is, but it's apparently unrelated to the previous one, and it's previously been answered.  "Isn't this what Bitcoin was supposed to do": What does "this" refer to?

First, anyone can use Bitcoin reliably without a bank account. In fact, there is no user registration, no credit check, and certainly no central institution that can reliably exclude users. Completely detaching your life from banking, however, should still be somewhat challenging:

To pay for groceries/clothing/gasoline/public transportation and other regular needs with Bitcoin will probably be hard. It can be done, but at this stage will require much more effort.
Emergency situations would really want you to have a fall-back. A broke down car in the middle of nowhere and stuck trying to get the tower to accept Bitcoin would suck, or, well, needing a taxi ride to the ER.
Obtaining bitcoins is harder without a bank account. You'd have to arrange to trade locally, which costs more time, is not without security risks, and a bit more expensive. Or convince your employer/your costumers to pay you in Bitcoin.
And you'd need to find an internet service provider that allows you to pay in another fashion than anything banking related.

Bitcoin is private in that nobody can easily see how much money you are holding or spending. It is not anonymous, because whenever you trade Bitcoin for anything else, your identity might be breached to at least your business partner, thus create a connection to your address or even several of your addresses.
With some nations having already declared Bitcoin's legal status (e.g. Germany), and some online services introducing Bitcoin as payment option(e.g. Shopify), also judging from news today (e.g. Time reporter doing her Christmas shopping exclusively with bitcoins), Bitcoin is spreading quickly. I'd say that with luck and a bit of patience, it might actually be comfortably possible to completely do without a bank account.


text:
Possible to use an already generated bitcoin address?
Back in June I was mining just to see what it was all about.  I grabbed bitcoin-qt, generated an address and put that address into the payout info of my account at the pool I was mining in.  I told it to send to my wallet for every .5 coins mined and during the time I let it run I managed to accumulate just over .5
I eventually quit running it, and sort of forgot about it.  I later formatted and re-installed, but I remembered my progress and backed up the folder containing my miner and my wallet.  Now it's Dec and my .5 coin is worth a bit of cash.  However I didn't export or back up my wallet, I just copied the folder.  Since there was no install routine I figured this was enough to preserve my addresses.
I still have the address I told it to send to and I can see the payout in the block chain and I see my address waiting for the payment.  Is there a way to put this address into my wallet or am I out of luck?

Are you sure the folder you copied doesn't have a wallet.dat file in it?

Yea, unfortunately it stores it in something like C:\users<user>\appdata\blah\blah\etc.  I ASSumed it would have everything it needed in the folder since there was no installation.

If you copied the appdata folder then it should contain the wallet.dat with your coins inside.

That's the problem, I didn't.  I uncompressed the bitcoin-qt archive to a folder of that name and stored it in a folder on my desktop that had my miner in it as well.  I knew that I could export or backup the wallet but didn't think it was necessary.  I thought the install would be "portable" because of it not having an installation routine.  You live and learn I guess  :(

You're out of luck if you don't have the wallet, only the address. If anybody could take control of an address they don't have the private key of, the whole system is broken.

Yea as I was laying there falling asleep last night it occurred to me if all you needed was the destination address...  well of course it seems silly now.  I really wish I had backed up that wallet file.  That's 500+ bucks down the drain.  Oh well that will teach me to pay closer attention next time.

For this answer, I'm going to assume that you were using the official Bitcoin client, Bitcoin-qt, since that's the most likely scenario.
If you still have the wallet.dat file from when you originally generated the address, you should be OK. If you did not save the wallet.dat file, then there will be no way for you to claim your money, and the bitcoins will just sit on the blockchain indefinitely. If you have the wallet.dat file, you can re-load it like this:

Install Bitcoin-qt on your new installation (Download Link)
Run Bitcoin-qt and wait until it updates the block chain.
This could take a very, very long time.
Stop Bitcoin-qt.
Go to Bitcoin-qt's data directory. You can find out where the directory is here.
If you are running linux, this should probably just be ~/.bitcoin.
Replace the autogenerated wallet.dat file with the one that you backed up from your miner.
Re-start bitcoin-qt

After this, the client should read your keys and calculate the money stored in this address.

I appreciate the info but sadly, I don't have the wallet.dat.  I even ran Recuva to see if I would have any luck of getting it but seeing as it was over 4 months or so that I formatted it didn't work, not that I expected it to.  Ah well, lesson learned the hard way not soon forgotten right?


text:
How many peers it MultiBit connected to? Can not send bitcoins
I have received bitcoins from an online wallet and I am now trying to send 0.05 BTC to another address. I have by now figured out that I need to set at least 0.0001 BTC as a sender fee (that error message was confusing, because it appears before has the opportunity to set that fee!).
I am now getting the error message “MultiBit must be online and connected to more than one peer to send bitcoin”. I can see from the status in the lower left corner that MultiBit is online, but I can not see the number of peers.

How can I check the number of peers?
Why is MultiBit not connected to more than one peer (if any)?
How long can it take to connect to more than one peer?

I am using MultiBit 0.5.14 with Ubuntu 13.10.

You can hover over the "Online" indicator to see the number of peers.
It should only take a few seconds to find more peers. This is dependent on the Bitcoin network though. You can force MultiBit to attempt to connect to a whole new set of peers by restarting it.


text:
Having trouble setting up the escrow function - returns transaction ID but doesn't get to blockchain?
Looking at both this example:
https://earlytemple.com:8181/index.jsp
and this example:
https://gist.github.com/gavinandresen/3966071
I think I plowed through everything to the point where I was doing it all right: I made sure the transaction funding the escrow account came from one of the two parties in the multisig address, in this case it was
createmultisig 2 '["02bf4782452f7605994a27ad130ff2d6ee7f2e3399f8c0be79a114a5c116794277","035602e50d80b4c0066d4bb004f33557b100d421f02a32cd853bb24ead7bbfd351"]'
which produced the escrow address 3QQTMoaJZzkRqWAavPJRvEcTTFt7sRxiPL.
I funded the transaction manually with createrawtransaction, pulling from one of these two accounts, then I created a redemption transaction, then I signed that the way specified in the instructions, then I went to the other machine running bitcoin-qt and signed the output of the previous signing operation with the private key on that side, then I tried a send operation from that machine (didn't let me) so I went back to the original machine and sent it from there (did let me) and it returned a transaction ID of 30a6693a74e9c60a34af0262c14e516dd4ffa75cb9f496cd2f6ba484135bbe2a, which does not seem to be getting into the blockchain.  I've had that happen about three times now.  I specified settxfee 0.0002 to make sure (I hoped) that I was paying to get it included?
Can anybody point me in the right direction here?  I really could get a lot of use out of this function if I could get it to work, and I just can't figure out what I'm doing wrong.

Struggled with this for a while as well. You need to announce the transaction to your local node and the network via the sendrawtransaction call with the raw transaction id.


text:
Are contrived combinations of address format and segwit version program possible?
I wonder that I'm unable to see how exactly BIP 0341 forbids v1+ segwit from using bech32.
Does consensus allow combining v1+ segwit programs with the bech32 format?
I could expect v0 segwit was maybe defined back in the day so to use bech32 in a somewhat hardwired fashion that allows for no tricks. But it obviously allows to hide the script behind a P2SH hash, so 'choices' exist.
Does consensus allow combining v0 segwit programs with the bech32m format?

You seem to be mixing two different things. bech32 and bech32m are address types. Taproot and segwit v0  wsh/wpkh are output formats for taproot and v0 spendings, respectively. Those are two different things, address is a common way to encode the actual script, but the network only sees scripts. You can use bech32m for v0, but this is not standard and hardly supported, but it's not consensus.

I wonder that I'm unable to see how exactly BIP 0341 forbids v1+ segwit from using bech32.

BIP341 has nothing to do with this; it specifies consensus validation rules, not address encoding.
BIP350 however specifies that Bech32m must be used for v1+ segwit, and Bech32 for v0 segwit. The older BIP173 specified that all witness outputs (v0 and v1+) use Bech32.

Does consensus allow combining v1+ segwit programs with the bech32 format?

As far as consensus rules are concerned, addresses do not exist (only scripts do). Conversion from/to addresses is something done by wallets (and other user-facing software), and thus if such software follows BIP350, they'd use Bech32m for v1+ segwit outputs.
Old pre-BIP350 software however might use Bech32 for such outputs, meaning such software won't accept addresses created by BIP350-compliant wallets. This is deliberate (from BIP350):

Experiments by Taproot proponents had shown that hardly any wallets and services supported sending to higher segregated witness output versions, so little is lost by breaking forward-compatibility. Furthermore, those experiments identified cases in which segregated witness implementations would have caused wallets to burn funds when sending to version 1 addresses. In case it is still in use, the chosen approach will prevent such software from destroying funds when attempting to send to a Bech32m address.

Does consensus allow combining v0 segwit programs with the bech32m format?

Again unrelated to consensus, but BIP350 does not allow this (and neither does BIP173).


text:
Is it normal all testnet p2wsh cosigners have same master public key?
Created a testnet p2wsh Electrum multisig 2 of 3 wallet.
When I click on the radio buttons in Wallet/Information, all cosigners have same Vpub master public key. Normal?
Asking because I am trying out Electrum Personal Server and getting the following error.

WARNING:2019-06-28 08:15:00,335: Address not known to server,
  hash(address) =
  d***********. This
  means Electrum is requesting information about addresses that are
  missing from Electrum Personal Server's configuration file.

The EPS config.ini comments mention the following format for 2 or 3 wallets but when I use 2 Vpub Vpub Vpub the first 3 addresses of each master public key don’t match the ones I see in Electrum. Help!

multisig_wallet = 2 xpub661MyMwAqRbcFseXCwRdRVkhVuzEiskg4QUp5XpUdNf2uGXvQmnD4zcofZ1MN6Fo8PjqQ5cemJQ39f7RTwDVVputHMFjPUn8VRp2pJQMgEF xpub661MyMwAqRbcFseXCwRdRVkhVuzEiskg4QUp5XpUdNf2uGXvQmnD4zcofZ1MN6Fo8PjqQ5cemJQ39f7RTwDVVputHMFjPUn8VRp2pJQMgEF xpub661MyMwAqRbcFseXCwRdRVkhVuzEiskg4QUp5XpUdNf2uGXvQmnD4zcofZ1MN6Fo8PjqQ5cemJQ39f7RTwDVVputHMFjPUn8VRp2pJQMgEF

Not normal, each cosigner should have a unique master public key.
There is a reported bug in Electrum 3.3.6 that causes the issue on macOS.
Until a fix is pushed to production, it’s possible to get master public keys using the Electrum console (View/Show Console).
[k.xpub for k in wallet.get_keystores()]


text:
Retrieving bitcoin address of the receiver of a transaction with bitcoinrpc
I'm trying to write a simple python implementation using bitcoinrpc to extract the address receiving a transaction but...

I'm not sure why certain fields are only accessible inconsistently.  E.g. tx['vout']['scriptPubKey']['address'] is accessible 43 times in transactions in the first 10,000 blocks (but doesn't exist on the other 10,075 occasions).  The documentation mentions I should even find a tx['vout']['scriptPubKey']['addresses'] (plural) field but I can access that 0 times in the first 10,000 blocks.  I understand that there are different transaction/script types and that may impact things, for example the 43 times I found an 'address' field, the tx['vout']['scriptPubKey']['asm'] field for that transaction had this identical structure/opcodes: OP_DUP OP_HASH160 12ab8dc588ca9d5787dde7eb29569da63c3a238c OP_EQUALVERIFY OP_CHECKSIG.  I also notice that fields like tx['vout']['scriptPubKey']['asm'] and tx['vout']['scriptPubKey']['desc'] are at least always present so I'm hoping it's possible to extract the receiver address from them somehow?  At least for a subset of the possible types of scripts?  If so, does anyone know the best place to find a definitive list of the valid types of scripts and for which I could extract the addresses?

The "desc" field has a structure like 'desc': 'pk(04b0db59592289864233ce40cf1dc7420e8b5e290b4402bd203545d330ece6ba841ffef40fa62b76596688a46e70b284f57566766b7d8bf75274b343164bafc8a3)#ef9sgeu5' but I'm struggling to find a description of the format used - e.g. does pk stand for public key?

Thanks for any thoughts at all

The "address" field in the Bitcoin Core RPC output is present for all transaction outputs for which a corresponding address exists. In the first 10000 blocks there are lots of pay-to-public-key (P2PK) outputs, which while possible to construct internally in wallet software, don't have a corresponding address format that allows instructing a payer to create such an output.
The existing address types in Bitcoin today are:

pay-to-pubkey-hash (P2PKH)
pay-to-script-hash (P2SH)
native witness addresses, for:

pay-to-witness-public-key-hash (P2WPKH)
pay-to-witness-script-hash (P2WSH)
pay-to-taproot (P2TR)

Whenever you inspect any output whose scriptPubKey matches any of these address types, the RPC output will report the address. But scriptPubKeys are free form byte arrays, and there is no strict requirement that they follow the structure encoded by any of the defined address types.
The "addresses" is older, and was deprecated and removed. Its purpose was listing the individual participants in bare multisig outputs. Such outputs predate the introduction of P2SH in 2012, and were never widespread. Today they're effectively unusable.
For documentation of Bitcoin Core's RPC, see the help RPC command, or https://bitcoincore.org. The https://bitcoin.org website is unrelated to Bitcoin Core, and its information is often outdated.
The "desc" field reports information about the output in "output descriptor" notation. This format is described in BIP380 and the following BIPs, and Bitcoin Core documentation about it can be found in its doc directory: https://github.com/bitcoin/bitcoin/tree/master/doc/descriptors.md. And indeed, pk() stands for public key, indicating a P2PK output with the argument as public key.

thanks that's incredibly helpful!  I also just realised I could use bitcoinrpc's deriveaddresses(tx['vout']['scriptPubKey']['desc']) which seems to either return addresses or throw an JSONRPCException if no addresses are associated to the vout

You can also check if the descriptor is of the form addr(), pkh(), wpkh(), wsh(), sh(),or tr(). Those have associated addresses.


text:
Why is the field 'hash' necessary in a bitcoin transaction?
Using bitcoin-cli decoderawtransaction I see results like...
{
  "txid": "d2183b3ea763f41a30ec5ba6fbf6e5f32e0ca6a5e8761249c533fe22190f71f1",
  "hash": "d2183b3ea763f41a30ec5ba6fbf6e5f32e0ca6a5e8761249c533fe22190f71f1",
  "version": 2,
  "size": 225,
  "vsize": 225,
   etc...

Why is the "hash" field necessary if the txid field is already a hash? (more specifically a double-pass through SHA-256 of the transaction's data)
I'm noticing in some transactions that txid and hash are equal, but in others they're not.  Appreciate any explanation on the difference since I'm struggling to figure it out through Google and the source code comments.

Note that Bitcoin transactions don't actually contain the txid or hash within them. This is only part of the decoding output from Bitcoin Core.
The hash is there because of segwit. Segwit specifies that witness data for a segwit input (i.e. signatures, scripts) are not part of the txid. Those are in a separate area in the transaction. You can see this information decoded in the txinwitness field. So the hash is over the entire transaction, including this witness data, but the txid is not. Since transactions that do not have any segwit inputs do not have witness fields for their inputs, the txid and hash are the same.

thank you - that makes sense regarding the hash field.  But if txid is not included in the transaction, is it also not included in the vin/vout fields within a transaction?

No, the txids for the outputs being spent are included. Just the txid of the transaction itself is not since you can calculate the txid from it.


text:
No accepted shares on cgminer (sync issue ?)
I don't really understand how cgminer works.
I try to mine using cgminer + cgwatcher on a BtcGuild pool but even after 1 hour mining I don't have any accepted or share block. What I don't understand is how cgminer sync with the current blockchain data??? Blockchain data is about 11Go. Should I find blk0001.DAT file in cgminer folder or Roaming folder?
Is it possible to keep miner tool (on a USB key) and keep data on the same USB key.
Thanx

CGMiner does not need to sync with the blockchain, the pool does. The pool keeps a copy of the blockchain and only sends you the block that is currently being mined. If you don't see any share on BTCGuild's website, you should check that your miner's username and password are correct (they can be different from your main username and password). If you see shares, but they are constantly rejected, then you have a connection problem between you and the pool server. If this is the case, try changing to another pool.

I do not have rejected block. I'm using a ATI w600. I don't know its hash rate power. Hashing rate is always equal to 0. Do I need to have an accepted block to know my hashing power. If my username is not correct should I have a special message? I don't know if I can send a log file to be more clear?

Yes, you can post your log file here. If the pool says you have a hashrate of 0, then they are not receiving any mined shares. If your CGMiner shows a hashrate of 0, then it means you are not mining (problem with GPU drivers, using a new version of CGMiner not designed for GPU mining, etc.)

I was using latest cgminer version (3.8.x), I downgraded to 3.7.2 to get GPU support. I installed ATI SDK to get OpenCL support (%system32%/OpenCL.dll is present). But when I run tests with cgwatcher I read OpenCL=-1 and so cgminer tells me that no GPU is usable... Are all ATI gpu supported for mining?


text:
Can i store multiple crypto currencies in one wallet?
Is it possible to make a wallet for BTC and store LTC and NMC or other coins in it?

I'm not sure if there is a software wallet to do this, but if you want it for cold storage, you can definitely create addresses for almost all the cryptocurrencies from a raw 256 bit private key. This allows you to just securely store the 256 bit key rather than the individual wallet files for multiple cryptocoins.
You can do this by:

Creating a 256 private key of 64 hex (0-9,A-F) digits
Open brainwallet.org and go to the "Generator" tab and select "secret exponent"
Paste your 64 hex digits into the "Secret Exponent" text box.
Select the coin type in the top right corner and the coins private key and address will be shown in the "Private Key" and "Address" areas.

As an example, the 256 bit private key A5F308EB5553464AD377C68D16CDB85F3C8D63CABAC8017BE6D9D9A43F7F0CDF is the following addresses:

BTC (Private): 5K5NXzAa7PE5irZFc9Va6eAN4zPfd2E9MBcrt1ea8j225ix6wpC
BTC (Address): 18S5Czkk3pp8vSwVsS8fD28HLxea6JcVc
LTC (Private): 6vP717i71ogxCET77yHXt2wY2Tx8ppgB7s22bCfbrBLdmZvbD5f
LTC (Address): LKMPLRJapi4sPj96g1RRwE5tVZKviuvMxS
NMC (Private): 74A5i3WERWPrjWmvkHmXhKLdgvR1Re3gGRJTZoRBpoNBk1JL8RM
NMC (Address): MvhoGrVjfRvNfThSmgkhsjB31aMhYnd5qs

Note that this is somewhat insecure as if someone knows the coin private key for one of the addresses, they can directly convert the coin private key back to the raw private key.
Also if you import a private key into a wallet program (eg: bitcoind), be aware that they may send change to new addresses.

Thanks. Seems like it was not a good idea to try it with multiple currencies in one wallet @.@ Then i must find how i can secure my ufasoft files then it would be working.

Ufasoft sent me the following on my question about the wallets they use "Private keys shared between all currencies in the Ufasoft Coin. But they have different address string for different currencies. Internally they are the same"

Here's a related question but it only describes UFASoft Coin, which seems like a windows-only desktop application. If you're looking for a cloud solution I've found HolyTransaction to work pretty good.

I don't know a real wallet program that does it, but if you look for a web wallet, VirCurEx might be something.
It's an exchange for different crypto-currencies and so you also have a web wallet for each of them.

I dont want to have all my money on a web wallet where it could be stolen all at once when something bad happens. I want to store 3-5 differenct coins but without installing several tools that hold a single coin type. When i find out where the Ufasoft Coin software stores my wallets i could go with it.

I can understand that you prefer not to. But as I said, there currently is no wallet that can fulfil your needs.

Yes and no, the wallet software for each is an independent piece of software built by the community around that single cryptocurrency. It's possible that third party developers have/will develop a multi-currency digital wallet, to date all I have found is http://ufasoft.com/coin/, but I have not used it personally.

My problem with the ufasoft solution is, that i can not find any information where my coins are really stored. My idea was to use my bitcoin public/private key on another currency.
It would be fine when someone can give me infos on where ufasoft stores its infos.


text:
Are Closed Prices just the last trade or are they averaged?
Since these exchanges run 24/7, are the posted close prices (say if the chart shows 1 hour increments like on bitcoinwisdom.com) based on the last trade for that time frame?  Or are they averaged over that time frame?

They are the endpoints. You can easily see that because in a bar chart, the bars always align with either the top or the bottom of the previous bar.


text:
Convert Base64 Private Key to WIF
How do I get my private key from this? I found an old file on one of my hard drives with a wallet address and something that looks like this (changed for obvious reasons).
What is this and how can I get my private key from it?
LZEuGNcDIJI5mRCATBouTmQgdpaycce0rDH/B//+w7v0hofB6+Apt0bepR8pUUxHEHAXHHAv7+67AHwh80Lx9g==

I tried this https://bitcoin.stackexchange.com/a/43438/105403. When I plug the WIF into bitaddress.org it's not matching my actual bitcoin address so I must be doing something wrong.

Hi, do you remember how you got this? Maybe which wallet you used?

The following using libbitcoin bitcoin-explorer (bx) piped command lines, see documentation to better understand the two piped examples below.
The 512 bit output below, leads me to believe the base64 encoded key is an HD key that already might have BIP 39 conversion and possibly BIP 39 passphrase applied.
1% echo -n LZEuGNcDIJI5mRCATBouTmQgdpaycce0rDH/B//+w7v0hofB6+Apt0bepR8pUUxHEHAXHHAv7+67AHwh80Lx9g== | bx base64-decode | bx base16-encode
2d912e18d7032092399910804c1a2e4e64207696b271c7b4ac31ff07fffec3bbf48687c1ebe029b746dea51f29514c471070171c702fefeebb007c21f342f1f6
Let's assume the path is the following Bitcoin path m/44'/0'/0'/0/0, then the compressed WIF key can be computed as follows:
2% echo -n LZEuGNcDIJI5mRCATBouTmQgdpaycce0rDH/B//+w7v0hofB6+Apt0bepR8pUUxHEHAXHHAv7+67AHwh80Lx9g== | bx base64-decode | bx base16-encode | bx hd-new -v 76066276 | bx hd-private -d -i 44 | bx hd-private -d -i 0 | bx hd-private -d -i 0 | bx hd-private -i 0 | bx hd-private -i 0 | bx hd-to-ec | sed 's/$/01/' | bx base58check-encode -v 128
L2Xa6v3zo12E813ssicXbjEeatdXa37J5532WwtdXYRzgzL9QSxw
The associated public address is as follows:
3% echo -n LZEuGNcDIJI5mRCATBouTmQgdpaycce0rDH/B//+w7v0hofB6+Apt0bepR8pUUxHEHAXHHAv7+67AHwh80Lx9g== | bx base64-decode | bx base16-encode | bx hd-new -v 76066276 | bx hd-private -d -i 44 | bx hd-private -d -i 0 | bx hd-private -d -i 0 | bx hd-private -i 0 | bx hd-private -i 0 | bx hd-to-ec | bx ec-to-public | bx ec-to-address -v 0
17Wnq9Nm5KcFtvhunSPN9WRTZxTUvkvri5
Your HD path path might be different.

You need to decode the base64 encoded string. After you've decoded it you will get the hex string that you could put into bitaddress.org to derive a WIF, or maybe it could be an HD seed.
<?php
$a = "LZEuGNcDIJI5mRCATBouTmQgdpaycce0rDH/B//+w7v0hofB6+Apt0bepR8pUUxHEHAXHHAv7+67AHwh80Lx9g==";
$b = base64_decode($a);
$c = bin2hex($b);

echo $c;
//returns 2d912e18d7032092399910804c1a2e4e64207696b271c7b4ac31ff07fffec3bbf48687c1ebe029b746dea51f29514c471070171c702fefeebb007c21f342f1f6

?>

Here's a fiddle:  http://phpfiddle.org/lite/code/3d4v-m1uf
Hopefully this gets you started. As skaht points out it could be a bip44 derivation key, or bip32, or something else.


text:
Undo files format change and reorg process question for v0.19
This is a follow-up question for rev.dat file format
Pieter Wuille gave a great explanation that is easy to follow. Since that posting there was a replacement of CTxInUndo with Coin, does the format still stands for the CBlockUndo record?

4 bytes: network magic (0xf9,0xbe,0xb4,0xd9)
4 bytes: size of the CBlockUndo record (LE32)
data_size bytes: CBlockUndo record
32 bytes: double-SHA256 of the serialized CBlockUndo record

CBlockUndo results in a serialized vector of CTxUndo records. Which is right now the serialized vector of Coin records.
And here is the Coin (or at least how I get it right now):

varint that is serialized: 2*height (+1 if it was a coinbase output): the height of the block that created the spent UTXO. By the way, is uint32_t{2} the same as (uint32_t)2 in TxInUndoFormatter varint Serialize
version dummy value 0: we do not use version anymore but for compatibility using a 0000 or zero value in here
CompressedAmount: spent UTXO's nValue
CompressedScript: spent UTXO's scriptPubKey

Questions:

Is it correct?
Does anyone by any chance have a detailed mind map of undo process and a byte format map for the CBlockUndo record?

Just for reference, I draw some image of current v0.19  and previous v0.13 versions
of rev*.dat file:

There have not been any format changes in 0.19 as far as I know. There last was a backward-compatible change in 0.15.

Thank you for responding.
So we can use the format that you described earlier and my pic of v0.19 is correct?

NOTES:
Heigh and Version fields
Fields height and version are needed to identify Outputs if they are last spent in the Transaction outputs. In older revxx.dat files, only if Output was last unspent in a Transaction it's height will be there together with it’s Transaction’s Version. If it's a regular Output then the height field will be 0 (00 HEX in Varint format ) and there will be no Version field
In newer revxx.dat files height is written for every Output and the Version field is 0 (00 in HEX) to be backward compatible. I did not check the revxx.dat files myself if it’s so, so please test this note first.
Calculation of Height from the Field Value:
To compress the Amount of Statoshis this field uses the following logic:
If the amount is 0, output 0
First, divide the amount (in base units) by the largest power of 10 possible; call the exponent e (e is max 9)
if e < 9, the last digit of the resulting number cannot be 0; store it as d, and drop it (divide by 10)
call the result n
output 1 + 10*(9n + d - 1) + e
if e==9, we only know the resulting number is not zero, so output 1 + 10(n - 1) + 9
(this is decodable, as d is in [1-9] and e is in [0-9])
Then store it as a VARINT
nValue field(Amount)
To compress the Amount of Statoshis this field uses the following logic:
If the amount is 0, output 0
First, divide the amount (in base units) by the largest power of 10 possible; call the exponent e (e is max 9)
if e < 9, the last digit of the resulting number cannot be 0; store it as d, and drop it (divide by 10)
call the result n
output 1 + 10*(9*n + d - 1) + e
if e==9, we only know the resulting number is not zero, so output 1 + 10*(n - 1) + 9
(this is decodable, as d is in [1-9] and e is in [0-9])
Then store it as a VARINT
Calculation of nValue field(Amount):
To decode this amount go through the operation backward:
First, decode it from VARINT. Then use the following procedure(taken directly from the Bitcoin core implementation):
uint64_t DecompressAmount(uint64_t x)
{
    // x = 0 OR x = 1+10\*(9\*n + d - 1) + e OR x = 1+10\*(n - 1) + 9
    if (x == 0)
        return 0;
    x--;
    // x = 10\*(9\*n + d - 1) + e
    int e = x % 10;
    x /= 10;
    uint64_t n = 0;
    if (e < 9) {
        // x = 9\*n + d - 1
        int d = (x % 9) + 1;
        x /= 9;
        // x = n
        n = x\*10 + d;
    } else {
        n = x+1;
    }
    while (e) {
        n \*= 10;
        e--;
    }
    return n;
}

ScriptPubKey size and SriptPubKey fields
Current Bitcoin serialization is using a compressed format to store common types of scripts:

Pay to Pubkey Hash (P2PKH) is encoded to – 20 bytes
Pay to Script Hash (P2SH) is encoded to – 20 bytes
Pay to Pubkey (P2PK) is encoded to – 32 bytes

Other script types are serialized using the general rule shown in the table:

scriptPubKey size
scriptPubKey data

Where script size is a VARINT field of len(scriptPubKey data) + number of special cases, where the number of special cases is int(6), then goes the regular scriptPubKey data.
The compression algorithm is removing all OP_CODE values from the common types of scripts and leaves only the Key, KeyHash, or ScriptHash intact. Then it is using the  field to indicate the type of script in the next field.

P2Pk cases: 0x02, 0x03 identify compressed Public Key and show how which Y coordinate to use to reconstruct the full key. 0x04, 0x05 identify uncompressed Public Key, but the value in the  is still in a compressed format and, and the size value shows which Y coordinate to use.
For other script types be sure to keep in mind that  is VARINT(len(scriptPubKey size) + int(6))
A small addition to the script compression, while you be looking through the Bitcoin core compress.cpp/.h files you may find that during compression either 20 bytes or 33/65 bytes are being manipulated that are not identified as any opcodes.
That's because of in bitcoin scripting if a field(4-bit hex value) is smaller than OP_PUSHDATA1 = 0x4c=76 is interpreted as an instruction to push the following number of bytes (the exact value of this field) onto the stack – this is called an immediate push.
As I'm not that good in modern C++, it was much easier for me to follow the compression algorithm when it was done in Golang:
https://github.com/btcsuite/btcd/blob/master/blockchain/compress.go
and in VarInt logic in Python:
https://github.com/christianb93/bitcoin/blob/1241778dc51bd39022611916f90f1bfaf07ee331/btc/serialize.py#L54
Greg did a really really nice explanation of Var Int, that I found so easy to follow. Thank you.
https://learnmeabitcoin.com/guide/varint
Yes, everything is in the code of original BitcoinCore implementation, I think maintainers and developers are doing an epic job to keep it nice and clear. It's because I was lacking some C++ skills I could not understand it properly from the beginning and had to spend some time on it. I just hope my notes will help someone to speed their learning process. Good luck.


text:
Optimising blockchain parsing with rpc + python
I have a python app to track and store utxo in a simple/flat structure that looks like this...
from bitcoinrpc.authproxy import AuthServiceProxy, JSONRPCException

# track the utxo
trackUtxoList = []

# rpc call 1
rpc_connection = AuthServiceProxy("http://%s:%s@127.0.0.1:8332"%(rpc_user, rpc_password))

for b in range(blockStart, blockLimit):

    # rpc call 2 (per block)
    blockhash = rpc_connection.getblockhash(b)

    # rpc call 3 (per block)
    block = rpc_connection.getblock(blockhash)

    for txid in block['tx']:

        # rpc call 4 (per tx)
        raw_tx = rpc_connection.getrawtransaction(txid,False,blockhash)

        # rpc call 5 (per tx)
        decoded_tx = rpc_connection.decoderawtransaction(raw_tx)

        for output in decoded_tx['vout']:

            # rpc call 6 (per vout)
            for l in rpc_connection.deriveaddresses(output['scriptPubKey']['desc']):
                trackUtxoList.append({'address':str(l),'value':output['value'],'block':b, 'txid':txid,'isUtxo':True})

        for output in decoded_tx['vin']:

            vinSearch = list(filter(lambda item: item['t'] == output['txid'], trackUtxoList))
            vinSearch[output['vout']]['isUtxo'] = False

The problem is that it runs very slowly for 2 reasons that relate to my 2 questions...

My blocks directory is on an external hard drive because it's too big for my laptop - pretty sure this will impact read-speeds and so I'm wondering if it's possible to somehow split the blocks directory so that for example, I could pull 100k blocks onto my laptop, process that, then delete and copy the next 100k blocks onto my laptop etc.  I've already split the blocks directory (on external hdd) from the rest of the data directory (on my laptop) but can't find any examples of people temporarily splitting the blocks directory itself.

I'm making 2 rpc calls per block, 2 per transaction and 1 per vout.  To my eye it looks like calls 5 + 6 (as commented in my code example) don't really need to use my rpc_connection since they are manipulations on data already pulled from the blockchain?  Whereas the others are essentials/unavoidable?  If that's correct, are there any python libraries that are typically used to decode transactions and derive addresses without using an rpc call?  I played a little with Buterin's https://pypi.org/project/bitcoin/ but since it's no longer maintained I wasn't sure whether it's my best bet.

Thanks for any thoughts at all on how to optimise my code to parse the entire blockchain

You're going to see much better performance by doing the parsing of block data yourself directly off disk, though that involves a decent amount of complexity.
If you want to stick with bitcoind RPC calls, I suggest using getblock(blockhash, 2), which will decode all transactions in the block for you in a single result, removing the need for decoderawtransaction.
Lastly, why the roundtrip through deriveaddresses? output['scriptPubKey']['address'] should give you the address directly.

wow - thanks so much for the tip on getblock(blockhash, 2) - didn't know that was possible but definitely sounds more efficient.  On your second question, sometimes the ['address'] key simply isn't present - in fact normally it isn't - if I could reliably access that field for every transaction I would definitely use it.  Not sure if there's any well-known non-RPC methods (or python tools) to derive an address from a descriptor?

You can just check whether the field exists, before accessing it.


text:
Bitcoin RPC BrokenPipeError on specific block/transaction
I have a simple python app running through the blockchain as follows...
rpc_connection = AuthServiceProxy("http://%s:%s@127.0.0.1:8332"%(rpc_user, rpc_password))
for b in range(blockStart, blockEnd):
    block = rpc_connection.getblock(rpc_connection.getblockhash(b))
    for txid in block['tx']:
        raw_tx = rpc_connection.getrawtransaction(txid)
        decoded_tx = rpc_connection.decoderawtransaction(raw_tx)
        for output in decoded_tx['vout']:
            print(rpc_connection.deriveaddresses(output['scriptPubKey']['desc']))

It successfully runs through all blocks from block 1 until block 115,257 where it encounters "BrokenPipeError: [Errno 32] Broken pipe".  It errors on transaction 11 (with txid 1c67abba71d570d0f0643b3d4ed93f528a68ef1c6a21e6d1f72535a15b0ce030).  Sometimes it errors on the rpc_connection.getrawtransaction line and sometimes it errors on the rpc_connection.deriveaddresses line but both times with a Broken pipe.
What's strange is that if I just run the script for the single transaction it works fine and I notice that the transaction before transaction 11 (i.e. transaction 10 with txid c45b2940e403a1598faaae33a24e385c92b4f051929a49fe3b079ef04b1e2dbc) returns an enormous result for rpc_connection.getrawtransaction() (pages and pages of console ouput) whereas all the others are about 3 lines of console output, and so I'm wondering if perhaps this is related to memory usage or timeouts or some conf setting that I don't have?
Has anyone run into a similar problem before?  Also, I'm guessing everyone gets the same enormous result for rpc_connection.getrawtransaction('c45b2940e403a1598faaae33a24e385c92b4f051929a49fe3b079ef04b1e2dbc')?  Really appreciate any thoughts on the best way around this problem.

What are you doing with the output of your script? Normally, BrokenPipeErrors occur when the process reading your script terminates early, e.g python myscript.py | head -n 100. head will terminate after 100 lines, but your script will still try to write to the pipe, which causes the BrokenPipeError. See https://stackoverflow.com/questions/26692284/how-to-prevent-brokenpipeerror-when-doing-a-flush-in-python for more info

thanks @josie - instead of the final "print" line in my example, I'm actually just appending to a list of dicts which once I exit the loop for a given block gets written to a file.  The list is about 600k lines large so far which seems relatively small.  And I'm just running directly like python3 myscript.py.

p.s. @josie - I noticed this morning it's actually throwing a new error (but at the exact same line): ConnectionResetError: [Errno 54] Connection reset by peer

It's difficult to tell what is a python error and what is a bitcoind error. perhaps you can try first running your script on signet. This will have fewer transactions and blocks and should at least tell you if the issue is related to the amount of data.

thanks @josie I'm pretty sure it's related to the volume data - I manually inputted the decoded transaction json and continued processing and ran into the same problem at block 118,597 right after another transaction which contains 438 vins.  hmmmm, not sure where to go with the troubleshooting now

just found a hacky fix: if I encounter a transaction with greater than a certain number of vins (around 200 in my experience), then I just reinstantiate the rpc_connection with rpc_connection = AuthServiceProxy("http://%s:%s@127.0.0.1:8332"%(rpc_user, rpc_password)) and it works.  Not sure if there's a more elegant way to flush/restart the rpc_connection or whether I'm spawning multiple sessions, but at least there's no more connection errors


text:
Why is creating a bitcoin fork very difficult and a Ethereum fork easy?
There are a dozen of projects based on Ethereum but very few based on the Bitcoin network. Why is this?

I'd like to point out that, technically, a fork is as difficult as it is modifying the source code of the project involved. Anyway, what makes a fork successful is the amount of adoption it manages to reach. So, if you want to measure the "difficulty" of a fork in terms of adoption, then we can say bitcoin forks struggle because they're overshadowed by the enormous popularity of bitcoin itself.

Forks of both are equally hard. What you're describing as "Ethereum forks" are actually tokens/smart-contracts that run on the Ethereum network, which isn't very common on Bitcoin (but there's Omni)
EDIT: Remved Rootstock as per darosior's clarification. Its only to relation to Bitcoin is that it uses merged mining, just like Namecoin.

Rootstock is not on the Bitcoin network.

@darosior Right, thanks.

I think it's also useful to mention that the reason why they are some many Ethereum-based tokens is that Ethereum was designed specifically for that purpose.


text:
How to clear peer list?
How to clear bitcoind's peer list? (also containing peers in the past)
I didn't find an RPC command for it, is it stored in a file?
Where?

You can stop bitcoind, and delete the peers.dat file in the data directory. On next startup, bitcoind will start a new one, by seeding from DNS seeds and other means.
Why, though? Generally the peers database you have will be better quality than the new initial one you get.


text:
How to get multiple vouts in one RPC call?
Is there an RPC call to get more (or better all) vouts for given transaction?
Iterating over each one takes a lot of network time.
gettxout txid 0
gettxout txid 1
gettxout txid 2
gettxout txid 3 -> returns empty, so last one

"getrawmempool True" doesn't have vout addresses with amounts.

You can get the entire transaction using getrawtransaction. This will include all vouts.

Yeah but it's raw hex, would you know a python parser for it? Segwit I guess is also encoded differently from legacy.

There is a a verbose parameter to have it be decoded by bitcoind and returned as json. See the help text.

That works great thanks! Although it requires block hash too.


text:
How exactly would anyone know from where I got a given "bit of Bitcoin", or who I send it to?
Let's say I buy 0.1 BTC using Bisq. Okay, so the person I bought it from will know my name since I have to give it up to make the international bank transaction. And I will know their name because that's how Bisq works and apparently has to work. Alright.
Us two strangers know each others' identities.
So, does this mean that the person I bought the 0.1 BTC from now can track exactly how I spend it? How? Isn't the truth that, at best, they can see when I spend it (if ever) and which "receive address" received it? Which tells them exactly nothing whatsoever?
Ever since I first heard about Bitcoin, over a decade ago, I've been trying to get clear answers on the most fundamental questions, but never receive anything but assumptions/guesses or such technical and in-depth explanations that they might as well be made up and I couldn't tell the difference between that and the truth.
The most common "explanation" is to vaguely state that "it's completely trackable and 100% non-anonymous", but that seems to be utter nonsense to me. It actually seems to be very anonymous. The person I bought the 0.1 BTC from cannot possibly know if I'm selling it, paying for something, or just moving it to another wallet of mine. They have no clue. It's just a gibberish string of computer-generated characters -- not a full name and address and photo id in a neat little digital package.
I seriously believe that only a handful of people in the world truly understand how Bitcoin works on any deeper level, and that all the others are just pretending in order to not be seen as "stupid". Like the old tale of the naked emperor.

I'd suggest editing out the last paragraph as it doesn't add anything to the question.

It's true that the receive address, all by itself, doesn't tell them anything.  But if it later becomes known whom that address belongs to, then they know that you sent money to that person.  So it's not so much that knowing the destination breaches your privacy in itself, but that it could be a piece of a puzzle that helps reveal information you'd rather not reveal.

All Bitcoin transactions are public information, and each transaction is uniquely identifiable via its txid. Each piece of bitcoin (called a transaction output) is uniquely identifiable as well by means of the transaction that created it, and the index of the output on the transaction. This makes the "outpoint" txid:vout the unique identifier of a UTXO.
So, what your trading partner learns is your name via the bank transfer, the address you gave them, and the transaction output they created for you. That alone is not very informative as you noted, but it can become useful in combination with large swaths of other information. For example, if multiple of your counterparties on Bisq collected the names of whom they trade with, they could cluster your addresses and unspents to the same name. They can also track your on-chain activity: when you spend the funds, they will assume that any other funds used in the same transaction are also owned by you, clustering the other addresses to you. When you send to a recipient and receive the remaining funds back as a change output, they may be able to guess which of the two outputs went to a recipient and which went back to you. In that case, they will be able to probabilistically associate your next payment to you as well. They may have information on the address that you sent to, because you paid into a KYC'ed entity like a payment provider or Bitcoin exchange. In that case, they learn more about the purpose of your payment, or potentially could even look up other account activity if you deposited into an account.
So, basically your bitcoin activity is generally private, in that no personally identifiable information is directly collected in the bitcoin network, yet it is also inherently pseudonymously associated with you which reduces your anonymity set depending on how traceable your activity is. However, since the blockchain is a permanent record, anyone sufficiently motivated and well-connected may be able to fill in the transaction graph to trace back step by step to you.
If you want to read more about privacy in Bitcoin, I would recommend this excellent treatise on the Bitcoin wiki: Privacy

does this mean that the person I bought the 0.1 BTC from now can track exactly how I spend it?

Lets imagine a scenario with three parties: Me, You and the chocolate factory. If I sell you 0.001 BTC, can I tell if you spend it on chocolate?
It's the early days of Bitcoin and I also like chocolate.
I use my wallet and send 0.001 BTC from my address III to the address CCC of the chocolate factory. The chocolate factory send me chocolate. The Blockchain records:
    III ----0.001----> CCC

Later you send me a bunch of $10 bills (banknotes) and I send you an equivalent amount of Bitcoin to your address YYY. The blockchain now contains:
    III ----0.001----> CCC
    III ----0.010----> YYY

Later still you buy chocolate. The blockchain now contains:
    III ----0.001----> CCC
    III ----0.010----> YYY
    YYY ----0.002----> CCC

I deduce that you have a secret passion for chocolate.
Nowadays most people use a separate address for each transaction to preserve privacy. But the transaction data is all public and there are businesses that specialize in blockchain analysis looking for patterns of usage that reveal how money is being used.

It's just a gibberish string of computer-generated characters

Some reading you might find interesting:

The Hut Six Story, Gordon Welchman, 0-947712-34-8
Station X, Michael Smith, 0-7522-7148-2
Codebreakers, F.H.Hinsley and Alan Stripp, 0-19-285304-X
Enigma, Hugh Sebag-Montefiore, 0-75381-130-8
Enigma and its Achilles Heel, Hugh Skillen, 0-9515190-1-8

These are all about exploiting poor habits of usage and implementation weaknesses into surprising ways of turning gibberish into information with life and death consequences.


text:
Can a regtest bitcoind node use SignRawTransactionWithKey + prevtxs for a mainnet raw transaction?
I want to know if a regtest nnode can sign a raw mainnet transaction with the signrawtransactionwithkey rpc provided that I pass the correct keys and prevtxs as the regtest node will not be aware of them?

No, you will get an Invalid private key error. Note that if you use a correct-network private key but it is the wrong key to sign the input you provide you get a different error: Unable to sign input, invalid stack size (possibly missing key)
The base58 prefix is checked against a constant value that is different for each network (main, regtest, etc)
const std::vector<unsigned char>& privkey_prefix =
    Params().Base58Prefix(CChainParams::SECRET_KEY);

https://github.com/bitcoin/bitcoin/blob/master/src/key_io.cpp#L132-L148

If I was to set the -pubkeyprefix and -secretprefix to the same values as mainnet would that work?

Hm are those actual command line parameters? I don't see those terms grepping the codebase. What do you mean?

Oh, you are correct those are daemon options for Elements Project. With Elements you can set those params.

I see. Cool. Ya know, you don't need a full node to sign a TX if you have all that data. There's libraries and toolkits written in other languages etc that might suit you better

Ya, I have been using NBitcoin but it can't sign Elements transactions for some reason.


text:
Can 2 bitcoin-cli's use the same blocksdir
I am trying to set up 2 clients with both using the same block directory is this possible?

bitcoin-cli simply acts as a convenience interface to the JSON-RPC api of bitcoind - as long as you only have one instance of bitcoind using a given datadir, you can safely use multiple bitcoin-cli calls at the same time.

Right, though beware of the maximum number of concurrent calls (4 by default, adjustable with-rpcthreads). bitcoind will ignore any calls made above this limit.

Does this mean that by default only 4 bitcoin-cli can ever use the same blocksdir or only 4 at a time?


text:
Crypto wallet for payments with no deposit
We are wondering how we can build a wallet that talks to our website and gives the user the ability to request a withdrawal of his funds. We do not know what is the right question for this type of functionality that we want to build is, so any advice would be much appreciated:
The flow would be the following ->
a: User got rewarded in crypto (BTC, XRP, ETH, LINK) (a digit on the database).
b: User withdraws his reward to their address.
The reward gets credited to the user's account (simply a digit on the database), and NOT to user's wallet address, as the wallet should NOT generate new addresses for deposits, as we do not want to allow deposits at all.
To help with the explanation, Bitcoin faucet websites have such functionality usually, where you can withdraw your earnings but not deposit funds in them.
Cheers

There are many layers to this question. Also, I'm going to assume using just Bitcoin, for simplicity. For other cryptocurrencies the procedure would be mostly similar with important differences mostly in the backend.
On the Bitcoin layer, the simplest solution would be to have a separate wallet for the website.
On the interface layer, you can have a simple form on your website where the user can input the address when requesting fund withdrawal.
On the backend layer, your website can use any wallet software with an API or CLI, Electrum should be good, but is just an example. This API or CLI could be then invoked to make payments to users.
Your server would necessarily have access to the private keys for the website wallet, therefore security should be an important consideration. The wallet file on the server needs to be protected and the backend of your website must properly check the withdrawal amounts, properly authenticate users and properly mitigate common attacks. If you don't have experience with website security, there are many potential holes that can open avenues for attack. Elaborating on them is beyond the scope of Bitcoin StackExchange. The important precaution would be not to keep more funds than necessary on the website wallet and deposit more as needed, manually, from a wallet on your own computer.
(This answer was edited by author as a result of a discussion in the comments)

There is no need for a 'master address', just a wallet that can programatically process withdrawal requests. A master address is just bad privacy for everyone involved.

That's a valid point, @chytrik. Using a modern wallet with change addresses is much better for privacy, although it doesn't really protect from transaction linking by determined attacker. There are also transaction cost considerations, especially with small amounts of BTC. I don't really think it's a "universally bad" practice, it all depends on the details.

Maintaining privacy against a determined attacker is tricky, but re-using an address like that just makes the attackers job unnecessarily easy. Transaction costs are not any different, whether you send wallet top-ups and change to the same address, or new addresses. There is no difference in number of transactions, or byte size of transactions.

@chytrik I believe that using change addresses may lead to output fragmentation and therefore subsequent transactions will require more than one input, which would definitely make them larger in terms of byte size. I believe I have seen it happen in my own Electrum wallet. Some transactions can easily go to thousands of bytes instead of the usual ~250 bytes per one-to-one transaction. Also, while I would appreciate your answer if I'm mistaken about change addresses, I do believe that this thread is becoming an "extended discussion" and not suitable for comments.

the specific address a new UTXO is locked to will not affect the fragmentation of the user’s UTXO set. Multiple UTXOs locked to the same address do not combine, they are still spent individually. So it is the same in either case, no extra cost. Your answer isn’t bad otherwise, I just comment because I hope to see builders of btc infrastructure using best practices, not re-using addresses :)

OK, now I see that you're right. Thanks for clarifying. I'm with you on that, now that I remember that UTXOs don't combine :) I will also update my answer accordingly, since this aspect is indeed misleading on my part.


text:
Lightning implementations
Why are there two implementations of lightning?
Is it because majority agreed on using Go for a reference implementation but a minority dissented that choice and built the alternative C implementation?

LND and c-lightning are probably the most popular, but there are more implementations than that still.

And neither is more or less of a reference implementation than the other. There were two teams who started early on with implementations of the protocol, because of different preferences and priorities, presumably, but they're far from the only implementations now. It has nothing to do with "majorities" (of what?) or anything - just two teams with their own focus. I don't know why that would be strange; there are dozens of Bitcoin wallets in a variety of programming languages. We should probably expect the same for Lightning-capable ones.

What is perhaps strange is that both c-lightning and LND (together with ACINQ) were pretty much there from the start, and so they're all reference implementations. Usually you'd perhaps expect more a single pioneer prototype, and others that later join the party.

Because nobody was interested in Bitcoin when it was proposed in 2008,
but many were interested in Lightning when it was proposed in mid 2010s.
A Bitcoin prototype was built for demonstration and a community and process developed around it only after the prototype was available. Lightning was theorized long before it was a working device, so people discussed what to do before it was built. When it was built, what to build had been discussed already.
Lightning doesn't have a reference implementation.


text:
alertnotify: how long is long?
  -alertnotify=<cmd>
       Execute command when a relevant alert is received or we see a really
       long fork (%s in cmd is replaced by message)

How long is "a really long fork"?

-alertnotify is only used by validation.cpp::AlertNotify
validation.cpp::AlertNotify is only used by validation.cpp::DoWarning
validation.cpp::DoWarning is only used by validation.cpp::CChainState::UpdateTip, for rules, not for forks or for alerts.

Because 1. and 2. and 3., there is no "long" at all. The RPC command help is obsolete.


text:
how to open the miniscript designer?
I've read Bitcoin Core 24 brings a miniscript visual programmer. Had a look, didn't find it.
Is that true?
How to check it out?

No, there is no such feature included in Bitcoin Core.
What is included in Bitcoin Core v24.0rc1 is the ability to use miniscript in imported output script descriptors, with the restriction that it is watch only (signing support will likely be for 25.0).
There are other tools out there, developed independently, that let you design scripts using miniscript-based tooling. Including:

https://bitcoin.sipa.be/miniscript (disclaimer: my own site), which lets you compile policies to miniscript.
https://min.sc, the minsc language, a layer on top of the Miniscript policy language.
https://miniscript.fun, a site to play around with Miniscript in a visual way

Were descriptors invented for being able to comfortably systematize complex spending policies? Or were descriptors themselves invented before systematized complex spending policies could be thought of on descriptors?

Both, I guess. Descriptors were originally designed to be able to generalize key/address derivation to future script versions, as well as multisig. Once that existed, the miniscript research showed that this approach could reasonably be extended to far more complex script constructions than originally aimed for.

No, Bitcoin Core has no graphical interface for miniscript. However, the 24.0 Release Candidate Testing Guide mentions miniscript.fun, a graphical playground for miniscript, which is likely what you're referring to.


text:
why int128 in secp256k1?
Why do they write an int128 type in secp256k1, when there's already arbitrary length rational numbers?
Is that fancy? Boredom? Isn't secp256k1 just for key pairs, and key pair arithmetic is seldom used, so to justify pasting together native smaller int types instead of using arbitrary length data types?

I assume you're referring to the C implementation of secp256k1 arithmetic, perhaps specfically this pull request? If not, comment and I'll revise my answer.

Why do they write an int128 type in secp256k1, when there's already arbitrary length rational numbers?

Computers generally cannot operate on arbitrary length numbers, let alone rational numbers. Hardware can generally only perform integer arithmetic up to numbers of 32 or 64 bits in size, or approximate arithmetic (with rounding) using floating-point numbers of 32 bits, 64 bits, or 80 bits in size. For cryptographic purposes we need exact arithmetic, so anything with rounding is off limits.
Anything else has to eventually be implemented in software. Many languages provide convenience functions that hide this complexity; for example Python has general-purpose arbitrary length integers and fractions as part of its standard library, but that simply means that the Python interpreter is translating operations on those apparent data types to many small individual instructions that each operate on just 64-bit integers, typically. If you wonder how that works, just imagine how you once learned to do math using numbers longer than 1 digit. Here the "digits" are 64-bit integers on their own, and so a 256-bit integer can be seen as a number consisting of 4 such digits. Many operations (addition, multiplication, ...) on those are very similar to what you'd do for decimal numbers on paper.
libsecp256k1 is not written in Python, but in C, and C doesn't have support for integer types larger than what CPUs support internally, in general. So, it doesn't have the luxury of being able to just use off-the-shelf code for its big integer arithmetic, it has to be implemented by hand. Of course, that is the point: libsecp256k1 is intended to be fast, and by having custom integer code that's designed specifically for this application it can be many times faster than what a Python implementation could ever hope to achieve.
Furthermore, it's necessary. Arbitrary-length integer types, even if they were available, are generally not appropriate for implementing cryptography. We aim to design code that runs in constant time, so that an attacker cannot learn anything about our private key by observing how long operations on it take. Variable-length types can obviously not be constant-time, as operating on them depends on how long the number is.

Is that fancy? Boredom?

The point of this pull request is testing, platform support, and verifiability.
Let me explain. libsecp256k1, in order to implement elliptic curve operations, needs to reason about fairly large integers (256 bits most of the time, occasionally up to 512 bits), often modulo some large (256-bit) prime.
To implement arithmetic with 256 bits long numbers, the operations are generally broken up into smaller bits as I explained above. But how small depends on what hardware you have. Modern x86_64 CPUs like those by Intel and AMD can natively do 64-bit arithmetic, including multiplication of two 64-bit numbers to obtain a 128-bit number (which is then stored in two 64-bit registers). This is very useful, but not possible everywhere. Most Raspberry Pi systems run in 32-bit mode, where no 64-bit integer type is available in hardware.
To deal with that, libsecp256k1 has multiple versions of its specialized 256-bit arithmetic code. Slightly simplified, it has one version for 32-bit systems and one for 64-bit systems. The first one uses 8 to 10 "digits" of 32 bits to represent 256-bit numbers, while the second one uses 4 to 5 pieces of 64 bits instead.
All of these of course have tests, but as this is a key cryptographic codebase, and bugs in it could very directly affect the security of many pieces of Bitcoin software that use it, including Bitcoin Core, more testing/verification/analysis is always welcome. Russell O'Connor has been contributing to this effort, with among other things, formal verification proofs for correctness. However, the system he is using does not support the 64x64->128 bit multiplication. We could of course only test the 32-bit implementation of the 256-bit integer logic, but we like to go a step further.
This is where the 128 bit integer type comes in. It's just a type implemented in libsecp256k1 itself. On 64-bit systems it would immediately defer to the actual 64x64->128 logic available in C. On other systems, it would emulate it by splitting things into operations on 32-bit integers. This means that the 256-bit implementation can then use our new 128-bit type (rather than use the C types directly), and this will work on both 32-bit and 64-bit systems. And more importantly, it will work in the formal verification tools that do not support the 128-bit type natively.
There is another advantage, though that's not yet implemented in this PR. That is the fact that MSVC (Microsoft Visual C) does support 128-bit operations, but doesn't do that through a 128-bit type. Instead it has special functions that do these using just 64 bit integers. So by introducing this intermediary 128-bit type, and then adding an instantiation for it for MSVC, we could automatically make our 256-bit logic work for MSVC without incurring the performance penalty of using 32-bit code only. If we wanted to achieve something similar without introducing a 128-bit wrapper type, we'd need to create a new implementation of the whole 256-bit integer logic just for MSVC, rather than just an implementation for the 128-bit wrapper. This may sound trivial, but it's several hundred lines of very tricky code, and code like this has actually had bugs in other libraries (including OpenSSL).

Isn't secp256k1 just for key pairs, and key pair arithmetic is seldom used

Not just key pairs; libsecp256k1 provides implementations for all kinds of operations that involve private keys, public keys, or both. That includes key generation (computing public key given private key), key derivation (e.g. BIP32), as well as signing and verifying digital signatures (ECDSA, since recently also BIP340 Schnorr).
In particular, signature validation is a very significant portion of time nodes spend on synchronizing and processing blocks and transactions. libsecp256k1 is primarily aimed at being efficient (in addition to being safe and well-tested) specifically because signature operations are such a bottleneck in Bitcoin.


text:
getwalletinfo.hdseedid security
Command help getwalletinfo tells:

"hdseedid": "hex", (string, optional) the Hash160 of the HD seed (only present when HD is enabled)

I understand that sharing this number will result in an immediate loss of funds, because this looks like should enable recreating the whole HD tree. Am I wrong and why?

I understand that sharing this number will result in an immediate loss of funds, because this looks like should enable recreating the whole HD tree. Am I wrong and why?

You're wrong. It is the hash of the seed, not the seed itself.


text:
Viewing truly raw but decoded transaction data
I've previously been using bitcoin-cli decoderawtransaction to get human readable bitcoin transaction data but am just learning that it's not only decoding the raw transaction but also adding extra derived fields (e.g. txid, hash) that aren't explicitly stated within the transaction held in the blockchain.
Purely as a means of education I want to be able to interact with exactly the transaction data that's stored by bitcoin in blocks/mempool with no extra extrapolated data.
What's the best way to get this data?

Why not take that raw hex and decode it yourself? The serialization is documented here: https://en.bitcoin.it/wiki/Protocol_documentation#tx
For example: https://blockstream.info/tx/597d47f1c1653b6e067d8a323c07e0d7702cc92445922e4ba1a61748e0e6fee8
Raw hex:
01000000018a6b50504336d298af1bef59f4292afdbac8ad29a0217ef6d67eb70120f33704010
000006b483045022100b0c1bbc3ab2b716f388fe9136cbed2a1e1562fe7a9b8b9847f27284340
85e9e602206351a3b9fb8e04258730856792237e98b9e8d4a89ca10cd5c1dfa68295b9f409012
103ddc5d4f8c82c81304a409200095f26ce3f51847c6f11793b3a744818edff7ad3ffffffff02
204e0000000000001976a914d2212980d7adf3596d4db7be218d4c0e95944be488ac098033000
00000001976a91460d6cdf16948d0a40667b7af195f3d233a35b0e288ac00000000

Decoded:
01000000 version

01 # of inputs

(input 0:)

8a6b50504336d298af1bef59f4292afdbac8ad29a0217ef6d67eb70120f33704 prev out txid

01000000 prev out index

6b length of script (= 107 bytes)

483045022100b0c1bbc3ab2b716f388fe9136cbed2a1e1562fe7a9b8b9847f2728434085e9e6022
06351a3b9fb8e04258730856792237e98b9e8d4a89ca10cd5c1dfa68295b9f409012103ddc5d4f8
c82c81304a409200095f26ce3f51847c6f11793b3a744818edff7ad3 script

ffffffff nSequence

02 # of outputs

(output 0:)

204e000000000000 value (20,000 satoshis)

19 length of script (=25 bytes)

76a914d2212980d7adf3596d4db7be218d4c0e95944be488ac script

(output 1:)

0980330000000000 value (3,375,113 satoshis)

19 length of script (=25 bytes)

76a91460d6cdf16948d0a40667b7af195f3d233a35b0e288ac script

00000000 locktime

thanks - I'm accepting as the answer, but how did you generate that - via a library or with your own code?  If it's the latter, any pseudocode you could share for decoding would be very helpful.

@d3wannabe  By hand! With the raw hex and the serialization spec you can sort it all out byte by byte.

thanks @pinhead - so "field size" is literally # of characters/bytes?  If so, the wiki says version is 4, but you knew to take 8 - how?  Also a field like tx_in count (which has a size of 1+) - how do you know it wasn't 018 instead of 01?  Think I might be misunderstanding the idea of field size

@d3wannabe You might be mistaking bytes for hex characters. For example, 01234567 is a hex string that represents 4 bytes.


text:
How can bitcoin transactions for the same coin belong in different blocks?
Isn't each transaction dependent on a hash of the previous transaction?  Wouldn't that mean all of the transactions for a particular coin would have to be grouped in the same block?  As far I can tell this is not true, so by what mechanism are transactions for different coins grouped in the same block.
Everything I've seen on StackExchange about this refers to hashing in blocks, which makes sense to me on the level of blocks, but then I don't understand the level of hashing of transactions since it seems transactions are not organized into blocks by coin.
So I guess a different way to phrase this is how can transactions from unrelated coins be organized into a block?  Because as I previously mentioned, I thought that each transaction was dependent on a hash of a previous transaction.

Isn't each transaction dependent on a hash of the previous transaction?

Yes and no.
Yes, in that each transaction must be created using valid inputs (ie, referencing a valid UTXO to be consumed as an input). No, in that transactions are not 'dependant' on the previous transaction's hash in the same way that blocks are 'dependant' on the previous block's hash.
For blocks, the hash has an extra level of importance, in that the hash of the block must be a valid proof-of-work on the network. Each block must have a valid hash, and also reference a valid previous block. For transactions, this extra layer of 'valid proof of work' is not required.
(Note that as Ugam mentioned, coinbase transactions are special, in that they do not consumer inputs)

Wouldn't that mean all of the transactions for a particular coin would have to be grouped in the same block?

When a UTXO is consumed as an input, those coins must be spent entirely, by the creation of new UTXOs as outputs. The sum of the outputs will be slightly less than the sum of the inputs (this difference will become part of the miner's fee for the block), so any excess of coins not specified in a new UTXO will simply be claimed as fees (added to the output of the coinbase transaction).

Everything I've seen on StackExchange about this refers to hashing in blocks, which makes sense to me on the level of blocks, but then I don't understand the level of hashing of transactions since it seems transactions are not organized into blocks by coin.

Right. A transaction is hashed to obtain the transaction ID (txID / wtxID), but this hash is not subject to the stipulations of being a valid proof-of-work.
There is one situation in which ordering within a block matters: suppose you create a transaction-1 that makes UTXO-1, and then create a transaction-2 that spends UTXO-1 and creates UTXO-2. If you wanted to include both of those transactions in the same block, then transaction-1 would need to be included before transaction-2, otherwise transaction-2 would be seen as invalid (and thus the whole block would become invalid). In this way, 'child transactions' must always come after their parents, if included in the same block.
Otherwise, the transactions included in a block do not have to be related to each other at all, there is no requirement like this. The only stipulation is that a transaction must reference a valid UTXO (and hence the rule about ordering transactions that I mentioned above).

Isn't each transaction dependent on a hash of the previous transaction?

It is correct for most transactions apart from the coinbase transaction. The coinbase transaction is one that mints new coins through the mining process and as such does not have a preceding transaction it can reference.

Wouldn't that mean all of the transactions for a particular coin would have to be grouped in the same block?

There is no need for grouping all the transactions 'related to a coin' in a single block. Whenever you want to spend some coins with the keys you control, you would simply reference the transaction outpoint (the txid and the output number) and provide a valid signature that satisfies the unlocking condition. Bitcoin full nodes maintain a complete set of unspent transaction outputs (UTXOs) data that they build by going through all the transactions in the blockchain when that node is bootstrapped. This data set contains the information of the txids and output numbers, which allows the full nodes to verify your unlocking condition without going back to the block in which this transaction was included. When a new transaction is created, the the outpoints which are used in the transaction inputs are deleted from the UTXO set and the outputs of the transaction is added to the UTXO set.

As far I can tell this is not true, so by what mechanism are transactions for different coins grouped in the same block? How can transactions from unrelated coins be organized into a block?

Coinbase transaction always comes first in a block. If a transaction (child) spends coins from another transaction (parent), and if both these transactions gets mined in a single block, then the parent must precede the child in terms of transaction ordering in the block. Apart from these two rules, miners can include transactions in any order.

I don't understand the level of hashing of transactions since it seems transactions are not organized into blocks by coin.

A transaction data is serialized and then hashed twice using SHA-256 which gives you the transaction id (txid). Given the randomness in SHA-256 one can be assured that a txid is a unique identifier of a transaction and can be referenced with only 32 bytes. When spending some coins you control, all you need to do is reference the txid and output number.


text:
Bitcoin address to Hash160 for brainflayer
I took a script to translate the bitcoin address to hash160:
http://lenschulwitz.com/b58/base58perl.txt
replaced the lines for working with the list from the file:
#Sample test taken from https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses.
my $base58_encoded_address = "16UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM";
print "\nRunning tests for bitcoin address $base58_encoded_address\n";
print "Bitcoin address is valid.  Address type: '", check_bitcoin_address($base58_encoded_address), "'.\n";
my $binary_address = decodebase58tohex($base58_encoded_address);
print "Binary hexadecimal representation is: $binary_address\n";
my $reencoded_base58 = encodebase58fromhex($binary_address);
print "Re-encoded back to Base58 is: $reencoded_base58\n\n";

to:
my $fileSrc = 'base58.txt';
open my $fhSrc, $fileSrc or die "Could not open $fileSrc: $!";

my $fileDest = 'hex.txt';
open(my $fhDest, '>>', $fileDest) or die "Could not open file $fileDest: $!";

while( my $base58_encoded_address = <$fhSrc>)  {
  my $binary_address = decodebase58tohex($base58_encoded_address);
  say $fhDest $binary_address, 2, 40;
}

close $fhSrc;
close $fhDest;

But this script stops and does not work with bech32 addresses, tell me what needs to be added so that it works with bech32. Or maybe someone has a similar script for converting addresses for the brainflayer?

Have you solved this problem now?

I didn't solve this problem :)


text:
Financial Department Bitcoin
I wanted to send bitcoins to my wallet from my trading account and did not receive anything. A short time later I got from
Fiancial Department Bitcoin received the following message:
Your payment of BITCOINS is ready to be processed and is already on BLOCKCHAIN.
This department wants to pay me bitcoins for a fee and I don't know if this is real? Has anyone ever had anything to do with it and can you trust this depatment?

This sounds like a scam.

So this service is holding your money, but wants you to send more money, to pay a fee? This is pretty obviously a red flag for it being scam, if they were legitimate they could just take the fees off the money they are already holding for you.

It doesn't seem right. I wouldn't trust them. I would suspect fraud.

Financial Department Bitcoin

As I'm sure you know, The Bitcoin currency and Bitcoin network is peer to peer and has no departments. So no financial departments.
In normal English, or business English this phrase doesn't make much sense. Some kind of business would have a financial department but those sorts of departments are not usually split by currency. Generally there would be an accounting department that might communicate with creditors and debtors, there might be some kind of sales department or customer services department that communicates with retail customers.

my trading account

If you have an account you are dealing with one of the many thousands of businesses that make money by selling services to people who want to invest or trade in Bitcoin. There are lots of fraudulent businesses that are just invented to trick people out of money. There are also some genuine businesses of this sort but many people find it hard to tell genuine businesses from fraudulent ones.
Finance departments are usually different, here's one definition:

Finance Department is the part of an organization that is responsible for acquiring funds for the firm, managing funds within the organization and planning for the expenditure of funds on various assets.

So in most businesses - the finance department mostly manages internal matters - it is generally not one that routinely interacts with retail customers.
For example a car manufacturer would have a finance department that might obtain funds for a new factory. They might not routinely be involved in selling cars to distributors and certainly not involved in selling cars to car-drivers.
Of course businesses are free to organise themselves as they wish and can name their departments whatever they want.

This department wants to pay me bitcoins for a fee and I don't know if this is real?

If the fees were not made very clear right at the start, before you placed any money in this trading account -- then you are very likely the victim of fraud.

+1 I admire your grit to suss out this sort of situation again and again.


text:
What is the best practice for listening to payments on the RPC api?
I have a docker instance running a bitcoin node and would like to listen to deposits, generating a new address each time a user requests to deposit then increment the users account balance on success.

Hey, this looks like you are in need of PoS software, as you'd have to implement a lot on top of bitcoin core to achieve this. You can look into btcpay server which is free OS PoS on top of bitcoin core?

Bitcoin has walletnotify feature that will notify you when an address you own in your wallet receives a transaction, and a second notification when the transaction confirms.
You can set it in your bitcoin.conf
walletnotify= curl http://yoururl.com/endpoint.php?tx=%s
%s will contain the transaction id. What you do from there is up to you.

Apart from walletnotify callback these are the JSON RPC calls that you would use:

https://developer.bitcoin.org/reference/rpc/getreceivedbyaddress.html
https://developer.bitcoin.org/reference/rpc/listreceivedbyaddress.html
https://developer.bitcoin.org/reference/rpc/gettransaction.html

For these calls to work, you need to have a corresponding wallet created or imported into Bitcoin Core. It is also a good idea to set txindex=1 so you can add pre-existing wallets to Core add hoc.
PS Depending on your specific use case it may be better to use existing open source, self hosted solutions like legendary BTCPay Server or more recent CypherpunkPay (disclosure: the author).


text:
Why aren't any BIP 69 facilities in Core Qt coin control?
I know (I sort of get) Core Qt is currently fingerprinted by means other than lexicographical analysis of order of inputs and outputs.
And yet I suppose it could make sense to have a status label in coin control advicing whether current tentative transaction complies BIP 69 or not.
Can you explain why there is no such facility?
Can you link Core discussions on BIP 69?
Can you link any Core PR exploring the BIP 69 concepts?

https://github.com/bitcoin/bitcoin/issues/12457, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-October/016457.html

A lexicographical order on transaction inputs and outputs could help improve transaction homogeneity and mitigate unnecessary privacy leaks present in some wallets if adopted by the entire ecosystem.
However, it is unlikely to ever be adopted by a majority of wallets, because a) some transaction uses have conflicting requirements for the order of inputs and outputs, and b) many wallet developers appear to either be indifferent or opposed to BIP 69.
As you mention in the question, while only a minority of transactions adopts BIP 69, it represents a wallet fingerprint. My understanding is that some Bitcoin Core contributors do not support implementing BIP 69 in Bitcoin Core, and there probably also hasn’t been a contributor sufficiently invested to make it happen.


text:
What are best practices around toggling between multiple wallets in bitcoind?
I've created a couple wallets on Core to experiment with and want to dedicate one wallet as a live one.  What is the best way to move between those wallets inside the command line?  When I toggle to a wallet that is not the default in the GUI and try some bitcoin-cli wallet commands it get an error
Wallet file not specified (must request wallet RPC through /wallet/<filename> uri-path)

Is it just a matter of passing a wallet file name into the command? Or is there a better way to manage multiple wallets? Other best practices to a multi-wallet setup (i.e. don't)?

For future reference, thought I'd respond to my original question with what I've found out to this point. Haven't fully answered the original question yet but the approach I'm using at the moment to toggle between wallets is:
bitcoin-cli -rpcwallet="filename" [command]

Any other thoughts on best practices would be great!


text:
Most efficient way to store Segwit Address in a database
This is not a duplicate of What is the most efficient way to store bitcoin addresses in a database? but it's the same question except I need a segwit answer.
Let's say I wanted to store every standard BTC address in an SQL database.
The most space efficient way is to extract the HASH160 address by converting to base58 then slicing away the checksum. This will allow you to store a BTC address in 20 bytes.
Until segwit blocks come.
Is there a way to get to the hash160 address from:
bc1q34aq5drpuwy3wgl9lhup9892qp6svr8ldzyy7c
If not, could someone tell me the most space efficient way to store this address in a database?
I have no need to convert it back to original string, but only ensure its identity.
Thank you

A popular block explorer converting addresses into hash160's in their database resulted in funds loss, since their service erroneously reported the same funds being paid to both p2pkh and p2sh addresses.  Make very sure what you do is fit for purpose...

Thank you, it's just for a home machine learning project. Not a mission critical security application.

Is there a way to get to the hash160 address from bc1q34aq5drpuwy3wgl9lhup9892qp6svr8ldzyy7c

Yes, you could use the reference implementations in various languages to encode and decode a bech32 address. For example, I have decoded the sample address you mentioned in the question, bc1q34aq5drpuwy3wgl9lhup9892qp6svr8ldzyy7c, using python below. The decode function gives us the witness version (0 in this case) and a byte array.
import bech32

address = "bc1q34aq5drpuwy3wgl9lhup9892qp6svr8ldzyy7c"
address_decoded = bech32.decode("bc", address)

address_decoded  # a tuple containing witness version and bytearray of the address
>>> (0, [141, 122, 10, 52, 97, 227, 137, 23, 35, 229, 253, 248, 18, 156, 170, 0, 117, 6, 12, 255])

bytes(address_decoded[1])
>>> b'\x8dz\n4a\xe3\x89\x17#\xe5\xfd\xf8\x12\x9c\xaa\x00u\x06\x0c\xff'

Couple of points to note:

The address you have mentioned here is a P2WPKH and has a length 20 bytes. However, P2WSH addresses are 32 bytes (they also begin with "bc1...") as we take the SHA256 of the witnessScript instead of HASH160.
Although version 0 addresses (P2PKH, P2WSH) will have a data payload of 1+20 or 1+32 bytes, BIP173 allows up to 40 bytes in a witness program, for a total of 1+40 bytes.

Note that although version 0 addresses will have a data payload of 1+20 or 1+32 bytes, BIP173 allows up to 40 bytes in a witness program, for a total of 1+40.

@RaghavSood Thanks. I have incorporated that in my answer.

As per BIP 173, the data part consists of:
The data-part values:
1 byte: the witness version
A conversion of the 2-to-40-byte witness program (as defined by BIP141) to base32:
Start with the bits of the witness program, most significant bit per byte first.
Re-arrange those bits into groups of 5, and pad with zeroes at the end if needed.
Translate those bits to characters using the table above.

The value itself is simply the byte data encoded with bech32's encoding system, which is also outlined in BIP 173.
Thus, you need to store up to 41 bytes per address, if you know that all your addresses have the same human readable portion. If not, you will need an additional byte or two to store a reference to which human readable part that address uses (if that information is relevant to your usecase - the 41 bytes from the data portion may be enough, if all you want is a list of used Bitcoin addresses, for example).
The human readable part is usually fixed for a given network or address family, and the separator is always 1


text:
How to scale JSON-RPC
I'm trying to scale getrawtransaction calls from bitcoind, without manually parsing the .dat files.
I've tried:

rpcworkqueue=512 (no difference)
rpcthreads=128 (no difference)
par=8 (no difference)
passing the blockhash with every call to avoid searching the txindex (big difference)
using JSON rpc batching (big difference)
having two separate instances on the same pc and rotating requests (double speed, but costs 200GB)

It seems that a bitcoind will only ever devote 1 core of the cpu to JSON RPC, so when it gets to 100% the only way to scale is with another instance. Unfortunately my server has 24 cores at 2.1GHZ.
Does anyone know if it's possible to have two instances of bitcoind running in the same folder. I.E. one instance is connected to the network and the other instance is running in a read only mode.
Or is is possible to allocate multiple cores(not threads) to JSON rpc
Any help is appreciated, thank you.

Or is is possible to allocate multiple cores(not threads) to JSON rpc

No. The problem is not to do with thread or core allocation. Rather Bitcoin Core makes use of locks to keep the chain state consistent when multiple threads may access it. In this case, you will need to access the chain state to get transactions so multiple getrawtransaction calls cannot really be run in parallel (locks aren't held for the entire call, but they are held for the parts that matter). So adding more cores or threads won't help at all.
The only thing that does help is to use the blockhash parameter. Without it, getrawtransaction will wait until Bitcoin Core isn't in the middle of processing multiple blocks, and the check and wait for this takes some time. However if you specify the blockhash, it will know immediately which block to look in and quickly look it up, no blocking or waiting for blocks to be processed. So this will be faster than without.
Otherwise there's nothing else that you can do.

Hi Andrew, thank you for your insight. So even if the block is from 2014, there still needs to be a read lock to maintain chain state?

At this point, your best bet is probably launching a bunch of 1 core pods on Kubernetes with copies of the chain lol


text:
What happens when i change the encryption password of Bitcoin-Core wallet
What happens when i change the encryption password of Bitcoin-Core wallet?
Is first pass lost forever , where is it saved - on the blockchain or on the wallet.dat file? What if encrypt wallet with pass1 , save wallet.dat  , than change the password and encrypt it again with pass2  -  what will happen if i input the first wallet.dat with pass1 - can i unlock the wallet ?

Bitcoin Core wallet encryption works by encrypting the private keys stored in the wallet file. The private keys are encrypted with a master key which is entirely random. This master key is then encrypted with AES-256-CBC with a key derived from the passphrase that you enter using SHA-512 and OpenSSL's EVP_BytesToKey and a dynamic number of rounds determined by the speed of the machine which does the initial encryption.
Now, the first wallet file contains private keys that were encrypted using your original passphrase. So, if you had backed up that file before changing the passphrase, then your old passphrase will work in unlocking that wallet. Thus you can spend the funds held in your original wallet.dat file with the old password.
However, the look-ahead keypool is refreshed so that any new addresses you request after the password change are not in the old wallet with the old private keys. This means that if you don't spend your bitcoins after you change your password, anyone with a copy of the original wallet with the old password can still steal your Bitcoin if they have the old password.

Can you take a look at my other question , and tell me if that makes sense ? 10x

@in7ane that question is already answered.