text:
Computer crashed, total reinstallation. Have wallet.dat but not private key
My computer crashed and I was using the Bitcoin Core/QT client (they're the same right)? I thought I had my public and private keys saved, but those keys are from my old Armory wallet. I don't think I swept them to Bitcoin core, but I still used those keys for encryption/decryption. I was able to retrieve the wallet.dat file from the oldwindows data that is backed up on my computer, but I was wondering if I could retrieve my private key from the dat. file and how. Or if that isn't necessary, how should I go about reinstalling the bitcoin client so that I will have my coin back? I appreciate your help.

I do have access to old receiving and sending addresses. As of yet I haven't reinstalled a fresh Bitcoin Core client. It will take generally a week or so to sync/install. I don't know if the oldwindows backup is going to slow my comp down down more or not. Seems like the repair shop would've saved oldwindows to an external drive. Anyway, one site told me to install the bitcoin core client, don't start it until I delete the newly created wallet.dat and replace the new dat file with my old one. Then restart the client? Rescan the blockchain? I would feel much better if I had the private key.

bitcoin is significantly slowing down your PC only when it is syncing the blockchain. But if you have a copy, it is perfectly ok to restore from backup. If you have old wallet.dat, just replace it, that file contains your private keys. You can extract privkeys with the command line interface in bitcoin-QT, see here: https://bitcoin.stackexchange.com/questions/4203/how-can-i-export-the-private-key-for-an-address-from-the-satoshi-client - let us know, how it goes.

As long as you have wallet.dat file and encryption key so you have nothing to worry about.
You can reinstall Bitcoin-core and move your wallet.dat file to bitcoin directory (./bitcoin on Linux) then you will be able to use it like nothing happened.
To get your private keys from wallet.dat you could run in your terminal
bitcoin-cli walletpassphrase "PasswordHere" 600
bitcoin-cli dumpwallet "txtfile_keysFile_path.txt"

All your private keys will be stored in that path.

Thanks for the help.  So using Windows 10, to restore the wallet.dat to the new wallet I would install the Bitcoin-Core client but not run it, switch the wallet.dat files, and then run it? Would it be easier to go into the command prompt and get the private keys?

Yeah switch the files and run it. it doesn't really matter if you do that through command prompt or GUI since you need to install bitcoin-core anyway.

It sounds like I have everything I need to get my wallet back up and running. Obviously it's going to take some time to sync the blockchain, but I feel better now that I know what steps to take. I really appreciate all the assistance.

I just have a couple quick questions. Is it necessary to delete the new wallet.dat after switching them? Also, it shouldn't do any harm to my wallet by running the command prompt to retrieve the keys, right? I would like to have the keys in case there's any trouble switching the wallet.dat files. Thanks again.

doesn't really matter as you have no funds with the new wallet.
No, it will never harm anything. Just keep a copy of your wallet.dat file somewhere else and set a copy in new bitcoin directory and you can try whatever you want. Don't forget to mark the answer if that helped.

Yeah this has definitely helped ease the apprehension I had about restoring my coin. I have one more question: Do I switch the wallet.dat file as soon as I install Bitcoin-Core, before syncing the blockchain, or do I have to sync the blockchain, switch the .dat files, and then re-sync? Thanks.

Doesn't really matter.

I should be good from here. Thanks for everything.

Ok. I'm syncing the blockchain, which will take a while. I wasn't sure if I had to download the chain before or after installing the Bitcoin client. I didn't see a wallet.dat in >appdata/roaming/bitcoin< to switch after simply installing the new wallet. So I'm syncing, and then I'll switch the new wallet.dat with the old wallet.dat. At that point will I have to simply restart the client, or do I need to resync the chain? What steps would I take to do that if so?

I didn't have any luck getting the keys using the command prompt. I haven't set a passphrase or pw, so I just used the second command-line. It didn't recognize it as a valid command. Were you saying to use that in the Bitcoin console? I was trying to do it from DOS. Many thanks.

try on bitcoin console with removing bitcoin-cli

Since I was installing a fresh copy of Bitcoin-qt and had to sync the blockchain from scratch, I simply swapped the wallet.dat files. There is no need for a forced rescan or to go into the console at all if you do it this way. 1st find your old wallet.dat. Install and start syncing the new wallet. Once it starts syncing, go to C:\Users\YourUserName\Appdata\Roaming\Bitcoin and swap the new wallet.dat with the one you want to use. Rename the new wallet.dat "backup wallet data" and use your old wallet.dat. I did it while it was syncing but before the date I made transactions, so just do it early.

Just switch your old wallet.dat with the newly created one.
When my computer and Bitcoin-QT crashed, I retrieved and backed up the old data. Geeksquad can do this part for you if need be but it isn't difficult. Once I had the data and a fresh install, I went to retrieve the wallet.dat from my old computer files at C:user/username/appdata/roaming/bitcoin. I backed that up and made copies of the wallet.dat file. Next, I installed a new Bitcoin-QT client and started syncing the blockchain from scratch. Shortly after beginning the process of syncing, I swapped the newly created Bitcoin wallet.dat with the one that had coin on it. It's probably best to rename the new wallet.dat "backup wallet data" instead of deleting it, but it doesn't matter. It just matters that the wallet.dat that you want to use is the only "wallet.dat" file in the folder or it won't know which one to read.
Once the chain was done, my coin showed up.


text:
Using blockcypher BitcoinJs at clientside is secure or not?
I am trying to create new transaction using bitcoinjs at client side.
Is it a secure way to create a transaction from Client side, which includes curl call.
Scenario, if I start from creating the new address using the library it includes curl call which can be easily accessible from the browsers dev tool which leads to direct access to my private keys.
So, is it safe to handle the transaction at client side or not?

source: Stack Exchange

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

sort: votes


text:
Cryptocurrency exchange needs more info than any bank or brokerage firm?
I wanted to quickly sign up for a cryptocurrency exchange today to act on some info I found out about a low-cost coin (hahahah, quickly. how naïve).  In signing up for the account, I got to a step asking me for my SSN, which is pretty normal. But then it asked for high resolution photos of a picture ID AND a proof of residency document??
I have MULTIPLE online bank accounts and brokerage accounts, with tens of thousand of dollars being held and traded in various forms, and I've never had to provide such information. Why the heck is the supposedly "anonymous decentralized currency of the future" requiring me to send in my firstborn and the results of my latest colonoscopy??

The requirements vary by exchange and are mostly as dictated by the regulating government. Bitcoin itself is decentralised, however, exchanges and businesses operate within government jurisdiction and must comply with any regulatory requirements. The requirements are usually country specific but mostly revolve around anti-money laundering requirements and whatever their standard requirements for investors are.

Right, which is why I included the fact that I have many US based banking and brokerage accounts that have NEVER asked for such info. So there has to be a better answer than this.

@WakeDemons3 Bitcoin is also considered an international trade by many governments whereas banking and brokerage is (probably?) just domestic trade. They hold your local regulated currency and trade on the domestic stock market, otherwise, they are probably international and not subject to the regulation of the US.

You can seamlessly trade international markets on any brokerage account without additional levels of identification or verification.

@WakeDemons3 I also have challenged one specific US-based cryptocurrency exchange service on this in the past and was told specifically that it is a regulatory requirement - I am not US-based.

@WakeDemons3 I would bet that the somewhat uncertain regulatory environment that bitcoin exchanges operate within would incentivize exchange operators to go ‘above and beyond’ the sort of verifications you are used to, in order to more fully cover themselves with respect to KYC/AML regulations.

a) It's not anonymous
b) Because governments hate it and are looking for any excuse to close down exchanges that deal in it. So exchanges have to cover their ass in triplicate by asking you for all this personal info.
If you don't want to provide personal info then you can buy in person from individual traders in the over the counter markets. Localbitcoins is the most popular site for arranging such trades.
Another option is a bitcoin ATM although I hear they ask for personal info too nowadays.
Once you have bitcoin you can exchange if for your choice of altcoin.

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


text:
Are DAG-based crypto currencies as secure as proof-of-work based blockchains?
A key feature of blockchain based cryptocurrencies is that they provide inherently secure systems that don't rely on third parties. The newer DAG-based cryptos like Byteball are being touted as superior to blockchains because they have faster transaction times and eliminate the need for miners. However, these cryptos use something called "trusted witnesses" to resolve double spend conflicts. Isn't this inherently less secure than a true trustless system like Proof of Work? I thought that the whole point of a blockchain was to provide intrinsic security without the need for trusted third parties.

You pointed out the flaw yourself. Naive people are being buzzword-ed off their money. No, 'trusted witnesses' are not decentralized by definition.

That's what I thought. I would really like to hear someone argue the other side of this and tell me why they believe trusted witnesses don't compromise the system. So far, I haven't seen any of the DAG supporters make any attempt to address this question.

I wonder how it will behave when witnesses used by sender and receiver disagree on amount of currency stored in given address - no malicious behavior required from witness, just someone spamming network. I guess they would need some distributed consensus protocol :)

You need to prove that the witness Selection process is random and independent. Alice can double-spent if she has control over the witness and the network.
Let assume Alice can double-spent, in bitcoin one can wait for 6 confirmations to rule out most of the double-spent. E.g. Seller only sends out the goods after 6 confirmation. How can you achieve this in DAG? since the account is only updated by its' own transaction. On top of that, the graph DAG is very complex compared to bitcoins' link-listed blockchain.
DOuble-spent transactions may get buried by other transactions.

It's interesting that so many believe that the original Bitcoin way is the only way to achieve Byzantine Fault Tolerance.  It is not.
Explaining why PoW with mining is more secure than other methods boils down to the math being the trusted element. This is also the case with Byteball (now called Obyte). The Obyte whitepaper explains that it considers PoW mining to be a leak of network value; to power companies, etc.
The Obyte consensus protocol follows a deterministic set of rules.  The role of the witnesses is only to order or sequence the units in a fair FIFO manner. Remember, in a DAG an unbounded number of units can be created at the same time, so in the case of an attempted double-spend, the fair ordering will have been determined by the witnesses broadcasting their encounter with the unit as they occur; and not by the amount of fee paid to prioritise them as is the case in BTC. Witnesses do not have other powers and should not be compared with bitcoin miners; they are trusted to act rationally to protect their own reputation in the real world. Full nodes are anonymous nodes which execute the consensus protocol to validate and store the unit.  The consensus protocol they execute is deterministic (while that of Bitcoin is probabilistic) so once a unit is confirmed stable in Obyte, it is final; it is then not just extremely unlikely to be invalidated as is the case with Bitcoin after x-number of confirmations; in Obyte it is 100% impossible.
The Obyte network is designed to allow for the number of witnesses to be limited only by the number of full nodes on the network, but just twelve are needed per transaction.
Anyone can set-up a witnessing node with relatively little hardware, etc. The Bittrex witness node at address QR542JXX7VJ5UJOZDKHTJCXAYWOATID2 is used by anyone who trusts it to be honest and reliable about broadcasting units as it sees them. They use it, but maybe others don't. Bittrex has a strong logical incentive to run an honest, reliable witness and Bittrex partners, customers etc. transacting Obyte Bytes with them expect Bittrex to protect their brand.  If however, they were to fail at that, it would just mean that other nodes would 'vote' away from them by not using them as a witness.  A transaction needs just seven of twelve witnesses to confirm sight of the unit. So, it would require seven simultaneous 'failed' witnesses (of a given transaction) for a unit to be stuck in an unstable position, or be sequenced in an unfair order. The probability of that is considered extremely unlikely, especially in a mature network.
The white paper explains this in full detail.

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


text:
What's partial spending? What does avoidpartialspend do?

Group outputs by address, selecting all or none, instead of selecting on a per-output basis. Privacy is improved as an address is only used once (unless someone sends to it after spending from it), but may result in slightly higher fees as suboptimal coin selection may result due to the added limitation (default: 0)

I don't understand. Isn't address reuse already avoided, if receiving/change address is used only once? Does this option mean that each receiving address would be tracked by the wallet internally, so that spending from multiple "sources" is generally avoided? Aren't there still some scenarios that "spending from multiple sources" is still unavoidable? How could this improve privacy? Won't this create a tracable "chain" of transactions?

Currently, best practices are to receive coins to an address only once - Any reasonably new wallet will generate a new receiving address for you if the previously displayed one has already received coins.
However, there are scenarios where an address might receive coins multiple times, such as being a saved address on an exchange, stored with an automatic payout system (mining pools etc), or just intentionally giving the same address to multiple people who send you coins.
In such cases, an address has multiple utxos, possibly of varying sizes, associated with it.
Additionally, if you also use your wallet normally, it would have many other addresses with just a single transaction. This one address with many transactions could result in coin selection algorithms spending this address' coins along with coins sent to other, single-use addresses, thereby linking them as belonging to the same wallet.
avoidpartialspend is a configuration option that tells the coinselection system to spend all utxos on a single address before attempting to source utxos from other addresses (which may still be necessary depending on the amount being sent). This ensures that, as much as possible, the utxos selected minimize the number of individual addresses that are linked together for a single transaction. However, this comes at the cost of a higher transaction fee due to potentially larger transaction sizes, and sub optimal utxo selection as opposed to selecting the best input(s) for the amount being sent.
This does improve privacy to some extent. However, as notes, it is not a complete solution, as future utxos to that address may be used in other transactions that link them to more wallet addresses, even after this process.

Enabling avoidpartialspend changes your wallet’s behavior if any of your addresses were reused.
avoidpartialspend causes your wallet to treat multiple UTXOs that share the same output script (i.e. were received to the same address) as a unit. You can think of this Output Group as a super-UTXO with the aggregate amount and weight. Instead of running coin selection on UTXOs, the wallet then runs coin selection on output groups. Output Groups are either spend completely or not at all. This prevents the privacy leak of spending funds associated with the same output script across multiple transactions and thus indicating that the same entity was involved in the creation of all of those transactions.
Bitcoin Core uses avoidpartialspend opportunistically, even if it is not explicitly enabled.

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


text:
How could an LN node acquire inbound liquidity? Is there any systemic risk?
I once heard that LN could support dual-funded channels. It doesn't seem so complicated, but currently, I don't know any LN wallet which supports creating dual-funded channels.
By the way, I'm also concerned about security: will dual-funded channels introduce systemic risks/attack vectors? For example, if an attacker is already able to do a 51% double-spending attack, could he leverage the inbound liquidity to multiply his profit?

Dual funded channels are theoretically easy but there is a little bit of implementation overhead. Also they are not fully spect out yet in the BOLT standard which is the reason why they are not implemented yet. They will be part of the next update to BOLT 1.1 and people are working on the specification.
While studying the Lightning Network white paper last year I discovered a potential 51% attack vector which I described on the Mailinglist. The attack can steel all the capacity that is in all your channels. With dual funded channels you could in fact increase the capacity that is attached to you. However the described 51% attack is rather unlikely to happen and in particular would yield many other problems.


text:
Public key Exceeding Mod P? A Clarification Request On The Discrete Logarithm Problem
I tried to observe / implement the discrete logarithm problem but I noticed something about it; but before I get into it let me give some clarification which is open to correction.

a = b^x mod P

Where as
a = the public key of the address;
b = the generator point of the secp256k1 koblitz curve (this is the
curve in context);
x = the discrete log;
P = the modular integer.

I coupled all parameters below:

A =
044f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa385b6b1b8ead809ca67454d9683fcf2ba03456d6fe2c4abe2b07f0fbdbb2f1c1
(uncompressed public key)
034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa :
(compressed public key)
B = 04 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B
16F81798 483ADA77 26A3C465 5DA4FBFC 0E1108A8 FD17B448 A6855419
9C47D08F FB10D4B8 (uncompressed generator point)
02 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B
16F81798 (compress generator point)
X = ?
P = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE
FFFFFC2F

I don't actually know what part of the parameters I should use ( compressed or uncompressed)
N. B :  I tried the uncompressed public key to Mod P but the uncompressed public key exceeded the Mod P in size.
What should I do about this?

It is important to note that the Elliptic Curve Discrete Logarithm Problem (ECDLP) is slightly different from the normal Discrete Logarithm Problem (DLP).
In DLP, the ^ operator is actually exponentiation and it is operating on integers so mod p is just the normal modulus. However for ECDLP, ^ is actually elliptic curve point multiplication. This is different from exponentiation and is a much more involved process. You also cannot mod p with a point because they are not integers. While there is a modulo, it is part of the point multiplication process itself.
The compressedness of the parameters you use does not really matter. In the end, the compression is just the encoding of a point. You need to parse this encoding to determine the X and Y coordinates of the point; both uncompressed and compressed allow you to determine them. The uncompressed just gives you the X and Y coordinates directly while the compressed one gives you the X and whether Y is even or odd so that you can compute the correct Y coordinate. When you do the point multiplication, you are not handling the encoded point as an integer and just multiplying it with x. You are doing elliptic curve point multiplication which is way more complicated.

But when i tried to use the uncompressed public key to solve for the Elliptic Curve Discrete Logarithm Problem; mod p was actually smaller than the public key. what shoud i do about that?

@DaveKent How are you trying to solve for ECDLP?

I actually converted the uncompressed public key from hexadecimal to decimal, same as the prime mod P. And as for how I'm going to solve it... It's still in theory;passed some tests though.... So yeah I'm good.


text:
Is there any available way to discover/find the public key of a specific address?
Is there any way to discover/ find out the public key of a specific bitcoin address? If not, are there any available tools online to help find the public key of a specific bitcoin address?

The only way is to see if any outputs for that address have been spent before, and then looking at the spending transaction(s). Those spending transactions will contain the scripts and public keys for that address.
Otherwise, no, it is not possible. Addresses are constructed by hashing public keys or scripts, and one of the key properties of hash functions is that they are not reversible. So you cannot take the hash encoded by an address and compute what was hashed (i.e. the public key or script).

So does it mean that a bitcoin address that actually has an incoming transaction but no outgoing transaction doesn't typically have a public key?

And I almost forgot... Is there any way I could use the public key I have to track the address which the public key has been specified to?

Every public key hash type address (1... and shorter bc1q... addresses) have a public key. Only once there are outgoing addresses is the public key put into the blockchain for everyone to see. Likewise, if you have a public key, you can compute the addresses for that public key.


text:
The Generator Point (G) in Eliptic curve Cryptography
I am aware that the generator point (G) in Ecdsa is constant... But if I we're to calculate an equation using this number, I don't know if I should use the compressed or the uncompressed format of the generator point (G). And how should I apply the numbers to avoid these gaps on the numbers...
Compressed(G) :02 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798
Uncompressed(G) :04 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798 483ADA77 26A3C465 5DA4FBFC 0E1108A8 FD17B448 A6855419 9C47D08F FB10D4B8

What kind of equation? If you mean elliptic curve equations, the serialization shouldn't matter (they're to be treated as pairs of coordinates, not bytes). If you mean equations in the sense of cryptographic constructions that take hashes of points, it may matter. Can you clarify?

Yes of course... The equation is not coordinate specific... It falls on hexadecimal arrangement like this (6g4uo358pi2996jo) or something like this :(0279BE667EF9DCBBAC55A06295CE870B07029BFCDB) instead of placing it separately like the original numbers above. I'm just trying to add it like how I would add/divide/subtract a normal hexadecimal number

G is not at all constant in ECDSA; ECDSA supports about a hundred different curves each with a different G. G is constant for an EC curve (or more exactly parameter set based on a curve) and the value you posted is the G for secp256k1 which is the curve/parameters used in Bitcoin. But a point (G or other) is not a number and should not be treated as a number.

thanks a lot... this has put a lot of clarification in my thoughts. but if i may ask, is the G for secp256k1 constant? and if it is, in which format is it in (hexadecimal, decimal, e.t.c). thanks in advance


text:
How do I solo mine with bitcoind-rpc?
I found this script: https://github.com/jgarzik/pyminer
But it uses getwork RPC call, which resulting me this:
error code: -32601
error message:
Method not found

From https://en.bitcoin.it/wiki/Getblocktemplate:

It supercedes the old getwork mining protocol.

Does it mean that getwork is no longer an option for miners? If so, how do I solo mine with getblocktemplate?
I never worked with this protocol, but from what I read on wiki, it apparently forces me to connect to pools. My task is to do solo mining by all means.
Could you please provide or refer to example Bitcoin RPC call, that would:

Get a job to mine
Send mined block hash with all the mined info (nonce, etc.)

If possible, please, do not refer me to third-party software like bfgminer, etc. I'm implementing my own miner, and I need to know RPC calls to do it.

Unfortunately, the information presented on Bitcoin Wiki is misleading. All I had to do is to call getblocktemplate with
{
  rules: ["segwit"]
}

JSON object (it happened to be crucial to pass exactly a JSON object, not a string). And for the work completion all I needed to do is to send submitblock request.
Hope it helps someone who's also struggling to find any info about solo mining with
Bitcoin RPC.

what to do with the data from getblocktemplate ? I could not find any code that makes use of the output. libblkmaker is severely outdated


text:
How to dump all transaction from single bitcoin address?
How to get/dump/or download/curl request/ for all transaction from single address ??? I need info about txID's, scryptpubkeys, txinwitness and other deep info about transactions
Br.

What have you tried? What part of them job is causing most trouble?

Hello. I need dupm TXiD, ScriptPubkey, txinwitness FOR ALL Transactions. Manually dump 5000 transaction is hard, because blockchain.com give only 50 transactions per once request.

Have you tried submitting multiple requests?

blockchain,com not worked for me - json without txinwitness !!!

Have you tried Electrum-4.1.0 (https://electrum.org/#download)? You can see all transactions history.  There is also a python console that you can use.  Type help() to get all the command available.  If I were you I would start by getaddresshistory('') which will give you a list of dictionary (or a json) and you work your way from there.

This could help also: https://jsapi.apiary.io/apis/blockchaininfo/reference/detailed-bitcoin-data/single-address/get.html


text:
Does anyone know of any surverys/statistics on the Bitcoin ownership demographics?
I've only been able to find stuff from coin.dance, but was wondering if any of you have stumbled upon better data.

@Prayank sorry, should've mentioned that: https://coin.dance/stats


text:
Scan ports for my onion bitcoin node and RPC calls
I'm getting to work my first bitcoin node, it is running P2P through Tor network.
1: How can it be scanned? how can I see if its exposing any port, or port 8333?
2: How can I make RPC calls through Tor?.... maybe this is not the best way because of security for the RPC API and calls in plain data...
Thank you!

This seems to be more a question about Tor than a Bitcoin specific question, but:

If your bitcoind is set up to use a Tor socks proxy, by default, it will not listen for incoming connections (because by doing so, you'd be listening on your real IP address, which defeats the security you'd gain from Tor). However, if you really want to help the Bitcoin network by making your Tor-protected bitcoind available on port 8333, you will need to configure it as a hidden service. Refer here for information about this: https://en.bitcoin.it/wiki/Setting_up_a_Tor_hidden_service

You should set up a hidden service for your RPC port if you wish to make RPC calls through Tor, then from the computer sending RPC commands, send those commands through a local Tor SOCKS proxy. Set up your bitcoind to allow RPC calls only from 127.0.0.1 port 8332 (this will ensure your bitcoind will only accept RPC calls made through Tor), then set up a hidden service for port 8332.


text:
Trying to understand the mempool and how transactions are picked
I am very new to blockchain and try to understand it completely. What I think I understood is,
that every transaction is going to the mempool first and these transactions are getting picked by miners. With a bunch of transactions and the previous block hash a new hash needs to be calculated. And as soon as the desired hash is calculated a new block is mined.
What I dont understand:

Is one transaction only picked by one miner or is it possible, that more miners can pick the same transaction?
If only one miner can pick a transaction, what happens if this miner has weak hardware?
If more miners can pick a transaction, what happens to the other miners(that couldnt calculate the hash first).

I googled a lot and couldnt find an answer to this questions.
Hope this question meets the criteria and you guys can help me :).
Thanks in advance.

Solo Miners

Is one transaction only picked by one miner or is it possible, that more miners can pick the same transaction?

Each miner is free to pick whichever transactions they want. They have no knowledge of what other miners are working on. Miners might pick different transactions, some the same and some different or all the same. There is no explicit coordination.
Only when the rate of new transactions is low, it is likely that each miner will have the same set, or nearly the same set, of transactions to work with.

If only one miner can pick a transaction, [...]

Not applicable.

If more miners can pick a transaction, what happens to the other miners(that couldnt calculate the hash first).

When they see another miner has produced a new block, the others stop their work and start on the next block based on the new block produced by the other miner. They first remove from their mempool any transactions included in the other miner's new block.

Mining Pools
Things are a little more complicated for mining pools. Members of a pool coordinate their work cooperatively. But you can think of each separate pool as a separate miner and the above applies.
Stratum v1: Pools and solo miners are the only entities that are constructing block templates. Regular miners cannot because they don’t have the transaction sets to build the blocks.
Stratum v2: Every miner (who has it implemented in their firmware & a pool that supports it) will have the option to prioritize transactions however they want without impacting the other miners in the pool.

Further reading

Slides about basics of Bitcoin Mining by Daniela Brozzoni
What exactly is Mining?
What are bitcoin miners really solving?

Maybe my question was not clear? Can different miners pick the SAME transaction at the same time. And if this is possible. It would be possible, that a miner eith bad luck would NEVER mine a block and would never be funded?

@user1949096: If you wish, you can Edit it and/or explain why this answer doesn't address your question.

@user1949096: 1) Yes (but it isn't important), 2) Yes.

There is no coordination, so miners have absolutely no clue what other miners are trying to include in their blocks. It doesn't matter, mining is a purely local process, so anyone can create whatever block they want. Once their block is created, and broadcast, other miners can't include the same transaction in a successor block anymore of course; that'd be a double spend.

RedGrittyBrick and @Pieter thank you for your answers. So I think I understood it now. I try to explain: the same transaction can be picked by x miners. When the first block is mined, the miner gets a refund. The next miner, who creates the next block, which contains also this transaction, is also getting rewarded. So a transaction can be exist in more than just one block. Did I get it right?

@user1949096: Miners never get a refund. A transaction can only be in one valid block. A block is invalid if it contains a transaction that is also in some previous block. All other nodes (wallets, miners, etc) ignore invalid blocks and will eventually ignore persistently misbehaving nodes.

@Prayank: Thanks - I was editing at the same time as you :)  So I merged my edits into yours.


text:
Are mnemonic phrase order-sensitive?
Is it important to remember just the set of the words, or also their order?
If I kept them without the correct order. Can I easily decrypt my wallet?

The order is important.
If you have 24 different words but don't know the order, you have to try up to 24 factorial permutations. That is around 620448401733239439360000 different attempts. This may take a very long time and cause you great anxiety, unhappiness and self-recrimination.

Related questions:

Unsure order of 12 word mnemonic
Bruteforcing a seed with 24 words of a unknown order
Lost my old-Electrum 12-word mnemonic seed order
Bruteforce bitcoin address - I know the words + public address but not the order


text:
I used to mine Bitcoin back in 2015/2016 but can't find my wallet now
It was on an old laptop that I got fixed. The laptop works but I don't remember my the app names of the wallet I used or the mining software. I tried searching for 'wallet.dat' and it didn't find anything.
I searched my email for key words like 'wallet' and 'bitcoin' and the only thing I could find is an old link that doesn't work anymore but re-directs me to Slush Pool. I tried to reset my password but it keeps telling me that my password is incorrect even though it successfully lets me change my password (and is able to send me a password recovery email). I don't remember my phrase, but I can go through all my phone pictures from 2015/2016 to see if maybe I screenshoted it. This is kind of my last resort as I checked and I have 4,000-5,000 pictures on my phone from those years.
Am I out of luck?

Can you give us anything else to go on? What operating system did the laptop run? Do you remember if you installed the bitcoin node software. Do you remember if you worked mostly through applications or through web pages? What level of technical knowledge did you have about bitcoin and computers generally? Were you likely to have compiled/built software yourself? Do you remember if you mined in a pool or solo mined?

Windows 10 Home
I don't remember if Bitcoin node software was installed or not
It was through an application, not web pages
I have a decent knowledge about computers generally and beginner about bitcoin
I didn't build the software myself, I most likely installed a prepackaged one
I mined in a pool

@DavidSchwartz Sorry, forgot to tag you

If you mined in a pool, there are two possibilities: 1) You just left the bitcoin in your pool account and it was waiting for you to withdraw it and you need to get access to that pool account. 2) You setup automatic withdrawals to some wallet you had somewhere and need to get access to that wallet.

@DavidSchwartz It's definitely #1. Is there a way for me to access that pool account with the information I provided? If not, what else would I need to access that pool account?

If the pool is still around, email-based password recovery is your best bet.

@DavidSchwartz Thanks! I got in and found my BTC. Appreciate the help!


text:
Keep getting non base-58 character error when trying to recover my old wallet. Any ideas on how to troubleshoot this?
Basically I made a purchase with bitcoins back in ~2014 and I remember that I had a little bit leftover. However all documentation I have is a file labelled wallet with a huge string of characters. But when I try and access it on any application I get the non base-58 character error. There are a bunch of +'s and /'s. Does anyone have any idea what I could try to see if this is it? Sorry for not having more advance knowledge.

How are you trying to open this wallet? What software are you using? The wallet is likely not just a base58 string. It is probably binary data containing a lot of information including private keys and transactions. It needs to be opened by compatible software, preferably the one that created it.

I've tried exodus, bitcoin wallet, blockchain explorer (to see if it were a public key), and bitaddress.org. I can keep trying other programs that were around in 2014. Do you think you could glean any info if I posted the code (with letters and numbers changed, but the format the same)?

and / sounds like it is base64 encoding. No idea what it could be, though.

There are a bunch of +'s and /'s.

That strongly suggests it is data in Base64 encoding. Note that, in this case encoding does not mean encryption, just a specific printable representation of binary data.

Does anyone have any idea what I could try to see if this is it?

It seems several different wallets might use Base64 encoding, including:

Blockchain.info backup using AES encrypted JSON

Bitcoin Wallet for Android (Schildbach wallet)

Print wallet.dat with base64

Of those, I'd guess the first is most likely. But that's just a guess. There are probably numerous other possibilities.
I think I'd try the Blockchain.info recovery process first then, if that didn't work, try decoding the file from Base64 into binary and using a hex editor to look for patterns that might give some clues to the software that produced it. If the file is encrypted using a wallet password this probably would not be fruitful.

You can try this "dirty" trick to figure out what the data corresponds to type of wallet.
Get Python, john the ripper and hashcat.
put your text in a file called wallet.json
With the run tools in JTR try the following on the strings:
python bitcoin2john.py wallet.json > bitcoinhash.txt
python blockchain2john.py wallet.json > blockchainhash.txt
python electrum2john.py wallet.json > electrumhash.txt
now with the hashes try your password with hashcat. if it accepts the hash and your password then you know which one it is.
for blockchain check if the wallet version is 1 or 2, they use different mode and if its v1 it will most likely fail to decrypt as both hashcat and btcrecover does not cover all v1 wallets correctly.


text:
I got a wallet. dat file, how do I transfer the bitcoin into a new wallet
I have just a wallet.dat files with an unconfirmed transaction on it, can’t remember the backup paraphrase.
I linked the wallet.dat in bitcoin core,
got the wallet I’d where I check and it shows the coin is unspent but unconfirmed. bitcoin is inside but available balance on my Bitcoin core is 00000 and blocks not yet fully syncd.
I tried using procedure with the JSONVIWER but after putting all I was asked, I still got this
E2 -> Error Parse error on line ‘1’ parse error on line^
Expecting‘STRING’, ‘NUMBER’, ‘NULL’, ‘TRUE’, ‘FALSE’
‘{‘, ‘[‘, got ‘undefined
And left me with options ordered than OK.
I don’t know if my question does makes sense but that’s what I’m facing please some should help me

Open your wallet.dat file through text format or open your wallet.dat file with notepad++ .
Click CTRL + F -> for search box
Type name in search box - It will show your btc address. Open blockchain explorer or any explorer to find the balance in your address.
If the above things go smooth, your wallet has working condition.
Now, Uninstall your current bitcoin core wallet . Clear all the stuff on bitcoin directory like make it as fresh.
Now Install bitcoin core wallet -0.,18.1 edition in your PC. Open the bitcoin wallet directory and delete the wallet.dat file in bitcoin directory and copy and paste your wallet.dat file in bitcoin directory. Make sure your wallet.dat file was named as "wallet.dat"
Now open bitcoin core wallet 0.18.1, you don't need to care about sync process. Let you check the receiving address in windows tab menu -> receiving address to confirm your wallet file and Just move to console tab by clicking windows -> console. Type dumpprivkey yourBTCaddress and press Enter to reveal the private key of your wallet.dat file. Install Electrum to Import the private key in Electrum because it doesn't have the feature of downloading blockchain data. Now you can send the BTC to your current wallet.
If your wallet was encrypted like passphrase protection, then you can do this below steps..
If it's your wallet.dat file, then you can know some password hints of your own. Let you try with bruteforce method of hashcat(GPU method), BTCrecover(CPU method) and pywallet method.
If you tried and still you encountering with no luck on getting passphrase, Then you can try this method.
You can do this when it is your own wallet. If you are trying to do on some other people wallet.dat files, the it will be considered as stealing. However, Here you going to crack the private key of the encrypted wallet.dat files through reverse engineering core wallet called cracked btc core qt wallet. It can show the private key by typing dumpprivkey BTCaddress in console , even it was encrypted wallet.dat.
You can open your wallet.dat file through text format and press ctrl+F to search box and type name to find the btc address of wallet.dat file. You can dumpprivkey with the shown address in wallet.dat file for getting private key.
First, You should Install the Bitcoin Core wallet -0.18.1 https://bitcoincore.org/bin/bitcoin-core-0.18.1/
Second, Remove the wallet.dat in Bitcoin directory and move your wallet.dat file in bitcoin directory. The installed wallet.dat should be replaced with your wallet.dat that needs to be recovered.
Third, Watch the video to see how to dumpprivkey of your address without walletpassphrase or password to view the private key - https://www.bitchute.com/video/9UQ9mgDmzk4B/
Once you get the private key of your encrypted wallet.dat file, then install electrum in your PC. https://electrum.org/#download
Open your electrum wallet -> Create new -> Import private key(last option) -> Paste your private key and click ok to get your wallet view and spendable.
Hope its helped you.. Good Luck


text:
How can I transfer unconfirmed transactions from wallet.dat to a new blockchain wallet
My question may not be very clear since I’m not really an expert in bitcoin and its technology. But in my possession I have just a wallet.dat files with an unconfirmed transaction on it.
I followed a procedure of spending the unconfirmed Bitcoin from the wallet.dat wallet into a new blockchain wallet address.
At this level I have linked the wallet.dat with my bitcoin core, and even checked the wallet.dat balance on bitref and it shows the bitcoins is unspent but unconfirmed.
This is where I’m confused

available balance on my Bitcoin core is 0.00000 and blocks not yet fully syncd.
I tried using the JSON process of spending the bitcoins into a new blockchain wallet, after putting all I was asked in the process I got what you will see below.

E2 -> Error Parse error on line ‘1’ parse error on line^
Expecting‘STRING’, ‘NUMBER’, ‘NULL’, ‘TRUE’, ‘FALSE’
‘{‘, ‘[‘, got ‘undefined
And left me with no option than OK.
My bitcoin core version is 0.19.0.1
I don’t know if my question does makes sense but that’s what I’m facing please some should help me

You've sent funds to a Bitcoin Core receiving address and then discovered that Bitcoin Core is NOT the wallet that you really want to use. Either because it takes a better part of a week to sync the blockchain or you just don't like the wallet.
You don't want to wait for a full synchronization of the blockchain before transferring your funds
Here is the procedure in a nutshell:
Install a new bitcoin wallet (like BitPay)
Open Bitcoin Core
Open the debug console inside Bitcoin Core
Gather some information
Create a raw transaction
Sign the raw transaction
Broadcast the raw transaction

I tried the above procedure and got this E2 -> Error Parse error on line ‘1’ parse error on line^ Expecting‘STRING’, ‘NUMBER’, ‘NULL’, ‘TRUE’, ‘FALSE’ ‘{‘, ‘[‘, got ‘undefined
At the level of opening the "load url" and put in:   https://insight.bitpay.com/api/tx/


text:
Signature for this request is not valid
im testing the binance api but cant get over the signature problem can u spot a mistake on my signature?:
   const crypted = CryptoJs.HmacSHA256("timestamp=" + new Date().getTime().toString() + "&recvWindow=5000" , this.APISECRET).toString();

Probable duplicate of  Binance API SIGNED GET request error code -1100 on signature parameter

I am just taking a wild guess, your signature needs to be encoded correctly. You can see some examples in this ask.


text:
Why is Ethereum total network hashrate still increasing if there are no GPUS to buy?
The total Ethereum network hashrate is close to doubling relative to its December level. Mining difficulty is also increasing proportionally of course as the total reward per block stays the same.
However, it is impossible to buy new GPUs in large quantity anywhere. So, where does the computational power comes from? I can't believe that there was enough capacity used to mine other coins to double the ethereum global hashrate, but I may be wrong. So, where do all the new mining rigs get their power from?

People who already owned GPU before Ethereum became popular are joining mining now.
People with piles of money (companies mostly) buy GPUs directly from manufacturer or big seller (that's why GPU's don't reach retail markets mostly)


text:
Got bitcoin on generated address, now my wallet doesn't have the address anymore
I downloaded bitcoin.com wallet and immediately sent myself an email of my BTC address. Right after that I purchased some bitcoin through simplex. So the transactions (I made two, on the same address) went through, i can also see it on blockchain.info. The thing is, that I can't see it in my wallet. Also, the address I sent myself is also not visible in the wallet. I still have the email tho. I went back and forth with bitcoin support (one guy named Steven), i cleared my chache, generated all the new addresses, scanned for funds, I tryed everything he said. He also said that  the error message should not be showing, also stopped believing me about my issue. Ok, so here's the thing I want to know. How can I try to access my bitcoin just through the BTC address? Or at least, can I find out to wich wallet this address is linked to? Because if it is not linked to my wallet, which wallet is it linked then? Can a bitcoin address not be linked to a wallet?  If so, can anyone retrieve the money then? I will be very thankful for any response that could be helpful. Thank you in advance

How can I try to access my bitcoin just through the BTC address?

You cannot, you need the private key that controls the address to access any bitcoin stored on it. (Wallet software will control the private key)

Or at least, can I find out to wich wallet this address is linked to?

Without any other info, there is no way to tell which wallet an address is linked to.

Because if it is not linked to my wallet, which wallet is it linked then? Can a bitcoin address not be linked to a wallet?

It is possible to generate an address that is controlled by a private key no one know. For example see the 1BitcoinEater address.

If so, can anyone retrieve the money then? I will be very thankful for any response that could be helpful. Thank you in advance

Unfortunately, no. If your wallet does not contain the private key for that address, the money is likely gone forever.
It is very strange that the wallet would display an address that it does not have the private key for, for any further help you'll likely need to continue with the bitcoin.com customer service reps. Sorry for your loss :(


text:
How could LN mitigate NAT transversal problem?
As we all know, IPv4 address space is already exhausted, many ISPs have deployed carrier grade NAT (CGN). So how could an LN node living behind NAT deal with NAT transversal problem? How could two NATed LN nodes communicate with each other?

first of all if your lightning node sits behind a NAT it can still connect to other lightning nodes and also open channels with them. once you have channels you don't need a public IP address but your node id is enough. your channel partner and nat will solve the rest.
The problem is that your node behind a NAT does not have a public IP address. therefor you need to configure port forwarding in your NAT.
edit:
Also you can run your lightning node behind a toronion to have a static address.

To my understanding, port forwarding configuration is not available for CGN users.

There's another problem: on-chain funds are linked to IP address.

No, on chain funds are not linked to ip addresses. No ip Address stored in the blockchain

But IP address and funding txid are published across the LN, isn't it?

Only the funding txid and the nodeid but not the iPad dress of the node. The ip Adress is published at a different part of the protocol. That is why it is easy for the node to change its ip address for example if moved to a different server

Just edited the option to run behind tor into my answer

IPv6 is still growing, so the problem described should be temporary - as in solved within 50 years. In the meantime, how about a portforwarding arrangment like this: Bob's LN node connects to his (ipv4) webserver on port 9736; Alice connects to Bob's webserver on port 9735; Bob's webserver sends inbound traffic on 9735 out 9736 and vice versa.


text:
Is there actually a dilemma of whether or not to publish channel states for LN nodes?
I've heard that there is such a dilemma for LN: if channel states were not published, the payer will not able to find any viable path, unless he takes brute-force-like probing approach (which looks quite unscalable); if the channel states were meant to published, the economic privacy of LN users would be sacrificed.
Does such dilemma exist? If such idea is wrong, why?

I suggest we say channel balance instead of channel state (the state is encoded by a signed  commitment TX and if it leaks you could loose your funds)
As for the balance such a dilemma indeed exists. Indeed routing becomes more trial and error without public channel balances. Yet, there will probably be methods that allow to predict routes with higher probability.
On the other hand, there is not only the privacy aspect speaking against public channel balances. One would have to announce every balance update to the network which happens for every payment and  would result in an infeasible high payload of gossip messages.

To add to Rene’s answer: The protocol design currently allows the probing of viable paths to leak just enough information to let you determine whether all channels along route provide adequate liquidity or not, without revealing the individual channel balances.
Note though that one could use probing (receiver and sender controlled by same individual) with different routes and amounts to derive/compute the exact or approximate liquidity in a given channel of interest.

However, this is only reveals the liquidity that a channel node is willing to offer for routing. There is nothing in the protocol that enforces a node to offer all its liquidity for routing.


text:
Bitcoin Core has some confusing UI text
I'm trying to localize following UI texts of Bitcoin Core, but I cannot understand them:

Cannot upgrade a non HD split wallet without upgrading to support pre split keypool. Please use -upgradewallet=169900 or -upgradewallet with no version specified.

What's "non HD split wallet"? What's "pre split keypool"?

Warning: Private keys detected in wallet {%s} with disabled private keys

What's "disabled private key"?

What's "non HD split wallet"? What's "pre split keypool"?

Bitcoin Core uses something called HD chain split for generating private keys. This means that it derives private keys using two different derivation paths to distinguish between addresses that the wallet gives out and change addresses (also known as internal addresses). This split also means that there are two different keypools.
However the initial implementation of HD wallets in Bitcoin Core did not use HD chain split hence such wallets are non HD split wallets.
Furthermore, non HD split wallets and non-HD wallets had only one keypool from which all addresses (including change) were retrieved from. When upgrading such wallets, they need to be upgraded to a specific version that allows upgrading the unified keypool to the split keypool. This results in those wallets having a third keypool called the pre-split keypool. This keypool contains all of the keys from the original unified keypool and lets that run out of keys before the split keypool is used.

What's "disabled private key"?

Wallets can be created such that they will not have any private keys and are not allowed to contain private keys. Such wallets thus have private keys disabled. (this string should really say "with private keys disabled" not "with disabled private keys").

So "non HD split wallet" should be "non-split HD wallet" actually, because it's in fact a kind of HD wallet?

BTW, I hope future versions of Bitcoin Core could be able to manage the keys/addresses more clearly. Currently it's quite confusing to use Bitcoin Core

It should be "non HD-split" as we consider "HD-split" to be a type in addition to HD, and non-HD.


text:
Do lightweight wallets validate signatures? If not, why?
I've learned that "some SPV clients simply don’t check signatures themselves at all": https://bitcoincore.org/en/2016/01/26/segwit-benefits/#efficiency-gains-when-not-verifying-signatures
I wonder if popular lightweight wallets (like Electrum) nowadays do signature checks? If not, why?

Some lightweight wallets do not check the signatures because checking the signature requires data from the previous transaction. However lightweight wallets generally will not have the previous transaction to fetch the data from and are thus unable to verify the signatures.

Incorrect, lightweight wallets most certainly have enough data to verify signatures via merkle root. How well they do it is another story, but it's is not unable.

Merkle roots are completely unrelated to signatures. The merkle root is about the block, not about signatures.

Interesting, I assumed because the merkle root was reliant on the transaction hash it thus had some data of the signature in it - but according to the whitepaper: "He can't check the transaction for himself, but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it." Which means it's really just relying on the network, not doing proper validation itself. I stand corrected

Lightweight wallets know each input of a transaction, thus they should be able to fetch every previous transaction, up to the coinbase transaction. I've also learned that Satoshi once said: "The recipient just needs to verify it back to a depth that is sufficiently far back in the block chain, which will often only require a depth of 2 transactions. All transactions before that can be discarded."

No, lightweight wallets can't fetch previous transactions. A full node will not relay transactions that are already in the blockchain. So a lightweight wallet would be unable to fetch previous transactions once they confirm. A lightweight wallet could fetch blocks, and from there the previous transactions. But they don't know which blocks, so they would have to fetch all of them.... and now we have described a full node.

I see Electrum, which should be a typical lightweight wallet, supports loading transaction from blockchain, by txid.

Furthermore, I see Electrum can tell whether a 0-conf transaction has a confirmed parent or not.

Beyond the viability of validating signatures for lightweight wallets, I think whether such validation actually makes sense might be more important. In some other word, will validating signatures improve security for them?

Yes, validating signatures does improve security. Being able to validate signatures means that you can partially check if a transaction is valid. This means that you are less likely to accept invalid transactions. However, signature validation is not the only thing for checking if a transaction is valid. You also need to check that the transaction spends coins that exist, and you can't really do that without validating the entire blockchain.

Most lightweight clients do not validate signatures in Bitcoin. While Simplified Payment Verification (SPV) was introduced in the bitcoin whitepaper as a method of verifying payments without the whole blockchain
re:

It is possible to verify payments without running a full network node

SPV has found most of it's usage on wallets that are unable to allocate the resources for a full validating node. The popular example belongs to the mobile wallet.

I wonder if popular lightweight wallets (like Electrum) nowadays do signature checks? If not, why?

Electrum isn't a standard lightweight wallet. Typical lightweight wallets connect via the bitcoin protocol directly to bitcoin seed servers and communicate directly with bitcoin servers.
Electrum does not do this. Electrum lightweight clients connect to Electrum servers, therefor it doesn't make sense for Electrum lightweight clients to take the burden on validation (when at best they could do a sub par job as SPV isn't perfect and results in plenty of false positives)


text:
Is backward syncing viable for full nodes?
Currently, Every Bitcoin Core full node has to download the whole blockchain at least once. This situation is even worse if pruning is enabled - the user has to download the whole gigantic blockchain all over again if a rescan is required (typically after importing privkeys/addresses/wallet.dat).
I once heard that "backward syncing" might help. I also heard that "UTXO commitment" could eliminate the need for downloading old blocks. I wonder what exactly are them? Is there any relationship between them? Is there any technical hurdle that is very hard to overcome?

In bitcoin we add unspent entries to the UTXO when created inside a block, and delete them when they are spent. Syncing “in reverse” would be a messy process that wouldn’t allow for the verification of authenticity of the blocks being imported until the sync was entirely complete, where going forwards we have complete confidence in blocks as they progress.
The software can reverse blocks to undo changes to the state during a block reorganization, but this is excruciating slow as it requires going back to the older blocks using a reference list and reinserting the UTXO entries that were previously removed.

"UTXO commitment" could eliminate the need for downloading old blocks.

UTXO commitments don’t remove the need for full validation, they introduce a new weaker level of node operation where they trust that miners have included valid commitments.
UTXO commitments also require an extremely large amount of hashing to achieve, which makes them implausible for use in the production network without other changes.

the user has to download the whole gigantic blockchain all over again if a rescan is required (typically after importing privkeys/addresses/wallet.dat).

BIP157 allows for wallet rescans without the block data being retained.

I see Bitcoin Core enables assumevalid by default, so by default it doesn't actually fully validate old blocks independently, right? In other words, the user trusts the developer who hardcoded the block hash if he never sets assumevalid to 0.

This is to prevent a denial of service where you produce infinitely large numbers of difficulty 1 blocks. Only signature validation is skipped, and this peg hasn’t been updated in many years.

Checkpoints, instead of assumevalid, are intended to defend against DoS attacks, which is a legacy that hasn't been updated in many years as far as I know.

As for BIP157, I heard it's for lightweight clients. I wonder if it's possible that a malicious full node feeds incorrect data to the client intentionally?

You can make your own 157 filters and discard the blocks, giving you a compact data set to rescan from without trusting anybody else.

assumevalid only disables script verification as that is expensive. Everything else (PoW, UTXOs, merkle root, etc.) is still checked. Assumevalid and checkpoints are actually very similar, they even share the same code. That's because assumevalid was designed to have the performance benefits of checkpoints without the requirement of blocks needing to be in the blockchain. Neither really defend against DoS attacks; rather that's what minimumchainwork is for. It requires that the cumulative chainwork must be at least that value.

When Bitcoin Core starts using BIP 157, it won't be for syncing faster. Rather it will generate the filters for every block it receives and store that. The filters allow rescans to happen much faster, regardless of whether the node is pruned or not. In both cases, the filter will indicate whether a block contains a transaction pertaining to the wallet so the block can be fetched (either from disk or over the network) and the necessary transactions pulled out. BIP 157 helps both pruned and archival nodes at no security risk. It only affects disk space and sync time (making filters takes time).

@AndrewChow Why minimumchainwork is intended to defend against DoS attack? I see no block height data tied to it.

I also found this: https://bitcoin.stackexchange.com/questions/76018/how-does-headers-first-prevent-fill-disk-attack?noredirect=1&lq=1#comment87815_76021

minimumchainwork does not need to have a block height tied to it. The chainwork is what determines what the best blockchain is. The blockchain that your node uses is the one with the most chainwork, not the one with the most blocks. Otherwise I could trivially make a blockchain that is millions of blocks long with all blocks being difficulty 1. minimumchainwork protects from those kinds of DoS attacks because it immediately ignores those low difficulty blocks since the blockchain they are part of does not have sufficient chainwork.

@AndrewChow According to the link above, I see minimumchainwork doesn't prevent header-fill attacks, since it actually allows the attacker to produce trillions of garbage block headers, which would trick a node into meaningless header validation work.

Checkpoints don't prevent that either. You can make trillions of garbage block headers now and trick a node into meaningless header validation work. Validating headers is not particularly expensive though. Checkpoints make it harder to create a large low work fork, but minimumchainwork prevents your node from being forced to validate all of those blocks (you would still validate the headers).

Validating a header is almost free, fortunately, though connecting them and storing them is not.


text:
If a user recovered data directory of LN node software with an old backup, what would happen? Would cooperative channel closing be possible?
As far as I know, the "Data Loss Protection" feature would just request the counterparty to unilaterally close the channel. I wonder if mutual closing is still possible, with old channel states?
By the way, I roughly remember that I once seen a comment like this:
Before the "Static Channel Backup" feature was introduced, there was once a bad situation that the funds could be permanently lost, even if the channel counterparty unilaterally closed the channel. However, this bad situation was a trade-off in exchange for better (or easier) watchtower implementation.

No, a mutual close is not possible. For signing a mutual close, both the parties should be aware as to what the current state of the channel is at. Since one of the party has fallen behind, it does not know how much it is owed (or more correctly cannot prove to the other party how much it is owed). Moreover, if the last signed commitment transaction included adding of HTLCs, it is impossible for the fallen behind node to know what those HTLCs are, if the pre-images were sent, or if the HTLCs have timed out.
The one way that can be though of is that when the other party detects that its peer has fallen behind, it sends its peer the last signed serialized commitment transaction (without signatures) that it holds and the signature that the fallen behind peer sent it. They can then negotiate the closing condition including the fees. However, the protocol allows only messages that are not more than 65535 bytes long. Commitment transactions can be as much as 400,000 WU (>100,000 bytes) so it would not fit in a single Lightning message. May be the protocol can use the new TLV format to indicate multiple messages to follow, but as is, the current specs do not allow it.

I'm confused. What did he mean in this tweet? https://twitter.com/forieq0/status/1187411491554779136?s=19

That is confusing. I think what they are referring to is that force close is not allowed when both parties are synced up. If one party sends a channel_restablish message and the other party detects that it's peer has fallen behind then the specs recommends force close. Try reading Olaolu' reply. It seems they had backed up an old state which led to force closure.

I can't see why mutual closing is impossible - on the contrary, to my understanding, it's much better than requesting the counterparty to unilaterally close the channel, because unilateral closing consumes more vbytes, thus more miner fee/block space. Unilateral closing also introduces a to-local delay, ironically, the data-losing party doesn't suffer from such time-locking, AFAIK.

By the way, I had actually asked the second question: was there once a period that using an old backup was still unable to recover the off-chain funds, and, these funds were permanently lost/destroyed, because the corresponding private keys didn't exist in the world any more.

@ChrisChen I do not know the answer to the second question. I might have to search the web for it. If you find it then you can comment here and then we can see as to what the reasons were. Coming back to your first question, the problem with mutual close is that the other party has lost all its commitment transactions since a particular point. So it does not know how much it is owed. The only way to prove is that the counterparty sends the last signed commitment transaction to it. Can you think of how you can let the fallen behind node know what the balance of the channel is?

Might be related: https://bitcoin.stackexchange.com/questions/92149/lightning-why-are-commitment-transactions-supposed-to-use-different-keys


text:
Why hasn't cold storage (offline signing) been supported by Bitcoin Core (GUI) up till now (0.19.0.1)?
Is there any deep reason not to support this? Or is this merely a "good idea, but no volunteers" situation?
By the way, although Bitcoin Core had supported BIP32 several years ago, it uses hardened derivation for addresses, which makes it impossible for the watch-only side to derive new addresses for receiving/change, or used addresses to watch transaction history and final balance.

Prior to segwit doing this securely required carrying around enormous prior transactions.
Prior to PBST there wasn't a standard serialization that covered all the interesting use-cases.
It's been possible to offline sign for years using the CLI and many people have been doing so.
More recently this PR adds a GUI for doing this using PSBT: https://github.com/bitcoin/bitcoin/pull/16944

Some update on this: unfortunately SegWit (v0) doesn't avoid the requirement of enormous prior transaction data: https://blog.trezor.io/details-of-firmware-updates-for-trezor-one-version-1-9-1-and-trezor-model-t-version-2-3-1-1eba8f60f2dd ( which was even discovered before SegWit activation actually: https://twitter.com/theinstagibbs/status/1268302648366624768 ) Even if SegWit/Taproot etc can fix it, IMHO it still doesn't fundamentally solves the problem, because even without the prior tx, the tx data itself can still be huge, at least exceeding capacity limit of one single QR code.

PSBT makes multi-sig, offline signing easy (interoperable/compatible among vairous different types/models/brands of wallets), however, in my opinion PSBT still doesn't fix two problems: (1) the QR code data capacity limit mentioned above; (2) the wallet setup process, eg. mnemonic format, HD derivation path, script/address type, gap limit etc.

I don't agree that it doesn't avoid the requirement-- the resign attack pattern is pretty contrived. Of course, better to have it fixed.   I don't see why you're hung up on QR codes,  -- don't use them.

To my understanding QR code is better than USB thumb drive/bluetooth etc, because the later two have their own attack surfaces. It's also slightly better than something like amodem probably, because sound "broadcasts" in air naturally.


text:
How could PSBT deal with data capacity limit of QR code?
QR code has very limited data capacity. (According to Wikipedia) one single QR code can only carry <3KB of binary data.
It's not rare for a PSBT to hit this 3KB limit, especially for ones which spend non-SegWit UTXOs.
SegWit features signing of input values - on the other hand, signing non-SegWit inputs on offline/hardware wallet still requires full data of previous transactions to validate input values. Otherwise, it could be a security issue: a malicious party/malware could tamper the inputs stealthily to trick the user into paying an unexpected high amount.

A solution is not using QR codes for an inappropriate purpose. Find something else.

Use multiple QR codes

@AndrewChow Multiple QR codes seems to require something like sequence number/checksum etc, maybe fountain code would be better.

@Anonymous I think at least QR code is better than USB, because I'm concerned about ADB. ADB has been "abused" by various companies, including both Android handset vendors and software vendors for quite a long time, they had turned ADB from a debugging interface into something for everyday use (as something similar to iTunes), thus countless users had already carelessly left ADB enabled.

@AndrewChow I posted this question mainly because Electrum had implemented BIP174 in a deviated way: to make the PSBT fit in one single QR code, they allowed the insecure signing mentioned in this question. Since BIP174 is intended to be used across multiple wallet implementations, I think this is not an issue only limited to Electrum.

Additionally, BIP174 didn't seem to have any checksum, did it? Since a single bit flip could lead to tragic outcome - erroneously sending coins to a black hole address, considering PSBT might go through unreliable communication channel, it seems that checksum would be helpful.

It was out of scope of the BIP to describe how PSBTs should be communicated. You can use other encoding methods to ensure proper transmission of the PSBT. With multiple QR codes, you can use a Forward Error Correction scheme where you just need to see an amount of data that is the size of the PSBT (you send a lot more than just the PSBT) so order doesn't matter.

@AndrewChow Yes, it's obviously out of scope of BIP174 - however, communication channel affects compatibility/interoperability, doesn't it? If so, we need something more than BIP174 to solve this, otherwise, as far as I can see, a wallet using FEC won't interoperate with another one using simple multi-part QR code with sequence number. I'm sorry for just complaining, however, I think this is a problem that deserves more attention.

Besides compatibility/interoperability, there's also a security issue (signing insecure inputs), isn't it?

I don't expect a newly proposed specification/standard could completely eliminate this problem, however, I think it should at least improve the situation a lot, better than doing nothing.


text:
Are lightweight LN wallets vulnerable to transaction withholding?
As far as I know, LN requires the user to watch the blockchain in order to perform penalty in time. However, running full node is probably a heavy burden to some users, especially to mobile phones. I once heard that improved protocol for lightweight wallet (like Neutrino) can solve this problem, but I also heard that such lightweight wallet protocol still implies trusting the full node or server which provides service. Especially, a malicious full node can hide transactions from its clients, which seems to be a potential threat to lightweight LN wallets.

There is no substitute in terms of security and trust for running a full node.
There are different "lightweight client" concepts. Some of them are...
BIP37 (bloom filter):

[minus] With current used false-positive rates, peers may learn all wallet addresses
[minus] Usually done over an unencrypted channel (p2p 8333), ISPs, etc. learn also all your addresses
[plus] client can validate if the transaction(s) were in a block (merkleblock)
[plus] clients keep a blockchain with headers only can at least check PoW
[plus] uses only little bandwidth
[minus] Hiding back transactions are possible
[plus]"Impossible" to fake a transaction

Neutrino (Compact Block Filters BIP158):

[plus] fewer privacy implications then BIP37 since filtering happens locally
[minus] needs more resources (basic filters from the genesis block up to block 560000 require ~3.5GB space/bandwidth)
[minus] more bandwidth consumption because full blocks must be downloaded (rather then Merkle-"blocks" in BIP37)
[minus] Hiding back transactions are still possible (though more complicated) because the block filters are not committed to the blocks (would require a soft-fork). Not committed means, peers can fake filters and make you miss relevant transactions (can be [partially] mitigated by comparing filters from different peers)
[minus] No solution for mempool filtering (can't show "incoming transactions" reliable)
[plus] "Impossible" to fake a transaction

Centralized Validation (Bitpay, Samourai, etc.)

[minus] Full trust in the company/server (they know all your addresses)
[minus] Can hide back transactions
[minus] Can artificially create transactions
[plus] Minimal bandwidth consumption

Some application mix different approaches (like Electrum does Merkle-tree checks and keeps a headers-only-chain to mitigate the "can artificially create transactions" problem).
Conclusion
If you want to watch the blockchain without trusted third parties, you must run a full node (could be pruned though <10GB space requirement, but lightning implementations are not fully compatible yet).
If (and only if) BIP158 block filters get committed (though a soft fork, hash in blocks coinbase of similar), hiding transactions through peers, providing filters, would no longer be possible.
Recommended practical approach

Buy a tiny computer (Raspberry, Odroid, Pine64)
Buy a >500GB SSD (USB3 SSD, ~100USD in 2019)

NO,.. don't use your old HDD (your sync time will be 20 times slower).

Install Bitcoin Core (there are pre-build ARM64 binaries)
Run with a large -dbcache (if you have 2GB+ RAM)
Sync the chain
zzzZZZ (takes maybe a week)
enjoy being a real Bitcoiner (by avoiding all trusted third parties)

I wouldn't say it's impossible to withhold transactions in neutrino, at least in its current implementation.

Depending on where you get your filters from, if from the p2p network, someone could intercept traffic (MITM) and hand you out "void" filters... but its not easy since maybe BIP157 is in use and clients keep a filters-chain.

The current implementations are very dumb. It has the ability to do better in the future, but for the moment it's about on par with bip37 in that respect.


text:
When, and why did people use 1-starting P2PKH address to represent bare-pubkey P2PK outputs?
I notice that some web blockchain explorer, like https://blockstream.info, doesn't show the famous "Satoshi's bitcoin genesis address" (1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa) for me in the genesis block: https://blockstream.info/block/000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f

The same happens to the famous "first used (spent) bitcoin address ever" (12cbQLTFMXRnSzktFkuoG3eHoMeFtpTu3S) as well:
https://blockstream.info/block/000000008d9dc510f23c2657fc4f67bea30078cc05a90eb89e84cc475c080805

AFAIK, these addresses have been mentioned in various places, like this analysis on genesis block - despite technically such addresses "didn't exist at all" because P2PK outputs are different than P2PKH outputs.


text:
Which cryptocurrencies are considered base coins?
Are these the only base coins: BTC, ETH, BTH and LTC?
Base coins are those that you can buy directly (USD -> base coin). Alt coins such as NEO, XRP and EOS require first going through a base coin.

In the context of defining basecoins as those that change directly with USD, there are actually quite a few. The 4 you've listed are available through Coinbase, which is currently the most popular fiat to cryptocurrency gateway.
However, there are many exchanges that still accept USD/EUR/JPY/KRW deposits with some level of verification. For example Bitfinex allows for fiat deposits after verifying your account, and they have 20 or so crypto assets (including EOS, XRP, NEO that you mentioned). I'm sure there are many more exchanges that allow fiat deposits, even if crypto deposits are growing increasingly popular for legal reasons.

Thanks. Then what is the definition of an alt coin? One that you cannot go fiat to crypto-coin directly? Also, do you know why Coinbase doesn't allow as many fiat to crypto-coin purchases as Bitfinex?

An alt coin is essentially any token/coin other than bitcoin. Even the bitcoin fork BCH is considered an altcoin to most people.

Coinbase is regulated and is located in the U.S., so they're slow to move. Two years ago, they only had BTC and ETH. Now they're slowly adding more assets as alt coins gain popularity and usability.

Where did you find the definition of alt coin as anything other than BTC? If not an alt coin, what is BTC considered? I'm not sure why BTC would be considered the center of the crypto universe when it's one of the most limited coins out there.

The name "alt" stands for "alternative to bitcoin" https://www.investopedia.com/terms/a/altcoin.asp . Even though bitcoin is the least advanced, it has the most secure network available due to global distribution of miners and hundreds if not thousands of exchanges. It leads the current economic movement that all cryptocurrencies and platforms are currently facilitating. Technically, all proof of work coins (~60% or so) are forks of the bitcoin protocol with a different name.


text:
How is mining associated to blockchain transactions?
I know how mining works and how transactions are added to the blockchain. What I don't understand is the association between the two...if any.
I've read a few times about how a cryptocurrency transaction is added to the blockchain through consensus. This often means PoW. Then there is mentioned that miners perform PoW and the transactions are cleared. How?
Miners mine for coins right? What does mining have to do with verifying unrelated transactions?
At least for bitcoin, is it even possible for miners to keep up with all of the transactions occurring?

How users / nodes see it:
When transactions are made, they stay in nodes' memory pools ("mempool") until a block that contains them, becomes mined and relayed. When this happens, that transactions become a permanent member of the blockchain (unless that block is orphaned).
How miners see it:
Miners' major incentives are block rewards. However, to maximize their profit, they can also include transactions in their block (According to BlockChair, 124k of 510k blocks include no transaction.) If they include transactions in their block, they'll be able to collect their transaction fees. That's why most of the blocks include transactions (and the miners who don't include transactions are mostly illogical).
tl;dr When miners include your transactions, your transactions become a permanent element of the blockchain. They do this to collect your transactions' fees, to maximize their profit.

Using bitcoin as an example, are you saying that when miners mine for bitcoin, each mined coin creates a block on the blockchain as a byproduct? How is that viable with bitcoin given the large number of transactions and then amount of time it takes to mine a coin? Seems as though miners can't mine enough to create new blocks for all of the transactions.

@4thSpace No, they mine for blocks and new coins are the product. And adding transactions to your block doesn't affect your luck finding a block. BTC miners can't put all of the transactions in their mempool, because there is a 1 MB (actually 4 MB with SegWit) limit of transactions you can put into your block. Miners put the transactions with the most fee/kb to their blocks, to maximize their profits.

Do you have a reference to discusses miners mine for blocks? First time I've heard of that. Everything I've read so far says they mine for coins, not blocks.

@4thSpace There has been 2 blocks, which their block reward was not claimed; however, there can't be any newly created coins without a block. Of course, miners absolutely mine for coins, and I was trying to say that coins are the product of block, not vice versa.


text:
Token vs contract - are they the same?
The Ethereum ERC20 token is also the contract. The token can never live without the contract. The name of the contract is the name of the token. In the code, the keyword is contract and not token.
I may hold 4 ETH but does that mean I'm holding 4 ETH contracts? If that is the case, why call them tokens at all?
Is everyone exchanging tokens or contracts?
For an ICO, there is an ICO contract created to limit supply and issue tokens. If the contract is the token and the ICO contract goes away after the ICO, how do the tokens exist?

On ethereum, all tokens are contracts, but not all contracts are tokens.
ERC20 is a specific type of contract that is recognized by everyone to be a token contract. It has a base definition and structure that is defined in the ERC20 spec regarding how transfers, balances, approvals, issuance, etc. work.
An ICO or anyone issuing a token will write an ERC20 contract that specifies things such as the initial supply, price of the token (if it is being crowdsold), bonus rounds, etc. This contract is deployed on the ethereum blockchain, and functions as the token. Any given user's token balance is simply a value that the contract says that user controls.
Ethereum is native to the platform, and does not have an underlying contract. It is not an ERC20 token.
You can also have non-ERC20 contracts, such as the lottery contracts, DAO contract, Ethereum Name Service contracts, etc. A contract can be any variety of programs in solidity.


text:
Blockchain.info testnet payment APIs
I have created a testnet wallet on testnet.blockchain.info and added some testnet bitcoins to it.
I want to test the payment APIs so I am following the documentation on how to Generate a receive address. Yet I do not see a way or an URI to register a testnet receive address.
I tried to use it as is and I've put my testnet xpub in the query but I get this error:
{
    "message": "Invalid xpub format",
    "description": "Ensure you provide an xpub key, rather than an address"
}

Anyone had success using blockchain's payment APIs with testnet before?

Blockchain.info doesn't support API for Testnet network.
That API Pages for Mainnet network. What you can use blockcypher as an alternative, they're supporting Testnet for bitcoin.


text:
Filter transactions by time on a given address
Is there an API that will list all transactions made on a given wallet address with the ability to filter by date? I prefer nodejs, but open to other suggestions.

Not exactly what you were looking for but there's a site that does exactly this, check it out.
https://goochain.net/
Filter on dates/ find adresses with partial numbers etc.

I dont see any APIs I can call programmatically

On Blockchair you can do that, e.g. to find all transactions to Satoshis Genesis block address 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa made in 2023 you could go to: https://blockchair.com/bitcoin/outputs?s=time(asc)&q=recipient(1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa),time(2023-01-01..2023-12-31)
To build that URL you need to go under "outputs explorer", then filter by "Recipient" and "Time".


text:
Bitcoin core delay in synching
My bitcoin core is delaying in sync saying two years remaining. And av sent bitcoin from my block chain wallet it's been deducted but am not seeing it. How can I go about it seeing that I can't wait for two years. The synching is not fast

The "two years behind" is not telling you how long the synchronization will take but what time you are caught up with. Bitcoin processes history much faster than real time.  If you are at two years behind you are most of the way done.  If you click the "behind" text it should give you an estimated time left counter.
Syncing speed depends on your hardware. The first time takes anywhere from a day (on reasonably fast hardware) to a few days (on slower hardware).  After that it doesn't take long on restart.


text:
Making a backup of my wallet
Let's suppose I make a backup of my wallet when it has 0.001 BTC, but then I transfer to it 0.001 BTC more (so at the end it has 0.002 BTC) and then my PC dies...
If I restore my wallet it will have 0.001 or 0.002 BTC?
Supposedly all transactions are recorded on the network (blocks), so what I understand by backup wouldn't be a backup, but rather a way to re-make my wallet on another device and my final balance will always be rescued no matter if I did a restore with a backup made one day or 5 years ago...
or do I have to do a backup once in a while?

0.002, coins are always on the blockchain, not inside your wallet.

If you made the second transaction to same Bitcoin address so yes you will not miss that second transaction even if you made the transaction after the backup.
if you made the transaction after the backup and you made the transaction to a different address you will also get any future transactions for two reasons:
1- Bitcoin Core using HD wallet so you have one master private key and they derive all your future addresses from that one seed.
2- if you are using old bitcoin wallet or HD wallet set to 'OFF' you will still have future transactions but not forever and that because of the limit of keypool future.

Keypool New public and private keys are pre-generated and stored in a queue
  before use.
This pooling feature was added so backups of the wallet would have a
  certain number of keys that would be used in the future. By default,
  the number of entries in the queue is 100[1].

Your backup contains in the wallet.dat file the keys (amongst others). With these keys the wallet would lookup the amount of the funds on the blockchain. Whatever is recorded on the blockchain, will be displayed by your wallet software. (The wallet does not keep the amount, it is not the ledger - blockchain is).

If I restore my wallet it will have 0.001 or 0.002 BTC?

You'll have 0.002 BTC.
You are ok with your backup, and if you use bitcoin regularly, a general rule of thumb is a monthly backup. Backup is always a good protection mechanism against data loss - that shouldn't happen to your keys. If you have a five year old backup, how do you assure data is still readable? (this is media dependent, for sure). Also, in 5 years, wallet software may have changed data structures. Better increase backup cycles!


text:
Can government agencies trace if I mine bitcoin?
I live in a country where the government has strict rules against using bitcoin. in fact, they are trying to find out the citizens who are related to bitcoin. I was just wondering if they can catch me if I just mine bitcoin without doing any transaction? if yes then I wanted to know if there are any alternatives which can make me untraceable.

Data linking is the only way there is any question of privacy. When you transact with Bitcoin, the goods or service you order will need to have a delivery address. Also, if you send your BTC to any merchant, service or, an exchange that has your personal data there will be a presumption that the sender was the owner of the inputs used and is the person that they have records for. There is no known way around this.
Apart from that question which exists for all cryptocurrencies, you may wish to consider implementing some of the configuration for privacy from here for your mining setup. Sound advice is, do not break the law.

If you are going to mine any significant amount, you'll consume a substantial amount of energy, which may be noticed.  For instance, if I were to install a single AntMiner S9 at my home, my electricity consumption would go up about 400%.  If the government runs your electric company or can monitor their records, this sort of thing could prompt an investigation.

When a new block is mined, newly generated coins are placed in whichever address they are mined to. If you do not transact from the mining address to somewhere like an exchange that has your personally identifying information, there is no way to know who mined the coins based on the address alone.
As there is no easy way to determine who actually mined a block, and who is just relaying it to other nodes, you might suspected of mining simply by connecting to nodes in your area. Depending on the monitoring done by your government, connecting to any node in the world that your government is aware of may lead to suspicion.


text:
Why do we inverse the hash of the blockheader?
Let's pick this example blockheader-hashing in Python:
from hashlib import sha256
import hashlib
header = "0000002066720b99e07d284bd4fe67ff8c49a5db1dd8514fcdab610000000000000000007829844f4c3a41a537b3131ca992643eaa9d093b2383e4cdc060ad7dc548118751eb505ac1910018de19b302".decode('hex')
print sha256(sha256(header).digest()).digest()[::-1].encode('hex')
// result is 00000000000000000020cf2bdc6563fb25c424af588d5fb7223461e72715e4a9

I know that it's part of the protocol and otherwise, a block will not be accepted, but:

Why do we not accept a hash that ends with all those zeros? Is it because it's easier for a program to calculate if hash < expected_hash?
But in this case, I don't understand why do we do not simply accept a hash sha256(sha256(header).digest()).digest().encode('hex') that is lower than the expected hash? The probability to get that should be as high as the inversed one.

So what's the reason of inversing it?

https://en.wikipedia.org/wiki/Endianness

Why do we not accept a hash that ends with all those zeros? Is it because it's easier for a program to calculate if hash < expected_hash?

Counting the number of leading or trailing zeroes does not give a lot of granularity. If represented as a hex number, then there are only 64 possible target values if you are counting just the number of zeroes. If in binary, that is 256 possible values. Furthermore, counting the number of zeroes means that you can only change the difficulty by some power of 2 (in binary, the difficulty has to be doubled or halved). There are thus not many values for the target and this loss of granularity is bad.
Conversely, comparing the value means that there are (in theory) 2^256 possible values for the difficulty. This is much more granular, and these values are integers. Instead of having to change the difficulty by multiplying, the difficulty can be changed with addition and subtraction. By having more values, the difficulty will be less likely to be too hard or too easy.

But in this case, I don't understand why do we do not simply accept a hash sha256(sha256(header).digest()).digest().encode('hex') that is lower than the expected hash? The probability to get that should be as high as the inversed one.

It is actually just like you said. The reversing of the hash is only for how the bytes are actually represented. They are stored as bytes and interpreted as a little endian 256 bit integer. The comparison is still an integer comparison and the data representation is irrelevant (they could just as easily be stored and represented as big endian integers). But when they are displayed, they are displayed as big endian values in hexadecimal because humans are accustomed to big endian. The reason for little endian is likely because the x86 architecture uses little endian for storing integers.


text:
Assumed, I hash the next bitcoin block. Whom do I tell if it's decentralized?
The bitcoin network is decentralized, right?
Assumed, I do hash a little bit and get a hash that starts with 20 Zeros..
What do I do than? I need to send the block to someone but who is that? It's decentralized... Do I send it to all the other miners?

Bitcoin’s open source software does that for you. There’s no need to do it manually. If you insist on it though, i’d recommend reading the p2p code from the repo.

You don't tell a specific node on the network, but rather broadcast your block to the entire network.  You essentially scream it from the rooftop.
If it's valid, it will be in the best interest of everyone to recognize your block and start mining on top of it.

"You essentially scream it from the rooftop" Ok, but how exactly? That's what I don't understand.

You are connected to multiple nodes.  You send it to all the nodes.

And they will send it on to everyone they are connected to.

You broadcast it to all the nodes you are connected to (usually at least 6), and they broadcast it to all the nodes they are connected to and so on. In this way it propagates across the whole network.


text:
How to know e-Wallet with xpub
How can I know what's e-wallet name provide the wallet?
When I know xpub and xprv and mnemonic
When I get mnemonic (12 words) and get xpub I can get balance with blockchain API
But how can I know what wallet company provides this wallet?

How can I know what's e-wallet name provide the wallet (...) When I know xpub and xprv and mnemonic?

You cannot. A mnemonic seed phrase, xpub, and xprv does not explicitly contain information about which wallet software was used to create that wallet. Generally this is not any issue to the user though, as this information alone should be enough** to recover the wallet, using any software which follows similar standards.
** you may also need information about the derivation path used, and the address type, in case the original wallet did not follow one of the more well-used standards


text:
In bitcoin-cli getpeerinf call what does "-1" mean as a "synced_headers" or "synced_blocks" value?
Sometimes I see this in getpeerinfo:
"synced_headers": -1,
"synced_blocks": -1,
sometimes it's only synced blocks at -1.
What does that mean?

It means you either have no headers, no block, or both known to be (*) in common with this peer.
From the help:
$ bitcoin-cli help getpeerinfo
....
    "synced_headers" : n,          (numeric) The last header we have in common with this peer
    "synced_blocks" : n,           (numeric) The last block we have in common with this peer

(*) As Pieter cleared in the comment it doesn't mean you aren't on the same chain, just that the peer didn't announce any block to you yet.

Yes I saw that help but are you sure of the meaning of -1? How is that possible that I have no block in common with so many peers, this -1 is not rare I see this all the time.

It's possible because they haven't announced any blocks to you yet. It doesn't mean "no blocks in common", it means "no blocks known to be in common".

Ah ok thanks for your reply MR Wuillle. And why they didn't announce any block? What can prevent a node from announcing its blocks?


text:
Where does it go and who verifies private keys?
Let's imagine a situation: I want to send bitcoins to a friend. I need a private key to identify my wallet ownership. So: where is this key sent and who verifies it? Wallet (client)? Nodes? Miners? Who?

There are a few steps involved here.

You create an address. That address is the hash of the public key corresponding to a private key you generated. This is a purely local operation. No communication with the network (or anyone) takes place.
You give that address to someone.
They create a transaction that credits (the hash of) your public key. This hash is stored in the transaction T1, and known to the entire network once it confirms. The coins are now yours.
You get an address from your friend.
You create a transaction T2 that credits your friend's address, while spending the coin you just received. That coin was encumbered with your public key hash, so it needs a proof that the corresponding key owner agrees with the spend. For that purpose, a digital signature created with your private key on, and included with, this T2 transaction. Every (full) node verifies this signature. That includes miners, but they just do it because they don't want to risk creating a block that includes a transaction that is invalid (which would mean losing their payout for the block).

The private key is used when signing a transaction. The private key usually goes into a bitcoin wallet, and the wallet software handles the signing and storage of your keys. Do not give your keys to anyone. Anyone with your private keys can spend just the same as you so it is important to keep these safe and preferably offline.
Yes your wallet software will verify the signature (not the key) before broadcasting as well as any listening nodes.


text:
Duplicate Wallet
I had a wallet on an exchange. For a few months I was using it with no trouble. Then one day I sent some BTC to it and it never showed up in the wallet on the exchange. I can see it in bitcoin explorer though. I can also send from the wallet on the exchange to an offline wallet...

"Then one day I sent some BTC to it and it never showed up in the wallet on the exchange." and "I can also send from the wallet on the exchange to an offline wallet" contradicts each other.

How? I said duplicate wallet addresses. You can check this address 1JG6QGxpS4wWk5ERw2F8mg5QHLjtd2w45Y on bitcoin explorer. Yet, when I access the wallet from the exchange, it does not show the BTC. I was fully able to send to an offline wallet from the exchange. But if you send to that address it will not show up on the exchange.