text:
Comparing "health" of Cryptocurrencies
I am new to cryptocurrencies, and I would like to explore how an analyst might compare the "health" of two coins, for example, Bitcoin v. an altcoin.
For a company that issues stocks, analysts look at its accounting details (e.g. book-to-value, credit spreads, long-term debt) and equity returns.
For a foreign currency, I fathom it is almost impossible. People question the demise of the US dollars, but it retains its value in the foreign exchange market. One could look at the accounting details or balance sheets of the US Treasury or Federal Reserve, but I don't think these are as helpful as the Fed's FOMC announcements in explaining the USD foreign exchange rate volatility.
For Bitcoin or any altcoin, if you were an analyst,
(1) How would you define the (accounting if there is any) variables that drive the performance of the coin?
(2) Are these observable (e.g. thus data-collectible) or not? If not, are there good proxies?

@Jannes Haha thanks! I am just trying to gain some insight, for example, as a beginner or analyst, why would you choose Bitcoin over Ethereum? Are there "health metrics" that convince you to make such a decision?

Why is this question closed?

@FrankSwanton thats actually being discussed in this site's chatroom right now, fwiw I've changed my mind and voted to re-open.

I voted to reopen this question, because I'm not convinced that the "not about Bitcoin" reason applies to it.

Thanks guys! So how do you choose Bitcoin over say Ethereum when you decide to choose your investment coin?


text:
Are there two versions of the armory webpage?
I'm seeing https://btcarmory.com/ and http://bitcoinarmory.com are both sites. Are they both legit? what is the reason for the duplicate? They seem to be slightly different.

https://bitcoinarmory.com is Armory's original webpage when it was maintained by Armory Technologies Inc. (ATI) They still control that webpage but it is currently unmaintained.
After ATI stopped maintaining Armory, the open source community picked it up with one of ATI's former employees taking the lead maintainer role. The website for the open source community fork of Armory is https://btcarmory.com.
You should be using https://btcarmory.com because that website is still maintained and the software that is listed there is also maintained.

btcarmory.com is the best one to use.
bitcoinarmory.com has not been updated since version .96 was released.

source: Stack Exchange

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

sort: votes


text:
bizarre transactions involving one address
Why would anyone spend $65 in fees to send 500+ outputs for .001BTC to the same address?https://blockchain.info/tx/0270a4af1269b52bf242390076faa460cfcffe2db74bc748163d8de94e9ce875
then clicking through to the input address, it has some really bizarre transactions. Tons of transactions that have undecodeable outputs, and also, blockchain.info shows that only .003 btc was transacted for many of them, when clearly more was transacted. Indeed, clicking through to the transaction itself shows the correct amount. What is going on here??
https://blockchain.info/address/1F89hmmrtonJfAQNAqDmeDadcw7AsZcvXG

The undecodable outputs appear to be OP_RETURN scripts whose purpose is to insert a short message or data snippet into the block chain.  They are not so bizarre.

The "amount transacted" is based on blockchain.info's guess that some of the outputs are "change" that's being paid back to the sender.  So only the part that doesn't appear to be "change" is reported as "amount transacted".  It's based on heuristics and can be mistaken or tricked.

so what about the .001BTC? are all 500 of those to encode data? If so, where is this data?
Is there a chance this is an attack to fill up the mempool?

That I do not know.

https://blockchain.info/address/1F89hmmrtonJfAQNAqDmeDadcw7AsZcvXG
The "Unable to decode output address" are as Nate commented OP_RETURN scripts whose purpose is to insert a short message or data snippet into the block chain. They are not so bizarre
Looking at some of the timestamps on the smaller transactions they are not all sent at the same time and fairly spaced out like someone might be manually making the transactions as opposed to a script running.  Each transaction is approx 30 USD so maybe not so unusual?

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


text:
For the 3 bitcoin address types, which can send to each other? Can a valid tx be created that spends to an unspendable address?
I'm just getting started with using bech32 addresses instead of legacy addresses, and I'm not familiar with how the legacy vs segwit compatible vs bech32 addresses play with each other.
Can I get an explanation or 3x3 square for the 3 address types on what can send to what, what would be lost forever, if any, and what the error messages or problem with sending from one to another would be?
(I'm interested in the deep dive, but probably just a description on how to avoid losing any coins would be most helpful.
If I give my friend a bech32 address, I want to make sure that when he sends to it, the worst case is that he gets an error. Is there any extra care I need to take, or is that how it generally works now?)

What you can spend, and what you can send to depends on the wallet software and nothing else.
There are no inherent restrictions on any combination.
In case someone uses old software, they may not be able to send to bech32 addresses. But they'll get an error that the software doesn't recognize the address; no funds will be lost.

Is there a different syntax (and thus, size) to create a valid tx from each address type?

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


text:
What is off-by one error in updating target? How is it fixed?
Can some one explain completely what off by one error is? how is it fixed?

In the bitcoin blockchain, the difficulty of mining is adjusted after every 2016 blocks. If the average mining time for the last 2016 blocks was higher than 10 minutes than the difficulty is reduced so that the time readjusts to 10 minutes. While if the time to mine the last 2016 blocks was lower than 10 minutes, then the difficulty is increased.
Although the target calibration happens every 2016 blocks, because of an "off-by-one" error within the Bitcoin Core client, it is based on the total time of the previous 2015 blocks (not 2016 as it should be). Because you are now including the time for the last 2015 blocks but comparing it to 20,160 minutes (2016 x 10 minutes), this results in the target bias upward by ~0.05%.

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


text:
What did I do wrong that caused me to lose bitcoin?
I've been accumulating bitcoin into a paper wallet for a couple weeks. It's all been stolen. I'm trying to figure out what I did wrong:
https://www.blockchain.com/btc/address/193jdrxMKoUjWLyKm2UCGNXLGGvK1x3FDV
I've been very careful with this wallet. I purchased bitcoin on Bisq. Over time I was sending them to a paper wallet that I generated on bitcoinpaperwallet .com. I printed this paper wallet on a piece of paper hidden inside my house. I never saved the private key anywhere on my computer.
As I transferred funds into the wallet, I would verify they arrived by checking blockchain .com. They always did.
A week ago I transferred a lot more bitcoin to this same paper wallet. Today I checked and the wallet was completely drained, hours after the last transfer and soon after I verified they arrived (using blockchain .com). The bitcoins seem to have been instantly transferred to a bunch of wallets downstream and scrambled.
I'm completely baffled as to what I've done wrong. I searched my computer to make sure I didn't accidentally save the private key somewhere, it's nowhere to be found. But I knew that I didn't do this. I was very careful when generating the paper wallet. The only place the private key is on this piece of paper.
No one in my house knows anything about bitcoin, and anyway, this paper has been kept concealed.
What did I do wrong? Any clues?
P.S. Since I know someone will ask, the reason I didn't use a hardware wallet is that I was going to save this paper wallet on multiple encrypted USB sticks. I don't trust the hardware wallets to be secure and recoverable ~10 years from now when those companies may be gone and their software may be outdated.

Can you elaborate on how you generated the paper wallet? Did you do so in a web browser? Did you save the .html file and then run it while offline? Did the computer that generated the keys ever go online again later? What sort of printer did you use, is it connected to your network? Your answers to these questions may provide clues. Sorry you were robbed :(

I use Chrome as my daily browse so I bitcoinpaperwallet .com in Safari and printed out a few copies of the wallet on my printer. It is a network printer but it's just on my local wifi. I did leave Safari open on my Mac for a few days with the paper wallet still open in the tab, but minimized it in the background. I'm 99% certain no one saw it on my screen as Chrome is always in the foreground and my computer locks after a few minutes of inactivity. I didn't save the HTML file, my only guess is somehow leaving this open something scrapped it? But browser tabs are pretty well isolated processes.

I just read about CookieMiner and now I'm wondering if I possibly have malware on my computer. I'm very careful about things like this. However, I just tried one malware scanner just now and it found nothing. I'm not sure if CookieMiner is being picked up by current malware scanners.

The site bitcoinpaperwallet.com was sold in April 2018
https://github.com/cantonbecker/bitcoinpaperwallet
And after this time many people wrote that their bitcoins were stolen. Draw your own conclusions.
P.S. To use hardware bitcoin wallet - https://trezor.io . It's safe way to keep and send bitcoins

1) If you generate your paper wallet on your computer, you have to fully trust your computer
2) If you use a website for generating your paper wallet, a) you need to trust that website (hopefully its local javascript) b) your browser and its random number generator and c) eventually your network provider(s) (depending on the transport layer security)
3) If you generate your paper wallet on your computer and it was compromised, the generated paper wallet was accessible at least during the time of your generation.
My recommendation
1. Never ever use a online paperwallet generator
2. Hardware wallets are eventually not super secure, but they offer great security, maybe use them instead of a paperwallet
3. The BIP39 24 word seed can be restored even if the vendor of your HWW disappears
Conclusion:
Use an old offline computer with Bitcoin Core or any other semi-trusted software to generate your private keys or seeds, keep it offline all the time!
Or... use multiple hardware wallets from different vendors in a multisig setup if you want maximal security (but comes with minimal user experience)

I said "old" computer because we can assume that older computer have less risks of included hardware based backdoors (like the intel management engine, etc.)

Another possible attack vector is the printer, especially if it is a network printer.

Also your printer may store a lot of info in it's memory. Including the private key :(

The site bitcoinpaperwallet.com was sold in April 2018 https://github.com/cantonbecker/bitcoinpaperwallet
And after this time many people wrote that their bitcoins were stolen:
1) https://www.reddit.com/r/Bitcoin/comments/cs68ri/my_paper_wallet_generated_on/
2) https://www.reddit.com/r/Bitcoin/comments/bjz1r9/my_private_key_from_my_paper_wallet_was_hacked/
Draw your own conclusions!
P.S. To use hardware bitcoin wallet - https://trezor.io . It's safe way to keep and send bitcoins

The scam was most likely on the paper wallet creation tool. But don't give up fast and try to get the funds back.
With high likelihood the thief sent part of the funds to his kraken.com account. If he did a KYC verification at kraken or cashed out then kraken might know the id or a bank account number. Or if withdrawn again then kraken should know to what address.
I assume that kraken is a cooperative company to hand over information if police asks or if you get a court order. Especially because the stolen amount seems to be high.
I'd report this information to police and if the thief wasn't too smart (fake id or temporary used bank account) you might have a chance to get the funds back.
This is how the funds got to kraken (I have access to non public forensic tools)

February 27 the funds were sent from 193jdrxMKoUjWLyKm2UCGNXLGGvK1x3FDV to 15mUHhJ2ZvFvmKKKGtgd5otygsTrMqWCca with transaction 4f9fc1f57de81c32841c6e41febd610f4d1477f106a84012e4a5acab77cad542
At same time in same block s/he resent it to address 1EkazEZe98eCFsbFQ8vsRQicemHLNkq1oE with transaction 21796cae9e80a4eef8ca565e507ac62d0e2cb9b7b09b97437145a6eb256e9b77
About two hours later the thief sent BTC 2.96009354 from 1EkazEZe98eCFsbFQ8vsRQicemHLNkq1oE to 3PMw63UXmoG2w8Su3yL4DtScmCNpGRKRpd in transaction 90d095850d5bd9a6942b3e8fb71ea3f96aca8c50a7bf8d57c0818ca5d8706a3d
This address 3PMw63UXmoG2w8Su3yL4DtScmCNpGRKRpd belongs to kraken.

More can be investigated in case this one trace isn't successful (looks like the thief emptied many more paper wallets).
This is the output of the forensic tool:
"Forensic analysis BTC address 1EkazEZe98eCFsbFQ8vsRQicemHLNkq1oE
The BTCtester analysis tool found that address 1G14RygU7NmsZjp3vVHvkzuvVczvgy1BY3 belongs with high likelihood to the same entity.
The BTC address 1EkazEZe98eCFsbFQ8vsRQicemHLNkq1oE sent funds to BTC address 3PMw63UXmoG2w8Su3yL4DtScmCNpGRKRpd which belongs to the exchange Kraken.com.
This result is a snapshot at 2019-12-27 16:48:32.891217 (UTC+1).
With appr. 300,000 new BTC transactions per day there is a good chance that future transactions will bring new insights about the analysed BTC address. Therefore we recommend a regular repetition of the analysis.
Your BTCtester team"


text:
testnet.blockchain.info api not showing latest results?
I sent a transaction to the testnet address mzWCWQU6phb9rKSAiQ4FBU92sGYtY7tjPH a few days ago and I have been using the testnet.blockchain.info api for a while now in my project.
It was working fine last month but now it doesn't seem to be getting the latest transactions.
This is the api call:
https://testnet.blockchain.info/multiaddr?active=mzWCWQU6phb9rKSAiQ4FBU92sGYtY7tjPH
and this is the same address on Blockcypher:
https://live.blockcypher.com/btc-testnet/address/mzWCWQU6phb9rKSAiQ4FBU92sGYtY7tjPH/
Does anyone know what the issue is?

I noticed a few weeks ago that the URL https://testnet.blockchain.info now redirects to the main BTC/BCH/ETH explorer page. The whole site has a new look, and new coins.
If you search for the address via the web interface, you can see the testnet transaction: https://www.blockchain.com/btctest/address/mzWCWQU6phb9rKSAiQ4FBU92sGYtY7tjPH
Given the recent changes, is it possible they just haven't yet changed over the API for testnet?


text:
transactions and 51% attack?
I have a very basic understanding of how the bitcoin blockchain works and am trying to understand how manipulating transactions in a 51% attack works.
I just watched a video which stated 51% attacks can't steal bitcoins from people's wallets. Is this true?
My understanding is if someone successfully implemented a 51% attack i.e. they created a longer chain than the current chain, then they would most likely have manipulated one or more of the transactions which had been confirmed in the original true bitcoin chain.
I assume the reason they can't steal someone's bitcoin directly from their wallet is because they would be unable to create a transaction to send bitcoin from that person's wallet, as they would need their private key to do that.
That said if for example William had sent 1 bitcoin to Sarah who previously had 0 bitcoin in her wallet. Could they not simply remove that transaction from their new/manipulated chain? This would then mean Sarah no longer has the 1 bitcoin in her wallet effectively stealing that 1 bitcoin from her.
William would still have the 1 bitcoin meaning he could now reuse that 1 bitcoin. I assume this is what they mean by double spend i.e. he can now spend that same 1 bitcoin again.
If this is possible then the blockchain would view Sarah's wallet as having 0 bitcoin. If in a later block Sarah had sent that 1 bitcoin to her friend Helen, then wouldn't that transaction be invalid? If so would this mean the person creating the fake blockchain would have to also remove that invalid transaction?
If that is the case it could presumably create a knock on effect where multiple future transactions are now invalid. Helen's wallet (like Sarah's wallet) could have only contained the 1 bitcoin Sarah had sent her, so if Helen had sent that bitcoin to someone else that transaction would now also be invalid.

I just watched a video which stated 51% attacks can't steal bitcoins from people's wallets. Is this true?

Yes, 51% attack cannot steal coins controlled by other people's keys. When you sign a transaction with your private key, you include the entire transaction data as a message in the signature hashing algorithm. Thus changing any data within the transaction (output value, address of the receiver etc.) will render the signature invalid and hence the transaction as invalid. An attacker can only make cosmetic changes like signature malleability (S component of signature can be replaced with -S) which can also be done by any other miner or an intermediate node in between that is relaying your transaction.

My understanding is if someone successfully implemented a 51% attack then they would most likely have manipulated one or more of the transactions which had been confirmed in the original true bitcoin chain.

An attacker cannot manipulate transactions as I have stated above. What the attacker can definitely do is exclude the transaction from their version of the chain thus bringing in a censorship attack.
When you read news articles like "attackers stole coins from 51% attack" it does not mean they changed the transaction data. This is how the attack happens: An attacker sends some coins to an exchange. This gets recognized on the Bitcoin blockchain and after that gets reflected in your exchange account. Now on the exchange portal the attacker exchanges BTC for any other coin like say ETH and withdraw the ETH coins from the exchange account to their personal wallet. Now, they launch a 51% attack and create a different version of the Bitcoin blockchain that has excluded that transaction in which they sent the coins to the exchange. After your chain becomes the longest it will be accepted as the main chain. Thus you end up in BTC and the ETH that you got from the exchange. Although I have given the example of Bitcoin, do note that BTC has never experienced a 51% attack.

This would then mean Sarah no longer has the 1 bitcoin in her wallet effectively stealing that 1 bitcoin from her.

Yes, this is the same example I have mentioned above. However, as confirmations on the transactions increases, the more difficult it is for an attacker to exclude transactions.  If there are tens of confirmations on the transaction, then reorging with just over 50% hash rate will take days if not weeks. Thus most recent transactions are more vulnerable to the attack than previous ones.
I think rest of your questions follow the similar tone. It is a best practice to wait for 6 confirmations, but if the amount sent is really large enough, it will be prudent to wait for tens if not hundreds of confirmations.

Thanks for taking the time to answer my questions.
Just to be clear though. If there are 3 wallets, A,B,C.
Wallet A contains 1 bitcoin and wallets B and C contain
0 bitcoin. In block 100 wallet a transfers it's 1 bitcoin
to wallet B. Then 3 blocks later in block 103 wallet
B sends the 1 bitcoin to wallet C.

If the owner of wallet A now wanted to implement a 51%+ attack
to get their 1 bitcoin back (this just for example as it
would of course be to costly to do this for just 1 bitcoin)
they would need to start their own side chain from block 100
and remove the transaction from that block where their wallet
A tranfers 1 bitcoin to wallet B.

When they then come to mine block 103 on their side chain i
assume the side chain will now view the transaction for wallet
B to wallet C as invalid, as wallet B now contains 0 bitcoin thus
has no bitcoin to send to wallet C. This means that transaction
will also be removed from the side chain. Is this correct?

@Stephen yes. you are correct.


text:
Is one lightning network channel equal to one transaction?
I understand how a lightning network channel is like opening a bar tab, where you can make multiple transactions off-chain between two parties, and closing the channel puts the total tab on-chain. However, if I'm visiting 20 different stores and making one transaction at each store, wouldn't I need to open 20 different channels and end up publishing 20 different transactions to the bitcoin blockchain anyway?

No you don't need to open a channel with everyone whom you want to pay.
The lightning network is a network of payment channels. This means that you can use the first channel to send money to other participants in the network as long as there are sufficiently liquid paths of channels from your node to the recipient.

So a channel could contain as many participants sending money between each other as possible, and then when it closes, it counts as a single multi-signature transaction?

currently a channel is between 2 peers. in theory one could have a multiparty channel and it would be have as you suggest have a look at the channel factory paper for which was discussed and referenced here at https://bitcoin.stackexchange.com/questions/67158/what-are-channel-factories-and-how-do-they-work the point is because of the network structure a payent can be routed to your channel partner and towards other peers. this does not need several peers in one channel but several channels per node


text:
Finding my Bitcoin and my wallet
How do I recover my lost Bitcoin wallet I have had in the past that I know have collected Bitcoin but I don't know how to access them

What do you have to recover it from? What do you know?

It depends how lost it is. If your OS crashed, boot it into recovery mode, decrypt the key (if necessary) and then copy back. Otherwise, it could be harder if not impossible.


text:
I was working on testnet but I'm lacking BTC ammount, can anyone help me please?
I was working a testnet project which requires Taproot btc , But I'm lacking of it, I need around 0.1 BTC, can anyone please help me? it will be a big help>>
tb1pjx30lagtgfeh6vkuqtwx5jzttsg3qnvtp3sdvre7vqkx3rjwc95qwf3d6t

This question is similar to: How can I get more than 1 BTC on testnet?. If you believe it’s different, please [edit] the question, make it clear how it’s different and/or how the answers on that question are not helpful for your problem.


text:
Are these Addresses Invalid ones?
I saw some addresses in blockchain that the format look "too pretty" to be valid:
- 1fuLL1xxxx1power1xxxxxxxxxxzatvCK
- 1xxxxxxxxxxxxxxxxxxxxxxxxxy1kmdGr

I assume these addresses are actually valid ones, but must never and will never get the private keys from which they are generated (i.e. No one can get the coins on these addresses). Am I right?
If I'm correct, why this guys even send (very little) coins to these "invalid addresses"? For Ad purpose? For fun?

You're correct, they're valid addresses, just that nobody will ever have the private key that corresponds to them.
As for why people send money to them... sometimes just for fun, and sometimes to encode data on the blockchain. This particular transaction might be a dust attack, of which the goal is to uncover which addresses are owned by the same owner, in case the owner attempts to spend the dust along with other coins in their wallet together.


text:
Why not use address in raw transaction instead of public key bytes
In raw transaction, bitcoin using bytes of the public key, like:
042daa93315eebbe2cb9b5c3505df4c6fb6caca8b756786098567550d4820c09db988fe9997d049d687292f815ccd6e7fb5c1b1a91137999818d17c73d0f80aef9

It takes a lot of bytes.
Technically, can we use bitcoin addresses (e.g.1MBngSqZbMydscpzSoehjP8kznMaHAzh9y ) instead to make the blocks smaller?

In raw transaction, bitcoin using bytes of the public key, like:
042daa93315eebbe2cb9b5c3505df4c6fb6caca8b756786098567550d4820c09db988fe9997d049d687292f815ccd6e7fb5c1b1a91137999818d17c73d0f80aef9

Technically the raw transaction contains the Script, which usually is written with Bitcoin script that is a stack-based language. It can contain the PubKey in the old scripts, like P2PK but the community is making a big effort to move the bitcoin users to use the script that contains the hash of the public key. The script like Pay-to-Public-Key-Hash (P2PKH) or pay-to-witness-public-key-hash (P2WPKH).
from the script, it is possible to calculate the address but not vice versa.
In conclusion, all the addresses have a conversion like:

P2PK, P2PKH: Start with 1.
P2SH: start with 3.
P2WSH, P2WPKH: Start with bc or with 3.

At this point, the answer should contain a resume of all the types of script and how the script is built, and also an introduction to the not standard script that is used extensively from the lightning network protocol.
But I think a very good summary is inside these two chapters of the Bitcoin book 'Transactions' and 'Advanced Transactions and Scripting', I can't do better
Update
I'm not a fan of theory, maybe you can use also this code example to understand how the script is converted on a Bitcoin address.
Decompiler Bitcoin Script.
it is only an example of the conversion that could be done.
The usage of the example code is described inside the bash script run-decompiler.sh
An example with the following block is the following ./Decompiler 76a914536ffa992491508dca0354e52f32a3a7a679a53a88ac
With the following result
----------------------------------------| Results |-----------------------------------
                               ###  Script PAY TO PUBLIC KEY HASH  ###
  Raw Script PubKey: 76a914536ffa992491508dca0354e52f32a3a7a679a53a88ac

OP_DUP OP_HASH160 536ffa992491508dca0354e52f32a3a7a679a53a OP_EQUALVERIFY OP_CHECKSIG

 The address: 18cBEMRxXHqzWWCxZNtU91F5sbUNKhL5PX
 The Hash160 pubkey: 536ffa992491508dca0354e52f32a3a7a679a53a
 The P2PSH address: 39JC9tvQ5CANbfuPgUZ4Zdc227m5uQnMRB

 https://blockstream.info/address/18cBEMRxXHqzWWCxZNtU91F5sbUNKhL5PX
______________________________________________________________________________________

See the result here https://blockstream.info/address/18cBEMRxXHqzWWCxZNtU91F5sbUNKhL5PX
Please consider this example as an example of code, I developed this to understand how de script works. Can contains error. I will work to integrate this in my project and I will maintain this post update.
To answer at your comment that is

Thanks. I use you the code linked, the the result address codepad.org/nRJhvMC3 does not match the expected address blockchain.com/btc/block/1 So what's the usage of this Decompiler?

The decompiler takes the hex of the script and try to calculate the corresponding address if it is a standard script.

Thanks. I use you the code linked, the the result address http://codepad.org/nRJhvMC3 does not match the expected address https://www.blockchain.com/btc/block/1 So what's the usage of this Decompiler?

Oh, I see, interesting, I have some bug in the P2PK deserialization, sorry you have right.  I will fix it for the P2PK. if you run the script you have a complete summary where is contained the link to see the address information on an explorer. Sorry for the P2PK deserialization. I update the post with an example of how to use the code

I fixed the bug with this commit https://github.com/vincenzopalazzo/decompiler-bitcoin-script/commit/b5540532f2e15e867be44573af4617711db96f31  thanks so much and sorry, now you can see with the following command that you address if calculate the same ./Decompiler 410496b538e853519c726a2c91e61ec11600ae1390813a627c66fb8be7947be63c52da7589379515d4e0a604f8141781e62294721166bf621e73a82cbf2342c858eeac. Look here the result https://blockstream.info/address/12c6DSiU4Rq3P4ZxziKxzrL5LmMBrzjrJX


text:
Where can I find people who support Bitcoin as a "Purely peer-to-peer form of electronic cash"?
I think it would be great to have a group with the purpose to support Bitcoin as a currency. What would be the best way to organize it?

If you want to talk with people who want to stay on a purely monetary network I invite you to look at people with the hashtag #FixTheFilters on Twitter.

We are everywhere. I suggest starting with Bitcoin Knots and contributing to other projects depending on your own abilities.


text:
Bitcoin Core v.26 crashes or closes unexpectely in Ubuntu Linux os
On Ubuntu my bitcoin core v.26 closes every few minutes without saving the downloaded blocks unless I close it first. Maybe a bug but how do I fix this? I updated version 22 to  v.26 because v.22 was not opening anymore at all and crashed totally. So, now I have 31753 blocks left to download and it is taking forever by closing it before it crashes without any warning, so its like a roulette game and very time consuming! Please HELP fix this. Thanks guys!

not totally sure what could be causing this. But I am running a full node on a raspberry pi (1GB ram) and before I editded my bitcoin.conf file, I would notice my bitcoin daemon would get randomly disappear. I found some information when I ran cat /var/log/kern.log (on rapian OS, not ubuntu)
which I realized I was running out of ram. So after that I tweaked my config file and my OS stopped killing the process.
Can you look for OS logs to see if theres resource management issues going on?

What do you mean by "tweaked my config"?


text:
What are all the actions that can be performed with a seed phrase
I am asking this question because  someone (malicious) else has access to a seed phrase I created and transacted for the first time. So the wallet is active in the blockchain.
Currently the seed phrase doesn’t store any founds on my end.
But I imagine can it still be used. Is it useful in anyway ?
Can somebody explain if there are risks associated to
This situation?
I’m not using that wallet I created a new one to store my coins.

Anyone with the knowledge of a seed phrase has complete control over the funds stored with that seed phrase. It is not safe to use, and any transactions made with it in the past can be linked together as belonging to one wallet, that's all. I am not sure why someone malicious (as you call them) would send funds to a seed phrase they know is not under their complete control, since you could easily sweep them to yourself.
As an example, I went to https://iancoleman.io/bip39/ and generated this seed phrase:
fabric nice tissue private subject decrease crazy repeat illegal pulp depart reward

Since I've shared it here it is now insecure and sending any funds to an address associated with it (e.g. bc1qq6hkw49wexxsd4n3avfwjkc06fejdwlxgxzqcq) means someone else will eventually take them. But as long as I don't use this seed phrase in the future, I have not compromised my security in any way.

Could a miner be interested in a seed ? Since their job is to process/verify transactions do you think he can use it to verify transactions for himself ?

A miner has no special abilities with regards to a seed. Like any actor, a miner with a seed would still need someone else to send/have sent bitcoin to an address derived from that seed in order to steal anything.


text:
How to make bitcoin-qt respect -prune?
I'm using Bitcoin Core 0.18.0-rc2 (64-bit) on Qt 5.9.7.
How can I make it respect -prune=550?
This is the minimum prune number, and should be approximately 550 MB.
Yet, my client is downloading tens of gigabytes worth of data, with no end in sight.
In "Options" it is stated:
"Options set in this dialog are overridden by the command line or in the configuration file: -prune=550"
Hence, it seems like the program is able to recognize the command line argument. It simply doesn't respect it as far as downloading and pruning the blockchain goes.
What can I do differently to fix this problem?

prune allows you to set the size of blockchain data stored, not downloaded. Therefore prune does not affect bandwidth usage.

TL;DR:  A pruned node is a fully validating node that is not an archival node. It does still process the whole blockchain from scratch, though.
Bitcoin Core is a fully validating node. Fully validating nodes check the entire blockchain from scratch to converge on the latest state of the network independently. By default Bitcoin Core runs as an archival node, where it keeps all blocks to serve them to other participants of the network. Running a Bitcoin node with -prune limits the data footprint of the node by discarding old block data after it has been verified. The pruned node keeps the newest blocks up to the specified data limit. Running a full node in pruning mode does not reduce the inbound bandwidth. Since it can only serve the latest blocks, it does reduce the outbound bandwidth indirectly.
To limit your bandwidth consumption, you can run in -blocksonly mode and disable peer services. If you don't want to download the full blockchain at home, you could download it somewhere else with a mobile device or copy it from another node (then preferably reindex to independently verify its validity). If neither is an option, you could look into other wallets that are not a fully validating node.

Are you saying there are clients that would allow me to use my wallet locally, without downloading the entire blockchain? I'm not that comfortable with the terminology. If so, what clients should I use?

Check out https://btcinformation.org/en/choose-your-wallet. You may want to have a look at Electrum for example.


text:
How do nodes come to consensus on whether a timestamp is valid?
From bitcoin wiki:

A timestamp is accepted as valid if it is greater than the median timestamp of previous 11 blocks, and less than the network-adjusted time + 2 hours.

If a miner submits a block timestamp on the cusp of the network-adjusted time + 2 hours threshold, some nodes will see the block as valid and some will see the block as invalid, regardless of the work done on the block. How do nodes come to consensus on whether the block is valid?

They don't need to.
If a block's timestamp is in the future, it won't be accepted - but it also won't be marked as invalid. Once enough time passes, the node will accept the block if it is offered or received again.
Effectively, the maximum limit on the timestamp is not a consensus rule, but just a temporary acceptance rule.

I had the impression that the nodes ask one another about their UTC timestamps and if it is within 70 minutes of your time, you use that to calculate the median of the network adjusted time.


text:
my account haked and black mailer give me add of bitcoin
I dont know who is that blackmailaer who send me a mail,,, copy below,,,
Sent: Monday, March 25, 2019 8:09 AM
To: lubby786
Subject: alqadar : lubby786
I am aware lubby786 is one of your passwords. Lets get directly to the point. Not a single person has compensated me to investigate you. You don't know me and you are most likely wondering why you are getting this e-mail?
wykyobnj alqadar lubby786 mrwvabxy alqadar lubby786 auxddu alqadar lubby786 zapesujzz alqadar lubby786 wkkuwify alqadar lubby786 npsaw alqadar lubby786 p alqadar lubby786 myeotoe alqadar lubby786 yamieyvib alqadar lubby786 z alqadar lubby786
in fact, i setup a software on the xxx vids (porn) web site and guess what, you visited this site to have fun (you know what i mean). While you were viewing video clips, your browser started operating as a Remote control Desktop having a key logger which provided me with accessibility to your display as well as webcam. after that, my software collected your complete contacts from your Messenger, social networks, as well as email . and then i created a double video. 1st part shows the video you were viewing (you have a fine taste hahah), and next part displays the view of your web cam, and it is u.
d alqadar lubby786 iyry alqadar lubby786 lvijty alqadar lubby786 huyje alqadar lubby786 tegkimtog alqadar lubby786 rwaj alqadar lubby786 yhazawega alqadar lubby786 iqrbeya alqadar lubby786 tnhucafq alqadar lubby786 coravelal alqadar lubby786
You got not one but two solutions. Shall we understand each one of these possibilities in particulars:
hoesro alqadar lubby786 dyeihkad alqadar lubby786 kcacxhemo alqadar lubby786 ejdkoy alqadar lubby786 dwouvmofc alqadar lubby786 jiocufeo alqadar lubby786 liirabae alqadar lubby786 bkuedx alqadar lubby786 toyhwveby alqadar lubby786 gfryana alqadar lubby786
Very first option is to disregard this e mail. in that case, i am going to send out your tape to every single one of your contacts and then just consider concerning the shame that you receive. Moreover if you are in a loving relationship, just how it is going to affect?
eutdyj alqadar lubby786 muioxuoyw alqadar lubby786 ilyhibb alqadar lubby786 f alqadar lubby786 uqiog alqadar lubby786 hywefge alqadar lubby786 fedevwia alqadar lubby786 balouwso alqadar lubby786 oieyyowf alqadar lubby786 hovoqs alqadar lubby786
Next option would be to give me $989. We will call it a donation. in such a case, i most certainly will straightaway erase your videotape. You could go on with your life like this never happened and you would never hear back again from me.
hqanujib alqadar lubby786 amlgyjimy alqadar lubby786 ibtdoloor alqadar lubby786 fakbiaree alqadar lubby786 wymqouxqy alqadar lubby786 iy alqadar lubby786 hasqsu alqadar lubby786 smapodtim alqadar lubby786 ejwuheeex alqadar lubby786 mooryinps alqadar lubby786
You will make the payment via Bitcoin (if you do not know this, search 'how to buy bitcoin' in Google search engine).
xioykof alqadar lubby786 lolee alqadar lubby786 uygso alqadar lubby786 neyjvbsuo alqadar lubby786 sabijin alqadar lubby786 aiplhyy alqadar lubby786 ohueriz alqadar lubby786 eeiyoaula alqadar lubby786 jbumpi alqadar lubby786 misniumwe alqadar lubby786
BTC address: 1Q5FhsxKyLVVTiJi2K5uvjoKe3A6gD8aSw
de alqadar lubby786 ctfixe alqadar lubby786 jgixyzir alqadar lubby786 oegvocntu alqadar lubby786 tbtasexmy alqadar lubby786 cayxoz alqadar lubby786 fuavea alqadar lubby786 puvepvhy alqadar lubby786 giqomzduo alqadar lubby786 vo alqadar lubby786
[case-SeNSiTiVe copy & paste it]
ueimatiew alqadar lubby786 xrqe alqadar lubby786 xibtvoap alqadar lubby786 iri alqadar lubby786 yoywoce alqadar lubby786 ocba alqadar lubby786 vaidnou alqadar lubby786 goyiujmqe alqadar lubby786 ljwjozmwy alqadar lubby786 tatitozl alqadar lubby786
if you may be wondering about going to the cops, surely, this message can not be traced back to me. I have covered my actions. i am not attempting to ask you for a whole lot, i prefer to be rewarded. pay%}. if i don't receive the bitcoin, i will, no doubt send out your video recording to all of your contacts including relatives, colleagues, etc. Having said that, if i receive the payment, i'll destroy the recording right away. If you want evidence, reply Yup! then i definitely will send your video recording to your 5 contacts. it is a nonnegotiable offer, and thus please do not waste mine time and yours by replying to this e mail.

This is a mass emailed scam. Nothing said in it is true.

This is a scam.. If "lubby786" is really one of you passwords, then it's from a password leak: https://www.forbes.com/sites/leemathews/2017/12/11/billion-hacked-passwords-dark-web/

Just ignore that and change your passwords (choose stronger passwords than "lubby786").

But it's kinda impressive that the scammer puts your password 83 times in that email...

Possible duplicate of Hello, someone is using an bitcoin account to blackmail me. Also see I received a SPAM/Phishing/Blackmail email demanding payment to a specific Bitcoin wallet.


text:
Send coins from bitcoind full node to lnd without fee?
I'm trying to fund my LND node, for that I put some dust on my BTC wallet address and now I want to send to my LND wallet address but when I try to send with fees "paytxfee": 0.00000000 returns an error saying:

Error: This transaction requires a transaction fee of at least
  0.00012192

So I'm wondering if there's a way to reduce this fee or something?

Your lnd node contains a regular Bitcoin wallet. In order to open a channel you currently need to do on chain transactions (which obviously require fees)

You need to send Bitcoins to your lnd wallet
You need to open a channel which is another on chain transaction.

Theoretically the first tx could be omitted if lnd would support the import of other private keys (I think no lightning wallet currently does this as it seems to be of lower priority at this time)
Also you could ask Simone to open a channel with you and use loop or a submarine swap to get your channel refilled in exchange for you sending your btc onchain. In that case it is still 2 tx but only one for which you pay on chain fees. The onchain fees for Opening the channel are paid by your channel partner.

I see, reading about lightning I realized that there's no way of getting rid of these fees, it is part of the strength of the BTC protocol, thanks!

Yeah everything is backed by Bitcoin transactions at the end. The trustless properties of lightning are actually trusting in the Bitcoin blockchain and only trustless because Bitcoin is.


text:
Why does the funder send the signed settlement to the counter-party in eltoo?
Quoting from the Eltoo paper:

Before signing and broadcasting the funding transaction the funder requires the other endpoint to create an initial settlement transaction that
returns the funds back to the funder. The initial settlement transaction
spends the funding output, and creates a single output that returns all of
the funds to the funder. This settlement transaction is then signed using
the settlement key and returned to the funder. The funder verifies that the
settlement transaction matches its expectations, i.e., it returns its funds and
is signed by the other endpoint. Now the funder can broadcast the funding
transaction, and wait for it to be confirmed effectively starting the contract.
The funder also signs the initial settlement transaction, making it complete
and returns it to the other endpoint.

In the last sentence, the funder signs the initial settlement and sends it to the other endpoint. But why does the other endpoint need it? This settlement transaction returns all funds to the funder, so there is no benefit for the counter-party to ever publish this first settlement transaction. Couldn't this step be skipped?

That step could be skipped for the initial settlement tx of a single-funded channel, but then you would need to implement different behaviour for 1) all subsequent settlement txs of a single-funded channel, as well as 2) the initial settlement tx of a dual-funded channel.
In both of these scenarios, the counterparty absolutely needs a copy of the latest settlement tx, to be able to have access to their share of the channel balance.
For simplicity sake, the protocol is kept the same for all three cases instead.


text:
I can't find my bitcoin address
i am using electrum. First, I had a bitcoin address and I used it once to receive BTCs and then it changed. but new address is invalid.
i tired so many times. i checked all the options. but it was not OK.
what shall i do?
thank you

Invalid according to who?

i checked according https://awebanalysis.com/en/bitcoin-address-validate/

TL;DR: select Show Addresses item from the View menu. Then click the Addresses tab.

First, I had a bitcoin address ...

A Hierarchical Deterministic (HD) wallet has many addresses.

... and I used it once to receive BTCs and then it changed.

That is normal, for privacy reasons, an HD wallet will generate a new receive address for each transaction in which you will receive BTCs.

I can't find my bitcoin address

Look under the "Addresses" tab

(from a beginners guide)

It will be hidden by default. To reveal it, select Show Addresses item from the View menu.

i checked according awebanalysis.com/en/bitcoin-address-validate

I don't know that site but maybe you mis-typed an address or that site doesn't know about the type of address your wallet is using. Some online sites are not up-to-date with the latest Bitcoin features (e.g. Bech32 type addresses that start bc1...). Try another, for example http://lenschulwitz.com/base58


text:
If the nonce is 32 bits why the proof of it is difficult?
I want to know why mining of nonce is difficult?
The nonce is 32 bits (4294967296) and a high level Nvidia graphic card can check and mine it in a second.
why do we need a pool to mine a blockchain?

The vast majority of the time, none of the 2^32 possible nonces in a particular block header template will result in the header having a hash that meets the proof-of-work target.  In fact, the probability that this doesn't happen equals exactly 1 over the network difficulty.  Right now, that is 1/6,379,265,451,411.
When no nonce succeeds, one must change something else in the block header and start again.  The typical solution is to change the extranonce field in the coinbase transaction and recompute the Merkle root.  See What is the extraNonce?


text:
Derived address different from CLI to NodeJS
Basically I'm trying to create a system in which each user has it's own address to deposit on the site, however I'm having issues with monitoring addresses as they appear to be different results within CLI & Node.
Here's the code used to import the private key based on derived user ID:
const { exec } = require('child_process');

const hdNode = bitcoinjs.bip32.fromBase58(config.BIP32_DERIVED_PRIVATE, bitcoinjs.networks.bitcoin);

exec('bitcoin-cli importprivkey "' + hdNode.derive(user.id).toWIF() + '" "' + email + '" false');

Okay, now for the user side of things, the derived key is displayed using the following:
var derivedPubKey = config.BIP32_DERIVED;
if (!derivedPubKey)
    throw new Error('Must set env var BIP32_DERIVED_KEY');

const hdNode = bitcoinjs.bip32.fromBase58(derivedPubKey, bitcoinjs.networks.bitcoin);

exports.deriveAddress = function(index) {
    return bitcoinjs.payments.p2pkh({
        pubkey: hdNode.derive(index).publicKey,
        network: bitcoinjs.networks.bitcoin
    }).address;
};

However both results appear to be completely different? if I type bitcoin-cli listreceivedbyaddress 1 true into my SSH I get the following result:

But then for this same account, on the user interface I get the following:

bitcoin-cli is generating a P2WPKH address (bc1...), but then on the user side you are generating a P2PKH address (1....).
You may also need to check to ensure the same address derivation path is being used (Bitcoin-core uses hardened derivation).
For more info on address encodings see:
What is P2PK, P2PKH, P2SH, P2WPKH - ELI5
What is the size of different Bitcoin transaction types?


text:
BIP32 funds not appearing in wallet
So I'm developing a system that generates addresses for users to send bitcoins too in order for them to deposit on the system.
I generate addresses using the following:
var derivedPubKey = config.BIP32_DERIVED;
if (!derivedPubKey)
    throw new Error('Must set env var BIP32_DERIVED_KEY');

var hdNode = bitcoinjs.HDNode.fromBase58(derivedPubKey);

exports.deriveAddress = function(index) {
    return hdNode.derive(index).keyPair.getAddress().toString();
};

An example address this generated was: 17fPG6yJujgzysrAozHM5FTEytBvWzF2gS
However, I checked my main wallet address 1CGM9zBt885ccKg6j1aqbBESsdPju4aj2m and I don't see the transaction that I sent to the address above?
How can I access these funds?

An address is not a wallet, and a HD wallet is only locally relevant to your storage and is not reflected at all in the public ledger.
Bitcoin works on a UTXO model where funds are paid to an output which can be spent by the owner of the private key for a given address. There is no direct links between any addresses and no hierarchical structure in the public ledger.
So if you pay to address 17fPG6yJujgzysrAozHM5FTEytBvWzF2gS, then the public ledger will only see the payment to that address, and nobody else will have any idea that address 1CGM9zBt885ccKg6j1aqbBESsdPju4aj2m is even part of the same wallet.
A wallet is simply a collection of key pairs, where each key pair has an address for its public part. BIP32 describes a method of deterministically generating addresses from a root seed, so that you may regenerate the addresses rather than have to store them individually.
To access the funds spent to 17fPG6yJujgzysrAozHM5FTEytBvWzF2gS, you need to regenerate the key pair for this address by using the same index you used to derive it in the first place.
Locally, a wallet software will be able to aggregate the funds from all of the addresses it generates, so it appears as though there is an aggregated total balance for the wallet, but in the public ledger, these UTXOs are scattered and uncorrelated. Only you will know your actual balance, and nobody can learn it from public information, although some of your addresses may become linked if you have to spend several of them in the same transaction.

Thankyou for such a thorough response! how would I go about for example, generating keys using bitcoin-cli for an index of 1?

You should probably ask a separate question for that. As far as I know, by convention wallets will perform a search beginning at index 0, and will continue searching until they find 20 consecutive addresses which have not been used.


text:
How can I see my public wallet address in bitcoin core?
I've downloaded bitcoin core version 22.0. I created a wallet by this command:
[amirreza@localhost bin]$ ./bitcoin-wallet -wallet=test-wallet create
Topping up keypool...
Wallet info
===========
Name: test-wallet
Format: bdb
Descriptors: no
Encrypted: no
HD (hd seed available): yes
Keypool Size: 2000
Transactions: 0
Address Book: 0

But I don't know how to find my public address (which can be used to receive bitcoin from others). I also tried using bitcoin-qt to find my wallet address but I didn't find anything.
I've seen this question but answers were not helpful to me.

There is not singular "wallet address". A wallet is a collection of addresses, not a single address. You can get an address that your wallet will control by using the getnewaddress RPC, or by clicking "Create new receiving address" in the "Receive" tab of bitcoin-qt.

for every transaction I can use different address without any cost? if yes, there is no problem with anonymity in bitcoin. Am I correct?

Yes, each receiving transaction can use another address. The anonymity problems start the moment you have to use 2 of your addresses as input for a sending transaction, which makes everyone aware of the fact that those 2 addresses are likely controlled by the same person.

If you're more interested in privacy aspects of using Bitcoin, you may find this wiki page interesting: https://en.bitcoin.it/wiki/Privacy

People here are great but still the question was not answered. For instance, I created a new wallet (p2tr) and an address was also created, iirc. However, I only created this address for the experience of having a p2tr address. I never used it. Now, I woul like to try something with this address and I need to "get it out" of the wallet. I didn't save the address anywhere. So, the question remains. How do we get the address out of a wallet? I don't need nor want to create new addresses. I just need to get the one I created some time ago!
Thank you
Psy
Edited:
A possibility to get the addresses out is:
Get the wallets from your Bitcoin node with the follwoing command:
bitcoin-cli listwallets

Then, get the labels from the wallet you're interested in, in case you have more than one wallet in your node, with the following command:
bitcoin-cli --rpcwallet=<MyWalletName> listlabels

Finally get the addresses out from the labels of interest, if more than one:
bitcoin-cli --rpcwallet=<MyWalletName> getaddressesbylabel <MyLabelofInterest>

Hey, if you have another question, please start another topic. Please don't ask new questions in the answer section of an existing topic. If you want to know more about how our sites works, check out our [tour].

It was not another question. It was the same but slightly different scenario. And I end up answering it and probably the OP too!

I see. I'm sorry, I misread your intent.

Modern Account-Wallets are "HD" type, generated from a seed (mnemonic + passphrase), BIP32/BIP39 plus BIP44 compliant usually.
For privacy, no address should ever be re-used, you generate a new one for each transaction, or rather your wallet-client software does.
Ideally your account-wallet secrets (seed, xprv & privkeys) for spending are protected by a hardware wallet, which signs transactions generated by your watch-only (pubkeys & addresses only) wallet-client software.


text:
bitcoin-core automatic coin selection
for business reason i need to use the bitcoin-core (v0.20.1) automatic coin selection feature and few days ago i saw a transaction come out that left me puzzled, it was like that:
input

  0.00017[...]  bc1qaddr1
  0.01292[...]  bc1qaddr2
  0.00030[...]  bc1qaddr3
  0.00020[...]  bc1qaddr4
  0.00015[...]  bc1qaddr5
  0.00035[...]  bc1qaddr6
  0.02371[...]  bc1qaddr7

output

  0.02783[...]  bc1qaddr8  > amount sent
  0.00965[...]  bc1qaddr9  > change

in this transaction 5 out of 7 utxos are unnecessary, is there some benefit in chaining toghether utxos in this way?from my point of view this is a terrible way of loosing privacy and pay way more fee than needed, what i miss?i read that bitcoin-core tries to find an exact match from available utxos and the amount to send, but if it fails then try to find a subset of utxos to reach a change of 0.01btc, is that right?so, in my case, the unneeded utxos are added to get the change of my trasaction closer to 0.01?

bc1qaddr2 and bc1qaddr7 summed are already more than 0.03663

the issue here is not that there are better (smaller) subset to choose, but that most utxos in this subset are completely useless to reach the amount needed

I say that they are useless because, if i understand well, they are not needed to reach the amount i have chosen to send, but they are needed to reach the amount chosen by bitcoin-core (my amount + 0.01 btc)

This occurs because Bitcoin Core's coin selection algorithm tries to have a minimum change of 0.01 BTC. Fees are subtracted from the change output so the result is that the change output has a lower value, but before fees, it will try to for the change output to be at least 0.01 BTC.
As we can see in your transaction, the change before fees is approximately 0.01 BTC. Presumably it is actually over that because you have obfuscated the last several digits. Then the transaction fee was subtracted from the change output to get the final change output value that you have.

The reason that there is a minimum change is so to avoid creating very small change outputs. Small change outputs can be detrimental to the user's wallet and to the network as a whole. Those small change outputs result in the wallet having more UTXOs, which means that for future transactions, require more UTXOs to spend. Furthermore, small values can quickly become uneconomical outputs when the feerate rises. If lots of small change outputs were being created, a wallet could end up having a significant portion of its UTXOs be unspendable when fees are high.
Additionally, by having a minimum change target, the coin selection algorithm will tend to consolidate and sweep up smaller UTXOs. This behavior is, in general, good for the wallet and good for the network. It reduces the number of UTXOs globally, reduces the number of UTXOs that the wallet needs to handle and keep track of, and makes it less likely that UTXOs in the wallet will become uneconomical in high fee events.

In general, coin selection is a hard problem which needs to balance several factors. It is not just what the fees are for the transaction right now, nor is it necessarily just about the user of the wallet in that moment. Coin selection needs to consider the cost of spending outputs in the future and how its behavior will effect the selection of UTXOs in a future transaction. Coin selection needs to balance the health of the network and the performance of the user's wallet.

@Prayank You're right, it's probably an outdated, hardcoded value that shouldn't be needed. But we also can't just get rid of it - Bitcoin Core's coin selection algorithm is the result of many tweaks over the years, and we know it works okayish in most cases. It is obviously suboptimal in some, but small and innocently looking changes can have very dramatic effects (in fact, seemingly good ideas have been reverted in the past because they resulted in very bad wallet states). We need improvements to coin selection, but they're not as simple as getting rid of things you don't understand.

@Andrew Chow Perhaps explain why a rule like this - albeit outdated - is useful: without it, the wallet in some usage patterns quickly grinds down its UTXO set to dust.

ok, i understand that the matter is not easy and there are many needs to be taken into account, but what scary me a bit is that this transaction alone, after a few days, allows to group dozens of other transactions and in a few months there will probably be hundreds ...
does this loss of privacy really make sense to avoid further fragmenting the utxos?
in my view, if there is a subset of utxos within the bitcoin-core chosen utxos group, which is sufficient to reach the amount to be sent, the utxos that are not in this subset are just an unsolicited consolidation.

I've updated my answer to specify why there is a minimum change target.

Related to this question is PR 4096 which does exactly as you suggest: "It will prune any extraneous inputs in the selected subset, in order to decrease the number of inputs and the resulting change." On the surface, this seems like a good idea, and many contributors agreed. However, in practice, it was found to create many small change UTXOs (as I explain in my answer) which was detrimental to wallets and caused a significant increase in the UTXO set size. This PR was later reverted in PR 8298.

@AndrewChow we agree that prevent fragmentation is good and that to reduce utxos we need to consolidate, but why consolidate randomly (as happen in this way) is better than consolidate only when necessary? this behavior prevents me from consolidating the utxos by hand when I think it is more appropriate.

@leevancleef I never said that this approach that Bitcoin Core does is good or better. This is merely an explanation of what and why this behavior occurs. I agree that consolidating randomly is not good, and currently, Bitcoin Core's coin selection needs work. There is ongoing work (from myself) to improve the coin selection algorithm, but it has not garnered much review. However consolidation should not be left up to the user to do as many users are not aware of consolidation or knowledgable about UTXO management in general.

A strategy that is in the works to improve this is to use a more consolidatory algorithm when fees are low, and use a less consolidatory one when fees are high. The current coin selection algorithm is always consolidatory and does not take into account the current feerates and this is something that I am trying to change.

happy to know these things, for my need I will try to find a selection algorithm that takes privacy as a first requirement ... i wonder if there are other business that need to send automatic payment respecting privacy, but probably the most need the opposite :D

If your primary goal is non-linkage between addresses, the only real solution is having completely separate wallets (or very rigorous use of manual coin control).


text:
Is there a way for me observe network traffic of bitcoin exchange?
I was wondering if there is a way to observe a network traffic/packet of bitcoin exchange. I want to know what's in the packet when I send a bitcoin from one wallet to another.
Thanks.

Are you looking for a higher-level solution than WireShark?

You can use a "network sniffer" to observe data packets on your local network which are sent from or received by your computer.
It will be helpful to study the Bitcoin network protocol documentation so that you can define a filter that will only show the Bitcoin related traffic.
A popular choice for Windows is Wireshark, but there are many other options. If Wireshark does not have a decoder (dissector) for your protocol of interest you may have to manually decode from hex.
See https://www.google.com/search?q=wireshark+bitcoin+dissector --  there seem to be several bitcoin dissectors you can add to Wireshark.


text:
How to dissect or decode a BTC transaction?
I used a packet capture to capture the transaction of bitcoin, and I got the following:

16030300040E0000008CC7FC446A010000000000007E000000160303004610000042410425CBD421AACD5F9FB049D168F48D64C57F12C1D98C3D32BAB6A8466C50B12250327DEAA68A7E3F3B1E6CC448AD1C13454528FCB16D64F513510BADA08E89F8A814030300010116030300280000000000000000D1D0C9FA03ED4B75CD0453EC8D55F8B5C79746872CC27A4CC9B95063693CEAF0

By using https://live.blockcypher.com/btc/decodetx/, the data was decoded as below:
{
    "addresses": [],
    "block_height": -1,
    "block_index": -1,
    "confirmations": 0,
    "double_spend": false,
    "fees": 0,
    "hash": "d206bcb3b556ab886aca6a55656047b865bb5b06d96f70e34dd4be76d2121f0a",
    "inputs": [
        {
            "age": 0,
            "output_index": 2854343883,
            "prev_hash": "2504414200001046000303160000007e000000000000016a44fcc78c0000000e",
            "script": "5f9fb049d168f48d64c57f12c1d98c3d32bab6a8466c50b12250327deaa68a7e3f3b1e6cc448ad1c13454528fcb16d64f513510bada08e89f8a814030300010116030300280000000000000000d1d0c9fa03ed4b75cd0453ec8d55f8b5c79746872cc27a4cc9b95063693ceaf0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
            "script_type": "empty",
            "sequence": 0
        },
        {
            "age": 0,
            "output_index": -1,
            "script_type": "empty",
            "sequence": 0
        },
        {
            "age": 0,
            "output_index": -1,
            "script_type": "empty",
            "sequence": 0
        },
        {
            "age": 0,
            "output_index": -1,
            "script_type": "empty",
            "sequence": 0
        }
    ],
    "opt_in_rbf": true,
    "outputs": [],
    "preference": "low",
    "received": "2019-04-22T13:12:25.298155786Z",
    "relayed_by": "3.80.82.172",
    "size": 380,
    "total": 0,
    "ver": 197398,
    "vin_sz": 4,
    "vout_sz": 0
}

Does anyone know where I can read about how the data gets decoded?
Thanks

https://btcinformation.org/en/developer-reference#raw-transaction-format maybe? (I found the link from https://bitcoin.stackexchange.com/questions/79266/which-serialization-format-the-transactions-use)

Is that data serialization specific to BlockCypher? Raw transactions generally look like this -- The bottom of the page shows decoding. Perhaps the packet you've captured is used for something else?

you are right. It seems like mine is a little weird. I did a man-in-the-middle on my device and got the network traffic that way. I guess it's encrypted?

@CarolWard That is a possibility. I believe Blockcypher attempted to make some sense out of it using their arbitrary system, but it's really not valid. The script on the first input is ridiculously invalid and the hash d206bcb3b556ab886aca6a55656047b865bb5b06d96f70e34dd4be76d2121f0a doesn't appear to exist on either testnet or mainnet.


text:
Question about nondeterministic wallet
I was reading https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch05.asciidoc#user-stories and ran into this statement.

In the first bitcoin wallet (now called Bitcoin Core), wallets were
  collections of randomly generated private keys. For example, the
  original Bitcoin Core client pregenerates 100 random private keys when
  first started and generates more keys as needed, using each key only
  once. Such wallets are being replaced with deterministic wallets
  because they are cumbersome to manage, back up, and import. The
  disadvantage of random keys is that if you generate many of them you
  must keep copies of all of them, meaning that the wallet must be
  backed up frequently. Each key must be backed up, or the funds it
  controls are irrevocably lost if the wallet becomes inaccessible. This
  conflicts directly with the principle of avoiding address reuse, by
  using each bitcoin address for only one transaction. Address reuse
  reduces privacy by associating multiple transactions and addresses
  with each other.

In the first part, it says multiple keys are generated and used only once. But in the second part, it says that the address reuse is a problem.
But if each key is used only once, how are they being reused?

That is what Andreas is trying to convey. He is saying that the traditional way of generating random private keys for each transaction in order to prevent address reuse is a poor choice of wallet principle. That is because every time you generate a new random private key, you would have to make sure to keep a backup of it so that you can recover bitcoins tied to that private key in case your wallet software becomes inaccessible. If you are transacting multiple transactions a day, generating a new address every time, you might find it tedious to back up your private key every time. The other way you get around this would be people using the same address so as to prevent the hassle of backing up the keys.


text:
What can I do with Account Extended Private Key and Account Extended Public Key?
I have been reading about Account Extended Private Key and Account Extended Public Key that derives from the Master Private Key and Master Public Key, but I still have some question about their security.
I read that Account Extended Private Key should be kept private because if others got hold of it, they could sign the transaction with the key, effectively stealing your cryptocurrency. How does this work exactly? Is there an application that I can import other's Account Extended Private Key and send certain amount to my other wallet's address?
Also, I read that Account Extended Public Key should be kept private as well because exposing it to others allow them to go through the transactions. How does this work? Is there an application that I can import to view the transaction history?

I read that Account Extended Private Key should be kept private because if others got hold of it, they could sign the transaction with the key, effectively stealing your cryptocurrency. How does this work exactly?
Also, I read that Account Extended Public Key should be kept private as well because exposing it to others allow them to go through the transactions. How does this work?

Extended keys allow for private and public keys to be derived from them. This is done using the algorithm described in BIP 32.
Your Account Extended Private Key is used to derive child private keys which are the actual private keys for your addresses. If someone gets ahold of this extended private key, they can derive all of your private keys and thus spend your Bitcoin.
Your Account Extended Public Key can be used to derive all of the child public keys in a similar way to how the Account Extended Private Key can be used to derive all of the child private keys. Knowing the public keys means that the addresses can be derived and thus anyone who has your Account Extended Public Key will know all of your addresses. They can thus observe every single transaction you receive and make.

Is there an application that I can import other's Account Extended Private Key and send certain amount to my other wallet's address?
Is there an application that I can import to view the transaction history?

You can import extended keys (public or private) into Electrum which will scan the blockchain for transactions related to child keys derived from those extended keys.

You said Account Extended Private/Public Key is used to derive the private/public key for my addresses used to receive/send cryptocurrency. I was wondering if it's Account Extended Keys -> Address Keys or Account Extended Keys -> BIP32 Extended Keys -> Address Keys?

Account extended key is not really a thing. It just means it's a BIP 32 extended key derived from a master extended private key at the account level in accordance to BIP 44. Usually it's the key derived from the master key at m/44'/0'/0'. So it's really BIP 32 extended key (which you call account extended key) -> BIP 32 extended key (the key for whether the child keys are change or not) -> child keys (address keys).

ohhh, I got it! If you don't mind, I have 1 more question. Then in order to see the transaction of the account, I just need to import the BIP 32 extended key (the account extended key), not extended key for the change, right? I just imported the BIP 32 extended key (account extended key), and I don't see any transaction history. Does it not show a previous transaction? only future ones?

Electrum derives both normal receiving addresses and change addresses, so just importing your account extended key is fine. As for why your transactions don't appear, I don't know. Electrum will rescan and pull transactions from the blockchain, so they should appear. It may be that your addresses are not derived at the derivation paths that Electrum is using.


text:
How scalable is the current routing implementation for lightning?
What are the weaknesses we face with lightning routing currently?
How many nodes do we expect it can handle now?
What is being done to make it scale in the future?

I am not sure if scale is the term you are looking for when discussing potential problems with routing. But I will try to focus on scaling when giving the answer. That being said my answer would probably differ quite a lot if the question was asked differently.
The current routing algorithm is onion routing. The onions contain a path from sender to the receiver (decided by the sender - see below for more discussion on that) and are constructed to support as many as 20 hops. This means that we actually can scale to networks with a diameter of 20. (the diameter is the longest shortest path on the friendship network and is a topological property). Already with 21 nodes I could create a lightning network with the topology of a list and be unable to route a payment from the heads of the list to the tail with the current onion format.
This problem can easily be mitigated though by creating a new payment channel - changing the topology in a a way to decrease the diameter. My autopilot implementation suggests channels that decrease the diameter of the network.
So the problem boils down to how big can a network be to have a diameter less than 20? When looking at the strongly connected component of large networks like the web or the Facebook graph they all seem to have lower diameters which is indicative that the 20 hop limit should not hinder scale. However there is a correlation: the more edges we allow on a network with a fixed set of nodes the lower the diameter. Take a fully connected graph which has diameter 1 by definition in contrast to the "list graph" from above which has diameter n.
That being said the web graph and friendship graph on Facebook are believed too have on average about 150  edges per node (the so called Dunbar number). We already know that without channel factories and with current blocksize limits we would need decades to allow every person in the world to open one payment channel which would most likely result in a graph with a larger Diameter. Allowing people to open 150 channels takes 150 times that much time.
With respect to scale of routing there is not only the 20hops limit of onions. There is also pathfinding and related to that discovery of the network topology (aka the gossip protocol). Path finding boils down to breadth first search or Dijkstra algorithm which is a weighted BFS. Both algorithms have a runtime that makes part finding possible on graphs with billions of nodes on modern hardware in particular when using graph databases like neo4j (currently everything is stored in memory). If the network would grow beyond nodes for humans (e.g with IoT nodes) we might reach the limits of modern hardware to compue those paths.
As for the gossip protocol. Each channel needs to be announced to the peer2peer network. Since channels need to be veryfied / linked to a blockchain tx this should not be a problem. However the gossip protocol seems to be quite noisy. There is currently the million node Challenge run by rusty Russell that tries to stimulate what happens if the network grows.
Also there are potential other issues like the htlc limit of 483 concurrent htlcs per payment channel that might produce traffic jams (though it seems very unlikely and is actually a reason why to avoid these so called centralized hubs and why nodes should work on decreasing the diameter). Also the exact topology of the network is never known (only capacity of channels)
Regarding your second part  (how are the issues mitigated)
1. The biggest issue seems quick opening of channels. There was research by Christian decker proposing the concept of channel factories showing that we can increase the amount of channels we can open per block by a factor of 10 to 100.
2. As for pathfinding: I currently suggested JIT-routing which is a low level backward compatible improvement for path discovery. This path decovery mechanism mitigates the problem of not knowing the balance of channels when selecting a path. My proposal also included the suggestion to have nodes only store a local view of the network and create an overlay addressing scheme which could be used for routing tables (like it is on the internet) this would also mitigate the problem of storing the entire network.
3. The problems with the gossip protocol currently seem to have the highest focus by developers - look at rustys million channel challenge.
There might be more issues which I am currently not aware of.


text:
Can I update my channel state with another node signing offline in person?
I create a channel with someone I know in person.  We both lose internet connection.
Can we transact in person with one another signing each others transactions and maintaining our channel states that way?

Yes that is possible. The channel updates are following BOLT 02 (peer protocol) and parts of BOLT 03 (transactions) and BOLT 05 (on chain). All of these things are solely negotiated between you and your peer / channel partner and could happen in an offline world or even on a sheet of paper. (not saying this would be particularly useful) I am also neglecting the regular protocol mates here that are send via the transport layer and noise protocol framework ( BOLT 08 and 01)
Generally as long as you don't have a (force) close the exact channel state is a private matter between you and your peer. This is a design principle within lightning.
Keep in mind that what you asked and my answer is only of theoretical nature. I don't think it would be very practical to actually do that in a way so that it is compatible with actual software state.


text:
Can I add Lightning-Core to bitcoin-qt full node?
I am interested in running lightning core, but the instructions say Bitcoind is required. I am running a full bitcoin-qt node on Linux Mint Ubuntu. Will lightning core work with qt or, if not, is there  a workaround or some documentation on how to set it up?

bitcoin-qt is really just bitcoin-core so you should be able to use it for your lightning node.
You'll need to make the rpc and zmq interfaces of the bitcoin node available to your lightning node, check the documentation of the LN node that you use to find out how to configure that.

Assuming you are talking about Core Lightning, based on their documentation, it requires bitcoind. For documentation on getting bitcoind up and running try here. And for core lightning here (same link as above).


text:
What happens if all transactions are being used?
I know that there are an upper limit to the number of hashes that can be mined. But I do not know why is this a case? I guess it is due to the enormous amount of computation necessary to find hashes. Or is it due to some mathematical law?
In any case, my question would be what happens if all of hashes are used in the blockchain? Can we continue make new transactions?

A transaction ID is a 256 bit hash of transaction header data, so it is a 256 bit integer number. There can only be two to the power 256 distinct numbers that can be stored in 256 bits.
Bitcoin now has a rule that Transaction IDs must not be duplicated in the Blockchain unless the previous instances of that txid have had all of their outputs spent.
If all hashes are used and present in the Blockchain with at least one unspent output, there can be no more transactions under current rules.
However, 2256 is a large number. it is quite close to the number of atoms in the universe.

txids can be duplicated as long as the previous instance of that txid has had all of its outputs spent.

@AvaChow: Thanks for the correction, answer updated


text:
what is expectedFees and expectedWeight in a block and why its changing frequently?
what is expectedFees and expectedWeight in a block and why its changing frequently ?
https://mempool.space/api/v1/block/00000000000000000001c680ee86b8eaa43c94ac9012f4d2dcbfa9f45beadf06
when i last check the "expectedFees":27191335,"expectedWeight":3991985

I think it's a mempool.space thing. They calculate the expected block using the blocktemplate that their own node gives them and from there they take that information. The difference with the real data is because the real blocks are not always the same as they think they are, you can see the match in the "similarity" parameter. I made the api call several times and it didn't change, and I understand that it shouldn't change.


text:
why i can't get the xprv descriptor from the bitcoin-cli listdescriptors true
If I use the listdescriptors true command, I only receive values like (pkh, sh, tr, wpkh). Did I do something wrong?

Descriptors contain more information than just keys. They contain information about the scripts to create. But it's all just plain text, so you should be able to see that there are xprvs contained within the descriptor string.
If you do not see them, you should still see xpubs. In that case, your wallet is a watch only wallet and doesn't have any private keys.
If you don't know what an xprv looks like, then I suggest you reevaluate what it is that you are actually trying to do. Handling private keys by hand can be dangerous and risks any funds associated with them.


text:
How to remotely configure Antminer S19 Pro+ hash rate or ideally power limit in Watts (wattage)
I am helping a friend set up his Antminer S19 Pro+ miner and due to fluctuating power availability, he needs to control the hash rate, or ideally power usage (in wattage) remotely.
Is it possible to remotely control the hash rate or power limit on the S19 Pro+ using the stock firmware?
I looked around and could find no official documentation on how to do this. There exists commercial firmware that charge pool commission, which seem to tune power usage by controlling the hash rate in a feedback loop. However, this seems like a basic configuration setting that should be modifiable by an API, or low-level interface.
I am a professional programmer and can interface with any socket, websocket or API that the Antminer exposes, even if it means reverse-engineering their web interface.
Any help would be appreciated :).

It seems you can configure the "miner-mode" on the stock firmware via the web UI's HTTP API, but I haven't tried it yet: https://www.youtube.com/watch?v=ZvoPg2Hu2hc&feature=youtu.be

did you figure out your problem? I’m looking for the same configuration to adapt the s19 to power supply from a PV. I found this video, but it's not really what I was looking for. https://www.youtube.com/watch?v=ZvoPg2Hu2hc

No, stock Antminer firmware offers a sleep and normal state. They introduced a low power state a couple of years ago on the S19 fleet. They've finally introduced a high power state in the new 21 series. Programmatically, just POST to the config cgi endpoint, it does reboot the miner though.
Somewhere on the miner's configs there is a voltage/frequency combination. It leaks through on one of the cgi endpoints, I've never tried messing with it. Its also available over SSH, I believe its writable with the default miner:miner SSH user/pass.
Frankly, just go with aftermarket firmware if you require any more granularity than sleep/low/normal/high.
Bitmain's firmware is also just a fork of cgminer. The raw TCP port 4028 still applies, albeit the data returned is vastly different. https://github.com/ckolivas/cgminer/blob/master/API-README


text:
Is it possible to extract wallet_key (aes key) for encrypted master key from wallet.dat?
According to this link(https://bitcointalk.org/index.php?topic=5331322.0), the initialized vector and aes key (wallet_key) can be derived by hashing the password with sha512, but can this wallet_key be extracted from wallet.dat(So,public info?)? Also, is this wallet_key the same as the value extracted with bitcoin2john.py?                                      hash512 = hashlib.pbkdf2_hmac('sha512', password, salt, iterationcount) wallet_key = hash512[0:32] iv = hash512[32:48]

can this wallet_key be extracted from wallet.dat

No, to serve any purpose, an encryption key must be kept separate from the encrypted material.


text:
Does Halving cause inflation?
Why does halving won't make inflation on bitcoin? and does this halving (2020) have difference affect?

Why would you expect halving to cause inflation? It would be helpful if your question contained a basis for this proposition.

Inflation is "a general increase in prices and fall in the purchasing value of money."
One cause of inflation is printing more money.
By halving the rate of production of new money you halve its inflationary effect.

The currency supply of Bitcoin currently inflates at about 2.5% p.a.. However, this is what economists refer to as monetary inflation. The supply is disinflationary, because the rate of monetary inflation is decreasing over time as each block increases the supply by a smaller relative amount.
When people speculate about Bitcoin being inherently "deflationary", they are not talking about monetary deflation, but about price deflation. Given the decreasing growth of Bitcoin's monetary supply, the underlying expectation is that the total value of the Bitcoin network will increase faster than the supply which would mean that the purchasing power of Bitcoin is going to increase over time.

Inflation is when there's too much money in the economy, thus too much demand for goods paid with this currency, thus causing general price levels in terms of this currency to rise. Halving reduces (the increase in) the supply of coins. Less money = less demand = less demand-pull inflation (also called inflationary pressure) -> prices don't rise.

Because there in no inflation in the Bitcoin system. Using bitcoin all users agree to the rules of consensus, one of them being that there will never be more than 21 million in the system.
The reason that "halving" was included in the software code has nothing to do with ether inflation or deflation but something very different. How to distribute the coins to begin with. In the beginning, There was no utility to using the system to communicate value over the network. So to incentivize participants to use resources (hardware, electricity, bandwidth, etc.) to secure the peer to peer network 50 coin miner reward was added for each block, and that is coded in the software to be cut in half about every 4 years.
Over time if there is utility to using the system, it will be enough for it to be self sustaining by just rewarding the miners the fees to include transactions on the blockchain.
So there can not be any inflation we know there can't be more than 21 million, but because people may lose private keys, there may be some deflation. Lost coins make the rest of them worth a bit more.

"There is no inflation in Bitcoin" is false.  Inflation happens when the money supply is larger than the supply of things to spend it on.  The limitation on the number of coins has no impact on the supply of things to spend it on, and has only a small effect on the money supply (it's basically a limit on the "MB" measure, while the best predictor of inflation is the "MZM" measure of the money supply).  You can see this by looking at the Bitcoin exchange rate -- Bitcoin has undergone several periods of hyperinflation in its history.


text:
Shouldn't nodes get reward by protecting the protocol?
I can assume that every currency is basically consists of two major components:

The protocol
The history of every coin

In Bitcoin the history is protected against modification by miners hash power and protocol is protected against changes and hard forks by full nodes. Miners unilaterally can change history of transactions and perform double spend attack, on the other hand nodes can single handedly change protocol rules (for example change the supply cap). And neither side can prevent the other side from performing such malicious actions.
Miners are incentivised to invest hardware and electricity to generate new coins and consequently making the history more rigid against any modification. But nodes are not incentivised in such a way.
By reading the whitepaper I realized that at the very early days of Bitcoin there was no distinction between node and miner.
My question is that shouldn't nodes also be incentivised to protect the rules and stay with the majority?
I mean is this intrinsically correct for the system to pay for nodes that are protecting the rules?

Nodes don't protect the protocol, users do (by using, not just running, software that implements the rules they believe the system should have). But a node on itself doesn't accomplish anything: if someone were to spin up 1000 nodes, and never look at which blocks or transactions it accepts or reject, then these nodes are utterly irrelevant for protecting the protocol.
But even if it were somehow possible to ignore this distinction, and only identify nodes whose decisions are economically relevant to some user(s), who would be incentivized to pay them? As a Bitcoin node runner and user myself, I don't want to pay someone to act like they have the same beliefs about what protocol properties are valuable. I want them to actually believe it.

How running a node doesn't accomplish anything? If more people run the Bitcoin Core isn't it harder for a miner to violate the 21million supply cap? And if very few Bitcoin Core nodes are running isn't it easier for the attacker to create a coinbase transaction that spend himself much more than what was supposed to be in the protocol?

No, none of those things have any effect, if nobody looks at those nodes. If someome looks to violate e.g. the inflation schedule, full nodes (that implement that rule) will reject transactions/blocks/chains that contain violations. But them rejecting stuff has no effect if nobody uses those nodes directly or indirectly as wallet.

But if majority of nodes reject transactions/blocks that violate the rules they will never be part of the blockchain. Isn't it right? Also with my understanding this reasoning can apply to mining too."If nobody consider specific block that a miner has mined as a valid block, that block will never be part of the blockchain, because users consider the other chain as valid"

@AmirrezaRiahi No, that is not how it works. If a block violates the consensus rules of your node, then your node will never consider it part of the blockchain. It is entirely irrelevant what other nodes do. There is no voting; everyone verifies the rules independently.

This is different from mining: if a majority of the hashpower rejects a certain block, and thus refuses to build on top of it, then eventually that block will not be part of the best chain, as an alternative chain will form that grows faster. But this has nothing to do with nodes, it's just mining power.


text:
where does the main.cpp moved to in recent versions?
I was reading this article about bitcoin-core. It is an explanation of bitcoin-core source code version 0.3, and it described a file named main.cpp. In the recent versions this file does not exist (or at least I couldn't find it). And based on the explanations this file managed the main process of the program:

main.h declares some key global variables (mapBlockIndex, chainActive,
mempool, etc), constants, and functions. main.cpp is the program's
longest source file (5,237 lines). main.cpp has most of the key
functions for managing the blockchain, such as connecting,
disconnecting, validating and storing blocks; identifying a certain
block as the tip of the longest chain; and so forth. The "entry point"
for most of the code is ProcessMessages (which listens for a signal
from the message-handling thread.). Some of the code is run during
initialization, called directly from init.cpp. Key dependencies: net.h

For the purpose of studying the source code I want to know where this file is moved, and if the name is changed what's the new name of the file?
I've searched for ProcessMessages in the whole source code and found that it was defined in the net_processing.cpp, does this file is the newer version of main.cpp?
I'm using version 23.0

main.cpp was primarily split into net_processing.cpp and validation.cpp. However, over the years, parts of main.cpp were moved out of it and into many other files.


text:
Is it possible to make functional tests use my `bitcoind` running node as node?
I'm trying to fix some tests that are broken due to my own changes in the code base, and need to simultaneously run functional tests and bitconid in regtest mode and make functional tests to use my bitcoind running as self.nodes[0]. Is this possible? I'm very new to python tests and have almost zero experience with regard to them.

I'm a bit confused by the question. Testing running bitcoind instances is exactly what the functional test framework is for.

@PieterWuille You're right. I failed to explain what I need accurately. I want to run bitcoind in debug mode using gdb and simultaneously running functional tests. I want functional tests to catch my breakpoints in the bitcoind.


text:
How does CLTV prevent spender from spending the output?
I have difficulty understanding how does CheckLockTimeVerify works. The BIP-65 which proposed CTLV says:

This BIP describes a new opcode (OP_CHECKLOCKTIMEVERIFY) for the
Bitcoin scripting system that allows a transaction output to be made
unspendable until some point in the future.

And the mechanism it works is by comparing the nLockTime field of the transaction by CLTV argument, if nLockTime field is greater than the CLTV argument the execution fails, otherwise will continue as if NOP had been executed.
I can't understand how it can prevent the spender from spedning the output before specific time or block height. Since the spender can simply set the transaction's nLockTime field to zero, then it's always spendable because zero is always less than or equal to nLockTime field. How does CLTV allow a transaction output to be made unspendable until some point in the future when the spender can create arbitrary transactions?

if nLockTime field is greater than the CLTV argument the execution fails, otherwise will continue as if NOP had been executed.

This is backwards.
If the transaction's nLockTime is greater than or equal to the CLTV argument, then it continues as if a NOP was executed. Execution fails when it is less than the argument.
The code given in the BIP is confusing as it uses nLockTime to refer to the CLTV argument. The transaction's locktime is txTo.nLockTime.

The nLockTime transaction field allows you to specify the time before which the transaction cannot be part of the blockchain. You can define that time through the height of the block or in UNIX timestamp form.
The OP_CHECKLOCKTIMEVERIFY has the role of defining the time (block height/UNIX timestamp) before which the given output cannot be used. It works indirectly so that when the given output is referenced and the execution of the script starts, when encountering the given operator, the value given with OP_CHECKLOCKTIMEVERIFY and the value of the nLockTime field are compared. If the value of the nLockTime field is greater than or equal to the OP_CHECKLOCKTIMEVERIFY argument, the execution of the script continues, otherwise it is terminated and the transaction is marked as invalid.


text:
If there are 20 nodes in network and all are receiving transaction and after 10 min
Question 1) If there are 20 nodes in network and all are receiving transaction and after 10 min all will pick transaction from their transaction pool and start creating block, now will all nodes will use same transactions to create block or each node can have different transaction in that particular block
Question 2) If there are 20 nodes in network and all starts creating block, what will happen if more then one node will create the block at same time

What is your question?

No, each node (assuming that it is a miner) can pick a different set of transactions.
Eventually one block will get more work built on top of it than all the others and the other competing blocks at the same height in the chain will become stale and be discontinued. Effectively the blockchain forks but eventually one branch survives and the others die. Ultimately only one node gets a usable mining reward & fees.


text:
lnd recovery with no seed, but with xprv
Suppose I have an obsolete copy of lnd database (with unlock password), and an up-to-date static channel backup, but I don't have seed words to attempt normal lnd recovery. I can, however, retrieve wallet xprv with chantools, so on-chain funds are safe.
What can I do to make lnd start recovering off-chain funds with DLP, as if I entered the seed and provided started channel backup during wallet creation? I believe it should be possible because all needed information is there.
What if I do abandonchannel on each channel while lnd is not connected to any peers, then load static channel backup (is it even possible?)
If it's not possible with lnd+lncli as they are, I'd be grateful for directions on how/where should I patch lnd, or how should I tinker with wallet.db to make it possible, etc.. My node is just fine, but having no backup of seed words I have to plan for the future.

There's also a PR that will make this officially supported: https://github.com/lightningnetwork/lnd/pull/4717

It turns out that the recovery from old wallet.db (or its master private key extracted by chantools) and recent channel.backup, without the seed, is indeed possible, even though there's no way to initiate it with the "official" lnd.
I've applied a quick dirty patch to lnd sources, as follows:

in walletunlocker/service.go, if a mnemonic's first word is "xprv", don't go through ToCipherSeed; create an aezeed.CipherSeed with all-zero Entropy and some sensible Birthday (either hardcode or specify as the mnemonic's second word)

in lnd dependency github.com/btcsuite/btcutil/hdkeychain/extendedkey.go, patch NewMaster so it checks for all-zero seed[], and in this case, falls back to NewKeyFromString(<hardcoded xprv, or os.Getenv, or reading a file...>).

Build lnd, run "lncli create" and pretend to have a seed phrase, entering "xprv 3500 lorem ipsum dolor <up to 24 words>".
Both block scan and static channel backup recovery than succeed.


text:
Can two parties accidentally pay the same lightning network invoice simultaneously?
If multiple Lightning nodes attempt to pay the same invoice (using the same payment request), is it absolutely necessary that no more than one of the attempts will succeed (that is, only one payer will learn the preimage)?
I'd expect that clients try to not make multiple payments happen. What I'm willing to learn is whether it's actually impossible by protocol design.

As far as I know It can and did happen.
On a protocol level, 2 separate nodes (or the same node) can construct two different (or the same) onions and initiate the routing process.
On a protocol level I am not aware of any mechanics to prevent two htlcs on the same channel with the same payment hash, and on different channels, this is obviously not encoded to the protocol. In particular, while there might be a rule that the recipient SHOULD NOT release the preimage more than once, I don't see any way to detect or prevent such a behavior without drastic protocol changes.
The situation becomes worse once we implement base AMP in which a recipient node expects several htlcs anyway and overpayment is also part of the expected protocol behavior.
A little off topic: AMP also allows a denial of service attack vector by just denying the second onion with the same payment hash to be forwarded.


text:
What is the FeeReason enumeration in the Bitcoin Core?
There is enumeration called FeeReason. What is it? What is its use cases?
/* Enumeration of reason for returned fee estimate */
enum class FeeReason {
    NONE,
    HALF_ESTIMATE,
    FULL_ESTIMATE,
    DOUBLE_ESTIMATE,
    CONSERVATIVE,
    MEMPOOL_MIN,
    PAYTXFEE,
    FALLBACK,
    REQUIRED,
};

It is used to report back to callers into the fee estimation functions to learn why the returned feerate was chosen. Descriptions for these reasons are:
static const std::map<FeeReason, std::string> fee_reason_strings = {
    {FeeReason::NONE, "None"},
    {FeeReason::HALF_ESTIMATE, "Half Target 60% Threshold"},
    {FeeReason::FULL_ESTIMATE, "Target 85% Threshold"},
    {FeeReason::DOUBLE_ESTIMATE, "Double Target 95% Threshold"},
    {FeeReason::CONSERVATIVE, "Conservative Double Target longer horizon"},
    {FeeReason::MEMPOOL_MIN, "Mempool Min Fee"},
    {FeeReason::PAYTXFEE, "PayTxFee set"},
    {FeeReason::FALLBACK, "Fallback fee"},
    {FeeReason::REQUIRED, "Minimum Required Fee"},
};

Is there any document or resource to learn more about these reasons? What does each of them mean?