text:
Sent 95BTC to my client from Mt.Gox and it never showed
I have had Bitcoin for some time now, but am relatively inexperienced. I have a Mac client, and yesterday sent 95BTC to it from my Mt.Gox wallet but it never arrived. I sent Mt.Gox a message asking for help they told me it would arrive when I reached block 160319 and my client is just at 124667 and not connecting at all! I can't get it to connect, have tried various suggestions from forums but can't make it work, please help! thanks

First, calm down - your money is safe. Not sure why you're client is not connecting - I believe there is a question on this site that already explains this. The BTC will only show up on your account when you reach the correct block count.

Other question with connection problems on a Mac: Bitcoin client won't connect to the network. I'd say this is a duplicate of that.

Can I ask to the @user858 user858 to please tell us the end of history, this helps to spread a word (good or bad).

If you are not sure if your wallet balance is okay, search for your address in the Block Explorer. If you see your coins there, they are safe. I'm guessing it's this address, so everything should be fine.
Make sure your client is up-to-date. If it is too old it might not be able to communicate with the network. (remember to backup your wallet.dat beforehand)
If your updated client can't connect to the network (0 connections), check out this topic.
If your client is connected to peers, but after an hour you don't see any block progress, try closing down the client, deleting blk .dat files from your Bitcoin data directory, and then starting it again.
When you see your block count progressing, be patient. Leave your computer running the client over night. The procedure takes awhile, as Bitcoin needs to download and verify over 1GB of data.

If all else fails, you can try redeeming your wallet at MtGox (remember exactly if this is the only service providing this functionality) and using an online wallet service, like StrongCoin, to never have to deal with the problem again.


text:
What incentive is there for a miner to not include a bad transaction?
'A' has got 1BTC legitimately. He sends out a transaction to transfer that one bitcoin to 'B' with a 1BTC transaction fee added on. (i.e. a bad request.)
'C' is a miner who cares nothing for integrity of the bitcoin system and only cares about winning blocks and selling the BTC he gets as soon as he can.
What incentive does C have to pass on the free 1BTC and not include A's transaction when putting the next block together?

Could you point us in the right direction regarding why you consider this transaction 'bad'? It doesn't make much economic sense, but assuming signature checks out.. it is a valid way to spend money..

'A' would be spending 2 BTC, but he only has 1.

Actually, such a transaction would still be spending '1BTC', with 'B' receiving 0BTC

I see, the fee is subtracted from the value being sent? I've edited the question to make it clear the fee is added to the initial 1BTC. Thanks.

Any block that contains an invalid transaction will be considered invalid as a whole, and every other peer/miner will reject it. A miner must check that every transaction included in a block is valid, otherwise there is a high risk that all the hard work required to solve the block is just being wasted.
Any miner who disobeys the validity requirements (by considering some invalid block as valid, or some valid block as invalid) will be completely disregarded by the rest of the network, defeating the point of any mining activity.
Note: Sending 1BTC with a fee of 1BTC is a perfectly valid transaction (even though it might be a mistake by A). Of course, doing that, A must own 2BTC and give them away, or the transaction can't possibly be valid.

If a miner includes a bad transaction (in your example, a person sending more BTC than they actually have), then the block will not be concidered valid by other bitcoin nodes and miners.  That means the block will not be built upon by the blockchain, and the miner will lose out on the 50 BTC generated from that block.

You are right.  If a large group of people agreed to change the rules, it would just fork the blockchain and normal people would ignore the forked chain.

source: Stack Exchange

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

sort: votes


text:
How do MuSig2 and FROST compare for multisig key aggregation schemes?
Although FROST is primarily for threshold (k-of-n, k<n) key aggregation schemes (and MuSig2 doesn't support threshold) FROST can support multisig (n-of-n) key aggregation. So what are the upsides and downsides to both for multisig and when might you use FROST over MuSig2 for multisig?

You would generally use MuSig2 for multisig key aggregation as it has fewer communication rounds (2) and less complexity than FROST. The additional complexity is illustrated in this graphic (shared by niftynei on Twitter).

The MuSig2 paper (Nick, Ruffing, Seurin) also states:

In comparison, the scope of our work is restricted to only “n-of-n”
multi-signatures, which enables us to optimize for this case and
achieve properties which, in the pure DL setting, are unique to
multi-signatures, namely non-interactive key generation as well as
non-interactive public key aggregation, two features not offered by
FROST. A major difference between our work and their work is the
cryptographic model. The FROST security proof relies on a non-standard
heuristic which models the hash function (a public primitive) used for
deriving the coefficients for the linear combination as a one-time VRF
(a primitive with a secret key) in the security proof. This treatment
requires an additional communication round in FROST preprocessing
stage and to disallow concurrent sessions in this stage, resulting in
a modified scheme FROST-Interactive. As a consequence, the
FROST-Interactive scheme that is proven secure is in fact a
three-round scheme and as such differs significantly from the
two-round FROST scheme that is recommended for deployment. Komlo and
Goldberg [KG20] show that the security of FROST-Interactive is implied
by the DL assumption. In contrast, our MuSig2 proofs use the
well-established ROM (or alternatively, AGM+ROM) to model the hash
function as a random oracle and rely on a falsifiable and weaker
variant of the OMDL assumption.

However, Jesse Posner highlighted a couple of benefits of FROST over MuSig2 at this Sydney Socratic. With FROST you can swap out public keys for other public keys or change the multisig scheme, say from a 3-of-3 to a 2-of-2 without needing an onchain transaction. (To do the same with MuSig2 would need an onchain transaction and MuSig2 does not support threshold if that is what you wanted to convert to.) So if you wanted to do this this might be a reason to use FROST over MuSig2.
Correction (June 2023): What is possible with regards to modifying FROST signers and the threshold is discussed in this Nick Farrow gist.
This was also discussed in this London BitDevs Socratic with Tim Ruffing and Elizabeth Crites. It is complicated by there being competing distributed key generation schemes and potentially different FROST standards between Bitcoin/BIPs and IRTF.

TR: I’m also not sure what Jesse is talking about here. I think in the pull request there were some discussions. What you certainly can do, you can downgrade n-of-n to k-of-n. This has been discussed. For example swapping out a key to a new key, maybe Elizabeth knows more, there are some key resharing schemes, I’m not really aware of those.
EC: Yeah. That’s what I was saying about doing the distributed key generation again. Say you run distributed key generation once and everybody has their secret shares of the overall group key. At least the DKG that is used in conjunction in FROST, the original one which is what we prove in our paper, it is based on Shamir’s Secret Sharing. There are some pretty standard ways to reshare using Shamir. That is possible. It is still non-trivial.
TR: You can do resharing but it is more like a forward security thing. You can’t reshare to an entirely new group of signers. You would still trust the old group of signers.
EC: You can transition from some group of signers to a new group of signers also. There are ways to reshare the keys. Or you can keep the same group and reshare a sharing of zero so your shares essentially stay the same, same group, or you can switch the group of signers. But it does involve performing the resharing. There’s a little bit that has to be done there.

MuSig2 and FROST could be used together in the same scheme. There could be a nested MuSig2 setup within a FROST setup or vice versa. Additionally if you wanted to move from a MuSig2 setup to a FROST setup MuSig2 keys can be converted to FROST keys without changing the aggregate public key. That is discussed here.

FROST also has two rounds. And that figure is completely nonsensical (just compare it to the FROST spec, nothing in the figure is in there, which is also very apparent by the figure mentioning "musig"), FROST is not significantly more complex than MuSig2.

@Conrado: The FROST signing protocol is two rounds but FROST requires interactive key generation in addition that MuSig2 doesn't. I think it is fair to say FROST is more complex than MuSig2, we could quibble on whether it is "significantly" more complex.

That's true, but when people talk about number of rounds in a protocol they are usually referring to the signing rounds. And sure, it depends on your definition of complexity, but the figure is still terribly misleading.

you can just use regular pre-commitment rounds.   frost saves one round with a lot of complexity.   having all participants commit to their public key and verify all other participants (standard pederson commitments) - probably ok

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


text:
How do the various Lightning implementations treat latency? How long do they wait for a peer to provide a signature before using unhappy path?
Rene Pickhardt brought up the problem of latency on the Lightning Network in this answer on using nested (or "recursive") MuSig2 or FROST when providing a signature within an existing Lightning channel or to cooperatively close a Lightning channel.
(This could be done once the Lightning protocol supports Schnorr signatures even if the 2-of-2 multisig between the channel counterparties that is funded at the opening of the channel remained 2-of-2.)
How to treat latency isn't spec'ed in the BOLTs. So how do the various Lightning implementations currently treat latency? How long do they wait for a peer to provide a signature before assuming the peer is unresponsive and instead using an unhappy path? This would give an upper limit on how long the MuSig2 or FROST protocol could (currently) take to generate a valid signature if they were used in this use case.

This was discussed on the lightning-dev mailing list.
Christian Decker stated:

It is worth mentioning here that the LN protocol is generally not very
latency sensitive, and from my experience can easily handle very slow
signers (3-5 seconds delay) without causing too many issues, aside from
slower forwards in case we are talking about a routing node. I'd expect
routing node signers to be well below the 1 second mark, even when
implementing more complex signer logic, including MuSig2 or nested
FROST.
In particular remember that the LN protocol implements a batch
mechanism, with changes applied to the commitment transaction as a
batch. Not every change requires a commitment and thus a signature. This
means that while a slow signer may have an impact on payment latency, it
should generally not have an impact on throughput on the routing nodes.

That doesn't mean that routers shouldn't strive to be
as fast as possible, but I think the MuSig schemes, executed over local links, is unlikely to be problematic when considering overall network
latency that we have anyway. For edge nodes it's rather nice to have relaxed timings, given that they
might be on slow or flaky connections, but routers are a completely
different category.

Matt Corallo added:

In general, and especially for "edge nodes", yes, but if forwarding nodes start taking a full second
to forward a payment, we probably need to start aggressively avoiding any such nodes - while I'd
love for all forwarding nodes to take 30 seconds to forward to improve privacy, users ideally expect
payments to complete in 100ms, with multiple payment retries in between.
This obviously probably isn't ever going to happen in lightning, but getting 95th percentile
payments down to one second is probably a good goal, something that requires never having to retry
payments and also having forwarding nodes not take more than, say, 150ms.
Of course I don't think we should ever introduce a timeout on the peer level - if your peer went
away for a second and isn't responding quickly to channel updates it doesn't merit closing a
channel, but its something we will eventually want to handle in route selection if it becomes more
of an issue going forward.

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


text:
In MuSig2 how is multiplication of coordinates defined?

In the MuSig2 paper each signer multiplies all the nonces together (in the naive version):

R_1 * R_2 * R_3 * .... R_n

where R_i = r_i * G. r_i is a scalar and G is the generator point (coordinate) hence R_i is a coordinate.
And all the public keys (coordinates) are multiplied together:

X_1 * X_2 * X_3 * .... X_n

Is the multiplication (over the cyclic group) defined here by multiplying the x cooordinates together and multiplying the y coordinates together?
e.g. (x_1, y_1) * (x_2, y_2) = (x_1 * x_2, y_1 * y_2)
It is not like the bytes() function in BIP340 is used where a coordinate is turned into a scalar by taking the x coordinate, the x coordinates are multiplied together and the y coordinates are dropped (the final y coordinate could be calculated later I guess from the final x coordinate)?
edit: I looked up the KeyAgg function in the MuSig2 (secure version) draft BIP and that states the aggregated key isn't calculated by multiplying the public keys, instead they are added with unique coefficients. I'm confused. Have we moved from a product (naive version) to a sum with unique coefficients (secure version)?
Q = a1⋅P1 + a2⋅P2 + ... + au⋅Pu

TL;DR: the multiplication operation you're asking about is actually what you're used to seeing referred to as point adition (when talking about elliptic curves).
The MuSig2 paper does not assume you're using an elliptic curve group, or even assume the objects operated on have a notion of "coordinates". The scheme is generic, and works for any cyclic group in which the discrete logarithm is assumed to be hard. That can be instantiated with an elliptic curve group like secp256k1, but it also works with very different groups.
Specifically, that means:

We need a finite set of elements, containing at least a "neutral element" o and a "generator" g.
There must be a function defined for all elements that takes two arguments; because its name and notation doesn't matter, we'll call it "blah(x,y)".
For any x,y in the set, blah(x,y) is also in the set.
For any x,y in the set, blah(x,y) and blah(y,x) are the same.
For any x,y,z in the set, blah(blah(x,y),z) = blah(x,blah(y,z)).
For any x,y in the set, there exists an element a in the set such that blah(x,a) = y.
For any x in the set, blah(x,o) = blah(o,x) = x.
Every element in the set can be written as blah(blah(blah(o,...),g),g), for some finite number of calls to blah, but given a random element x in the set, it must be hard to find how many g's need to be blah'ed together to obtain x.

This is all. If we use secp256k1 (or any other elliptic curve group) then we use the points on the curve as the set, the point at infinity as o, the secp256k1 generator as g, and the elliptic curve point addition formula as blah(). Repeated blah'ing in this case is denoted as a multiplication between the number of blah's and the point being blah'ed.
But the whole scheme can also be instantiated for other groups in which these properties hold, with different bandwidth/computation/security tradeoffs. For example, it's possible to use multiplication modulo a very large prime p. In that case o is the number 1, g is for example the number 2, blah is multiplying two numbers together modulo p, and repeated blahing is raising a number to a power modulo p.
And thus, the MuSig2 scheme, when described sufficiently abstractly, works on any such group. The same is true for Schnorr for example: BIP340 is an instantiation of the Schnorr signature scheme over the secp256k1 group, but Schnorr himself originally described it to operate on just integers modulo a prime.
This leads to a practical problem: if the scheme is generic, and works over any group with certain properties, how do you write it down? People working on elliptic curves are used to writing the group operation blah() as "+", and people working on integers are used to writing this operation as "*".
So what happens is that some authors choose one, and others use the other, depending on their background. Among Twitter cryptographers there are often heated (but usually friendly) arguments about which is better. And in the end, it doesn't matter - it's just notation. Both "+" and "*" work fine, as we just need a single operation, and both are much more readable than "blah()".
BIP340, BIP32, and many other BIPs and descriptions of the cryptography in Bitcoin, use "+", or additive notation, for the group operation, and "*" for repeated use of it.
MuSig2, as well as many other cryptography papers (but not all) use "*", or multiplicative notation for the group operation, and "^" for use of it. This is where the name "discrete logarithm problem" comes from. In additive notation, for consistency, we ought to be talking about the "discrete division problem".
To see the correspondence, BIP340 (in additive notation) uses equation sG = R + H(R || P || m)P for valid signatures. Using multiplicative notation it would instead be Gs = PH(R || P || m)R, but this is just a notation choice - both describe exactly the same thing.
So in short: the multiplication operation you're asking about in the MuSig2 paper is just what would more commonly be referred to as elliptic curve point addition in Bitcoin-specific context. Multiplying the individual coordinates together is not a valid operation; this will generally not yield a point on the curve again.


text:
Check an outpoint's scriptPubKey against known scripts
So I would like to check if coin.out.scriptPubKey is part of GetScriptForDestination(mypubkey.GetID())
A simple comparison isn't possible as the scriptPubKey (when I decode it) contains only the native SegWit address while the output GetScriptForDestination() will return all associated addresses.
Is there a nice and clean way to do this or do I need to work my way through?

GetScriptForDestination in the current Bitcoin Core source code returns a single script. There are no witnesses in scriptPubKey. I don't understand your question.

yes, my abilities to describe problems are pretty poor. if I decode the output of GetScriptForDestination, it contains all from legacy to native segwit. so I can't compare it directly to the scriptPubKey if I want to check if the Coin matches the provided key

I still don't get it. GetScriptForDestination only returns a single script, not all associated addresses (unless you're not talking about Bitcoin Core's current codebase).

Well, if you don’t get it, I may be up to something here. The codebase I am talking about is the current Core’s master branch. Actually the same thing I am doing now was working perfectly before, so I (maybe wrongfully) assumed that this comparison is now failing because on the old test and on live environment there was always at least one legacy prevout involved, now I am doing things on a plain SegWit environment, starting from coinbase. Definitely the scriptPubKey and the output from GetSctiptForDestination(mykey.GetID()) aren’t equal. The latter contains the first one though if I decode it

GetScriptForDestination(mykey.GetID()) will give you the script corresponding to the P2PKH address for that key. If you want the P2WPKH address, use GetScriptForDestination(WitnessV0KeyHash(mykey.GetID())). GetScriptForDestination always returns just a single script, though.


text:
bitcoind > 0.9 - unexpected end of data - handling of arbitrary data in tx - UPDATE
I'm working on a pretty old blockchain here which was based on codebase 0.9 and never updated since. Now getting that stuff to a proper codebase, I'm facing following situation on initial block download:

Downloading headers is working fine, all block headers accepted
then, during the actual block download, always at the same height, we are throwing an exception at streams.h line 352: throw std::ios_base::failure("CDataStream::read(): end of data");

UPDATE
The block in question got 12 additional bytes appended to a standard transaction. Actually I thought from 0.9 this should not have been possible anymore since OP_RETURN was introduced. But afaik similar things happened in earlier bitcoin versions.
(general) Q: How did Core "fix" this issue as data is supposed to persist in the blockchain? e.g. How are newer clients treating it?
Q: Is there an example of a similar transaction on the Bitcoin blockchain (prior 0.9, I was only able to find the OP_RETURN examples)?

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


text:
Synchronize mempool between 3 nodes
Three bitcore nodes (version of bitcoind is quite old - 0.12.1) are deployed to the servers on different cloud platforms.
All instances have the same bitcoin.conf files (except of rpcallowip, rpcuser and rpcpassword):
server=1
whitelist=127.0.0.1

txindex=1
addressindex=1
timestampindex=1
spentindex=1

zmqpubrawtx=tcp://127.0.0.1:28332
zmqpubhashblock=tcp://127.0.0.1:28332

rpcthreads=8
rpcworkqueue=32
rpcservertimeout=60
rpcallowip=127.0.0.1
rpcuser=...
rpcpassword=...
uacomment=bitcore

The problem is all of them have considerably different mempools:

first has 33689 txs in mempool
second has 58219 txs
third node has 39540 txs
blockchain.info has 63598 txs

I understand, that mempool is node-specific and there is no "Single Bitcoin Network Mempool". However I need synchronization at least between these three nodes (though it would be better to be as close to blockchain.info as possible).
If there is transaction, that exists in blokchain.info's mempool, but doesn't exist in all three nodes' mempools - it is ok. But as soon as this transaction get to one of these three nodes, it should appear on others as soon as possible.
I've tried using addnode option to force nodes connect to each other, but it didn't helped.
May be I am missing something, or at least there is a way to find the reason of so big differences in mempool ?

Aim of consistent mempool.
We have mobile client and application server, all looking into these nodes (some kind of load balancing). User can be logged into one account on different devices. When server sees transaction in mempool, it should update user's status.
When mempools differ it is possible, that:

User will see different transactions on different devices, which may mess him
User will see transaction, and server will miss it. In such situation user expects, that status will be updated, but server wouldn't do it

So it would be very nice, to have (almost) equal mempools.

So far.
I've tried:

addnode (to connect to specific nodes)
connect (to connect only to specific nodes), to give it a try, thanks to @whatever

This options were described here, on bitcoin.se, and (alongside with other possible options for bitcoind) in bitcoin wiki. But there is still problem with big difference in mempool's size.

It would probably be helpful if you told us what problem you're trying to solve by synchronizing the mempools.

Use this: https://github.com/dev7ba/mempoolcp

You can force mempool synchronization by running a script which connects to the RPC ports, fetches transactions from one node's mempool, and sends it to the other nodes. Note that because this uses RPC, it will be fairly slow and will still result in some mempool desynchronization. You will probably want to run this script periodically. Here is an example in python using python-bitcoinrpc.
Note: I have not tested this
from bitcoinrpc.authproxy import AuthServiceProxy, JSONRPCException

# rpc_user and rpc_password are set in the bitcoin.conf file
nodes = []
NODE1_URL = "10.10.10.1:8332"
NODE2_URL = "10.10.10.2:8332"
NODE3_URL = "10.10.10.3:8332"
nodes.append(AuthServiceProxy("http://%s:%s@%s"%(rpc_user, rpc_password, NODE1_URL)))
nodes.append(AuthServiceProxy("http://%s:%s@%s"%(rpc_user, rpc_password, NODE2_URL)))
nodes.append(AuthServiceProxy("http://%s:%s@%s"%(rpc_user, rpc_password, NODE3_URL)))

for node in nodes:
    txs = node.getrawmempool()
    for tx in txs:
        rawtx = node.getrawtransaction(tx)
        for b_node in nodes:
            b_node.sendrawtransaction(rawtx)

What this does is it fetches a list of transaction ids in a node's mempool. Then it fetches each transaction and broadcasts them through the other nodes. It does this for each node. This, in theory, ensures that all of the nodes will have the same transactions in their mempool.

This is the approach i'm using to keep a fresh mempool between two nodes when I have to reboot one of them or send the whole mempool to a new one. But I've found that the transaction set it's not the same between them. One lacks some transaction from the other. The more times you execute this script (or equivalent) the more the two sets are the same. The reason? I think is because CPFP and dependant transactions: If the script sends a child Tx before it's parent, bitcoin node will reject it. The more you execute the script the more parents you have. And the mempool will eventually converge.

This script could be updated to take this into account. If I have time in the future, I'll try to post it here.

Also, I've realized that it could be that a transaction is not accepted by a node due to the first seen policy. This must be also taken into account: for example, a tx1 is relayed with low fees and node1 is up but node2 is down, tx1 is not replaceable by bip 125, but anyways another replacing tx2 is broadcasted to the network with more fees, this time node 1 and 2 are up. Node 1 rejects tx2, but Node 2 does not. If you try to send tx1 from node1 to node 2 with the script above it will be rejected by node2.

If anyone think this a corner-case and can't be seen see: https://bitcoin.stackexchange.com/questions/99717/transaction-being-ignored-by-miners-i-mean-ignored-not-not-mined-because-low

I finally made a cmd utility to resolve this: https://github.com/dev7ba/mempoolcp

I've noticed 2 things:

If I started second node, when first had 1000 txs in mempool, then second node will have 1000 txs less (almost) constantly till mempool clearing. This means that all newly broadcasted txs hit all (three) mempools, but newer nodes cannot catch up with older nodes.
Periodically mempools decrease abruptly (from 70 thousands to 40 thousands for example). Nodes remove expired transactions or reach their maxmempool size and clean mempool. After this event, amount of transactions is roughly the same on all three nodes (difference is less than 100 txs, comparable to several thousands in my case).

Old transactions seems not to be broadcasted by nodes. And it looks right, because if nodes will broadcast all their mempool transactions all the time, network will be bloated by unnecessary information. So new node can catch up with old one only when all transaction, that existed before new node's start, will be deleted from mempools (by either way). However may be I am mistaken and there is a way to force new node fetch all transactions from mempool of older node.
(Almost) All new transactions will be in mempools of (almost) all running nodes. Mempools sooner or later will become roughly the same in size. The less time there is between the start of your node - the better (difference will be smaller).
So if you need to sync mempools, use addnode=IP:PORT option in your bitcoin.conf file (just to be sure that your nodes are talking to each other) and wait a little bit (approximately 72 hours) and mempools will be as close as possible to each other. However as far as I understood, there is always the possibility that some transactions will be missing in some mempools and there is no way to fix it.

You could set 2 nodes to connect to 1 node and nothing else.

You might want to add some details to your answer to show the necessary modifications to bitcoin.conf

As far as I understand, connect says to connect only to specified node.
Then 'master' node appears, and if it stops working, its 'slaves' becomes useless (they wouldn't get any updates and wouldn't be able to broadcast txs).

Of course, but it solves your requirement. You didn't mention HA was a requirement (in fact you have 3 servers, so you have HA, but you could have 6 or use failover or other approaches to address that). connect is the parameter to connect to other nodes, that's the only modification required (to Max's point).

You can use the answer by @Andrew above but instead of using the script use mempoolcp command line utility. https://github.com/dev7ba/mempoolcp
Mempoolpc takes into account the dependencies between transactions and the fact that you can't send a child tx before a parent tx, or a parent tx before a grandparent tx... because otherwise, the sent transactions could be denied by the receiving node. The script above does not have this into consideration.


text:
Python Code - import error : cannot import name "privtopub" from 'bitcoin'
Hello everyone when I start this code on PYCHARM looks like no
problem. But when I turned this code from python to exe and exe
don't start and it says: import  error: cannot import name
"privtopub" from 'bitcoin'
import random

import requests

import base58

import hashlib

from bitcoin import privtopub, pubtoaddr

# Some code here

while True:

    i += 1

    first_character = "89ABCDEF"
    first_character.encode('utf-8')
    last_15_character = "0123456789ABCDEF"
    last_15_character.encode('utf-8')
    privateKeyByte = ("000000000000000000000000000000000000000000000000" + "".join(
        random.choice(first_character) for _ in range(1)) + "".join(
        random.choice(last_15_character) for _ in range(15))).encode('utf-8')
    privateKey = str(privateKeyByte)[2:-1]
    extendedPrivateKey = ("80" + privateKey)
    extendedPrivateKeyByte = bytearray.fromhex(extendedPrivateKey)
    firstHash = hashlib.sha256()
    firstHash.update(extendedPrivateKeyByte)
    secondHash = hashlib.sha256()
    firstHashFromHex = bytearray.fromhex(firstHash.hexdigest())
    secondHash.update(firstHashFromHex)
    checksum = secondHash.hexdigest()[0:8]
    finalPrivateKey = extendedPrivateKey + checksum
    encodedKey = bytes.fromhex(finalPrivateKey)
    wifKey = base58.b58encode(encodedKey)
    wifKeyString = str(wifKey)[2:-1]
    publicKey = privtopub(privateKey)
    btcAddress = pubtoaddr(publicKey)

Last 2 code i mean
publicKey = privtopub(privateKey) and btcAddress = pubtoaddr(publicKey) cannot import from bitcoin ? why ?

Also i had another problem but i solved it turned my privateKeyByte
to byte add this code " .encode('utf-8')." end of the privateKeyByte

When i delete this all code and to get to public adress with
this way :

    import random
    import bitcoin
    import requests

    while True:
        i += 1
        liste_ilk_basamak = ("89ABCDEF")
        liste_son15_basamak = ("0123456789ABCDEF")
        private_key_random = "".join(random.choice(liste_ilk_basamak) for _ in range(1)) + "".join(
            random.choice(liste_son15_basamak) for _ in range(15))
        decoded_private_key = bitcoin.decode_privkey(private_key_random, 'hex')
        valid_private_key = 0 < decoded_private_key < bitcoin.N
        wif_encoded_private_key = bitcoin.encode_privkey(decoded_private_key, 'wif')
        public_key = bitcoin.fast_multiply(bitcoin.G, decoded_private_key)
        adress = bitcoin.pubkey_to_address(public_key)

İ Have This Error : AttributeError: Module "bitcoin" has no attribute 'decode_privkey'

I am trying to solve this problem 4 days and I am going to be crazy lost my mind :S help me pls :)

I think a link to the library that you are using can be helpful, not all the programmers here use python and know all the details about the library. A link can be helpful.

I have the same problem with the missing attribute 'decode_privkey'. This attribute existed, but now it's not existing. Strange. This happened with my script "doubleslow": https://github.com/vstoykovbg/doubleslow . Maybe "bitcoin" was installed with "pip3 install --user bitcoin".

$ python3 -m pip show bitcoin Name: bitcoin Version: 1.1.42 Summary: Python Bitcoin Tools Home-page: http://github.com/vbuterin/pybitcointools Author: Vitalik Buterin Author-email: vbuterin@gmail.com License: UNKNOWN Location: /home/valentin/.local/lib/python3.6/site-packages Requires:

Hmm... Strange. The package bitcoin 1.1.42 was released on Jan 11, 2016. Therefore, it was not changed. The attribute 'decode_privkey' should not be missing.

You can try to run your script with this distro: https://github.com/vstoykovbg/cryptopup/
With this distro my script was working without the error about the missing attribute 'decode_privkey'.
Now I am with the latest Ubuntu 18 and this error occurs.

I solved the problem by installing the bitcoin package again.
I was getting this error message with my script doubleslow-base.py:
Traceback (most recent call last):
  File "./doubleslow-base.py", line 136, in <module>
    print_the_secrets(digest256_final)
  File "/home/valentin/python/doubleslow/doubleslow_module.py", line 301, in print_the_secrets
    my_256_bit_secret_WIF = bitcoin.encode_privkey(my_256_bit_secret_HEX,"wif_compressed")
AttributeError: module 'bitcoin' has no attribute 'encode_privkey'

After installing it again it works:
$ pip3 install --user bitcoin
Collecting bitcoin
Installing collected packages: bitcoin
Successfully installed bitcoin-1.1.42

Just in case I installed again all requirements:
$ pip3 install -r requirements.txt

I am not sure why this solved the problem. The script was working last year (when it was released) on the same system.
I was able to run your script with python2 and python3 by installing bitcoin with pip install --user bitcoin (to work with python2) and by defining i:
#!/usr/bin/python3

import random
import bitcoin
import requests

i=0

while True:
    i += 1
    liste_ilk_basamak = ("89ABCDEF")
    liste_son15_basamak = ("0123456789ABCDEF")
    private_key_random = "".join(random.choice(liste_ilk_basamak) for _ in range(1)) + "".join(
        random.choice(liste_son15_basamak) for _ in range(15))
    decoded_private_key = bitcoin.decode_privkey(private_key_random, 'hex')
    valid_private_key = 0 < decoded_private_key < bitcoin.N
    wif_encoded_private_key = bitcoin.encode_privkey(decoded_private_key, 'wif')
    public_key = bitcoin.fast_multiply(bitcoin.G, decoded_private_key)
    adress = bitcoin.pubkey_to_address(public_key)

    print(adress)

The module requests is not being used, so the line import requests can be removed. I added a print to see what happens and to confirm that the script is actually working.
First, I got this error:
$ python3 ./test0.py
Traceback (most recent call last):
  File "./test0.py", line 9, in <module>
    i += 1
NameError: name 'i' is not defined

Obviously, you forgot to define i.

For this error:
AttributeError: module 'bitcoin' has no attribute 'privtoaddr'

I uninstalled bitcoin lib:
pip3 uninstall bitcoin

Then removed folder:
/home/user/.local/lib/python3.11/site-packages/bitcoin

with all files. Install the lib once again:
pip3 install bitcoin

Then the problem vanished.


text:
Change addresses in old backups
I have a very old wallet backup, from 2011, from bitcoin-qt, I imported it to bitcoin core, but I seem to have only one address, seems that I have no change addresses in the imported data.
Is the current bitcoin core importing wallets partially?
Did bitcoin-qt at 2011 create change addresses in a different way?
I searched, but the info I found mainly relates to much newer versions of wallets than the ones bitcoin-qt used.
Update: using pywallet I managed to get the additional 102 addresses in the wallet, and import them, now I'm doing a rescan.

Only very, very early Bitcoin clients didn't create change addresses automatically.
In 2011, change addresses were automatic, but the address pool was only 100 addresses long (more frequent backups were needed). It was some years later it was increased to 1000 and Hierarchical Deterministic was invented.

I'm pretty sure that the Bitcoin Core wallet always created change addresses (including before it was called that way) since version 0.1..


text:
Fee Paid vs Confirmation Time
I there a graph correlating fee size and confirmation time?
A graph where I can see the fee paid by transactions which got confirmed in less than 20 minutes. Is there a graph like that?

All you should care about is time to first confirmation. The rest is random and independent of the fee paid.

@DavidSchwartz OK, I changed that part of the question.

It should likely be fee/byte vs confirmation time, not just fee.

I put together this script that spits out a table of exactly that information directly from your full node:
fees:
#!/usr/bin/env bash

getprice () {
  curl -sL 'https://api.bitfinex.com/v2/tickers?symbols=tBTCUSD' | jq '.[0][1]'
  #curl -sL 'https://api.quadrigacx.com/v2/ticker' | jq -r .last
}

n=${1:-100}
size=${2:-226}
price=${3:-$(getprice)}

for x in $(seq 1 $n)
do
  bitcoin-cli estimatesmartfee $x
done \
  | sed -e 's,\(0.[0-9]\+\),"\1",g' \
  | jq -r "[.feerate, .blocks, (((.blocks * 10)/60)*100 | floor)/100, (.feerate | tonumber | ((. * $size)/1000) * $price) ] | @tsv" \
  | sort -n -u -t$'\t' -k1,1 \
  | tac \
  | column -t -s $'\t'

usage:
All arguments are options. jq required.
fees [blocks] [tx size] [price]

outputs:
feerate     blocks  hours   fees (fiat)
0.00128259  2       0.33    1.65150777465
0.00110992  3       0.5     1.4291718392
0.00105930  6       1       1.3639917555
0.00100597  8       1.33    1.29532218095
0.00096015  13      2.16    1.23632274525
0.00091192  14      2.33    1.1742201092
0.00082616  15      2.5     1.0637925316
0.00079090  17      2.83    1.0183905215
0.00056060  20      3.33    0.7218481809999999
0.00005352  25      4.16    0.06891422520000001
0.00005093  61      10.16   0.06557925055000001

then you can
bitcoin-cli settxfee 0.00105930

the satoshis per byte are simply
$ bc <<< '(0.00105930 * 100000000)/1000'

105

I now have a github repo for this: https://github.com/jb55/bitcoin-fees

I have made a similar graph here
https://estimatesmartfee.com/
It shows how much fee transactions pay and how long they are in mempool. (Which is different from what you are asking, but similar.)
It's not very pretty, since I didn't have time to add CSS yet.
Note that it doesn't get CPFP into account at all.

For the sake of this question's PageRank, there is now such a service:
  https://bitcoinfees.21.co/
.


text:
How does the Bitcoin Standard Client wallet encryption work?
I encrypted my wallet using Bitcoin QT, then closed the application. When I restarted Bitcoin QT, it did not ask for the passphrase. But I could still access the wallet.
How is it possible to access an encrypted wallet without the passphrase?
Does it save the passphrase somewhere?
What is the purpose of encrypting a wallet and not requiring the passphrase?
If you re-install Bitcoin QT do you need to enter the passphrase?
What if you transfer the wallet.dat file to another computer? Would you need the passphrase to access it?
Do you need the passphrase to access a backup of the wallet file?
Do you need the passphrase to access a copy of the wallet file?
I searched and did not find basic information about using Bitcoin QT. Is there documentation somewhere?

You only need the passphrase to do certain things like send bitcoins or change the passphrase.
The encryption itself is attached to the wallet.dat file which contains

keypairs for each of your addresses
transactions done from/to your addresses
user preferences
default key
reserve keys
accounts
a version number
Key pool

and if you ever want to switch your wallet or add the same wallet to a different computer, this is what you would actually be making a copy of. And because this is the file that's encrypted your passphrase will move along with it.
You do not need a password to make a copy of it, but making a copy of it, doesn't give you access to the coins. Unless your using a hosted wallet, then you need to make copy of your wallet yourself. Put them on a flash drive or another computer, or maybe even in a safety deposit box.

Only the private keys are encrypted, so the only time you need to enter a password is when you are generating new transactions, and I believe you have to enter the password to create new addresses as well.


text:
Ubuntu Server vs Desktop for mining PC
Could anyone tell if Ubuntu Server has any advantages over Ubuntu Desktop for mining?
Basically, here is explained that there should be no big difference since that the Server and Desktop are different by initial packages installed.
I am wondering:

if energy can be saved as you are not using graphical environment
if GPU would have better performance in case it mining PC is manage
by SSH connection against a monitor is connected to it when using
Ubuntu Desktop
if the mining PC will work better - I noticed that some icons (like updates) are not responsive on my Ubuntu Desktop after 24 hours mining a

Any others pros and cons about using server versions against desktop version that anyone can share will be helpful.

I would highly recommend using Ubuntu Server for this, as long as you know what you are doing without a GUI. Not having a GUI at all means smaller OS size and much less OS tasks. This translates into more power savings. If you are using graphics cards, a non-GUI OS will improve your mining performance. If using an ASIC/etc. you probably will not see performance improvements, but you should definitely see power consumption improvements.

Thanks a lot. I wwas kind of knowing this, but need a confirmation.


text:
Someone has sent money to my wallet, then got them back with everything else in a wallet
I had about 0.02 bitcoins in my wallet for couple of years, but when I've started bitcoin wallet last time I've found out three transactions (two incoming and one outgoing), which I've never authorized:
4/1/18 18:51 Confirmed (2508 confirmations). Sent to (no label) 18wrbpmkwNTCyT6BYNYEenzRXKvf8ZXHHc -1.97508779
4/1/18 18:43 Confirmed (2509 confirmations). Received with (no label) 1HMpg6iHbwWmeezxfczKPH5ZK5NCTx5n5x 1.19001290
4/1/18 18:13 Confirmed (2510 confirmations). Received with (no label) 1HMpg6iHbwWmeezxfczKPH5ZK5NCTx5n5x 0.76083845

I can't fully rule out that somehow I've lost my wallet key. Although it was a local wallet on my PC in a Bitcoin Core client. And PC wasn't even on on that day. But then, they would have just transferred the money out and that's it. But here it seems to be some kind of attack, by first sending money, then cancelling transactions and getting them back with high transaction fee. It doesn't fall under any bitcoin weakness described on this page. So I'd be glad if someone help me understand what has happened.

The wallet stated in question only had two transactions in total, one incoming and one outgoing, both of which are pretty recent (1 Apr 2018)  https://www.blocktrail.com/BTC/address/18wrbpmkwNTCyT6BYNYEenzRXKvf8ZXHHc/transactions


text:
Unconfirmed Transactions on Balance and History
Is there any way to see the unconfirmed transactions within the balance of the CoPay's Bitcoin Wallet and get notifications when it receives an unconfirmed transaction?
Because I didn't see my transaction and had to search it in the blockchain to be sure that it exists .. and I remember that some other wallets already do this with an UNCONFIRMED tag.

You should enable this feature in copay settings:


text:
Is transactions in bitcoin blockchain always coin transaction?
I'm new to crypto currencies correct me if I am wrong, when I checked the block explorer I found a single block contains nearly 2300 transaction in it and I think at an average every 10 minutes a new block is created. My question is, Is all the transaction in the block is, one sending bitcoins to some other or Is there any other application running in bitcoin block chain like in etherium. Because with this much of demand in bitcoin and that many transactions happening even inside 10 minutes is quite unbelievable (sometimes this question might sound stupid).

All transactions are "sending bitcoins to somewhere".
Some of these transactions are "sending bitcoins to nowhere". Some others are "sending bitcoins to the same place". And some transactions are "sending zero bitcoins to somewhere"
So, there are no other data structures in bitcoin blockchain except of moving bitcoins from one place to another. But the transactions can handle portions of arbitrary data.

"sending zero bitcoins to somewhere" will be a non-standard transaction. It is interesting to find out whether this was possible in satoshi's first version. edit: found https://blockchain.info/tx/b4ea693a9d2d7e32b66777964fce13da302bed024bd9fd4651919da650fb1c40

hehe :) this tx was created by me :)


text:
how difficult is it to generating an ECDSA (or Schnorr) signature with a certain number of leading zeros?
If both the public key and the private key are known ahead of time (public knowledge), and the goal is to choose a message/nonce that generates a signature with, for example, a certain number of leading zeroes, is this a similarly computationally challenging task to traditional proof of work in that it is "hard to find" but "(relatively) easy to verify?"
It seems like the answer should be "yes," because if the answer is "no" then (I think?) it would imply that signatures are not pseudorandomly uniform for different messages.
Put perhaps more succinctly, can a signature also itself serve to represent a targeted proof-of-work?
Lastly, do answers to any of the above change when the signature scheme used is Schnorr rather than ECSDA?
edit: it seems that adapter signatures[1] may essentially allow for this, but I do not know enough about how they work to know for sure.
[1] https://github.com/ElementsProject/scriptless-scripts

Not if you just do leading zeroes or just lowest value when interpreting as a very large integer.
To make things easier, let's just assume that you use compact signatures which are just the signature's R and s values concatenated with each other instead of other signature formats which have additional surrounding formatting bytes that would interfere with a direct comparison.
The compact signature format just concatenates the R and the s values. However this would be a trivially broken PoW scheme as soon as one person found a valid PoW, and that person would always be the winner. This is because the R value is just the X coordinate of a nonce which is multiplied by the curve's generator point. If someone finds a R value that works with the PoW, they can just keep reusing that nonce and always have the same valid R value. So this is obviously broken.
But if you were smarter about what is compared for the PoW by instead checking that the s value is lower than the target. The s value is computed using a formula which includes the nonce, the message hash, and the private key. In Schnorr, there are also multiple hashes and EC Curve point multiplications, which help to make it more random. So s should be pseudorandom.
But there are some other issues with a signature based PoW, although these are more directed at ECDSA specifically rather than signatures in general.
The public key to verify against must be known, and must be known to be "correct". This means that you can't just have each person participating in the PoW provide their own public key, it needs to be some fixed public key, and everyone has to know the private key.
This is because, given an ECDSA signature and a message, you can compute a public key that would validate that signature and message combo. This is why it is important that the public key is known before validating the signature. Note that this is not possible for the proposed Schnorr signature scheme as it is not possible to do public key recovery with it.
The message that is verified must be published and hash. That's pretty obvious as it's a crucial part of any PoW algorithm. But specifically with ECDSA, given a signature and a public key, you can compute a message hash that would would result in a valid signature. This is why it is important that the message is something that is hashed and not just the value that gets put into the signature algorithm. This shouldn't be possible with the Schnor signatures.
So you could use signatures as a PoW so long as you are checking s and not R for the actual PoW check. And I would suggest that you use Schnorr signatures rather than ECDSA.

Thank you for the very detailed answer. I'm glad you also clarified the specifics how the different signature schemes behave differently for this purpose. My original conception of "signature" was something more like what you describe as s in your answer. I will look into Schnorr signatures as you suggest (and apparently I also need to better understand ECDSA too!). Thanks again.


text:
rpi3 bitcoin full node missing wallet commands
I built a bitcoin full node from 0.15.0.1 that is missing the wallet commands:
pi@raspberrypi:~ $ bitcoin-cli help getwalletinfo
help: unknown command: getwalletinfo
It synced the blockchain fine. I used the instructions here: http://www.raspberrypifullnode.com/
Any suggestions of what might have caused this omission?

The instructions you're linking to include the line
./configure CPPFLAGS="-I/usr/local/BerkeleyDB.4.8/include -O2" LDFLAGS="-L/usr/local/BerkeleyDB.4.8/lib" --disable-wallet

The --disable-wallet in that line (surprise!) disables the wallet functionality, making the node purely act as a P2P participant.
If you want a wallet, you need to configure enabling the wallet support.

Duh! That's what I get for blindly cut and pasting. (Strange that no wallet is the default). Greatly appreciated Pieter!

Note that the only way I could get this to build the wallet was to add  the
"--with-incompatible-bdb"
option to the above ./configure command.


text:
How to import multibit private key to bitcoin core?
I've just found an old HD with a multibit wallet with a little bit of content and I want to open it in bitcoin core since multibit is deprecated nowadays. I have the private key for the wallet, how to do this in bitcoin core? being the gui interface or the command line interface? Thanks in advance.
EDIT
I keep getting the error key 'XXXXXXXXXX' is not valid (code -5) when running getdescriptorinfo, I think it is as mentioned in my commets below, maybe the encoding used in multibit legacy is different from bitcoin's...
Btw, I'm using the key in multibit.key which contains a string of 237 characters and when outputted to cat multibit.key | base64 has 329 characters. Is it really the private key?
Also, my question is not duplicate as mentioned in the comments below...

Does this answer your question? How do I import a private key into Bitcoin-Core?

no because the encoding used to store the multibit key seems to be different, I've tried simply outputting it to base64 too to import to core but didnt worked also... any idea?

I vote to leave this question open as importing a private key is a legacy and footguny way of recovering a wallet on Bitcoin Core.

You can use the importdescriptors RPC command of Bitcoin Core, given you can find the derivation path(s) used by this wallet.
Start by creating a descriptor-enabled wallet on bitcoind (unfortunately not yet the default, you have to set descriptors to true in the createwallet call).
For example if you were looking for native segwit v0 outputs you would import a wpkh descriptor: wpkh(yourxpriv/deriv/path/*).
Here is a concrete example with xpriv xprv9s21ZrQH143K2CewR4LfKvC1Liw16RxrUMSUAiiHs4eqyMPE6UNxKmtKKTG7jFWSUhzDP2YT45ej8ratyi2TjL9UVKDVSCj5BDZiBiP91ew and derivation path m/0/1/*:
wpkh(xprv9s21ZrQH143K2CewR4LfKvC1Liw16RxrUMSUAiiHs4eqyMPE6UNxKmtKKTG7jFWSUhzDP2YT45ej8ratyi2TjL9UVKDVSCj5BDZiBiP91ew/0/1/*)

Now, bitcoind mandates the use of a checksum for the import. Therefore if you don't already have one, you can request it using the getdescriptorinfo command (keeping the same dummy values as above):
getdescriptorinfo "wpkh(xprv9s21ZrQH143K2CewR4LfKvC1Liw16RxrUMSUAiiHs4eqyMPE6UNxKmtKKTG7jFWSUhzDP2YT45ej8ratyi2TjL9UVKDVSCj5BDZiBiP91ew/0/1/*)"

You will get a desc#checksum out of it.
For this call it was wpkh(xpub661MyMwAqRbcEgjQX5sfh48jtkmVVtghqaN4y77uRQBpr9iNe1hCsaCoAkV14nksbcNSWWXH8tr9eKrPTLBpGifS8TMG8toqgtVRP6NWZpT/0/1/*)#78f39hv7.
Finally, you can import the descriptor to bitcoind and rescan the block chain from the timestamp at which you created your wallet (here again an instance with the above dummy values):
importdescriptors '[{"desc":"wpkh(xprv9s21ZrQH143K2CewR4LfKvC1Liw16RxrUMSUAiiHs4eqyMPE6UNxKmtKKTG7jFWSUhzDP2YT45ej8ratyi2TjL9UVKDVSCj5BDZiBiP91ew/0/1/*)","range":1000,"next_index":0,"timestamp":1630308659}]'

The same goes for other scriptPubKey types, you can find a reference of the syntax to use here.

I keep getting the error  key 'XXXXXXXXXX' is not valid (code -5)  when running  getdescriptorinfo, I think it is as mentioned in my commets above, maybe the encoding used in multibit legacy is different from bitcoin's.. any idea?

btw, I'm using the key in multibit.key which contains a string of 237 characters and when outputted to base64 has 329 characters...

Is it an xpub/xpriv similar to the one in my answer?

no, it doesn't begin with xpub/xpriv and it ends with =, so I guess it's ciphered?

You can't know whether it's ciphered just based on the encoding. You should look into how to get an xpriv from a multibit wallet.


text:
What will happen when the last bitcoin will be find
I have read there is a mathematical limitation of bitcoin count.
What will happen when a miner will find the last bitcoin ? I have read nobody will do mining anymore.
But, we will need miners in order to compute proof of work of transactions ?
They will earn bitcoin with transaction fees ? So mining won't stop ?
Thanks

The Mining process uses the proof-of-work algorithm to generate new bitcoins and protect the network from attack by attackers, such as the publication of an invalid block or the modification of a transaction within a block. .
Bitcoin performs the validation of transactions on average every 10 minutes and they are considered "valid" only when the block containing them is appended to the official chain; each transaction can include within it a bitcoin value which is equivalent to a fee addressed to the miner for reward of the work done, which can choose to give precedence to transactions with a higher commission than a quantity of bitcoins of their choice.
Bitcoin establishes a process of creating a new decreasing and limited currency, in fact it imposes a maximum upper limit of twenty-one thousand bitcoins; the value created by the miners halves every 210,000 blocks, on average every 4 years.
The creation of bitcoin began with an amount equal to 50 bitcoins per block in January 2009 and halved to 25 bitcoins in November 2012 thus estimating the complete issuance of all the bitcoins available in 2140; at the end of the issue, the gain of each miner will be exclusively the value of the commission.
So, the mining will not stop, only the miner's gain will decrease (it is not said because there could be many transactions)

Actually, the miner wins 2 things when he validates a block: The fees for all transactions inside the block and the new bitcoins. That's it ?

Everything I know of, if I'm wrong someone will correct it


text:
Mining operation calculation
My goal is to understand bitcoin.
I have read what happens during a transaction and have a question about it:
When a transaction happen, the miners compute a value called "prof of work". This value is calculated in order to get a 0 value (or something very closed to 0) for the hash of the value + the transaction + the last pow.
So the miner work is to calculate a prof of work. But i have read the miner discover new bitcoins too. Is it another form of mining ? I do not see the link between the POW calculation and the new bitcoins)
Thanks

Your question is a collection of many questions, and they have been answered before. Check out the search function on this site, and then report back with any other questions you may have :)

I have read a lot of things, including on stackexchange but this questions are very confusing for me. This is why i have compiled them... Thanks

Please split up your question in individual questions per topic. This is a Q&A site, not a forum, and the goal is making good questions with good answers searchable.

thanks for your answer, i have edit the first question

When a transaction happen, the miners compute a value called "prof of work". This value is calculated in order to get a 0 value (or something very closed to 0) for the hash of the value + the transaction + the last pow.

The miner does not perform the PoW on each transaction individually, but on a set of transactions, whose combined size is less than approximately 1MB when serialized (There is a 1MB limit for non-SegWit parts and 4MB limit for the entire structure including SegWit parts).
The set of transactions is placed into a structure called a block. The block has a header which contains, among other things, a timestamp, the target, a nonce, the hash of the previous block's header, and the merkle root of the set of transactions in this block. The actual representation of the transactions in the block structure is a simple serialized list.
Miners can choose which transactions they wish to include in a block and in what order. However, the usual method is to sort transactions by highest paying fee and select the first bunch of transactions which fit within the block size limit.
The merkle root is calculated by placing the transaction ids (the hash of the serialized transaction) into a binary tree where each parent's value is the hash of the concatenation of its two children's values. The value of the root of this tree is then placed into the block header, along with the other necessary information.
Proof-of-Work is then performed by taking a hash of this block header, and the proof of work is successful if the resulting hash is less than the value specified by the target, which determines the difficulty. The target indicates how many leading zeroes the hash must have - the more leading zeroes, the smaller the possible range of hashes becomes, making it more difficult to produce a matching hash. This difficulty is adjusted according to a consensus algorithm which attempts to make blocks created on average every 10 minutes - using historical data from the past 2016 blocks and their timestamps.
The Proof-of-Work is essentially brute-forcing the double-SHA256 of the block header by using different value for the nonce in the header until the resulting hash of the header is a value which is less than the target. The nonce can be randomly selected, but it is more sensible to simply cycle through all possible 32-bit integer values in order.

But i have read the miner discover new bitcoins too. Is it another form of mining ? I do not see the link between the POW calculation and the new bitcoins)

Each block must contain at least one transaction in its set, which must appear first in the list. This is known as the coinbase transaction. Unlike other transactions, it has no UTXOs as inputs - but its virtual input is newly generated coins plus the aggregate of fees paid in all transactions in this block. Newly generated coins must be strictly less than or equal to 50 >> floor(block_height / 210000) bitcoin, which determines that the number of new bitcoins which may be generated is halved approximately every 4 years (210000 blocks).
The coinbase can also be used to include an extra nonce value because the nonce in the regular block header is too small (32-bits), and its entire range can be exhausted by modern miners more quickly than new transactions are added to the block. Mining pools also usually insert their name into the coinbase transaction so it can be public knowledge.


text:
How can I keep my wallet secure?
The standard Bitcoin client does not encrypt wallet files, so any malicious user that gains access to this file will be able to transfer all the coins to their own wallet.  Furthermore, if I lose the wallet file then I lose access to those coins.  What steps must I take to prevent loss of coins like this?

Any answer to this question should include this link: https://en.bitcoin.it/wiki/Securing_your_wallet

Note that the latest version of the client does encrypt wallet files now (v0.4 at the time of writing)

The "offline wallet" method described by David Perry is a good way to securely generate a bitcoin address/wallet.dat but in order to be secure from both loss and theft the first thing you will want to do is encrypt that wallet, and then make many different copies of it.
One easy way to do this is using the program TrueCrypt as explained here.  To summarise the contents of the link, you will use the default options in the software to create an encrypted volume, then move your "wallet.dat" file into it as soon as you create it on the trusted, offline computer.  This will create an encrypted copy that can be placed on a thumbdrive and then saved in multiple locations such as gmail, dropbox, a physical safe, etc.
I would also highly recommend testing the file once with a small amount before copying any substantial sum of bitcoins to your newly created address.  If you are satisfied with both the test and all the precautions you have taken, then transfer the rest.  You can keep your wallet secure by not accessing it frequently, so this should be used as a savings wallet and not for regular transactions.  Hope this helps!  Also, you can find an excellent overview of good wallet practices and security methods at https://en.bitcoin.it/wiki/Securing_your_wallet

That is not secure for me, because I would forgot/lost the password after several years.

update: TrueCrypt is deprecated. BitLocker is also broken according to https://ieeexplore.ieee.org/document/7467359 and other sources. I recommend https://cryptomator.org/ or PGP

One method commonly in use is an "offline wallet."
To generate an offline wallet, launch a bitcoin client on a known clean computer, virtual machine, or use a bootable Linux distribution like LinuxCoin. Make sure this system is NOT connected to the internet for this process. When the bitcoin client is first launched, it generates a brand new wallet.dat file with one address. Save that wallet.dat file to a thumb drive along with a text file containing your new bitcoin address. Delete the wallet.dat from the machine once you've copied it.
Any coins sent to that address are only accessible to someone holding the wallet.dat file on your thumb drive and since the computer which generated that thumb drive has never seen the internet so it's a pretty fair bet that your copy is the only copy. Send any coins you want to secure to your "offline" wallet's address and use your thumb drive to recover the coins when needed. Remember that once you've used the wallet on the thumb drive, it is now "burned" and a new one must be generated.
Edit: There is an excellent resource for wallet-securing techniques available on the Bitcoin wiki which also covers backup methods, encryption and many other topics at far too great a length to cover in a single answer.

The upcoming Bitcoin client v0.4 will have encryption on wallet.dat if you choose to set password on wallet.

v0.4 has been released now. Voted up.

This is an involved topic and the answer will change as bitcoin clients improve.  Here is what works for me...use a drive encryption solution (i.e. truecrypt) and keep your wallet.dat file on it (you'll need to read the docs about how to relocate the wallet.dat file to a different location).  I recommend using aes256 encryption.  Make sure you remember your password used to encrypt the drive.
After creating a wallet on the encrypted drive, shut down bitcoin and unmount the encrypted drive (important to avoid data corruption).  For backup, just copy the encrypted drive to other devices both inside and outside your home (i.e. online storage provider).  Since the volume is encrypted with strong encryption, it will be unusable for anyone that obtains a copy and you will have multiple copies in case your hard drive crashes (just don't lose your password!).  Anytime you spend coins out of your wallet or generate new addresses, you should update your backups.
Note, this solution may not protect you from viruses...you should never handle your unencrypted wallet.dat file on a computer you suspect may be infected with viruses.  There are wallet stealing viruses in the wild.  There are more advanced measures that can be taken that further mitigate the threat posed by viruses.

I use virtual machine with encrypted home folder. It's a bit geeky, but is very secure and I am able to send money with no hassle of repeating the process (David Perry's advice). Don't forget to encrypt and backup your wallet.dat regularly.
With time there will be many reputable online wallet services available, though I would recommend diversifying your bitcoins in multiple places, just in case.

To avoid heavy coin losses I advise you not to keep all your money in one place. You can, for example, create one wallet for everyday payments and another wallet for savings.
The savings wallet is rarely used and usually contains more coins, so you should enforce its security by keeping it offline most of the time. You can save this wallet inside an encrypted USB stick, write its private key in a piece of paper or use any other method that you feel comfortable with.
The everyday wallet should contain less money (enough for day to day transactions) and be more accessible. You can keep it encrypted in your computer/phone or take an USB stick with you everywhere. Usability and security come hand in hand here so you should choose a solution that fits your needs.
You can obviously spread your money through many other places (multiple offline/online wallets, ewallets, exchange sites, etc.). This will reduce the probability of loosing a lot of money.

There are a few options available. Here are a couple:
Encryption with Winrar is secure if you use a long password with no dictionary words, both upper case and lower case letters, numbers and special characters in it.
Truecrypt is more secure but most people don't have it already installed, so it's little more time to get it setup.
Whatever password you use to encrypt, make sure to record it on paper, and physically store it in a couple of easy to remember and secure locations that you will not forget. Without it, you won't be able to decrypt and access your bitcoin wallet.

https://bitcointalk.org/index.php?topic=17240.0
This link will show you how to create a secure wallet.

posting back to the forum is no good.

@tysat You should include the relevant section from the forum to make your answer more resilient to loss of the link

The paper is most secure, because it will be readable after 20 years. If you need long time secure, I suggest following

Disconnect from internet (or you can boot from CD).
Run multibit and create a new wallet
Copy you public bitcoin address to some txt file or your email
Export your private key as plain text myprivatekey.txt (no password, no crypt)
Close multibit
Print file myprivatekey.txt on the printer in two copies
Delete the entire multibit data folder, it should be in C:\Users\YourUserName\AppData\Roaming\MultiBit\
Take scissors and cut every copy of the private key in half.
Hide the halves separately into waterproof case and hide the copy in different place/building (for the case of fire).
Remember your hiding place.

If you do mistake, you will loose all your bitcoins!
Before you do this, try this with empty wallet. And ensure yourself that you are able to recover the wallet from the private keys from the printed and cut paper on another computer.
This will work, even if all clouds, email, computers, dropboxes and hardisks vanish/destroy and your house burn.

The best advise is to back up your wallet account and have the seed phrase securely saved somewhere. Make sure not to disclose this seed phrase bc who ever has it can steal your money within minutes.  Encrypt your wallet also, just be patient enough to find the best encryption platform.


text:
Can bitcoin transaction be signed offline without access to blockchain
To make an offline transaction signing we do the following:
[Online PC]:  Create unsigned transaction
[Offline PC]: Select and sign the transaction
[Online PC]:  Broadcast to network
Is it possible to do the following:
[offline PC]:  Create transaction
[Offline PC]: Select and sign the transaction
[Online PC]:  Broadcast to network

If you know the unspent outputs you have the keys for, yes.
Which in practice means that you need to have seen the transactions that have paid you. Once you know that, the actual transaction to spend it can be created offline.

thanks, can the transaction history be updated on offline device after every signed transaction?

okay, incoming transactions cannot be added.

see http://bitcoin.stackexchange.com/questions/17966/how-to-safely-spend-from-a-compressed-key-offline/17975#17975


text:
Need help! Initial sync not progressing, BTC sent already, + warning message
Please help! I look forward to your intelligent caring responses.
Here is the situation:
I'm trying to do the initial synchronizing of Bitcoin-QT, which hasn't progressed in 14 hours, and:
- Significant BTC has already been sent to an address generated by the wallet.
- My primary objective is to receive the BTC that was sent to me. If Multibit is a sufficiently secure/etc wallet alternative, I do not care about completing the sync process in order to use Bitcoin-QT ** - I just want to effectively receive the BTC that has already been sent.**
Here is the problem:

For the past 14 hours, there has been NO progress in the synchronization (after some progress in the time proceeding that). (The # of blocks processed has stayed the same, but the estimate of total blocks fluctuates - what i mean is, where it says "Processed 'x' of 'y' (estimated) blocks of transaction history" - the 'x' (i.e. blocks actually processed) has stayed the same for 14 hrs, the 'y' of estimated total blocks has fluctuated (sometimes larger, sometimes smaller).) - The golden arrow wheel on the bottom right is also not turning at all.
Also the following warning message is at the top of the Overview page: "Warning: Displayed transactions may not be correct! You may need to upgrade, or other nodes may need to upgrade."

Background on this: the whole synchronization was started over 24 hours ago, but in the middle of night Bitcoin-QT crashed. (I think the warning message appeared after the program crashed & was restarted.) Whenever I restart Bitcoin-QT, it takes 5 minutes of rainbow-wheel loading on "verifying blocks" on initial bitcoin-version screen.
(other info if relevant to resolving this: the machine is a Mac, Snow Leopard; Bitcoin-QT v.0.8.5-beta
-- The progress bar shows about 1/8th complete. That has also not budged in 14 hours.
-- I did try this on a different and faster internet connection/network for about 5 hours with same result except the last bar on the right did not go green like on my regular internet connection.
-- I do have the original .dmg download file if that's of any help.
-- I have restarted both Bitcoin-QT and the computer a # of times.
-- When the progress was actually happening yesterday before the program crashed, the arrow-wheel was turning and there was no warning message.)
So basically the questions are:

Is it actually synchronizing even though there have been NO signs of further progress for at least 14 hours & a Warning message has appeared?
What is the most effective - and secure - way for me to actually receive the BTC that were sent to me to this Bitcoin-QT wallet-generated address? Should I ditch trying to synchronize and try to receive them through something like Multibit? (Even if the initial sync ends up happening I will likely ditch Bitcoin-QT anyway for something like Multibit, as long as it is sufficiently secure.)

Your help is appreciated! Neither the sender nor receiver of these bitcoins wants them to be lost due some sort of synchronizing malfunction, if that is what's going on.
I look forward to hearing from you, oh intelligent caring knowledgeable BTC users.

You won't see your BTC in your wallet until it processes the blockchain up to the point when such amounts were sent to you - be patient or switch to Multibit/Electrum or an online wallet.

If you want to switch to Multibit, you can get the private key from the Bitcoin-Qt wallet using the debug console:  Help -> Debug Window -> Console.  Enter the command:
dumpprivkey public-address
This will list the private key associated with the public address you used to send the coins to your wallet.  You can then import this private key into a Multibit wallet by following this guide to import a private key into Multibit.
If you want to keep using Bitcoin-Qt, you can download the initial blockchain and then start Bitcoin-Qt to synchronize with the network.  Go here to download the initial blockchain.  Delete the 'blocks' and 'chainstate' folders in the bitcoin data directory and then unpack the downloaded file in the bitcoin data directory.  Start Bitcoin-Qt and it will rebuild the blockchain and then synchronize with the network.
The bitcoin data directory can be found here,

(regarding the 2nd suggestion for Bitcoin-QT, the synchronization did make some initial progress, but is now apparently stalled, so i don't know how that would work.)


text:
Will there be a point in the future where moving bitcoins to a new address will make them safer?
OP_SCHNORRCHECKSIG:
Exploring Schnorr Signatures as an
Alternative to ECDSA for Bitcoin
I've noticed (e.g., the above article) that newer forms of encryption are being researched and developed for use in bitcoin. Is it possible that moving bitcoins to a new address using new encryption will make those stored bitcoins less likely to be lost than keeping them where they currently are?

Will there be a point in the future where moving bitcoins to a new address will make them safer?

That is already the case.

Using a 2-of-2 multisig address (with keys separated) is safer against theft than a normal P2PKH.
Using a 1-of-2 multisig address (with keys separated) is safer against accidental loss than a normal P2PKH.

If native P2WSH segwit addresses get deployed in the future (with 256-bit script hashes, instead of 160-bit P2SH script hashes), we'll also get a way that is more secure against exhaustive collision searches.

I am noticing (e.g. the above article) that newer forms of encryption are being researched and developed for use in bitcoin.

I believe the term you're looking for is digital signatures rather than encryption. While some cryptographic algorithms (notably, RSA) can be used for both encryption and digital signing, this is an exception rather than a rule. Bitcoin's authentication used in its script system is currently based on ECDSA, which cannot be used for encryption. The only places in Bitcoin where encryption is used is locally in wallets for password protection, and possibly on the P2P protocol if BIP151 gets adopted. If one of these is actually what you're asking about, I misunderstood the question.
The linked paper suggests the use of Elliptic Curve Schnorr signatures, something I've been working on myself as well. They have various advantages, one of which is a theoretical proof for its security. ECDSA does not have this, though it's not considered to be an issue in practice.
What Schnorr mostly helps with is privacy and compactness. The most interesting idea is signature aggregation, which would allow us to combine all signatures in a transaction - whether they are from multisig, multiple inputs or whatever - into just a single one.
Regardless, the answer to your question is absolutely yes. In particular, if we'd ever want Bitcoin to remain safe in the presence of sufficiently powerful general-purpose quantum computers, we'll need to switch from elliptic curve cryptography to post-quantum cryptography, which uses entirely different private keys, public keys, and signatures, and thus addresses.

the safety of Bitcoins depends on the function that is used to sign your transaction such that it's valid. Now that signature is based on ECDSA, that paper is talking about changing it to use Schnorr signatures
the security of keeping your coins in a particular wallet or storage medium depends on the strength of your authentication/password and it's not related to the signature schema used by the protocol
these are two different things. the signature scheme used in the protocol and the way you choose to store your bitcoins.
so the answer to your question, in the way that it is defined- with your assumptions, is no


text:
Does a new block necessarily include all transactions that occurred before its generation? What about network latency?
I read What exactly is Mining? and What are bitcoin miners really solving?, but was left wondering: What happens if a new transaction comes in, whilst mining? To answer that, I found Do transactions affect the discovery of a block?, which, if I understand correctly, says that the mining must "start over" (but the chances of finding the "nonce" on the first attempt are about the same as any subsequent attempts, so there's no "loss of work").
But, what about network latency? It must take a finite amount of time for a new transaction to reach miners—so what happens if a miner solves a block, but then receives a transaction timestamped before the block was solved?

Miners have total freedom to choose which transactions they will include in their blocks. Most miners will include any transaction that reaches them (assuming it includes an appropriate fee) but nothing forces them to do so.
But if a miner decides, for whatever reason, to omit a particular transaction, or if it's omitted by an accident of timing, no permanent harm is done. Another miner can include that transaction in a later block with no problem. Transactions don't even have a timestamp, per se, so it's not a problem if it takes a long time (other than the inconvenience to the parties involved). (Blockchain.info and its ilk may record the time at which they first saw the transaction on the network, but that time stamp isn't part of the transaction itself, as far as I know.)

I see, thanks. One follow-up question though, to make sure I understand this. Does that mean that a miner may, theoretically, solve a block without including any new transactions?—that is, the same set of transactions as the previous block? (As I understand, the new block must include the hash of the previous block, so it's just as difficult a problem.) If so, is the only reason this doesn't happen, that miners wouldn't collect transaction fees by doing so?

@acheong: Yes, indeed, a block with no transactions is still valid. There was a previous question addressing this but I can't conveniently find it right now.

It is up to individual mining pools to decide how quickly to include newly received transactions. There are no strict rules here and delays of a few minutes are usually acceptable. Transactions with higher fees may encourage miners to include them in a block ASAP.

So, a block generated at 09:53:28 is still valid even if it doesn't include a transaction that was transacted at 09:53:27?

Yes. In fact miners have no obligation to include any  transaction before a "deadline" -- it is only done on a best effort basis. It is perfectly acceptable for a mining pool to aggregate new transactions in a queue and only include them say every 5 minutes.

If there was a way to ensure that everyone agreed when a transaction was performed and saw it when they had to decide whether a block was valid, there would be no need for mining.


text:
How data should be build in submitblock
I am trying to understand how bitcoin works internally in solo minning, and i am a little confused with the submitblock method:

version:     The current version
prev block:  The previous block
merkle root: The merkle root (Double SHA of the coinbase transaction)
timestamp:   The middle time
bits:        The difficulty
nonce        The valid nonce
num txs:     Number of the transaction (01 if it contains only coinbase transaction)
tx1:         The coinbase transaction (Built from the createrawtransaction method)

Is that correct?
Thank you for your help

I want add a fix at your post, the Merkle root is built with all transactions inside the block, so in other words the merkle tree is not a normal binary tree but it is built from the left. The merkle tree root is the result of some process that include all transactions

@vincenzopalazzo Yes, but if the block contains only the coinbase transaction, the merkle root will be only the double sha256 of the coinbase transaction (Little endian)? Or i am wrong?


text:
lightning nodes cannot find route
I have two lightning nodes, Bob and Charlie (using bitcoind backend with LND).
They both have an open and funded channel with this testnet faucet:
https://faucet.lightning.community/
Both nodes have a 50000 sat local balance, and a 49056 sat remote balance.
Bob created an invoice for 100 sats, but Charlie cannot find a route to Bob to pay that invoice.
Here's the payment_request for the invoice (note this on testnet):
lntb1u1psnjevnpp5dt60ltx4pwxw24ze4e6vx6fatfpsah7a629fqxnp2ufjawpe0apsdq5w3jhxapqwpshjmt9de6qcqzpgxqyz5vqsp56mzmrleumdkj92q64l99gjatyrcm7l7nlur3uqq82de2v8fmsfvs9qyyssqult5ngct3d447vcyjt0pyh3y0qfmaghmlhf488vera3zd0se9pnx77g9jxufpesc9j3ha5nflhnkx04c4kqgsgjhjjp2jqfdsk79jcqpl38ee3

Why can't Charlie pay Bob?  I figured they would use the channel to the testnet faucet as a middle hop.
Bob has already connected to Charlie.  Charlie appears in Bob's list of peers, and likewise Bob appears in Charlie's list of peers.

How many blocks have been found since the channels were established? I am asking because the funding TX usually needs to be buried deep enough until gossip announces the channel


text:
Bus error (core dumped)
Running a new install of Ubuntu 18.04.3 LTS and downloading blocks in bitcoin-qt up to over 70% when pgm quits with "Bus error (core dumped)".
Anyone else gets this or how to fix it? (-rescan didn't help)
Thanks.

Try to delete the ~/.bitcoin dir and restarting the download blocks

There isn't a single condition that triggers a SIGBUS. Without more details it's impossible to debug this problem remotely.
A Bus Error can be indicative of a hardware problem. Check your motherboard and look for bulged capacitors near where the memory slots are located. If you find any, take your PC to a technician. You may try taking out the memory modules and clean their gold contacts with paper or eraser rubber. It's also recommended you clean out the memory slots themselves from any dust.
To completely rule out a memory problem you can boot your Linux box into memtest86 (included in most Ubuntu boot options or live images) and leave it running for a few hours. If hardware-related, memtest86 will find most memory-related problems during its very first test stages.
Software conditions can also trigger a SIGBUS. Since there isn't currently a specific known issue on Bitcoin Core that triggers a Bus Error, I'd assume it's a problem in your installation. Try rebuilding Bitcoin Core from source or reinstalling/upgrading its prerequisite packages.
Lastly, you may try tweaking Bitcoin Core's memory parameters to see if the Bus Error goes away. If you notice your Linux box is disk thrashing and using too much swap when running Bitcoin, that could be an indication of low memory. Use iotop and htop in different screens to monitor the IO and CPU-bound systems respectively while running Bitcoin Core and see if either disk or CPU are being hogged by a specific process.


text:
libbtc: Where are the binaries generated?
I installed and compiled libbtc from https://github.com/libbtc/libbtc, but where are the binaries generated or how can I compile my C project with gcc using it?
My OS is Ubuntu 20.04.
I am running:

./autogen.sh
./configure
make
sudo make install
sudo make check

But when I run make check, it never ends.
EDIT: make check resulted ./build-aux/test-driver, linha 107: 18325 Segmentation fault (core dumped) "$@" > $log_file 2>&1
FAIL: tests
============================================================================
Testsuite summary for libbtc 0.1
============================================================================
# TOTAL: 1
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0
============================================================================
See ./test-suite.log
Please report to https://github.com/jonasschnelli/libbtc/issues
============================================================================

this is a grait question, but we need to know the OS and the command that you are running, in other words, we need you know if you run make install, or you run only the make command. If you are using Cmake inside your app and you are not found the library that you installed, you need to require it. But it is another question for another forum.

@vincenzopalazzo My OS is Ubuntu 20.04.
I am running:
./autogen.sh
./configure
make
sudo make install
sudo make check
But when I run make check, it never ends.

How the console tells, maybe this is not the correct place, also because you receive a segmentation fault (core dumped) during the make check.

See ./test-suite.log
Please report to https://github.com/jonasschnelli/libbtc/issues

However, may you have installed the library in your system with the command sudo make install, this command puts the binaries of the library is a place where are all the libraries of the system?
Maybe you have only a failure in the check
But the last commit of this library is on Nov 4, 2018, and maybe this can be a signal of the motivation of your error.
I hope I clarify your idea

Thanks! It worked! I just used -lbtc!

@Papaulo if you accept my edit on the question, we make the question more readble

@vicenzopalazzo I accepted, and now it's better, thanks, but I've got another error: "error while loading shared libraries: libbtc.so.0: cannot open shared object file: No such file or directory" when running my program. I think I will make another question.

I don't know if it is good open a new question, the problem is related to a failure of the install process

This question is old, and it's another failure.

@vincenzopallazo Oh, I solved this problem.


text:
running bitcoin-cli -testnet getblockchaininfo
Hello when I run this command (bitcoin-cli -testnet getblockchaininfo) I get this:
{
  "chain": "test",
  "blocks": 0,
  "headers": 0,
  "bestblockhash": "000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943",
  "difficulty": 1,
  "mediantime": 1296688602,
  "verificationprogress": 4.453828060385498e-08,
  "initialblockdownload": true,
  "chainwork": "0000000000000000000000000000000000000000000000000000000100010001",
  "size_on_disk": 293,
  "pruned": false,
  "softforks": [
    {
      "id": "bip34",
      "version": 2,
      "reject": {
        "status": false
      }
    },
    {
      "id": "bip66",
      "version": 3,
      "reject": {
        "status": false
      }
    },
    {
      "id": "bip65",
      "version": 4,
      "reject": {
        "status": false
      }
    }
  ],
  "bip9_softforks": {
    "csv": {
      "status": "defined",
      "startTime": 1456790400,
      "timeout": 1493596800,
      "since": 0
    },
    "segwit": {
      "status": "defined",
      "startTime": 1462060800,
      "timeout": 1493596800,
      "since": 0
    }
  },
  "warnings": ""
}

can you explain what does each line mean and why headers :0 ?
Thank you

You can get information about each value on the RPC documentation on bitcoincore.org or by running bitcoin-cli help getblockchaininfo. I paste it below:
{
  "chain": "xxxx",              (string) current network name as defined in BIP70 (main, test, regtest)
  "blocks": xxxxxx,             (numeric) the current number of blocks processed in the server
  "headers": xxxxxx,            (numeric) the current number of headers we have validated
  "bestblockhash": "...",       (string) the hash of the currently best block
  "difficulty": xxxxxx,         (numeric) the current difficulty
  "mediantime": xxxxxx,         (numeric) median time for the current best block
  "verificationprogress": xxxx, (numeric) estimate of verification progress [0..1]
  "initialblockdownload": xxxx, (bool) (debug information) estimate of whether this node is in Initial Block Download mode.
  "chainwork": "xxxx"           (string) total amount of work in active chain, in hexadecimal
  "size_on_disk": xxxxxx,       (numeric) the estimated size of the block and undo files on disk
  "pruned": xx,                 (boolean) if the blocks are subject to pruning
  "pruneheight": xxxxxx,        (numeric) lowest-height complete block stored (only present if pruning is enabled)
  "automatic_pruning": xx,      (boolean) whether automatic pruning is enabled (only present if pruning is enabled)
  "prune_target_size": xxxxxx,  (numeric) the target size used by pruning (only present if automatic pruning is enabled)
  "softforks": [                (array) status of softforks in progress
     {
        "id": "xxxx",           (string) name of softfork
        "version": xx,          (numeric) block version
        "reject": {             (object) progress toward rejecting pre-softfork blocks
           "status": xx,        (boolean) true if threshold reached
        },
     }, ...
  ],
  "bip9_softforks": {           (object) status of BIP9 softforks in progress
     "xxxx" : {                 (string) name of the softfork
        "status": "xxxx",       (string) one of "defined", "started", "locked_in", "active", "failed"
        "bit": xx,              (numeric) the bit (0-28) in the block version field used to signal this softfork (only for "started" status)
        "startTime": xx,        (numeric) the minimum median time past of a block at which the bit gains its meaning
        "timeout": xx,          (numeric) the median time past of a block at which the deployment is considered failed if not yet locked in
        "since": xx,            (numeric) height of the first block to which the status applies
        "statistics": {         (object) numeric statistics about BIP9 signalling for a softfork (only for "started" status)
           "period": xx,        (numeric) the length in blocks of the BIP9 signalling period
           "threshold": xx,     (numeric) the number of blocks with the version bit set required to activate the feature
           "elapsed": xx,       (numeric) the number of blocks elapsed since the beginning of the current period
           "count": xx,         (numeric) the number of blocks with the version bit set in the current period
           "possible": xx       (boolean) returns false if there are not enough blocks left in this period to pass activation threshold
        }
     }
  }
  "warnings" : "...",           (string) any network and blockchain warnings.
}

The headers field means the number of block headers your node has validated, without validating whether the transactions inside that block are valid. Validating the header includes validating the difficulty, timestamp and blockhash fields and can be done without downloading the whole block. The headers must be equal or higher than the blocks field which indicates how many blocks have been fully validated.

thank you for your answer. So in my case headers= 0 means no header is validated ? and why i got that? Thank you

You either created your own testnet and therefore there are no blocks created until you create them or you are having connection issues with other peers - make sure your firewall is not blocking port 18333

When I run bitcoin-cli getblocktemplate it gives me that blocks still downloading.. Can it be because the blockchain was not yet downloaded?

Yes, you have not synchronized any headers or blocks with the network. You may have a network issue.

should I let it run for more than one day? or at least some hours?


text:
Can you break down what data is encoded into a bech32 address?
Can you break down what data is encoded into a bech32 address?
e.g. bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4
How do bech32 addresses on testnet, regtest, signet compare?

Bech32 addresses are defined in BIP 173.
This slide is taken from Pieter Wuille's presentation on bech32 at SF Bitcoin Devs in March 2017.

Different prefixes
A list of address prefixes on the Bitcoin wiki is here.

bc is representing Bitcoin (mainnet)
Testnet bech32 addresses start tb
Signet (both default Signet and custom Signets) bech32 addresses also start tb (although an earlier iteration of Signet used sb).
Regtest bech32 addresses start with bcrt. This is defined in chainparams.cpp here. Discussion on why regtest addresses don't have the same prefix as testnet and signet is here.

Remaining data

1 is just a separator and doesn't represent any particular data
q is the witness version. This represents zero as the first SegWit witness version introduced was SegWit v0. Taproot introduces SegWit v1 with p representing one (v1).
w508d6qejxtdg4y5r3zarvary0c5xw7k is the witness program.
v8f3t4 is the checksum

As the slide says, mainnet P2WPKH addresses are 42 characters and mainnet P2WSH addresses are 62 characters under SegWit v0. Future witness versions can be up to 74 characters although SegWit v1 addresses (Taproot) will be the same length as v0 P2WSH addresses (62 characters). Witness programs as defined under SegWit v1 are 32 bytes.
There is a bech32 demo decoder site here.
Please note that SegWit v1 (Taproot) addresses will use bech32m encoding rather than bech32.


text:
What problem set is the Minisketch library designed for? What is it currently used for and what could it be used for in future?
What problem set is the Minisketch library designed for? What is it currently used for and what could it be used for in future?

libminisketch is a library implementing the PinSketch set reconciliation algorithm and was covered in this Bitcoin Core PR review club. In theory it could be used for any problem where you have two sets of data and want to work out how those data sets differ (which specific elements are present in one but missing in another) as efficiently as possible.
The primary use case for Minisketch at the time of writing (February 2021) is Erlay on Bitcoin.
Erlay is a proposal for more bandwidth efficient transaction relay in Bitcoin and was covered in this Bitcoin Core PR review club. The Minisketch library is used in Erlay for set reconciliation between peers (peers generally have slightly different sets of transactions in their individual mempools).
There is also potentially a Lightning use case for Minisketch which was described by Rusty Russell in this lightning-dev mailing list post. Lightning nodes exchange gossip messages in an attempt to understand the topology of the network (nodes and channel sizes). They use this understanding to construct a route for a payment to a specific destination. This idea has not been implemented at the time of writing (February 2021). More centralized solutions such as LN-sync are currently used to address this problem.
There are also potential use cases unrelated to Bitcoin for Minisketch too. Pieter Wuille stated on IRC:

One of the most deployed uses of efficient set reconciliation algorithms is in the way PGP keyservers synchronize (or at least used to); that's using cpisync (an earlier algorithm before pinsketch was invented, which has far worse performance)

For additional possible applications of Minisketch see the Applications section of the README.