text:
Where can I find the core binaries for v.0.1.5 to v.0.3.21?
I have been looking for core binaries (i.e. win32-setup.exe & win32.zip & macosx.zip) for earlier clients. Any advice on where they are hosted? They have all been removed from SourceForge.

https://satoshi.nakamotoinstitute.org/code/ (Only v.0.1.0 to v.0.1.3)
https://bitcoin.org/en/version-history (Only v.0.3.21 to v.0.20.0)
https://github.com/bitcoin/bitcoin/releases (Only tar.gz, also not accurate)

Any advice appreciated!

Cheers :-) Saw in the Dev Mailing List, very cool!


text:
Which major/noteworthy BIPs, Soft-Forks and Hard Forks have there been since the Summer of 2017 (after SegWit/Bitcoin Cash)?
There are many lists of major forks however most of them end after SegWit. The full list of BIPs is extensive. Which noteworthy BIPs, Soft Forks and Hard Forks have there been since SegWit and Bitcoin Cash (i.e. After Summer of 2017)?

Bitmex List
Book List
Full List of BIPS

"have there been" -> could you clarify whether you mean BIPs that have been activated, proposed, or iterated upon?

Also, are you specifically referring to consensus changing BIPs (ones that involve a softfork), or any type of BIP? Most are about interactions between wallets and network protocols; the ones proposing consensus changes to Bitcoin are a minority.

source: Stack Exchange

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

sort: votes


text:
Why is BIP133 listed as 'Draft' when it has been implemented for years?
BIP133 is listed as 'Draft' but it has been implemented since v.0.13.0
https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki
Is there anything preventing it from being labelled as 'Final'?

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


text:
I found evidence Hal Finney was working on Bitcoin (05 Jan 09) before v.0.1 was released (09 Jan 09). Is there any evidence he was involved earlier?
I found evidence Hal Finney was working on Bitcoin (05 Jan 2009) before v.0.1 was released (09 Jan 2009). Is there any evidence he was involved earlier?
https://web.archive.org/web/20090105145118/http://sourceforge.net/project/memberlist.php?group_id=244765

He must have generated his first address before 3 Jan since he received coins on that date: https://www.washingtonpost.com/news/the-switch/wp/2014/01/03/hal-finney-received-the-first-bitcoin-transaction-heres-how-he-describes-it/

@MCCCS: Please post an answer when you are answering the question. :)

Thats very cool. Cheers MCCCS :-D


text:
Cannot cross-compile for Windows from Ubuntu 18.04
I have been at this for ages now and I am unable to cross-compile Bitcoin-Core 0.19.1 on my Ubuntu 18.04 machine (not a VM). I follow these exact instructions:
sudo apt install build-essential libtool autotools-dev automake pkg-config bsdmainutils curl git g++-mingw-w64-x86-64
sudo update-alternatives --config x86_64-w64-mingw32-g++ #successfully changes to posix here
git clone https://github.com/bitcoin/bitcoin.git
cd bitcoin
cd depends
make HOST=x86_64-w64-mingw32
cd ..
./autogen.sh # not required when building from tarball
CONFIG_SITE=$PWD/depends/x86_64-w64-mingw32/share/config.site ./configure --prefix=/
make

everything goes well till the autogen step. The configuration script executes normally but I always get the same output no matter what I do...
Build Options:
  with endomorphism   = no
  with ecmult precomp = yes
  with jni            = no
  with benchmarks     = no
  with coverage       = no
  module ecdh         = no
  module recovery     = yes

  asm                 = x86_64
  bignum              = no
  field               = 64bit
  scalar              = 64bit

  CC                  = gcc
  CFLAGS              = -g -O2 -W -std=c89 -pedantic -Wall -Wextra -Wcast-align -Wnested-externs -Wshadow -Wstrict-prototypes -Wno-unused-function -Wno-long-long -Wno-overlength-strings -fvisibility=hidden -O3
  CPPFLAGS            =
  LDFLAGS             =

Fixing libtool for -rpath problems.

Options used to compile and link:
  with wallet   = yes
  with gui / qt = yes
    with bip70  = no
    with qr     = yes
  with zmq      = yes
  with test     = yes
    with prop   = no
    with fuzz   = no
  with bench    = yes
  with upnp     = yes
  use asm       = yes
  sanitizers    =
  debug enabled = no
  gprof enabled = no
  werror        = no

  target os     = linux
  build os      =

  CC            = /usr/bin/ccache gcc
  CFLAGS        = -g -O2
  CPPFLAGS      =   -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2  -DHAVE_BUILD_INFO -D__STDC_FORMAT_MACROS
  CXX           = /usr/bin/ccache g++ -std=c++14
  CXXFLAGS      =   -fstack-reuse=none -Wstack-protector -fstack-protector-all  -Wall -Wextra -Wformat -Wvla -Wswitch -Wformat-security -Wredundant-decls  -Wno-unused-parameter -Wno-implicit-fallthrough   -g -O2
  LDFLAGS       = -pthread  -Wl,-z,relro -Wl,-z,now -pie
  ARFLAGS       = cr

I have tried to uninstall and install the Ubuntu. Also tried to compile on a clean repository several times but the output always shows that the target OS is Linux. I run the make command after this but never get the exe. I am stuck and don't know what else to try. Any help would be appreciated.

I don't see anything wrong with the output you're seeing. It seems you're just not doing the "make" command at the end. After this output, just run make.

@PieterWuille Sorry if I wasn't clear enough.
I want to cross compile for Windows on my Ubuntu to get an .exe file to run on Windows.

Can you post the full output, for exactly what you typed in the shell and the produced output?

First I run the commands as mentioned at the top of my question till ./autogen.sh step then:
$ mkdir build $ cd build $ CONFIG_SITE=$PWD/depends/x86_64-w64-mingw32/share/config.site sudo ./../configure --prefix=/


text:
After last bitcoin is mined, can miner(s) with nefarious reasons kill bitcoin by holding fees thereby deflating Bitcoin eventually to zero?
Just hypothetically speaking, once there is no more rewards and we transition entirely into transaction fee regime, if a miner (or group of miners) with unlimited supply of electricity, computing resources and sole intention to kill bitcoin decides to mine and hold up all the fees they collect and never again releasing those fees back into circulation (they have other means to pay their expenses and their primary goal is to kill bitcoin), wouldn't eventually they end up with all the bitcoin ?

In order to do that, the very last transaction would need a 100% transaction fee. Why would anyone do that transaction?

True, but by then, for all practical purposes the goal of destroying Bitcoin would have been accomplished. So to clarify my question, isn't this a weakness of a post reward regime that could in theory kill Bitcoin?

This is some variation of game theory. It only works if a majority of miners agree to burn power with zero income, and destructively destroy any blocks that contain income.

I am asking because governments could in theory exploit this if they really wanted to destroy bitcoin. A government is capable of burning power with zero income to eventually accomplish this.

If you have unlimited energy and computing resources, there are a lot of easier ways to kill Bitcoin, without waiting 120 years for the last coin to be mined.

This would be fantastic for everyone but the attacker.
First, everyone who held bitcoin would be rich. As bitcoin became more and more scarce, the price would go up. The attacker would have to offer full value for every bitcoin it managed to acquire, so it's no different from an attack where you buy all the bitcoins.
However, as the distribution becomes more and more skewed, the value of bitcoin will eventually crash because people couldn't get it.
Once that happens, everyone who likes to use bitcoin for payments or as a store of value, now all fantastically rich, would simply migrate to a different system. The attacker would have bought every bitcoin all the way up the rise in price.
Of course, this would be so obvious to all involved (at least eventually) that it would never get this far. Whether the result would be changing the mining algorithm, restoring the block reward, or something else, I can't predict. But likely the mere threat of changing the mining algorithm would be sufficient to end this.
A related, but more realistic, attack involves someone with 51% of the mining power taking all the transaction fees for themselves by refusing to mine on top of blocks mined by anyone else. As a monopolist, they could increase the transaction fees to as much as the "market" would bear. This faces the same problem -- everyone else can threaten to change the mining algorithm. If decentralization is the value proposition, such a chain would have no value proposition -- so why would anyone pay high fees to use it?


text:
Procedure to recover BTC stuck in 2/2 Multisig
I opened a 2M Sat Channel and my peer should send me back 1M Sats Onchain, as I have pushed half.
Now unfortunately, I’ve sent my peer the address of the 2/2 Multisig of the funding TX and not the Onchain one :-(
I thought that I would get those Sats back, when I close the channel, but now unfortunately they are stuck.
I’ve been told that it should be theoretically possible to get those Sats back, but as a noob I don’t know how to proceed.
Any hints would be very much appreciated.
Many thanks in advance for any reply!

Ok, I have reactivated the efforts on this one, as I'm now retired and have plenty of time...
Well from an economical point of view it's an absolute "no go" and makes no sense at all, as only 1M sats are stuck and I better would go cleaning toilets to make the money back :-)
But on the other hand I think this would be quite nice learning experience an keep the brain of an old fart going :-)
What would be the first step of the recovery procedure?
Would getting the key pairs (private key and address) that have signed the 2/2 Multisig a good start?


text:
More Input-Values than necessary. How and why is this possible? No it is not the fees!
The TXID I am talking about: 21179a8560a0a0906f0c3396af338f74528130d46b65b7f0c79c378d343b3177
blockchain.com link: https://www.blockchain.com/btc/tx/21179a8560a0a0906f0c3396af338f74528130d46b65b7f0c79c378d343b3177
3JZq4atUahhuA9rLhXLMhhTo133J9rF97j is a known Exchange-Address.
Within above listed transaction there are multiple output-transactions which this address has received referenced as input-transaction to pay 1Kr6QSydW9bFQG1mXiPNNu6WpJGmUa9i1g.
In the above transaction, the source address 3JZq4a.. issues 7 previously received transactions to pay the target address 1Kr6QSy... with 2000 BTC, the rest goes back to its Change address.
My question now is why 7 transactions are "consumed" for this, when it would have worked with a fraction of the transactions.
For example the 7793.90573 BTC transaction.
My first assumption was that this is somehow chronologically handled by the wallet, but even if that were the case, according to the listing in the blockchain explorer after the first 4 referenced transactions used as input, the sum would be sufficient.
131,37735 BTC
1687,1255 BTC
157,79525 BTC
395,876 BTC
Are the first Transactions consumed and the result already exceeds 2k BTC.
I am thankful for any help and ideas!

Only the exchange can answer this - most exchanges and hosted wallets implement their own utxo handling mechanisms, and don't necessarily follow a space/fee optimal approach. There could be other considerations, such as reducing the number of utxos in their wallet, consolidating funds into bigger utxos during a low fee period as they expect larger payments during a high-fee time, or other business reasons.
Alternatively, it could just be an inefficient implementation.

Thank you very much! I also think that this will be it.

I hope this doesn't violate any forum etiquette, but I also asked this question on Bitcointalk.org.
Like you said the answers referenced the concept of input address consolidation.
Like you assumed, inputs are consolidated in times when fees are low, in order to keep the transaction size as small as possible in times when fees are high.
My forum post: https://bitcointalk.org/index.php?topic=5245438.new#new
A very helpful link: https://bitcointalk.org/index.php?topic=2848987.0


text:
How much of bitcoin core software can be custom written at miner's end and how much of the code you can't touch? where does bitcoin draw the line?
I've read bitcoin content everywhere on the internet and nobody has yet demystified the fact that different versions of bitcoin core are working simultaneously. I know how soft forks work and how they are backward compatible and the don't break consensus. But nobody has come up with an explanation that how much of the bitcoin software can be custom-written or It can't be custom-written?
Please explain in terms of powerful solo miners and pool miners.

Forget Bitcoin for a second, instead imagine a network of nodes that passes around data packets that say Hello World!, followed by the current GMT date. To be a part of the network you just need to transmit such messages, but transmitting a different or improperly formatted message will get you banned.
So to join this network, all you need to do is to write a simple program that creates a message which reads Hello World!, and then the date. The choice of programming language doesn't matter much, neither does the method of discerning what the date is. Even the most newbie developer could write a program that would successfully maintain a position in the network, as long as they follow the rules.
Notice that in this example, what matters is the output, not how we arrived at it.

Back to the bitcoin network:

But nobody has come up with an explanation that how much of the bitcoin software can be custom-written or it can't be custom-written?

All of it can be custom written. On the bitcoin network there are many different versions of bitcoin-core running, as well as some other full-node implementations such as btcd or bitcoin-knots. For mining it is the same. Each different implementation can be an entirely different codebase, written in a different language, by different developers. What is important is the output of that codebase:
For bitcoin full-nodes, the desired outcome is that the node will stay in consensus with all other nodes about the current state of the network. Broadly speaking, this means following along with all 'consensus rules'.
For miners, the desired outcome is that they will be working to create what the network of full nodes will view as a valid block. A new block must conform to many rules in order to be seen as valid, so again the implementation's output will obviously have to respect those rules. Note that a miner will need to be running a full node to do so, in addition to running some code that actually constructs and hashes block candidates.
Pragmatically speaking, it is much easier to write a custom miner implementation, as there are less rules that must be strictly followed to achieve the desired outcome (ignoring the dependancy on a full node for network status information, of course).
Note that there is no way to check or enforce that other nodes on the network are running some specific code, even if you asked, they could just give a false answer. What does matter is the ability of those nodes to all stay in consensus - it is perhaps easier to maintain this if all nodes are running the same codebase, but it is not strictly necessary.


text:
Bitcoin c-lightning node on Synology cannot connect to bitcoind
I'm trying to setup a bitcoin lightning node on my NAS (Synology), following this tutorial: https://bitcoindev.network/running-a-lightning-node-on-synology-nas/
Unfortunately I get the following error (log):
lightningd: WARNING: default network changing in 2020: please set network=testnet in config!
bcli:
Could not connect to bitcoind using bitcoin-cli. Is bitcoind running?

Make sure you have bitcoind running and that bitcoin-cli is able to connect to bitcoind.

You can verify that your Bitcoin Core installation is ready for use by running:

        $ bitcoin-cli -testnet echo 'hello world'

2020-06-30T19:45:20.256Z INFO plugin-bcli: Killing plugin: Plugin exited before completing handshake.
The Bitcoin backend died.
lightningd: WARNING: default network changing in 2020: please set network=testnet in config!

My lightning.conf contains the following:
alias=myalias
network=bitcoin
bitcoin-rpcuser=myusername
bitcoin-rpcpassword=mypassword
bitcoin-rpcconnect=127.0.0.1
bitcoin-rpcport=18332
log-level=io

I've tried several parameters for bitcoin-rpcconnect (internal ip, external ip of my bitcoin node including the right ports).
Since my bitcoin node is running on mainnet I try to setup the lightning node for mainnet as well.
So does anyone knows what I'm doing wrong?

It seems that lightningd isn't using the mainnet (notice the -testnet in the bitcoin-cli line), are you sure the config is in the correct place? Notice that you call the file lightning.conf but it should really just be config in the correct directory.

I tried to name the file just config but unfortunately it gives the same error. So any ideas what else it might be?

You can always pass any options you have specified in the config on the command line, alias=myalias just becomes --alias=myalias and so forth. That eliminates at least the config filename source for issues.


text:
Bitcoin full node running on Synology not visible to network
Last week I bought a Synology (918+) and starting running a Bitcoin full node (https://hub.docker.com/r/kylemanna/bitcoind).
To check whether the Bitcoin node can be found by the network, I checked on bitnodes.io with my external ip. Unfortunately my Bitcoin node is not reachable. I have forwarded ports 8333 - 8334 on my router. Checking whether port is open on canyouseeme.org, it gives as reason 'Connection refused'.
Another thing which confuses me is the following: if I check the logs, it gives the following (snapshot):
2020-05-14T11:01:13Z UpdateTip: new best=00000000000009b091d2696ccfceae650b7f7a4fd8a9fd1893598647b9a886b4 height=1744386 version=0x20000000 log2_work=72.438235 tx=56041013 date='2020-05-14T11:00:46Z' progress=1.000000 cache=3.7MiB(28196txo) warning='22 of last 100 blocks have unexpected version'
2020-05-14T11:03:14Z UpdateTip: new best=00000000000006d99735a74bae0c3bba509d56af9f8a01595099533c9bc34e6c height=1744387 version=0x20000000 log2_work=72.438236 tx=56041054 date='2020-05-14T11:03:13Z' progress=1.000000 cache=3.7MiB(28220txo) warning='22 of last 100 blocks have unexpected version'

What my understanding is that height is the block height. How can this be height=1744387 when we're currently around block height 630335? What am I missing here?
Please note that I am both new to running a NAS and a Bitcoin full node, so any help is appreciated!

Are you connected to the testnet?

That is the block count of testnet: https://live.blockcypher.com/btc-testnet/. The Docker script automatically generates a bitcoin.conf configuration and launches bitcoind. Somehow testnet=1 got set in bitcoin.conf or bitcoind was run with -testnet at the command line.

Yes, this was indeed the problem, thanks for clarifying! Now downloading the main chain. Going very slow (for days now already), but enough threads on here how to speed that up. :-)

For reference, downloading the entire blockchain on my Raspberry Pi over a 80/5mbps cable internet connection took a couple MONTHS. Too many nodes these days are bandwidth limited or pruning, significantly slowing a full download. My point? It takes patience to download it the first time.

Ah, that's good to know. So I guess downloading should take a couple of weeks. Probably the 4 GB memory being the bottleneck. Anyway, thanks for your help, much appreciated!

When bootstrapping my node CPU rarely wen above 25% and memory rarely above 75% on my 1.2ghz RPi 3B with 1Gig RAM. Unless I'm missing something, it appears the bottleneck is a lack of other nodes that have the full blockchain and allow you enough bandwidth to download. Just my $.02. Regardless, a long wait is likely


text:
In the future, if I pay a coffee with a very low fee, will it ever be paid?
So this is the thing, I am just learning about feedrates and how the miners pick their transactions with higher fees, so they can get more money. But, what will happen in the future when people pay really small things in the daily basis and the fees are insignificant, does this mean that I would get my coffee but it will be never paid?

No, ofc not.
In future, if the fees are insignificant, there will be a lot of transactions and miners will get the proper rewards for their work by all those small fees together.
New blocks are coming with new transactions every 10 minutes. Any transaction with fee superior to 1sat/byte will eventually gets confirmed.

Thanks for the answer. It is that in time, all transactions will be processed? This is because it is not possible to make a 0 fee, you always have to pay a fee..? That's the rule right?

Yes,the minimum fee is 1 sat/byte.
It is not possible anymore to make a free transactions with 0 sat/byte, as it was long ago.
If transactions were free, Bitcoin network could be easily attacked with lots of spammy transactions to congest the network.
Even now with the network highly congested all transactions are processed if they have at least 1 sat/byte fee. I made one a few days ago which too 3 days to get confirmed.  I wasn't in a hurry.

When constructing a block, miners will choose the highest fee-rate transactions to be included (measured in sats/vbyte), such that they will gain the largest reward for each new block they find.
So the answer to your question entirely depends on how much demand there is for blockspace in the future. As the technologies concerning fee-estimation develop further, we may expect less volatility in fee rates, but it is unclear how low the lowest fee rate will be in the future.
Over the last few years, the network has seen periods of high fee-rates, and then periods of low fee-rates. During the less congested, low fee-rate periods, it is possible to confirm transactions with fee-rates of 1sat/vbyte.
If demand increases in the future, then we may see a new floor for the fee-rate develop, at some level higher than 1 sat/vbyte. How how the new minimum rate is, and how long the new minimum lasts will depend entirely on the usage of the network. All else equal, more demand = higher fees.

But, what will happen in the future when people pay really small things in the daily basis and the fees are insignificant, does this mean that I would get my coffee but it will be never paid?

A savvy merchant wouldn't hand over a coffee if you broadcast a transaction that pays fees far below what would be reasonably expected to be confirmed in the ~near future. More likely, the merchant would accept payments for small items like a coffee using a technology like the lightning network, or perhaps a sidechain that is more amenable to low-value payments.

It is also possible to create a transaction which pays zero fees, but the network's nodes will generally not relay such transactions (as an anti spam measure). However, if you are a miner (or an acquaintance of one), then you can have a zero fee transaction included in a new block, without having to broadcast it to the network at all.


text:
I think I was scammed
A few days earlier, a guy approached me claiming to mine bitcoins and multiplying my bitcoins 10 times.
I invested with $700 and the blockchain wallet after 24 hours showed me $7000 worth bitcoins.
But it was non-spendable.
The guy told me to give him half the commission so that he could approve the profits for them to reflect in my wallet which could be spendable.
I bought $350 worth of BTC and transferred them to The guy’s wallet address. And now he is asking for a transfer fee of $300 worth bitcoins So he can transfer my profits to my bank account.
The profits that reflected in my blockchain wallet are still non-spendable. His approval of the profits did not reflect that money in the wallet. And now he is asking for more money.
Is this a scam?
How can I recover my initial investment?
Where can I report him?

I am afraid this is a common scam, yes

So there’s no way for me to recover the money?

Also, I do not know what the private key is and how I can find it. The blockchain wallet was created by me.
But the guy had logged into it once. Does that mean he did something?

I read this question and the answers on it.
But I was the one who created the blockchain wallet. So reading that question made me further confused. Kindly explain more on this. Will be grateful.

And no, They didn’t Give me the login credentials. I logged in with my email address.

They Had logged into my account once. But now that I have uninstalled the blockchain wallet app, I cannot again log in to it.

This is DEFINITELY a scam. Unless you can convince the scammer to return your funds (unlikely), there is nothing you will be able to do. Sorry for your loss, whatever you do, do not send this individual any more of your money. For future reference: no legit investment broker will promise huge returns, that is a huge red flag.

Since the other answer didn't help I've added an answer here. If you don't understand this stuff, please keep away from it until you have had a chance to get more familiar with it - there are some good books and online resources around. Bitcoin isn't for everyone - you need to be careful and trust no-one with your wallet or private-keys or seed-phrases etc.

How we know this is a scam:

a guy approached me

That's a red flag, its how many scams start

claiming to mine bitcoins

That's another red flag, real miners don't approach strangers asking for $700 investments.

multiplying my bitcoins 10 times.

Another red flag, such big profits don't happen quickly - or at least are exceptional and cannot be predicted by a miner or investment expert or broker. In reality your $700 is almost as likely to turn into $70 as $7000.

the blockchain wallet after 24 hours showed me $7000 worth bitcoins

Another red flag. 10x gain in 24 hours never happens.

it was non-spendable

Another red flag. The scammer had altered the wallet to show someone else's money not money that you control.
What you see in a wallet isn't always real, a watch-only wallet or a watch-only / non-spendable address shows you someone else's money not yours.

The guy told me to give him half the commission

Another red flag, there's generally no such thing as commission in Bitcoin. Third-party business that act as a middleman may charge commision but you never really need to do business through a middleman.

now he is asking for a transfer fee

Another red flag, there's no such thing as a transfer fee normally. Theres a different thing that sounds similar - the transaction fee. But that should be a few cents.

Your questions

Is this a scam?

yes

How can I recover my initial investment?

You can't.
Beware. Now that you are known as having been tricked once. Other tricksters will contact you and offer to help you recover your money or tell you about marvellous people who can get your money back. All lies.

Where can I report him?

Local police.
They won't do anything for a $1050 loss though, other than provide advice and then update crime statistics, which may eventually lead to a change in their priorities.

How this happened
A bitcoin wallet doesn't contain money.
We talk about it as if it does but that's just a convenient shorthand, the reality is complex and its easier to talk about wallets as if they contained money. They don't,  it's an analogy, a misleading analogy alas.
A bitcoin wallet normally contains a secret number called a private-key. That's the only valuable thing in it.
Bitcoin payments are made to Bitcoin "addresses". An address is just a number, it doesn't identify a place or a person. Normally your wallet generates addresses from the private key using a mathematical procedure that can't be reversed. Wallets also allow you to add other unrelated addresses you want to watch (see the balance and payments in and out). Without the private-key for those other addresses you have no control over money sent to those addresses.
Even though you created the wallet yourself, you then gave control over that wallet to a criminal. The criminal changed the wallet by adding an address to it that they controlled not you. This is called a watch-only wallet or a wallet that contains a watch-only address. Some wallet show this money as "non-spendable". Same thing.
If you give control over your wallet to someone they can extract and copy the private-key. They can create their own wallet and put that copied private key into it, giving their new wallet control over any money associated with the original wallet. They could also (or instead) put watch-only/non-spendable addresses into the wallet.
Changing the password on a wallet has no effect on any extracted copies of the private-key that the fraudster made when you gave them access to your wallet.
You should throw away that wallet. Any money put into it in future is under the control of the fraudster no matter what passwords you change.

You mention that you use your email-address to access your wallet. I hope you didn't give anyone the password to your email account.
You may have created a type of online wallet called a custodial wallet - these are the least secure types of wallet. A custodial wallet is controlled by a business not by you. If the business goes bust, is hacked or closed, you have no money.

The terms and conditions at Blockchain.com say

5.5.2 When you create a Wallet, you must: (a) create a strong password that you do not use for any other website or online service; (b) provide accurate and truthful information; (c) protect and keep secret all credentials for the Wallet; (d) protect access to your device and your Wallet; (e) promptly notify us if you discover or otherwise suspect any security breaches related to your Wallet; and (f) use the backup functionality provided through the Wallet and safeguard your backup files. You agree to take responsibility for all activities that occur with your Wallet and accept all risks of any authorised or unauthorised access to your Wallet, to the maximum extent permitted by law.

(My emphasis)
You didn't do this unfortunately.

thank you so much for this information.
Yes, I had not done any background check nor did I read and follow the blockchain wallet’s instructions.


text:
Will my funds return?
so after 3 days , my transaction is still unconfirmed , is it possible that my money is gone ? Cause i've read after a week it would be removed from network but i didn't fully understand this .
does this mean my money would go away or it would be back in my wallet ?

https://en.bitcoin.it/wiki/Fee_bumping#I_sent_the_stuck_transaction

If a transaction is not confirmed, your coins are still in your own "wallet". Money is transferred only when the transaction is confirmed and are part of the blockchain.


text:
bitcoin block time after halving?
I would like to know why the bitcoin block time is taking longer than 10 minutes, I know that bitcoin halving had decrease reward and increase difficulty but according what I read the blockchain itself will regulate the block time by adjusting difficulty to create a new block in order to have the same block time as first block was ever mined.Now block time are taking even hours what is it ?
thanks a lot

Does this answer your question? What keeps the average block time at 10 minutes?

thanks for the response, because of halving and difficulty increasing, the time for block is changing recently an even will continue increasing, that's the summary but because  halving miners are increasing by themselves the fees and controlling what to mine, I don't agree.

After halving, the reward goes down by 1/2. Some miners may find it unprofitable to mine and thus shut down their mining operation. However, the network difficulty remains the same until the next difficulty adjustment, which is every 2016 blocks (14 days approximately). Thus, the block time will increase to > 10 mins per block until the next difficulty adjustment.


text:
can sign derived wallet transactions with master seed phrase private key?
I would like to sign a transaction from a wallet which is derived from a seed, and sign it with master seed private key, can I sign any tx of any derived wallet address after the master seed wallet?
thanks a lot.

No you need to derive a private key from the master in order to sign a transaction (which, I assume pays to the PKH of this key).

yeah, thanks for the response I'm a little confused, because I don't know if there a master seed than can sign any child wallet tx, instead of using its derived private key, it's like a father which signs all child's tx without prompting them.

No, there is not.

ok, both thanks a lot, I thought it was possible. :)

The master private key is derived from the seed and all child private keys are derived from the master private key. Knowledge of the child private keys lets you sign transaction spending coins sent to the corresponding addresses. So yes if you have the master private key you can derive the child private keys and use those to sign any transactions related to that wallet.

ok, thanks for the response, I have a 12 word seed phrase, but I don't know how to do it using javascript there any any guide that you can share me, thanks a lot :)

what I meant was I have 12 word seed phrase, and it will generate a master private key, and I want to have another derived wallet using the same seed, then with with the second wallet send a tx no signed with its own derived private key  instead I will sign it using master private key can I do that? if so there any guide or link for explaining using any programming language. thanks a lot

@andrew007 master private key can't be used to sign transactions. also do learn the difference between a wallet and an address. a wallet contains many addresses. bitcoins are sent to addresses and spending transactions are signed with child private keys corresponding to those addresses.


text:
segwit compatilibity bc1 and 3 bitcoin wallet?
I would like to know what's the better aproach for upgrading from a legacy address to a segwit one, but there are two type of segwit as P2SH starting with 3  and Native SegWit (bech32) starting with bc1, but don't know which of the two segwit one, is better and is compatible to transfer and receive from a legacy one. ?
I know that a segwit wallet helps to reduce the size of the tx, and reduce fee,but don't know if there is a drawback for each type of segwit?

there are two type of segwit as P2SH starting with 3 and Native SegWit (bech32) starting with bc1, but don't know which of the two segwit one, is better and is compatible to transfer and receive from a legacy one?

Generally speaking the "bc1" native SegWit address is better. It's completely redesigned comparing to the classical/legacy Base58 encoding invented by Satoshi.
Alphabets in a "bc1" address can be either all upper-case or all lower-case, the former fits QR code better, resulting in a more compact QR code. Without mixed-case alphabets, "bc1" address is also easier to be read orally.
"bc1" (P2WPKH) addresses take the least bytes in transactions comparing to "3" (P2SH-P2WPKH) addresses or "1" (P2PKH) addresses, therefore its miner fee is the cheapest among three address types.
Bitcoins can be freely transferred among all three address types.
However, when you are receiving bitcoins, there's a compatibility issue around "bc1" addresses, that some (old) wallets (including the withdrawal interface of some exchanges) simply don't recognize it.
When you are sending bitcoins from SegWit addresses, there's nothing to worry about, except a minor issue that a 0-conf SegWit transaction may not show up in the payee's view, if the payee is using an old wallet which is not SegWit-aware. In that situation, it will finally show up in the payee's view when it gets included into the blockchain.
By the way, SegWit addresses, including both "3" and "bc1", currently doesn't support the "sign/verify message" feature in Bitcoin Core. Some developers also worried about abuses of this function IIRC. Trezor and Electrum had implemented this feature in ways which were not compatible with each other. In the future, maybe we could see this standardized by BIP322.

a segwit wallet helps to reduce the size of the tx, and reduce fee

Currenty SegWit doesn't really reduce the size of the transaction. The "bc1" native SegWit address only reduce the size by several bytes. The "3" P2SH SegWit address on the contrary cosumes more bytes in the block, because P2SH wrapping itself requires a 20-byte hash.
Mostly it's just a discount (aka. "virtual byte", or vB for short), that the "witness" part (mostly digital signatures and pubkeys) would be counted as 1/4 of its actual size. Obviously, only transactions spending coins from SegWit addresses enjoy that discount.
However, SegWit has other benefits, like Signing of input values, which simplifies unsigned transaction format, especially PSBT, which could benefit offline/cold/hardware wallets and transactions involving multiple parties (related).  Update: it turns out that this improvement doesn't really work for SegWit, then Taproot fixes this issue: https://blog.trezor.io/details-of-firmware-updates-for-trezor-one-version-1-9-1-and-trezor-model-t-version-2-3-1-1eba8f60f2dd

According to Blockstream Explorer native Segwit (bc1) saves you a 40% in fees and Segwit compatible (3) saves you 30%.

@mengeroshi Depends on the number of inputs and outputs of transaction.

Why are asm hash lengths different for bc1 transactions?
OP_0 4d6a8b2c7dfa984a0de1041f121453c220734e147f379461d2dbe8b9183eba2f vs
OP_0 0174f58fd3a3be597fb9110305f2c2cc2ffeb8dd

@VincentAlex because P2WPKH uses HASH160, while P2WSH uses SHA256. See BIP141 for details.

Here is a brief comparison
Native segwit

Compatibility: Not supported by many wallets like blockchain.com, various bitcoin exchanges like coinbase
Fee saving: 38% [1]

Segwit in P2SH

Supported by all bitcoin wallets/exchanges
Fee saving: 26% [1]

In summary, if you are receiving bitcoin on a website/shop it is good to use P2SH addresses as many of your customer will not be able to pay you. If you are receiving BTC from peers that you know have better wallets, you can send them bech32 address to take advantage of lower fee.
[1] https://blog.blockonomics.co/saving-transaction-fee-using-segwit-how-to-be-a-bitcoin-ninja-78d8416375db


text:
How to best practice restoring a wallet in bitcoin core
I have a test wallet in bitcoin core that I want to play around with and get comfortable with before I move my btc from blockstream green wallet. I primarily use that wallet because so far it has been easy to understand. So I have created this core wallet, sent $1 worth of btc to it, so not worried if I mess it up. I have backed up the wallet.dat file, backed up my private key and backed up my encyrpted passphrase all physically.
How would I go about deleting the wallet so I could practice restoring it? When you restore a wallet do your addresses automatically show up, or do you also need to import your private keys for each address in this case I have one test address.
I ordered a coldcard and want to use it with bitcoin core. Looks like I can here
https://github.com/Coldcard/firmware/blob/master/docs/bitcoin-core-usage.md for storage and need to do something called HWI for sending. I think I am reading this correctly.
Is this a good practice for security, I was looking at https://yeticold.com/ seemed interesting but it failed to restore my wallet, but it integrates with bitcoin core. I think it's just still very new so not good for storing anything real at the moment, I posted a issue on github with no response.
Apologies for jumping from one thing to another
To Summarize
A. what is the best practice for getting my feet wet with bitcoin core, ideally practicing restoring a wallet and private keys.
B. Is coldcard with bitcoin core very secure?
C. What's the deal with yeticold.com
and finally, is there a good practice for generating my encryption password for bitcoin wallets, is this what people generally call a seed phrase in most wallets, what is a seed phrase in other wallets vs cores passphrase.
Thanks ahead of time. Im new to bitcoin security so hopefully I am making sense. I don't mind spending the time to learn and practice things slowly to get this right, so fine with good resources to read.


text:
I transferred about 0.54 BTC and I cannot find this on Blockchain.com. Can anyone help?
I'm hoping someone more onto it can help me find or understand exactly what happened when I xferred my BTC from an exchange (Dasset) to my wallet.
I transferred about 0.54 BTC to bc1ql8wxn65d7crka2gr4f3gcgnynv23hvqg6akxef
When I searched for transactions under this address nothing appears on Blockchain.com.
I know I have transferred to this wallet before but I can't even see those transactions.
Thanks in advance.

I also transferred this about 18 hours ago now.

What is the name of the software wallet you use? If it's custodial, it might be some scam. Have you got the confirmation from exchange that the money was sent and transaction has been made? Sometimes exchanges take some time to withdraw. Are you using HD wallet, or one address all the time? If latter, it is weird that magically some transactions just disappeared.

Hi Tony, thanks for the response.
I use Dasset as an exchange and Exodus as a wallet.
I just noticed that my BTC Wallet address on Exodus has changed since I last used it (I have the option to use 2 different receive addresses, one I've used in the past and the other is new - if that makes sense).

Dasset didn't transfer any money to bc1ql8wxn65d7crka2gr4f3gcgnynv23hvqg6akxef. What did Dasset customer support say when you spoke to them about this?

So Dasset finally responded to me.
Dasset - "It wasn't process because it was bech 32 address".

I'm not sure what that means but they've apparently still have my BTC somewhere, its just not showing as available on the exchange.
I'm waiting for them to get back to me with what that is and how I can get my BTC to my wallet.

Firstly, I would use Blockstream.info or mempool.space, not blockchain.com for your online block explorer.
Second, depending on the exchange, they could batch withdrawals at a certain time each day, or they could set a very low fee, which means it would take a long time to be confirmed.
As was said in the comments, you could've been scammed. I have never heard of Dasset before.
Lastly, for each transaction, generate a new receive address to ensure privacy.


text:
Generate multiple public bitcoin receiving addresses (HD wallet) from seed phrase in nodejs
I want to generate a new receiving address for my bitcoin wallet for each new user. Bitcoin transferred to all these address should be received in my bitcoin wallet. I don't want to expose my private key or seed on the server.I found that this is how HD wallets work so I tried this.
const bip39 = require('bip39')
const bitcoin = require('bitcoinjs-lib')   //ver 3.0.2

let phrase = 'width humor wheat sad obscure outer ancient grab edit labor record express devote humble recipe occur refuse tooth original fluid learn scheme fuel assault';
let seedBuffer = bip39.mnemonicToSeedSync(phrase)
// <Buffer 85 19 18 81 cf 0e cc f7 9c 5d 61 ......

let masterNode = bitcoin.HDNode.fromSeedBuffer(seedBuffer)
// Deriving the first account based on BIP44
let account0 = masterNode.derivePath("m/44'/0'/0'")

let xpubString = account0.neutered().toBase58()
console.log(xpubString)
let address0FromXpub = bitcoin.HDNode.fromBase58(xpubString)

let address0 = address0FromXpub.derivePath("0/0").keyPair.getAddress()
let address1 = address0FromXpub.derivePath("0/1").keyPair.getAddress()
let address2 = address0FromXpub.derivePath("0/2").keyPair.getAddress()
let address3 = address0FromXpub.derivePath("0/3").keyPair.getAddress()
// address0.toBase58()
console.log("address0",address0)
console.log("address1",address1)
console.log("address2",address2)
console.log("address3",address3)

but I tried sending bitcoin to the generated address and didn't received any? If anyone could help.

Which address did you send to? Additionally, your code above has a seed phrase in it, so you're not really hiding the keys on your server

I used address0 and address1. Once I have generated the xpubString I don't need to use the above steps again so only the extended key generation code will be on server.

If you want to do Bitcoin stuff in nodejs, I recommend using bcoin:
repo: https://github.com/bcoin-org/bcoin
docs, guides: https://bcoin.io
It has a fully-validating full node implementation, SPV implementation, and BIP44 wallet that is used by Purse.io and several other Bitcoin-accepting merchants for this exact use case: Each customer gets a dedicated account and the wallet can track balances per-user, generating new addresses each time the current receive is used (a la BIP44)
You can set up your server with a watch-only wallet to report incoming deposits, and keep the private keys either offline or on more secure, local machine.
Example:
On secure or offline machine:
$ bcoin --daemon
$ bwallet-cli mkwallet --witness=true --id=HOT
$ bwallet-cli --if=HOT account get default
{
  "name": "default",
  "initialized": true,
  "witness": false,
  "watchOnly": false,
  ..
  "accountKey": "tpubDD3BFBuLYg2cspeDSWZgo9qv4qYi7KQF5oov8theqbFRUFqXPmsowPqAY1PQqnEdUe5JrFqf8ZGWLwEQEKB5WjJjxgMwcXmFuu1XDrG4RSr",
  ..
}

On "hot" production server:
$ bcoin --daemon
$ bwallet-cli mkwallet --id=WATCH --watch-only=true --account-key=tpubDD3BFBuLYg2cspeDSWZgo9qv4qYi7KQF5oov8theqbFRUFqXPmsowPqAY1PQqnEdUe5JrFqf8ZGWLwEQEKB5WjJjxgMwcXmFuu1XDrG4RSr
$ bwallet-cli --id=WATCH address default
{
  "name": "default",
  "account": 0,
  "branch": 0,
  "index": 1,
  "witness": false,
  "nested": false,
  "publicKey": "026f1afcab2942fd932760557943b287957bb8aa6ebe0f8dc64fa25862e23d52a2",
  "script": null,
  "program": null,
  "type": "pubkeyhash",
  "address": "mjdcszSLXHd6awrnM4bgJiFEbTFZdyw7de"
}

...etc
From here you can use API calls to create transaction templates and sign them on the offline machine.
If you are queasy about running an alternative implantation of Bitcoin, you can still run bitcoind on the hot server and run bcoin behind it (even in SPV mode) with bitcoind as it's --only= peer, like a Bitcoin Core Firewall

(edit)
Generate static addresses
'use strict';

const bcoin = require('bcoin');
const m = bcoin.Mnemonic.fromPhrase(
  'abandon abandon abandon abandon abandon abandon'
  + ' abandon abandon abandon abandon abandon about');
const master = bcoin.HDPrivateKey.fromMnemonic(m);
const key0 = master.derivePath("m'/44'/0'/0'/0/0");
const ring0 = new bcoin.KeyRing({privateKey: key0});
console.log(ring0)

Will output:
{
  witness: false,
  nested: false,
  publicKey: '03aaeb52dd7494c361049de67cc680e83ebcbbbdbeb13637d92cd845f70308af5e',
  script: null,
  program: null,
  type: 'pubkeyhash',
  address: '1LqBGSKuX5yYUonjxT5qGfpUsXKYYWeabA'
}

You can verify this is address 0 from that mnemonic phrase using https://iancoleman.io/bip39/ and of course because this phrase is so abysmally insecure and used by developers testing on mainnet (sigh) there are several transactions to this address: https://blockstream.info/address/1LqBGSKuX5yYUonjxT5qGfpUsXKYYWeabA

I haven't tried this but in my case, I only want to generate addresses for a single account. It's not a wallet and I don't have any users, I just want multiple receiving public addresses for my own account. Won't this be overkill for that?

I added a new section to my answer that demonstrates how to generate static addresses from a minimal script using a phrase. This is the same logic the bcoin wallet uses. I noticed your phrase in the original question had a checksum error, so I'm demonstrating with a null mnemonic (a private key of all 0's, commonly used in testing)

I tried using the static method and the address I got in ring0.address is exactly same as I got using the method I added in question => address0.  And also changing last digit of m'/44'/0'/0'/0/0 to 1 gives me address1 and so on. So I guess I am already generating the right address but when I sent some bitcoin to the address, none showed up in the account? Why is my account balance still 0 if the address is right?

What wallet software are you using to check the account balance?

edge wallet https://edge.app/

So your wallet shows you an address. You send BTC to that address, and the wallet never receives it? Are you sure your transaction was broadcast over the network? Can you find it on any block explorers?

No, the address that wallet shows works but when I try to generate more public addresses as above using the seed phrase from the app, then it doesn't work

This is the transaction https://blockchair.com/bitcoin/transaction/1293da90d81506041571f7aee138f2bcb0dc1e489ceb078a5ed02f84d5b43c07

Oh, contact edge or look through their documentation. Not all wallets derive keys along the same path. There is unfortunately no standard for this and different wallet developers will use different BIP44 paths for native/nested segwit addresses, etc. See BIP84 and BIP49

I couldn't find the standard for edge wallet in their docs. Can you suggest me any other wallet where I can test this?


text:
How to get bitcoin bip32 public key from private key?
I need to know how to get the corresponding public key of a private key in hd-wallets, I don't need the derived ones but the public key who is related to the private I got. If there is an algorithm using python it will be very helpful but also the formula will be good as well.
thank you.

I need to know how to get the corresponding public key of a private key in hd-wallets, I don't need the derived ones but the public key who is related to the private I got.

A private key derived using the BIP32 hierarchical derivation is similar to any other one and the corresponding public key is obtained by "multiplying" your private by G, as for any other private key.
You want to use a specific crypto library for this operation, and I believe coincurve to be a good maintained Python binding to libsecp.
You can also use python-bip32 to simplify your use of BIP32 derived keys (relies on coincurve under the hood).


text:
What's the easiest way to create a backup node?
My node recently had a data corruption and I had to re-sync it which was painful.
Presuming I don't use the node as a wallet, what's the easiest way to have a backup with the fully sync'd blockchain? Is it as simple as copying over the files from one external hard-drive over to the other?

You can just create a backup of the datadir folder, which could be saved on another hard drive in case your node’s chain state becomes corrupted. In case of corruption, just copy the saved data into the appropriate folder, and your node will then sync from that point in history, rather than starting from scratch. The datadir can be specified in your bitcoin.conf file, but will otherwise be found in the default path.
NOTE: you’ll want to stop the node before starting to copy the files. The normal operation of a node includes a lot of ~random reads and writes to the data directory files, so you’ll want to stop the node first to eliminate the chance of corrupting the data during the copy.

You can simply copy and paste the chainstate and blocks folder to some other hard drive. But copy-pasting it back in the case of a failure will still take awhile, though not as long as a full IBD


text:
Why doesn't basepoint G of Secp256K1 seem to be on the Elliptic Curve?
From what I understood are these the coordinates of basepoint G of Secp256K1 on the Elliptic Curve, in hexadecimal and decimal format.
Hexadecimal
Gx = (79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798)
Gy = (483ADA77 26A3C465 5DA4FBFC 0E1108A8 FD17B448 A6855419 9C47D08F FB10D4B8)
Decimal
Gx = (55066263022277343669578718895168534326250603453777594175500187360389116729240)
Gy = (32670510020758816978083085130507043184471273380659243275938904335757337482424)
What I don't understand is that if I enter these values in the corresponding equation (y² = x³ + 7) as below, it seems that point G isn't on the curve at all. But it should, right? So what do I wrong?

(32670510020758816978083085130507043184471273380659243275938904335757337482424)²

is not equal to

(55066263022277343669578718895168534326250603453777594175500187360389116729240)³ + 7

The secp256k1 curve is defined over x and y coordinates that are members of the finite field GF(2^256 - 2^32 - 977), or in other words, their operations hold only when considered modulo 115792089237316195423570985008687907853269984665640564039457584007908834671663.
55066263022277343669578718895168534326250603453777594175500187360389116729240^3 - (32670510020758816978083085130507043184471273380659243275938904335757337482424^2 + 7) is exactly 1442042049659660869506300006036683750029629333882594701370927246876626245108435922902327776681700708714008192087431130951749952236093997894375239788520937 times 115792089237316195423570985008687907853269984665640564039457584007908834671663.

Christ, don't you guys have MathJax on this site?

@probably_someone: see https://bitcoin.meta.stackexchange.com/q/563/208

@PieterWuille Aha that explains it! Thank you. It has been a long time since I worked with modulo, so I am practicing a bit again. Is this a correct representation of graph g(x) = 2x + 1 (mod 4)? (graph in red) https://www.mediafire.com/convkey/c56a/tcux7iwkbkqf7razg.jpg

@Harald1970 Yes.

Finite field mathematics and elliptic curves don't use the "normal operations". For example adding two finite field elements a and b isn't as simple as a + b. its actually
(a+b)%Prime where prime is the size of the finite field, this ensures the CLOSED property is meant. which says that if a is in the set and b is in the set than a + b is also in the set.
Same goes with multiplication which is what we have here.
ab=(ab)%Prime
so for gx and gy you can use this (gy^2) % (2^256 - 2^32 - 977) = ((gx^3) + 7) % (2^256 - 2^32 - 977). These are in fact are equal.


text:
Is that proved that for each block there is always nonce value which will make block hash to start by n count of 0
Sorry for the obvious question, but I'm looking for a mathematical prove.
Block header is calculated as a concatenation of the following values.

Version
hashPrevBlock
hashMerkleRoot
timeStamp
Bits
Nonce (32-bit number)

First 5 parameters are static for each block. Miner only tries to find out Nonce value, such that Hash(Block_header) will start with a certain number of zeroes.
Is that proved that for each combination of Version, hashPrevBlock, hashMerkleRoot, timeStamp and Bits there is a Nonce value, that will make block hash to start with a certain number of zeroes?
If yes, can you please share any article that explains that prove?

the hashMerkleRoot is not static, as it is calculated from the set of transactions included in the block, which can vary. The miner is free to organize these however they like, with the only restriction being that the first transaction must be the coinbase.

The odds of any nonce producing a valid block are miniscule. The vast majority of blocks cannot be mined. Miners have to try to mine billions of blocks before they succeed in mining one.

32 bits nonce + maybe a few bits in timestamp which you can change in hope to get a hash with 9.5 bytes of zeroes in front (19 hex-zeros) it is highly unlikely (as off June 2020 difficulty rate). Thus, you have to change your Merkle root. Just change the transactions inside the block (add, delete or rearrange or modify the coinbase tx )

Part of the requirement of a secure cryptographic hash function is that the output should be unpredictable, and therefore it should not be possible to say much with certainty about what can and can't happen.  It's overwhelmingly likely that every block can be mined, as explained in the answer.  But if there were a mathematical proof that it's always possible, that would be an indication that SHA256 is too predictable and that we ought not to be using it.

Cryptographic hash functions are collision resistant and the digests produced by SHA-256 are approximately uniformly distributed. This suggests that if the input space to the hash function is magnitudes bigger than the projection space of a hash function, we would expect that every value of the projection space can be hit.
The block header is 80 bytes, and the digest space of SHA-256 is 32 byte (256 bit). Out of the 80 bytes of the block header, version is unrestricted on 29 of 32 bits, the nonce is a 4-byte arbitrary value, the Merkle root is a 256-bit digest derived from an enormous combination space, the timestamp is rather flexible—limited to a unix timestamp range of roughly 3h/10,800 seconds (~13 bits), only the previous block hash and difficulty statement are fixed. So, before counting the Merkle root, miners could generate up to 74 bits of entropy in the block header.
The Merkle root is derived from the set of transactions that a miner is choosing to include in their Bitcoin block. Not only can the miner arbitrarily pick content and order of the (valid) transactions, but also each miner is paying themselves in the coinbase transaction of their block candidate. Given that paying to different addresses results in different coinbase transactions, every miner is working on a unique transaction set whose Merkle roots making any overlap between block candidates of different miners astronomically unlikely. Further, parts of the coinbase transaction's input can be picked arbitrarily (the "extranonce" and most of the remaining 2–100 byte input script of the coinbase transaction) giving miners a way to easily add further entropy to the set of block candidates they're evaluating. Additionally, miners update their block candidate's transaction composition whenever more new transactions paying higher fee rates arrive. Even if there were no transactions to add in the block, miners could just generate a different address to pay themselves for use in the Coinbase after exhausting the nonce and extranonce space.
Given the power set of all possible transaction orders, the address space of Bitcoin, and the 100 byte input script in sum by far exceed the 32-byte digest size of SHA-256d, I'd argue that the Merkle root provides a full 32 bytes of entropy.
In sum that gives the miners ~41 bytes of arbitrary input data to produce a 32-byte digest i.e. an input space 272 bigger than the projection space. Meanwhile, a block is only restricted to the current difficulty which is significantly smaller than 2224 (the difficulty of requiring a block hash 000…0).
While this doesn't meet the requirements of a rigorous mathematical proof, I'd surmise that miners do not have to worry about running out of possible block candidates. Therefore, it's just a matter of time until someone happens to succeed at creating a new valid block.
Also see this closely related question here: How can we be sure that a new block will be found?.

Nice! Thanks, @Murch, it makes more sense now.  The nice and detailed answer, thank you.  One more question. If I want to play with this, any way to connect to the pool of unapproved transactions and try to compose block myself (by using local custom programs), instead of using bitcoins standard mining tools. Any API, or similar thing to get unapproved transactions.

I think you may be looking for getrawmempool. Not sure about programs to build blocks from that then, though. I guess some miner controller might do?

Version, hashPrevBlock, Bits (a representation of the current difficulty) are static for the current block, the timeStamp is a unix representation of the current time, the miner can change it to change the blockheader too (untill 2 hours in the future)


text:
How to recover bitcoin wallet from messed up seeds
I have a ledger nano s wallet that is broken , when i tried to recover wallet from 24 recovery word i got error that says the recovery phrase is incorrect, i think the place of some words is incorrect and one weird thing is one of the words is duplicated in phrase, which i think is wrong.
So far i wrote a program in C# with nbitcoin library that checks all 2048 words of BIP39 wordlist in one place of 24 place and tried to generate its deposit address and compare it to lost wallet address like (i checked the code with new ledger wallet address and it worked) and i couldn't the correct phrase.
Write now i want to generate every possible combinition of these word and check them, i think it's around 24! Possibilities which is almost impossible to check, but i also know that every combinition of words in wordlist is not true and there is a checksum which i hope limit the possibilities.
Right now i need a code preferably in C# with nbitcoin library to generate every possible and true phrases of mnemonic and a suggestion for fast checking the phrase against the wallet.

i already using btcrecover library, the problem is I dont know python and I cant read the source and optimize it to my need

U probably may need to pay someone to do the program. Please don;t give them your 24 recovery word OK. Otherwise, your $$fund is as good as gone.


text:
Wallet.dat bitcoin cash?
I had 20 btc in 2012, and I spent it all in December 2017. I heard there was a fork for Bitcoin cash.
How do I get my 20 bitcoin cash out of my wallet.dat ?

Run Bitcoin Core. Use dumpwallet to save private keys. Download a Bitcoin Cash wallet from https://electroncash.org/ Once you set it up go Wallet > Private Keys > Sweep. Good luck, this should be straightforward.


text:
Bitcoincore wallet 0.20.0
Because on windows it is so difficult to load the blockchain into the BitcoinCore wallet. Arrives in 2016 the loading rate increases days. In ubuntu18.04 it is so fast and does not slow down after 2016. When it slows down and checks on windows with bitcoind.exe after 2016 and it finds four errors in the blockchain; how should I proceed?

It doesn't depend on the node version but from the network status. You couldn't have for all the time the same download velocity. Sometimes yes, sometimes no. Also, you should considerer that the bitcoin core data are big and not all people have the complete copy on their pc, so it mean that only a few nodes on the network has all data available to share. I downloaded the bitcoin network in two different places in the same day and I had some big differences on the timing

It's normal, because the number of transactions are bigger. The blockchain size is very big one, and it depends in your internet speed, it can take even 4 weeks to download the entire blockchain

My network traffic on debug console is so fast in ubuntu, then one day I charge blockchain, but in windows it is very slow; it will take almost 1 year. Is this normal on windows?

I addnode almost 20 node on windows debug console but my network traffic isn't continous. Appears and disappears and fades away the registered nodes (20 addnode)

It will not take one year, even the remaining time will change, sometimes to one year, then to 4 days, then to 4 week, but will take a good period even with a good traffic

@MinerBr99 It happened to me too when i donwloaded it, it wasn't continous


text:
Bitcoin V0.1 Not Connected
My Bitcoin V 0.1 says, "not connected" when I try to generate coins. I have ensured the port is connected through the firewall. Also, I have read that V 0.1.3 corrected this problem. However, I am trying to connect without installing V 0.1.3.
Does anyone know how to correct a V 0.1 "not connected"?

You cannot.
There have been both changes to the P2P protocol that prevent this, and changes to the way that nodes are discovered.
The method which 0.1.0 discovered new nodes was by joining the #bitcoin channel on freenode. Your IP address would be encoded in a certain way and that would be the IRC nick for your node. However this has long since been removed from the Bitcoin software and any node that does connect to the #bitcoin channel will be kicked from it (the encoding is unique and identifiable).
Since 0.1.0 can't connect to the IRC channel to discover new nodes, it is unable to learn about nodes that it can connect to.
Furthermore, the P2P protocol has changed since 0.1.0 was released and thus 0.1.0 is unable to communicate with modern nodes. This change was to add a checksum to the end of the P2P message header. Messages without this checksum will be rejected by modern nodes.
Lastly, 0.1.0 is too old so modern nodes won't connect to it. They have a minimum supported protocol version number, and 0.1.0's protocol version number is far too low. So even if you could get it to connect, the connection would be dropped.

The way to deal with the node discovery issue is to manually modify the peers.dat file to have the IP address and port of nodes that you want to connect to.
The only way to deal with the P2P protocol changes (checksum and version number) is to have a shim that sits in between all of your connections and modifies the P2P messages to work with modern node software. Or you can connect to a modified node which can deal with 0.1.0 traffic.

Even if you are able to connect to the Bitcoin network with 0.1.0, you won't be able to mine anything as the CPU mining is no longer viable, and the CPU miner implementation in 0.1.0 is not efficient. You also wouldn't be able to even sync as it syncs too slowly. Blocks will be found faster than it is able to process them. It will run into additional issues when it receives a new block before it is able to sync the blockchain that precedes that block.

Okay. What version and date implemented these changes? Also, Does the modified version contain all block and transaction data from day one of bitcoin because when I installed the latest version, it started around, I believe, 2012 (Wheres all the previous data (2009-2011), what happened to it (Wallets, Transactions, Keys, etc), what became of it?)

...also, how do you create this shim?

0.2.9 introduced the checksum in May 2010. 0.3.18 is the oldest version allowed by modern nodes. All versions will attempt to download the blockchain from genesis. The software does not come with the data from day one, it all gets downloaded from other nodes on the network. If it did not begin from the genesis block, then you already had some of the blockchain already downloaded. The shim needs to be a program that you write yourself.

Do you know when version 0.3.18 was implemented (Doesn't seem far off from May 2010). I do have some backup files from my older drives loaded. I wonder if it was found while downloading. I believe, on my other drives, I have a wallet.bat file (Not sure but remember seeing it when reviewing my data). Okay, the implementation date of 0.3.18, will determine on whether I attempt to write a shim. Currently, I'm using version 17 and 20, and I want to use the oldest possible version to recreate the original environment from a decade ago. I'll search for 0.3.18 version, now. Thanks!

All version back to 2011-06-05 Bitcoin version 0.3.22 released (to new) may be found here...  https://bitcoin.org/en/version-history, and I have found that that version 0.3.18 was released on 8 December 2010 (perfect), posted release here... https://nakamotostudies.org/emails/bitcoin-list-bitcoin-0-3-18-is-released/ released in 2010 and may be downloaded here https://sourceforge.net/p/bitcoin/mailman/message/26722835/. I'll download and check if it works, now. And follow-up with a resolution or technical question if needed. Thanks!!!!!

The previous link to download 0.3.18 forwards to https://github.com/bitcoin/bitcoin as of 5 June 2015. And version 0.3.19 was released on 13 December 2010 http://satoshinakamoto.me/2010/12/08/bitcoin-list-bitcoin-0-3-18-is-released/ (I'll go with that one), also found here, https://github.com/bitcoin/bitcoin .

Older versions are no longer available because they are insecure and no longer able to sync the blockchain. 0.1.0 is only available because some people have decided that it has historical significance and re-uploaded copies that they had downloaded when it was available. Why are you trying to use such old versions of Bitcoin?

Because it has historical significance to the operation of my older account that I'm trying to recover and because I'm learning again, and since older software is also much easier to learn, work, and to understand in relation to all revisions through the years. Also, if bitcoin denies the operations of older versions, it denies any historical significance it may hold. Does Microsoft deny installation of its previous versions of Windows? No. Because its needed to operate older versions of different associated files or software (off topic: I read a white with your name in it. Interesting paper)?

Older Bitcoin software provide far less access to the inner workings of Bitcoin. There are few/no RPCs (depending on how old you go) and there are newer RPCs that provide better access to internal structures so that you can inspect and learn from them. Older does not necessarily mean better for learning. Older software is also not necessary to access old files. Bitcoin largely maintains backwards compatibility with the data files produced by old software so you should be able to open wallets and some existing blockchain data in a new software.


text:
Transfer BTC from paper wallet without 3rd party (like blockchain.com etc)
I have btc on my paper wallet and I want to transfer to some other address. How can I do this without sharing my private key to some other site like blockchain.com or electrum?

Electrum does not share your private key with its server. I would use Electrum as it's very convenient, well-maintained and it does not have large storage requirements.

Create new wallet
File > Sweep private key

Some other options are:

Bitcoin Core, which expects you to download the whole blockchain. Use the importprivkey command.
BRD wallet, which is my favorite mobile wallet that can sweep from QR.
CoPay mobile wallet also has the same feature.

Electrum and Bitcoin Core are the two most popular desktop wallets. (Core was actually designed as a full node, therefore it's not very user-friendly and not the best wallet). I'm not aware of a third desktop wallet.

how can I trust Electrum? is it open source?

Yes, it's here: https://github.com/spesmilo/electrum @kilonet


text:
Explain how unused addresses in wallet.dat have no balance when mining occurred for many months
I have a wallet.dat file with many zero transaction/(unused) addresses in it with keys assigned to each address.  I’ve done research and there’s quite a bit of info about mining back in the day (2013-2015) say but what people don’t explain is when someone solved a block and thus got rewarded 12.5 bitcoins, and when the bitcoins are saved in a wallet, how can the unused addresses in a wallet.dat file have no balance when checked with blockchain.info?  Where are the bitcoins that were mined and why do the addresses have no balances? Why were all these addresses created in the wallet.dat file?
There is a disconnect between a miner’s reward of bitcoin he earned while mining and what is in his wallet and unused addresses showing zero balances. I am having trouble understanding the relationship with mined bitcoin, unused addresses with assigned keys in a wallet.dat file, and having zero balances when checked with blockchain.info

Unused addresses are unrelated to mining activity. Even if you were mining, you will still see many unused addresses. The Bitcoin earned from mining would be associated with a used address.
Bitcoin Core by default will generate 1000 (previously 100) unused keys to be used in the "keypool". The keypool is the pool of unused keys and is used as a lookahead. This is useful when you restore a backup. The unused keys you are seeing are this keypool.

But why would mined bitcoin be associated with used addresses if no bitcoins were spent?  Where are the mined bitcoins located or stored on my computer? This keypool has no monetary value? Let me ask this question... if I allow bitcoin core to sync for days (because I’m years behind) will it read my wallet.dat file and tell me my bitcoin balance or will it read a different file to determine the bitcoin balance? By the way, the reason I’m ignorant with all this is my teenaged son mined, not me!

An address is used when it has received Bitcoin. So mined Bitcoins are received and thus make the address used. You won't see any object in the wallet that is "a bitcoin" because that is not how Bitcoin works. The keypool has no monetary value. If you let Bitcoin Core sync, it will use the wallet.dat file and determine the balance of that wallet.

Bitcoins are not saved in wallets.
The only important data in a wallet are the secret numbers called the private-keys.
The nearest approximation to the truth is that bitcoin are stored in the public blockchain - of which every bitcoin wallet either maintains its own copy or has access to a copy.
In the case of the wallet named "Bitcoin Core", the private keys are stored in the wallet.dat file along with a lot of other unimportant stuff. On MS-Windows Bitcoin core stores a local copy of the public blockchain in a set of files named blk00001.dat to something above blk01234.dat in %APPDATA%\Bitcoin\blocks.
What is actually stored in the blockchain data is just transactions. Just a complete historical record of amounts of money for which control has been transferred from one person's private-key to another person's private-key. Some clever mathematics allows this to be done without disclosing private-keys. To work out a balance you have to read the whole blockchain and subtract the sum of spent amounts from the sum of received amounts. The blockchain is what accountants would call a journal. It doesn't keep track of balances directly.
The profits of mining are handled in almost exactly the same way as ordinary transactions. The first transaction in a block is the so-called coinbase transaction which pays the miner the amount of mining reward specified in the rules plus the transaction fees from the other transactions (if any) in the mined block.

So how does this relate to unused addresses in wallets?
It doesn't. These are unrelated concepts. Wallets generate addresses in advance of them being needed. This is just a convenience so far as I know. It is helpful when using the seed-phrase or private-key to re-create a destroyed or lost wallet as it allows the new wallet to find amounts of money received and spent by the previous wallet(s) at a range of addresses.
Addresses are just numbers used in popular types of bitcoin transaction. These numbers don't have any intrinsic meaning - they don't identify people or places or anything else. They are just a number mathematically derived in a deterministic way from a public-key associated with a private key.
So most wallets will have many many unused addresses with no balance associated with them because they have not been used yet in any transactions.


text:
View backed up wallet.dat using sqlite browser
I backed up my wallet.dat using the command as mentioned in the api ref:
bitcoin-cli -rpcport=18332 -rpcuser=user -rpcpassword=password backupwallet "/bitcoin/backup.dat"
I would like to view the backed-up db file using 'DB browser for sqlite' (or any other sqlite browser). However when opening the db file it prompts for the password / key to decrypt the wallet file.
Which password / key is it referring to? When creating the backup I didnt specify any password or key..

Is there any reason you don't use db_dump from the Berkeley db-utils package? I've used that under Windows-10 by using WSL (Ubuntu) - It can definitely dump an unencrypted Bitcoin wallet.dat file. I imagine it might even be easier to install and use db-utils under OSX - if that's your operating system.

Well the wallet.dat is from an Ubuntu server running Bitcoin-core that I am then opening on the OSX machine after the backup.. I hadn't known about the Berkeley db-utils package, can the db_dump util be safely run against a live running node? Or could it be run against the already backed up wallet.dat file?

I ran it against a backed up wallet.dat - not one that was being actively used.

Thanks @RedGrittyBrick works well, didn't know this package existed! I guess the wallet.dat is just made up of a 'main' db/schema and the keys inside it, I was hoping to see visually what else was contained in it, but it looks like only keys and some meta

OK I'll post my comment as an answer

wallets only use SQLite in limited circumstances.  To make an SQLite wallet run Bitcoin Core version v0.21 or v22.0 then create a new descriptor wallet; https://github.com/bitcoin/bitcoin/blob/9a42b5e/doc/release-notes/release-notes-0.21.0.md#sqlite-database-backend

db_dump
You can use db_dump from the Berkeley db-utils package.
I've used that under Windows-10 by using WSL (Ubuntu) - It can definitely dump an unencrypted Bitcoin wallet.dat file.
The Berkeley DB libraries used by Bitcoin core for the wallet.dat are a key-value store - and the keys used appear to be words like "key" and "keymeta".
As far as I know, the structure (if not simple data types) of the key and value are not known to the DB libraries. I believe applications such as Bitcoin core will often be storing blobs whose contents cannot be dissected by general tools which lack knowledge of the applications' schema.  The same observations are likely to apply to sqlite browser
However db_dump output is a worthwhile step up from a hex dump! The -p or -da options may be useful.

SQLite
https://github.com/bitcoin/bitcoin/pull/19077 says

This PR adds a new class SQLiteDatabase which is a subclass of WalletDatabase. This provides access to a SQLite database that is used to store the wallet records. To keep compatibility with BDB and to complexity of the change down, we don't make use of many SQLite's features. We use it strictly as a key-value store. We create a table main which has two columns, key and value both with the type blob.

...

We keep the name wallet.dat for SQLite wallets. We are able to determine which database type to use by searching for specific magic bytes in the wallet.dat file. SQLite begins it's files with a null terminated string SQLite format 3. BDB has 0x00053162 at byte 12 (note that the byte order of this integer depends on the system endianness). So when we see that there is a wallet.dat file that we want to open, we check for the magic bytes to determine which database system to use.

I'm using current Bitcoin core 0.21.0, but the wallet I examined was first generated in 2018 and has the Berkeley DB (BDB) signature. Bitcoin core has not rewritten the file in a newer/different format.
https://github.com/bitcoin/bitcoin/issues/20160 provides a timeline for the phasing out of Berkely DB (which obviously affects the contents of this answer)

Wallet.dat
My brief examination of a wallet.dat backup using a hex-dump suggested that the wallet mostly contains private keys, addresses generated and some sparse metadata about each.
See also

dumpwallet output documentation & explanation? (2021 and relevant)
What do the different .dat files contain? (2011, ∴ limited usefulness)
File format -- rev*.dat (2017, interesting but different file)
What is the database for? (2013, ∴ limited usefulness)
UXTO DB structure (2017, not relevant but interesting documentation)

wallet.dat contains your private keys, your address book, a copy of the transactions that send coins from or to one of your addresses, accounts, reserve keys, personal settings, and a pointer to the current best block.

(Note: Bitcoin core's "accounts" feature was deprecated some years ago)

New wallets are using SQLite, since the OP mentioned it they probably using that so i doubt a Berkeley DB tool would work for their use case

@darosier, AIUI Bitcoin core uses different libraries for the wallet file than for the other files. https://github.com/bitcoin/bitcoin/issues/20160

I ran db_dump on the already backed up wallet.dat (sqlite) and it did dump some interesting info ie. I the name of the db 'main' and the keys. I guess thats pretty much all there is in the wallet..? Was hoping to see a visual depiction of the db. I haven't marked this answer as correct yet as I still would like to know which password / key the browser is wanting

@leo: I'd guess it needs the password used to encrypt the key values (if you protected the wallet.dat with a password) But I don't know if Bitcoin Core uses some global encryption provided by the DB library or whether it applies its own encryption to the relevant value contents only (I thought it was the latter but don't actually know for sure). I surmise SQlite might be asking for a global DB password which doesn't apply, might be doing so because it is confused or might be doing so because it wants you to decide if one is needed. I'm not familiar with SQlite


text:
Read block info from log
I'm new in the Bitcoin world, but I want do the script. The script will read "blocks" from debug.log, but now when I looking to a debug.log I don't see anything about blocks. Is it possible?
Here is example from my log:

[D:2020-04-13T18:58:49Z] (mempool) Added 30e28c7a2ad288fa3457569423b388f43e0b874032dd14c8bfc1db49777c6746 to mempool (txs=3182).
[D:2020-04-13T18:58:50Z] (net) Requesting 1/1 txs from peer with getdata (131.188.40.191:8333).
[D:2020-04-13T18:58:50Z] (mempool) Added 0ee02ea46ea6c06a3c0addcf651612f8681272310f583f2bd3f273d0c14c3cf0 to mempool (txs=3183).
[D:2020-04-13T18:58:50Z] (net) Requesting 6/6 txs from peer with getdata (194.15.231.236:8333).
[D:2020-04-13T18:58:50Z] (mempool) Added 86e5a85abc674e432aeffef3876772ea8588dc2cdab79ed236041b8875a171e7 to mempool (txs=3184).
[D:2020-04-13T18:58:50Z] (mempool) Added fc5c9d831785b1e43b0f9adb4333d7ed23562b332a061f958f7f98dcd5397043 to mempool (txs=3185).
[D:2020-04-13T18:58:50Z] (mempool) Added 5742cd2c1f376720596ee0256ca825b2940cf22b7b6e681c3666b46fb72fe144 to mempool (txs=3186).
[D:2020-04-13T18:58:50Z] (mempool) Added e8222822f1fba4fb8dd4d2aa60e6d42b38f2ef35c98e09f81961d72c4502beb1 to mempool (txs=3187).
[D:2020-04-13T18:58:50Z] (mempool) Added 123d121ec06bf8cfaeefb5ba25ed303fa82ee75e8179452cfb4be80d7cfd7161 to mempool (txs=3188).
[D:2020-04-13T18:58:50Z] (mempool) Added 59b40a817ffc223361ec07874abb889d0769c8bb6155cb6cdf175680221a0f77 to mempool (txs=3189).

What is "the script"?

debug.log is just a software level log; you should not rely on it for any serious data, as it offers no actual way to verify anything

when I looking to a debug.log I don't see anything about blocks. Is it possible?

I expect the net category of log information should contain entries relating to the exchange of blocks with peers but I would not expect the full block data to be logged.
The name of the debug log suggests it is mainly intended as a way to investigate problems, and not intended as a means to routinely extract block data. You should use the RPC API for that.

Related

What are the debug categories?
API reference (JSON-RPC)
getblock


text:
How to check if one transactions is from the same wallet (public key) as a previous one
I wonder how to figure out whether one Bitcoin transaction is from the same wallet (public key) as any previous transaction in order to proof the ownership of a wallet.

Could you be more precise ? Are you looking for a wallet footprint or a public key reuse ? Wallet tend to, actually, not reuse publeys.

Hi Homer, this sounds like a bit of an XY-question: you seem to ask about a solution approach for a problem you are trying to solve rather than the problem itself. What are you actually trying to achieve for which you want to know whether the same wallet paid twice?

Hi all,
I want to identify a sender by transactions, i.e. to compare two transactions and and find out whether the two transactions are from the same sender (wallet). It is for a proof of ownership to register a wallet and then in the future check if subsequent transactions are from the same sender (wallet).

If the transaction in question consumes inputs that were locked to a bitcoin address that has been previously used, then it would be easy to tell that the payment came from the same wallet. After all, the payment came 'from the same address' as a previous payment.
However, re-using addresses is not best practices. Doing so is very bad for your privacy, just consider the premise of this question to understand why! There is no reason to re-use addresses and thus allow someone to see your financial history (ie, all of the other transactions you've made from that address).
Thankfully, modern wallets are built to never re-use addresses. Further, addresses from the same wallet are indistinguishable from random addresses, there is no public information included in the address/transaction that links them together. This is by design: you wouldn't want someone to be able to determine your entire wallet balance, after receiving a single transaction from you.

Hi chytrik. Thank you very much for your answer and explanation. What exactly do you mean in paragraph 1 of your answer? Thank you.

link
Could that solve my problem?


text:
Transaction parsing - Satoshi value
how exactly is the satoshi value in a raw transaction calculated to decimal? Because on blockchain.info, I cannot figure out how they parse the raw transaction from that value to the JSON result. I thought it would be just a hex to decimal parsing, but I cannot get the same results. Neither I understand it in here, how you get to 49.99990000 BTC (from https://developer.bitcoin.org/reference/transactions.html):
Sorry if it's a silly question.

The amount is encoded as a little endian signed 64 bits integer.
Here is how you would decode your sample in Python:
>>> int.from_bytes(bytes.fromhex("f0ca052a01000000"), "little")
4999990000


text:
90% confidence interval for mining a block?
I did some math and found that the 90% confidence interval for bitcoin blocks is that the block will take less than 1381.6 seconds. I used the calculation ln(10)*600 with 10 being used because a 90% confidence interval means one in ten blocks are expected to fall outside of this range. Could this be considered a 90% confidence interval?
Note: this could change if the difficulty is expected to rise or drop. If block time is 576 seconds, for example, it becomes a 91% confidence interval. In practice this changes a lot once the difficulty adjustment has passed.

Note that the network difficulty is only retargeted every 2016 blocks, so any changes to the amount of hashpower pointed at the network in between retargeting events will alter the effective confidence interval. Historically, hashrate has increased on average, and thus we may expect the measured result for the 90% confidence interval to be less than predicted, on average.

I don't think you understand correctly the definition of a confidence interval. It is a range of values where you can be e.g. 90 percent confident the interval contains the population mean. Typically you will calculate the confidence interval using sample data e.g. sample mean, sample size. You have not given any sample data. Instead we know the population mean assuming constant hash rate. It is 10 minutes. Hence I have given quantiles of the exponential distribution below in my answer.

Bitcoin blocks are mined according to a Poisson process with a mean of 10 minutes (600 seconds) if you assume constant network hash rate. The difficulty of mining blocks gets adjusted every 2016 blocks to address this variability.
Interarrival times of a Poisson process are exponentially distributed.
The 95th quantile of an exponential distribution with a parameter of 1/600 is 1797.4
The 5th quantile of an exponential distribution with a parameter of 1/600 is 30.8.
90 percent of the time an observation from an exponential distribution will fall in the interval of (30.8,1797.4) seconds
The median time is 415.9 seconds.

Ln doesn't make sense, you need to use gamma distribution. On https://keisan.casio.com/exec/system/1180573218 with 0.95, 2, 10 I get 47 minutes.

It said 90 not 95.

@NumberFile Hence I wrote 0.95. On https://www.simplypsychology.org/confidence-interval.html as you can see for 5%, 2.5% is on the right 2.5% is on the left. If he had said 80% interval I would be doing 90% for the upper bound and 10% for the lower bound.


text:
How to generate btc addresses from XPUB?
I have an xpub key and I'd like to generate the sequence of btc addresses in PHP based on the index.
Is there a way to do that?

An extensive public key (XPUB) is a sort of different evened out deterministic (HD) wallet key that licenses you to deliver a boundless number of bitcoin addresses from a singular master key. This can be useful on the off chance that you want to make a new bitcoin address for each trade then again to manage endless bitcoin addresses.
To deliver a bitcoin address from a XPUB, you can use a gadget, for instance, the bitcoin-cli request line interface or a programming library like BitcoinJS. Here is a representation of how you could make a bitcoin address from a XPUB using the bitcoin-cli request line interface::
1-Regardless, guarantee you have the bitcoin-cli instrument presented on your structure.
2-Open a terminal window and enter the going with request to communicate with your bitcoin center point:
--      bitcoin-cli -regtest   --
3- Next, use the getnewaddress command to generate a new bitcoin address:
--      bitcoin-cli -regtest getnewaddress   ---
4- This will return a new bitcoin address that you can use to get portions. To make additional areas, you can use the deriveaddresses request, which acknowledges a XPUB as a conflict and delivers an overview of addresses:
bitcoin-cli -regtest deriveaddresses "xpub6DU6JYBvfZjSJgUJpMh6FiZbvL3Bd4ZxAZuvZQgcCv5vY3qrWj5J35Q2K5zAKvZ8XaZxJpZcPJGmrgvw8HJWfjHRBJ1MgvMYdJzW5xp8Gv"
This will create a summary of 10 areas considering the XPUB that you gave. You can change the amount of addresses made by using the count limit:

Hi Rafi, I'm confused by this answer. It's not clear to me what the “areas” are that you start talking about in the latter part of the answer, and the question was about PHP, which your answer never mentions. Would you mind looking it over one more time?


text:
How do we know that a certain hash below the target is even possible when mining?
If the target hash were artificially low, i.e. 3, how do miners know if there will ever be a nonce that produces such a hash?

Possible duplicate of https://bitcoin.stackexchange.com/q/9933/5406, https://bitcoin.stackexchange.com/q/22978/5406

If the target hash were artificially low, i.e. 3, how do miners know if there will ever be a nonce that produces such a hash?

They don't.
However if the difficulty were ever such that miners were unable to mine new blocks at the expected rate (1 every 10 minutes approximately), the difficulty algorithm would reduce the difficulty after a while (up to 2 weeks if I remember correctly)

The difficulty resets every 2016 blocks by a factor in the range of 0.25–4. So we'd be a bit in a predicament if we couldn't mine blocks at all anymore. ;)

@Murch Yes. I suspect it would take an unprecedented and unforseeable worldwide catastrophe of extraordinary rapidity to get into this situation in the first place.

You try all 2^32 possible nonces. On realistic mining hardware, that takes a very tiny fraction of a second. Of course, most of the time there is no nonce that works. Mining is so hard that all the miners combined only find a block that has any nonce that meets the difficulty once every ten minutes.

For a given block header where the only variable is the nonce, it is trivial to brute force all nonce values and verify if any gives a hash that meets the target.
For the vast majority of block hashes, no nonce value will meet the target in normal difficulty settings (let alone at a target of 3).
Miners get around this by altering other values in the block header, such as the timestamp, block version, merkle root (via altering of the Coinbase transaction and/or set of included transactions).
By the balance of probability, you will eventually find one block header for some combination of the above that meets the target.
The difficulty levels control how likely it is for that block header to be found in ~10 minutes for a given hash rate.
The Bitcoin Wiki elaborates on how the calculation is actually performed to determine this difficulty, along with some example code.


text:
BIP-330 test cases
Are there any test cases for BIP-330 "Transaction announcements reconciliation"? More specifically, I need some test cases for the serialization/deserialization of the new p2p messages, something like a byte-array of the data and what it should look like after parsed. I couldn't find it in the BIP or in the PRs.


text:
How to create watch-only wallet on a server with a full node?
Given: there're online shops and a server with a full BTC node that I plan to run. I'll be using a full node to monitor incomming transcations thus receiving payments in an automatic manner. Only. Namely, a customer will see a result of his payment in, at most, 10 minutes.
Question: How can I create a wallet that's receive-/watch- only, that'll have to stored on a server?
That is, if a server gets broken into, a hacker won't be able to do anything with a wallet he steals, later on. But I will be because a private key will be stored on my local computer. I'll login into a server once a week and withdraw the funds from a wallet.
--
I don't consider any other - paid, free, open source - ready solutions. The question isn't about a solution to receive BTC payments.

What's the question?

You can install Bitcoin core and import an address as watch only, then you can track all transactions.

how import an address as watch only?

@kosmosu05 Very simple, into console type importaddress "address"

Maybe the following article can help you:
https://bitcoinelectrum.com/creating-a-watch-only-wallet/

that doesn't help me


text:
Investing in cryptocurrency in India
Question: My friend in India wants to start investing in cryptocurrency such as bitcoin. I have a few questions. What is the current legality of cryptocurrency in India? What exchange should he use? What wallet app should he use (should support main popular coins)?

Crypto was declared legal in India, earlier this year by the Supreme Court. That being said there are no legal frameworks/regulations right now by the government.
WazirX is one popular exchange in India. Haven't used it though.

mentioned that haven't used it, therefore got no idea.


text:
Bitcoin-cli responding but not curl
According to the bitcoin documentation I can make curl calls to my bitcoin node. However, whenever I run a curl command like the following (as per the docs):
curl --data-binary '{"jsonrpc": "1.0", "id": "curltest", "method": "getbestblockhash", "params": []}' -H 'content-type: text/plain;' http://127.0.0.1:8332/

I get no response. But when I run the bitcoin-cli edition:
bitcoin-cli getbestblockhash

I get a response.
So what is the difference? What am I missing?
I've seen this and this but they were never resolved.

Found it out, you just need to give it a username and password. You can add them to a bitcoin.conf file in your datadir. This file isn't automatically created. The default datadir is at ~/.bitcoin, so you can make a ~/.bitcoin/bitcoin.conf
rpcuser=user
rpcpassword=pass

Additionally, if you'd like, you can later pass your username and passwords as URL parameters, like so:
http://user:password@IP_ADDRESS:PORT

Keep in mind that the configuration file is not automatically created; you can create it using your favorite text editor. By default, the configuration file name is bitcoin.conf and it is located in the Bitcoin data directory, but both the Bitcoin data directory and the configuration file path may be changed using the -datadir and -conf command-line options. Also, do not forget to set the appropriate file permissions and restart the bitcoind.


text:
How to split a Bitcoin Core wallet
I have an 'omnibus' wallet.dat which holds balances for multiple parties which I would like to disentangle and split. The UTXOs are not blended, each UTXO is owned by a given party in whole and there  has been no key reuse throughout the wallet's life. It is not an HD wallet.
Q) What is the best way to 'fork' this wallet into multiple new wallet files, one per party, such that I can retire/deprecate (obviously not delete) the old wallet, while still propagating the same UTXO states and transaction histories into the new wallets?
This is a question about delicate wallet manipulation without any on-chain activity.
I have tried dumpwallet to obtain the list of keys+addresses, separated the relevant ones manually and then used importwallet on each resultant file into a new wallet.dat for each. This sometimes loses address labels, and seems to adjust the transaction timestamps versus the original file. There is apparently some metadata lost in the transfer, is there a better method for what I'm trying to achieve?


text:
Confused about LND derivation of node's payee pubkeys
Okay. A short summary of the problem: I'm trying to derive the root key from LND from the aezeed, but I can't get it right.
Assume the following seed (aezeed):
ability quality bulb clap quality piano focus ivory trust essence improve book antique analyst double equip reason venue jazz zoo host potato harvest divorce

For which the following root keys result:
tprv8ZgxMBicQKsPct7CvypLfrMHfanE3cmTwZuy8QTGNgzFZKSqFeXXinsuKvkyMe6DbqdGMu8Xp1fon8E3mgW62RiorqMv6qLV2dqPFX3pETp
xprv9s21ZrQH143K24sgGQxqWCjJMTN1p6jTc1zrFz2otiVmmihkGHBnD3WTQkbKMGhuEQ6VMoWmef61KGgJeUA9DNTDLC9cSUcS7Y5xos3tfBr

To check if these are correct, we derive the node's payee key (identity pubkey), which is m/1017'/0'/6'/0/0
results in 03bb9f9f7734ca9da4ec06543d32456384f878303305a72979e7316825e00749ad
the problem is; the above seed results in 039e625ffe5325224e6273fc5e0afe59f7ec82cb90add45e76f34cfff9efdcac60
(as per LND's getinfo)
Anyone who can spot my mistake?

Wrong cointype. I'm assuming mainnet = 0, and testnet = 1,  although I can't find any documentation on this.
m/1017'/1'/6'/0

gives the correct identity key.


text:
What RBF policy will be default on SegWit v1 nodes?
What RBF node policy will be applied by default in order for a SegWit v1 transaction to relay when encountered. Full RBF, or Opt-in RBF?

As far as I'm aware, there are currently no formal proposals to introduce Full RBF. Therefore, I'm expecting that the default behavior of upcoming nodes will remain to forward and create transactions according to the rules specified in BIP125, Opt-in RBF.