what if someone tries to finish public keys by non-stop creating

Yes, in theory but it would take so long that neither you, nor I will still be alive by a long shot.

At about 10,000 key pairs per second, with an address space of 2^160, it would take you 50 tredecillion years to finish.

Thats 50,000,000,000,000,000,000,000,000,000,000,000,000,000,000 years
To put that into perspective, the age of the universe is about 13,000,000,000 years


How are Bitcoin ATMs secured against double-spends?

I can't talk about other ATMs but in BTCPoint (The Bticoin ATM of Barcelona) works the following way:

The user want to SELL bitcoin
The bitcoin machine provides a fresh new public address for the transfer
The user sends the bitcoins to that address
Bitcoin network detects the transfer sent and issues a ticket with a confirmation code
The user waits for some minutes while the transaction is confirmed (the ATM can be used by other people)
After some confirmations the user scans the "ticket with the confirmation code" in the QR reader.
The ATM validates the confirmation and gives money out if everything is valid.

Check out the operations in: http://www.btcpoint.org

For some extra security (camera recording the confirmation code in step 4.) the machine can be configured so that a PIN code is inserted. This PIN code is then required in step 6.


Can hashtype in BTC scriptSig contained value other than 0x01, 0x02, 0x03, 0x80, 0x81, 0x82, 0x83?

Yes, the sighash type can be other than 0x01, 0x02, 0x03, 0x80, 0x81, 0x82, and 0x83, but it can't be values like 1190874345 or -886562767. You will see these in the tests because of the specific functions being tested, but those sighash types will not work in actual transactions.

In actual transactions, the sighash type is the last byte of the signature item. Because it is one byte, there are only 256 possible sighash type values. However, in creating the sighash (and the functions that create that) take a signed int which is 4 bytes. So the unit tests for that function use valid values for the function but those are not valid in transactions.

So in actual transactions, you can use other sighash types. How they behave is a little hard to describe. Confusingly, sometimes the sighash type is treated as a bit set, and other times, as an int.

If the eigth bit (most significant bit) is set, then the SIGHASH_ANYONECANPAY behavior will apply. If taking just the first 5 bits is equal to 2, then SIGHASH_NONE behavior applies. And if taking just the first 5 bits is equal to 3, then SIGHASH_SINGLE behavior applies. All values that do not meet these requirements (which includes the default SIGHASH_ALL 0x01) all mean to use the SIGHASH_ALL rules.


When ipv6 is enabled my ipv4 address does not appear in getnetworkinfo localaddresses

The localaddresses field (which I assume is what you are looking at) is not always accurate. Your computer does not actually know its external IP address so it has to ask its peers for the IP address, which may not always happen or may not always be correct. Keep in mind that if no one has connected to you on IPv4 you won't know your IPv4 address.

Instead what you should look at is the networks field and check whether ipv4 is available. Also use getpeerinfo to see what the IP addresses of your peers are.

You can also run netstat -nlp in your terminal to check whether bitcoind has actually bound to port 8333 with IPv4.

Lastly, make sure that your ISP is actually giving you an IPv4 address. They may only be giving you an IPv6 address since you can use IPv6. Without an IPv4 address, you won't be able to actually receive connections from IPv4 peers. Additionally, a new IPv6 address will not be known to many peers or the DNS seeders, so it is unlikely that you are getting new peers that want to download the blockchain from you.


Where is the exact code part of the walletnotify function?

I don't know exactly what you are asking, but

wallet.cpp (from line 591)

    // notify an external script when a wallet transaction comes in or is updated
    std::string strCmd = GetArg("-walletnotify", "");

    if ( !strCmd.empty())
    {
        boost::replace_all(strCmd, "%s", wtxIn.GetHash().GetHex());
        boost::thread t(runCommand, strCmd); // thread runs free
    }

runs a thread that executes the runCommand() function in util.cpp

wallet.cpp (from line 1335)

void runCommand(std::string strCommand)
{
    int nErr = ::system(strCommand.c_str());
    if (nErr)
        LogPrintf("runCommand error: system(%s) returned %d\n", strCommand, nErr);
}

and I think that is all code you need.


What is "version" used for in Bitcoin transactions? Does it have any meaning?

It seems to be related to BIP 0068.

https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki

BIP 68 deals with relative locktime and repurposes sequence number for a that purpose. Relative locktime allows the user to set locktime relative to a previous output.

As of April 2017, Shapeshift uses only v2 transactions, when exchanging from altcoins into bitcoin.

Just for interest, zcash says this about version 2 (zcash uses version 2 to mark transaction with "secret" inputs/outputs):

  Note: A transaction version number of 2 does not have the same meaning as in Bitcoin, where it is associated
  with support for OP CHECKSEQUENCEVERIFY as specified in [BIP-68]. Zcash was forked from Bitcoin v0.11.2 and does
  not currently support BIP 68, or the related BIPs 9, 112 and 113.


Missing unconfirmed transaction from trezor

This is not your fault. I have published the transaction.
You may track it here: https://blockchair.com/bitcoin/transaction/a23173e98ac492eb84c4324ce66817a6900d89c2fb408a85daf9ba98f1a7b513 or here:
https://blockstream.info/tx/a23173e98ac492eb84c4324ce66817a6900d89c2fb408a85daf9ba98f1a7b513?input:3

At the bottom of https://btc4.trezor.io/tx/a23173e98ac492eb84c4324ce66817a6900d89c2fb408a85daf9ba98f1a7b513
you can see the

  "hex": "0100000000010871f83...

which has the full hex-encoded raw transaction.
I have copied this to push it here.


Passing a wallet to rpcwallet in bitcoind JSON RPC

To query a specific wallet, set the URL to be

http://127.0.0.1:8332/wallet/<wallet_name>


How to generate a bitcoin address from a hexadecimal private key using openssl in swift

I wanted to put this as a short comment, but it get’s unreadable. I also don’t go into segwit.
I am not clear on your question: are you looking how to use the OpenSSL library for iOS (then this might not be the right forum - review of parameters to an OpenSSL library is not bitcoin specific...), or more at the conceptual steps to come to an address? Then read on:-)
Searching for OpenSSL and keys in the forum reveals lots of hints on how to use OpenSSL at the command line. I put here some links, that I find useful for creation and conversion of keys:
Bitcoin Address generation
What are steps 4-9 in bitcoin address generation for?
Then you‘ll have to go some additional steps, as described in bitcoin wiki.
And finally, if you want to check the addresses, this is a useful page:
http://gobittest.appspot.com/Address
Let us know how it goes, and see where we can bring you to your goal!


Remove noisy log messages like AcceptBlockHeader

According to my understanding, ERROR: AcceptBlockHeader: Consensus::CheckBlockHeader: can be excluded from log file using -debug or -debugexclude mentioned in https://github.com/bitcoin/bitcoin/pull/10123/ because it is assigned a category 'VALIDATION' in: https://github.com/bitcoin/bitcoin/blob/48c1083632687a42ac603d4f241e70616a1d3815/src/validation.cpp#L3643
Other error messages saved in logs are not assigned any category and LogPrintf is used instead of LogPrint in https://github.com/bitcoin/bitcoin/blob/48c1083632687a42ac603d4f241e70616a1d3815/src/validation.cpp#L3622


No information available about transaction

looking at blockchain.info, your first spent to this address was done at 2016-DEC-03 11:19:29 CET, amount was 0.01036619 BTC. This is what is shown in your picture above. You can look at the raw TX here: 9ff577ce...c55efb82
Later on there was a second TX: e71a26555...f8f5360
Both TX are confirmed. All good.
Not sure if I got your question right, on the payment to yourself. Usually if you spend bitcoins, they come from UTXOs, and if a value doesn't exist, the wallet will try to combine several UTXOs to near the desired value. The remainings go back into your wallet. It is like buying something for 9 Euros, you pay with a ten Euro bill, and get 1 Euro back to your wallet.


How do exchanges and atms introduce bitcoin

Miners need to pay for costs, namely electricity and hardware. One such way to pay for these is to sell the Bitcoin they mine for regular money.

Such transactions will often pass through exchanges. Exchanges and ATMs are simply order books. They accept Bitcoin and fiat money, and match buyers and sellers. If you want to sell 1 BTC at $1000, the order will only go through if there is a buyer willing to pay $1000 for 1 BTC.

Exchange will rarely hold large positions themselves. Instead, all the funds on an exchange usually belong to buyers and sellers, which can be miners, or people who have previously bought Bitcoins.

ATMs and other such systems will often just be a more user friendly mask to an exchange. An ATM operator might deposit $100,000 into an exchange account. Then, when someone puts $100 into an ATM, the ATM operator will execute a buy order of $100 on the exchange (out of their 100k balance). If the order is successful, the ATM will send the BTC out to the user's address, usually from a "hot wallet", which contains some prepurchased BTC that is readily accessible (also commonly known as the "float").

The ATM operator will then perform some balancing of their own, which may involve moving the BTC purchased on the exchange to their hot wallet, and moving the $100 physically deposited into the ATM into a bank account, and then transferring to the exchange he/she uses to maintain liquidity.

At the end of the day, if you follow transaction inputs back long enough, you will eventually end up at a coinbase input, which is the block mining reward that created some BTC. This till then pass through an assortment of exchanges, personal wallets, and p2p trades until it finally ends up with you.


Bitcoin Core extremely high syncing time

The transaction will go through whether Bitcoin Core is done syncing or not, so don't worry about that.  You just won't see the transaction appear in the application until syncing is finished.

The Bitcoin Core GUI doesn't always give the most accurate updates on its progress.  But one way to check the progress is to open Help:Debug Window, click the Console tab, and type getinfo.  Look at the blocks number.  Then try getinfo again a minute or two later and see if the blocks number has increased.  If so, you are in fact syncing and just have to be patient.  Note that you are downloading about 60 GB of data and performing fairly intensive computations on all of it.

If you get tired of waiting, you might prefer a "thin" client that doesn't try to download and verify the entire block chain.  See Cannot access my bitcoins because my wallet is still synchronising. What can I do to spend them immediately? to learn about your options for switching.


I need a few lines of python to make WIF addresses

Note: WIF is a format for private keys, not addresses.  There are multiple address formats, but the most common is P2PKH (hash of a public key).

I recommend looking that the code for Electrum to learn about how to work with public keys and addresses in Python, (check out bitcoin.py).  It contains everything you need and is reliable code used by many thousands of users to secure their bitcoin.


According to OP's comments

  I checked with my network admin, they were blockling port 8333.

probably meaning port 18333


Does a bitcoin node broadcast that it is full synced?

No. The nodes notify only about block height in the beginning of connection in version message. When node wants to notify about new block/tx it received/created, it uses inv message.

There is no point to notify other peers about downloading full blockchain. Other nodes have nothing to do with such information.


What is the ECC key length for OpenCoin's implementation of Ripple?

Ripple uses the same signature scheme as Bitcoin, 256-bit ECDSA keys and elliptic curve SECP256k1. It takes about 5 times more CPU effort to verify a 512-bit ECDSA signature than a 256-bit ECDSA signature and signature verification is a huge CPU load for both Bitcoin and Ripple. And, of course, keys and signatures are twice as long.


What is the chance of someone (randomly) finding the private key for an existing Bitcoin address?

Essentially zero. They would have to find a private key whose public key hash matched yours. The public key hash is 160 bits long. If they had a billion computers, each of which could try a billion keys a second, and they tried for a billion years, they'd have much, much less than a one in a billion chance of getting it.


Why does getNewAddress take so long? Often times out python-bitcoinrpc

The problem has to do with other processes on the computer with too high CPU priority:

https://raspberrypi.stackexchange.com/q/42474/39301


A Bitcoin soft fork idea to help compress the blockchain

Why don't we force miners to embed the height of the TX Merkle tree in the first two bytes of the 4-byte block header version?

That would be a sane softfork, but it would need to take into account that due to BIP65, the block version (which is a signed integer) needs to be at least 4, restricting it to 2^31-4 values. Maintaining compatibility with BIP9 and possibly BIP340, which assign meaning to certain bits in the version number, would complicate things further.

Also, it's hard to convince miners to softfork in a change that complicates matters for them, which means that absent a successful UASF-style pressure, it's unlikely this would be adopted.

  It'd fix the leaf-node brute force weakness (CVE-2017-12842), which is currently fixed only by standard-ness rules but not by consensus rules.

Indeed! I think a consensus change that enforces a minimal transaction size instead is probably far less invasive.

  Similarly to the description in BIP 141, we can introduce a type of node that is neither a pruned node nor a complete full node, but they'd have txindex=1 for transactions with unspent outputs. Those nodes would first store full blocks. When the next block comes, using their txindex they'd look up the block, find the transaction and check if all outputs are spent. If so, they would remove the transaction from the storage of that block but only keep its hash. This would save a large space since it seems to me that most scenarios of querying a txindex-enabled node would use gettransaction on transactions with unspent outputs?

I don't see how this change is related to this potential mode of operation. Whatever you suggest blocks commit to in their header, it can instead just be remembered by nodes when they first validate a block, without consensus change. To a node locally, if it itself validated how many transactions there actually in the block, it won't ever convince itself of anything else.

I also don't think this mode has any benefits. It shares the slowness of the pre-UTXO model validation(*) with the lack of ability to provide full blocks (like current pruned nodes) while consuming far more disk space (it would need to keep every transaction fully that has at least one unspent output, rather than keeping just the unspent outputs themselves).

(*) Before Bitcoin 0.8, instead of a blockchain + UTXO set, there was a blockchain + index into that chain for every transaction + a boolean for every output whether it was spent or not. This was slow, because it meant that the working set (data frequently accessed by the code) was effectively the whole blockchain (doing many random seeks into for every input being spent). In the UTXO model introduced in 0.8, the UTXO set is kept independently from the blockchain (it does not contain pointers into the blockchain; it contains a copy of all the UTXOs), enabling efficient caching of just the UTXOs, and pretty making the blockchain unnecessary for normal operation (except serving blocks to other peers, or rescanning). That model is what enabled pruning too, as the blockchain itself is no longer used for validation.


Why does Wikipedia's Bitcoin entry imply Satoshi's whitepaper is from May 2009?

That is clearly incorrect. His whitepaper was released on October 31st, 2008 via the metzdowd mailing list

  Bitcoin P2P e-cash paper

  Satoshi Nakamoto satoshi at vistomail.com
  Fri Oct 31 14:10:00 EDT 2008

  Previous message: Fw: SHA-3 lounge
  Messages sorted by: [ date ] [ thread ] [ subject ] [ author]

  I've been working on a new electronic cash system that's fully peer-to-peer, with no trusted third party.

  The paper is available at: http://www.bitcoin.org/bitcoin.pdf

  The main properties:  Double-spending is prevented with a peer-to-peer
  network.  No mint or other trusted parties.  Participants can be
  anonymous.  New coins are made from Hashcash style proof-of-work.  The
  proof-of-work for new coin generation also powers the
      network to prevent double-spending.

  Bitcoin: A Peer-to-Peer Electronic Cash System

  Abstract.  A purely peer-to-peer version of electronic cash would
  allow online payments to be sent directly from one party to another
  without the burdens of going through a financial institution. Digital
  signatures provide part of the solution, but the main benefits are
  lost if a trusted party is still required to prevent double-spending.
  We propose a solution to the double-spending problem using a
  peer-to-peer network.  The network timestamps transactions by hashing
  them into an ongoing chain of hash-based proof-of-work, forming a
  record that cannot be changed without redoing the proof-of-work.  The
  longest chain not only serves as proof of the sequence of events
  witnessed, but proof that it came from the largest pool of CPU power.
  As long as honest nodes control the most CPU power on the network,
  they can generate the longest chain and outpace any attackers.  The
  network itself requires minimal structure.  Messages are broadcasted
  on a best effort basis, and nodes can leave and rejoin the network at
  will, accepting the longest proof-of-work chain as proof of what
  happened while they were gone.

  Full paper at: http://www.bitcoin.org/bitcoin.pdf

  Satoshi Nakamoto

He realeased Bitcoin v0.1 on Thu Jan 8 14:27:40 EST 2009 -- more than 2 months later. By May, he had ceased all communication on the mailing list.


How do developers fix bugs when compiling takes so long?

Initial compiling of bitcoin-core can take a couple of minutes. If you have a multicore processor, you can use make -j<cores+1> to speed up compiling (parallel compiling).

Once bitcoin-core is compiled, a single semicolon change does (mostly) not require to recompile everything. You only compile the affected files (.cpp) again and do do the linking.

On most machines, compiling a simple change requires mostly less then 10 seconds.


If I held fiat currency, instead BTC, on MT Gox, would I get paid sooner/more?

Unfortunately you are in the same boat as all the people that had BTC at Mt.Gox. Think about it positively, you are now part of a club of people that all had their money stolen / lost.

If you are keen to try and get your money back, keep checking in at http://www.reddit.com/r/mtgoxinsolvency. But if you are taking this route, prepare to be really patient.

Here is the latest update from the above reddit thread.

  LAST UPDATE: 3 JANUARY 2015 11:00 AM GMT

  NOTE: Progress is slow nowadays, so this current state of affairs sticky thread should be up to date.

  A note on recovering funds: From announcement dated 26 November 2014:

  The deadline for filing the proof of claims of bankruptcy in these bankruptcy proceedings is set as May 29, 2015, and we plan to disclose the necessary information one or two months prior to the said deadline. The bankruptcy trustee will make effort to ensure that creditors around the world have a reasonable period of time in which to file proofs of claim.

  Important dates: From announcement dated July 24th 2014:

  Period for filing proofs of bankruptcy claims: By May 29, 2015

  Date and time for investigation of claims: September 9, 2015, 1:30 pm.


How to sign a SegWit transaction via NBitcoin?

signing with Segwit is in no way different from signing with P2SH or P2PKH.

If you want interoperability, you need to use Segwit wrapped into P2SH. Please check https://programmingblockchain.gitbooks.io/programmingblockchain/content/other_types_of_ownership/ for more info.

But in a nutshell, if you want to have a P2WPKH-PS2SH (Segwit P2PKH wrapped into P2SH for interoperability), then query the coins based on this address.

[Fact]
[Trait("UnitTest", "UnitTest")]
public void CanGuessRedeemScriptWithInputKeys()
{
    var k = new Key();

    //This gives you a Bech32 address (currently not really interoperable in wallets, so you need to convert it into P2SH)
    var address = k.PubKey.WitHash.GetAddress(Network.Main);
    var p2sh = address.GetScriptAddress();
    //p2sh is now an interoperable P2SH segwit address

    //For spending, it works the same as a a normal P2SH
    //You need to get the ScriptCoin, the RedeemScript of you script coin should be k.PubKey.WitHash.ScriptPubKey.

    var coins =
        //Get coins from any block explorer.
        GetCoins(p2sh)
        //Nobody knows your redeem script, so you add here the information
        //This line is actually optional since 4.0.0.38, as the TransactionBuilder is smart enough to figure out
        //the redeems from the keys added by AddKeys.
        //However, explicitely having the redeem will make code more easy to update to other payment like 2-2
        .Select(c => c.ToScriptCoin(k.PubKey.WitHash.ScriptPubKey))
        .ToArray();

    TransactionBuilder builder = new TransactionBuilder();
    builder.AddCoins(coins);
    builder.AddKeys(k);
    builder.Send(new Key().ScriptPubKey, Money.Coins(1));
    builder.SendFees(Money.Coins(0.001m));
    builder.SetChange(p2sh);
    var signedTx = builder.BuildTransaction(true);
    Assert.True(builder.Verify(signedTx));
}

Nicolas,


How does CryptoNote provide anonymity for a new coin when the user base is still small and additional signatures are scarce?

Small user base doesn’t seem to be such a big problem for CryptoNote coins. It is possible that up to a thousand of initial transactions would be more transparent than the ones that come next but this does not constitute an unsolvable issue. There is an interdependence between the number of existing signatures in the network and the level of anonymity available to users. If  a cryptocurrency has been created just recently the sufficient amount of signatures can be obtained through user’s transactions (even in small quantities) in a short period of time or it can be done with so called transaction tests. At the very beginning of the coin’s life-cycle the number of users can be very small and some of the transactions are created deliberately by the developers (manually or automatically) to increase the number of ring signatures for future transactions. It seems to be the case with Bytecoin (BCN). This coin is a first CN based currency launched in 2012. Now let's take a look at the chart below, it shows a transactions distribution since the launch of the coin.

As an author writes:
“Obviously at the beginning a certain number of transactions was created deliberately to make enough ring signatures for the future transactions (marked with brown color). Eventually this number has dropped leaving only the transactions created by users”.


How to convert P2PKH to Hash160 (or something else acceptable by Script)?

To convert a P2PKH address to a script, you first have to decode it using base58check.

Here is an example:

$ bs58 -dc 1GzqkR2zNQUzHLpE7PLPjVNJ51FHC3bpDH
00af7a4a30243f2301e6a14a4979ae099d52f560d4

Remove the prefix 00, see https://en.bitcoin.it/wiki/List_of_address_prefixes. You are then left with the hash160 of the pubkey, but this is not a full script. The P2PKH script looks like: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG. So you need to add the missing ops:

OP_DUP = 0x76
OP_HASH160 = 0xa9
OP_EQUALVERIFY = 0x88
OP_CHECKSIG = 0xac

Resulting script: 76a9af7a4a30243f2301e6a14a4979ae099d52f560d488ac

Note wallet software does all this for you when creating transactions based on an address.

Links

Bitcoin Wiki | Script
Bitcoin Wiki | Transaction (P2PKH)
Python Tools (bs58):
https://github.com/jbaczuk/blockchain-dev-tools/


+Accidently sent my BCH from my ledger nano S to a BTC address in Coinbase how can i get it back?

You would need to contact Coinbase to retrieve the coins back, because Coinbase hold the private keys on behalf of the users.


It's not a standard occurrence, it's just a company of dubious origin deciding that they will spam transactions to somehow prove a point about block sizes. Interestingly it proves the opposite of what they intended, rather than showing that the block size needs to be bigger, it shows that no matter how big you make the blocks people can spam enough to fill them.

If you have trouble getting transactions confirmed, you need to pay a fee for them rather than relying on the charity of miners. A transaction paying more than an absolutely rock bottom fee will be prioritized over the spam.


Location is not a detail recorded in transactions.  Specific Exchanges might record the IP address or location where their clients are located at the time they make a transaction, however that is clearly only going to be a small portion of the overall chain of transactions.


getblockfilter Error: Index is not enabled for filtertype basic

To enable the compact block filter, you need to start bitcoind with the -blockfilterindex=basic (or simply -blockfilterindex) command line option, or put that option in your bitcoin.conf file.
Depending on your hardware, it may take a few hours to build the compact block filter index. This is done in the background and does not affect normal node or wallet processing.


a) no need. you can fork your chain with the new chain-id at any time. but the wallets have to know the point of fork. The spanish coin pesetacoin forked the chain  near block 32000. and has no problems.

c) there is (at least) one pool mergemining with 3 main chains (you have to choose one) and 4 aux chains (pesetacoin orgcoin hutercoin and usc) have a look at http://manicminer.in


Restore a wallet from an external drive?

To avoid any problem,in your source computer backup your private keys

bitcoind dumpprivkey

to answer your question, By default Bitcoin will put its data here:

~/.bitcoin/

I think the wallet is located in a file wallet.dat(https://en.bitcoin.it/wiki/Data_directory#Linux), so if you copy it, it will works.

fore a best security level, encrypt your wallet with a paraphrase before backaping it.


Is one Bitcoin node has One wallet only?

As of v 0.14.x, Bitcoin Core supports only one wallet.  You can't create more than one.

You can sort of achieve this by having multiple wallet files and choosing which one you rename to wallet.dat.  You have to restart Bitcoin Core to change between them.  It's error-prone and not an officially supported feature.  You can read more about it at Bitcoin-qt multiple wallets and transferring between?


Every transaction input consists of a number of fields:

The txid of the transaction whose output is being spent.
The index of the output being spent (also called vout).
The scriptSig, or unlocking script.
The sequence number.
(SegWit inputs only) The scriptWitness.

The first two (txid, vout) are called the outpoint.


Why doesn't the Bitcoin blockchain truncate past data?

The idea of Bitcoin is that you can obtain the current state of the network without having to trust anyone. You essentially rely on the fact that the state that has most work put into it, is the valid state, and that all transactions are chained together up until the genesys block, after which there are no more transactions.

Now if you were to truncate this state (the block chain) in half, you could hard code this information into the software and it could reach some form of consensus among the nodes of the network. However this opens the door for attacks, because a dishonest node could easily fake and send you a wrong block height information, perhaps making you believe that a different history happened before the truncation of the block chain. And it could do this by simply broadcasting chunks of the history that was truncated, because lots of work has been put in that chunk and your client is programmed to accept longest worked on chains.

You would really have no way of knowing unless you read the entire history yourself.


This is possible, but your customers will have to use a wallet that supports the functionality of signing messages using the wallet’s private keys. For example, bitcoind has the signmessage command. The user could input a message such as ”todays date is ____, and I control bitcoin address ____, which sent coins to ____ service” in order to prove their identity.

Using any identifying info from the transaction itself will not be a good way to prove user identity, since all transaction details are a matter of public record.

Note: By utilizing this functionality, you will be restricting your potential user-base to only more knowledgeable users. Not all wallets have this functionality, in fact most do not. If a user happens to sends bitcoin from a wallet that cannot sign messages, they can prove their identities by importing the private key into some other software that is capable and then using it to sign a message— but again this is a more ‘advanced user’ sort of operation.

Another note: DO NOT build a service which requires users to communicate their private key to you. This would be an irresponsible thing to do.


How to find ripple faucet coin for development

I haven't tried it these website but i guess it should work: http://satoshibakery.com/ripple-faucet.php


Verifying transactions on a 2013 version of qt

You should first create additional backups of the wallet.dat from your laptop, as we're now talking about a significant amount of value.

Your old version of Bitcoin-Qt should be able to catch up eventually, but there have been lots of improvements, especially including the speed of synchronization but also security. A newer version of Bitcoin-Qt (now Bitcoin Core) should be at least 10× faster in catching up.

To switch to a new version, simply shut Bitcoin-Qt down, install Bitcoin Core, then copy the wallet.dat to Bitcoin's folder. It'll discover the wallet when you open and continue the synchronization.

You may also want to consider running the program on your newer computer instead, if it's much faster, the last year saw a significant increase in Bitcoin transaction traffic, so the later blocks are significantly slower to verify than earlier ones. If you're not using the computer too much, and can afford to give Bitcoin more RAM (and have enough RAM), you can speed-up the synchronization by increasing it's RAM usage by upping it to e.g. 2GiB with -dbcache=2048.

If you just want to check whether the coins are still untouched, you could look up the address on a blockchain explorer, e.g. https://blockexplorer.com/address/<your-address-here>.

If you want to spend your coins immediately, you may want to look at:

Cannot access my bitcoins because my wallet is still synchronising. What can I do to spend them immediately?

In the long term, you may want to look into hardware wallets or paper wallets to store a large sum of bitcoins safely.


How should I safely buy/sell a preorder for Bitcoin mining equipment?

They do it all the time over at the 'Group Buys' section of the bitcointalk forum. Have a look at how they have theirs arranged.

https://bitcointalk.org/index.php?board=137.0


That is the risk you take when giving someone else control of the private keys to spend your coins. When you transfer them to an address in custody of a centralized exchange, that means they have the corresponding private keys to spend it. You need to do your own research and determine if the exchange has good security measures to protect from breaches.

Many decentralized exchanges let you retain control of the private keys, but you also have to do your research on the software implementation to make sure it's design is secure with your keys.


Why are some BIP numbers missing from BIPs list?

If I understood correctly https://github.com/bitcoin/bips contains a list of change proposals that have been accepted as BIPs by the BIP editor?

Correct.

  Why are some of the numbers missing, for example 0155.mediawiki to 0158.mediawiki?

They haven't been assigned yet. The BIP editor sometimes chooses to reserve a range of number for BIPs around a common theme. When a BIP is proposed matching that theme, it is given a number from the range. Other BIPs get numbers outside of the range.


What does best block time mean in wallet.dat

Its the time the wallet was last synchronized to, it won't know about any transaction changes in or out past this time until it has been loaded again by a synchronized node. It has nothing to do with your transactions specifically.


What you need are the private keys, which are contained in the file wallet.dat.

You can access them by importing wallet.dat into a new installation of Bitcoin Core, or any other wallet client that is able to read the wallet.dat format.  You will then be able to spend the coins, if any, using that wallet client.

If you choose a wallet client which is a full node (e.g. Bitcoin Core), then you do have to download and sync the entire blockchain (currently about 130 GB).  You can also choose a "thin" (SPV) client such as Electrum which does not need to do this, at the cost of slightly increased vulnerability to certain kinds of fraud.  You can see a list of currently available wallet clients at
https://bitcoin.org/en/choose-your-wallet.

You could also use a tool like pywallet to list the addresses whose keys are in the file, and look up those addresses on a block explorer like http://blockchain.info.  This will tell you whether you have any coins, though you would still have to import the file (or at least the keys, which you can also list with pywallet) into another wallet client in order to spend them.

All the other files store the full blockchain and transaction register as of the last time you ran the program in 2011.  You don't need these files for anything.  If you install a new wallet client, it will re-download this data if it needs it.


Bitcoin Transaction using API with Custom Fees

I have not tried this myself but having a look through the documentation on blockchain-transaction - npm api it looks like you can query fees, under the advanced section:

  fees - Gets a list of current fees based on the BitCoin network going
  rate.

https://www.npmjs.com/package/bitcoin-transaction

Looks like you can select a 'fastest' option or others:

  Set the fee for the transaction. Can be either one of "fastest",
  "halfHour" or "hour" in which case the actual fee numbers are fetched
  from the fees provider. Or it can be just a plain number in which case
  that will be used as the Fee per Byte value in Satoshis. It is
  recommended to use one of the string aliases unless you know what you
  are doing.

You might have to specify a feesProvider, not sure if they have a default selected when nothing set.


Is there a 'command' to get the max supply of bitcoin that will ever exist using the bitcoin-cli?

In a sense, such a command would be trusting a third party: any putative answer would be that given by whoever supplied that code to you; and it may not be trustworthy - it could tell you it was 21 million, but behind the scenes actually use, say, 42 million.

The nearest you could do would be to download the source code from a proper source and, having verified your download, check the file src/amount.h for the line static const CAmount MAX_MONEY = 21000000 * COIN; before building the software yourself. You are now more sure that your node has the proper max supply.


bitcoin payment accidentally sent to Bitcoin-Qt application's sending address

There is no difference between sending and receiving addresses. If the address is his, the payment will become visible once his Bitcoin-Qt has synchronized with the network. (Unless with "sending address" you mean an address held by someone else that sent money to him.)


Single tx included in two different blocks

Occasionally, minor alternate chains emerge if multiple blocks are found for a given blockheight. Usually, these alternate chains only last for a single blocked, and are quickly dropped once another block has been found, allowing one chain to become longer (and thus have more work).

More rarely, these chains might last for a couple of blocks.

Block 525890 for this tx is not part of the main Bitcoin chain, and thus the tx was unspent when block 525891 was processed.

525889 ------ 525890 ------ 525891*
      \------ 525890*

The blocks marked with * contain the transaction in question here. As you can see, they occur on separate, parallel chains. Of these, only the chain extending 525891 survived, resulting in the version of block 525890 containing the transaction being dropped.


Bitcoin fees as of 2017-10 range from $3-$10 to send. How is this going to be sustainable with an increasing price?

And since fees cannot be lowered below .0001, how is that going to scale bitcoin in the future with an ever increasing price?

As demand for block space increases, it is anticipated that less valuable transactions will be moved off-chain to use solutions such as the lightning network.


Is there a Python or SageMath implementation for solving the ECDL problem for small secret multiplier?

In Sage.

Let's first define a finite field of size 2^32 (over which exhaustively searching would be painful but doable, but Pollard-Rho should be pretty fast).

sage F = GF(2^32 - 5)

And a prime-ordered elliptic curve over it (y^2 = x^3 + x + 13 happens to be prime)

sage: E = EllipticCurve(F, [1, 13])

Let's call the order of the curve n:

sage: n = E.order()
sage: n
4295040499
sage: n.is_prime()
True

Let's pick an arbitrary generator on that curve:

sage: G = E.gen(0)
sage: G
(4022957561 : 1193765470 : 1)
sage: G.order() == n
True

Now let's pick a random multiple of that generator:

sage: import random
sage: x = random.randrange(n)
sage: x
1334636724
sage: P = x * G
sage: P
(2051230087 : 1391923842 : 1)

And to find the discrete logarithm, simply use:

sage: discrete_log(P, G, n, operation='+')
1334636724

The same as our random secret multiplier x.

Sage uses Pollard-Rho and other algorithms internally.


Are sipa's standardized schnorr signatures incompatible with blind signatures?

Andrew Poelstra suggests that:

R' = R + alpha*G + beta*G

should be put in a loop .. whenever R.x is not a quadratic residue. You can change beta and this should give you compat with sipa's scheme with no security, privacy loss or blind-sig-linkability loss


I can't think of any known data about real demographics.

But here are some things you can consider to get an idea:

BitcoinCharts' currency distribution: Gives you a view on what currencies are traded the most, most currencies are country- or region-specific so this can be a measure.
BlockChain.info's real-time transaction mapping: You can literally see every new transmitted transaction appear on the map. (This is possible because all transactions are public and have an IP bound to them. But note that some users might use Bitcoin with tools like Tor so their location can be wrong.)


Why does Avast and other antivirus' detect gpu miners as viruses?

This is probably because hackers install these miners on peoples computers without their knowledge or make a botnet of miners.

Solution to this is placing your miner to ignore-list or get another antivirus like Avira, Avg, or just switch to linux and no need for antivirus anymore.


Accounting for currency destroyed in lost wallets?

Bitcoins can be divided up infinitely. So if there was just one bitcoin left (the rest are lost) then there can still be a viable economy with fractions of bitoins.

Lost wallets are only a problem for the people who lost them, not for bitcoin. It would of course limit supply and push the the cost of bitcoins versus other currencies.


I found the way. I confirmed the logs are saved as I expected.

bitcoin.conf

debug=mempool
debug=rpc


Why must some bitcoin clients download the block chain and others not?

Security of Bitcoin as a whole depends on the Block Chain being held in full by many people. Currently, the Standard Client does exactly that. However, given enough copies of the Chain, one can assume the system is secure enough from the data being lost and rely on other nodes to provide the information we require when we need it.

This is where Thin Clients appear - they only store the information that is useful to them and discard all the excess. Thin Clients usually scan and verify the entire Block Chain on the go to look for any information that is of interest to them during the first synchronisation. They get that data from the Standard Clients operating in the Network, while not providing the same services to other Clients themselves.

Next type of Client relies on external servers to store and verify all the data for them and provide it when needed. They only store their Wallet locally and use it to sign transactions created from provided information. The servers supply them with information about their balance, list of unspent transaction and the like.

Last type of Client could be considered an eWallet, where all the information is stored by the server, including one's private keys used to sign transactions. With this you don't need to store any data locally and instead rely fully on third party to secure your money for you.

All in all, the more data a Client stores, the more independent it is from others. Some Clients sacrifice security for convenience, and there are many levels available for both.


Not really.

Buying Bitcoin Through Google Checkout:

  Unsurprisingly, [neither] Apple nor Google will ever allow for digital currencies to be exchanged through their systems as a part of their TOS.

btcnow.net used to, but apparently Google put the kibosh on that some time ago.

fireduck asked in the Google Checkout/Wallet forums, but never really received an answer.

HOWEVER

Bitcoin Keys does digital delivery of private keys tied to accounts which have been loaded with the desired amount of BTC.

In my ~30 minutes of research on this, it's the only site I could find that does it in any way.

I have not personally used any of these sites, so I cannot vouch for them.


You share the block by broadcasting it on the Bitcoin peer-to-peer network.  This will ensure that other miners know about it and can mine their next blocks on top of it.

When you created the block, you included a coinbase transaction which pays the reward to an address belonging to you.  This can be spent after an additional 100 blocks have been mined.

Normally your mining software takes care of all this for you.


Partially sign a transaction with coinb.in

Well, I managed to solve this issue by manually modifying the transaction in javascript before calling coinbin's sign method. I've filed an issue with details here. This is how I ended up solving the issue in Javascript (this is kind of a hack, I just specify the same redeemScript for each input, which works for my specific usecase):

var rawtx2 = "01000000021a1f40dba3ab5c208b165d47bdcf2aadc517c4f2b90b781eab53dadcb35d61200100000000ffffffff05ec447a886d8711db0d5f4cbf1f61956cf227c82c5594ee195bb179e86faa910100000000ffffffff0138c70000000000001976a91472a2a94468e42593656cc9803c7a48c1863fc3e588ac00000000";

(function partialSignMultisig(window) {
    var coinjs = window.coinjs;
    var wifkey = "<WIFKEYHERE>";
    var script = rawtx2;
    var redeemScript = "5221020150ce6954f0cdcc2c5d57cf249f25eab0eed23e39549c4f06bcb42a37f308ce2102224aca2849ddad9c663c0bcfdac5ce3ca06f784ac8eca83404a4ea4ac61dbe7d52ae";

    var tx = coinjs.transaction();
    var t = tx.deserialize(script);

        // Manually specify scripts for inputs ..
    for (var i = 0; i < t.ins.length; i++) {
        t.ins[i].script = coinjs.script(redeemScript);
    }

    var signed = t.sign(wifkey);
    console.log( signed );

})(window);


Is it possible to split a key for transaction signing without using multisig?

There is a way for you to do so, but it involves something called Threshold Signatures which lets you do most of what you want (n-of-n without multisig). The thing about threshold signatures is that they require at least 2 round trips. That is, A and B have to exchange partial signatures a few times before the signature is valid. For 3-of-3 and higher, you need 3 trips to each person in order to produce a valid sig. Also, threshold signatures haven't really been implemented in any software than the one the Princeton researchers made.

The other method of sort-of doing something like what you want is using Shamir's Secret Sharing. I know Armory implements this for fragmented backups but you can't use the sharded pieces for actually signing, only for recovering the actual private key.


What prevents a miner to change the locking scripts of an unconfirmed transaction

Signatures cover inputs and outputs.

If someone changes one of the outputs in a transaction, a new signature is required. Effectively your signature signs "permit using my UTXO X to send A BTC to B, C BTC to D, ...".


Bitcoin transaction failed to broadcast (code 66)

It will be rebroadcast by your wallet automatically. However, you may want to bump the fee (bumpfee RPC command) if it's urgent as you are paying so low fees that you got evicted from your mempool.


How do I create a new genesis block for an altcoin?

They just removed the gen-generation part from the sources as it's not needed after the genesis being generated and already implemented (hardcoded) into the sources.


How to find Values N and K given R,S and Z in ECDSA?

k and n are not values that you calculate. k is randomly generated while n is predefined by the curve parameters.

n is the order of the curve G. It is defined by the curve parameters for the secp256k1 curve which are defined here: http://www.secg.org/sec2-v2.pdf. In those parameters, n = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141.

k is a randomly generated integer that is used only once for a signature. It is known as the nonce and acts as a source of randomness. If the same k is used to sign two different messages with the same private key, the private key will be leaked.


Receiving `error: {"code":-25,"message":""}` on sendrawtransaction with v0.9.3

After connecting to bitcoin-core (0.10.0rc3) I received:

ERROR: CScriptCheck() : 620186f101b7db97393af8747923db4cf3f30c3c3c48f4c7cfc23567b6d9ca07:0 VerifySignature failed: Data push larger than necessary
ERROR: AcceptToMemoryPool: : ConnectInputs failed 620186f101b7db97393af8747923db4cf3f30c3c3c48f4c7cfc23567b6d9ca07

(Thanks bitcoin devs for adding sane error messages!)

From here I noticed I was building the transaction with an outdated fork of bitcoin-ruby, updating to the latest bitcoin-ruby fixed this issue (On both 0.9.03 and 0.10.0). Still not sure why it would only relay after a bitcoind restart, will edit this answer if I figure this out.


How do you output segwit bech32 (bc1...) / P2SH (3...) addresses from a bitcoin private key?

Load up electrum 3.1.1+ and enable the "console" and in the console do the following to output the addresses you need by providing your private key:

bech32 format bc1...:

  bitcoin.address_from_private_key("p2wpkh:5Kkzs8XrJNAmf9......")

p2sh format 3...:

  bitcoin.address_from_private_key("p2wpkh-p2sh:5Kkzs8XrJNAmf9VQDFeG......")

you just need to prefix your private key with p2wpkh or p2wpkh-p2sh to get one of them.


How can a transaction have more than one recipient address?

Actually, most transactions you see will have two recipient addresses. One is for the actual transaction and the other one is change.

  When the output of a transaction is used as the input of another
  transaction, it must be spent in its entirety. Sometimes the coin
  value of the output is higher than what the user wishes to pay. In
  this case, the client generates a new Bitcoin address, and sends the
  difference back to this address. This is known as change.

But you can also add any number of recipients to a transaction so you'll find transactions with 20 or 50 receiving addresses too if you look around. In Bitcoin-Qt simply click "Add Recipient" on the "Send coins" tab.


Can private keys be securely stored on blockchain?

There is no encryption involved anywhere in a blockchain. There are no keys to encrypt with, as every node has the same information as all others. Cryptography is involved, but for signing/proving. Not for encrypting.

Even in the zcash case, encryption is not involved. All wallets do is prove to the rest of the network that they had the funds they're spending. The only difference compared to Bitcoin is that it reveals less information in doing so, and as a result, the proofs are much more complex.

blockchains don't generate private keys - that doesn't make sense, as the chain can be seen by everyone.

Wallets do have private keys. They're never shared with anyone. They hand out the corresponding public keys in order to be paid, and use the private key to later prove to others they own certain coins.

The example you're describing with an exchange occurring between two chains is possible using a technique called cross-chain atomic swap. It relies on a hashlocked transaction where the first wallet that moves its money out on one chain reveals a random value that hashes to a value that is known ahead of time. The other party then uses this preimage to unlock funds on the other side.


The way you describe it it's not possible. The pool sends you the template of the block that you ought to be working on. Should you really find a block it is bound to the block template you received from the pool, i.e., the nonce that satisfies the proof-of-work difficulty is only valid because it is valid in combination with the template. Since the block template also includes the coinbase transaction, transferring the reward to the pool operator, you cannot steal the reward.

Hence you cannot work for the pool, creating valid shares, and at the same time work for yourself. You could only not submit the nonce for the valid block to the mining pool, but that would reduce your share of the reward as well.


Is there an on the fly service to exchange physical currency for BTC for payment processing?

I don't know of any third parties that provide this service. I do know of a few (Example) that provide the opposite, where a customer has bitcoin, but the merchant will not accept it, however.

The problem here is that these customers (in your scenario) would be giving a credit card for payment. They have up to 30 days to claim the charges are fraudulent and unless you have some good proof that they are not, you will not get your money from them. In your example, they would be buying bitcoin with it, which would then be transferred to you, leaving this third party carrying all the risk. The only way I, personally, would run a business like this is with high fees to offset the high risk. You might at well just raise prices 2~4%. It's easier and is becoming more common for brick and mortar shops to do this for card purchases and not cash.

The difference with the reverse situation, where the customer has bitcoin and the merchant will not accept it, is that there is very little risk. The customer is buying money with the bitcoin and once the bitcoin transaction is verified it is permanent.


Won't DNS records reveal who Satoshi is?

Assuming that Satoshi himself registered the domain with his or her own personal information, and/or used a credit card tied to his or her real name, then it is likely that the registrar maybe have knowledge of the real identity.

HOWEVER,

It is not known if Satoshi used his or her real name to register.
It is not known if Satoshi used his or her personal payment information when registering.
It is unlikely that a registrar that specializes in privacy would ever divulge the above information or even its existence without a court order.
It is possible that the registrar may not have retained records dating back to then, so it is possible that the above information was known but is no longer retrievable.

DNSHistory.org began tracking bitcoin.org in early 2011, well after Satoshi exited. It does not track registrant information. WhoisRequest.org tracks NS back to September 2008, but only tracks nameserver changes. Who.is yields the known fact that the domain was registered with the AnonymousSpeech registrar and the registrant information as DigiRock, a Japanese domain registrar and hosting provider. This was likely a proxy registration.


How to store private data in blockchain and smart contract

If I've understood correctly, I don't think you need block-chain technology to achieve what you want. This is exactly what asymmetric public key encryption is designed for.

A simply encrypts some information using A's private key and B's public key... thereby ensuring:

Only B can decrypt the information
B can verify the information was
encrypted by A (using A's public key)

There's no way for A to prove to B that their copy of the information has been destroyed or forgotten by A, but at least secure transmission is ensured.


Short answer: No. Do you still have access to Mycelium and can send BTC from there to other addresses? Then you could transfer funds somewhere else. But to restore a wallet e.g. on another phone you need the mnemonic words based on the security implemented to secure wallets (or the extended private key which you probably do have as well).


Failed to start bitcoind using Ubuntu 20.10

Seems that you have an error in bitcoind starting options, you have -daemonwait instead of -daemon, you can check with systemctl cat bitcoind.service
The file to edit should be /etc/systemd/system/bitcoind.service


Ransomware requesting payment through Bitcoin

Has any malware successfully used this technique yet, using Bitcoin?

I got around 10 people contacting me via localbitcoins in a day asking to buy exactly 2BTC to unlock their computers. I'd say it's pretty effective. I did get the addresses but don't seem to have it around now, when I looked around 30 people total had been paid out to two addresses.


Why do we need bitcoins in the bitcoin network?

You cannot transact physical goods digitally. If I have a physical dollar bill, I cannot magically turn that into something digital that I can send to you. I have to go to someone who will accept my physical dollar bill and give me digital dollar bills in return. Likewise, with my bank account, I need to convert my bank dollar bills into digital dollar bills that work on this other network.

Well now we really have three things that represent the same value: physical dollar bills, bank dollar bills, and digital dollar bills. At this point, the only thing holding them together is the fact that they all have the same value. But they can only have the same value if some central authority is dictating that all of these have the same value.

Suppose the digital dollar bills were created by some independent entity which is not influenced by the same entity that enforces that a physical dollar bill and a bank dollar bill are equal in value. Well now we have digital dollar bills which have a different value; it is now its own currency. It has its own digital tokens which have their own value. And thus we have Bitcoin, a digital token which has its own value independent of any other currency.


Is it technically feasible to "shun" particular bitcoin wallets?

Not really, if you start doing that then chain forks and a whole load of nasty things follow. There's no real way of blacklisting a "wallet", as by design there's no way of determining exactly the extent of the keys under control by a specific party, so for the sake of this discussion we will assume we have one blacklisted "address".

Even if nodes reject transactions from specific addresses, miners can still include them in blocks without them even having to be broadcast. If some nodes decide to arbitrarily invalidate blocks with transactions they don't like, you've then got a forked network. Massive double spends occur on both forks by intentional and unintentional parties, and the network collapses in the sea of mistrust.

Currently, some mining nodes (like mine) specifically refuse to include transactions in blocks that come from known betting site addresses, like SatoshiDice. I however don't reject blocks that contain the transactions, or I'd be very quickly become isolated from the network.

You'll never get all the miners to agree with any form of blacklisting, so no, it can't technically happen.


BIP 144 transaction format and soft-forks and old nodes

This is correct. As an upgrade mechanism, nodes do not relay or mine transactions which they know that they can not correctly validate. The P2P network expressly avoids situations in which it could cause invalid transactions to be included in a block. It will however accept these transactions in a block.


How should I encrypt a bip39 mnemonic with a password?

Bip39 has an optional "encryption" over PBKDF2 (passphrase-to-key) used as salt (this allows possible deniability).
https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki#from-mnemonic-to-seed

The weakness there is that BIP39 uses only 2048 rounds during KDF. Which is easy to bruteforce.

If you store it in a cloud (or similar), I recommend to do a AES-256-CBC encryption of the mnemonic with a strong password and a strong KDF (maybe use PBKDF2 with at least 30'000 rounds).


Is there a risk in entering my Bitcoin-Core wallet passphrase, if it's for sending all my available balance and never using that wallet again?

Sure, just make sure it's a computer you trust to be free of malware.


How to read blockchain.info transactions in the blockchain?

The transaction in which someone sends you 0.0007 BTC includes more payments to other people and one payment back to himself, what is called the change.

When you get Bitcoin in a wallet, everything you get in each transaction is a separate input. Any or several of those can be used to make a transaction, but you can't break them. In order to send a smaller amount than an input, what you do is to make two payments, one to the address to which you want to send that smaller amount and another one to yourself, usually to a new address for privacy reasons. In you example, the sender had a 69 BTC input, made some payments and sent himself back around 67 BTC.

Than second address you mention (1DZPyyLMcu1jKaEJ5fskeEpsMbjY49L9JL) has not been seen in the network, what means that it is not associated with any transaction yet. In the big transaction your 0.0007 have an "unspent" next to them. This means that you have not used them and they are in that address.


How do Blockchain.info recovery mnemonics encrypt wallet data and what prevents hacking of the algorithm?

Edit:
Blockchain.info is open source, the algorithm is public. The mnemonic that they use stores information about your wallet id and your password only.

Previous answer: You should read into BIP 39 this covers how mnemonics map to the values that are used to create a HD wallet the algorithm is very well known and corresponds to the size of the key space needed for wallet generation.  There are generally 2048 words in the wordlist used to create a wallet. A 12 word seed generates 128 bits of information (and 4 check bits). That's 11 bits per word from a list of 2048 words.


Bought Bitcoin from ATM, haven't showed up

What kind of wallet are you using?  I ask because if you're using a full node (like bitcoin core) then it could be that you need to wait for the latest blocks to finish uploading...or... it could be that the transaction for £80 hasn't had a confirmation yet and we're still waiting for that confirmation before it appears in your mobile wallet.

Using tradeblock (the screenshot) we can see that there's about 1,718 tx still waiting to be confirmed in the queue and that the last block happened 6 minutes ago...I'm guessing that it wasn't in that full Bitfury Block there so it's likely still waiting to be confirmed.

Final edit:  Electrum is an spv wallet, likely you're waiting for a confirmation as it should download the block headers pretty much instantly.

Do this...close Electrum...then reopen it..I don't expect your balance to update but maybe it will (if there's some sort of bug or network timeout issue happening)...from there...give it about another 30 or so mins for it to be included in the next block...this happens because sometimes bitcoin ATMs send non-standard trx and the fee is low (compared to free market).  I believe the recommended fee is approximately 10 satoshis per byte and we see the average fee is about 14 in the pic above.  Taking my comments into consideration - don't worry about the coin being lost it should still hit your address balance.  The worst case scenario is this:  in 72 hours if the coin fails to route then the ATMs wallet gets the coin back - you would be able to reference the failed transaction with the atm operator to get your money back or request them to send the coin with a higher fee so it confirms faster.


How do nodes verify Bitcoin Transactions?

Yes, but that doesn't mean that the network has accepted it.
There are rules for accepting a transaction.  Miners only include blocks that don't break the rules.  The rules include checking that the inputs are valid, that a coin isn't double-spent, that the output isn't more than the input, etc.

A miner can choose to include a transaction or not.  A miner could even choose to include a transaction that breaks the rules!  But if he does that, other miners that are following the rules won't accept his block and he won't get his mining reward.  So he has incentive to follow the rules.


If you have not seen this yet, here is a diagram by zerohedge.com I found enlightening in order to understand how transactions fit into the Bitcoin concept.

The wiki at bitcoin.it has a more in detail overview of the inner works of Transactions and the inner workings of Raw Transactions.

From what I understand inputs to Bitcoin addresses are always spent completely in a transaction, so whatever you don't assign to a recipient will be available to be collected by a miner as transaction fee. So you'd need to set your client software to use the same address as source as well as for the recipient address of the transaction's change.

You could create a transaction that collects the complete balance from your wallet and sends them to a single output address. However, it is beneficial to use more than one address in order to make it more difficult to connect different transactions as belonging to the same identity. The bitcoin.it wiki has more information on privacy concerns

Additionally, Gavin Andresen, the lead developer of the reference client explained in this question, why change is sent to another address.


Does proof-of-work contribute directly to prevent double-spending?

There are multiple definitions of the term "double spending" at play here. First, there is the actual definition of double spending: to spend the same money multiple times. A simple example of this is the coin on a string in a vending machine. You put tie a string to a coin, when you put the coin in the machine, it thinks you paid, you get whatever you want from the machine, then you use the string to pull the coin back out so that it can be spent again somewhere else.

By this definition, the exchange of goods has occurred, but the money used to pay for it is used by the payer to pay for another good later. In effect, you created multiple transactions that conflicted with each other and they are all considered to be settled (i.e. final and irreversible) in the accounting system of that money.

Then there is the definition of "double spending" in the context of Bitcoin transactions. Double spending is often used to say that there are multiple unconfirmed transactions which conflict with each other. But unconfirmed transactions are not considered to be settled, so you have conflicting unsettled transactions under this definition.

The goal of the blockchain is to resolve these conflicting unsettled transactions. It's purpose is to ensure that all transactions do not conflict with each other and to make them considered settled. So to not have double spends, you need two properties for transactions: irreversible, and non-conflicting.

The non-conflicting part is handled by nodes. Nodes validate blocks and transactions. They reject blocks if they contain transactions that conflict with other transactions in that block or in the blockchain. So the thing that prevents the conflict aspect of double spends are nodes.

The Proof of Work is what allows for the irreversible aspect. It requires that miners expend time and energy in order to create a block. In order to change the contents of a block, one must expend time and energy to create a new block which conflicts with one that already exists.

The Proof of Work is also used to resolve blockchain conflicts. If there are multiple candidate blockchains that stem from a common forking point, nodes follow the one that has the most cumulative work because that chain is the one where the most energy was expended to create.

The chain part of the blockchain creates a compounding factor so that in order to replace a block in the blockchain, you must also replace the blocks that are on top of it thus expending far more time and energy. Because there are other people mining on the original blockchain, you must also be able to mine faster than them in order for your blockchain to have more work than the original for yours to be accepted by everyone else.

Because replacing blocks requires significant time and energy expenditure, one can reasonably assume that a block and the transactions it contains will never change once multiple blocks have been mined on top of it. This gives us the irreversible aspect. This is why it is said that confirmed transactions are irreversible.

  why can't we replace PoW with an automatic 10 minute block-addition based on a simple timestamp?

Because that is not decentralized. Who creates the blocks? If multiple people can create blocks like with mining, by what mechanism are ties broken? How do you resolve two different people creating different blocks? What stops someone from spoofing timestamps and replacing the blockchain with their own version?

The easiest way to resolve these is to make blocks only produced by a limited and trusted group of people. So it is now centralized. Congrats, you created Paypal, but less efficient.

The whole purpose of the Proof of Work is to allow for a decentralized system where everyone can agree on the truth without some central authority dictating what that truth is. If everyone follows the same rules, then everyone will eventually conclude on what the truth is. The use of energy expenditure in the Proof of Work prevents someone from rewriting history with different blocks because it is expensive to do so. The tie breaking of using the chain with the most work allows nodes to converge on the same blockchain. Use of the Proof of Work answers the questions I gave above without relying on a central authority.

In conclusion, the Proof of Work allows transactions to become settled and irreversible. It allows nodes to converge onto the same blockchain and makes it extremely expensive, to the point of impossible expensive, to rewrite history thus making transactions in the blockchain irreverisble. The actual ensuring that no conflicting transactions exist in the blockchain and thus actually preventing true double spends is left to the nodes that validate the blockchain.


Yes, once you have generated an address, you can have people send any number of transactions to that address from then on.  I just tried it with Copay on testnet and it works fine.

It automatically generates a new address when a transaction arrives, just to encourage you to use fresh ones if possible, for privacy.  But previous ones continue to work indefinitely.

(Interestingly, it generates a new address whenever a transaction is received, even if that transaction was sent to an older address and the previously displayed address hadn't been used at all.)


Bitcoin node refers to a "full" client. A "full" client is a client that owns the block chain and that is sharing blocks and transaction across the network. In opposite a Lightweight client can not be considered as a node because he doesn't share the block chain with the network.

Bitcoin network uses a client to client network infrastructure so there is no difference between a mining client and a non-mining client, they don't have any privileges.


Does bitcoind need to be up to date to serve blocks to other servers

Bitcoin clients are perpetually in a state of "catching up with the network".  There is no definitive point at which they are completely caught up.

If you are requesting a block or transaction that the client has yet to see, it will not be able to respond with that block or transaction.  Make sure that what you are requesting is something that the client has already seen and verified.  If you are sure that the client is aware of the data being requested, then you should continue troubleshooting.


If a solution is found by a miner, does the miner have the control to which nodes is it broadcasted?

Certainly, they can control the first level of peers they broadcast a solution to. However, they have no control over which peers will receive the block from the peers they have sent it to.
It is in a miner's best interests to broadcast it to as many nodes in the network as possible.

If it is broadcasted based on the location of miners, then won't all the miners in the pool have an intrinsic advantage of their pool peers validating the solution?

There are two kinds of miners in a pool - large scale mining operations with mining farms occupying the same physical space, and smaller scale miners who have anywhere from 1 to a few thousand miners who connect to the pools from anywhere around the world.
These mining devices receive work instructions, usually via a protocol such as stratum - once any device in the entire pool discovers a solution, the pool immediately instructs all devices connect to it to mine on top of this new block. Miners that are a part of that pool will then begin mining the next block, likely even before most other pools have finished receiving and validating the newly found block.
Since sharing your block with as many other nodes as possible is key to its acceptance in the event of a competing block, there are special solutions solely dedicated to broadcasting blocks, such as https://bitcoinfibre.org/.

Let's take a case when there are two solutions being broadcasted at the same time, one from the USA and another from China. Since, a lot of miners are there in China, Mongolia, Russia etc. doesn't miners in China have a better chance of getting consensus?

Pools will generally mine on top of the first block they see. However, consensus will only be achieved when a new block is found on top of one of the two competing blocks.

Also, what do we mean by consensus in the above case? Let's say the USA solution reached 20% of the active miners and the Chinese solution reached 80% of the miners. As per my understanding even the USA solution could reach more than 51% consensus(more than 10% of globally active miners agreeing with the solution). Shouldn't there be a threshold on the minimum number of global miners agreeing with your solution given this large pools existence?

Consensus here is not dependent on how many nodes you are able to broadcast your solution to, but depends on the next block to be mined. If block N has N_USA and N_CHINA, and block N+1 refers to N_USA as the previous block, block N_CHINA will be discarded as block N_USA is part of the longest chain, regardless of how many nodes had received N_CHINA before N_USA. Until block N+1 is found, both blocks are valid.
This is known as selecting the longest chain, or more formally, the chain with the most work.


What does it mean if TXID and WTXID are the same?

The wtxid and txid are the same if and only if the transaction does not contain any segwit inputs. The wtxid is the hash of the entire transaction including all segwit data (i.e. the marker and flag bytes and the witness fields themselves). The txid is the hash of the non-segwit parts of the transaction. Because a transaction that does not have any segwit inputs does not have any segwit data at all, both the wtxid and txid hash the same data, so they are the same.


The number of newly-created bitcoins with every mined block gets halved every 4 years on average. (More precisely, every 210,000 blocks). When bitcoin started, this was 50 new coins per block and currently it's down to 12.5 coins. This halvening creates a geometric progression which converges to the theoretical maximum number of bitcoins that can ever be mined, which happens to be 21 million.

Mathematically:

50 + 25 + 12.5 + 6.25 + ... = 100

100 × 210,000 = 21,000,000


Is there any academic research on the influences of Bitcoin's long term valuation?

There are some research papers out there, including about bitcoins economical viability. A wonderful (a pleasure for hours) and fairly complete list can be found on the wiki. A random chosen abstract:

  Bitcoin has emerged as a fascinating phenomenon of the ﬁnancial
  markets. Without any central authority issuing the currency, it has
  been associated with controversy ever since its popularity and public
  interest reached high levels. Here, we contribute to the discussion by
  examining potential drivers of Bitcoin prices ranging from fundamental
  to speculative and technical sources as well as a potential inﬂuence
  of the Chinese market. The evolution of the relationships is examined
  in both time and frequency domains utilizing the continuous wavelets
  framework so that we comment on development of the interconnections in
  time but we can also distinguish between short-term and long-term
  connections.

Have fun! :)


With only the bitcoin address, there is no way to discern which wallet was used.

Bitcoin addresses do not contain this sort of information, if they did it would be detrimental to user privacy and security.


Trying to send bcc with bitcoin-qt but getting "16: mandatory-script-verify-flag-failed" - error

Since i'm sure others will encounter the same problem, the solution is that BCC requires you to put in the amount-tag when signing a transaction. You have to put in the full amount that is shown on the listunspent-command though, else you won't be able to send the transaction.


How to get historical balance of a Bitcoin address at a particular block number or date?

Account/address balance are higher level constructs that are built on Bitcoin's low-level transaction scripting language and cryptography. As such, data related to funds 'belonging' to a particular address is not readily available in the blockchain, but has to be built separately by scanning the entire database. The Bitcoin-Core reference client does not even support showing 'balances' of address that are not part of your wallet, let alone providing you the data related to a particular address at a particular point in time. You would either have to do this yourself or search for third-party data providers who provide this kind of information through an API (that is off-topic on this forum).


Yep. You'll notice increased fees and confirmation times eventually. Those amounts aren't super dusty though, even smaller transactions are the ones that will really bog you down.


Most altcoins have done very poorly. You can see the list of relatively successful ones here. There isn't a country coin that's got a market cap over a million. I would say there hasn't been a success story.


If scripts were Turing-complete, you could construct a fairly short script that took an extremely long time to run (a la the Busy Beaver) or contained an infinite loop.  This would tend to result in a denial of service against everyone on the network, when they tried to verify the transaction.

And there would be no general way to tell whether a script would loop infinitely or would eventually finish: that's the halting problem.

One could try to avoid this by including some sort of cutoff on how long a client will spend verifying a transaction, but it would have to be done very carefully so as to be consistent across all clients: if some accept it and others don't, the block chain will fork.

It seems simpler to avoid the situation all together.


Possible to use an already generated bitcoin address?

You're out of luck if you don't have the wallet, only the address. If anybody could take control of an address they don't have the private key of, the whole system is broken.


It is going to be slow when you first install. I'd recommend downloading the bootstrap.dat file. If there is an X and two monitors, you're either not connected to the internet or something like your firewall are preventing you from updating it.


Do imperfections in dice make them unsuitable to make really good bitcoin private keys?

You can certainly use any randomness source you like to generate a private key; however, any bias or correlation in your random inputs will make your key easier to guess and reduce its security.

I wasn't able to find a comprehensive analysis of dice randomness in the scientific literature, but this paper could be a start:

  Labby, Z. Weldon's dice, automated.  Chance 22(4): 6-13, 2009.  http://statistics.uchicago.edu/about/docs/labby09dice.pdf

Based on a total of 315672 die rolls, the author found a statistically significant bias toward the numbers 1 and 6.  The other references in that paper could be useful.  I also found remarks elsewhere that casino dice, which have flat faces rather than hollowed-out pips, may be less likely to be biased.  Of course, your dice could be different; if you wanted, you could roll them a large number of times and perform various statistical tests on the outcomes.

Even if your dice are biased, there are various ways to extract randomness from your data to obtain unbiased random numbers.  One of the simplest approaches (though not the most efficient) was described by von Neumann in 1951:

  Von Neumann, J.  Various techniques used in connection with random digits. NIST journal, Applied Math Series, 12:36-38, 1951.

There's a description of the technique here.  Note that it depends on the die rolls being independent and identically distributed, so you would need to roll the same die in exactly the same way each time to get a truly unbiased result.


Does changing mining algorithm(SHA256) of bitcoin cause any side effect?

Apart from GPUs being more viable for mining, no, there isn't. (And asics being less viable, or more or less useless..)

Apart from maybe a difference in difficulty etc, but blocktimes and blocksizes should be the same.

(Unless ofcourse they changed it in the hardfork itself, but that has nothing to do with the mining algorithm.)

EDIT:

Note: I've answered this question in technical terms, not economic/emotional terms.


Why hash witness script instead of pubkey script in signature?

I'm just guessing, but by having the transaction commit to the scriptCode, we ensure that the signer knows what script they're signing for.  A hardware wallet, for example, can only be certain that outpoint 1234...cdef:0 pays a particular script if we give it the transaction that created that outpoint (so that it can hash that transaction, verify the txid, extract the scriptPubKey, and compare that to a provided witnessScript).  Because a transaction (without witness data) can be up to almost a megabyte in size and a spending transaction can refer to thousands of previous transactions, we create a situation where low-resource devices such as hardware wallets have a hard time verifying what they're signing.

By contrast, with BIP143, we need only tell the wallet each of the scriptCodes it's supposed to sign for.  BIP141 allows these to be up to 10,000 bytes, which is just 1/100th the maximum size of a transaction.  The wallet can examine these scriptCodes, ensure they agree with what the wallet expects, and commit to them in its signature knowing that if the person sending them the scriptCode lied about the actual scriptCode, the signature will be invalid.

This is the same reason the BIP143 signature format commits to the value of each input.  Before it had to process previous transactions in order to get their output amounts; now it just accepts whatever data it receives and signs it knowing that, if someone lied to it about the amount, the signature will be invalid.


Bitcoin-Core re-synchronizing after updating to v0.18.0

By default, Bitcoin Core does not create a configuration file. If you want to change configuration options, you can either pass startup parameters or add the bitcoin.conf yourself.


Does my segwit node only have segwit blocks?

BIP 144 equipped nodes doesn't fetch blocks from old nodes since they are only capable of providing witness stripped blocks.

If someone sent it a stripped block (e.g. by lying about their support or whatnot) and it contained any segwit using transactions then it would get dropped and the peer disconnected-- basically treated like merkle tree malleability.


How many times a single transaction can be included into different blocks?

Each transaction can only be included into one block since it spends the coins (outputs) of the origin address. Including it in a second block would be invalid because the coins are already spent.


I need to know about wallets in cryptocurrency, how do exchanges generate deposite address per user?

In exchanges like Binance when a user wants to deposit coins in bitcoin or in other coins, per user receives a unique public key?Do they have to generate pair key private/public key for each user in each coin?

I suppose they must be using a HD wallet for each users, but since one you send them your coins, everything happen in their back end they can do everything they want with them, especially for coins that dont support HD wallet, they could just generate private key then link them together in one of their database.

  Or there is a way that we can have many public key for a special private key and Binance had one private key and unlimited public key related to that?

Yes, this kind of "special private key" is called a Hierarchical Deterministic Wallets and will allow you to generate an infinite amount of private key and so public keys, addresses derivated from a master seed, and so if you know this seed you can link those private keys together

This technology is used in personal wallet software like mobile wallet, but as I said since we dont have access to the back end of exchanges like binance they could use other tactics to organize their users funds.


Is there a way to get all addresses from an Wallet?

If I was to search the blockchain for address X, then I see that it has two inputs in a transaction, X and Y.
I can safely assume that X and Y are owned by the same person?

That's usually the case, but not always.  They could be owned by different people who have cooperated.  It is possible to do this in such a way that neither party reveals their private key to the other.

Now if I look at all of the transactions for Y, and I see that it has a transaction with two outputs, Y and Z.
Then I can now assume that X, Y and Z are all owned by the same person, right?

No, that's not a good assumption.  When a transaction has two outputs, there is no reason to think they both belong to the same person.  In fact, a more common case for two-output transactions is that one of the outputs is the "real" payment, and the other is "change" that goes back to another address belonging to the same person who sent the payment.  (See How does change work in a bitcoin transaction?)  However, there is no way to be sure which is which.

If a wallet has 10 addresses, then could I not get all of those addresses using the above method?

Nope.  If you continue in this way, you'll pull in a vast number of addresses belonging to different people who were paid by your initial target (and people who were paid by them, etc, etc).  You'll also miss any addresses from the wallet that have been used independently, if they've never appeared together in a transaction with any of the other ones you saw.


Is the potential number of blocks in the Bitcoin blockchain limited?

No, there is no limit on the number of blocks in blockchain. The transaction can go on for ever.

The limit is only on the bitcoin that will ever be produced in the environment (Why was 21 million picked as the number of bitcoins to be created?) , but no limit on the number of times it can be exchanged.


How to transfer addresses from Satoshi client to MultiBit?

Notice that your private key retrieved from the Satoshi client begins with a K. According to the List of Address Prefixes, that means the key is exported in compressed form.

MultiBit's export file saves private keys in uncompressed form. Private keys in uncompressed form begin with a 5.

You can divine the uncompressed key using Bitaddress's wallet details page. Just look for the private key that begins with a 5. It's the private key that has a QR code next to it.

Repeat the latter part of your steps, adding the uncompressed key to the export file and then importing that file.


For a start and to get to know the different exchanges and wallets you should checkout: https://www.bestbitcoinexchange.io/ (I'm not affiliated with that website).

To buy and sell Bitcoin I recommend https://gemini.com and https://xcoins.io. https://coinbase.com is popular but I'm not a huge fan of them for a number of reasons.

Just sign up and add your bank account to purchase Bitcoin. Gemini allows you to buy/sell Ethereum as well.

If you're worried about adding your bank account I would use https://xcoins.io or https://localbitcoins.com


How do we verify the signature on a raw transaction using Bitcoinj?

You're interested in the following API calls:

public List<TransactionInput> Transaction.getInputs()
public Script TransactionInput.getScriptSig() throws ScriptException
public void Script.correctlySpends(Transaction txContainingThis, long scriptSigIndex, Script scriptPubKey)

Use them like so:

Transaction tx = ...
List<TransactionInput> inputs = tx.getInputs();
for(int i = 0; i < inputs.size(); i++) {
    TransactionInput input = inputs.get(i);
    Script scriptSig = input.getScriptSig();
    Script scriptPubKey = ...
    scriptSig.correctlySpends(tx, i, scriptPubKey);
}

The tricky bit is getting scriptPubKey. If you have the transactions you're spending in memory, it's as simple as input.getConnectedOutput().getScriptPubKey();

If it isn't, then you can make an educated guess by converting the address to a P2PKH scriptPubKey.

public static Script ScriptBuilder.createOutputScript(Address to)

This creates an edge case where if someone tries to spend a P2PK output, it will appear to be signed incorrectly to your program. (Both are represented by addresses.)


Who controls the Payment Hub in tumblebit?

The notion is that anyone with sufficient Bitcoins to act as collateral for the payment channels could setup a TumbleBit payment hub. This would likely be a company.

The more users a TumbleBit payment hub has the greater the privacy and utility offered so one would expect a small number of payment hubs with many users.


Please Help! !Unconfirmed transfer for over 12 hours using recommended fee?

It is confirmed now.

The fee for that transaction should be little more than 0.0001 btc.

Click "Settings" in Multibit and increase the fee to about 100 satoshi per byte to get fast confirmations.


Understanding transactions in orphan blocks

I haven't looked at this particular case, but it sound like a "simple" reorg.

When a 106 or more blocks re-organization happens: in this case block 923,255 was in the main chain, but then someone forked the chain at 923,149 (or earlier) and created new blocks. For whatever reason that fork became longer than what was the main chain and thus the fork became the main chain, leaving 923,255 and neighbouring blocks orphaned.

Note that this can easily happen on the testnet and is probably done on purpose by people to test their sortware's ability to handle (long) re-orgs for example. If such a re-org would happen on the real Bitcoin chain, it would be quite a disaster. In principle all transactions in those 106 blocks could have been double-spent. On the mainnet, it regularly happens with 1 or 2 block forks (just a matter of chance), but anything more is remarkable and luckily rare.


Is there a reliable and accurate profitability calculator?

All the calculators I have seen have been correct.

There are three typical sources of the confusion you are experiencing:

1. The calculator is NOT telling you what you will earn in the next 24 hours.

No, mining calculators cannot tell you exactly what you will earn from day to day. And they're not trying to.

If you had a dice calculator it would tell you that your average roll will be 3.5. You can roll a die 1 time, get a 6 and call bullshit because 6 is far from 3.5. But the calculator wasn't trying to tell you what your next roll will be. It cannot know the future. Neither can mining calculators.

What they are telling you is the average expected income with your hashrate mining at the given difficulty. Over the long term variance evens out, but something short like a single day has a lot of variance.

A common mistake among beginners is to try a few different mining pools for one day each and declare the one that paid the best as the most profitable pool. This is like buying one scratch ticket from three different lotteries and declaring one of the lotteries the best because you won on that ticket. This sort of thing makes absolutely no sense once you learn about variance.

2. Payouts lag behind mining work.

Another source of confusion is that pay from most pools lags behind the work you do. For example, many pools use PPLNS with shifts and pay for your work as long as your work is among the 10 latest shifts at the time when a block is found. If your work is eligible for pay (in the 10 latest shifts) for e.g. 48 hours, then it will take 48 hours before the work can no longer get paid more coins.

If you look at the pay after 2 of those 48 hours you are sure to be unhappy with how much you've been paid. This is like working a single day and then complaining to your boss that you didn't get paid, when your salary is being paid on a monthly basis. Note that 48 hours is just an example, this will vary from pool to pool.

3. Calculators don't include all the factors

This is a much smaller issue than the two others, but can still be useful to be aware of. There are many factors that affect your mining income, and most are ignored by calculators. I wrote about this here: BTC/hashes/second rates for various pools


Is bitcoin an effective way to receive international payments?

It is efficient , but I would advise read all laws before you do so. As it can get you in trouble legally.


How do I exchange one cryptocurrency (not BTC) to another (not BTC)?

Exchanging means you are swapping one currency for another. That means you need to find someone who has the currency you want, who also is willing to swap for the currency you have. The purpose of exchanges is to make that 'finding' process easy, because lots of users meet on an exchange to swap their currencies around. There is no way to 'manually' convert one currency into another without swapping with someone, because each currency is different.


Hash rate for litecoind is way below the one I get for bitcoind, is this normal?

Mining in Litecoin uses a significantly different algorithmic pattern which takes substantially longer to complete a "round".

Litecoin uses scrypt while Bitcoin uses SHA256. Usually devices are measured in Khash/Mhash for Litecoin and Mhash/Ghash for Bitcoin.

The initial concept behind this is that it would be GPU proof so everyone could use their PC. GPUs can still perform substantially well.


How can I follow the progress of miner signaling for Taproot activation during the Speedy Trial deployment?

Hampus Sjöberg has set up a site (https://taproot.watch/) with a graphic for which blocks have signaled for Taproot activation and a breakdown by mining pools. It was announced here on Twitter.
AJ Towns stated on Mastodon that once signaling starts the Bitcoin Core RPC getblockchaininfo will report the number of signaling blocks in the current period.
David Harding added on Mastodon:

If you want to implement checking yourself, you can use
the versionhex in either debug.log or the results of getblock.
Taproot is using bit 2.  See the versionbits FAQ for details about
bits:

pox also wrote an awk script that I haven't tested.
gawk -F'[= ]' '/UpdateTip/ { print("block="$7" taproot="and($9,2)) }' <~/.bitcoin/debug.log

If you are interested in which mining pools have already indicated that they will be signaling readiness for Taproot activation see taprootactivation.com.


If I bought bitcoin in the early days in some exchange for $10, would it have been lost if I kept it in the exchange?

You are correct.
Leaving your money in the hands of a third party such as an exchange means two things

so far as the Bitcoin network is concerned, you own no money at all.
when that business fails, your money is usually lost. You might get some back if there is a police investigation and/or some bankruptcy process - but you shouldn't rely on this.

Transferring the Bitcoin amount to the sole control of your own Bitcoin wallet means that your money is safe, so long as

you keep a copy of the private key(s) or seed-phrase somewhere safe, or make regular backups and remember any password.
your computer isn't hacked or infected.


What does the debug output look like when a new block is found?

I got the following output when I set gen=1 on test net:

BitcoinMiner:
proof-of-work found
  hash: 00000000502cfb2fe549f1d672ff60cab179b8c91c95fe6d4d9dce490a8e00e8
target: 00000000ffff0000000000000000000000000000000000000000000000000000
CBlock(hash=00000000502cfb2fe549, ver=2, hashPrevBlock=000000008efd2a2075c9, hashMerkleRoot=cae3a8d5d1, nTime=1355478291, nBits=1d00ffff, nNonce=119890730, vtx=1)
  CTransaction(hash=cae3a8d5d1, ver=1, vin.size=1, vout.size=1, nLockTime=0)
    CTxIn(COutPoint(0000000000, 4294967295), coinbase 03b39b00010e062f503253482f)
    CTxOut(nValue=50.00000000, scriptPubKey=031e72826fe94305e81a34e34ea316)
  vMerkleTree: cae3a8d5d1
generated 50.00
keypool keep 6
AddToWallet cae3a8d5d1  new
NotifyTransactionChanged cae3a8d5d1feb8e058ddf4a30d021a9f1f85775b474456f4d6b595ffd832b7f3 status=0
updateWallet cae3a8d5d1feb8e058ddf4a30d021a9f1f85775b474456f4d6b595ffd832b7f3 0
   inWallet=1 inModel=0 Index=0-0 showTransaction=0 derivedStatus=0
SetBestChain: new best=00000000502cfb2fe549  height=39859  work=4384611213659391  date=12/14/2012 09:44:51

ProcessBlock: ACCEPTED
CreateNewBlock(): total size 1000
Running BitcoinMiner with 1 transactions in block (189 bytes)
CreateNewBlock(): total size 1000
Running BitcoinMiner with 1 transactions in block (189 bytes)
CreateNewBlock(): total size 1000
Running BitcoinMiner with 1 transactions in block (189 bytes)
CreateNewBlock(): total size 1000
Running BitcoinMiner with 1 transactions in block (189 bytes)
keypool added key 110, size=101
connection timeout
keypool reserve 10
CreateNewBlock(): total size 1000
Running BitcoinMiner with 1 transactions in block (189 bytes)
CreateNewBlock(): total size 1000
Running BitcoinMiner with 1 transactions in block (189 bytes)
CreateNewBlock(): total size 1000
Running BitcoinMiner with 1 transactions in block (189 bytes)
CreateNewBlock(): total size 1000
Running BitcoinMiner with 1 transactions in block (189 bytes)
received getdata for: block 00000000502cfb2fe549
received getdata for: block 00000000502cfb2fe549
received getdata for: block 00000000502cfb2fe549
received getdata for: block 00000000502cfb2fe549
received getdata for: block 00000000502cfb2fe549
received getdata for: block 00000000502cfb2fe549
received getdata for: block 00000000502cfb2fe549
received getdata for: block 00000000502cfb2fe549
received getdata for: block 00000000502cfb2fe549
received getdata for: block 00000000502cfb2fe549


A limit on privpub key pairs in a wallet

As far as I know there is no limit of keys you can keep in Bitcoin-Qt. Beware though that Bitcoin-Qt only creates 100 addresses in advance with default settings and you should create backups at least every 100 transactions, or set it to generate more private-keys in advance.


How long are orphaned or stale blocks kept in bitcoin core nodes memory?

What you are referring to are stale blocks. Orphaned blocks are one for which the previous (parent) hash field points to an unknown block or to a block not yet processed by the local node. Since Bitcoin Core follows headers first approach, block headers are downloaded and validated first before downloading the block data. As a result, full nodes will never receive blocks whose parents it doesn't know about. So with the current headers first approach an orphan block will not be downloaded by your Bitcoin Core node.

Now, coming to stale blocks. All blocks are stored on the disk in the blocks/blk*.dat file. The block data that you receive from your peers, if it is valid, is stored forever in that directory. However, in order to receive stale blocks, you need to be online at the time when your peer broadcasted a block to you from different chain view. Peers will only broadcast those blocks that they view form the current active chain from their perspective. So using that command, you will only be able to retrieve the stale blocks that you received when you were online.

You can use the bitcoin-cli getchaintips command to return information about all known tips in the block tree, including the main chain as well as other branches.