BitInstant "Bitcoin Address" option is down!

From what I heard browsing /r/Bitcoin, it might be due to BitInstant running out of coins in their hot wallet to fulfil transactions. However, this question would be best asked to BitInstant directly.


The easiest way to do a double spend against someone who accepts zero-confirmation transactions is with a Finney attack. To perform a Finney attack, you must first mine a block and be willing to risk losing that block. So the answer is that if the value of the transaction is small relative to the risk of losing a block reward, you don't have to worry about the attack.

Using today's numbers: An attack with a one minute window has about a 10% chance of costing you a block. The block reward is 25 Bitcoins and a Bitcoin is around $600. So for amounts much less than $1,500, you don't need to worry about a double spend. Nobody's going to risk losing $15,000 to steal $1,500.

Note that this assumes you know how to accept zero confirmation transactions! You must watch at multiple points in the network and ensure the fee is adequate.


How does the blockchain work, explained in layman terms?

The purpose of the blockchain is to create agreement about the ownership of balances.

The problem is that if everybody was creating their own records of transactions they witness, the various records would be in different orders and any conflicting transactions would cause a split in what is considered true. At any point of time it would be very unlikely for any two sets of records to match completely.

Traditional money services solve this by having a trusted entity as the arbitrator and sole source of truth.

Bitcoin solves this differently: Each participant collects all transactions they hear about and repeatedly proposes these packaged as a set of updates. We call these sets of balance updates blocks. Instead of having a sole source of truth, the network holds a lottery to designate one of these blocks as the commonly accepted new status quo of the balances. As each block refers to the previous commonly accepted network state and by its acceptance creates a new commonly accepted network state, the blocks create the eponymic chain of commonly accepted states.

The resulting blockchain contains the record of every transaction ever performed on the Bitcoin network. It also allows any new participant to audit the accuracy of the present status quo of the network. Upon joining, they rebuild the set of balances by applying each block in the right order, and will finally arrive in agreement with the rest of the network.


What is "Key Splitting"? When would I use it?

No. Multisignature transactions involve multiple keys/signatures, whereas this involves splitting up one key.
As far as I know, it's not used at all in production. There are a whole host of issues.
P2SH was created to make multisignature transactions easier to implement for e-wallet providers and merchants, and to move the burden of multisignature transactions from the sender to the reciever.
Like so:

Generate a key
Split the key up, store the pieces in different places
Put the key back together
Sign transactions

The major problem with split-key transactions is that you need a trusted third party. When they generate the key, they could secretly store it. When they put the key back together, they could secretly sign a transaction that stole all of your bitcoins.


Shares are an accounting mechanism to allow for miners in a pool to prove how much work they did towards finding the next valid block hash and fairly divide any rewards. With solo-mining, there are no shares to account for, none to be accepted, since it is only you mining. This means if you successfully find a valid hash you will get all of the reward from it.


It's possible that your firewall is blocking the BTC node connections without blocking the price data. The price data is probably obtained through a normal port like HTTP or something, whereas the usual port for BTC connections is 8333. Other than that, the only other possibility that comes to mind is that it could have not got enough confirmations yet, blockchain.info can tell you how many confirmations your transactions have. Change the address in this URL to your own and see if the latest (top) transaction has 6 confirmations: https://blockchain.info/address/1DFNwqgF1HToPaveeoGZL4qdBDEZYUmC89.


Is there a client that can export to Excel detailed information about transactions?

You can use blockchain.info to get information about your address, then use the Export History option in the dropdown menu (slightly confusingly marked 'Filter') to export to CSV.

It doesn't do exactly what you ask for, but has one line per transaction. I'm having difficulty picturing how it would work with one line per address.

The address for querying addresses is https://blockchain.info/address/1youraddressgoeshere


how much data represents 1 satoshi? and on entire bitcoin

Bitcoin amount is simply a number in the outputs of transactions, bitcoins themselves don't really exist. For example, in this transaction, there is this output:

  "addr":"1P3VQasrhmCnViL4sVouxSZiSu1BRWuCvN",
           "value":6103964

Value is the number of satoshis in the output, these output values are the only representation of bitcoins on the blockchain.


An honest node is a node that does not try to modify history. This is opposed to an attacker node which tries to modify a past block in the blockchain presumably to benefit them financially.

Note that because transactions are cryptographically signed, "An attacker can only try to change one of his own transactions to take back money he recently spent," Bitcoin Whitepaper.


Is there a plug in for credit card charges to be converted automatically into bitcoin

No, and there likely will never be. The reason for this is that bitcoin transactions (and all other crypto currencies as far as I know) are none reversible while credit cards transactions are, for up to about a month at most banks. This means that if someone buys bitcoins with stolen credit card information and you give them the bitcoins, and then a week later the bank tells you the transaction was fraudulent, you will have to return the money, but you are never getting the bitcoins back.

A way around this would be for the seller to hold on to the bitcoins for a month and wait for the credit card transactions to definitely go through before dispersing the coins, but with the price of bitcoin as volatile as it is, I don't see this happening.


Running multiple bitcoin instances on same server system

The provided approach is correct.

A binary itself does not handle any requests. When you run bitcoind with separate instances of the config and data directories, the system will create multiple instances of the bitcoind program to execute. Each of these instances is a fully independent bitcoin node, and has no relation to any other instance running on that machine.

Copying the binary will make no difference.


How to access my bitcoin gold without compromising my hardware wallet?

As far as I can see the answer is that you can't access your BTG without one of:

A BTG app from Trezor/Ledger (note it is possible to write custom apps for the Ledger but it would want to be a LOT of BTG for you to countenance that),
Accessing the private key stored in your hardware wallet.

The second option, while not easy or as safe, would probably be the most economical from a time and effort perspective. The approximate steps to take would be:

Find or write an app that will allow you to enter your mnemonic seed. This could be done on an air gapped PC and you could microwave the harddrive afterwards if do desired,
From the master key you would then need to acquire the specific private key(s) for the transactions you want to spend on the BTG chain,
Construct and sign the transactions for that you want to spend on the BTG chain. And VERY importantly make sure whatever the transactions implement whatever BTG's replay protection mechanism is so that they can't be replayed on the BTC chain.
Copy the signed transactions from your air gapped PC onto a USB drive and broadcast with a BTG node.

Essentially that's a lot of hassle and not without a fair degree of risk. I guess it will all come down to how the value of BTG fares.

Personally I had my BTC stored in my full node wallet at the time of the BTG fork. After that I transferred them back to my hardware wallet. Now once BTG goes live I have the option of copying the wallet.dat into the BTG full node.


Bitcoin.conf setting for CPFP - how can I enable longer 'chains' of unconfirmed transactions?

The maximum unconfirmed descendant count is a mempool setting, not a wallet one. Assuming most of the network run with the default of 25, even if you changed your own mempool to accept a longer chain the last child transaction would not relay.
Anyways, in such an extreme case (a chain of >25 unconfirmed transactions) you likely want to bump your fees already. And batch your transaction next time..

how bitcoin core decides to allow an additional CPFP transaction to be chained, and when it gives an 'Insufficient Funds' error.

The wallet will by default spend unconfirmed change (transactions it itself created), but not unconfirmed incoming payments.


What is an uninitialized read? Can you point out some examples found in Bitcoin Core? How do you detect them?

An uninitialized read is when a variable is created without an initial value and then the value of this variable is read. This should be avoided as the resulting behavior is unpredictable and could be different each time the program is run. According to cppreference.com:

Normally uninitialized variables are a bad idea, and the only place where they are useful is when you are about to read the variable in from some input stream.

There are various tools for detecting uninitialized reads, some of which were covered in this Bitcoin Core PR review club session in December 2019.
These include dynamic analysis tools such as MemorySanitizer (MSan), Valgrind (specifically Memcheck) and static analysis tools that examine the code without running it.
Uninitialized reads can also be found through unit, functional or fuzz tests, by compiling with the -Werror=uninitialized flag or compiling with Clang with the -ftrivial-auto-var-init=pattern flag which will pre-initialize variables with dummy values.
History of detected uninitialized reads in Bitcoin Core
The most recently detected uninitialized read at the time of writing (October 2020) was found by Marco Falke in the recently merged Signet code. He found it through visual review and it was caught before it made it into a major Bitcoin Core release.
As practicalswift highlights, there have been a number of examples of uninitialized reads found in recent years but with more widespread usage of sophisticated tools these are likely to be found with decreasing frequency.
2020: Use of uninitialized memory in Erlay networking code - found pre-merge
2020: Use of uninitialized memory in BIP324 encrypted p2p transport de-/serializer code (truth in advertising: I haven't verified this one by writing a PoC) - found pre-merge
2020: util: Avoid potential uninitialized read in FormatISO8601DateTime(int64_t) by checking gmtime_s/gmtime_r return
2019: Use of uninitialized memory in networking code when receiving a transaction we already have - found post-merge
2019: wallet: Uninitialized read in bumpfee(…)
2018: wallet: Fix non-determinism in ParseHDKeypath(...). Avoid using an uninitialized variable in path calculation.
2018: wallet: Fix use of uninitialized value bnb_used in CWallet::CreateTransaction(...)
2017: [net] Fix use of uninitialized value in getnetworkinfo(const JSONRPCRequest&)
2017: [test] Avoid reading a potentially uninitialized variable in tx_invalid-test (transaction_tests.cpp)


First of all, transactions do not "bounce". Once a transaction is broadcast, it can confirm or remain unconfirmed indefinitely. There is no point where your transaction "expires" or the transaction "bounces" and the coins return to you; anyone who has a copy of the transaction can, at any point in time, rebroadcast the transaction and remind the network that the transaction still exists and can still be confirmed.

In order to send Bitcoin, you must be fully synced. If you are not fully synced, you risk spending coins that have already been spent and thus creating an invalid transaction. Furthermore, your wallet cannot know how much Bitcoin you actually have without being fully synced. While you can spend while unsynced, there is no guarantee that the transaction you are creating will actually be valid.


how to get private key from passpharase in php?

if you have mnemonic seed phrase
use offline
https://iancoleman.io/bip39/


What's the rationale of using ECDSA instead of RSA?

I'm not sure why you think RSA is much safer than ECDSA. As you can read here: https://crypto.stackexchange.com/questions/3216/signatures-rsa-compared-to-ecdsa

ECDSA offers same levels of security as RSA, but with a much smaller footprint.

In fact, the more you increase the security, the larger the RSA keys become compared to ECDSA.  This makes RSA less fit for a system such as bitcoin which requires small packets to be sent around the network all the time (being peer-to-peer).


Uptime and other service performance levels

You seem to conflate several issues in your question. If you are just talking about "uptime", which your question title implies, then speed of transaction propagation or confirmation is not relevant. As long as your node is can connect to other nodes and send/receive data, the network is "up". If you send transactions that require fees and they don't confirm for a long time, that's your problem, not the network's.

That said, the "gist" of your question, about network health, transaction processing speed, etc, is not unimportant. There is a bunch of useful data on this site, dedicated to monitoring the bitcoin network: http://bitcoinstatus.rowit.co.uk/ that would probably get you started in the right direction. :)


Can I send message inside the transactions script?

You will find that non-standard transactions are very hard to get into the block chain. Instead, encode the additional information as accounts and send a single satoshi to each account needed to convey your message. That way, you can use standard transactions.

Transaction 28ccf29cfcc9f82d42793db770e7c7894d61ccf3d18299f34bda2e54415da287 is a particularly silly example of this.


Can an Ethereum contract be updated without having to be re-submitted?

You can separate concerns - have a contract that the users interface with and that has a reference (an address) of another contract that contains the actual logic. Then, you can control the interface contract and update it with the address of the logic contract on updates.


Here's where they're defined:

            case OP_TOALTSTACK:
            {
                if (stack.size() < 1)
                    return false;
                altstack.push_back(stacktop(-1));
                popstack(stack);
            }
            break;

            case OP_FROMALTSTACK:
            {
                if (altstack.size() < 1)
                    return false;
                stack.push_back(altstacktop(-1));
                popstack(altstack);
            }
            break;

Example:

Stack:
Alternate Stack:
Script: OP_1 OP_2 OP_TOALTSTACK

.

Stack: 01
Alternate Stack:
Script: OP_2 OP_TOALTSTACK

.

Stack: 01 02
Alternate Stack:
Script: OP_TOALTSTACK

.

Stack: 01
Alternate Stack: 02
Script:

  what is it for? Do any specific use cases come to mind?

It's... use-impaired. 99% of the time, you can avoid using OP_(TO|FROM)ALTSTACK by putting things onto the stack in a different order. There are 18 stack manipulation operators, but only one (OP_DUP) is used with any regularity. I'm of the opinion that Bitcoin scripting is overcomplicated for its intended use.


What would happen if PoW cost were drastically reduced or eliminated?

It think you have your steps of an exploit wrong.  It sounds like you are trying to describe a 51% attack, but are ignoring several factors

First off, step 1 isn't required for steps 2-4 to occur.  A bad actor could make changes to an old block (for example, removing a transaction) and then perform the proof of work on that block and all the blocks on top.  Winning the current block isn't required until all the blocks on top of the edited one are computed and caught up to the current block height (or really chainwork).  So the order of the attack would be step 2, step 3.

Step 4 also isn't really required.  Once the attacker has a longer chain than the rest of the network, she can simply publish their blocks, and other nodes will perform a reorganization.  Whether it's the attacker or someone else that wins the next block doesn't matter.  The edit of a previous block has already occurred, and the attack is complete.

So, in your preferred format:

Bad Actor makes changes to an Old Block
Bad Actor re-hashes affected
block segments, from Old Block to Last Block — (now possible due to
low cost)
Attack complete

The problem with this is that you are assuming that only the attacker has the reduced cost for PoW.  If everyone has access to cheaper hashing, then it doesn't matter that the attacker has access, because she would still have to out-compete the rest of the network combined.  Also, even if the attacker is the only one with access, there's only a limited amount of blocks she can reasonably recompute in a timeframe.  Every 2,016 blocks the difficulty is recalculated based on the amount of time that it took to calculate the previous 2,016 blocks.  If a decent number of those blocks were calculated in secret at this much higher rate, it will increase the difficulty even for blocks calculated in secret.  At some point, the attacker would be making her own job harder.

You may want to read this question to understand better:  What can an attacker with 51% of hash power do?


Of course it's possible. Since SegWit outputs look like AnyoneCanSpend outputs, you can redeem the outputs.

I can create the redeeming transaction for you, but since transactions with ACS outputs are not relayed, you'll need to find a miner and send your transaction to them, which requires you to e-mail a mining pool owner (No one I've talked to tried this, so I don't know if they will help)

You'll need to check if your SegWit address has spent any Bitcoins. If it hasn't, send the address Bitcoins and spend the Bitcoins from that address.

Maybe you should contact this guy: https://www.reddit.com/r/btc/comments/7g6s9l/an_update_on_bch_segwit_recoveries/


Bitcoin Cash: difference between addresses

Yes.

If your wallet does not support this, you can use https://cashaddr.bitcoincash.org to convert the old addresses to new addresses, and send to new addresses.


Share the same private key on two ledger devices

Whether or not it is good practice depends on your threat model (I personally wouldn't for security reasons), but it is technically possible - the ledger devices and corresponding computer apps will have no issues with it.


The fee specified by your send transaction could be too small for any miner to include it in a block of transactions.

Some -- possibly too much -- information about fees is here: https://en.bitcoin.it/wiki/Transaction_fees


What happens when you close a payment channel on tumblebit?

All the parties who wish to pay have at least one payment channel to the Tumbler (i.e. the payment hub), all parties that wish to accept payments have a payment channel from the Tumbler to them. Thus, each payment channel is either from the user to the Tumbler or from the Tumbler to the user.


Manually extracting ledger nano s wallet public / private keys using "Mnemonic Code Converter" from ledger

Right. PIN just protect the configuration. It is not an input in the calculation.

The first normal address should be m/44'/0'/0'/0/0, the first *change address should be m/44'/0'/0'/1/0.

If you use segwit-p2sh m/49'/0'/0'/0/0 and m/49'/0'/0'/1/0. Native segwit: m/84'/0'/0'/0/0 and m/84'/0'/0'/1/0. And so on

Use the command line utils in pycoin. Pretty up-to-date. You have to somehow start from the seed though. They don't support BIP39.

EDIT: The Master Public given by ledger wallet is already derived so: to obtain the first 10 addresses with ku (pycoin) this work for me (segwit):

ku -j -s0/0-9 xpubYourMasterPublicKeyHere |jq '.p2sh_segwit'

If you don't use segwit it's much easier:

ku -s0/0-9 -a xpubYourMasterPublicKeyHere

DISCLAIMER: Don't send money on a derivation you have obtained like this unless you know exactly what you're doing!

Check that the addresses produced are the same AND you have to use the address try first with a small amount to test and check the landing on Ledgerwallet.


Is it possible to create a transaction in pure python without needing to run bitcoin locally?

In case you have not seen it, there is a good (IMHO) article which describes how to generate a transaction "manually" using "raw" python (no bitcoin libs or RPC):
"Bitcoins the hard way: Using the raw Bitcoin protocol"


How exactly are Bitcoin's consensus rules enforced?

But how exactly the consensus rules are forced?

Every single full node enforces them.

Internet says that the consensus rules are the rules thet every full node follows. And rejects blocks that do not meet consensus rules "no matter what".

Correct.

Ok.
But.
Should ALL of the full nodes accept? Or should MOST of the full nodes accept? Or is there some "holy full node" that must accept?

It doesn't matter to me what your full node does. It doesn't matter to me what anyone else's full node does. Mine enforces the consensus rules as I understand them.

What if one controls 90% of full nodes and decides to accept blocks with, say, 200btc/block? What if one controls 90% of hashpower AND 90% of all nodes AND 90% of all full nodes?

Then one has a network that won't interoperate with anyone else because it doesn't follow the consensus rules and so everything it says looks like garbage to everyone else. As far as the rest of the world is concerned, 90% of the hashing power just stopping mining valid bitcoin blocks. They won't try to make sense of the garbage that person is generating because they have no idea what it means. How would they know what the rules are that make that data sensible?
How would I even know that those blocks have a 200 BTC reward? The very same rule set that tells me where to look in the block to figure out the reward also tells me that the reward is not 200 BTC. How would my node even know how to make sense of that? Of course, it wouldn't. It would say, "that's not a block, it's some garbage that I can't make sense out of" and ignore it.
The rules my bitcoin full node follows don't provide any way to specify a block reward over 50 BTC. There is simply no way to get my full node to accept that such a thing exists because it's coded not to.

Is full node software "signed" in some way to prevent modification to consensus rules?

No. Everyone is permitted to follow whatever rules they want. Of course, they can only interoperate with people who have agreed to follow the same rules. If they cannot agree, then the network can fork with the people who have chosen different rules winding up on different blockchains.


How vulnerable are offline users of bitaddress.org, who don’t use Ubuntu?

Depends on what you are going to do with your address. As for me there are three main cases to consider:

Will you store so huge amouts of bitcoin to fear attackers who are targeting yourself directly?
Are your computer as unsecure as most of non-technical people computers (and therefore: is it possible that it is already infected by some virus)?
Or last but not least: are you doing some controversial business and fear being spyed by government or someone else who may want to know either your private keys or just that certain address belongs to you?

In fact in everyday life situations there is no need for security better than just keeping your antivirus up to date and avoiding storing generated keys on disk (which could lead to a leak if your computer gets compromised in the future). Unless you've put all your savings in BTC.


How to get list of all transactions in bitcoinj wallet?

Use Wallet.getTransactions(boolean). This returns a Set<Transaction>:

boolean includeDeadTransactions = true;
Set<Transaction> transactions = wallet.getTransactions(includeDeadTransactions);

for (Transaction t : transactions) {
    //Do something
}


How do I export my private keys from my Bitcoin-Qt client?

I believe that listreceivedbyaddress 0 true does not list the change addresses that are created as part of the normal client operation.

Starting from bitcoin 0.7, you should use bitcoind listaddressgroupings to get all the addresses, and then follow up as usual with dumpprivkey.


I've experienced the same problem. I can assume that you're creating API keys at https://coinbase.com/.

The passphrase is related to updates they made so far and you have to create API keys at https://pro.coinbase.com/


SPV (lightweight) users do not have a chain. (Well, some SPV users have a fraction of the full chain, but some SPV users only have block headers. Am I correct?)

SPV clients only keep track of the block headers, usually rely on other nodes to do the block validity verification, and do not keep any full blocks around. This may seem similar to a pruned node that only keeps a portion of the latest blocks, but is entirely different. Full nodes need the complete blocks to update the state of their ledger (the UTXO Set), pruned node fully verify each block and later discard part of the original chain. This only means that they cannot serve all blocks to other nodes and that they have to download the blocks again if they reindex, but they always have verified the full blockchain themselves. SPV nodes only track the block headers, and when they're interested in a block consume that block fully. Only then do they do some sanity checks like verifying that the block is well-formed. However, it's impossible to verify a single block fully without verifying all of its predecessors, so SPV nodes inherently trust their peers to serve them the correct blockchain.

  If a block is created by a miner and a SPV user receives this block, he must append this block to the existing block chain, but this SPV user does not have the blockchain in this case, so what does SPV user do with a block when he receives it?

SPV clients don't keep track of the full ledger, they only track the state of transactions that they created or that got sent to them. SPV clients use one of multiple methods to find out whether a block includes any interesting transactions such as delegating this completely to third parties (e.g. wallet service, Electrum server), requesting full node peers to run the SPV client's BIP37 bloom filter on any new blocks, or searching the fairly new BIP158 Compact Block Filters. Once the SPV client has identified that they're interested in a block, they either request the full block to get the actual transaction data, or they ask for the Merkle branch and the transaction.

  Do they just attach its block header to what the SPV user has at that time?

Yeah, SPV clients keep a chain of all block headers, and for any transactions they're interested in, they keep the Merkle branch that ties the transaction to the block.


This isn't a problem with git.  The problem is that the program 'a2x' is not found.  Either you don't have it installed, or it can't be found in your path.


How do I send a transaction directly to a miner or pool for processing?

You can use this service.

https://blockchain.info/pushtx

It will transmit transactions for you. Useful for testing or for sending money over TOR.


Please help. BTC has left Armory wallet and shows as gray, but says "Not in the blockchain yet"

The original questioner had a comment pointing to the solution, which I will reproduce here for completeness. TL;DR: A bug. Upgrade the software.

Details from https://bitcointalk.org/index.php?topic=1846233.0

  Update: 0.96.0 has been released. Update to that if you are still
  experiencing this problem.

  Many of you may have noticed that with the Armory 0.95.1 and Bitcoin
  Core 0.14.0, Armory tends to fail to broadcast transactions and give
  the "Transaction timed out" and "Transaction broadcast failed" error
  messages.

  The underlying issue that is causing this problem has been fixed for
  Armory 0.96, which will be released soon. However, in the meantime,
  downgrading to Bitcoin Core 0.13.2 will fix the issue. Once 0.96 is
  released, you will be able to use Bitcoin Core 0.14.0 again.

  To downgrade to Bitcoin Core 0.13.2, just download the Bitcoin Core
  0.13.2 binaries from https://bitcoin.org/bin/bitcoin-core-0.13.2/ and install them as you would normally install a new version of Bitcoin
  Core. There is no need to redownload the blockchain nor reindex
  Bitcoin Core's databases nor rebuild Armory's databases.

  Now for the technical details about the problem, for those of you who
  care.

  I first noticed this issue back in December, but only very recently
  have I nailed down why this problem cropped up in the first place.

  Bitcoin Core 0.14.0 merged a change back in December which changed how
  Bitcoin P2P messages were being broadcast. Previously, the p2p message
  header and the message payload were sent all at the same time using
  the same kernel call. However, during their net refactor and cleanup,
  this mechanism was changed to send the message header in one call, and
  then the payload in a separate call. This is more robust and allows
  for better code separation, but it also causes problems for Armory.

  The implementation in Armory 0.95.1 for receiving the p2p messages is
  not able to handle that the two parts of a p2p message are essentially
  sent separately. It interprets the message header as one p2p message,
  and the message payload as another p2p message. This means that it is
  incorrectly parsing the messages. The crux of the issue is that every
  so often Armory will receive a ping message from Bitcoin Core. However
  the payload of the ping message is only 8 bytes, but the message
  header must be 24 bytes. When Armory interprets the ping payload as a
  separate message, it will throw an exception because it thinks the
  message is too short. This exception causes the data processing thread
  to exit and disconnect from Bitcoin Core. Once it disconnects, it will
  typically reconnect, but the reconnect does not always mean that it
  will actually be receiving new blocks and transactions and actually
  remaining up-to-date with the blockchain. Thus, because of this
  disconnect, when you go to send some Bitcoin, it will fail to either
  connect to Bitcoin Core or the reconnected connection is messed up and
  the transaction broadcast times out or just fails entirely.


How do you extract the sending and receiving addresses, and the amount, from a Bitcoin transaction?

Bitcoin transactions are serialized into a hex string that contains all the necessary information to execute the transaction such as input and output values and origin and destination addresses. Blockchain.info decodes transaction hex strings to show this information.'

We can take the transaction you listed as an example and decode it:

Starting with the transaction hash:
2c1a83d5a511399f151571ff26925764ef73081251c239dd2eb6904304d7bcba

We get the hex string using blockchain.info's api:

https://blockchain.info/rawtx/2c1a83d5a511399f151571ff26925764ef73081251c239dd2eb6904304d7bcba?format=hex

Which gives us the hex:

0100000001923f8a599a04a21ef10da6330a21d29fe162d653267da012d6eededb55702e4e010000008a47304402203207e257255a21ac32fe2203f3356f6a5303b8cfca6a6b66c16a23d68f818ff902206a83cce8450aac66f300f0579d4274c6d9852ef3ea74826c9817b87dd9a0abec0141049778e7a85cad5d71cec7fde276842f744f0615897a3f28015489bf2b4bbfda11227e84ff553d7d0762baf5ff50371dfec0c1bf6f5a8ff9937e6bc9c431297981ffffffff02008c86470000000017a914ed3001d36afe91700b20d07bef089323daacc6788750647800000000001976a9140cb6c275be7f179883bb821ef1dfd6b520fc656988ac00000000

Almost all bitcoin libraries (in whatever language) have functions to decode hex strings. Here's an online service that lets you decode the hex:

http://chainquery.com/bitcoin-api/decoderawtransaction

Pasting the hex from above will give you information about the transaction.


If most G20 nations ban bitcoins, would that effectively kill bitcoin?

My thinking is that (i) G20 nations are democracies, and (ii) Bitcoin is a useful service. If it's useful to people, and people want it, they'll vote for it and it won't get banned.

If your country bans something useful to the masses, it's not a democracy. It will be banned only because it lost its utility, and if that happens, there will probably be something better replacing it.


For this task, it's better to run a full-node with the transaction indexing txindex=1. Then you can get the number of confirmations from the txid of a transaction by calling:

bitcoin-cli getrawtransaction "txid" true and checking under the field confirmations. If you have jq installed you can call for example bitcoin-cli getrawtransaction 64749d0a6ab7292ed7445609e1adb8df8d67b29e344d752971699ca75bbda78e true | jq '.confirmations' and you get your answer.

In case you are not running your node with the txindex=1 option, you need to loop through the blocks to find your transaction and the number of confirmations is obtained by subtracting the block height of the transaction from the block count. You could check if the transaction is in a block like this:

bitcoin-cli getblock $(bitcoin-cli getblockhash 610321) | jq '.tx' | grep 210d8e526f4d3f72f7cdc9014ef057aa4654f64a7b1bd059f2d8dea7fcce79cd

If the command above returns anything, the transaction is in that block.


What other purposes can I use my [obsolete] hashing hardware for?

FPGAs and GPUs are reprogrammable, so you can use them for anything. FPGAs require some specialised programming, while GPUs just use OpenCL.

ASICs have specialised chips highly optimised for mining and only mining. I don't think they could ever be reprogrammed or reused to do anything else than mining blocks according to Bitcoin rules.

As for what to do with that hardware, have you considered such noble causes as Folding@home, or perhaps less noble split-key vanity mining, for example through my Vanity Pool website?


Spending BTC from an Electrum watch-only paper wallet?

As you know, it isn't possible to spend money using a wallet that doesn't contain the relevant private-key. Your watch-only wallet cannot be used for spending.
See https://bitcoinelectrum.com/importing-your-private-keys-into-electrum/
In brief it says

These instructions are for Electrum 3.0 and later.
You cannot import private keys into an existing HD wallet.
Start new electrum wallet file
Click on next to see the wallet type selection window:
select “Import bitcoin addresses or private keys”.
Enter one private key per line. Electrum supports mini private keys and full sized keys in Wallet Import Format (WIF).

You may need to convert your BIP-38 data into WIF first.
It is worth reading their notes on why you might prefer sweeping to importing despite the transaction fees involved.


The math in the wikipedia article is primarily concerned with generating a BCH code-- which is something that was done for the design of Bech32 but obviously isn't part of the implementation itself-- and with correcting errors which isn't done with Bech32.  The article's section on encoding is blank, which is too bad because that is the one thing that's done in the Bech32 code. Even bech32 validation just works by re-encoding and checking if the new encoding matches.

Bech32 is a BCH code constructed with a characteristic-2 field. This allows its symbols to be an integer number of bit's long (5 in the case of bech32).  In this kind of field the numbers are treated as coefficients of a binary polynomial, addition is accomplished via xor, and multiplication is accomplished by shifted xors reduced mod a polynomial. As a result the workings look pretty different from what you'd expect from an algebraic description.

A fancy bech32 decoder that finds the error positions also ends up not looking too much like the algebraic decoder in wikipedia, because bech32 has performance better than guaranteed by the fact that it is a BCH code but to exploit that you must go beyond the plain algebraic decoder.  When we designed bech32 we also found a non-BCH cyclic code that had somewhat better error detection-- and would have used the same encode/validation code with different constants-- but preferred to stick with the BCH code since proving a lower bound on its performance is much simpler and there are more options for constructing fancy decoders since BCH codes can be decoded algebraically (as described in Wikipedia).

The implementation in the Bitcoin code of bech32 has an extensive description of the mathematics of it and how the mathematics relates to the implementation.


This kinda thing gets your website put in blacklists.

The only way (I know of at least) to mine in the browser is Bitcoin Plus, which actually is just a wrapper around a background Java applet. So you would probably want to make a Java miner and then work off that.


When do miners stop waiting for new transactions?

They were never "waiting" in the first place.

A miner is incrementing nonces and computing hashes continuously.  As soon as a new transaction a2 arrives, it is added to the Merkle tree, the block header is regenerated, and hashing continues with the new block header.

It's misleading to call this a "restart", since that implies there was some progress that is being lost.  Mining is progress-free.  Each hash is an independent trial with equal probability to succeed, regardless of what the underlying block header is.

To emphasize this, suppose you have a block header h1 on which you have already tried a billion nonce values, and a header h2 which has just been generated and on which no nonces have been tried yet.  If you have the choice as to which one to hash next, which should you choose, for the greatest chance of finding a winning nonce?  The answer is, it makes no difference - they both have exactly the same probability.  So there is no harm in switching to h2.


Bitcoin network is heavily loaded with thousands transactions staying unconfirmed for a long time, your funds are totally safe with Coinomi.
Your transaction will eventually get confirmed or it will be "discarded" by the blockchain network and your funds will be back in your wallet.
Unfortunatelly, there is nothing we can do to unstuck your tx.
To avoid such issues in the future you could increase the default fees for Bitcoin from Settings -> Transaction Fees.

You could also use a transaction accelerator such as https://www.viabtc.com/tools/txaccelerator/ or https://bitcointalk.org/index.php?topic=2204426.0

You could find more information about bitcoin fees through the link : https://bitcoinfees.21.co/

Coinomi Support


Yes, what you wrote is correct.

The number of confirmations a block has is defined as the number of block building on top of it.

The number of confirmations a transaction has is defined as 0 if the transactions is not included in any block and as the number of confirmations the oldest block* (block with the lowest block number; it's not about time) containing it has + 1 otherwise.

You know how many confirmations a block or a transaction has by knowing a (usually "the") longest blockchain has.

* Note that in any blockchain, a transaction is included in at most 1 block but there can be different blockchains and a transaction can be included in blocks having different block numbers in different blockchains.


Miner modify pending block (not yet on chain) and successfully solve the PoW

It is perfectly possible, and it is why it is discouraged to take irreversible action based on transactions that are unconfirmed (=not in a block yet).

However, the transaction is not invalidated just because it is reversed. Another miner can still include it at a later time, unless you issue a conflicting transaction  (=double spend) with a higher fee.


First we define some information which goes on the block, namely what version the block is, what the previous block hash was (because each block references the previous one to create the chain), what the merkle root of all the transactions in this block is (see Wikipedia if you don't know what this is), the current timestamp, and the current difficulty encoded in the bits variable:

import hashlib, struct

ver = 2
prev_block = "000000000000000117c80378b8da0e33559b5997f2ad55e2f7d18ec1975b9717"
mrkl_root = "871714dcbae6c8193a2bb9b2a69fe1c0440399f38d94b3a0f1b447275a29978a"
time_ = 0x53058b35 # 2014-02-20 04:57:25
bits = 0x19015f53

Then we take the bits value, and convert it into a difficulty target based on the steps listed in the linked wiki page on difficulty. The target is basically a number we want to find a hash below (e.g. if the target was 10, only hashes less than 10 would be valid):

# https://en.bitcoin.it/wiki/Difficulty
exp = bits >> 24
mant = bits & 0xffffff
target_hexstr = '%064x' % (mant * (1<<(8*(exp - 3))))
target_str = target_hexstr.decode('hex')

Now we start a loop, hashing the block many many times with different nonce values until we find a hash less than the target. We start the nonce off at 0, and increase it by 1 each loop so we get a different hash every time:

nonce = 0
while nonce < 0x100000000:

This is just putting the data we defined earlier (including the nonce) together into the serialised block ready to be hashed:

    header = ( struct.pack("<L", ver) + prev_block.decode('hex')[::-1] +
          mrkl_root.decode('hex')[::-1] + struct.pack("<LLL", time_, bits, nonce))

This is where we actually hash the serialised block data, obtaining a hash, which we print out (encoded as a hexadecimal string) with the nonce for logging purposes:

    hash = hashlib.sha256(hashlib.sha256(header).digest()).digest()
    print nonce, hash[::-1].encode('hex')

Finally, we compare the hash value to the target, and if it's lower than the target, we've successfully found a valid block, otherwise try the next nonce:

    if hash[::-1] < target_str:
        print 'success'
        break
    nonce += 1

Note that this is a very simple program, good for understanding, but wouldn't really work in real mining because changing the nonce alone is no longer enough variation to find a block, data is also varies in the coinbase transaction to change the merkle root as well. That's just because the target is so low (difficulty so high) that the chance of hitting it is quite low to combat the massive mining power on the network. The program also doesn't calculate the merkle root itself, which needs to be done if you're starting straight from transactions.


Huge price difference between mtgox and others - why?

Observations

Mt.Gox is currently offering neither fiat withdrawals, nor Bitcoin withdrawals.

No withdrawals means that the Mt.Gox price is completely decoupled from the Bitcoin market, as there can be no arbitrage to close the gap.

Precursors

Mt.Gox has handled the Malleable Transaction issue poorly, and squandered the trust of a lot of its users. Since shutting down withdrawals on February 10th, they have pointed fingers about an issue that was known since 2011, which they did not take into consideration when implementing their exchange software. They promised on Februar 17th that withdrawals would recommence "soon", which still hasn't happened yet, instead on Februar 20th they announced further delays. They have also not made any statements about how strongly they were affected by the issue and whether their customers money is safe. For comparison Bitstamp.net immediately communicated that all deposits were safe, and had their service fixed and secured against Transaction Malleability within a few days.

Idle Speculations (=ramblings, certainly not investment advice)

I am seeing two scenarios possible at the moment:

Mt.Gox is insolvent. This could have happened due to them unwittingly double-sending many withdrawals of a total immense amounts due to the Malleable Transaction issue.

They cannot recommence withdrawals, as the bank run would immediately take all their room for maneuvering. At the moment they can still earn a fee on every trade and enough trade just might lift them back to business.
First lawsuits are imminent. People holding fiat on the exchange might have better chances of getting some money back.

Mt.Gox actually is just communicating poorly and, being more strongly affected by the issue, requires more time to sort out all their transaction history.

Once withdrawals resume, the market will settle to somewhere between current market value and Mt.Gox value through arbitrage. Mt.Gox' market share would probably still drop significantly.

I'd be surprised if they were actually insolvent, as they would have to be making a good amount of money from exchange fees every day.


Do I need to secure my Master Public Key generated from an Electrum wallet?

The xpubkey (your master public key) is not something you need to export.

What you need to store is your seed value for the Electrum wallet. With this it can regenerate you the xpubkey.

The xpubkey is not really useful unless you are providing it to someone who intends to make multiple payments to you. If this is the case then make sure only that individual or business will be sending you funds to the address set as once the xpubkey is shared it allows them to see all addresses down that chain.


How do I get coin supply on Bitcoin core?

It depends on what you want.
If you want to know the amount of currency that has been available for miners to bring into circulation (the "210000-1 blocks of 50 BTC, then 210000 blocks of 25 BTC, then 210000 blocks of 12.5 BTC, ..." rule), the answer is no, there is no RPC that computes this. It's easy to do yourself, though.
If you want to compute the amount in circulation, namely the sum of all UTXO values, there is; it is computed by the gettxoutsetinfo command.


How can I tell what input address sent me coin?

You don't.  Bitcoin doesn't work that way.  To identify the sender, you can provide a new Bitcoin address for each payment request and then you'll know from which party the funds were sent as only that party would have that Bitcoin address.

Some services, such as SatoshiDICE, return funds to one of the inputs in a transaction.  This frequently causes losses however as those sending from a hosted (shared) E-Wallet don't own the Bitcoin address that their payment was sent from.  So returning funds to one of those inputs benefits some party other than the intended user.

Other parties use unique payment amounts to uniquely identify the sender.  For instance, a payment of 1.23 could be suffixed as 1.23000001 to differentiate that from another party that was asked to pay 1.23000002.  However doing that is no less work than simply providing a unique Bitcoin address for the two payment requests.

Planned for a forthcoming version of the Bitcoin-Qt/bitcoind client is a Payment Protocol which might be useful to you as well.


I cannot see from your screenshot, usually, the pool worker name is entered in the format userName.workerName.

Have you tried getting onto WhatsMiner support? Your question didn't say. The error message looks like it is coming from your miner actually and being reported by CGMiner. It looks like the support address for your WhatsMiner is shown in one of your screenshots.


What happens when a node goes offline for a while?

Full nodes are always in a perpetual state of "catching up to the network".  This is true if they are just booting up for the first time, have been down for a month, or have been running since the network began.  Nothing is fundamentally different about their operation.

The amount of time a node will take to catch up is determined mostly by a) how many blocks/transactions it still needs to verify, and b) how fast the node is at verifying blocks/transactions.  To a lesser extent, it is also determined by network speed (how fast it can receive blocks/transactions), but the bottleneck is usually the computational power of the node.


What you have is something called a change address. Your client used an unspent output of 1993.07508548 BTC and split it into two outputs (1993.06549173 BTC & 0.00859375 BTC). The larger output is considered change back to the sender. I would imagine the 0.008 BTC output is yours as that is the output displayed on your client.

If for some reason you wish to spend this 0.008 BTC and the amount you wish to send is 0.004 BTC, the output of this transaction will act as the unspent output of the new transaction you wish to make. The total transacted will be 0.008 BTC even though your only sending 0.004 BTC.

Here is some documentation on unspent outputs


The differences between SIGHASH_NOINPUT (BIP 118) and SIGHASH_ANYPREVOUT (proposed update to BIP 118) were discussed at the Sydney Socratic Seminar in July 2020.

There is not a real conflict between the proposals apart from the
naming. The NOINPUT original proposal was we want to have this
functionality and we’ll do it when the next version of SegWit comes
along. The next version of SegWit is hopefully Taproot. The original
way it was proposed meant that eltoo would’ve had to have been a
CHECKMULTISIG script path rather than key aggregation Schnorr key path
potentially. It is not technically any worse than what the original
concept was by having to go through the script path. It is just the
next progression now that we have some idea what the next version of
SegWit should look like.


Where does the extended block in a segwit transaction get stored?

This is defined in bip-0141:

  This BIP defines a new structure called a "witness" that is committed
  to blocks separately from the transaction merkle tree. This structure
  contains data required to check transaction validity but not required
  to determine transaction effects. In particular, scripts and
  signatures are moved into this new structure.

  The witness is committed in a tree that is nested into the block's
  existing merkle root via the coinbase transaction for the purpose of
  making this BIP soft fork compatible. A future hard fork can place
  this tree in its own branch.

This new structure represents the extended block which is attached to the merkle root of the coinbase.

If a full node doesn't understand SegWit format it won't be able to validate the transaction. But it can accept it as is, just like lightweight clients do.


Are there public LN nodes that have some gRPC LND API endpoints accessible for 3rd parties?

As far as I know there are no open nodes anywhere. But I have not been searching for them. Generally you don't need a full node / a full implementation to get the data from the lnd command subscribechannelgraph.

Basically you will only need to reimplement BOLT 07 ( https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md ) to listen to the gossip protocol.

However since the transport layer in BOLT 08 is encrypted via the noise protocol framework you will also have to reimplement this in order to be able to connect to a peer. Only your peers can be queried for the network graph from BOLT 07. The only other BOLT that you need is BOLT 01 which describes the message format of peer messages.

Implementing these allows you to interact with the peer to peer network and get information about the channel graph without the necessity to implement a full lightning node or even run a Bitcoin node. In fact you don't even need any of the Bitcoin techstack (just ecdsa for your static node key and strong authentication within BOLT 08)

I might make the network graph available via my lightning node next weekend if I remember to do so. Then there would be an open api command to query for this data. Hope that answer helped.


What percentage of Bitcoin transactions never complete?

I have watched for reports of a transaction that appeared live on the net that never got into a block. It has never happened, and I don't think it's likely to happen. The only practical way for it to happen is for the network to be split due to a connectivity problem or for a miner in cahoots with the person attempting the double-spend attack to mine a conflicting transaction (not accepted by the network) into a block before the transaction itself gets into a block.

I agree that accepting 0/unconfirmed transactions is sufficient for point of sale applications. Someone is very unlikely to attempt a double-spend in person for a few thousand dollars or less and is even more unlikely to succeed. (Update: Due to the risk of the Finney attack, I withdraw this argument.)

I think your guess is only reasonable within limits though. For big transactions, companies will sue people who charge them back. They can do the same thing with Bitcoin transactions if they ask for ID first. For face-to-face transactions, I don't think confirmations matter for transactions that aren't massive.

It's not a big deal for online transactions for a different reason. If we're talking a small payment for access to a web site, is anyone really going to bother with an attack? And does anyone care? Here, the percentage risk argument works. And for big online stuff, delivery's usually not immediate anyway (think PayPal, eBay, Amazon).


Is a hypothetical Bitcoin network on Mars guaranteed to fork from the one on Earth?

No, not necessarily, but mining in both locations is infeasible.

As Pieter explained in Is it possible to use bitcoin as interplanetary money/store of value?, exorbitant latency between miners would cause perpetual forks especially when the latency exceeds the targeted block interval. Only one of the two latency-separated mining clusters can be profitable: the stronger mining cluster will over-proportionally win cases of competing chain-tips, curbing the revenue of the weaker mining cluster due to mostly losing rewards to extinction of their blocks.

While mining is impractical, it would be possible to send and receive Bitcoin payments. Since communication between the planets could potentially be censored, a user located on Mars (i.e. the weaker mining cluster) must wait for an ample number of confirmations before relying on the payment's finality.


mnemonic pass phrase generation in wallets / hardware wallets - security flaw?

Wouldn't it be saver to generate a mnemonic passphrase manually by just taking random words from a lookup table?

No, it would not be. This method may even be insecure if you are actually doing it manually.

A BIP 39 mnemonic, if generated properly, is secure. It is just as secure if you randomly choose words too. This is because both methods require a Cryptographically Secure Random Number Generator. For BIP 39, you use a CSRNG to generate a 256 bit random number and split it up in order to produce the mnemonic. There's an additional checksum that makes the mnemonic represent a 264 bit number.

In your method, you generate 24 random 11-bit numbers (because there are 2048 words in the wordlist) and use each number to choose the word to use. While this is more random, you lose the checksum. Furthermore, it's only 8 bits more random, which is not much more random. Either way, the mnemonic is sufficiently secure, not because of the method used, but because a CSRNG was used to generate the numbers.

However if you actually do it manually, then it is likely insecure. If you are generating the numbers yourself (i.e. without the help of a CSRNG), then your seed is not going to be sufficiently random enouhg. Humans are a notoriously bad source of entropy, but you want your mnemonic to have good entropy. So doing this manually is not a very good idea.

Although you could use a 6 sided die to randomly generate your numbers, but that may not necessarily be a good source of entropy either. It would also require a few hundred rolls in order to have a sufficient number of bits.

  a wallet creator can can accidentally or on purpose use deterministic seeds for creating the mnemonic pass phrase

They could, but it would be noticed very quickly. The wallet is open source and people do actually audit the source code. People would notice if a change went in that modified its random number generation.

  but also using ledger nano s - so there is not really a way on verifying that the threat above is not implemented on the HW wallet, correct?

Not necessarily. Most of the Ledger Nano S's firmware is open source. And the seed is generated using from the secure element which has a True RNG which is AIS-31 Class PTG.2 compliant. You can check that the firmware calls the correct functions in the Secure Element SDK to use the TRNG for seed generation.

The Secure Element's firmware is closed source unfortunately, however I don't think Ledger can modify that firmware. I believe they only get a binary blob for the firmware from the chip's manufacturer, STMicroelectronics.


How is hash160 calculated from an unseen public key?

Because an address is the Hash160 (=RIPEMD160(SHA256(x))) of the public key. The transaction output lists that 160-bit hash directly.

When redeeming such an output, you provide both the public key (which must hash to the value given in the output) and a signature (which must be valid for the given public key).


Errors running bitcoind in the background

bitcoind has a -daemon command line option that will cause it to run in the background.  That is likely to work better than using nohup.

There should be a debug.log file in your bitcoin data directory where any errors will be logged.


How do the most popular Bitcoin wallets handle transactions stuck in the mempool with too low fees?

In general TX is removed after arbitrary time period (14 days for Bitcoin Core) or when mempool size is exceeded and space is needed for fresh TXs. For Bitcoin Core check this answer.


Bitcoin core does not support multiple users with separate addresses in a single wallet.

Neither does it provide for running a wallet service to other people.


What are the pros and cons of different methods for transferring Bitcoins between different wallet services?

This is a very interesting question. Of course there is no "right way" and as far as I know not even a best practice. I can't make up for myself either what I'd consider the best method, but I'll list up some considerations.

Not all clients allow exporting and/or importing private keys. I think this will be the biggest problem when you decide to go for the second method. There are even wallets that don't store individual private keys for every user, but just store all the coins from all their users somewhere together (probably for a big part in safe cold storage) and just send some when you want to make a transaction.
Transferring private keys involves some risk. Any sort of malware can be operating in your computer to monitor the appearance of private keys. F.e. malicious browser plugins scanning web pages for private keys, spyware monitoring your clipboard and looking for wallet.dat files or network spoofers monitoring private keys included in unencrypted network traffic.
Sending the coins over can cost you a transaction fee. This is normally no significant amount, but when sending much small amounts this can weigh. Of course you have to keep in mind that when you export-import the private keys, you will eventually pay the fee as well when you want to spend the coins.
When you want to transfer the coins to the wallet that will become your mail wallet, you may already have used its address on several places on the internet. When importing the private keys for other addresses will not make the coins available on your main address, but on the imported one. Most clients have no problem with sending/receiving from multiple addresses, but f.e. when you send coins with that other address to a contact that saved your main address in their contact list, they will not know that the payment comes from you.
The inverse argument of the previous one counts as well. If the address you want to move to another wallet is considered your main address (the one you shared with contacts), you will probably very much like to keep this address in your new wallet and importing it in your new wallet will be the very best option.
Just sending the money over is of course far easier than the hassle involved with transferring private keys. Some wallets f.e. don't allow you to import raw private keys but require them to be in some specific form like a wallet.dat file or some home-brew JSON format.

I hope some of my considerations help you to decide what to do with your two wallets.


How do I solo mine my own modified altcoin

The mining software (darcoin-cpu-miner- in dashpay github). It used getwork method. I changed to cpuminer which uses getblocktemplate and supports x11 also. After that I run my altcoin mining. Then it started working.


There is no such thing as multiplication (or division) of two points in the world of ECC math. This is because the points on an Elliptic Curve form a mathematical Group, rather than a Ring.

As such, you shouldn't expect the coordinates of 4*G and 2*G to be related by the method you described. The result of 2*G is not the same as multiplying each of G's coordinates by 2. You can verify, however, that

4*G - 2*G = 2*G

The subtraction here is actually shorthand for a complex, but formulaic, procedure for two ECC points. Note that subtraction is simply addition of the additive inverse in the ECC group. This is very different than the multiplicative inverse in the modular field that your Python method defined.


0 active connection to bitcoin network (testnet)

This worked for me:

addnode 185.28.76.179:18333

This "well connected testnet node" was suggested to me here.


How do I decrypt a password protected, BIP0038 address?

I found https://github.com/sour-is/bip38tool on github and after a little bit of struggle with the unfamilar golang ecosystem got it installed.

Once installed, the instructions for use are as follows:

export BIP38_PASS=<PASSWORD>
cd /usr/local/go/src/bip38tool
./bip38tool decrypt <KEY>

This produces your entire decrypted wallet including the plaintext private key which you can import into electrum or any other wallet application.


How would you find the Merkle Root with a Block that contains 6 transactions?

You would duplicate the hash of the last two txs. The tree would "look" something like this:

             abcdefef
              /  \
           /        \
        /              \
      abcd             efef
      /  \            /  \
   /        \      /        \
  ab        cd    ef        ef
 / \        / \   / \
a   b      c  d  e   f


What effect will the halt of the use of cpu-gpu miners have in the difficulty?

It won't matter. The difficulty will rise until the most efficient miners can't make a significant profit. What inefficient miners do has no effect because their actions are balanced out by efficient miners.

Essentially, take the most efficient mining setup widely available and compute the difficulty at which it just breaks even. Market forces will, over time, push the difficulty to be a bit less than that. If the difficulty is more than that, efficient miners will leave, reducing the difficulty. If the difficulty is less than that, efficient miners will enter, raising it.


Block Chain length/size may one day get unwieldy to compute

Is it possible that the length of the existing block chain will one day become unwieldy to compute?

A fully validating node, on first startup, will sync to the network by downloading and verifying the entire blockchain history. Doing so means validating every block and transaction in the blockchain history (but a node does not necessarily need store the entire history, it can opt to 'prune' old transactions that are not relevant to it, once they have been validated locally).

Right now, your 'average' PC will probably take a few days to sync. As the blockchain grows, it will take more computational time to validate the entire chain. Much work is being done to optimize these validation steps, with the goal being to maintain a low barrier of entry in terms of computational power.

Many of the important properties of Bitcoin (censorship resistance, immutability, etc)  are born of it's decentralized network of nodes, so working to ensure the largest number of users are able to run a full node is very important for maintaining a healthy network. The blockchain will continue to grow in size, so balancing this against computational resources is an important part of scaling bitcoin efficiently.

  Would it make more sense that the chain would somehow be rolled up like normal bank ledgers do with opening balance for every account every year?

Bitcoin does not use 'account balances', instead it uses an 'unspent transaction output' (UTXO) system under the hood. If I understand correctly, what you are suggesting would be to implement a 'checkpoint' that new nodes can start from.

This would mean that a new node has to place trust in the checkpoint they have received, since they will not be able to verify the authenticity of the UTXOs as being 'real bitcoins' themselves. Bitcoin is designed to be a system that can be engaged with without having to trust any other user on the network, so doing so is somewhat antithetical to its design.

If you search for 'checkpoint' on this site, you'll find some answers such as this one, which contain more info.


If you sent a coin there, of course you need to keep the wallet itself or you won't be able to claim that coin.

You may delete and re-download the blockchain, though.

Or you can try to open the wallet with another client.


Why don't most Bitcoin exchanges like Mt. Gox accept debit cards?

Main reasons :

1) Bitcoin is anonymous, free and irreversible. Credit and debit card transactions have to be reversible, Paypal transactions are reversible. So such a system would be a gold mine for card thieves, money launderers, scamers, etc. A relatively small website cannot face the risks.

2) If you're dealing with credit cards you have to follow some regulations, pay charges to the card emitter network, etc.


What are some examples of companies that have abandoned Bitcoin payment processors in favor of in house Bitcoin integration?

Some companies who have left cited privacy and security related concerns as their primary reason. It is therefore not surprising that some who have left the largest (and arguably most highly regulated) Bitcoin payment processors (Coinbase and BitPay) have chosen to remain anonymous:

https://www.reddit.com/r/Bitcoin/comments/3glqsx/after_using_bitpay_since_2013_to_run_my_online/

Here is a post from a Bitcoin Foundation member citing a need for improved privacy policies and more decentralization:

http://bitcoinfoundation.org/forum/index.php?/topic/1132-open-letter-to-bitcoin-businesses-why-im-closing-my-accounts/

Others may have moved to other providers that support more currencies than Bitcoin. This could be part of the reason Coinbase recently announced they will be adding support for Ethereum and Litecoin:

https://twitter.com/SatoshiLite/status/733531564852699136

My Google search revealed more merchants having accounts (involuntarily) closed by Coinbase, Bitpay, Circle, etc than merchants requesting a closure.  Since most businesses that accept Bitcoin online still convert it to fiat, the major payment providers offer a lot of convenience in terms of integration and currency conversion.


Most people have estimated his wealth to be around 1 Million BTC. Don't take my word for it though this post https://bitslog.wordpress.com/2013/04/17/the-well-deserved-fortune-of-satoshi-nakamoto/ is often the first referring to this discussion.


Everything MCCCS wrote is good, but just to clarify on your last question:

  How many nodes must approve/verify the winning hash before it is accepted into the bitcoin network as the next block to be added?

This question is slightly misguided: there is no 'accepting a block into the bitcoin network', because this assumes there is some network-wide threshold of acceptance that must be reached, or some sort of central yes/no switch for a block's acceptance.

The reality is that the network is made up of independently acting nodes. Each node decides for itself whether or not a block is valid, and it is by these 'consensus rules' that the network happens to come to agree on what the longest (most work) blockchain is. Once a valid block is broadcast, each node will independently work to verify that it is valid, and then add it to their local copy of the blockchain if it passes all the tests. The network is designed such that we expect all nodes that follow these consensus rules will remain in consensus, even though they are acting independently.


How to spend the change in a BIP32 super account?

You can do this with 1 transaction, it will get more expensive, but it has nothing to do with whether you use separate addresses or not (or with whether or not you're using BIP32 in any way or form, for that matter).

Bitcoin uses a UTXO model: every transaction has 1 or more inputs, and one or more outputs. Every output creates a UTXO (which you can think of as "a coin", with a certain address and a certain amount). Every input consumes an entire UTXO. Change is simply an output that goes back to yourself, because the sum of the input values exceeds the amount you want to send. Change always requires a separate output, whether it reuses an address or not.

So, what matters to the complexity (and thus cost) of your transaction is how many inputs you need. If that's outputs created in 10000 outputs, you will need 10000 inputs, regardless of whether they're all in the same address or not.


Why is it so hard for alt clients to implement Bitcoin Core consensus rules?

Because they're not known.

This may sound surprising, but you have to realize that Bitcoin's consensus rules are defined by what (economically relevant) full nodes actually enforce. We can assume at this point that that is mostly various versions of Bitcoin Core, and derived projects, but that may change over time.

However, they are certainly not defined by some document that people blessed into being the rules. Even if we would somehow create such a document, and everyone would agree to it, what would happen if we realized that there was a bug in actual implementations? In that case, you could call the implementation buggy, but you can't just change it. Any (uncoordinated) change to implementations could result in them ending up in their own fork, resulting in all preexisting coins being spendable twice on each side (the precise thing the blockchain was designed to prevent). Thus, in such a situation there would be no choice but to change the document. Essentially, Bitcoin's consensus rules can be described, but not prescribed.

All of the above is to illustrate that it is not sufficient to replicate any specific intended behaviour; you must mimick the exact behaviour of existing software. You must:

Accept every valid block, but you also reject every edge case exactly that causes rejection.
Guarantee that nodes can find each other
Guarantee that nodes continue to download blocks from each other in various circumstances
Prevent transitive disconnects/bans (A should not be able to relay a block to B - which possibly runs different software - in such a way that when B relays it to C, C disconnects or bans B).
Take performance considerations into account. If a block or transaction can be constructed that a significant amount of time to validate, you simplify selfish mining attacks. If validation time can be caused to take close to the block interval time (10 minutes), convergence across the network may fail entirely.

Even worse, all of these properties must be maintained under adversarial circumstances. Blocks may not only contain randomly stumbled-upon edge cases; people may actively try to trigger them.

Mimicking the behaviour of software exactly is a very hard problem. While there is some progress in the field of provably correct software (which includes proving equivalence between two programs), it is nowhere near advanced enough to apply to something like Bitcoin's consensus rules. As a result, the only approach for replication is reimplementing the rules as you believe they are implemented already, without strong methods to guarantee you're right.

In short, in order to replicate the behaviour, you must know the existing behaviour. And history has shown that in many cases, the existing behaviour is not exactly known:

The OP_CHECKMULTISIG redundant stack pop. This one has been known for a long time, but it probably was not known in the first months or even years of Bitcoin's history. The OP_CHECKMULTISIG opcode pops one more element off the stack than needed. People have worked around it by pushing an extra OP_0 when spending a multisig output. BIP 147 has been proposed to require that to be an OP_0 even. In Bitcoin's early days, a reimplementer would likely have incorrectly replicated this.
Compressed and hybrid public keys. According to various specifications, secp256k1 public keys can be encoded in uncompressed, compressed or hybrid formats. Bitcoin initially only used uncompressed keys (comments in the source code indicate that the original author of the software was not aware of compressed keys), but as every node at the time was using OpenSSL for validation, people were able to just start using compressed keys and the network accepted them. In this case, an unknown part of the rules was 'abused' for an improvement.
OP_SIZE does not pop the stack. All opcodes that inspect a stack element also pop that element. There is one exception to this (OP_SIZE), which at least one reimplementation got wrong.
The distinction between signature validation failure and script execution failure. Some reimplementations have initially treated signature failures as script failures (which is a correct assumption for almost all scripts, but not all). Consider a script of the form <pubkey> OP_CHECKSIG OP_NOT. This is a script that consumes one signature from the stack, and requires it to a signature that is invalid in order to pass.
Serialized size vs. normative size. Various resource limitations exists on the size of blocks, transactions, scripts, ... However, these sizes are defined in terms of the number of bytes that would be produced by serializing the data structure. Sometimes, multiple valid serializations used to exist. At least one reimplementation for period of time used the size of a block - as sent on the wire - to check against the block size limit. However, a 999999 byte block could have been sent using a longer-than-necessary serialization of the number of transactions in it, resulting in perhaps 1000001 bytes. This is a valid block, but the reimplementation would reject it.
OpenSSL's inconsistent DER parser. OpenSSL used to support signatures encoded using various deviations from the DER standard, often with arbitrary restrictions and weird differences (an integer could be encoded as a struct containing an integer), implemented in thousands of lines of hard to read C code. At the time, every reimplementation that did not use OpenSSL could have been trivially forked off by creating a transaction that abused on of those weird deviations. This is a very good example, as it is likely that nobody ever exactly knew what OpenSSL accepted and didn't. This was eventually fixed by BIP66 which made signature parsing much more restrictive, and allowed us to move away from OpenSSL after it became a network rule.
OpenSSL signature parser inconsistency. The OpenSSL signature parsing story goes further: it was discovered that one of its permitted DER deviations was platform dependent. A particular length descriptor was allowed to be up to 4 bytes on 32-bit systems and 64-bit Windows, and up to 8 bytes on others. This resulted in Bitcoin Core instances on different platforms to be inconsistent with each other even, much less be consistent with reimplementations at the time. This discovery was indirectly fixed by BIP66 as well, by requiring that the shortest possible length descriptor had to be used. The full timeline is in this disclosure.
The BDB lock limit. Early versions of Bitcoin Core (before it was called that way), up to version 0.7.x, used a chainstate database implemented in BDB. BDB is a multi-process database environment (something we don't need) that needs a preallocated number of locks to prevent concurrent access to records and deadlock detection. Turns out that the number of locks chosen was mostly enough for processing Bitcoin blocks, until one unfortunate block on March 11th 2013. This was a block with a remarkably large number of inputs (and few outputs), resulting in way more transaction records in the database model of that time being affected. The preconfigured number of locks was exceeded, the database operation failed, and Bitcoin was unable to process that block. As a result, a fork appeared. It was compounded by the fact that many miners had already upgraded to version 0.8.0 (which used LevelDB and no longer had this lock limitation), while many other nodes had not. More information can be found in the post mortem document BIP50.
... Who knows which things we don't know about yet?


A block consists of a header, and then a number of serialised transactions. The block header contains no script, it only contains data such as the merkle root of the transactions in the block (so the header commits to the list of transactions), nonce, version number, etc. Note that a block isn't encoded with JSON, it has its own serialisation format which you can find in most developer documentation (e.g. here)

The script is contained only inside transactions themselves, specifically to dictate the spending condition of an output. An output will have a scriptPubKey which holds the outputs script (usually of a specific form like P2PKH, P2SH) and the input when it's spent will contain a scriptSig which contains the spending script. In segregated witness transactions, the scriptSig will be empty and the script will instead be in the witness section of the transaction, but it's still the same principle.

Block verification takes a number of steps such as validation of the proof of work, validation that the timestamp is ok, that the coinbase transaction is ok, that all the other transactions are ok, etc etc.


What is the difference between Segwit and non-segwit?

Seg-Wit or Segregated Witness term can literally be explained, that we are segregating (separating) Witness (Signature Data) from something.

Now What is Witness?

For spending a unspent bitcoin output, one has to create and sign a transaction. The signature along with public key is included in scriptSig field,which is used to validate the transaction.
This validation content (scriptSig) is referred to here as witness.
(If multiple outputs are spent, there will be multiple scriptSig fields for corresponding inputs).

Why are we segregating (separating) it and from where?

Under SegWit contents of scriptSig fields are removed from transaction inputs [txins] and placed separately under witness field.
So, format of transaction now changed from:

[nVersion][txins][txouts][nLockTime]

to

[nVersion][marker][flag][txins][txouts][witness][nLockTime]

Why it was necessary?

Transaction ID generated in bitcoin system is double SHA256 of the serialized transaction structure.
Generation of txid in Non-SegWit transaction structure had a annoying bug known as transaction malleability, after broadcasting transaction with TXID1, any node in network could slightly alter content of scriptSig field still maintaining transaction validity, changes Transaction ID TXID1 to TXID2. Now for same transaction system has two txid's.

Other Benefits

Block Capacity Increase, as transactions are clubbed in blocks, current size limit being 1MB, separating scriptSig content from [txin] to new witness field, results in inclusion of more number of transactions.

Further Reading:

A good & simple explanation of SegWit : http://learnmeabitcoin.com/faq/segregated-witness

Benefits of SegWit :
https://bitcoincore.org/en/2016/01/26/segwit-benefits/

BIP 141: https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki


How to correctly set attributes for block hash and nBits in PIVX Fork?

I found the answer. However please correct me if there's I'm wrong in explaining this.

Basically, once we have inputs for the block, we hash the data. This hashing can be achieved using multiple techniques viz. SHA256, scrypt, X11, etc.

The issue with generating a hash for the genesis was I used scrypt algorithm to generate the hash. You may come across paste bin links with this method scrypt_1024_1_1_256_sp_sse2.

So in my case, I replaced this with the method offered by uint256 class. You can find this genesis creation logic at this pastebin.

Feel free to add anything or correct me if I'm wrong.


Why number of zeroes in bitcoin hash is increasing?

To find a valid block the hash of the blockheader must be below the target, the hash is Hex  number, everytime the difficulty is higher, the target is lower, so the number of zeroes will increase
For exemple this 32 bit number 0x00000100 contains five zeroes, if i want a number lower then this, it will contain 6 zeroes in this case: 0x000000ff
So the number of zeroes increase everytime the target is lower


Whats the easiest way to go from BTC to GBP? Paypal solution?

I assume you are asking about how to convert your BTC into GBP.

For small quantity, you can do a direct sales at one of the many bitcoin community forum, such as bitcointalk.org (particularly, the Currency Exchange sub-forum).  There is currently an active thread on the forum, where someone is buying large quantity of bitcoin and payment via cash deposit into your UK bank account.

For large quantity, you should check out major exchanges, such as MTGOX, and receive your money via Bank Wire.

Accepting payment via Paypal and other reversible transfer services should be avoided, as the buyer can take your bitcoin and reversed the payment at a later date.


How does the difficulty target affect the time to complete the block?

Have you read this? It is sort of technical, and goes into How is difficulty calculated? and How is difficulty stored in blocks?
https://en.bitcoin.it/wiki/Difficulty
re your comment about nonces: The nonce is not the difficulty. In the example below, I'm trying to find a sha256 that starts with 0. On my imaginary blockchain, a proof-of-work that starts with a single 0 is good enough. Notice that I don't change anything but the number after foo. The number after foo can be thought of as the nonce. It's just some thing I change to get a new proof-of-work.
[I] ➜  ~ echo -n "foo" | shasum -a 256
2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae  -
[I] ➜  ~ echo -n "foo1" | shasum -a 256
bb4eca334f61af3b67b5d528907d30285151610200539302f4c8cabe66225b53  -
[I] ➜  ~ echo -n "foo2" | shasum -a 256
4963bd713a7eb1bce458868b0c8472bdc8bc5929a7892a92dd24344aea92093d  -
[I] ➜  ~ echo -n "foo19" | shasum -a 256
06651ba147df6422edcd47690fd3d68795bc59636f37f10b67a94fa70fe1fdbb  - yay

Compare that with miners on the bitcoin blockchain. Currently they have to find a sha256 hash that starts with 19 0's. e.g: 00000000000000000006d31a10b4190a8f86c93189debe87a4d1fff54fbd5b23


Can we drive the bitcoin transaction fee arbitrarily close to zero by keep increasing the block size limit?

No. The fees are the incentive for the miners to continue their work, verifying transactions and including them in blocks. Mining is expensive. Eventually, the block reward will reduce to zero and the fees will be the only payment that the miners will receive.

Whatever may change with Bitcoin in the future, the fees must be able to float to the market and that must be protected, although, I do disagree that the current auction model for limited bandwidth is the optimum model for Bitcoin to be using as it is nowhere near scalable.


When the number of bitcoin reward halves after 4 years, doesn't the perceived value of a bitcoin about double?

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

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


How do you determine how much money an address has?

They don't.

You can have as many addresses as you like, and there is little anyone can do to track them all to you.

This means that usually people can know how much money a single address has, but that's pointless, since you can have multiple addresses.


What information about a transaction can be assumed accurate before confirmation?

Think of a bitcoin transaction as a paper check, and confirmation as cashing the check.  The check, itself, is no different prior to cashing than it is after cashing.  However, the person who gave you the check could have closed down his account after writing you the check, yet prior to you cashing the check, thus making the check invalid.  The check contains the same information, but the system to which it belongs changes.

So the account the check/transaction is drawn from remains the same.  The amount of the check/transaction remains the same.  Who the check is made out to remains the same.  However, whether or not the money represented by the check/transaction has already been claimed can change.

So:

  Can you verify the from address?

Yes

  Can you verify that the amount transferred is accurate?

Yes

  Can you verify that the sender has enough balance to be sending this amount?

Yes, but it could change if a competing transaction is broadcast prior to confirmation.  So in your scenario A, a double spend attempt could spend the UTXO before the "real" transaction makes it into a block.  This means that you can't verify the validity of your transaction until at least 1 confirmation.  In your scenario B, where double spending isn't economically feasible, you can assume that if the outputs the transaction inputs draw from are unspent, then the transaction is valid.

  Anything else?

Deriving additional information from a transaction is too large a topic for this answer.  You may want to look into blockchain analysis.

Also keep in mind that this check/transaction metaphor breaks down at some point.  For example, Bitcoin transactions can have multiple inputs and outputs.  Also, anyone can look to see whether an input is unspent, and not just a central authority.


Crashing problem when running 2 x 7950's on Corsair CX750 in mining rig

I eventually figured out this problem, and it was solved by lowering the voltage on the cards to 1100 or 1150.

Stock Sapphire 7950 boost cards are volted at 1250, and when running both cards concurrently it was making the system unstable and thus it would crash.  Even so, I would have expected a Corsair CX750 to still be able to handle them both, but it seems not.

Lowering the voltage through Sapphire Trixx makes the whole rig stable, and I can now run at 18/19 intensity without any problems. Heck I might even try 20 soon ;)

Hope this helps anybody out in the same situation.


Why future Bitcoin Core release shouldn't be in python?

Apart, from having to tear down the entire code, and re-write it in python and check for vulnerabilities,

This is what is known as a self-answering question. The obstacles you list are not trivial.

There is a considerable cost, a great deal of effort that could instead be spent on functional improvements to existing code.

There is also the matter of losing core developers who are skilled in C++ but may not care to use Python

Also if you are going to switch languages, it would be sensible to evaluate a much larger range. You advocate Python, I like Go, others may push for Rust, Haskell, Java, C# or any of a huge number of other possibilities.

This isn't a can of worms anyone would open lightly.


What can an attacker who controls majority or all of the full nodes do?

Here is an additional answer about what you can do if you control all fully validating nodes (but not necessarily all nodes that don't validate):

Anything

Bitcoin's security rests on auditing by full nodes. It is directly what prevents them from accepting fraudulent payments, and indirectly what makes it uneconomical for miners to produce invalid blocks (which in turn could be used to defraud non-validating clients).

If you have control over all fully validating nodes, you can effectively set the protocol rules at will. Including but not limited to theft and printing money out of thin air (beyond what the subsidy schedule currently permits).


Can they mine empty blocks?

The miner must include a coinbase transaction (which determines the mining reward), or the block will be rejected by the network. That way, the miner is awarded coins for solving a block (even if it contains no other transactions) and coins are distributed according to consensus rules.

  And how it works when there won't be any hash in empty block or there
  is a hash?

There is still other data that is hashed, including:

version, previous block hash, merkle root, unix epoch time, difficulty target (bits), and nonce.

The merkle root including only the coinbase transaction in this example.


Mining Fee for the blocks that are orphaned

If the block he mined is no longer a part of the main chain, then his mining fee for that block would simply not exist on the chain. So the miner would not retain the fee, but it wouldn't technically be 'deducted' either. 'Deducted' implies that the system is reducing the value of the miner's account. Instead, the system just has a different UTXO set, which does not include those mining fees.


yes, UINT64 is sufficient, which is in fact how the Bitcoin protocol works internally. The conversion factor from UINT64 to BTC is 1.0e8.

Not using floating point numbers is a very good idea indeed.


Regtest: address is still at zero after sending some bitcoins

getreceivedbyaddress is only able to show the balance for the addresses in the account: it stores only UTXO for these. The addresses generated with Pybitcointools are not stored in the account (contrary to addresses generated with getnewaddress).

To get the balance of any address, a block explorer is needed, which scan ALL UTXOs of the blockchain (like blockexporer.com or blockchain.info).

And for Regtest, it's more complicated since a local server is needed like https://github.com/bitcoin-abe/bitcoin-abe.

Conclusion: I"ve finally switched to Testnet mode, for convenience.


RTX 2070 and GTX 1660 super in same rig with 1000W Corsair power supply - rig shuts down

I think I figured it out guys.

I removed the Plexiglas off my case because I suspected my rig was overheating. No shutdowns so far, looks like I have to investigate water cooling


Every Bitcoin qt transaction I send comes up uncomfirmed?

With the information you provider, the most likely answer is one of two things:

Your fee may be too low. Based on current fees the fee you paid may not be enough. Keep in mind that the fees displayed here are calculated per byte so if your transaction is particularly large (in bytes not in BTC value) then you will need a larger fee.

Another possibility is that your transaction includes inputs that are themselves unconfirmed. This question will provide you with more details, with the child-pays-per-parent answer providing a possible solution if this was your problem.


How can I generate a Bitcoin address from a 12 word seed without using a computer?

While theoretically possible, the algorithms involved mean that it is practically impossible. You would need to compute the seed from your mnemonic word according to BIP 39, and then derive the keys and address from that according to BIP 32.

Generating the seed from the mnemonic alone requires executing the PBKDF2 function, which is specifically designed to take a long time for a computer to compute. The time required and the complexity of the problem mean that you've got no chance.


Will cross-input signature aggregation need a new output type?

Cross-Input Signature Aggregation (CISA) is an idea for allowing multiple inputs to be covered by a single signature. One of the main motivations is that it would allow multiple users to combine transactions they're about to send in a single transaction and reduce the overall cost. To that end, CISA is chiefly interesting for key path spends.
The current sketch for CISA would be to replace all but one of the corresponding scriptSigs with a one-byte placeholder and then to provide the signature for all the encompassed inputs in the last input's scriptSig.
Since BIP341 defines the spending rules for P2TR key path spends, but did not allow for an input to be spent with an empty scriptSig, it would not be possible to introduce CISA with a softfork for P2TR key path spends after activation of Taproot as proposed.
Therefore, a new output type would be needed that explicitly permits the placeholders employed by CISA.

As there is no formal proposal for CISA, yet, the above observations are potentially subject to change.


Does createrawtransction accept scriptPubKey and redeemScript as inputs?

Yes, it accepts them (and any other parameters you care to specify in the JSON).  No, it doesn't use them---and I don't know why Gavin used them in his example.

There's a more detailed and more up-to-date example of spending a P2SH multisig output on the Bitcoin.org developer examples page.


Software wallets and what happen if you break your computer

Every p2pkh bitcoin address has a key pair behind it i.e. a private key which remains secret and a public key.

There are two ways in which you can generate these keys. There is the old fashioned approach where the wallet is Just a Bunch of Keys (JBOK) and the newer approach where the wallet is a deterministic wallet.

In JBOK wallets the private keys are totally random and unconnected to each other. You need to backup all the private keys in this type of wallet. Furthermore, because address reuse is a bad thing new addresses are created by the wallet software all the time so you need to periodically create fresh backups of your wallet. If you fail to do this you might find that your coins were sent to some change address whose private key you don't have.

In the case of deterministic wallets also known as hierarchical deterministic wallets (HD wallets) all address specific private keys are derived from a seed. You backup the seed once and that's enough to restore your entire wallet. The downside is that if the seed is exposed you lose all your bitcoins and what's more the person who has your seed can wait for an optimal time to steal from you because all future addresses' private keys are also derived from your seed.

In recent years there has been a shift towards HD wallets. What is the reason for this shift? The reason is that the vast majority of people who lose bitcoins lose them because of their own mistakes and not because they got hacked. They lose them because they forgot their password or didn't backup their wallet file. HD wallets make backups easier and so they prevent such losses.

Regarding that bitcoin hard drive guy he didn't make a backup of his wallet. Back then the wallet would have been a JBOK type one. We don't know whether he didn't make any backups at all or whether he had outdated backups. If it's the former then not even HD wallets would have protected him because you still need to backup the seed by writing down the mnemonic or making a copy of the wallet file.


What bitcoin wallets support bip32 extended public key export?

Consider to use a hardware wallet: https://bitcoin.org/en/choose-your-wallet.
IMO all of the available hardware wallet do allow to export an xpub.

But watch out (regardless of what wallet you are going to use)!

Even if you private keys are safe when you use public child key derivation, what happens if an attacker compromises your server and replaces the xpub with a extended key controlled by the attacker?

Be careful and read about "Server Hardening".
Also, if you run a VPS or dedicated root server, your server-center operator may have full access to you file-storage.


Is this thing on? (How to tell if my cpuminer is working?)

You're using the wrong hash algorithm for Bitcoin mining. Bitcoin uses SHA256d (d = double), but cpuminer (at least the version 2.3.2 on my system) defaults to scrypt (for Litecoin) instead:

-a, --algo=ALGO       specify the algorithm to use
                      scrypt    scrypt(1024, 1, 1) (default)
                      sha256d   SHA-256d

Slush's pool is Bitcoin, so you should add -a sha256d to your command line. You'll see a much higher hash rate (scrypt is intentionally much slower to compute than SHA256) and you'll get yay!!! instead of booooo after some time in your log:

[2013-12-09 21:51:25] thread 0: 49985792 hashes, 832.61 khash/s
[2013-12-09 21:51:29] thread 1: 51072988 hashes, 841.16 khash/s
[2013-12-09 21:52:23] thread 0: 49956628 hashes, 864.18 khash/s
[2013-12-09 21:52:32] thread 1: 50469540 hashes, 808.16 khash/s
[2013-12-09 21:53:26] thread 0: 51850904 hashes, 833.58 khash/s
[2013-12-09 21:53:29] thread 1: 48489516 hashes, 855.40 khash/s
[2013-12-09 21:54:25] thread 1: 46821320 hashes, 834.33 khash/s
[2013-12-09 21:54:25] accepted: 1/1 (100.00%), 1668 khash/s (yay!!!)
[2013-12-09 21:54:25] thread 0: 50014552 hashes, 838.40 khash/s
[2013-12-09 21:54:41] thread 1: 13586032 hashes, 850.75 khash/s
[2013-12-09 21:54:41] accepted: 2/2 (100.00%), 1689 khash/s (yay!!!)

For best results, you should also use the above mentioned stratum+tcp protocol and adjust --threads to the number of cores in the system.