I would say that the depth feed you are reading is of the orders coming in, before they are matched.

Those orders would feed into the matching engine which would make fair trades off those orders.

It is not possible to or desirable to make an optimal trade at any given instant. this can be due to network latency (etc)  and because someone might think it would be better to make a trade, that was slightly less than optimal, than to miss out on making a trade (but still not too much up or down);

For example:
What you will probably find is that if you put in an order to buy 10 btc at $100 but someone else has put in a sell order for 10 at  $99 you order will convert to a trade of $99. The buyer and the seller both get what they wanted.

Like wise if one seller was willing to sell 5 btc at $95 and someone else was willing 5 btc at $100 you would end up with 2 partial fills to complete the trade.

Back in the day on stock markets (i.e., not btc) the exchange (or broker) would just pocket the difference. However this doesn't really happen much now (in my understanding) as the markets are more efficient (fast traded data feeds & order placement + high liquidity)

At the end of the day both buyers and sellers get what they want, and because there is reasonable liquidity, speed and fast access to market information, people will not be making trades which are too different from what would be optimal.


A block chain is a transaction database shared by all nodes participating in a system based on the Bitcoin protocol. A full copy of a currency's block chain contains every transaction ever executed in the currency. With this information, one can find out how much value belonged to each address at any point in history.

If you are new to Bitcoin or have never worked with 'bitcoind' (the Bitcoin daemon with no user interface) then I suggest you start clicking (and reading) around on these sites:

en.bitcoin.it - A Bitcoin wiki

bitcointalk.org - A Bitcoin Forum

Unless one really dives into the source code of Bitcoin one can't really manipulate (or sometimes even view) a Bitcoin blockchain without running the Bitcoin software.

Most blockchain software is running a form of original Bitcoin software underneath the blockchain software.

If you are looking to try and do something like blockchain.info then I would suggest Abe to start with. Abe draws inspiration from Bitcoin Block Explorer (BBE) and BlockChain.info and seeks some level of compatibility with them but uses a completely new implementation.

If you are looking at Abe like it could be way over your head then try googling "bitcoin blocknotify" or "bitcoin walletnotify".

Block and wallet (and alert) notify is a parameter you can set in your bitcoin.conf file that will make your bitcoin wallet execute a script of your choosing and can pass the script an argument.


What other decentralized bitcoin / altcoin exchanges are there besides Bitsquare?

You can try https://localbitcoins.com
It is a p2p crypto exchange market that allows you to interact and exchange currencies with your counter-party directly, no intermediaries.

See also:

https://0xproject.com
https://etherdelta.com


How to calculate txid for segwit transactions?

The txid of a segwit transaction is computed by first dropping all the witnesses, and encoding it in legacy notation, and then computing the double-SHA256 hash of it.

This is the only possible way, as anything else wouldn't be compatible with old clients (which is required by it being a softfork).


Must my wallet be connected to the internet to receive payments?

No, the transactions are weaved into the blockchain by the p2p network of miners. That's what counts. Your address is only a keypair that proves you ownership. The concept of cold storage is exactly the idea to not connect to the internet so nobody can steal your coins (or rather, the key to access your wallet).


I have my wallet id and bitcoin address [...] how do i recover my bitcoin by using these?

You cannot recover control over Bitcoin using only a Bitcoin address.

You cannot recover control over Bitcoin using only a "Wallet-ID" you typically need a password also. But in the case of custodial wallets, the custodian may provide a means of recovery based on other information (e.g. an email address used for original registration). Note that custodial wallets are widely regarded as the least secure way to store Bitcoin long term. See What kinds of wallets are there?. Also note that private companies like Blockchain.com don't own either the Bitcoin system or the Bitcoin blockchain - they are just one of many businesses that offer services based on cryptocurrencies.

You generally need either

The Private Key in some well-known format (e.g. WIF) or
A seed recovery phrase (often 12 words from a special list)

If you don't have these, it usually means your Bitcoin are forever unusable.


As explained by Gavin Andersen on the forum - in order to calculate the ID hash of the Tx that is used in the Merkle Tree, one needs to SHA hash the whole Tx message as defined in the Protocol Specification wiki page twice.

For example, for the only Tx from the Genesis Block one would double hash the following array of bytes:

01000000010000000000000000000000000000000000000000000000000000000000000000FFFFFFFF4D04FFFF001D0104455468652054696D65732030332F4A616E2F32303039204368616E63656C6C6F72206F6E206272696E6B206F66207365636F6E64206261696C6F757420666F722062616E6B73FFFFFFFF0100F2052A01000000434104678AFDB0FE5548271967F1A67130B7105CD6A828E03909A67962E0EA1F61DEB649F6BC3F4CEF38C4F35504E51EC112DE5C384DF7BA0B8D578A4C702B6BF11D5FAC00000000

And if double hashed correctly, it would give the following hash:

4A5E1E4BAAB89F3A32518A88C31BC87F618F76673E2CC77AB2127B7AFDEDA33B


Is there a 64-bit port of the original software for windows?

Short answer: no.

Long answer: It's not likely to be necessary for some time.

There are still a considerable number of people on 32-bit Windows (~23% according to the Valve Hardware Survey, which paints a good picture of forefront computer enthusiast hardware, so the market share is likely to be larger among non-gamers).
Bitcoin-Qt doesn't yet push the limits of 32-bit memory address space. On my machine, Windows 7 64-bit, the program is consuming only ~128 MB of RAM while downloading blocks (haven't sync'd in a while). On my Mac, it's about 240 MB.
The type conversion necessary may be prohibitive, if there is significant code written specifically for win32. Qt itself is obviously working fine on 64 bit, as is the most of the bitcoind codebase. There may be things here and there to work out.
More likely to be prohibitive, or at least "not worth it", is the management of the release of another package. There's already five packages managed, so including another is just that much more.


Discrepancy between blockchain.info live unconfirmed transactions page and chart

You're not missing anything. If the two where sourced from the same full node, they should show the same data. It appears that there are two distinct sources used for the graphs.

By the way, the mempool chart indicates that the full node sourcing the chart was uncleanly shut down today, which is not reflected in the other unconfirmed transaction count. On a clean restart, the node should have simply reloaded the persisted mempool state, but instead the graph indicates that it took hours to build up transactions in the mempool. (Alternatively that full node predates Bitcoin Core 0.14.0 when the feature was introduced.)


What does a negative Ripple balance mean?

Ripple address r3AWbdp2jQLXLywJypdoNwVSvr81xs3uhn and you set up a trust line for 1.0 BTC in each direction. As part of some previous payment (not a trade), Ripple made use of that trust line just as it was told it could. If you don't want a negative balance ask people not to trust you :-). [As an aside, previous ripple implementations like classic.ripplepay.com required you to approve and limit what trust others gave you, it's more complicated and there really isn't a downside to people trusting you so ripple.com doesn't support that, at least not yet).]

Looking at the Ripple Live Graph... you currently owe the above address 0.1 BTC and you have 0.096+ BTC from WeExchange. For small amounts it's generally easiest to just leave it alone in Ripple rather than trying to zero it. The friend that has your IOU can use it to make payments through you and anyone that accepts your IOUs or that accepts any IOUs you hold.

E.g. If your friend had a WeExchange account (they don't trust WeEx currently so they may not) they could pay WeExchange say 0.06 BTC. Your total balance would stay the same but you'd owe the friend only 0.04 BTC and hold 0.036+ BTC from WeExchange. Your friend could pay their Bitstamp account too. In that case the payment would go through you, to rfTXGr6j9ExwSQd9NwRaLBCCa4VETr4GYu (who trusts you) and from them to Bitstamp. In that case the first friend would effectively be exchanging your IOUs with the second friend in exchange for their Bitstamp IOUs :-).


Multibit vs Electrum - which is more mature and secure?

At the moment the Electrum client is more secure as the wallets are password protected.

I am the lead developer on MultiBit and am working on wallet encryption but it will take me a few weeks yet. There are a number of changes to make.


Always when in doubt, check online block explorers (at least two as all of them are buggy to some extend and might freeze for some hours/days):

blockchain.info

insight.bitpay.com

blocktrail.com/BTC

etc.

...is your transaction there (you can search for your receiving address)? Is it confirmed? When it is not there at all you know it is not problem with your local wallet. If the tx is there you have probably problem with synchronization of your wallet - you can try to select different server to connect to (in Electrum's settings). You can also try running Electrum with different directory ('-D' command line parameter) to force it to download its metadata again and recreate your wallet from seed. You can also try to install Electrum on different machine & restore your wallet there. Maybe check your firewall, too.


How would debt work in a bitcoin only economy, and why would anyone ever spend?

Question: how is this planned to function in a bitcoin only future???

They can use their assets as collateral for the loan.

The price of Bitcoin (measured in chicken eggs, for example) doesn't necessarily need to increase when somebody takes out a new loan. The price of fiat doesn't change when people take new loans either.

(If workers become more productive and their pay correspondingly increases, the employer may require more money to fund their working capital, but their cost structure doesn't change - the workers help them earn more and the employer pays them approximately the same percentage of their earnings as before. There it is unlikely that everyone would have to use Bitcoin - if Bitcoin gets used on a large scale, that means multiple crypto-currencies would be in circulation.)

  Second Question - if what I suppose in the first question is in fact the vision (please correct me if im wrong!), why would anyone ever spend?

Gold mining generated approximately the same amount of new coins as Bitcoin mining and people would still spend their gold (and silver and stock certificates and diamonds and other savings and assets).

Things worked well before today's fake fiat money existed, and will work equally well after it gets destroyed.

You can learn about it from books and materials discussing how it was before central banks instituted state-sponsored plunder.


I've found what was wrong. It seems that technical info is not up to date to the current Bitcoin Core version (0.11.2.0). Since version 0.11 (12 July 2015) the minimum relay fee is 5 times bigger (from 1000 Satoshi to 5000) so the transaction has not enough fees to be relayed.

Here you could find a discussion about the topic.


Do I need to be already running a full node to run LND Lightning?

Using LND, you can use the neutrino client (which is a lite client). Instructions are available here.


Electrum Offline Storage - two different OS, multiple wallets

This can easily be done and due to Bitcoin mechanics, you are going to be pretty safe. Electrum wallets cannot be desynced, maybe become inaccurate but the same seed will always give you access to the corresponding wallet and its bitcoins. Electrum inaccuracies in balance and transaction history rectify themselves over time. Just restore from seed on the other computers to set your wallet up on multiple computers.

Why does this work out?

Bitcoin does a neat thing with transactions and history. I won't go into all of it but the blockchain makes working between two computers easy. Your seed is the deterministic private keys for 10 addresses on electrum. This will always be true, on any machine, anywhere in the universe (unless a bug breaks it on a computer).

As long as you have the private keys, you have access to all funds sent to the corresponding public addresses of the private key. Even if the wallet is offline and detached, it can still access value. Imagine the electrum seed as a key to a coin safe, you can have as many duplicates of key as you want, as long as they are identical they will open the coin safe.

The balance of your addresses are purely derived from info available to anyone on the Bitcoin network, your balance is not dependent on your Electrum program, computer, or identity. If you sent me an address, I could tell you the balance. To get your balance, Electrum queries the many Electrum nodes to sync up. The balance can be wrong on multiple computers but give it a few seconds to correct itself.


Other ways to determine the validity of a public key

You got the formula wrong.

The correct formula is

y2 = x3 + 7 mod N

where N is a very large prime.


How to unblock an account that is held to ransom

I have to pay 2140$ to get a private key.

That is invariably a solid indication you were the victim of a scam.

I did a trading agreement. The dealer put my profits into a mining account on Blockchain.

This is typical of scams and nothing like what happens with honest businesses.
Blockchain don't have a type of account called "mining accounts".
That isn't how Bitcoin mining actually works.
The "profits" are fake. Probably the criminal "dealer" set up a watch-only / non-spendable wallet to fool you into thinking the money shown belonged to you.

To retreive my funds I need to purchase a key from the dealer to have the funds released.

You are being cheated by someone dishonest. Keys are free. There is no such thing as a release fee in honest Bitcoin businesses.
The money you gave to the dealer was given to a criminal. Now the criminal is trying to get you to give them more money. Every time they succeed in tricking you they will invent a new reason for you to give them even more money. They will continue doing this until you either have no money left or realise that you are being tricked.

Is there any way to report this to Blockchain.

Blockchain.com and Blockchain.info are domains owned by Blockchain Luxembourg S.A. There is also a Blockchain Ltd mentioned on some of their web-pages but presumably this is a subsidiary company.
You can contact that European company through this web-page:
https://support.blockchain.com/hc/en-us/requests/new
The domain registrant is
Name:          Blockchain Admin
Organization:  Blockchain
Street:        Rue de Merl 74
City:          Luxembourg
Postal Code:   2146
Country:       LU
Phone:         +44.07476822631
Email:         email@blockchain.info

Note that the phone number looks like a UK mobile phone (cellphone), not a Luxembourg land-line.
The founder is Nicolas Cary, an American businessman.

If the wallet at Blockchain.com was created by the dealer, it is possible that Blockchain Luxembourg S.A. in Europe would not want to get involved in a dispute between you (a third party with no business relationship to them?) and their customer (the dealer). If the account was opened in your name, that might help to get them involved.
If you believe a dealer is holding your account to ransom, you should probably contact a lawyer or the police.


Bitoin payment sent and confirmed, but not received

UPDATE: Payment/transaction didn't disappear. After looking into this it turns out the PASTED VALUE of e9104412aac5327e5eaad31485335d822d5e7a22f00c370d8f055286ed02e187 has invisible ASCII characters in here. Looks like a color code or some conversion of the Byte array. The transaction IS valid, but copy/pasting from the question in this topic will result in invisible ASCII.

Example:

Bad: e9104412aac5327e5eaad31485335d822d5e7a22f00c370d8f055286ed02e187
Clean: e9104412aac5327e5eaad31485335d822d5e7a22f00c370d8f055286ed02e187

They look the same, but they are not the same. You can test this by putting your cursor just after the final 'e' (4th to last character in string) then hitting the left arrow (be sure to use the "bad" or original example above). You have to hit the left arrow twice between the '2' and 'e'. The cursor is navigating the invisible character.

Here is a C# example of how to find this:

static void Main(string[] args)
        {
            var x = Encoding.Default.GetBytes("e9104412aac5327e5eaad31485335d822d5e7a22f00c370d8f055286ed02e187");

            foreach (byte item in x)
            {
                Console.Write(item);
            }

            var a = Encoding.UTF8.GetString(x);
            var b = Encoding.ASCII.GetString(x);

            Console.WriteLine(a);
            Console.WriteLine(b);
        }

The result is:

1015749485252495097979953515055101531019797100514952565351515310056505010053101559750501024848995155481005610248535350565410110048506363101495655e9104412aac5327e5eaad31485335d822d5e7a22f00c370d8f055286ed02??e187

e9104412aac5327e5eaad31485335d822d5e7a22f00c370d8f055286ed02??e187

-------------------------END OF UPDATE-----------------------

It LOOKS like somehow the transaction ID is messed up. It's a transaction on the blockchain but at the same time it looks abnormal. All of these show and contain the transaction:

Longhorn.Bullpay.com - https://longhorn.bullpay.com/?gateway=2&data=e9104412aac5327e5eaad31485335d822d5e7a22f00c370d8f055286ed02e187
BlockCypher.com - https://live.blockcypher.com/btc/tx/e9104412aac5327e5eaad31485335d822d5e7a22f00c370d8f055286ed02e187/
Blockchain.info - https://www.blockchain.com/btc/tx/e9104412aac5327e5eaad31485335d822d5e7a22f00c370d8f055286ed02e187

However, they "search" function in 2 of them fails to see it as a valid transaction (reported it to both). Was able to get to them by going to the wallet itself and finding the transaction. So while it is being consumed by looking at a raw block, the transaction ID itself is jacked up in some way.

This MAY mean, that your wallet program is also having a hard time seeing that transaction (even though it submitted the transaction to whatever node generated that transaction ID). It does exist and an expert should be able to form and submit a valid transaction to the blockchain using the UTXO's from it.

Without knowing more like what wallet is being used, the functionality of that wallet, in a general sense i would import that address into a more flexible more advanced wallet to see if it picks up the transaction. If it does, spend the UTXO's and stop using whatever wallet resulted in the malformed transaction ID. The node would have provided the transaction ID when it was submitted. So this is dependent on the wallet setup and what node setup the wallet used to cut out the "messed up" aspect.

Beyond that an expert in recovering this type of thing (assuming you still have ownership of it) should have no problem if you have access to the wallet and are willing to provide the information.

Note: This is not an endorsement of any particular recovery service (i listed none) or action you should or should not take. I've listed here some possible options to recover the coins from a wallet program that fails to see a particular transaction.


Assuming you are checking the balance using MultiBit perhaps your missing coins are sitting in a change address - when you send bitcoin often some coins are moved to a newly generated change address, so you would need to export more than just the one address.

Fire up bitcoincore again and check the other receive addresses in a blockchain explorer for balances.


Best resource is the book "Mastering Bitcoin" by Andreas Antonopoulos. You can find it online at https://bitcoinbook.info. You can download it for free on github. The book explains everything in a structured and easy-to-process way.


How does Chaum style e-cash work? (all the Wiki links are broken)

Here's the basic idea of blind signing in Chaumian e-cash:

Let's suppose that a central issuer (Chaumian e-cash is centralised) has an account in my name with a value of 10 dollars.  In order to "withdraw" this money as 1-dollar "bills" I begin by generating ten random serial numbers, each long enough that I can be reasonably sure no one else will generate the same numbers.

I am going to have the central issuer sign a message saying these are now worth one dollar each, only I don't want the issuer to know which bill is which (otherwise they could just match up outgoing and incoming serial numbers to know who I spent it with, since Chaumian e-cash can only be spent once before it has to be re-issued).

So in addition to the serial numbers I also choose secret 'blinding factors' and combine them with my serial numbers.  I give these blinded serial numbers to the central issuer, and they sign each one with their 1-dollar key (they have different keys for different denominations) and reduce the amount in my account with them accordingly.  They know how many 1-dollar bills they signed, but they don't know what serial numbers were on each bill they signed.

Now, the trick with "blind signing" comes in.  Because of how blind signing works, I can now remove the blinding factor, but I still have a valid signed message which can be verified using the issuer's public key.  This gives me a signed one dollar bill with its own serial number that the bank doesn't know (but they do know how many one dollar bills they have signed, because each one can only be un-blinded to a single serial number).

Now, to spend the bills to someone else, I simply show them the un-blinded, signed serial number.  They must now immediately "cash in" this token by going to the central issuer and showing them the signed serial number.  The central issuer verifies the signature using their "1 dollar" key, records the serial number, and credits the new person's account.  From their perspective, this dollar is indistinguishable from any other they have issued in the past.

However, if someone else shows up and tries to cash in the same dollar again, they will not honour it because they have already recorded the serial number as spent.  You also cannot spend a $1 serial number as a $50 serial number because $50 serial numbers use a different key.

More details about e-cash, including an "offline mode" that relies on trusted hardware, can be found here.  They use a different method of ensuring a $1 bill is not spent as a $50 bill--I don't remember which variant is whose but there are several of them which basically accomplish the same thing in slightly different ways.


Tracking the wallet owner of stolen bitcoins

Every Bitcoin transaction is traceable, but... unfortunately, it is not possible to determine who owns the address. Unless somebody admit to having a particular address.


The mining process is similar to a brute force attack and, assuming you already appreciate the nature of such attacks, mining is computationally intensive.  More specifically, mining involves repeatedly, and as fast as your computer allows, guessing at the solution to a problem that cannot be solved quickly by the human brain.  There are now dedicated computers, made specifically for the Bitcoin community, able to make billions of guesses per second.

The mining process is hard by design as it does make the Bitcoin generation process harder, almost like mining for gold.

The mining activity cannot be substituted by other hard labors in the physical world.  BUT, you can buy Bitcoins on an exchange with the dollars you earned in the physical world.


Have there been reports of botnets mining Bitcoin / crypto-currencies?

First report about mining botnet was made at the end of June, and it evolved rapidly from CPU to GPU mining. But there is no consensus about what kind of harm it will do to Bitcoin, because from the bitcoin network point of view, infected computers run legitimate mining that supports network operation.

17 Jun 2011 - Symantec suggested that it would be profitable to
run CPU mining botnet.
28 Jun 2011 - Kaspersky Lab's expert Alex Gostev made first
report about simple CPU mining botnet found in the wild.
2 Aug 2011  - F-Secure reported about discovery of advanced CPU
mining botnet controlled via twitter.
11 Aug 2011 - Symantec discovered first GPU mining botnet called
Trojan.Badminer.


From my experience the bitcoin wallet can only use listunspend with known addresses and keys. One can import keys or addresses, addresses without keys will be watch-only addresses. I am not sure if txindex=1 is required though (with a rescan of the blockchain). See here and for txindex also here.


With Ripple, what is "Close Resolution?"

Ledgers do include a close time because it is expected that contracts will be able to support things that can "expire" such as escrow. However, validators might see a ledger close at very slightly different times owing to their slightly different network views and errors in their clocks.

To resolve this, Ripple uses a close time resolution. Validators announce the close time they actually saw to help their clocks stay in synch, but they only try to reach a consensus on the rounded close time.

If validators ever fail to reach a consensus on the close time (and this has happened a few times), they agree to disagree, indicate this in the ledger, mark a close time one second greater than the previous ledger, and (if it keeps happening) raise the close time resolution to make it more likely they'll agree.

If validators consistently do agree on the close time and the close time resolution hasn't reached the minimum (10 seconds, I believe) it will decrease until it reaches that minimum.


In Proof-of-Stake, can a block creator fudge the block hash?

Absolutely. ECDSA signatures at not unique, they can always be permuted by the signer at will by re-signing with a new nonce. The creator of the block can also choose to reorder or omit transactions to alter the block and then re-sign this to get a new block hash.


What is the longest known vanity address generated?

It's impossible to say for sure what's a vanity address and what's generated purely at random, but 1CFBdvaiZgZPTZERqnezAtDQJuGHKoHSzg is 34 characters with no digits in it other than the initial '1'.  That may well be a vanity address.  Then again on average 1 in every 515 34-character addresses you generate won't have any digits in them other than the leading 1, so possibly not.

The address with the longest initial list of lower-case letters is 1yaniraswqyghuJKCRrGwJUA2HakWtRad, and is clearly a vanity address since it appears in the same transaction as many other vanity addresses.

Edit: I just found this one:

1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX

It belongs to etotheipi, author of the Armory Bitcoin Client, and was found using vanitygen, as he said in a bitcointalk forum post:

  Yessir!  I got a little crazy with vanitygen and succeeded.  It
  should've taken about 70 days of computation time but I got lucky and
  found it in about a week...  (notice no digits either, only uppercase
  letters).

  Unfortunately, it's so cool that people don't even recognize it as a
  Bitcoin address :)


I try to help a bit on the question, there is more than it seems:

1.) transactions are basically a transfer of value from one address to another address. When a transaction is sent to you (to your address), then it should have a confirmation in one block, before you can spend it. The miner basically takes all transactions, verifies them for correctness, and puts them into a block.
If you don't wait for a confirmation: the use case would be like this:

your wallet get's notified, that a transaction has been sent to you, and you don't wait for the confirmation. You try to spend the fund of this tx for s.th. else, send it into the network, and you will remark, it does not get confirmed. This might happen, because the original sender has sent another transaction with the same origin of funds to another address (not yours). So in this case, you would "believe" to have received funds, but you actually don't have the funds. It's a trust issue. In general it is said, that 6 confirmations (after ~1 hour) make it sure, to spend the funds.

2.) You are right, it is not in your control. The miners make sure, that the network is working correctly, and security is kept to the highest level. So they provide a service, and get payed as incentive with block rewards and fees.


i have 0.10096 mbtc (0.00010096 BTC) in my btc wallet but when ever i try to send bitcoins it always says your balance is low to pay the fee

The fees you may pay for a transaction do not depend on the amount to be transferred, but to the transaction size. Transaction size highly depends on the number of inputs and outputs, as well as the type of those.

For example, a normal Pay-to-PubKey-Hash (P2PKH) transaction with a simple input, lets say with the exact amount you referred to (0.00010096 BTC), will pay less fees than a transaction with the same amount but 2+ inputs.

Can it be that you have such amount of bitcoins spread in really small amount transactions?


How to quickly get the balance of any bitcoin address? (with no third-party API)

There is no way to enable faster querying for arbitrary addresses than scantxoutset in bitcoind.

Explorers provide this functionality by maintaining a separate database of all addresses and transactions which is optimized for that kind of query. Bitcoin Core, on the other hand, is optimized for consensus related queries, which are largely a hashset lookup for a given input for a transaction.

You could try running something such as ElectrumX, which backs the electrum wallet, or Bitcore, which backs many of Bitpay's wallet and explorer services.


(dis)Advantages of migrating funds to segwit?

I am assuming that keeping coins in 'legacy' format would still be cheaper in terms of future spending since the miner fee for moving to a segwit address would still be significantly higher than any future potential gains. Is this correct?

You still need to move the coins eventually, and the potential gains will be nullified by the fact that you still have to pay BTC in order to move the coins. The amount you pay will probably still be the same amount whether you move the coins now or move them later.

You can also just be very cheap on your transaction fees. Just pay a very low fee rate. Your transaction will take a long time to confirm, but if it's just for cold storage, there's nothing to worry about there.

  Among current downsides to migrating to segwit wallets I see incomplete support in existing apps, eg Mycelium won't work with a ledger nano/trezor if it is configured as segwit.

If you aren't planning on spending your Bitcoin, then that doesn't matter. Just use software that supports segwit. If you want to be compatible with non-segwit wallets, use a P2SH nested segwit address.

  Can segwit be considered ready for use?

Yes.


How to split BTG in electrum and send to new ledger nano s wallet

The steps you stated look good to me. It would be prudent to wait for a few confirmations of your BTC transactions, to make sure your BTC are safe, before exporting your private keys from electrum.


Deeper understating of blockchain forks.

Short answer is no.

Forks

A fork can mean that you "forked" the code on a repository, meaning you copied it and modified it for your own use case. It can also mean that the blockchain network itself "forked" when it split the blockchain and the network adopted two different chains and usually code and rules as well.

  Is it possible to use Dogecoin on Litecoin network without converting through an exchange?

Because two different blockchain networks have 2 different blockchains, they have different sources of truth.  One transaction on the forked chain isn't necessarily considered valid on the other (especially if they happened after the fork) because they are reaching consensus on separate blockchains.  See this related question: Can I do a replay attack to spend my testnet bitcoin on the mainnet?


BFGMiner, what will be displayed when solo mining?

It could be bitcoind: Long Polling is enabled on BFGMiner by default (at least on *NIX), as it's rather useful for pooled mining. But bitcoind seems to not support it yet, so you'll need to disable it. That can be done with switch

--no-longpoll

And you might try

--no-getwork

And/or

--no-gbt

It could be a driver: The Block Erupter COM can be downloaded here.

It cold be your .conf: I don't see why you're using the -G switch. You aren't GPU mining. I also don't even see --icarus-options 115200:1:1, or --icarus-timing 3.0=100 as applicable options as per this GitHub readme.

It could be permissions: If none of that helps, the documentation says

  To use ASICs or FPGAs, you will need to be sure the user BFGMiner is running as
  has appropriate permissions. This varies by operating system.

This was mentioned specifically toward Gentoo and Ubuntu, but it might apply to Windows as well. You might need to run BFG as Administrator. (My Windows experience is lacking though, so I'm not sure.)


Which country has the most friendly regulatory environment?

Great Britian is a country that many companies moved their bitcoin related business to. One of the the best countries that respect privacy is Switzerland.

There are some tax-heaven type countries that have pro-bitcoin policies.

If you count it toward country Liberland is probably most friendly.

In this article you can find various contries with an explanation.


Why are there so many opcodes in Bitcoin Script, but they are not usable

Those opcodes can be used in non-standard scripts as part of a Pay-to-Script-Hash address. They can be in the redeemScript of the P2SH address and be standard.

Furthermore, standardness is not something that is set in stone; it is not a consensus rule, rather it is node policy. So in the future, we may create new script types which become standard that use other opcodes. Such scripts may be non-standard now (as P2SH and Segwit were in the past) but can become standard in the future. Those opcodes exist so that we can make scripts which perform smart contract-like things without needing a fork.


as explained here I showed that the betweeness centrality of a node on the fee graph is proportional to the expected routing fees which again is proportional to the throughput of your node.

So taking your throughput and dividing it by your betweeness centrality score should give you a rough estimate of how much throughput is handled by the network.

That being said. The betweeness centrality is constantly chaning as well as routing fees. Also the entire argument assumes a uniform distribution of sender, receiver pairs (which is highly unlikely) Other than that there are no verifiable sources you can use. You will however find people publishing their logfiles or some statistics. All of that information has to be taken with doubt though


ZeroMQ Notifications in Browser JavaScript

If I understand this correctly, you're trying to communicate with Bitcoin Core through ZeroMQ directly from the browser.
This is not possible.

The reason why JSMQ only supports Websockets (ws://) is that browsers don't allow you to use raw TCP sockets. The only protocols you can access from within the browser are HTTP(S), Websockets, and WebRTC (which is still not supported everywhere).

In other words: the browser won't let you communicate directly through ZeroMQ.

If you don't want to rely on an external API, then you can always write your own and run it on the same server/computer where you are currently running Bitcoin Core.
This software should receive updates from the Bitcoin node through ZeroMQ, and send them to the browser via websockets.

As long as it supports websockets or HTTP(S) you'll be able to connect to it from within your browser.


Who are you solving algorithms for and why?

The algorithm of choice is two rounds of SHA256, which has completely arbitrary outputs and a massively unsearchable output space. To this end, there is no data mining or valuable calculation actually being done. Here's what's really happening:

Every so often, the rules of the Bitcoin protocol set a difficulty number. This number sets a sort of target for a value miners are looking for. Since the output of SHA256 is essentially random with respect to its input, miners are all just looking for some random value in a given field that makes SHA256(SHA256(x)) return a value within a specified range. Such a value is considered a "solution" to the mining problem, but really it's less like math and more like throwing darts while blindfolded until you hit the bullseye. The changing difficulty number ensures that block solutions will be found at regular intervals no matter how many people are mining.

This solution does not hold any valuable data or information of any kind, except that it proves that someone somewhere had to have done a lot of work to find a value that produced the desired output. This also means that for someone else to fake that data they would also have to do a lot of work.

Since each block of data references the block before it, these hashes - and the work it took to create them - also stack up, meaning that older data would require a TREMENDOUS amount of computational power to falsify, since you'd also have to falsify every block that came after it, faster than the entire network combined is solving new blocks. This is the entire underlying security mechanism of Bitcoin: Data in the Blockchain represents a consensus and this is the way a network of people with no other trust mechanism reach a consensus.

This is likely why you've had such a hard time finding an answer to your question: There isn't anyone you're solving algorithms for and the only "why" is "because it's hard work, and fraudsters would have to do more hard work than everyone else combined to lie to the network."

Finally, as to the "someone thinks this is worth a lot of money" - there are two sources of mining income. The first is transaction fees paid by those whose transactions are in the mined blocks, which seems pretty reasonable given that the miners' work is the only reason that data will be trustable. The second is the block reward.

One of the more difficult problems to solve when decentralizing a currency is deciding who gets the initial run of the stuff. In this case, it was decided that the miners who are doing valuable work to secure the network should receive that initial issuance, in the form of a "block reward." Every so often this reward is cut in half and eventually it rounds down to zero. At that point all 21 million bitcoins that will ever exist will have been mined and the only reward miners will continue to receive is the transaction fee.


What is the quickest way to bring a bitcoind node up handling 99% of edge cases?

The problem is less so with validating the blocks and more to do with bandwidth constraints and the time it takes to write blocks to disk and update the databases.

As you sync more of the blockchain, the blocks become bigger and contain more transaction inputs and outputs. The outputs need to be added to the chainstate database and the inputs removed. This takes time especially as the database grows and the number of inputs and outputs per block increases. Even if you were to disable all block validation completely (which is not possible), it would still take a long time to build this database.

The best that you can get is to use the assumevalid=<hash> startup option. This can be added to your bitcoin.conf file or used in your startup command. What assumevalid does is it skips script verification for blocks that are ancestors of the block with the hash <hash>. Bitcoin Core already comes with a default value for this that was set before the last major release was made. You can set this value to a more recent block and get some performance improvements for blocks that have been mined since the last major release.


The probability that the entire network generates at least two blocks within 10 minutes?

Since current hashrate and current difficulty level should be matched up usually, we can disregard them. (Although, we could easily accommodate them if they are diverging as well.)

Finding blocks is a Poisson Process.

The chance to find at least two blocks in ten minutes is "all cases" excluding the cases where we find 1 and 0 blocks: P(2+) = 1 - P(1) - P(0)

P(0) ≈ 0.368
P(1) ≈ 0.368

→ P(2+) ≈ 0.264 = 26.4%

I've described the formula here: How can we be sure that a new block will be found?


If you control that address then you should be able to spend any bitcoins sent to it. Make sure that address and its private key are added to your wallet and you should be able to spend those coins.


Do you pay verification fees in an exchange?

That exchange takes place entirely on the exchange's books. Miners don't verify those transactions. Someone will pay transaction fees when you deposit or withdraw to and from the exchange.


Updating my online wallet to not rely on the Blockchain.info API

I do not want to use third party services or APIs like Blockchain o
  Coinbase. I do not want to download and process all the Blockchain.

If you don't want to use 3rd party APIs, you should have your own node which requires downloaded the full blockchain. There's blockchain torrent https://bitcoin.org/bin/block-chain/ that speeds up the download process, and there's advanced Bitcoin node libraries like http://bitcore.io that integrate with Bitcoin core.

There's more reliable blockchain as a service like BlockCypher https://dev.blockcypher.com which is programming language agnostic. I use it all the time and I am satisfied.


Why isn't transaction replacement supported?

That's not correct. The nLockTime field is implemented. It was deliberately switched off some time ago in order to reduce the complexity of the protocol. The reason was a series of protocol-based attacks that had compromised the integrity of the system.

At some point the feature will be re-activated. Probably, after someone has written a comprehensive test suite and technical analysis showing that it's not risky to re-enable.


Bugs can be reported at https://github.com/luke-jr/bfgminer/

Please run with --log-file debug.log --debuglog -P and upload the entire file to Dropbox (or equivalent); if you have sensitive information (passwords?), be sure they are not in the log file before publishing it.


When Bitcoin was invented, Blockchain analysis was not as advanced as it was today and pseudonymous transactions were believed to be closer to anonymous than they are with Bitcoin today. Under the current Bitcoin system, privacy can be greatly improved by avoiding fiat entry/exit ramps connected to your identity and by avoiding reusing BTC addresses.

Yes Bitcoin transactions for the coffee shop you describe can easily be tracked. As you mentioned, stealth addresses can bring privacy improvements but not ideal for every situation. Once Confidential Transactions are added to Bitcoin (https://bitcoinmagazine.com/articles/bitcoin-privacy-confidential-transactions-feature-can-fix-some-of-coinjoin-s-problems-1457703275), privacy will improve but still not meet the level of the top 2 decentralized solutions solutions described below:

Ring signatures exist already with Monero and Ring Confidential Transaction (RingCT) is one of the most promising areas of privacy development: https://eprint.iacr.org/2015/1098.pdf
ZCash is another leading alternative if the market is satisfied with its trusted setup solution and developer mining reward share: https://blog.okturtles.com/2016/03/the-zcash-catch/


Can I retrieve funds in a derived address with a high index?

Yes, just use something that lets you generate addresses with a high index. For example, you could use https://iancoleman.io/bip39/ and enter into the starting from index box the index you would like to begin deriving addresses at. Then you can get the private keys and import them into your wallet.

IIRC there is not a wallet software that will let you specify where to start deriving addresses.


Is it possible to detect if flag -txindex is enabled using RPC?

You can use the getindexinfo RPC call to list (and get the status of) all the available indexes since version 0.21 (currently in rc3).
On my local bitcoind with (only) txindex enabled, here is the output:
$ bitcoin-cli getindexinfo
{
  "txindex": {
    "synced": true,
    "best_block_height": 660887
  }
}


Is there a way to automatically send bitcoins from one wallet to another?

You may use /etc/crontab on your Ubuntu:

* * * * * root /usr/local/bin/bitcoin_resender

And script shall looks like:

$ cat /usr/local/bin/bitcoin_resender
#!/bin/bash
if [ $(echo "$(bitcoind getbalance) > 0" | bc) -eq 1 ];then
      bitcoind sendtoaddress YOUR_NEW_ADDRESS $(bitcoind getbalance) "Comment for resender"
fi

It will check every minutes your bitcoind balance and resend each bitcoins to YOUR_NEW_ADDRESS.


AML laws seem to be very erratically enforced

Your question is almost meaningless unless you specify which country's AML laws you are interested in. Some potentially useful pointers:

US Federal Regulation 31, especially Part 1022 about Suspicious Activity Reports
German Gesetz zum Aufspüren von Gewinnen aus schweren Straftaten (Geldwäschegesetz), which translates roughly into Law towards Detection of Profits from serious Crimes (Money Laundering Law).

There is also the question of how to apply these laws. In the US, FinCEN's guidance on Bitcoin (FIN-2013-G001) has a statement that indicates FinCEN views bitcoin exchanges as Money Service Businesses (to which above FR 31, Part 1022 relates). I believe there are multiple interpretations of whether this would apply only where real currencies enter, or if the bitcoin side alone is enough to qualify.

Beyond all this is the practical, rather than legal necessity for customer identification. If an exchange allows anyone to do business on your exchange, you may attract the kind of illicit business that its bank's more elaborate AML procedures might flag as suspicious---which may be one explanation why bitcoin exchanges have, historically, run into trouble with their banks, often getting their accounts closed and having difficulty to find new banking. Dreaming of starting my own bitcoin exchange, I had decided I would need some identification due to these practical issues even before I learnt of legal AML requirements.

I do not think your premise that only MtGox requires identification is correct. I suspect all of their competitors do, even for only handling bitcoin. For their biggest competitor, Bitstamp, I am actually rather certain that they do. However, some of them may have been slower in adopting such measures, and indeed what exactly is required varies, both from country to country and from business to business as some of the anti-money laundering laws seems to require effective measures rather than prescribing anything in particular. A company with more data on their customers or more insight into how to second guess what of their behavior may be suspicious might get away with more selectively seeking information.

Finally, let me address the erratic enforcement you hinted at. Is there any chance you could supply more information about what that term describes in your mind, what led to the idea, etc.? I agree that, at least in the past when apparently no bitcoin exchange even tried to identify their clients, they would, in retrospect, appear to probably have been breaking some kind of legal AML requirement. However, this retrospective outlook is probably unfair and the wrong standard to apply; after all, bitcoin and the comparatively small market was hardly seen as "financial" back then. Law enforcement action, as we have seen in a few cases, naturally depend on police or other government agents becoming aware of the violation, and on a local prosecutor to decide that the specific case is worth pursuing. Whilst a standard involving no chance and no human element might seem best theoretically, I suppose that is not practically possible in our world, or at least not in our legal systems. So if you are talking about erratic actions by the authorities, then I suppose I can only point out that they must proceed on a case-by-case basis---to my own regret, considering I wish for a level playing field for all bitcoin exchanges.


What if you're not given an option for a transaction fee?

As Nick says, there really isn't anything you can do by yourself. The transaction fee has to be included when the sender creates the transaction.

There is a provision for transactions to be confirmed without fee, based on a "priority" measure that depends on  the size of the transaction, and the length of time since those coins were previously spent. As such, the priority increases over time, so the transaction should eventually be confirmed, though the length of time depends on the size of the transaction. (The size may be larger than the amount due to you, if it includes payments to other people or  an amount being returned as "change".) If you have the transaction ID, you can look it up on a block explorer like blockchain.info  and see the priority.

If it doesn't confirm in a reasonable length of time, all you can do is take it up with the ATM operator. In principle, they can try to retract an unconfirmed transaction (by double spending) and issue a replacement or a refund.


Why am I able to export private keys using my seedless online Electrum wallet?

this was a gui bug; the menu did not really export private keys.

fixed here: https://github.com/spesmilo/electrum/commit/3fc7d0ef9e34465a47017ffa1f567d829aa0f2a2


To answer your first question:

A P2SH transaction activates a special rule in Bitcoin nodes. When a Script_Publick_Key comes with this pattern:
OP_HASH_160, <HASH>, <OP_EQUAL>
 then the node runs the information in a different way.

First, it runs as it usually does. It puts the ScriptSig on top of the Script_Public_Key. The ScriptSig must follow this form:

OP_0
<Signature 1>
<Signature 2>
...
<Signature (m)>
<SerializedRedeemScript>

Due to Script rules of evaluation, the first item to be evaluated is going to be the <SerializedRedeemScript>. If the hash160 of this serialized script matches the hash in the Script_Publick_Key then the first round is valid and older nodes would stop here. However, BIP0016-compliant nodes will later interpret the serialized version of the redeem script (<SerializedRedeemScript>) as actual Script commands, and the process will repeat this time with the redeem_script commands and the ScriptSig but without the <SerializedRedeemScript> since it was already consumed during the first round of validation. So, let's talk about this redeem_script.

The redeem script must specify how many private keys can sign a transaction (n), how many signatures are necessary to legitimately sign a transaction (m), and all the public keys that corresponds to the private keys that can sign the transaction. The form of the redeem script is as follows:

<OP_m>
<PublicKey 1>
<PublicKey 2>
...
< PublicKey (n)>
<OP_n>
<OP_CHECKMULTISIG>

Since we have only consumed the <SerializedRedeemScript> in the first round of validation, then we still have our OP_0 and signatures left, and the final stack of commands, which is a combination of the redeem script and what is left from the ScripSig, will look like this:

OP_0
<Signature 1>
<Signature 2>
...
<Signature (m)>
<OP_m>
<PublicKey 1>
<PublicKey 2>
...
< PublicKey (n)>
<OP_n>
<OP_CHECKMULTISIG>

The first OP_0 is necessary although it has no meaning at all. It is necessary because of a bug called Off-By-One bug. This was done by accident by Satoshi Nakamoto.

The signatures and public keys will be evaluated by the <OP_CHECKMULTISIG>.

How can i verify that this is a correct partial signature (N 2 of 3) P2SH transaction.

If you want to check signature by signature, then you can try to do this by first calculating the transaction hash (z) and then checking your single signature with each one of the public keys from the redeem script through OP_CHECKSIG instead of the OP_CHECKMULTISIG. If your signature is valid for a specific public key then your signature is valid. If your signature is not valid for any of the public keys then it is not valid.


If the mathematical problems done by miners had value by themselves beyond blockchain purposes, a miner could work on two parallel blocks at the same time to try to pull a double spend, without losing much money with electricity, bandwidth and other mining costs.


How do HD wallets use mnemonic to recover all private keys?

mnemonics are the seed. you use that to get your private key.

the rest of the story as you have pointed out, is about deriving child key pairs. The process is deterministic (as the letter D in HD), meaning that you can get the same tree of child keys from the root seed whenever you do that. This could go "indefinitely", so how would you know when to stop? The answer is that you need additional information about the depths.

In the case without branches, you simply need to know how many keys have been generated (whether they received payment or not) to get the full balance. Most implementations of default look-ahead and will stop checking after a certain number of addresses don't have any UTXO.

With branches, it gets a bit more complicated. But in theory, if you know where things branch and how deep it go, you can restore the full tree.

[EDIT] in response to your comment, there are standard ways though. For example, this picture here shows the hierarchy.


How to access bitcoin wallet on an android that became unresponsive?

It's not possible to answer this question without knowing what's wrong with the phone. Your best bet might visiting a repair shop. Tell them you need the data on that phone.


Why wait for several confirmations before shipping?

After one confirmation, the transaction is very unlikely to be double spent. However, each further confirmation reduces the probability exponentially. Basically, the number of confirmations provides additional security that the transaction will not be reversed.

One reason a retail store or individual might wait for more confirmations to ship is time; it only takes an hour for 6 confirmations to go through, which is negligible time for shipping a product, but can provide assurance to the seller.


Can't understand arbitrage profit calculation

As explained by http://www.investopedia.com/terms/p/profit.asp:

  profit = total revenue - total expenses

or in plain English:

profit = (what you had received after selling all your coins) - (what you had paid to buy your coins)

so, for example:

If you had spent $1000 for Bitcoin priced at $500/BTC on exchange A, and say the fee is 1%, you will received

$1000/$500*(1-0.01) = 1.98 BTC

If you move and sell your 1.98 BTC at for $600/BTC on exchange B, which also charges a 1% fee, you will receive

1.98*$600*(1-0.01) = $1176.12

So your profit will be

$1176.12 - $1000 = $176.12

Remember to also subtract any withdrawal/deposit fees if applicable.


Why are Electrum 2.x mnemonic sentences thirteen words long?

The seed phrases in 2.0 are longer because 8 extra bits are required in order to store the seed version number. (default entropy is 128 bits)

Note that the number of words in the seed phrase depends on the size of the wordlist used in the generation. Currently, the English wordlist used in Electrum has 2048 words, which results in 13 words per seed phrase. This wordlist can be extended in the future, for example 2581 words would give you 12 words per seed.


Why does this document seem to imply that the birthday attack only works for multisig P2SH and then only for one of the signers?

The birthday attack (to the best of my knowledge) requires that the P2SH address is constructed from a script which involves both a key of the victim and the attacker. That is typically only the case for multisig, but is not technically restricted to it. It does not apply to single-key scenarios.

  If an attacker can generate an alternative redemption script that happens to hash to the value given in a P2SH output

That is called a preimage search, not a collision search.

Preimage search: given a hash H, find X such that Hash(X) = H.
Collision search: find an X and a Y, such that X != Y and Hash(X) = Hash(Y).

A preimage search for a 160-bit hash function needs 2160 steps. A collision search however only needs 280 steps.

  Am I misreading the document or misunderstanding the nature of the birthday attack?

I believe you are. I'll start with explaining a simplified (infeasible) attack in a 2-of-2 multisig situation, and then optimize it and generalize.

Example

Say you (A) and me (B) are engaging in a 2-of-2 escrow. This means that someone (possibly one of us) is going to send money to a 2-of-2 multisig script, requiring that both of us agree before it can be spent.

In order to do so, we must first agree on what that script is going to be. You have revealed your public key A to me, and are waiting for me to respond with mine.

Instead of just giving you the key B, I generate a huge list of 280 public keys, all of which I know the private key for.

For each of those keys K, I compute:

Hash160(A-and-K)
Hash160(B-and-K)

I put all the A-and-K hashes in one list L1, and all of the B-and-K hashes in a list L2. I sort both lists. Then I go through both lists, and find a hash that exists in both in a single iteration. This is the critical point. It is likely that such a collision exists, because even though there are only 280 entries in each list, there are 2160 combinations of entries. Each of those has a 2-160 chance to be a collision. This is also the explanation of the Birthday Paradox, and such an attack is therefore called a birthday attack.

So, say I have found a hash that occurs in both lists. Say that K1 is the key that generated the hash in L1, and K2 is the key that generated the hash in L2. In other words, Hash160(A-and-K1) = Hash160(B-and-K2).

Now I just tell you that my key is K1. You cannot disprove that, as in fact, K1 is a completely valid key of mine. You happily accept that, and we both agree on using the script A-and-K1. We construct the address Hash160(A-and-K1), which I already know is identical to Hash160(B-and-K2).

We hand out that P2SH address, and the payer sends money to that hash's address.

Once funds have been sent there, I can spend them without your cooperation.

The requirements for spending a P2SH outputs are:

(1) a redeemscript whose hash equals the Hash160 in the P2SH address
(2) inputs to that redeemscript that make it evaluate to true.

For (1) I can use the B-and-K2 script, and for (2) I can simply sign with both B and K2, both of which I have the private keys for.

Making it practical

In practice, the above attack is not feasible, because the lists L1 and L2 are too large to store (much less sort them) for current day hardware. However, cycle-detection algorithms can be used to find a K1 and K2 such that Hash160(A-and-K1) = Hash160(B-and-K2) in 280 steps without ever fully storing or sorting the lists L1 and L2.

Generalizing

The attack can also be generalized for other scripts where multiple people are involved, as long as the attacker has an influence over the chosen script.

Mitigation

SegWit does no longer have a 160-bit script hash system. It still uses 160-bit hashes for the single key case (for efficiency reasons), as the birthday attack does not apply to them. Instead it introduces P2WSH, which uses 256-bit script hashes. The birthday attack still applies there, but requires 2128 steps rather than 280. 2128 is considered infeasible to attack in the short to medium term. Furthermore, it is the security target for Bitcoin in general (including forging signatures), doing more is not very valuable.

Why is this not an issue for single-key addresses?

In the case where no input from the attacker goes into the creation of the address being stolen from, this attack doesn't work.

All the attacker has in this case is an address. He can't insert variance into it to produce 2160 combinations out of 280 attempts. The only thing that works here is a preimage attack, which needs 2160 iterations for a 160-bit hash.


Why do you need to send a transaction out with NXT to secure your address?

NXT addresses are only 64 bits long. So to find a passphrase that matches it should only take on average 2^63 times.

But once you send a transaction from the address, the address gets permanently locked to the public key you used to make the transaction. The public key is 256 bits. So now even if someone cracks the address, they can't do anything at all until they crack the public key.


Yes, I did some double-spends playing on-chain games. It was years ago when a game (for example luckyb.it) accepted transaction with high-S-value, but most of pools did not include it into the block. The strategy was: send a bet with high-S-value, doublespend it if loss or wait several hours for a pool what confirm it on win.
As far as I remember, successful doublespend was performed by pool operator (I do not remember which one) when Bitcion forked in 2013 (0.7 to 0.8 version upgrade)


What determines BTC's wallet size in bytes?

Does wallet.dat contain every address that I created?  Even if I didn't get any coins from it?

Yes

To be clear, suppose I run bitcoin-qt in Linux, and, in the GUI, I click on Receive then click on Create new receiving address:

At this point, no coins are received.  Will this immediately generate a new public-private key pair?

Yes. Well, not quite, but in essence, yes. Bitcoin Core pre-generates 1000 keys in a structure known as the keypool. When you request a new address, one of those pre-generated keys is returned to you and another one is generated to replace it in the keypool. This replacement generation can be deferred to a later time, if, for example, your wallet is locked.

How was this public-private key generated?

Depending on when you created your wallet, either randomly, or with BIP 32. Newly created wallets with modern versions of Bitcoin Core will use BIP 32. BIP 32 is a deterministic way to generate keys from a randomly generated seed. Bitcoin Core randomly generates the seed and derives the actual private keys from it using BIP 32.

Is this new key pair stored in wallet.dat even before me receiving any payments?

Yes

I receive coins on that address.  Will this affect the size of wallet.dat?

Yes. When you receive a transaction, that transaction is added to the wallet and this will increase the size of the wallet.dat.

Basically I'm concerned on the size of wallet.dat as I keep creating new receiving addresses.
What determines the size of wallet.dat?  It's about 1.4 MB now.  What made it so?  What will make it change?

The size is largely determined by the number of addresses you have requested already, the size of the keypool, and the number of transactions that you have, both incoming and outgoing.

Looks pretty linear to me with a slope of 1135.0361445783133 bytes per address.  I wonder why is this?  Is it because wallet.dat is storing a whole new public-private key pair per address?  Or what is happening?

Yes.
If your wallet is unencrypted, each new keypair that is generated will add at least 388 bytes.
If your wallet is encrypted, each new keypair will add at least 120 bytes. This size difference is because encrypted private keys are encoded more efficiently than unencrypted private keys.

I then delted all those addresses, but  wallet.dat's size didn't reduce.  In fact it even increased!

Bitcoin Core does not allow you to delete addresses. However you "deleted" them, it was likely just hiding them.

If you want a smaller wallet, then you should create a new encrypted wallet. Note that this means creating a new wallet and choosing the option to make it encrypted. Creating a new wallet and then encrypting it after the fact will create extra keys that are never used and just take up space.


Is there a javascript library for generating litecoin address from a string?

Try this https://github.com/litecoin-project/litecore-lib.
You can generate a Litecoin address with a long string by using above library.


Are there any C# wrappers for the Bitcoin REST API?

Take a look at this c# bitcoin rpc api wrapper: https://github.com/GeorgeKimionis/BitcoinLib that, unlike bitnet, is up-to-date.


If you have a look at https://github.com/bitcoin/bips you can find all BIP's. Scrolling down to the README, you will find the list number and title of every BIP and the current status. The BIP process with definitions for the status codes and other aspects is in BIP0002. At the top of the page you can search for P2SH or Pay to Script Hash and find many matches. BIP0016 seems to be particularly relevant but is certainly not the only source.

There are several BIP's dealing with aspects of P2SH and I would suggest that you should support P2SH transactions as they are a standard type of transaction that your end users may receive, although, being able to create P2SH transactions is probably not necessary. Check the BIP's.

You may also be interested in the [bitcoin-dev] mailing list.


Is the "vin" value field necessary or just a matter of convenience?

That field in the RPC response is by definition just information about the output being spent, so yes, it is always going to be equal.
As for whether it's necessary - no, of course not. But the RPC in the first place exists because of convenience.


Well exporting the raw keys is as standard as you'll get. Different wallet implement their own file format for storing information such as addresses, and keys. But most wallet have at least an "import private key" functionality so that would work.


The standard bitcoind core daemon has no methods to query the UTXO set for reasons I don't know: it should be trivial to give access to it even on a pruned node since it needs to have the full UTXO set at any time to validate a new block.

Anyway a pull request seems in progress to add this capability:
https://github.com/bitcoin/bitcoin/pull/8952

There are anyway third party apis to query a single address, for example https://www.blockcypher.com/dev/ or https://chain.so/api


The Bitcoin network has a global block difficulty. Valid blocks must
  have a hash below this target. Mining pools also have a pool-specific
  share difficulty setting a lower limit for shares.

ASIC hardware is required for profitable mining because the current difficulty is extremely high as a result of increased hashing power coming online. GPU mining is unable to compete with this specialized hardware. It is most likely the case that your GPU is unable to find any valid shares within the ~10 minute timeframe that occurs between discovery of new blocks.

See this response for more information


No.
Maybe one day some exchange partners with a bank to allow such deposits. But that is very far in time...


Zero-BTC transaction fees, service-specific mining pools and external compensation

Every mining pool can select (valid) transactions for confirmation on basis of whatever criteria they want. If the mining pool had an agreement based on direct payment by those wanting to use the notary service, they could prioritize confirmation of document hash transactions.

The criteria of selection would then perhaps be that they get the transaction from their customer with the request to confirm it.

However, this scheme would only make economic sense for the mining pool, if confirming the notary transactions was more valuable to them than the fees paid by regular transactions. So, in a sense, those notary transactions would have to compete with a similar value level as regular fees anyway.

With 0.1% of the global mining power, the expected time until the pool finds a block is 10000 minutes, which is pretty close to one week. If the pool were to maintain their 0.1% hashrate, it would have a chance of 1 - exp(-4) = 98.1% chance to find at least one block in four weeks.

Something very similar is already happening: BTCC is running a service called BlockPriority that prioritizes transactions of BTCC customers.

That said, it is unclear to me why one would want to encourage users to create bloat on the Bitcoin blockchain. It would make much more sense to create a Merkle tree from all documents to be confirmed, publish it somewhere online, and just anchor the root of that Merkle tree in the blockchain by paying a single transaction fee.


Wallet.dat can contain only 100 private keys even if I back up?

Run the client with the parameter -keypool=10000 to generate 10000 keys in your keypool.

Pros: Less backing up

Cons: Your wallet will be bigger (file size) and take maybe a few seconds extra to load


Transaction with duplicate address in the output

There is no command that allows you to do that. While there is no network relay or consensus rule that prevents this, the wallet side has its own rules and will prevent you from doing this as it is largely pointless. If you really want to send to the same address multiple times, you will need to create the transaction bytes manually without the use of any of the RPC commands.


When walletnotify and blocknotify notifications are sent out?

Refers to Bitcoin Core 0.17:

WalletNotify

Will be executed at the time when a transaction gets added to the wallet. If your wallet is 100 blocks behind and in those 100 blocks you have 2 transaction in each block, the wallet notify script will be called twice per block (== 200 executions during the 100 block catch up).

Only valid blocks (valid transaction) will result in a wallet-notify call.

Will also be called when a mempool transactions (unconfirmed transaction) was added to the wallet (and therefore relevant to the wallet)

BlockNotify

Will be executed when a block gets connected to the active chain and before WalletNotify.

Consider taking a closer look at Bitcoin Cores ZMQ API that allows more efficient process interaction (wallet/block notify spawn a process on each call).


What would cause the price of Bitcoin to flatline for several hours on Bitstamp?

I think this was "Bitcoin Sell Wall of Death" at Bitstamp. Somebody sold 31 000 BTC at 300 USD. The wall was eaten over Sunday-Monday night.

https://www.cryptocoinsnews.com/bitcoin-sell-wall-death-chomped/


Checkout pywallet. Its a python script that may be able to help you out. I've had similar issues with OSX clients in the past. You may also want to try finding an older version of the bitcoin-qt client for OSX and see if that works.

https://github.com/jackjack-jj/pywallet


Split coins in wallet using coins from coinbase.com

coinbase.com claim their sends have replay protection: "You can safely send any BTC or B2X from Coinbase without worrying about replays on the other chain."
  Does this imply that the coins I get in (1) can be used as a "taint"?

Yes, if a transaction only exists on one blockchain, it is by definition only valid on that blockchain, so any other transaction which spends from it is also only valid on that chain.

  Is this necessary, or are my BTC coins immune to replay by virtue of already having been spent?

The latter, since your outputs have already been spent on the B2X chain, any replay of your BTC transaction would be rejected as a double-spend there, so you can safely just spend your BTC normally.

  Now that I have a wallet for each chain, will they remember which chain they belong to?

I assume that would be the case, but I'm not familiar with the wallet so I can't answer this.

I'm unsure what you mean in your last point, send which transaction back to coinbase?


How do block rewards work with a mining pool?

As others have said schemes differ. But to try to answer the question you asked:

  Are all the shares submitted between blocks found counted? ie. If a pool finds a block every 10 blocks, do the shares from the other 9 get added together and the entire block reward split across all work done on the found and previously unsuccessful blocks based on the share scheme?

Probably not. That would be a terrible scheme. Assume a pool has a constant hash rate. Right after it has found a block, it's just as likely to find another block in the next minute as it is when it hasn't found a block for a long time. But the reward per share will be much higher if the pool finds a block shortly after finding another block and much lower if the pool hasn't found a block in a long time.

So a pool that counted every share since it last found a block would likely see a huge influx of users right after it found a block, since the expected reward per share will be abnormally high.

And if the pool is unlucky and hasn't found a block in a long time, the number of counted shares will be abnormally high, making the reward abnormally low. This will cause miners to abandon the pool.

So counting all shares since the last found block is perhaps the worst reward scheme possible.


First a bit of perspective on FPGA mining.

Around 2011 some miners started switching from GPUs to FPGAs, (Field Programmable Gate Arrays), after the first implementation of Bitcoin mining came out in Verilog, (a hardware design language that’s used to program FPGAs).

The general rationale behind FPGAs is to try to get as close as possible to the performance of custom hardware while also allowing the owner of the card to customize it or reconfigure it "in the field".

By contrast, custom hardware chips are designed in a factory and do the same thing forever. FPGAs offer better performance than graphics cards, particularly on “bit fiddling” operations which are trivial to specify on an FPGA.

Cooling is also easier with FPGAs and, unlike GPUs, you can theoretically use nearly all of the transistors on the card for mining. Like with GPUs, you can pack many FPGAs together and drive them from one central unit, which is exactly what people began to do.

Overall, it was possible to build a big array of FPGAs more neatly and cleanly than you could with graphics cards. Using an FPGA with a careful implementation, you might get up to a GH/s, or one billion hashes per second.

This is certainly a large performance gain over CPUs and GPUs, but even if you had a hundred 141 boards together, each with a 1 GH/s throughput, it would still take you longer than 50 years on average to find a Bitcoin block at the current difficulty level.

Despite the performance gain, the days of FPGA mining were quite limited. Firstly, they were being driven harder for Bitcoin mining — by being on all the time and overclocked — than consumer grade FPGAs were really designed for. Because of this, many people saw errors and malfunctions in their FPGAs as they were mining. It also turned out to be difficult to optimize the 32‐bit addition step which is critical in doing SHA‐256. FPGAs are also less accessible‐you can't buy them at most stores and there are fewer people who know how to program and set up an FPGA than a GPU. Most importantly though, even though FPGAs improved performance the cost‐per‐performance was only marginally improved over GPUs. This made FPGA mining was a rather short‐lived phenomenon. Whereas GPU mining dominated for about a year or so, the days of FPGA mining were far more limited — lasting only a few months before custom ASICs arrived.

However- the cycle repeats itself.

It’s worth noting that several smaller altcoins have indeed used a
different puzzle than SHA‐256, but have seen a similar trajectory in mining as Bitcoin.

For ASICs there is still a long lead time between designing a chip and shipping it, so if a new altcoin uses an new puzzle (even just a modified version of SHA‐256), this will buy some time in which ASICs are not yet available. Typically, mining will proceed just at Bitcoin did from CPUs to GPUs and/or FPGAs to ASICs (if the altcoin is very successful, like
LiteCoin). Personally I'm quite interested in Zcash.

Much of the content for this answer was drawn from this excellent resource.


There are many sites indeed and some over the counter transaction, but for the sake of being short.

Try: Mt. Gox

You can draw money from your bank account and put it in escrow for BTC and vice-versa... It's known as the biggest bitcoin exchange over the world.


How to get the "BTC" abbreviation via command line?

I will post my solution, but I still think there should be a cleaner way of doing this.

You would first need to open up (or create) the conf file for the coin which you wish to connect with then add abbr=BTC (or replace 'BTC' with whatever coin abbr you want).

You would then need to open up and read that conf file with your script/module. Since I am working with Python, here a function that does that:

def readCfg(location):
    cfg ={}
    with open(location) as f:
        for line in f:
            line = line.strip()
            if line and not line.startswith("#") and '=' in line: cfg[line.split('=', 1)[0]] = line.split('=', 1)[1]
        return cfg

cfg = readCfg('/home/username/.bitcoin/bitcoin.conf')
print(cfg['abbr'])

I think maybe having a documentation of this method done in other languages would be beneficial to the Bitcoin community. Feel free to expand on my answer until Bitcoin devs decide to add 'BTC' to the output of an rpc call.


Is there a way to tell that our bitcoin is safe after we put it in a hardware wallet for cold storage after 3 or 5 years?

Yes, you can use, for example, two or three different blockchain explorers to check the balance for your Bitcoin address(es).
Or you can set up a watch-only wallet on any PC or phone - import the Bitcoin-addresses but not the private keys and the wallet cannot spend the money, only monitor. The money will be shown by the wallet as "watch-only" or "non-spendable" (depending on the wallet). It will show you any transactions involving money at that bitcoin-address.


Can anyone delineate a phrase in the Satosh's white paper?: limiting the minimum practical transaction size

What Satoshi is referring to is the traditional financial system's inability to transfer small amounts of money.  Traditional money transfer systems such as ACH and various wire transfer services are reversible for a certain period of time, meaning that there is some risk involved.  The risk that the bank will have to mediate a reversal in payment (which costs them money) makes it so that they need to charge fees in order to transfer money on your behalf.  If the fee is not worth the risk, the bank won't do the transfer.

Let's take the example of paying a friend $5 for picking up the tab at lunch.  You tell your bank to transfer $5 to his bank over the ACH system.  This system takes 3-5 days to complete the transfer.  During that time period, a reversal is possible, and if it occurs, the bank needs to use its resources to mediate it.  This might include retrying the transaction, contacting the other bank, or contacting the customer in the case that the $5 has already been withdrawn.  These actions all cost the bank money.  If the probability that a reversal will occur, P, multiplied by the expected cost to the bank for dealing with the reversal, C, is greater than the fee the bank will earn, F, then the bank shouldn't allow the transaction.  So we have a system where the following must be true:

F > C x P

Let's say the bank charges a percentage as a fee, let's say an outrageous 10% of the transaction.  That means 'F' is $0.50.  In this scenario, it is unlikely that C x P will be less than $0.50, so the bank can't do the transfer.

Let's say that the bank charges a flat rate for transfers, one that will cover any of the risk.  A value of $10 for a transfer of any amount would not be unreasonable from the bank's standpoint.  However, would you be willing to pay the bank $10 to transfer $5 to your friend?

This is just one of the many problems that Satoshi solved with the invention of the Bitcoin blockchain.


Do i delete the Bitcoin folder & data directory in Appdata after i copy it on an encrypted drive?

Make sure to delete wallet.dat - that's the only file with sensitive information. (You might want to run a utility such as unix shred on it to make sure it's really deleted).

Just a warning - before deleting, rename the file, and try to copy it from your backup and see if everything works.


What would be a safe way to store large amounts of Bitcoin long term to ensure safety from loss?

NO. Using an online source to generate private keys is incredibly unsafe for a variety of reasons. The best way would be to produce the private keys offline either with a Hardware Wallet or private keys generated from an air-gapped computer with a Bitcoin client installed on it that is capable of functioning as a wallet. Once the private key stores bitcoins, it is then advisable to export it to a paper wallet and removed securely from the computer. Then the paper wallet is left to you as an exercise to keep safe at all times.


What is the difference from coinjoin and a coinshuffle transaction?

CoinJoin is the core idea underlying CoinShuffle (and other mixing techniques).

The idea behind CoinJoin: "When you want to make a payment, find someone else who also wants to make a payment and make a joint payment together". This leaves out two major details:

How two (or more) participants who want to make a payment find each other?
How is the joint transaction composed and submitted to the network?

This leaves much room for different approaches and implementations. There's more info about some of them here.

CoinShuffle only addresses the second question.  When you think about this problem for a moment, the obvious solutions which come to mind involve a centralized entity to compose: either a 3rd party, or one of the participants. It isn't immediately clear how this can be done in a decentralized manner, which also protects their privacy.

CoinShuffle describes an elegant decentralized protocol for constructuring the joint transaction in such a way that no privacy is compromised: there is no "centralized coordinator", and even the participants cannot link inputs to outputs (except for their own input and output, of course, which they chose). Of course, this unlinkability feature only makes sense if there are more than two participants.  The protocol is elegant and simple, and is described here.

Also, I don't think it is accurate to say they "create an anonymous transaction". It is more accurate to say they create a joint transaction in which it is either hard or impossible (depending on the method used and some implementation details) to link inputs to outputs, thus (among other things) improving users' unlinkability and making taint analysis harder.


First of all, this is a slight oversimplification: after taking transactions with fees, the standard policy is that priorities of remaining transactions are weighted by age and amount transacted.  For each input to the transaction, the age of the input being spent (counted by number of confirmations) is multiplied by the bitcoin amount of the input, and the result is summed over all inputs to get the priority of the transaction.  So a large-value transaction spending a fairly recent input might get higher priority than a very small-value transaction spending an old input.

There's certainly no requirement for any given miner to follow this policy (miners have complete freedom as to which valid transactions they include in their blocks), nor is there any direct financial incentive for them to do so.  However, there are a few indirect incentives.

The policy described above is the default behavior of Bitcoin Core.  A miner who is willing to use this policy can use Bitcoin Core for their transaction processing, rather than having to spend time and money to find or develop some other software.
Since miners are out to earn bitcoins, they have an incentive to behave in ways that help make the currency convenient and desirable for people to use, since that should increase adoption of the currency and ultimately increase the value of a bitcoin.  So if they believe this policy is helpful to the community as a whole, it is in their interest to use it.  Even if they are not sure this policy is inherently the best, there is some benefit in using it simply because it is standard; it is good for the currency's transaction processing to behave consistently, so that users know what to expect.


What does difficulty indicate for litecoin mining?

Litecoin's difficulty means mostly the same thing as it does for bitcoin.  It's the ratio of the maximum target to the current target.

Difficulty within (but not between, for obvious reasons) each can be compared the same way.  A difficulty of 100 means it takes, on average, 100x as many hashes to find a valid block as it does at a difficulty of 1.


What date does the 2016 halving happen at?

The first block with the halved block subsidy is 420,000. However, blocks are discovered in a random process – whereas the protocol aims to have blocks found approximately every ten minutes, in effect blocks are currently found about every 8.94 minutes. Therefore, one can only estimate the precise arrival of the Halving:

thehalvening.com estimates 2016-07-10 – 10:24 UTC
bitcoinclock.com estimates 2016-07-10 – 05:39 UTC
bitcoinblockhalf.com estimates 2016-07-10 – 10:10 UTC

It's not clear from the sites whether they rely on the current measured block interval or the theoretical ten minutes for their estimates. So far, it seems to me that the time has mostly been overestimated, earlier predictions were for later in July.

It seems therefore likely to me that the halving will occur on the 8th, 9th or the 10th of July. Naturally, any predictions will increase in accuracy as the halving draws nearer.


technical requirement to running a Bitcoin node

Bitcoin.org suggests the following minimum system requirements:

  Desktop or laptop hardware running recent versions of Windows, Mac OS X, or Linux.
  145 gigabytes of free disk space
  2 gigabytes of memory (RAM)
  A broadband Internet connection with upload speeds of at least 400 kilobits (50 kilobytes) per second
  An unmetered connection, a connection with high upload limits, or a connection you regularly monitor to ensure it doesn’t exceed its upload limits. It’s common for full nodes on high-speed connections to use 200 gigabytes upload or more a month. Download usage is around 20 gigabytes a month, plus around an additional 140 gigabytes the first time you start your node.
  6 hours a day that your full node can be left running. (You can do other things with your computer while running a full node.) More hours would be better, and best of all would be if you can run your node continuously.


How many shops accepted BTC? Is it somewhere roughly statistics data?

For example you can look at this site. It has a lot of shops who accept bitcoin, but I don't know if it's complete up to date. It does not have a graph, but you have some rough data (498 pages with 10 companies per page, so ~5000 companies)


How does a Bitcoin block get generated and 'agreed upon' by everyone?

Miner ASICs have one job: Change the meaningless parts of the block until the difficulty target (related to the hash of the block) is satisfied.
ASICs connect to the pool to first download the block template (they regularly do that - maybe every few seconds?). The block template contains the transactions. They calculate the merkle hash of the transactions, embed it in the block header, and hash the block header many times.
When the target is satisfied, the block is published. From then on, no one can change the transactions in the block.

all that work is wasted

This is a lottery where everyone's chances of finding the next block is proportional to their hashrates. If you need to mine all day to find one block per day -- congratulations! You can afford solo mining and you don't lose anything, and your reward is fair.
Trivia: Block mining is a Poisson process. One property of this is memory-less-ness. That is, given that the average time until the next block is 10 minutes (it is for Bitcoin):

After about how many blocks will someone find a block if everyone started just now: 10 minutes (t = 10)
What if you all had been mining for 2 minutes? Still 10 minutes (block to be released at t = 12)
What if you all had been mining for 20 minutes? Still 10 minutes (block to be released at t = 30)

Here's a fun puzzle by Russel O'Connor and Pieter Wuille.
So, there is no wasting in mining: it's memoryless. If you fail, you just keep trying, and everything works as intended in the end.


It is specified in BIP32 (https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki). The SHA512-HMAC function is reused because it is already part of the standard elsewhere, but it takes a key in addition to the data being hashed. As the key can be arbitrary, we opted to use to make sure the key derivation was Bitcoin-specific.


How to goto a nxt / ardor wallet with a default address set in the url?

In Ardor you also need to specify the chain i.e. https://ardor.jelurida.com/index.html?account=NXT-YD9C-ZKZW-ZZLZ-BNB3W&chain=IGNIS


Reproducible Gitian Builds .. but not the same hash as bitcoincore.org

I've done a rebuild of 0.20.1 and I get the same results that you do. This would indicate that a build dependency has updated to produce slightly different results than the version that was in use at the time of the release. The build dependency versions are pinned unlike the actual software dependencies. IIRC this is common for gitian builds and attempting to rebuild even older releases will result in similar mismatches.
There is ongoing work to move to a different reproducible builds system called guix. This build system will pin the exact dependency versions, along with the option to build the entire toolchain from scratch. This should enable fully reproducible builds that can be replicated at any point in time.

Here is a more in depth explanation of this particular mismatch, copied from my response in this GitHub issue.
If you look at the gitian build results, you will see a file named bitcoin-0.20.1-x86_64-linux-gnu-debug.tar.gz. If you untar this file, there will be *.dbg files, e.g. bitcoind.dbg and bitcoin-qt.dbg. These *.dbg files contain the debug data for their respective binaries, i.e. bitcoind.dbg contains debug data for bitcoind.
To ensure that you use the correct dbg file with the correct binary, gcc embeds a checksum of the dbg file within the binary itself. This means that bitcoind contains a checksum of bitcoind.dbg. This is to prevent attempting to debug bitcoind with another dbg file. For example, if you attempted to tell gdb that the bitcoin-qt.dbg file contained the debugging symbols for bitcoind, it would detect it does not and not attempt to load debugging symbols from bitcoin-qt.dbg.
The debugging symbols are initially compiled into the bitcoind binary, but later during the gitian build these are removed and placed into the bitcoind.dbg file. However because they are compiled into bitcoind initially, the debugging symbols have an effect on the build id that gcc embeds into the binary. The build ID is a hash of the compiled binary, including the debugging data.
So the end result is that the published binary contains two commitments to the debug symbols, but does not actually contain them itself.
You can read more about these separate debug files here: https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html
The crux of this issue is that the debug symbols from recent gitian builds differ from the debug symbols that were generated for the original release. This means that both the build ID and the debug symbol checksum that we find inside of bitcoind are different. This then results in the bitcoind hashes being different (as well as all of the other binaries). And of course that causes the tarfile hashes to be different.

Here is the diff of the binaries that diffoscope generates:
--- bitcoind
+++ /mnt/archive/bitcoin/bitcoin-binaries/0.20.1/bitcoin-0.20.1/bin/bitcoind
├── readelf --wide --notes {}
│ @@ -1,15 +1,15 @@
│
│  Displaying notes found in: .note.ABI-tag
│    Owner                Data size     Description
│    GNU                  0x00000010    NT_GNU_ABI_TAG (ABI version tag)        OS: Linux, ABI: 3.2.0
│
│  Displaying notes found in: .note.gnu.build-id
│    Owner                Data size     Description
│ -  GNU                  0x00000014    NT_GNU_BUILD_ID (unique build ID bitstring)     Build ID: 6b464617f7f91fd270ac86f43ef4a58eeeedff19
│ +  GNU                  0x00000014    NT_GNU_BUILD_ID (unique build ID bitstring)     Build ID: 3a439a31a5157ff7052ed310050df5643a02ea3f
│
│  Displaying notes found in: .note.stapsdt
│    Owner                Data size     Description
│    stapsdt              0x00000036    NT_STAPSDT (SystemTap probe descriptors)        Provider: libstdcxx
│      Name: throw
│      Location: 0x00000000006e550d, Base: 0x000000000086d140, Semaphore: 0x0000000000000000
│      Arguments: 8@%rdi 8@%rsi
├── readelf --wide --decompress --hex-dump=.gnu_debuglink {}
│ @@ -1,5 +1,5 @@
│
│  Hex dump of section '.gnu_debuglink':
│    0x00000000 62697463 6f696e64 2e646267 00000000 bitcoind.dbg....
│ -  0x00000010 b25ceebb                            .\..
│ +  0x00000010 114d519d                            .MQ.

As you can see, there are only two differences here, one in the build ID, and one in the .gnu_debuglink section. From the documentation I linked earlier, we can see that this .gnu_debuglink section has the first line is the debug filename followed by enough 0 bytes to pad to a 4 byte boundary. The second line is the 4 byte CRC checksum. And it is this CRC checksum that differs.
So why do the debug symbols differ here? Again, diffoscope can help us a bit.
--- bitcoind.dbg
+++ /mnt/archive/bitcoin/bitcoin-binaries/0.20.1/bitcoin-0.20.1/bin/bitcoind.dbg
├── readelf --wide --notes {}
│ @@ -1,15 +1,15 @@
│
│  Displaying notes found in: .note.ABI-tag
│    Owner                Data size     Description
│    GNU                  0x00000010    NT_GNU_ABI_TAG (ABI version tag)        OS: Linux, ABI: 3.2.0
│
│  Displaying notes found in: .note.gnu.build-id
│    Owner                Data size     Description
│ -  GNU                  0x00000014    NT_GNU_BUILD_ID (unique build ID bitstring)     Build ID: 6b464617f7f91fd270ac86f43ef4a58eeeedff19
│ +  GNU                  0x00000014    NT_GNU_BUILD_ID (unique build ID bitstring)     Build ID: 3a439a31a5157ff7052ed310050df5643a02ea3f
│
│  Displaying notes found in: .note.stapsdt
│    Owner                Data size     Description
│    stapsdt              0x00000036    NT_STAPSDT (SystemTap probe descriptors)        Provider: libstdcxx
│      Name: throw
│      Location: 0x00000000006e550d, Base: 0x000000000086d140, Semaphore: 0x0000000000000000
│      Arguments: 8@%rdi 8@%rsi
├── readelf --wide --debug-dump=info {}
│┄ error from `readelf --wide --debug-dump=info {}`:
│┄ readelf: Error: /build/binutils/src/binutils-gdb/binutils/dwarf.c:1989: read LEB value is too large to store in destination variable
│┄ readelf: Error: /build/binutils/src/binutils-gdb/binutils/dwarf.c:1989: read LEB value is too large to store in destination variable
│┄ readelf: Error: /build/binutils/src/binutils-gdb/binutils/dwarf.c:1989: read LEB value is too large to store in destination variable
│┄ readelf: Error: /build/binutils/src/binutils-gdb/binutils/dwarf.c:1989: read LEB value is too large to store in destination variable
│┄ readelf: Error: /build/binutils/src/binutils-gdb/binutils/dwarf.c:1989: read LEB value is too large to store in destination variable
│ @@ -85052,36 +85052,36 @@
│      <29607>   DW_AT_decl_line   : 124
│      <29608>   DW_AT_decl_column : 16
│      <29609>   DW_AT_type        : <0x28761>
│      <2960d>   DW_AT_data_member_location: 12
│   <2><2960e>: Abbrev Number: 30 (DW_TAG_member)
│      <2960f>   DW_AT_name        : (indirect string, offset: 0x13aaf): __kind
│      <29613>   DW_AT_decl_file   : 108
│ -    <29614>   DW_AT_decl_line   : 148
│ +    <29614>   DW_AT_decl_line   : 128
│      <29615>   DW_AT_decl_column : 7
│      <29616>   DW_AT_type        : <0x287a6>
│      <2961a>   DW_AT_data_member_location: 16
│   <2><2961b>: Abbrev Number: 30 (DW_TAG_member)
│      <2961c>   DW_AT_name        : (indirect string, offset: 0x7a535): __spins
│      <29620>   DW_AT_decl_file   : 108
│ -    <29621>   DW_AT_decl_line   : 154
│ +    <29621>   DW_AT_decl_line   : 134
│      <29622>   DW_AT_decl_column : 3
│      <29623>   DW_AT_type        : <0x2879a>
│      <29627>   DW_AT_data_member_location: 20
...

There's a lot more output that I haven't included because it's pretty much all of the same.
Now this isn't terribly helpful, but we can see that for a bunch of functions, the line number for that function differs by 20 lines.
To get some more information, I used dwarfdump. This is what it says for the new build for the two functions I show in diffoscope (the functions are __kind and __spins).
0x0002960e:     DW_TAG_member
                  DW_AT_name    ("__kind")
                  DW_AT_decl_file       ("/usr/include/x86_64-linux-gnu/bits/thread-shared-types.h")
                  DW_AT_decl_line       (148)
                  DW_AT_decl_column     (0x07)
                  DW_AT_type    (0x000287a6 "int")
                  DW_AT_data_member_location    (0x10)

0x0002961b:     DW_TAG_member
                  DW_AT_name    ("__spins")
                  DW_AT_decl_file       ("/usr/include/x86_64-linux-gnu/bits/thread-shared-types.h")
                  DW_AT_decl_line       (154)
                  DW_AT_decl_column     (0x03)
                  DW_AT_type    (0x0002879a "short int")
                  DW_AT_data_member_location    (0x14)

As you can see by the given file name, these functions come from libraries installed to the system. These appear to be headers for gcc's implementation of the c++ stdlib.

So what's happened is that libstdc++ has updated in Ubuntu. Whatever updates hapened have moved some code in some header files that Bitcoin Core includes in its use of the c++ stdlib. In turn, compiling with those updated headers results in different debug symbols because function declarations have moved in those header files. This then results in gcc computing a different build ID and a different CRC checksum for the debug symbols. This lastly results in the final binaries being slightly different, which causes the hashes to mismatch.