1. As I understand it, there's a block approximately every 10 minutes. But when I pay a high fee on my transactions, I've had confirmations happen within 30 seconds or so, and the stories of people accidentally paying really high fees seem to result in instant confirmations. How do they confirm before they're included in a block?
2. Coinbase have fees several times higher than other exchanges (a static 1.5% to Bitstamp's 0.1-0.25%). However, people still use them over Bitstamp. I'm guessing that it has some relation to the fact that Coinbase has no spread and only one price, but I don't get it. Can someone explain?
3. Are public keys related to a whole wallet or just single addresses? As I understand it, they're displayed with each transaction, so if it's related to a single address what would happen when a transaction is sent from several addresses, and if it's related to a whole wallet why wouldn't it reveal a person's association to other addresses that they own?
4. I'm a bit confused about the trust system. I read
theymos' thread about it, but I still don't quite get exactly what causes someone to have a positive rating, what the multiple different numbers mean and how DT members tie into this.
5. The transactions that I send are only to one address, but there also shows Bitcoin being sent to a second address. What is this second transaction (it's not the same amount as my fees)?
6. What are inputs and outputs to a transaction exactly? At first I thought they were just addresses that you received Bitcoin in and addresses that you're sending to, but now I think there's more to it.
7. How important really are full nodes? People seem to talk about the node count, but can't SPV be good enough for the majority if there's just one honest node willing to relay your transaction?
8. What are "anyone can spend" outputs (SegWit), and "witness blocks"?
9. In a hard fork, is there automatically a chain split or can a large economic majority render the old chain meaningless, and in a soft fork, does the chain split if a majority of hashrate moves away from the soft fork again?
I'm not a complete idiot, but I'm new so try not to add any more questions for me in your answers. Less techy explanations please.
1. They happened to submit right before a block was mined, but early enough that the transaction made it to that miner in time.
2. Not sure of all the factors, but validating KYC/AML and linking a bank account with them was relatively straightforward (I switched to them on short notice as Gox was about to go under, and needed to set up quickly).
3. There's two ways to create a wallet. In one of them, your client creates a new random private key every time you need an address. Backing up your wallet will only back up the keys generated so far, so you need to take regular backups. Each of those has an associated public key; hashing and encoding that public key creates an address. In the other (called a Hierarchal Deterministic wallet), your client creates a random private and public key (master keys, or xpriv and xpub respectively). From these, the client derives a bunch of private and public keys for each address that you need. Each of these key pairs is associated with its own address. The benefit of this is that you can back up the xpriv key once, and all the addresses you ever create from it will be protected by that backup.
4. I'm not 100% familiar with the system. Someone else can probably answer this better than I can.
5. That's a change address that your wallet creates. When you send a transaction, you are using up some so-called inputs to your transaction (which are the outputs of transactions that you receive); you can't subdivide those inputs. Hence, when making a transaction, your client selects enough of those inputs to cover the amount and fees, and includes outputs to the recipients, as well as an output sent back to you with the remainder.
6. They're amounts of coins that are available on an account. Each transaction consumes one or more inputs, and creates one or more outputs.
7. Again not as familiar, but having just one honest node presents a large risk (incentive to tamper with that node) and bottleneck.
8. Outputs have so-called output scripts, that are used to secure spending of that output. A common output type (corresponding with outputs sent to most "normal" addresses, i.e. the ones starting with 1) is P2PKH (pay to public key hash), whose script looks like: OP_DUP OP_HASH160 <PubkeyHash> OP_EQUALVERIFY OP_CHECKSIG
This means that a script redeeming it needs to provide the public key itself and a signature using that public key. The key is on the script stack, gets duplicated, hashed, compared to the pubkey hash, and the signature is checked using that key.
A segwit transaction has a script that looks like anyone can redeem it at present. However, new rules regarding how segwit clients validate that transaction will mean that they check a witness block (containing additional transaction data) for the signatures themselves, saving space in the "normal" blocks themselves, since that sig data is no longer stored there.
9. I have a vague idea of how this works but am not sure enough to answer it, since the ramifications of this for your decision-making may be extensive if/when forks occur.
