text:
Can we look at how long it took to solve for the most recent block in the blockchain? (and how?)
For example, can we see, the latest block, somebody got lucky and solved it in 1 minute, but then the next block, nobody solved it until 18 minutes later? (and how can we see it?)

If your question get a satisfying answer, it would be appreciated if you can mark them accepted. If not, can you comment on what is missing?

@PieterWuille actually, I would have hoped that the answer contains a link or an alternative, to go to a website, so that we can click "display last block", and then click "previous block", so that we can see the time interval between the two

Sure, that makes sense. But please help guide the answers you get towards acceptance (not just this question; I've notices you don't have any accepted answers so far on all the questions you've asked).

@PieterWuille yes, the reason is that I am learning a lot of things about Bitcoin. The answer posted, I do not know whether it is the most correct or definitive answer.  It is not like programming, where we could ask, how do we do logarithm in base 10 in JavaScript, and the answer is Math.log10(), and the person try it, and it works, and it is almost certain it is the definitive answer, because it is such a short and simple answer and that it worked.

@PieterWuille Also, sometimes, such as on Interpersonal Skills or Math, I can ask a question about e and probability, and they gave me differential equations as an answer and I don't know if it is the definite answer, but they asked me to accept it, and then the Meta actually states that users cannot ask or force other people to accept their answers. For example, some users just let other users vote on 2 or 3 solutions and let one of them become the best answer by popular vote.

@nonpolarity Of course, I'm not demanding that you accept my answer in particular (or any answer). I'm just noticing a pattern that you don't seem to accept any answers, so I thought it'd be good to encourage you helping guide answers towards acceptance; whether that is by accepting, or by commenting what you feel is missing to make the answer satisfactory. Note that you can always change the accepted answer; for example, if another one pops up later that gets higher community votes.

@PieterWuille yes, I hear you. One thing I also was thinking was, if I accept any answer when I don't know whether it is a definitive answer, there can be 30 or 500 users coming over later, see the answer, and see that it is accepted as the correct answer, and therefore think this is verified and all correct. I do not yet have the ability do verify it is all correct, so I don't want to mislead the other users who come over and think so. I can certainly find out the truth 3 months later, and modify the accepted answer, but every time I learn something, I can't go thru all 35 questions I asked

Generally if you see an answer being upvoted, and there aren't people commenting that it's wrong, I think it's reasonable to assume the answer is correct. Acceptance isn't really about correctness, but about whether your question has been answered in sufficient detail. If it's actually factually incorrect, people will point that out.

Accepting an answer indicates a) that the topic was addressed satisfactorily, b) which answer was the most helpful to the asker. This does not necessarily need to match the most upvoted answer. As frontpage and search results indicate whether a question has an accepted answer, accepting helps other users navigate the site's content. Incorrect content will accumulate downvotes or comments pointing out the flaws, and will get corrected or removed when discovered as incorrect. While accepting is not mandatory, I would consider it polite for a regular user to provide this form of feedback.

I wouldn't be worried about accepted answers misleading other users since you will get notifications about new comments on any answers to your questions. If that were to happen, it should get pointed out to you. :)

Blocks have timestamps, but they are not very accurate. The protocol rules only (roughly) require them to not be more than 1 hour in the past and not more than 2 hours in the future. At least historically, miners have used this flexibility, effectively turning part of the timestamp as an additional nonce field. I don't know if this is still common practice.
Still, this means you can't rely on block timestamps to determine when they were actually created. It is possible to run a Bitcoin node yourself, and just observe when your node learns about every block - if you have decent connectivity, it will generally be within seconds of the block being found. There are also block explorer websites that generally keep track of this information.

You can get an overview of the recent blocks by visiting a "block explorer" such as e.g. blockstream.info or blockchair.com. These usually report the timestamps of blocks as seen in the screenshot below. Note that the timestamps in Bitcoin blocks are picked by the block's author and may diverge from the actual time the block was found.

via blockstream.info


text:
It is said that never reuse an address, but the news is stating biggest bitcoin addresses are buying?
It is said that we should never reuse addresses, so I think one time into the address, and one time out, and that address should be abandoned.
So the top holders of bitcoins should know that too, but the news is having headlines:

Top 100 richest Bitcoin addresses bought 17x more BTC than sold in last 30 days
Top 100 Bitcoin addresses accumulated $11B more BTC in the past 30 days

So why aren't they following this simple rule?

This is mostly about privacy

Because they don't care about their privacy

Because they don't care about their clients/customers/friends' privacy

Because they want to keep their code simple

Because they don't want to keep a database of their addresses

Because their identity is already obvious: This is the case for exchange wallets

Because multisig addresses whose transactions require mulitple private keys to be signed are one each and I'm not aware of a "multisig hierarchical deterministic wallet" system. Multisig addresses are intended for reuse, at least until someone finds a way to solve this

For "Because their identity is already obvious: This is the case for exchange wallets", even if it is exchange, wouldn't they want to divide their wallets into 20 or 33 of them, so that if they get impacted for any negative reason, only 5% or 3% of their asset is affected and is not end of the world. If it is one address and it is impacted, it is 100%

Instead of using multiple addresses, they might be using addresses where the signatures of multiple people are needed which are even more secure.

And yes they do use multiple addresses. Some are cold addresses like the multisig ones and some are hot addresses.

You may see the self-named holders of Tether ERC20 here: https://etherscan.io/token/0xdac17f958d2ee523a2206206994597c13d831ec7#balances The numbers after exchange name show the wallet number

Come to think about it, it may even be "They want to give the signal that, me (such a big guy), is buying, folks"

source: Stack Exchange

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

sort: votes


text:
Can I create my own 24 word system using JavaScript or Ruby?
Ledger Nano X has a 24 word system.  So can I create this system on my own computer?
And I can use 3 words, 9 words, 24 words, just by a method like the following?

Say, for simplicity, if it is 3 words, "apple", "pisces", "steve"
Now I sort them, in alphabetically order, but no need to, because they already are sorted
Now use any package to create a Private Key A and Public Key A from them
Now, for the so valuable BitcoinPrivateKey of my "address" that has the bitcoin, use the public key in step 3 to encrypt it.
Now I can email this code to 20 of my friends or post it in my Google Docs or any website
So only the private key A can get back my valuable BitcoinPrivateKey, because that token I emailed to 20 friends, if I use the private key A to encrypt it (to pass through the private key function), then I will get back BitcoinPrivateKey. (that's the property of private key and public key, if f is a function of private key and g is the function of public key, then we know x = f(g(x)) and x = g(f(x)) meaning pass through f and then g, and you get back itself. Likewise for passing through g and then f, you get back itself.
So from now on, I only need to remember "apple", "pisces", "steve", and I can generate Private Key A and Public Key A again. And then I can ask any of my friend what that token is, and use Private Key A to get back your BitcoinPrivateKey, and therefore get back my bitcoin and sell it.

Does it work?  Is there any online system that can do that? But that will mean we need to enter the private key on a webpage and let it go through the Internet once, with HTTPS it is better, but if that online system has some loophole, then the private key could have leaked.

See BIP39 https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki

The concept you're describing is called a brain wallet: [tag:brain-wallet]

so brain wallet involves private key and public key... so it could be a poem they lock up in the safe, but it is the 1st, 3rd, 5th word on each line, and then the 1st, 3rd, 5th word on each line again... and this is the key to $3 million dollars... and it can be made into a puzzle like in the book Da Vinci code... so they can make a movie out of it

You can do this, but is it a good idea? No.

One does not "encrypt" with a BitcoinPrivateKey, or any private key in any cryptosystem. The proper term is "sign", which goal is authentication, not secrecy (the goal of encryption). In other cryptosystems that do encryption, one encrypts with the public key and decrypts with private key. Any mention of encryption with the private key is at best using incorrect terminology.

You have reduced the level of security by making it so that an adversary only needs to figure out your three-word phrase rather than your 24-word phrase. Assuming 170,000 English words from which you derive your phrase, your three-word phrase only has 52 bits of entropy. In practice, it will probably be less than this because your set of words may not be sufficiently diverse or your choices may not be sufficiently random.
Of course, the adversary also needs to find the encrypted seed which you have sent to your friends, but that's a different matter, and socially engineering a specific person is still easier than brute forcing a 128-/256-bit key space, let alone only need to successfully socially engineer 1 of 20 specific people. Assuming the probability of the adversary successfully attacking a particular friend and getting the encrypted seed is 0.1%, the probability of them succeeding when you have given 20 friends the encrypted seed is 1.98%.
You're better off just using a BIP-39 seed phrase, writing it down somewhere (not sharing it with your friends) and using "apple pisces steve" or whatever as the BIP-39 optional passphrase, which you either remember or also record somewhere (not as important where, as long as the actual 24-word seed is stored in a safe, offline location). This would effectively result in a 27-word seed.
Consult this video by Andreas Antonopoulous for other reasons why you shouldn't devise your own schemes, and what you should do instead: https://youtu.be/jP7pEgBpaO0

yes, right now the "3 words" is just for simplicity here. In reality, I might use 9 words, or I might use a poem or lyrics, but the 1, 3, 5, 7, 9, 11, 13th word... or the 2, 3, 5, 7, 11, 13, 17, 19th word (prime numbers, or use prime numbers + 3)...  so I can go any where in the world, find that poem on the Internet, and just remember my "formula", and be able to get those 9 or 24 words back

"your choices may not be sufficiently random." —Those are all horrible schemes with poor randomness. They are not cleverer than those of cryptographers, they are extremely weak, and attackers will rip them apart. Please watch the linked video.

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


text:
Random Number In R Value , what is it actually, is it the same as Nonce in the blocks
I wonder about the random number in R value ...
if i am right , the R value is First part of the script signature which is combined of two parts (r,s)
r = Gk  (elliptic curve scalar multiplication) Or does the whole signature is the Gk ??
So r , is a multiplication of random number ( k ) times G (elliptic curve scalar multiplication )
while
r = xcoordinate(R) , is just the first part of the ( r,s )
I read an article the most repeated R values in transactions is
0x00000000000000000000003b78ce563f89a0ed9414f5aa28ad0d96d6795f9c63
while G is the Double of this point means that the random number is (1/2)
so R value Is simply is simply calculated by multiplying any number by G ???
and they do call it nonce , so is it the same nonce shown in blocks ? that is already public ?
or it is another nonce ?

The nonce in a signature is different from the nonce used in the block header. These are unrelated to each other. They only share a name because the term nonce is a generic word that means "a number used only once."
A signature is composed of two numbers: R and s. R is the X coordinate of a random nonce k multiplied by the generator point G. It is the result of elliptic curve scalar multiplication with a point. k is a scalar, which means it is just a random integer modulo the n, the order of  G.
The nonce k must be kept private. If it is known, then anyone can compute the private key used in the signature. Additionally, reusing the same k (which results in R being the same) with the same private key will allow the private key to be computed.


text:
When the number of bitcoin reward halves after 4 years, doesn't the perceived value of a bitcoin about double?
Let's say the price of a bitcoin is US$33,000, and all the miners mine it or not mine it if their electricity kWh price is too high, and it is at an equilibrium that it is somewhat profitable and worthwhile for the miners to mine bitcoin.
Then in year 2024 May, when the rewards changes from 6.25 bitcoins to 3.125, and if the price of a bitcoin stays at $33,000, then it become unprofitable for many miners, and they would stop the mining, and for all the miners to still keep on mining, they would think that the price of one bitcoin is more like $66,000 as before. So would the perceived price of a bitcoin double every time the reward becomes half?
Or would the price just stay low, but just that all of a sudden, a portion of the miners would stop, but when it becomes easier to "win" the block every 10 minutes, some miners will join again, until it reaches an equilibrium around this lower price?  But it seems many miners would think, it is so difficult to mine and be profitable, and therefore they are not selling their bitcoins at $33,000 but would demand a higher price.

TLDR: The price of bitcoin determines how many miners are mining, not the other way around.
Your last paragraph is on point! After a block halving, every miner unprofitable at the new reward will stop mining. They will stop mining because they need to pay for the electricity they burn. But for each miner that stops mining, the remaining miners become more profitable. The remaining miners become more profitable because it's easier to find new blocks! That means they have to use less electricity to find new blocks, and there is less wear on their mining hardware. So just like you say, after a while it reaches an equilibrium.
The big peak in this picture is May 11th, 2020, the day the previous halving occurred. You can see the estimated hash rate went from 119 to 76 Ehash/s. That's a lot of miners that had to shut off!

It's also important to note that miners don't decide what the price of bitcoin is. Miners just react to the bitcoin price. Starting their miners when it is profitable and shutting them down when it is no longer profitable. The total amount of bitcoins that are sold or bought determine the price of bitcoin.

so I guess if the miners collectively have a lot of bitcoins (if each miner has 1 bitcoin and I wonder how many miners there are), then if all of a sudden, they won't sell their bitcoin at $33,000 but want to get more, then it creates a sudden drop of supply. If other people also feels that the supply will be less and the price should go up and hold on to it, then the supply becomes even less, then if the buyers want to buy it but cannot, they will need to bid a higher price or if they buy it at the market price, then they will get matched with a seller asking for a higher price

That doesn't happen though. In the real world they can't afford to not sell their bitcoin.
Also, it's not necessarily the case that the supply goes down by a lot if miners stop selling. There are 900 bitcoins mined each day, but 18 616 581 already mined bitcoin. (not counting lost ones)
Those 18 616 581 coins already in circulation have a lot more to say about the supply of bitcoin than new coins mined.

I see your point... I was just thinking, if some swordsmen are making swords, and all of a sudden, they know the special metal they use to make the sword will be difficult to get, and therefore, the swords will be hard to get, and people holding and have the collection of swords know about this situation, would they hold onto their sword tighter, and not let go of them as easily. So if they sold they sword for $100 in the past, will they all feel, I got to get more for the sword now, perhaps $110, or perhaps more, and I will see what kinds of offers I get first

According to Messari, Bitcoin's approximate real 24h-trading volume is $6.8B. That's about 220 times the value of the coins mined per day. Miners have an influence, but there are a lot of other people creating offers. For example exchanges selling their trading fees.

hm... by the way, Bitcoin's award was halved 3 times since 2009?  But Bitcoin's price has risen more than 8 times. (2 to the power 3, meaning more than doubling 3 times)

There are a lot of other things that happen in the world that influence the Bitcoin price. For example generally increasing adoption and interest, or the macro trends with huge amounts of quantitative easing and negative interest rates. It's not clear to me why you think that the price is so strongly tied to the halvings.


text:
Which transactions go through the SHA256 process of "trying to win the new block"?
It is commonly said that a new block that is hoped to be added to the existing blockchain is filled with transactions, and together with a nonce, go through SHA256 twice, and tries to be a small enough number (with many leading 0's)
Isn't it true that each miner or mining pool, can get different transaction to fill in?    Are these transactions coming in that "are hoped to be added to this new block in about 10 minutes"?  Some transaction are chosen because they offer a good fee. And it is just up to the miner or mining pool to decide which transaction go in?  So then, can the miner or mining pool put in one transaction, two transactions, 0 transactions, or any number of transactions?
So each miner or mining pool work off a block that are filled with different transactions plus a nonce?

Yes, each miner decides which transactions to select into their block templates. Blocks must have a coinbase transaction, all other transactions are optional, but blocks are limited to 4,000,000 weight units.
Let me elaborate: unconfirmed transactions are relayed on the network by the participating nodes via the p2p gossip protocol. Each node maintains their own list of unconfirmed transactions in its memory pool (mempool). Miners generally pick transactions from their mempool to assemble block templates.
Blocks must have a coinbase transaction as the first transaction in the block, and the remaining transactions must be valid and sorted topologically. A block may not exceed 4,000,000 weight units. Other than that, miners are completely free to pick and choose the composition of their block. Blocks that only contain a coinbase transaction are allowed and referred to as empty-blocks.
It is expected that miners wish to optimize their revenue by collecting the most transaction fees possible. By default, the getBlockTemplate call uses a greedy algorithm that iteratively picks the set of transactions with the highest effective feerate until the block is full.  Miners may use the prioritisetransaction rpc call to reprioritize transactions for the block template consideration. Some miners may use custom software to build their blocks.
In effect, block templates usually overlap almost completely across miners as nodes should see the same transactions on the network (with some slight delays due to relay). However, since each miner's block template attempts to pay the block reward to themselves via the coinbase transaction and each miner has a different payout address, every block template produced by miners will be unique and no miners will ever repeat work done by another miner.
Given a block template, miners search that template's combination space by injecting random data via varying nonces, extranonces, timestamps, malleating the version field, etc. Each new combination yields a unique block header which is hashed using SHA-256d. If a resulting digest meets the target, the miner has found a new block. Otherwise, they create a new block template and start over.
Once a new block is discovered, the block author broadcasts it to their peers. Other nodes that learn about the block append it to their blockchain, update their UTXO sets, and remove the confirmed transactions from their mempools. Since the best chain can only have one block at every height, it does not make sense for an honest miner to continue mining at the old height, therefore, they switch to mining at the new height as quickly as possible.

The answer to all your questions is yes, except for the last one. There is more that can be varied. Nonce, extranonce, transaction order, transaction selection, maybe timestamp (within +/- an hour or so) and some other contents of the block can be varied to change the hash. The higher the difficulty, the more creative miners become.

you mean it is not as simple as such some chosen transaction plus a nonce?  My main focus is, different miners can choose different transactions to be in the block, and different mining pools, also, have thousands of miners in it, and each miner can have their own chosen transactions in the block?

yes, yes, no - pool allocates work to prevent duplication of effort


text:
Can miners collude to bypass the penalty based revocation system of the lightning network?
The core lightning security assumption relies on a punishment mechanism called “Justice Transaction”. However, how can you prevent a malicious user from colluding with a miner, and producing a block with old state transactions without the rest of the network (watchtowers/honest nodes) realising it pre-mining?

When a channel is closed unilaterally, it requires two transactions by the closing party to move funds from a channel back into unilateral control.
The closing party publishes their version of the commitment transaction to the network. The commitment transaction has a special condition for the closer's output.  After the commitment transaction is included in a block, the closing party's funds are locked for a period of time in which only the counterparty is able to issue their penalty transaction. The closing party can only spend their output after the lock expires. Since the two spending conditions are encoded in the output's locking script, the funds remain subject to potential penalty spending until the closing party moves the funds to a different output.
To prevent a penalty transaction from occurring during the wait period, the attacker would need to be able to censor the penalty transaction from being included in any block between the commitment transaction being confirmed and the lock expiring. Censorship of such level would require sufficient hashrate to reorganize any block that includes it.

It's named "penalty transaction" by the specs :).
What you say is true but far from sufficient. It also requires this miner be able to heal this block chain without a censored (the penalty) transaction. It therefore assumes that a single miner controls more hashpower than the rest of the network combined.
Thus it can be stated as such:

The Lightning Network core security assumption relies on the fact that nobody can "51% attack" the network.

But it is arguably already an assumption made by Bitcoin itself.

You don't need a majority hashpower since a minority hashrate can also mine an old state if channel lock time is long enough. I understand your “healing” argument, but in order to “heal” the chain you should be able to differentiate fraudulent blocks from honest blocks. So the new question is, how honest miners can identify those fraudulent blocks that include old states. PTLCs are now making this differentiation even harder.

You do need a majority of hashpower as we assume the miners to be economically rationale. ie they will mine the transaction that pays more fee. So what happens is: with a funding tx A an old state tx B gets broadcast, the penalty tx C gets as well. Most of the network will include C which pays more fees, unless the miner you colluded with is most of the network itself and will likely get paid through a bribe. If the colluding miner does not have enough hashpower, even if it finds a block it will get reorged out as the rest of the network just mined the high-fee tx C, which

conflicts with the stealing transaction B. In addition the rationale miners have a huge delay to mine the penalty tx C before B even gets valid. This is the reason why you need to have >50% of the network hashrate in order to censor the transaction long enough AND then not even getting reorg'ed out by economically rationale miners: you need to heal a chain which censors a transaction.

Your argument is true for pre-mining, but I'm talking about post-mining of an old state. I don’t think reorg is practical (at least today) since all these miners must consolidate and agree on whether to reorg a particular block. Miners are all independent organisations and they have no clue what strategy the rest of miners are following.

Also a miner can be the fraudster himself, so no bribe involved.

Ah also, you can consider reorgs as an attack vector to the network since it increases mempool congestion.

You are confused. As detailed above, the transaction representing the old state is timelocked and conflicting with the penalty transaction. Therefore the penalty transaction will be included in the block chain before the old state transaction (as it can pay any feerate). What an attacker can do -which requires >50% network hashrate- is replace the block that included the penalty transaction and all blocks that were created on top of it. This is a block chain fork and will only heal if you have more hashrate than the rest of the network combined.

Yes the miner can be the fraudster, it is recommended to set a big timelock for a channel with an entity that control a significant portion of hashing power.

"you can consider reorgs as an attack vector to the network since it increases mempool congestion." => This is wrong and completely unrelated.

The point is, old state tx "B" is not broadcasted at all, its injected to fraudulent miners' isolated mempool and eventually end up in a block without the rest of the network realising it pre-mining. Penalty tx "C" cannot be broadcasted/relayed from that point.

Ok, spotted the confusion: in order to effectively steal from an old state you have to 1. broadcast an old commitment transaction 2. wait to_self_delay (as per spec wording) 3. Get a transaction (B in my wording) that spends the commitment transaction to an output you control. But point is, the delay you have to wait is more than enough to get the penalty transaction (C) confirmed before B is even valid :-)

Then i went further and detailed a race condition, but there is no window for a race condition in the first place.

I don't think you get my point. TX B is not broadcasted at all, but surprisingly end-up in a valid block. Also there couldn't be a race condition anyways since LN transactions are not considered first-seen first safe (non-max sequence).

I don't think you read carefully and try to understand my explanation.. Ping me on IRC if you'd like as it's becoming too long for this medium. As for your last comment: tx B cannot end up from nowhere in a valid block as it is not valid by the time the peer remarks the tentative of theft and broadcast tx C (penalty). first-seen safe is brittle and completely unrelated.

Aren’t tx B and tx C spending from the same inputs? If so, tx C cannot be relayed when tx B is mined (with no reorgs) Also what is the best to reach you on IRC?

They are but B is invalid so it's the other way around. I'm darosior on any bitcoin-related channel on freenode. Probably #bitcoin for this matter.

This is a special case of 51% attack.
The lock of the funds in a force-close is at a minimum 144 blocks for the person who submit the old state, but the other party can claim their share at once. They can also submit a penalty transaction at once, and have all the funds in a channel to spend from.
So 144 is how many blocks that had to be mined in secret to pull this off.
And yes, it would have to be a majority, because the chain with the most PoW wins.
In theory it is possible, but it's impossible in the same way that 6 blocks is seen as immutable - it is not likely to yield gains worth the expenditure, to pull it off.
If they had that hash rate and the willigness to steal, they'd be more likely doublespend a transaction to an exchange, because that is easier.

No it's not a special case of 51% attack. Anyone with %1 hashrate can mine such block and the rest of the miners will continue to mine from that outpoint.

You have not done your research.
I read your post on r/btc, and it is pretty clear you have no idea how any of this works. Now, it's fair not to, but you should try to listen to those who do.
Any commitment transaction that a channel partner can spend unilaterally is a smart contract that is formed like this:
1 output is the counterpartys money. He can spend those immediately.
1 output is what you claim is your money. This output has this contract:

After a timelock (minimum 144 blocks), you can spend them.

Your counterparty can spend them immediately with revocation key

The revocation key, he will have, because that is part of the protocol.
And when I say "the counterparty", I mean the counterpartys node - or someone who he have delegated to watch for him (populary called a watchtower).
Now, this is part of the standard functionality of lightning network. Mobile nodes will typically enforce longer timelocks, though, I have seen two weeks.

Having read the other comments here, I sense the grand misunderstanding here.
It's really very simple: The penalty TX C spends from the output of the channel closure B. It can't be mined before a faulty channel closure has been mined.
There is a time lock that says how many blocks the penalty transaction has to claim the attackers money. The minimum is 144 blocks, the maximum will usually be substantially higher for mobile wallets.
The attacker will not be able to move those funds during this period. This is coded into smart bitcoin contracts and is part of what makes LN safe enough.

You can't as described here:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-March/001080.html
Tl,dr: if one controlls more than 50% of hashrate and secretly mines the longest chain with old state one can steal the entire capacity of all channels one is connected to. Reward is much higher than regular Bitcoin double spent through reorg but execution is also more expensive

A %1 hashrate can mine an old state without others realizing it. Your approach could be true if the rest %99 reorgs (aka heals) the fraudulent block. However I don’t think this is practical since all these miners must consolidate and agree on what to mine. Miners are today not even in agreement what method to use to activate a soft fork.


text:
Undo a transaction to a wrong adress
I made a transaction to a wrong adress. How can I find where the transaction reciever has an exchange adress?
Transaction:
Completed   BTC 0.10951991  2021-01-02 23:25:18 Adres:1L5wSMgerhHg8GZGcsNmAx5EXMRXSKR3He
Txid:
4a22a54a7a314a4a6fcf14d1b8a64cbc320fcd854d5cd806a23024f446a4fbb2

Bitcoin transactions cannot be reversed. The address you sent money to has never sent any money away, so the address might even be owned by no-one

Undo a transaction to a wrong adress

Bitcoin transactions cannot be undone.

I made a transaction to a wrong adress.

That is usually hard to do because standard addresses have checksums.
If you sent it to a genuine address given to you by someone other than the intended recipient, you'll need to contact the person who gave you that address and see if they are willing to create a new transaction sending money to you.
If you somehow entered an address that no-one gave you, then there will almost certainly be no-one who owns that address. There are an incredibly vast number of valid addresses and almost none of them will ever be owned.

How can I find where the transaction reciever has an exchange adress?

Not all addresses in use are related to exchanges. Many addresses that are in use will have been generated by standalone wallets on phones or personal computers. As I wrote above, almost all valid addresses are not owned by anyone and never will be.
There are businesses that analyse the blockchain to try to associate used addresses with exchanges but they may be very expensive to employ. Even if you did identify an exchange, the exchange has no reason to violate their customer's privacy. At best they might pass on a request to their customer for that customer to consider your request that the customer send money back to you. But even that might take an enormous amount of persuasion.

If it was unconfirmed, you could double-spend to reverse it. Publishing a second transaction to yourself that spends bitcoin used in the first transaction.
It's talked about in this question: Is it possible to cancel an unconfirmed transaction?
Otherwise, no way to reverse it if it has been confirmed. If you can track down the owner (if it has one), you could ask for it back.


text:
What is the meaning of difficulty in Bitcoin mining?
I'm a beginner in Bitcoin and Blockchain technology, so I have a question after reading about the difficulty in Bitcoin mining:
What does the difficulty actually mean?
I read that

A high difficulty means that it will take more computing power to mine
the same number of blocks, making the network more secure against
attacks

However, I don't clearly understand.
Ex: When the difficulty is 6, then what I can know from that number?

This question is similar to: What is "difficulty" and how it relates to "target"?. If you believe it’s different, please [edit] the question, make it clear how it’s different and/or how the answers on that question are not helpful for your problem.

Suppose I give you some very complicated function f(), and I assign you the task of finding an input n with the property that f(n) is small.  That can be difficult.  I can make it more difficult by changing the definition of "small".  If I ask you to find an n such that f(n)< 100, that's difficult.  If I ask you to find an n such that f(n)< 90, that's more difficult.
Once you've compiled a block, you're confronted with a function f().  The function itself depends both on the block you've just compiled and the solution someone found for the problem associated with the preceding block.  Successfully mining the block means finding an n such that f(n) is small.  The only way that anybody knows to solve this problem is by trial and error.
The definition of "small" is periodically adjusted.  That definition of "small" is what people mean by "difficulty".

I'm a beginner in Bitcoin

Therefore this answer will be a broad overview and simplified.

What does difficulty actually mean?

To understand the difficulty number in Bitcoin, you have to understand it's purpose and not just the mathematics of it.
To understand the purpose of the difficulty number, you first need to understand the role of mining and timestamping.
Bitcoin is digital cash and it has no tangible coins. Bitcoin money is kept track of by keeping a record of the transactions. A transaction is a transfer of control over some amounts of money. For example if you give someone 10000 BTC for two Pizzas, the Bitcoin part of that exchange is a Bitcoin transaction.
It is obviously important that the person who already spent the money isn't allowed spend it again. To prevent that, everyone has to know what transactions already occurred and in what order.
The order is important so that you can decide which of two spends are valid.
For example Joe has 10 BTC
Monday,  Joe gives Sue the 10 BTC
Tuesday, Joe gives Bob the 10 BTC

Is different from
Monday,  Joe gives Bob the 10 BTC
Tuesday, Joe gives Sue the 10 BTC

We need to know which transaction is accepted and which is fraudulent and should be rejected. This is important to Sue and Bob. Those timestamps (Monday, Tuesday) enable us to do that. This has to work at a global scale so that nodes in Atlanta and Auckland agree.
In Bitcoin it is miners who add transactions to blocks and add blocks to the blockchain. The blockchain is like an accounting journal of transactions and blocks are like pages in that journal.
So miners are ordering the transactions by timestamping the blocks (and by effectively numbering the pages).
Adding a new block is also the way that new amounts of Bitcoin money are created. You can think if it as new Bitcoin "coins" being created. This money is created as a reward for the miners.
Bitcoin's designers wanted a new page to be written every ten minutes. The rate is important because it affects inflation in the currency. The rate must also be fast enough that recipients can quickly see they have been paid. The rate must be slow enough that every node can keep up with receiving and checking new pages (new blocks).
However producing a new block could be a trivial amount of work, so greedy people might mine 1000000 blocks a second to scoop up all the mining rewards. They would quickly run away with vast amounts of money. Therefore the mining is made difficult.
How difficult it needs to be depends on how much computing power all the miners have at any moment. If there are more miners with better computers, we need to increase the difficulty of mining so that they can't produce more than a block every 10 minutes on average.
The difficulty number is the inverse of a target number, higher difficulties correspond to smaller targets.
Miners construct a block (a page in the transaction journal) and then calculate a hash of that block. This hash is a very large number that has to be less than the current target number.
About every two weeks, all Bitcoin nodes (wallets, miners, etc) recalculate the difficulty based on the average time between blocks in the last two weeks. If the average is less than 10 minutes, the difficulty is increased proportionately; if more, decreased. From then on nodes reject any blocks from miners that don't have a hash less than the new target.
This prevents double spending and ensures a wealthy miner can't take over mining and commit fraud.

When the difficulty is 6, then what I can know from that number?

You could calculate the target. You could see that new blocks have a hash smaller than that target.

Thanks @RedGrittyBrick for your detailed answer. You helped me to have a sense of what the difficulty is!
Hmm, I'm a little confused that with a specific target, and the difficulty is 1, then is there any useful information that I can retrieve from that? It may be about computation power, speed, or something like that
Thank you so much

A simple way to think about bitcoin's mining "difficulty" is to remember that purpose of the difficulty (which is re-assessed/changed every 2016 blocks - about 2 weeks), is to keep the bitcoin block issuance time at 10 minutes.
The difficulty determines how much work the bitcoin miners have to do in order to solve the "puzzle" in order to create a new and valid block. If more hashrate gets added to the network, then the blocks get created faster than 10 minutes. So at the next difficulty adjustment, the difficulty will increase so that the block time (on average) will take 10 minutes. Conversely if hashrate leaves the network then blocktimes slow down, so at the next adjustment period, the difficulty reduces, returning the average block time to 10 minutes.
It's very clever and one of Satoshi's unique innovations that makes the protocol self-regulating!

Difficulty adjustment is one of the critical features of Bitcoin that Satoshi implemented. It basically means - adjusting the bitcoin block time to ~ 10 minutes as programmed.
Think of it this way - if suddenly more miners join in then there would be more hash power and blocks would be mined quicker then before (less then 10 minutes) - the difficulty adjustment, that happens every 2016 blocks (~2 weeks) would raise the difficulty of mining making if harder to find the block eventually raising the block time back to ~10 mins.
The same thing applies if there are miners leaving (shutting of their miners) - then there would be less hashpower resulting in slower block times (more then 10 minutes) so the difficulty would lower making it easier for the remaining miners to find the block eventually lowering the block time to ~ 10 minutes.

Ex: When the difficulty is 6, then what I can know from that number?

Difficulty is measured in % of change, the current difficulty change is estimated at -10%, meaning it will be 10% easier to mine a block in the next difficulty epoch (each epoch is 2016 blocks)
check it out here https://bitcoin.clarkmoody.com/dashboard/


text:
Why does the TXID have 256 bits when Bitcoin's address security is 160-bit?
Commonly used Bitcoin addresses have the security of 2160 (due to the RIPEMD-160 hash). This means that Bitcoin is based on the fact that 160-bit security is good enough. If someone breaks 160-bit security, most bitcoins are in trouble.
The TXID is used to determine previous inputs. For each input, you need to specify the TXID and the output number you want to spend. But the TXID is 256-bit. If 160-bit is good enough, why do we need to enter 256 bits for each input? Why don't TXIDs have only 160 bits as well? This would save 12 bytes for each transaction input, reduce blocks, etc.
If this is for historical reasons, why do some other unrelated cryptocurrencies (e.g. Ethereum) use the same scheme (160-bit address, 256-bit TXID)?

TXID has nothing to do with security, even if you could produce a collision you couldn't spend an input that you don't own.

@Mike D It does. The ability to produce colliding txids where one version is valid and the other is not could be used to trivially fork the network (send the tx two distinct nodes, and the one who saw the invalid one will first will reject the chain that includes the valid one).

Security levels
First of all, the relation between security level and the number of bits involved is non-trivial, and depends on the sort of attack we're talking about. For what follows, there are roughly 3 ones that matter:

preimage resistance of a hash function: This is how hard it is for an attacker to find a piece of data that hashes to a given hash. So, symbolically, given a, find x such that hash(x) = a. For secure N-bit hash functions it is assumed that the preimage resistance is 2N work. For example, finding a preimage for RIPEMD160 takes roughly 2160 attempts, so we say it has 160 bits of security. SHA256 has 256-bit preimage security.
collision resistance of a hash function: This is how hard it is for an attacker to find two pieces of data that hash to the same thing (but it doesn't matter what that hash is). Symbolically, find x and y such that hash(x) = hash(y). Perhaps surprisingly, this is a significantly easier problem than finding preimages, and for a secure N-bit hash function it is assumed that finding a collision takes only roughly 2N/2 invocations of the hash function (e.g. , so we say for example that SHA256 has 128-bit collision resistance, and RIPEMD160 has 80-bit collision resistance.
existential forgery of signatures: This is how hard it is for an attacker to construct a valid signature for a private key they don't have. For a secure N-bit elliptic curve, this is assumed to take roughly 2N/2 group operations, so secp256k1 is said to have 128-bit security for this sort of attack.

Security in Bitcoin
Bitcoin aims to have a 128-bit security level.

The secp256k1 Elliptic Curve used to sign transactions has a 128-bit security level
The SHA256 hash function has 128-bit collision resistance (it has 256-bit preimage resistance, but for some security properties of the system collision resistance is important).
Using 160-bit hashes for single-key addresses is actually overkill. This could just as well have been a 128-bit hash, as only preimage resistance matters. Presumably no 128-bit hash was chosen as at the time Bitcoin was designed no 128-bit hash functions were considered secure anymore. Of course, a 160-bit or 256-bit hash function truncated to 128-bit could have been used, but presumably there was little desire for such an unconventional design to just save a few bytes.
For multi-party addresses like P2SH multisig and P2WSH, the situation is a bit more complicated. There are known collision attacks that matter in this case (where one of the multisig parties defrauds the other parties, resulting in the ability to spend coins unilaterally). For this, a 256-bit hash of the script is needed to get 128-bit security. P2WSH (and the upcoming P2TR) has this, but P2SH does not, so P2SH technically only has 80-bit security against this attack.

Thanks for the great info! So which resistance do we actually need for TXID? Is the preimage resistance enough, and then 256-bit is overkill? Or do we need collision resistance as well? The case from your other comment (send the tx two distinct nodes, and the one who saw the invalid one will first will reject the chain that includes the valid one) is rather a bug, isn't it?

We need collision resistance on the txids. I'll try to extend this answer later with why.

Can you extend it? I don't want to pressure you but I'm still very interested in the answer. Thank you!

@AlešJanda I think it's answered in this comment, but would be good to add it to the answer itself: https://bitcoin.stackexchange.com/questions/109652/why-does-the-txid-have-256-bits-when-bitcoins-address-security-is-160-bit/109658#comment124396_109652


text:
Running Electrum wallet and full node on Windows. How to configure SSL with self-signed certificate
I have a full node running on Windows 10, I have Electrum wallet installed and I have BTC-RPC-EXPLORER set up.
The problem I have is that I can find no clear guide to setting up and installing a certificate so SSL can be used on the Electrum server port 50002 so everything can actually talk to each other.
I installed just about everything 'out of the box' and expected it to all work...
I guess I need to generate a certificate and then put files etc. in certain places. This must be something that most installations have done - but not documented.

I almost deleted the question - but the answer maybe of use to others.
I have Bitcoin Core running as a Windows app, I have Electrum wallet running as a Windows app, but have Electrum server running under node... and btc-rpc-explorer running as a stand alone EXE -- all on the same PC.
The problem was that I had forgotten to start the Electrum server!
So this issue is fixed, but I have a load more (the explorer isn't showing wallet balances - it says 'no transactions') -- but I'll post these in the best place I can find when I run out of ideas again...

Seeing a load of recent edits, I think an admin has far too much time on their hands... this is dangerous... people looking for things to do, that don't need doing.


text:
Transaction has 900+ confirmations but doesn't show up in my wallet
I've received a payment to 1KGUphZbuMj5dU9WD4ZKVqHdtz2jSLPXv3. It has over 900 confirmations, but it doesn't show up in my Exodus v20.12.22 wallet on Windows, yet. I have no idea what to do. Is there a way that I can get my wallet to recognize the transaction?

What services and wallet were you using ?

Wallet is exodus.

Without more information it is difficult to provide help. ie: which wallet software are you using? software version? have you used this software successfully in the past, or is it a new install? does your wallet show the receiving address? is it properly synced to the network? what OS are you using? etc.

Exodus / 20.12.22 / Have used in the past and successful / yes it shows / no idea / windows 10

900+ confirms ...

Then you have definitely, incontrovertibly and irreversibly already received the money even though your wallet doesn't know yet.

... but nothing in wallet

Sure but remember that wallets don't contain money. They check the public blockchain to add up how much money you have.

No idea what to do.

is it properly synced to the network?

no idea

https://support.exodus.io/article/75-how-do-i-refresh-my-wallet
says

Did you send a coin to your wallet, but it's not showing in your balance? Is your Bitcoin displaying incorrectly? Do you get an error when trying to send?
If so, then your wallet may be out of sync with the blockchain. A quick wallet refresh tends to fix a number of balance-related problems and help your wallet correctly align with the network.
As a first step, make sure you are using the latest release of Exodus. Here's how to upgrade.
Refresh the wallet by clicking the logo:

Open the crypto wallet you want to refresh inside of Exodus.
Mouse over the asset's logo and click.
A dialogue asks you if you want to rescan the blockchain. Click Rescan. When the refresh icon is finished spinning, all your transactions will be updated and refreshed.

I think I'd try refreshing before upgrading but it's your call.
I hope you have your recovery phrase or your private key written down somewhere safe.


text:
Who is paying for the running costs of Bitcoin?
Bitcoin mining will consume around 70TWh for 2020 (~3 nuclear power plants).
As far as I know, electricity is paid using fiat money. If 1 kWh costs 0.1 $, without counting hardware costs, that means that 1 year of mining costs $7 Billion for electricity.
At the moment, the Bitcoin capitalization is around 357 B$.
It follows that 2% (7/357*100) of the capitalization is used by electricity every year!
Who is paying for that (and how can it be sustainable)?

people who invest in Bitcoin using fiat money?
by Bitcoin deflation comparatively to fiat money?
people who lose money when/if Bitcoin goes down?
more generally: Mafia (an expensive laundry is not a problem if it is good)?
or I don't understand enough how Bitcoin works, and that's something else :-) ?

An interesting related question: what portion of the 'bitcoin market cap' will the network converge on as the yearly security expenditure?

The miners pay for the energy use directly, but the whole network pays indirectly. As @AndrewChow described, the miners provide a service to the network. They secure the ledger and provide the transaction ordering necessary for users to converge on a shared ground-truth. In exchange for this public service, the miners are reimbursed via block rewards.
The block reward consists of two parts, the block subsidy and the transaction fees. The subsidy consists of newly minted bitcoins. It doubles as both an incentive to miners as well as the initial distribution vector for bitcoins. It is financed via monetary supply inflation and thus a levy on all holders of bitcoins. The transaction fees are paid by the winning bids for the blockspace the transactions occupy in the blockchain.
You ask how this cost can be paid without anyone losing money. There is no such thing as a free lunch: the Bitcoin ecosystem pays an on-going maintenance cost for the network to continue running. There is no guarantee that the value of the overall Bitcoin ecosystem is stable or increases.

I understand how miners recoup their costs from mining and transactions, and how costs will "gradually shift from holders to transactors". But what puzzles me, if the price of the Bitcoin was not increasing (or if most people was not thinking it will increase), does holders and transactors would accept to lose 2% every year of their capitalization in order to "secure the ledger" ?

What alternative do you propose?

I don't understand why you ask if I have a solution. I am just wandering how a money system can been seen as viable when only the ledger takes 70TW/year and how this cost is/can be supported by the whole system. My question is a bit biased, but I wanted to confront my thought with Bitcoin people. I think I'll accept your answer cause it answers more on how the costs are supported by the whole ecosystem.

Do you think that other financial systems do not have operating costs? Printing bills and minting coins is fairly expensive. Collecting, counting, cleaning, redistributing adds friction. Banks and payment providers run huge datacenters and offices. Central banks debase their currencies by several percent points per year by increasing the monetary supply. As long as the currency provides utility, why would people not be able and willing to pay for the upkeep?

It seems that many hodlers expect Bitcoin to store purchasing power better than alternative stores of value, or prefer Bitcoin for other reasons, so while I can't give a definitive answer why they accept the on-going cost, I have observed that they have been doing so for the past decade.

As far as I know, we shouldn't compare Bitcoin with coins, bills or Visa. Bitcoin is used by much fewer people than the laters, provide different service and Bitcoin technology could not support mass utilisation (max 7 transactions / s). But yes, I am not sure we can compute operation cost of usual money and its efficiency in relation to its total capitalization.

I've seen estimates that more than 7M people hold Bitcoin, which is in the range of smaller countries. But that figure is two years old.

Who is paying for the running costs of Bitcoin?

The primary costs are almost entirely paid by miners.
Anyone else who runs any other sort of node (wallet etc) is likely to be also contributing by forwarding Bitcoin messages. They also pay a tiny amount of costs to sustain the network in terms of their own electricity costs, networking costs, capital assets (computers) depreciation etc.
Miners recoup their costs entirely from

In the form of fiat currency from people who buy from miners their mined Bitcoin (the inflationary block rewards subject to halving roughly every 4 years).

People using Bitcoin who include transaction fees in their Bitcoin transactions.

Appreciation in value of their Bitcoin assets (probably).

So in the end the costs are paid by people using fiat to buy Bitcoin and people who send bitcoin to others (e.g. to purchase goods, services or other kinds of assets).

The people operating the mining hardware do. Mining hardware consumes electricity, so people who run the hardware receive an electricity bill from their electricity provider. They pay the bill using the proceeds from mining. Usually miners will sell some portion of the Bitcoin they earn for fiat, and pay for electricity using that fiat.

All right, but that means that bitcoin must raise by at least 2% / year (i.e. running cost / total capitalization) against fiat money so that no-one lose money ?

@souch when miners exchange Bitcoin for fiat to pay electricity bills, the Bitcoin doesn't disappear. When the mining reward halves to insignificance in the future, transaction fees will pay for electricity. Bitcoin circulates but is not lost by circulation.

Even if some answers (like this one) clarify things. My question (perhaps badly asked) was not on primary cost (the miners...) but more on how these costs are dispatched on the whole network and how or why these people are ok to pay 2% tax / year on their capitalization.

The other answers do a good job of explaining how miners are compensated for their electricity (and other) costs.  As the other answers point out, there are two ways that miners are compensated: block rewards and transaction fees.
In real terms, the block rewards (which halve approximately every four years) are paid for by everyone holding bitcoin, as the newly minted coins which comprise the block rewards have a deflating effect on coins already in circulation (by virtue of increased supply).
The transaction fees are paid by those that send coins to others.  Senders include transaction fees in their transactions, and these transaction fees go to the miners.  This incentivizes miners to include these transactions in blocks that they mine.
As the block reward decreases (with each halving), it is expected that transaction fees will have to increase, in order to incentivize miners to continue to mine.  So, the costs of keeping the blockchain going will gradually shift from holders to transactors.

When you say "are paid for by everyone holding bitcoin" what do you mean??

@troybeckett It's supply and demand.  With any currency - when more of it is produced, this increases the supply, which tends decrease its value.

I get that the price decreases but how is that price decrease connected to "are paid for by everyone holding bitcoin"

They are paying (indirectly), because the bitcoin that they are holding has been devalued.


text:
Can I interrupt the initial blockchain download without losing progress?
I just installed Bitcoin Core through brew on my mac.
The blockchain is now downloading but it's slowing down, so I would like to restart it.
Can I abort the process and restart it and will it pick up from the last block?
Or will it start from scratch again?

Ok, I just open anoter terminal window and do:
bitcoin-cli stop

This answer could be improved by explaining why this works: it instructs the Bitcoin software to flush the current state of its synchronization progress to disk, gives it time to finish that and only then cleanly shuts down. Also check out How to increase the speed of synchronisation? for some ideas how to configure the node to sync faster.


text:
How do you reliably estimate mining fees?
I'm asking this question because sites seem to yield widely different estimates.
For instance, if I want a transaction to be accepted within 6 blocks, this is what I currently have to pay according to various calculators:

https://bitcoinfees.net - 5 sat/vB
https://www.buybitcoinworldwide.com/fee-calculator - 123 sat/vB
https://privacypros.io/tools/bitcoin-fee-estimator/ - 356 sat/vB
https://btc.network/estimate - 230 sat/vB

Why are the numbers so different? Who's right?
For the record: at first, I was convinced that bitcoinfees.net had to be wrong, but then, someone sent me a transaction (4a129199006935cad810f99a41c14b2e2cdc4f8043732fde8f6db3f7aa899dfc) with a mining fee of 5 sat/vB... and it received its first confirmation within 20 minutes. It makes me even more confused because I see many transactions currently paying a much higher mining fee.

TL;DR: you don't, you enable RBF and adapt the transaction fee to the block space market (or use a wallet that does).
Best effort(s)
One is interested in the cheapest reliable fee estimation. That is, in estimating the lowest fee that will get their transaction included in a block before a configured deadline.
There are 3 classes of estimates:

Those based only on the mempool. For instance Electrum's. Or just users looking at Johoe's before making a transaction. It consists in targeting the depth at which you want to add your transaction (below 3 blocks worth of transactions, below 10 blocks, etc..). However looking at the snapshot of the mempool does not give you any guarantee about the time it will take for your transaction to be included in a block. This method is also gameable by miners.
Those based only on the block chain. It consists in looking at the feerate of the transactions that were included in the previous block. It however against doesn't give you any ETA guarantee, and is even more gameable by miners than looking at a snapshot of the mempool.
Those based on both the mempool and the block chain. This is the case of the Bitcoin Core fee estimation algorithm. Instead of looking at past blocks or a snapshot of the mempool it will look at the dynamics of transaction confirmation (when was a transaction broadcast, how long did it take for it to confirm, at what feerate, ..) in order to give you more assurance regarding the ETA you can expect by choosing a specific feerate.

However note that no estimation can ever be 100% reliable, it can't predict the future. If after your transaction is broadcast someone wants to fill the blocks up to your target with megabytes of high-fee-paying transactions, they just can.
A guess isn't reliable
Since you cannot reliably estimate transaction fees, you need to adapt your price to the market. However you will only witness the market actions after broadcasting your transaction. This is the reason behind Replace-by-fee (you need a way to bump your fees post-broadcast).
But RBF is opt-in, you need to enable it before performing a transaction. In case you already broadcasted your transaction, you can fall back to CPFP (spend the unconfirmed output with a second, high fee paying, transaction that pays for both --example with Electrum).
Conclusion -- what should i use?
First of all use RBF when possible. Start with a lower estimation and bump the fees as your transaction is approaching your deadline without getting confirmed.
If you are building an application, prefer Bitcoin Core's block chain estimations as:

Reliability often outweighs cost (stuck transactions really aren't fun).
With a larger sample of transactions, statistics are on your side.
If all applications start relying on mempool estimations and fees continue to rise it becomes attracting for miners to try to play games. :)

I like to use https://jochen-hoenicke.de/queue/#0,2h
Presuming there is about 2,000 tx in a block I would pay 0.00070 BTC/KB to get into the next few blocks (probably the next)

This image shows there are 1712 tx paying more than 0.00060 but less than 736 paying 0.00070

My recommendation is to look at mempool.space before sending a transaction.
There you can either choose to trust their estimates which are posted directly on the site, or you can figure out yourself based on the actual fees also shown on the same dashboard having been paid in the previous few blocks, combined with information on the nr of transactions in their mempool etc, to make your own informed judgement.
Even better, you can run mempool.space on your own hardware showing you your own mempool from your full node, if you install e.g. the Raspiblitz on a raspberry pi. :)
/bitcoinomnivore


text:
BLS signature verification?
Is it possible to perform BLS signature verification with upcoming Taproot/Tapscript proposal?

No, only Schnorr signatures are supported.


text:
I don't have data on my phone, can I still send and receive bitcoin without internet?
I dont have internet on my phone at all at the bitcoin ATM and want to know if i can still receive my bitcoin with my phone

Hi, in theory you can just provide an address and someone can broadcast a transaction that pays to this address even if right at this moment you're offline, but obviously you can't see an incoming transaction if you're not online. But I'm just making a very general statement here, I think you could provide more specific information, especially about the ATM and the software you're using in order to receive precise answers

Yes, you can receive Bitcoin even if you don't have internet, but you will only see them when you synchronize your wallet (for this you need internet).


text:
Binance: How to check BTC value by USDT at time of arrival after blockchain disabled it
Let's say that I received an amount of BTC to my Binance wallet one week ago.
How can I look up the value of the payment measured in USDT at the time I got paid?
I used to be able to see that on blockchain.com by looking up the transaction there, but they since removed the value by USDT at time of receiving.

You seem to have answered your own question: You find the value in USDT at time of arrival by hovering your mouse in blockchain.com.  Did you want to know how to use Binance's service to achieve this (which would be something you, as a customer, could ask them)? Or did you want to know something else?

Seems that you aren’t aware that blockchain disable the functionality of displaying the value at time of receive !

I wasn't aware, the question would be better with that information edited into it.

authors: αԋɱҽԃ αмєяιcαη


text:
Is there a way to see the precise time of when a transaction was sent out?
I'm a developer. I'm not really knowledgeable in bitcoin development, yet.
Say, I'm using Electrum wallet. I share an address with someone. The thing is that I need this someone to pay a certain amount of BTC within a certain time-window, 15-30-60 minutes. It's because I have products that are priced in fiat money.
That person will send me BTC. I may open my wallet not right away but in 12-30 hours, to check incoming payments. Or, even if I open it sooner, there may also be delays in BTC network and I won't see a payment, right?
Goal: to prevent a customer from taking a potential advantage of fluctuation of BTC/FIAT prices.
I don't consider handling my payments via 3rd-party crypto-coin payment providers or their APIs.
Is the precise date and time of when a payment was sent attached to a transcaction and can it be retrieved? How, where?
Can it been seen in Electrum?

Is the precise date and time of when a payment was sent attached to a transcaction and can it be retrieved?

No
And it is useless information anyway. The transaction fee chosen by the sender can influence whether the transaction gets included in a block in 10 minutes, 10 hours or 10 days. If all you care about is that the sender broadcast their transaction proposal within 10 minutes of clicking a checkout button on a web-page they can just set a very low fee and not care how long it takes for the transaction proposal to be mined and included in a block.
But there's no way of measuring when the sender sent out their transaction proposal.
Miners timestamps in blocks are also pretty useless for your purpose. There's no guarantee that the timestamps are more accurate than an hour or two. There no guarantee that a block has a later timestamp than the prior block.

ok. In that case,  what would you propose for avoiding situations when a customer tries to gain the system using bitcoin price fluctuations? Namely, he sends me N bitcoins claiming that "I sent it yesterday and yesterday bitcoin costed that much, it's you who received it today", altough in reality a customer sent me bitcoin today

@Lelouch: If short-term currency exchange rate fluctuations are a concern, you should probably only accept currencies you are comfortable with. Either that or apply some hedging strategy separate from the transactional side. I see no way to transfer risk to the customer apart from getting them to perform the exchange into your target currency prior to purchase. If you are accepting BTC you need to agree with the purchaser (or just set) a BTC price that takes into account the cost to you of that exchange-rate risk, don't just use some third-party rate unchanged.

While Murch answers the technical side of it already, what you're trying to do is simply not possible. There is no provision in Bitcoin to know the exact time a transaction was broadcast (short of running several nodes that connect to enough of the network to attempt to deduce the first broadcast time).
If you're trying to protect yourself against price fluctuations, your best bet would be to have a system that requires a certain number of confirmations within a time window of your choosing (say, 30-60 minutes). If you have not received BTC in that time period, you can cancel the order. If you receive it after the window has closed, you simply refund the BTC back to the customer and ask them to place a new order (or let them use that BTC amount as a credit against their new order).
This ensures that you only have to sell BTC for fiat within a certain window of time, and if the BTC transaction occurs too far after the order is placed, you return the BTC, without touching fiat at all.

and if customer uses a low fee, even the first confirmation may take a long time to arrive

Precisely, which is why you wait for at least one confirmation, possibly more, depending on the value of the transaction

Not precisely. Even one confirmation may arrive in a day, whereas a time window within which a customer has to pay is 30-60 minutes. He might pay in time, but the first confirmation, as I'll see it, will arrive in 24 hours.

Which is why you wait until the first confirmation. Most payment gateways require that the transaction be confirmed within a certain window, not just broadcasted, precisely to motivate users to put a high enough fee to confirm quickly

Even the first confirmation may arrive in a day at the ealiest

The first-seen time is not usually tracked by Bitcoin wallets. You could log when a transaction was first seen by your wallet, but that would not necessarily be a reliable approach.
I would suggest something else though: generate a new unique address every time someone gets to the checkout of your sales portal. You would want to do that anyway since that would be how you can identify which invoices got paid. When you generate the invoice for the customer, store a timestamp and the exchange rate used in your invoice. Add a small markup to hedge against the currency risk.
Corollary, you will generally not be able to rely on people to pay within a certain amount of time. Statistically speaking there is at least one block per day that takes longer than one hour to get mined, so you will not be able to rely on getting the first confirmation within 15-30-60 minutes. Returning Bitcoin payments is non-trivial, so having an extremely short time frame in which you accept payments will likely turn into a frequent source of support issues.

You would want to do that anyway since that would be how you can identify which invoices got paid. When you generate the invoice for the customer, store a timestamp and the exchange rate used in your invoice. --> how would that help solve my problem of "precise timestamp when payment was sent" ?

Statistically speaking there is at least one block per day that takes longer than one hour to get mined, so you will not be able to rely on getting the first confirmation within 15-30-60 minutes.  --> how is that relevant? even if that block took a whole day to get minned, what matter is, date-time when a transcaction of a customer was sent from his wallet

@Leloucha: You would have an exact time when the invoice was generated and use that for determining the price. You'd get an estimated time when the transaction got sent by logging when your full node sees the transaction. If the payment arrives more than  after the invoice was generated, the trade is void and the customer can either use their balance towards a new invoice or have their funds returned (possibly minus the transaction fee).

I've already determined the price in BTC at the checkout step. That's before a customer even sees a BTC address to send bitcoins to

I don't run a full node, not yet


text:
How can I recover the missing end of my private key?
I found this paper among my old stuff.
What can you do with it?
Is there any way to fill in the missing part?

Be very, very careful - The address has over 25 BTC in it - do not accept offers of help from anyone, do not give the part of the key that you have to anyone or any software without fully understanding what you are doing. While I don't normally do this, given the amount of BTC at stake here, there's an email in my profile, reach out if you have any questions

I'm pretty certain Raghav is completely trustworthy. However I expect dozens of scammers may be  busy working out how they can pretend to be him and contact you. Remember that email addresses are easily faked and it isn't hard to set up other social media accounts in someone else's name (or with minor variations of their name). Just be very very careful.

As a general case you can brute-force it.
https://github.com/salian/btc-incomplete-key

TL;DR:
You don't need to bruteforce anything here (at least almost), and can recover the missing last 7 characters on an average PC at home within less than 1 second using a simple Python script!
In detail:
In your picture there are 7 characters missing at the end of the private key (figured out by comparing with a test-printout using the same HTML file).
Yes, it is correct that this key format is using Base58 alphabet and therefore there are 58 possibilities per character, so for 7 characters you would need to try 58^7 possibilities (which would be about 2 trillions) in theory, but all these considerations are missing an important fact:
When such a private key (the format is called WIF short for Wallet Import Format, see also the reference documentation here) is encoded, at the end (after the actual private key) 4 bytes are added as a checksum. So if these 4 bytes are missing (at the end) you can calculate it from the rest.
Second: in your picture it looks like your private key starts with an L. This indicates that the Bitcoin address is based on a compressed public key. Don't worry, this is a technical detail, but this helps you further:
Private keys for compressed pubkeys have another special byte added after the key (and before the checksum), namely a fixed 0x01 (see also in the reference documenation for WIF).
This means that the last 5 bytes of a WIF encoded private key (starting with L or K) are either static or can be computed from the rest.
So you are very lucky that the last 7 characters are missing (and not the first 7, because then you really would need to bruteforce 2 trillion possibilities).
What to do with this information:
If we apply this knowledge now to base58 we see that only a single character is missing and then we can calculate the rest.
Reasoning: first: a single base58 character carries ~5.85799 = log2(58) bits of information and second: we don't need the last 40 bits (4 bytes checksum + 1 static byte for compressed key are 5 bytes = 40 bits).
So, if only 6 characters would be missing at the end (6 * 5.85799.. = 35.14794) we not need to bruteforce anything, because this would be still less than the 40 bits we don't need.
Conclusion:
As you are missing 7 characters we just need to bruteforce one single character (and this means just 58 attempts, not 2 trillions).
So we just attempt to add one of the 58 characters from the bas58 alphabet. For each attempt we calculate the full base58 string by adding the static compressed key flag byte (0x01) and after that the checksum and simply compare it with the rest of the key you have. If it matches it is a valid candidate.
At the end of these 58 attempts you will end up with 2 or 3 (at most) valid private key candidates, and just need to check these 3 keys, to see which one belongs to your address.
The Reddit user /u/dooglus/ (not me) pointed out exactly this in the first place in his comment on your post and he also added a snippet of Python code which does exactly I've described above.
Don't trust anybody, don't hand out your key to any stranger!
Now take your time, learn what the Python script below does (don't trust me or any strangers) and when you feel safe, copy the Python snippet from /u/dooglus/'s comment, save it in a text-file named complete-wif.py on a safe computer. After that take the computer offline and run the Python script by typing this into a commandline:
python3 complete-wif.py L...-your-private-key-goes-here...yhub
and it will print 2 or 3 completed WIF private keys in less than 1 second.
Appendix:
For reference, I appended the Python script but it's not my work, all credits go to /u/dooglus/. I just can confirm that it does what I described above (but ask others to confirm this and try it with other private keys before you trust it with your real private key):
#!/usr/bin/env python3

import base58, sys

partial = sys.argv[1]

if len(partial) != 45:
    print("partial key should be 45 characters")
    sys.exit(1)

results = {}
for c in '123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz':
    wif = base58.b58encode_check(base58.b58decode(partial + c*7)[:33] + b'\x01').decode('ascii')
    if wif[:45] == partial: results[wif] = True

for k in results.keys(): print(k)

Thank you very much, I will try this method

Thanks for crediting me as you did. This whole question was only recently brought to my attention.

@chris-moore: of course, credit where credit is due. It was your work. You are welcome! :-)

It has to be brute forced. There are a couple of ways but basically it is replacing each character by base-58 chars and checking the key.
The amount of time that process takes depends on the number of characters missing and slightly on whether the key is compressed or uncompressed and a little on your luck.
However if your key is compressed and is missing up to 11 characters or is uncompressed and is missing up to 9 characters from its end (which seems to be the case from your screenshot) it can be recovered within seconds.
Check out FinderOuter on GitHub. The Missing Base58 option handles your case. You'll have to enter the characters you already have and replace the missing ones with a special char like * then enter your address in second box and click Find.
Full disclosure: I'm the developer of The FinderOuter.
P.S. The released version (0.4.1) is old and doesn't have the optimization mentioned above, you'll have to compile the code yourself or wait for 0.5.0.
Edit: Version 0.5.0 released on 2020-09-17 and can recovery this special case with up to 11 missing chars from end.

Unfortunately, I don't understand programming. My laptop has windows 10.

@gabalex: If I offered you a quarter of a million dollars to spend a week or two learning programming, would you consider it?

@RedGrittyBrick even if it took a year to learn enough to complete this task, thats still a great wage for the time spent.

Unfortunately, I don’t have the money and a quick fix would be good.

@gabalex You don't need to spend money to recover this wallet, you can learn all of those things on Youtube for free. Keep in mind that even if it takes a long time this is a lot of money, so it is worth it.


text:
How to make a taproot transaction with bitcoin-cli?
Can you give a simple step-by-step example for a taproot transaction with bitcoin-cli on Testnet?

There is the step-by-step example of spending from the  tb1p8wpt9v4frpf3tkn0srd97pksgsxc5hs52lafxwru9kgeephvs7rqlqt9zj
Taproot address to the other Taproot one: tb1p90h6z3p36n9hrzy7580h5l429uwchyg8uc9sz4jwzhdtuhqdl5eqmpwq6n.
$ ./bitcoin-cli.exe -testnet createrawtransaction '[{"txid":"8cdf19ed3ade4af038314ef58b116a523f99aa1c585ca3c157ce5386f9df6421","vout":0}]' '[{"tb1p90h6z3p36n9hrzy7580h5l429uwchyg8uc9sz4jwzhdtuhqdl5eqmpwq6n":0.00001000}]'
$ ./bitcoin-cli.exe -testnet importdescriptors '[ { "desc" : "tr(cV628xvqToz45dwdPmTcJ9RgEVnWMwP8dpZBGzb9LfTk3sBHFNwc)#8skcj28y", "timestamp" : "now" } ]'
$ ./bitcoin-cli.exe -testnet signrawtransactionwithwallet "02000000012164dff98653ce57c1a35c581caa993f526a118bf54e3138f04ade3aed19df8c0000000000fdffffff01e8030000000000002251202befa14431d4cb71889ea1df7a7eaa2f1d8b9107e60b01564e15dabe5c0dfd3200000000" '[{"txid": "8cdf19ed3ade4af038314ef58b116a523f99aa1c585ca3c157ce5386f9df6421", "vout": 0, "scriptPubKey": "5120c38859777bc9c3294d3587035fc3823a146dabaab1fa250bc04e92f16887a065", "amount": 0.00000000}]' "DEFAULT"
$ ./bitcoin-cli.exe -testnet sendrawtransaction 020000000001012164dff98653ce57c1a35c581caa993f526a118bf54e3138f04ade3aed19df8c0000000000fdffffff01e8030000000000002251202befa14431d4cb71889ea1df7a7eaa2f1d8b9107e60b01564e15dabe5c0dfd320140f10fc6bb1d414d4c888838fb6b1699c3e538331d32b64b5baf85c1cc34e2c43eb7bdd7a14fd4a4a07341d1b0390ad977be711bc49df786982243c6564a33f6b400000000

Note that the commands with arguments may not work from PowerShell. There is the Bash used in the example above.


text:
How can I know that a full node has finished the initial synchronization process?
I run a full bitcoin node. I launched it several days ago and it has consumed around 300 GB of traffic already which implies that it is about to finish the initial syncronization process.
Except for that implicit sign, is there a more reliable and concrete way of determinining whether or not a full node has finished the initial syncronization process? Is there a special RPC API call that would return "true" for that?

You can check three factors in the getblockchaininfo RPC call:
The result contains a count of the blocks in your chain, and the headers your node has received from peers. For a fully synchronized node, the number of blocks equals the number of headers.
Additionally, there is an initialblockdownload boolean in the response, which will be set to false once the node has caught up with the main chain.

is it normal that it's taken several days to syncronize a full node?


text:
Bitcoin Core resynching after updating from 0.19 to 25.0
Similar to this post after upgrading Bitcoin core from version 0.19 to 25, it is re-synching and ignoring the already synched blocks.
This is a quite a large version jump, there doesn't seem to be a difference in location of the blocks, is there a way to upgrade without re-synching?

Are you running a pruned node or a node that keeps the complete blockchain?

@Murch running a full node


text:
The Mystery: I've mined some BTCs with Bitcoin Core 0.9.0, however the system no longer synchronizes and in the blockchain the balance is zero
I got some BTCs using a Bitcoin Core 9 version beta, from August to December 2019, they are listed in my history as "generated" and with several confirmations with one, the balance appears in my system, however when I put the key or the hash on a blockchain explorer there is no balance.
Another problem is that my system is stuck, it doesn't synchronize anymore, I've tried using a 0.20 and 0.18 Bitcoin Core, I copied the wallet to the new systems but then the transactions appear without validation, even synchronizing the system.
Does anyone know what I should do?
Below some screenshots

Comments are not for extended discussion; this conversation has been moved to chat.

As outlined in the comments, there's a couple of possibilities here:

You downloaded a very old version of Bitcoin Core, and managed to end up on a private chain where CPU mining is possible, and the chain is still new enough that the block reward is 50 BTC
The program you downloaded is a Bitcoin clone and gives the illusion of paying out 50 BTC or more, while either stealing crypto keys from other wallets on your computer, or later on asking you to pay some kind of recovery or unlock fee to claim these mined coins.

In either case, there is no Bitcoin. The block reward has not been 50 BTC for many, many years now (it was 12.5 BTC in 2019, and is currently 6.25 BTC in July 2020). Regardless of what method you used to mine, it is simply impossible to have a 50 BTC block reward dated in 2019 on the Bitcoin mainnet.
In short, you're either being scammed, or are mining on a private Bitcoin network with no relation to the public mainnet.
As Murch said in the comments below, you should definitely NOT use any address generated by this software to receive Bitcoin from an external wallet, exchange, or other service. All of these will send you real, mainnet Bitcoin.
As your version of Bitcoin Core is, at best, on a private network, you will not be able to access any externally received coins until you move your keys into a legitimate wallet that connects to the public Bitcoin network.
At worst, you're running some form of malware, and any real coins sent to addresses generated by this software will be stolen by whoever wrote it.

You may want to add that this software should under no circumstances be used to receive actual bitcoin payments.

@Murch Fair point, editing it in

Good evening everyone. I understood perfectly the answers and doubts about the veracity of the operation, but I also found some articles talking about people who had BTCs in the same situation, so, aside from the criticisms and supposed arguments that it would be a fraud or maleware, someone in this group would have any idea , even if improbable, how could we move this over the network and get these credits for exchange?

You can't. Those coins don't exist. There is nothing you can do to make them exist.


text:
accept bitcoin payments for orders without 3rd party software
I've been searching for an open-source alternative to blockchain.info's Receive Payments API (https://blockchain.info/api/api_receive). I want to run bitcoind on my own server and have payments handled in my own database.
Is there any project in existence that is kept up-to-date with the current version of Bitcoin?
Searching here, github, and Google has returned me no results.

I don't think you need a third-party library if you have a reasonable level of programing experience.  (If you don't, you probably shouldn't be handling money directly.)
Here are the steps from the Blockchain.info (BC.i) page recreated for Bitcoin Core.
Get A Receiving Address
Use the getnewaddress RPC.  The JSON-RPC result will be a string with the address.
Get A Callback When An Address Receives A Payment
Use the -walletnotify bitcoind command line switch to run a program every time a wallet transaction is received, sent, or confirmed.  Your program can use the following commands:

gettransaction to get details about the transaction, including everything BC.i would've sent you and more.  (See link for an example.)  When Bitcoin Core runs the walletnotify command, it can pass an argument with the TXID, so you would run gettransaction <txid>
Something like curl to send an HTTP GET to your callback URL with whatever details you need

That's it.  As long as you can write a script that can parse JSON, you can do everything BC.i does with just a few lines of code.  That's also probably why you don't see any code on GitHub: it's too simple to make a project out of.
Before you get started, I highly recommend reading the Bitcoin Wiki proper money handling page to learn how to handle high-precision bitcoin values.  Also, if this is your first money-handling program, please remember the high stakes that come with holding on to money.  Hackers love stealing bitcoins.

Libraries serve many purposes, and there are good reasons to use them instead of building everything from scratch. I'm looking for something that's been tried and tested for at least one year. I could build it myself, but I'd rather start my next project using code that is more than 0 days old and has been tested more than 0 times. If it's true that this doesn't exist and everyone uses third party services (blockchain.info/bitpay/coinbase) for merchant processing, then what's the point of even using Bitcoin in the first place?

David Harding was not telling you to build everything from scratch, he was telling you how to integrate your app with bitcoind with a few lines of code.  It sounds pretty reasonable to me, except you should use a heirarchical deterministic wallet so that you only need one backup ever.

The Mycelium Gear is probably the most practical way to go. While technically it's a 3rd party, the money is not routed through them, and thus no KYC/AML, no censorship, and no commission. Mycelium Gear simply notifies you about the incoming payments based on your HD wallet xpubkey.
Alternatively, you can setup their open source software yourself.

Unlikely the OP is still waiting for the answer but the question remains valid and six years later community actually has some good answers.
Open source, self-hosted payment processors for Bitcoin:

https://btcpayserver.org/ - the most powerful one
https://cypherpunkpay.org/ - the lightweight one (disclosure: author here)

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


text:
does blockchain.info have everyone's private key?
I'm looking at blockchain.info's FAQ page, and they describe the wallet creation scheme here: https://blockchain.info/wallet/technical-faq (please scroll down to the Please describe the wallet creation routine. section)
Because their wallet encoding tool is in Javascript, which is clientside, the user can trust that the encryption key cannot be on the server because Javascript must be all clientside code?
Is there any server side method in which the site could maliciously collect this data, therefore compromising blockchain.info's integrity?
Could blockchain.info suddenly change a line of code in their javascript, for say, a few minutes, and begin storing the pre-encrypted data into their servers without many people noticing? They could use this method to collect private keys from random samples of people, and would likely get away with it.

The Browser extensions provide protection.  With the Chrome browser extension the javascript comes from the extension and not from blockchain.info website: https://blockchain.info/wallet/browser-extension

I had no idea this existed. This is certainly something that I will start using. However, I feel the majority of the users on their site who trust their javascript client could be at risk.

No, they have everyones encrypted private key. The private key get's decrypted locally on your client.
And of course they could change some lines of code and collect your private key. But this is true for every bitcoin client (thin client or not). That's why it is important to get the client binaries from trusted sources (and deterministic build).

What client binaries are we talking about here, though? When I sign up for a new account on blockchain.info, the entire process is on their web page. The javascript client that exists in the browser during account creation can be verified by binaries, I guess, but they'd have to provide the binaries for each page you visit every step along the way? Is this a common practice or even feasible?

The "binaries" in the case of blockchain.info are the HTML code for their site and the Javascript it uses. For desktop wallets, they are the distributed executables.

So everyone simply trusts blockchain.info with all of their money? I think it's likely that less than 0.10% of people actually check the Javascript on blockchain.info for malicious code.

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


text:
Where to advertise new bitcoin service?
i created new service which is using bitcoin for payment. I am bit struggling with Bitcoin community and don't know what to do next.
Recently i
- i added service to bitcoin.it wiki
- created announcement on bitcointalk.org
- added link to reddit /r/Bitcoin
Is there any other possibilities to let the Bitcoin community know about my service?

You've already made a post on reddit, made a thread on bitcointalk and added it to the wiki, but if you want to advertise it (as in paid advertising) then you can try the following sites:
coinurl.com - banner and text advertising, fairly cheap
bitads.net - you choose which sites you want to advertise on. can be quite cheap too
a-ads.net - no account system, just create a campaign and deposit. again, fairly cheap.
Bitcoin advertising are generally much cheaper than traditional advertising. If you accept Inputs.io, you can also get a free ad slot on Inputs' wallet page, and an instant payment button sounds perfect for selling digital files :)

If you have a service that accepts bitcoin, you should consider posting it here:
https://www.spendbitcoins.com
or specifically:
https://www.spendbitcoins.com/submit-place/


text:
Where can I trade BTC/USD with a small transaction fee?
I don't need a leveraged account. I just want to trade with real money.
The Mt. Gox transaction fee is 0.60%. Is there a place with a lower transaction fee?

related: How do you obtain bitcoins?

Base fees:

Mt. Gox: 0.6%
Bitstamp: 0.5%
Intersango: 0.65%
Bitcoin-Central: 0.498%

Can you update on the non-base fees?

@Pacerier feel free to edit my post

btc-e is a good choice for low fees.
https://btc-e.com/
Currently fees are set at 0.2%, The best available at the moment, although getting money in and out is quite tricky.

Can cost as low as you want, but if you can't withdraw...

You can buy bitcoins through Ripple:  https://ripple.com

Although the markets there for anything other than XRP currently aren't very deep and the spreads are wide. Hopefully this will improve in the future.


text:
How can I determine the number of confirmations of a transaction and its fee using the Blockchain.info DATA API?
How can I know if any given transaction has confirmations and has paid the miner's fee, using the BlockChain.info DATA API?

If a transaction returned from the http://blockchain.info/rawtx/$tx_hash endpoint has a confirmation, it will have a block_height member. You can then calculate roughly its number of confirmations by subtracting that value from the latest height retrieved from the http://blockchain.info/latestblock endpoint.
Code example, in Ruby:
#!/usr/bin/env ruby
require "open-uri"
require "json"
# call this script with `ruby block_height.rb <tx_hash>`
tx = ARGV.shift
puts "Getting info for #{tx}..."
j = JSON.parse open("http://blockchain.info/rawtx/#{tx}").read
if j["block_height"]
  b = JSON.parse open("http://blockchain.info/latestblock").read
  puts "%d confirmations" % (b["height"] - j["block_height"] + 1)
else
  time_since = Time.now.gmtime.to_i - j["time"]
  puts "It's been #{time_since} seconds since the transaction was created."
  puts "It's not been ten minutes yet!" if time_since < 600
  puts "It's due any time now." if time_since >= 600
end

Calculating the transaction fee is best done by summing the inputs and outputs of a transaction, then subtracting the inputs from the outputs. Difference is the transaction fee.

Hi Colin! Thanks a lot! Could you expand a bit on the block_height part?

Added a code example for you.

verifies but just out of curiosity, how do I explain the relations between the number of confirmations, the tx block height and the latest block height?

number of confirmations = latest block height - tx block height

I have created a simple php function with my basic knowledge of php.
here

function get_tx_confirmation($tx_hash_id){
      $raw_lastest_block= json_decode(file_get_contents("https://blockchain.info/latestblock"), true);
   $lastest_block=$raw_lastest_block["height"];
   $raw_tx=json_decode(file_get_contents("https://blockchain.info/rawtx/$tx_hash_id"), true);
   $tx_block_height=$raw_tx["block_height"];
       $confirmations = $lastest_block - $tx_block_height +1;
  return $confirmations;
      }

This is just to get the amount of transactions using the hash id


text:
Is there a secret number that is only known by the sender and the receiver after making a transaction?
After making a transaction and receiving all the hashes and ids, is there a number that is secret and only the two people involved in the transaction know?

Yes. You can view a transaction as being a public link between a number of public keys. If different people have the secret keys for those public keys then they have all the necessary information to calculate shared Diffie-Helman elliptic curve points. So in the simple case that you transfer all the bitcoins in an address to someone else's address then you can use his address and your private key to calculate a point which will be the same as the point calculated by him using his private key and your address. Nobody else can calculate these points.

Could you elaborate on how this works? In particular, is it a problem that an address is not itself a public key, but only its hash?

With current whitelisted scripts, all transactions (apart from coinbase) allow the recipient to obtain a public key where the sender knows the private key. You are right that if the coins are sent to an address from which there have never been any spends then the sender cannot complete their half of the key agreement until the recipient spends the coins or otherwise reveals the relevant public key.

The public key of the receiver is not in the transaction, only the public key of the sender.  The hash of the public key of the receiver is in the transaction, but I don't see how that is enough to make a shared secret.

No.
However, it would be possible to build a scheme on top of the public and private keys that they used to exchange a secret key, similar to how RSA/DSA is used to make session keys for encryption.

This would require the receiver to transmit additional information back to the sender, correct?

@JohnHenry: No, there are schemes that have no such requirement, such as ECIES, which instead require the sender to disclose a public key and to know the recipient's public key.

ECIES does establish a shared session key, but there is still bidirectional communication involved (one way is the disclosure of the public key, the other is the message + ephemeral key). In any case, I don't see how that is relevant here - the question is about Bitcoin transactions I assume.

@PieterWuille The question only asks about establishing a shared secret, which an ECIES session key is. So you would only need the part of ECIES that doesn't require any bidirectional communication.

No.
This is because the receiver does not play any role in the transaction. They don't even have to know about it. The transaction actually takes place between the sender and the bitcoin network, and the sender needs to have a private key which (hopefully) is secret.

There are schemes that create a shared secret without one party playing any role in the transaction.