how make own gitian-sigs end detached sigs?

Instructions for setting up a Gitian building environment are available at https://github.com/bitcoin/bitcoin/blob/master/doc/gitian-building.md. Instructions for performing the gitian builds for releases are available here: https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md


There is no reason to use multiple cold storage wallets, but either way, offline-generated keys and a full sweep upon spending is enough to keep your funds completely safe. When the time comes, don't try to "test" moving funds out of cold storage. Do the full sweep.
Also see this
if my wallet is sufficiently secure, can I ever lose my coins?


Should I be worried that bitcoincore.org now suddenly only provides an "unsigned" Bitcoin Core installer?

Beginning with Taproot? Hmm... Something about this feels scary to me.

Your mistrust is misguided.

So, they are no longer making "signed" installers?

The releases are still signed with the release GPG key, what is lacking is the Windows specific binary signatures which have to be made by a paid certificate by one of several authorities Microsoft has trusted. Bitcoin Core being an open source project is having issues getting a new one issued, this is called out specifically in the release notes.
The only thing this changes is that there will be a warning when the binary is first run, it is completely meaningless  to the actual security of the system as there are other stronger verification methods already in place.

Binaries in that folder are still built using Gitian and are still verifiable as being compiled from the source code if you so choose.
Gitian binaries are still signed by hoards of people who attest that they got the same result as everybody else.
Binaries are still signed by the same GPG release key as always.

Which still is nowhere to be found on bitcoin.org, BTW

See this issue on GitHub for discussion.


How does Bitcoin protect itself from invalid peers from being broadcasted?

The client connects to peers in its database randomly (?) so even if given a set of IPs of peers in which all IPs are invalid (connection fails), the client will only be slightly disrupted by this.

A node with a lot of invalid IPs in its list of peers may take longer to find a peer that it can connect to, but at the same time that lack of connectivity prevents it from receiving any new transactions from the network as well.  So there's no increased risk of accepting a transaction that ends up being a double spnd.

This receipt of non-usable IPs can cause this specific node to not get a new block in a timely manner, but because nodes remain connected most of the time there isn't a system-wide issue just because some of the nodes remain disconnected longer than they should when switching to a new node.

When the node does come across a peer IP that it cannot connect to it will ban the node and not attempt to connect to it again for at least 24 hours.


Does Multi_Signature transactions enable trust-less payments? (Edited)

In the paper, it mentions a third party, Chuck, who will resolve disputes.

  (1): If customer (Alice) before receiving the product, signs 2-of-2
  transaction, then transaction is payable for merchant (Bob), but what
  happens if merchant (Bob) does not send the product to customer
  (Alice)?

Assuming Bob only cared about getting paid, he would always sign a transaction which paid himself, so it does little good to require his signature. If alice signed a transaction which did not pay her, it would show good faith, if there was another party involved, Chuck. Chuck would require that the product be sent to Alice before the funds would be fully released to Bob. In this case it would be a 2-of-2 multisig script requiring Alice and Chuck, and requiring Alice to sign before Bob ships the package, for example.

  (2): What happens if customer (Alice) denies to sign 2-of-2
  transaction before receiving the product, and after receiving the
  product also does not sign the transaction?

Assuming this is a 2-of-2 requiring Alice and Chuck from above, then Bob would require Alice's signature before sending the product, that way the arbiter, Chuck would be responsible. Note that using a multisig script on blockchain to trace an external physical action would require trust (from both parties) in the arbiter, Chuck, and is not completely trustless.


How is nSequence interpreted with CHECKSEQUENCEVERIFY?

First of all I am not sure what it means when e.g. the type flag of the sequence number is referred to as bit (1 << 22). Does it just mean it is the bit at position 22?

Yes. It means the bit position that is set in the integer 4194304 (in decimal) or 0x400000 (in hexadecimal).

  Similarly with the disable flag (1 << 31), is the bit at position 31? And what is its implication? It must be "unset" (=0?) to use the NEW consensus rules for the sequence number? Why is it necessary when the version field of the transaction > 2 already tells to use the new consensus rule?

Maybe some day we introduce a version 3 transaction that adds more possibilities. Maybe somebody wants to use one of the new features introduces at that time, but does not want relative locktime. He would be out of luck, as 3 is larger than 2.

  I also don't understand this sentence: "The flag (1<<22) is the highest order bit in a 3-byte signed integer for use in bitcoin scripts as a 3-byte PUSHDATA with OP_CHECKSEQUENCEVERIFY (BIP 112)." A 3-byte integer has 24 bits, or not? And one bit is used as sign. Then since the flag is the highest order bit, why is it not at position 23? And why is it represented as a signed integer, when obviously negative block-counts is marked as error by BIP112?

Integers in Bitcoin Script are always signed, and this is not changed for OP_CHECKSEQUENCEVERIFY, to avoid introducing more specific logic. As a result, the highest bit that is not a sign bit is (1 << 22).

I'll add an example later.


Possible to include a per miner transaction to prevent withholding and independent rebroadcast of a solved block?

I think you may be confused about what block withholding means.

Pools already assign unique work to miners which credits the pool, not the miner. A miner cannot take the block reward for himself.

"Block withholding" means the miner submits shares normally, unless the share happens to be a block. Then he withholds it for either sabotage or lie-in-wait. Since block finding is random, no "marking" by the pool can help it determine if the miner found a block or not.


Is it possible to determine the index of a bip32 address?

One of the privacy properties of BIP32 is that given two public keys (or even private keys), you cannot even tell whether they were generated from the same xpub or two distinct xpubs. This implies you certainly can't tell their index.


what does it mean when a transaction contain multiple inputs?

A single transaction may contain multiple inputs and outputs. It is not the transaction that is signed by the sender, but each input. The signature is in the scriptSig field of each input.

See http://en.bitcoin.it/wiki/transaction


Does the U.S. Securities and Exchange Commission govern Bitcoin?

Is a Bitcoin a security?   The SEC hasn't said that it believes it is and not communicated with or taken action, formal or informal, asserting that a miner is issuing securities or that exchanges are engaging as brokers of a security, which is a regulated activity.

Is a Bitcoin an asset or commodity?   Does your grocery store need SEC approval to sell bananas?   Or, more similarly, does a coin dealer need SEC approval to sell gold and silver bullion?

Now a broker where gold bullion is speculated on is regulated in the U.S., just not by the SEC.  The Commodity Futures Trading Commission (CFTC) is the regulatory body that addresses that.  To-date, there are no bitcoin-related services offering futures contracts, options, or anything similar which operate from the U.S.

Now issuing shares in a company is exactly the activity the SEC addresses.  There are no bitcoin-related services issuing company securities or operating a secondary market for shares that operates from within the U.S.  The regulators may still assert jurisdiction though if securities are offered to investors from the U.S.

Now there may be registration requirements for an organization that holds deposits or where an exchange interacts with the banking system they may need to register as a money transmitter, but that is not something under the SEC's purview.


Are Mastercoin addresses Bitcoin addresses?

Yeah, that's right - Mastercoin uses the same address space as Bitcoin.

You can store BTC, MSC, TMSC (Test MSC), and soon many other crypto-currencies on the same address using The Master Protocol.


How can I generate addresses for all altcoins?

You don't have to just create addresses. You have to track what's happening on each network and make sure that you actually have received funds before you can credit deposits to your customers' accounts. There are easier ways to just create addresses, but you would very much want to run at least one full node of each network under your own supervision to track the networks.


What is the relationship between a Bitcoin Private Key / Public Key / Address?

Using Elliptical Curve Digital Signature Algorithm (ECDSA), the private key is used to generate the public key, a secure hash function is then applied to the public key and a checksum appended to produce a Base58 formatted bitcoin address.
A private key collision is theoretically possible, but practically impossible due to the sheer number of them available on the network (quadrillions+).


how to parse input script of a transaction in blkzzzz.dat file?

The funky bytes, as you call them, are data-pushing op codes.  The wiki has a complete list of op codes.

For example, the op code before a signature is probably OP_71 (0x47) which pushes 71 bytes to the stack as data.  Without these data-pushing codes, there would be no way for Bitcoin to tell the difference between an arbitrary sequence of bytes (such as a signature) and op codes which need to be evaluated.

Parsing is simple:

The first byte is an op code.  Read it and do what it says.  If it's a data-pushing op code, read that many more bytes and push them onto the stack as data.
The next byte after that is an op code.  Read it and do what it says.  Repeat until all bytes have been processed.


When did BIP66 switch from activation to enforcement?

From BIP66:

  The new rules are in effect for every block (at height H) with nVersion = 3 and at least 750 out of 1000 blocks preceding it (with heights H-1000..H-1) also have nVersion = 3. Furthermore, when 950 out of the 1000 blocks preceding a block do have nVersion = 3, nVersion = 2 blocks become invalid, and all further blocks enforce the new rules.

I wrote this script to monitor the number of the last 1000 blocks that have nVersion set to 3.

require_once 'jsonRPCClient.php';

$daemon = new jsonRPCClient('http://{my_user}:{my_password}@127.0.0.1:8332/');
$blkStart = 364136 - (24 * 14 * 6);

$ver3InLast1000 = 0;
for ($i = $blkStart;; $i++) {
    try {
        $blockHashOld = $daemon->getblockhash($i-1000);
        $blockHashNew = $daemon->getblockhash($i);
        $blockOld = $daemon->getblock($blockHashOld);
        $blockNew = $daemon->getblock($blockHashNew);
    } catch(Exception $e) {
        break;
    }

    // Don't want to start subtracting until have processed 1000 blocks
    if ($blockOld["version"] == 3 && ($i - $blkStart >= 1000)) {
        $ver3InLast1000--;
    }

    if ($blockNew["version"] == 3) {
        $ver3InLast1000++;
    }

    if ($i - $blkStart >= 1000) {
        echo "$i, $ver3InLast1000\n";
    }

}

The result can be found in this pastebin.

  Block number 363724 is the block that turned on nVersion=3 enforcement for all further blocks.


Is there a self contained C/C++ code snippet out there to validate a Bitcoin public address?

This isn't precisely what you asked for, but it should be a good starting point.

https://bitcointalk.org/index.php?topic=1026.0

import re
import math
from Crypto.Hash import SHA256

def validate_bitcoin_address(self, value):
  value = value.strip()
  if re.match(r"[a-zA-Z1-9]{27,35}$", value) is None:
    raise ValueError("Contains illegal characters")
  version = get_bcaddress_version(value)
  if version != 0:
    raise ValueError("Not a standard bitcoin address")
  return value

__b58chars = '123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz'
__b58base = len(__b58chars)

def b58encode(v):
  """ encode v, which is a string of bytes, to base58.
  """

  long_value = 0L
  for (i, c) in enumerate(v[::-1]):
    long_value += (256**i) * ord(c)

  result = ''
  while long_value >= __b58base:
    div, mod = divmod(long_value, __b58base)
    result = __b58chars[mod] + result
    long_value = div
  result = __b58chars[long_value] + result

  # Bitcoin does a little leading-zero-compression:
  # leading 0-bytes in the input become leading-1s
  nPad = 0
  for c in v:
    if c == '\0': nPad += 1
    else: break

  return (__b58chars[0]*nPad) + result

def b58decode(v, length):
  """ decode v into a string of len bytes
  """
  long_value = 0L
  for (i, c) in enumerate(v[::-1]):
    long_value += __b58chars.find(c) * (__b58base**i)

  result = ''
  while long_value >= 256:
    div, mod = divmod(long_value, 256)
    result = chr(mod) + result
    long_value = div
  result = chr(long_value) + result

  nPad = 0
  for c in v:
    if c == __b58chars[0]: nPad += 1
    else: break

  result = chr(0)*nPad + result
  if length is not None and len(result) != length:
    return None

  return result

def get_bcaddress_version(strAddress):
  """ Returns None if strAddress is invalid.  Otherwise returns integer version of address. """
  addr = b58decode(strAddress,25)
  if addr is None: return None
  version = addr[0]
  checksum = addr[-4:]
  vh160 = addr[:-4] # Version plus hash160 is what is checksummed
  h3=SHA256.new(SHA256.new(vh160).digest()).digest()
  if h3[0:4] == checksum:
    return ord(version)
  else:
    raise ValueError("Bad checksum")


What determines how many transactions end up in a given block?

Miners (that is, the full node building the miner's blocks - which may be a pool) decide what they put in blocks.

Reasons for including more transactions:

Earn the fees of transactions included.
Make the Bitcoin on-chain ecosystem more useful.

Reasons against including more transactions:

Larger blocks propagate more slowly through the network, giving them a slightly larger chance for being reorganized (as a competing simultaneous block may win).


The probability of a block hash being all zeros is the same of all being ones, and the same of odd digits being ones and even digits being zeros, and the same of being every other number.

So the problem created by a future block having the same hash as the genesis block or the block the genesis block points to as its previous block is the same problem of any future block having the same hash as any existing block today. It would not be a special problem.

It's currently believed this have a very low probability to happen, as there are not known SHA256 weakness.

In the practice, however, if something so unlikely happens, maybe some software like wallets or block explorers use the 'zero' value to identify the genesis block and present some bug or erratic behavior. Maybe some miner even mines another block on top of it, and then it broadcasts the new block to the network, where it may be rejected as a sibling of the genesis block, being regarded as part of orphaned chain.


What are the constraints on Bitcoin Core's wallet passphrase?

is the passphrase a phrase I come up with?

Yes.
It is used to encrypt the wallet so that only you can use it.

is it just one word or a sequence of words?

It is up to you what characters to type and whether it includes spaces.
The program suggests "Please use a passphrase of ten or more random characters, or eight or more words"  So, if you are the sort of person to heed advice, you probably chose a passphrase following one or the other of those forms.

I have forgotten it.

See Are there Bitcoin password crackers I can use to recover forgotten passwords?
Don't use any online tools.


Will the performance of calculating the balance for an address degrade over time?

The balance is calculated from something called UTXO, this is a list of unspent coins, it is created on blockchain rescans and updated on receiving of new blocks. It is therefore not dependent on transaction history size but only all current available coins fragmentation.

There are performance issues with this solution also, but they are been worked on...


How can I find my Bitcoin address on Airbitz?

If you click in the top left that brings up the menu, select "Request". You will then be shown a screen with a QR code, your bitcoin address is below that QR.


They are trying to add new features that would help with privacy! There is an upgrade proposal known as Taproot that would come with features to enable additional transaction privacy in Bitcoin.
Note, however, that major changes like this to Bitcoin are much more difficult than they are in smaller altcoins, simply because a significant amount of infrastructure must be updated, and getting so many different people and organizations to agree to a major update is challenging, although necessary to avoid a fork in the network. Also, there is an effort to keep updates backwards compatible with existing infrastructure, which limits the extent to which major changes like this are possible.


Information to recipient of the transaction

Block explorers know some information about wallets because they belong to public entities with known addresses.

Other wallets are known because Bitcoin wallets typically follow a spending pattern where it's very easy to link together outputs and inputs belonging to the same wallet.

For example:

in most transactions all inputs belong to the same wallet
if a transaction has one output of 0.5 (or any other round number) BTC and one output of 0.158293 (or any other non-round number) it's likely that the second output is machine generated and belongs to the wallet of the sender


In creating a scriptSig, how do I sign the hash of a raw transaction?

It is not the sha256(sha256(tx_bytes)) that needs to be signed. You need to follow the specific algorithm defined inside of Bitcoin core to produce a proper digital signature. Here is where the signature encoding algorithm is defined. Notice, that this algorithm changes slightly based on the hash type you provide. This allows us functionality to include (or prevent inclusion) of extra inputs/outputs on a transaction.


What value stores can be exchanged for bitcoin purely pseudonymously?

Over a reputable, lisenced exchange? Nothing. They all require KYC (know your customer) laws to put friction in money laundering, with the exemption of Swiss based Vaultoro.

What you want is to find someone on localbitcoins.com who will meet you in a cafe or restaurant or somewhere and swap bitcoin for whatever you want, dollars, gold bars, diamonds, art, or whatever else. You call ask to meet at a place that can verify the transaction ( for example, if you wanted to anonymously buy art with bitcoin, you could ask to meet at an art gallery).

No reputable online exchange will provide this service, except vaultoro will give you gold anonymously (since they are based in Switzerland which does not have strong KYC laws.)


Do I really have to place my wallet file in the data directory?

If you want your wallet database (file) to be in a different directory than your data directory, you can use the -wallet=<path> startup option to specify a custom path to your wallet.
Quoting the manpage:

-wallet=< path >
Specify wallet database path. Can be specified multiple times to
load multiple wallets. Path is interpreted relative to  <wallet‐
dir>  if  it is not absolute, and will be created if it does not
exist (as a directory  containing  a  wallet.dat  file  and  log
files).  For backwards compatibility this will also accept names
of existing data files in .)


Need help with a .conf file to run a lighting node?

I got this code from https://medium.com/@crypto_coffee/how-to-set-up-a-bitcoin-lightning-node-b54733fbcb7f.

eclair.chain=mainnet
eclair.node-alias=”node-alias”
eclair.bitcoind.rpcport=8332
eclair.bitcoind.rpcuser=username
eclair.bitcoind.rpcpassword=password
eclair.bitcoind.zmq=”tcp://127.0.0.1:29000"
eclair.server.public-ips = [“xxx.xxx.xx.x”]
eclair.node-color=”ffffff"

Just replace the generic text with your computer's info.


Where is the downloaded Ardor blockchain stored on windows and linux?

On Windows (when using Ardor mainnet) the blockchain will be downloaded to your "C:\Users\USERNAME\AppData\Roaming\Ardor\nxt_db" folder. Make sure that you can see hidden folders. You can find your AppData folder very quickly by entering "%appdata%" in the address bar of the file explorer.

On MacOS (when using Ardor mainnet) your default user directory is ~/.ardor so the blockchain should be in ~/.ardor/nxt_db

For Linux, you usually use the Platform Independent Zip Package and the blockchain is located in the nxt_db directory in the directory of the unzipped package


How does ShapeShift operate on 0-1 confirmations

They're not saying that larger deposits will take 1 confirmation. They're saying that they will take at least 1 confirmation.

How can they do this and cover themselves from double-spending?

Sure, doing this increases the risks of double-spending. However, that might be an acceptable risk. They may have done the math and figured that the additional business they get is worth it.
They might be doing it to distinguish themselves from the bajillion other exchanges out there.
Also, they're charging a fee of 3.7%.
Edit: Clarification

With ShapeShift, what you see is what you get. The exchange rate shown is exactly what you'll receive, minus only the "miner fee."
There is no exchange fee, or service fee.

This is true, but the spread is noticeably higher than on other sites.
I arrived at 3.7% by taking the BTC -> LTC exchange rate and comparing it to the LTC -> BTC exchange rate.
1.00 BTC = 137.1636 LTC
1.00 LTC = 0.00685688 BTC

If you multiply 137.1636 and 0.00685688, you get 0.9405. This means that if you exchanged 1 Bitcoin for Litecoins and back, you would have 0.9405 Bitcoins left. (Ignoring transaction fees.) This is a change of 5.95%. Divide that by two, because you'd only exchange once.
This gets you 3.0%, which is different from my original calculation because the prices on ShapeShift have changed since then.
So there is a fee, but it's baked into the price they show you. On the other hand, if you're exchanging less than 0.33 BTC, the fee is lower than what BTC-E would charge you.


What precisely does the commonly reported network hash rate refer to?

The number reported is an estimation of the number of block headers iterated through by all miners on the network.

This means it refers to double-SHA256 hashes performed, not broken down to individual SHA256 operations. This makes the most sense, because even in the very early days (2010, perhaps before), no full SHA256 instances were being computed. Several optimizations let you skip parts of the computation.

It is an approximation, because the actual hash rate is not observable. It can be computed by looking at the created blocks on the network, and treating each as (2^256 / target) worth of attempts (so approximately 4.3 billion hashes per difficulty per block). That is the expected number of necessary hashes.

By looking at the blocks, another inaccuracy is introduced: only blocks that end up in the main chain are counted. Some blocks end up on temporary forks because another miner produces another nearly simultaneous competing block that wins. This is only a fraction of a percent today, but it does waste a small amount of hashrate, which also ends up not being counted.


Yes. Mining in your browser means mining with CPU. There are a lot of coins that focus on CPU-mining. Of course, Bitcoin is not one of them as ASIC-mining is much more effizient.

There is a useful list of coins:

  The CPU Coin List is a sortable list of Alternate Cryptocurrencies (Altcoins) that can be mined on your CPU

http://cpucoinlist.com/

By the way: Mining in the browser already happens. There is coinhive ( https://coinhive.com/ ) for example. They offer a script you can implement into the sourcecode of your website. If someone visits the site with activated javascript, the mining starts automaticly. The mined cryptocurrency is Monero.


How can one join and leave Blockchain network?

Let's say you want to send an email, so you type your email adress, your password and log in to your mail box, you type the mail receiver adress, and then send the e-mail
In case of Bitcoin, you want to send 0.001 BTC, so you log in to your wallet (A full node or an application in your phone or your desktop) you type the BTC adress, you type the amount, and then send the coins.
When you log in to your wallet, it's like you are connected to the blockchain via a node, when you sign out from your wallet you are no longer connected to the blockchain


Understanding Bitcoin protocol (through practice)

Bitcoin protocol is VERY simple. You haven't to read tons of manuals and study for years.

My point of view is (answrering your question) :

Write down on the piece of paper what you want to do.
Take your preferrable programming language (C++/Python/Delphi/Java/whatever)
Use internet sources only as referal information. Do not copy-paste
large pieces

Of course,

USE TESTNET FOR EXPERIMENTS! NOT THE MAIN NETWORK!


Are transactions with the same ScriptSig a security problem?

In the example you specified, the scriptsig is duplicated as these are p2sh-p2wpkh addresses. The actual signature is still different, with unique R values.

It is only possible to recover the private key if your have two different signatures from the same key that use the same R-value. This is avoided in any sane wallet by following rfc6979, which creates an R-value deterministically from the data being signed.


Can there be a half segwit, half normal Bitcoin transaction?

Yes, absolutely.

Every output can independently be a normal or SegWit output (when using P2SH-embedded SegWit, you can't even tell until it is being spent).

Every input can independently spend a normal output or SegWit output.

When a transaction has at least 1 SegWit input it's called a SegWit transaction.

When not all inputs are SegWit inputs, the transaction is still malleable.


Is there an intermediary that allows me to pay eBay purchases with Bitcoin?

One thing you could do is order an prepaid debit card with one of the various providers. They usually allow you to create virtual cards instantly, which are just denominated in one of the major currencies. One example is crypotopay.me


Any advice for attorney accepting bitcoin?

I'm not qualified to answer about the legal rules surrounding confidentiality. (Though, I imagine you have a better handle on California/United States confidentiality than I do anyway.) However, there are a few technical details you should be aware of.

First, transactions in Bitcoin are essentially public. The transaction amounts and the time of the transaction are both public information. That means that if you're forced to disclose the amount and day of the transaction, someone could figure out the transaction that you were paid by.

Second, transactions are linkable. That means that if someone figures out which transaction you were paid by, they could follow the money that you were paid with, and they might be able to identify your client.


How can be proven that a signature is valid with it's public key

When signing the transaction, a sha256 hash of the transaction data is taken, and a ECDSA signature of this hash is generated using the private key.
When validating the signature, we first generate the sha256 hash of the transaction data the same way, then we validate the signature using the ECDSA algorithm by passing in the signature, the public key, and the transaction hash.


Would quantum computing be able to deanonymize CoinJoin transactions?

No.

CoinJoin does not rely on any cryptography to hide transaction flows. It merely combines multiple transactions into one, and randomizes the order of inputs and outputs.

Of course, as you point out, quantum computing would allow stealing ECDSA outputs...


Does number of inputs or outputs affect bitcoin transaction fee?

Format for 1 input 2 outputs (1 to receiver, 1 change to owner). Normal non-seg transaction

P2SH    73 bytes(input) 32x2 (output)

P2PKH  about the same as P2SH

To reduce fees reduce

a) no of inputs.

b) Use exact match (with no change output) if possible.

c) when fee is low, use more inputs or consolidate your input to fewer UTXO.(reduction of input for your future tx).

I think fee reduction increases a lot when you use multi-sig using seg-wit.

Output format 2of3 multisignature
      Input size    Out size

P2SH    297 32

P2SH-P2WSH  140 32  Wrapped Segwit

P2WSH   105 43 Native Segwitness

P2TR    58* 43 Pay to Taproot

P2PKH   148 34

means the recovery is more expensive.

To be actually sure of saving then you may want to go through the exercise of manually decoding every different type of bitcoin TX with various no of input and output.

(up to byte level where U can actually count).


Why doesn't bitcoin place additional constraints on competing block chain forks, other than length of chain? (e.g., time and confirmation count)

My question then is: why doesn't bitcoin specify a maximum duration of time and/or a maximum number of confirmations, after which a competing/forking block is rejected even if it's backed by a longer chain of (secretly premined) child blocks?

Because you can't prove that to nodes that weren't on the network at the time of the attack. Which means that either:

It's possible for an attacker to create a new chain, and if enough nodes join the network while the new chain is the best one, it will lead to a situation where half of the nodes believe that one chain is the best, and half think the other chain is the best.
If you make new nodes trust old nodes when they say that the best chain isn't the real chain, you're now expanding the circle of people you trust to the people relaying the chain, in addition to the people mining it. Before, if two nodes thought different chains were best, you could download both and say with certainty that one was better than the other. If you implemented this change, you would need to decide which node was more trustworthy.

  If this would be viable, then the 51% attack scenario described above would become much harder; and as a result, the amount of time/confirmations to wait for before a transaction can be safely believed would decrease, right?

A 51% attack can double-spend outputs with any number of confirmations. The oft-quoted 6 confirmations figure comes from the Bitcoin paper, where Satoshi calculates that an attacker with 10% of the network hashpower would have less than a 0.1% chance to catch up.


Mining pool hardware and bandwidth requirements

a good dedicated server will be enough to run a pool like eligius
you will need to ln -s /dev/null debug.log ( or logrotate the file ) if you dont want to run out of space
you could use a good anti-ddos protection if your pool becomes popular ( most pools and bitcoin businesses are regularly ddosed .
concerning server load and bandwidth usage, you could be interested in reading this ( very technical ) log extract , setting this parameter ( difficulty rewrite ) can help to reduce load ( receiving more or less miners requests / second ) and / or make your pool more or less cpuminer friendly


Can you mine smaller cryptocurrencies - e.g. coins found in an ICO etc?

"Can you mine smaller cryptocurrencies?"

if they are mineable: obvious yes. (otherwise they can not be used to execute transactions so they would not have any benefit.)
but there are also some not mineable cryptocurrencies, for example ripple or cryptocurrencies which have 100% proof of stake.

"... e.g. coins found in an ICO etc?"

nearly all ICOs use tokens. a token is not a mineable coin. a token exist due to a smartcontract of another cryptocurrency. so the creator of the smartcontract can decide who gets how many tokens.


Mining was first, as you say, there had to be bitcoins to transact which must have come from mining blocks. The key is, that blocks can be empty. Most early blocks were. And even some blocks now are mined empty, e.g. this one: https://blockchain.info/block/0000000000000000005afd87cdbb34e8126674766c261619044c4c213286d72b

Blocks always contain a Coinbase transaction which pays the reward to the miner regardless of whether there are any other transactions to mine or not.

The incentive for miners to include other transactions in blocks rather than leave them empty is the transaction fees.


Is SegWit similar to/ derived from Hyperledger Fabric?

OP clearly felt his question was adequately answered by Pieter Wuille's comment:

  Segregated Witness (on a Bitcoin-like system) was first deployed in Elements Alpha, released in May 2015, while the Hyperledger project only started in December 2015. It's also a very straightforward design (and arguably Bitcoin's legacy one was the weird one), several from scratch projects never considered anything else

  Is SegWit derived from Hyperledger Fabric?

No, the dates above make this very unlikely.


Every client on the Bitcoin network validates incoming blocks, to check that they conform to all the requirements of the Bitcoin protocol.  One of the checks is that the block reward (coinbase transaction) is for an appropriate amount.  Blocks that fail this are rejected by the client, and conforming miners will not link their own blocks to  them, so such a block will not be incorporated into the block chain.

If you tried to make such a block, and then spend the coins you awarded yourself, those transactions would also be rejected as invalid.  Other participants on the Bitcoin network would not consider those transactions as valid payment, and would not give you goods or services in exchange for them.

It would be roughly as if you were to walk into a coffee shop and try to pay for coffee using a one-dollar bill, on which you had crossed out "One Dollar" with a crayon, and written "Five".  They wouldn't accept it, and they wouldn't give you any coffee for it.


How to denote  script in P2SH transaction?

Short Answer
Yes, but there's more than one.
Long Answer
Bitcoin scripts are a stack-based language. The 'separators' are the Bitcoin push-data-onto-stack instructions. There are multiple instructions to push data onto the stack:

OP_0, OP_1, OP_2, ...
0x01-0x75 (Yes, that's their real name)
Push opcode bytes onto the stack
This is most common - the average piece of data in Bitcoin is shorter than 75 bytes.
PUSHDATA1 - Read 1 byte, convert to int, read that many bytes
PUSHDATA2 - Read 2 bytes, convert to int, read that many bytes
PUSHDATA4 ...
OP_1NEGATE - Pushes -1 onto the stack. Somewhat use-impaired.

There's a useful rule of thumb here, though it's not always correct. Take the first byte. Convert it to a number. Count that many bytes forward. That's a single piece of data. Repeat.
Let's work through an example. Let's find the elements of the input script for this transaction.

0100000001cce488677848b7a962f01a525d7cd78139a5be1ab75ead5b7336ba6f512d0388010000008b483045022100b65463abe3b5f79dbe9556180e60db4b6b3a6db7c43132e1e396e73023b34d2402206a412868470f8b83dc266a364b79e0a2acd0f5642181f7d0212c7ea608271a4a0141040ab8f88b419c62dba59d2e685bd3bc07367236d841abf3068b5886cd7a6c7297e721d42a41cb1bbd69ed684cc5d5c738d611d886c4493280b26637abad5603a5ffffffff0280f0fa02000000001976a914f593d5cfb3b74ac2988815cdf26c0420981385b788ac50d2a019000000001976a9148a0c13d08a36e68aa5294ca7e6f06a9946c3f1d588ac00000000

Break it up, find the input script:

version: 01000000
inputs: 01
hash: cce488677848b7a962f01a525d7cd78139a5be1ab75ead5b7336ba6f512d0388
vout: 01000000
input script len: 8b
input script: 483045022100b65463abe3b5f79dbe9556180e60db4b6b3a6db7c43132e1e396e73023b34d2402206a412868470f8b83dc266a364b79e0a2acd0f5642181f7d0212c7ea608271a4a0141040ab8f88b419c62dba59d2e685bd3bc07367236d841abf3068b5886cd7a6c7297e721d42a41cb1bbd69ed684cc5d5c738d611d886c4493280b26637abad5603a5
seq: ffffffff
outputs: 02
amount: 80f0fa0200000000
output script len: 19
output script: 76a914f593d5cfb3b74ac2988815cdf26c0420981385b788ac
amount: 50d2a01900000000
output script len: 19
output script: 76a9148a0c13d08a36e68aa5294ca7e6f06a9946c3f1d588ac
lock_time: 00000000

Now, we know the first piece of data is 0x48 (72) bytes long.

48...3045022100b65463abe3b5f79dbe9556180e60db4b6b3a6db7c43132e1e396e73023b34d2402206a412868470f8b83dc266a364b79e0a2acd0f5642181f7d0212c7ea608271a4a01...41040ab8f88b419c62dba59d2e685bd3bc07367236d841abf3068b5886cd7a6c7297e721d42a41cb1bbd69ed684cc5d5c738d611d886c4493280b26637abad5603a5

The second part is 0x41 (65) bytes long:

48...3045022100b65463abe3b5f79dbe9556180e60db4b6b3a6db7c43132e1e396e73023b34d2402206a412868470f8b83dc266a364b79e0a2acd0f5642181f7d0212c7ea608271a4a01...41...040ab8f88b419c62dba59d2e685bd3bc07367236d841abf3068b5886cd7a6c7297e721d42a41cb1bbd69ed684cc5d5c738d611d886c4493280b26637abad5603a5...


I think the best point to start with is: https://en.bitcoin.it/wiki/PHP_developer_intro
Nothing much to say, just read and follow the steps.


Can a scriptPubKey have multiple addresses?

Any of the addresses in that array can spend that output. Multisig transactions will give you multiple addresses there.


ELI5: does the number of 0's required in mining for SHA256 over the years strictly increase, or does it depend on how many miners there are?

Leading zeroes
The number you refer to is usually called the mining difficulty or target.
The aim of miners is to produce a block with a hash less than that target.
If you represent numbers in binary, a number with more leading zeroes is a smaller number.
For example 00010 (2) is smaller than 00101 (5)
However you shouldn't think about leading zeroes because 00101 (5) is smaller than 00110 (6) but bigger than 00100 (4) although all have the same number of leading zeroes.
It is an arithmetic relationship that is tested, not the number of leading zeroes.
Target value and mining
The target is adjusted up and down regularly. It doesn't continually increase.
The target is adjusted to make the average time to find a new block close to 10 minutes.
This means as there are more miners the target is likely to increase. But more importantly, if there were fewer miners but each had more powerful hardware, the target would also increase, not decrease. It is the total amount of mining power, not the number of miners, that affects the target.
In the past, when the value of bitcoin fell, the value of the mining reward also fell. This can result in less efficient miners leaving the mining business and the difficulty target dropping not rising.

Miners assemble a block of transactions selected from a pool, then calculate the hash, if too big, they make a small change to the block, like change the nonce value, and recalculate the hash, they repeat this until either they find an arrangement that hashes to a value smaller than the target or until some other miner beats them and they have to start all over again.


Which Two-factor authentication methods are available at which exchanges?

Bitcoin Currency Exchanges:

Mt. Gox: OTP using YubiKey or Google Authenticator

Options: [On Login] | [For WIthdrawals] | [For Changes To Security]

Camp BX: OTP/Google Authenticator
Bitstamp: OTP/Google Authenticator
Bitcoin-24: OTP using Google Authenticator and for withdrawal SMS messaging
Bitcoin-otc: GPG authentication with gribble bot
BitMarket.eu: OTP/Google Authenticator
Coinbase - OTP/Authy or OTP/Google Authenticator
FYB-SG (Singapore) - OTP/Google Authenticator
VirWoX - OTP/Google Authenticator
WeExchange.co - OTP/Google Authenticator
BTC-E - OTP/Google Authenticator
Local Bitcoins - OTP/Google Authenticator
bitcoin.de - OTP/Google Authenticator or Yubikey (but not Mt. Gox Yubikey)

Other Exchanges:

MPEx: GPG authentication
ICBit.se: OTP/Google Authenticator
BTC Trading Corp (BTC-TC): OTP/Google Authenticator or YubiKey
BitFunder: OTP/Google Authenticator

Other Services:

BitPay: OTP/Google Authenticator

EWallets:

Blockchain.info/wallet - Google Authenticator, e-mail verification, SMS, and YubiKey (but not Mt. Gox YubiKey).
WalletBit - SecureCard (or perhaps OTP/Google Auth has been added now?)
Coinbase - SMS text messaging-based two-factor, Authy (Android/iOS app similar to Google's)
Paytunia - OTP/Google Authenticator or Yubikey (but not Mt. Gox Yubikey)
bitZino - OTP/Google Authenticator
Just-Dice - OTP/Google Authenticator

Mining Pools:

MaxBTC - Yubikey and Google Authenticator
EclipseMC - Supports Yubi/GA OTP


Bitcoin Core What default values should I pass for some positional RPC params in sendtoaddress

The fee estimator works by targeting the number of blocks that will occur between the time when you broadcast and when it confirms. So a confirmation target of 6 would mean that the fee estimator is trying to get your transaction confirmed within 6 blocks. The fee estimator does not know within how many blocks you want your transaction to be confirmed, so it asks you as a parameter.

The default value for this is 6, but you can set it to whatever you want.


What are the internal details of GetWork() .. the foundation of Bitcoin mining?

You can find some examples of the GetWork protocol here.

Generally, the pool provides a block header that is to be hashed with various nonces, as well as some additional information, such as:

hash1, which is always "0000000000000000000000000000000000000000000000000000000000000000000000800000000 0000000000000000000000000000000000000000000010000"
midstate (deprecated), a value calculated by hashing half of the block header, used to speed up the process. Midstate is deprecated, as it is redundant data that can be calculated by the miner.
target - the target that is to be used to determine if the header is hashed correctly
Various other protocol extensions

The pool has to keep a track of the various block headers sent, as well as their corresponding blocks.

Generally, the transactions that are included in the block are all the transactions that the pool knows about (with some exceptions, for example some pools exclude 0 fee transactions altogether).
The order of the transactions can be random, but the coinbase transaction is most often the first transaction in the block.
Most miners will work on different sets of transactions, but most often it will just differ by the coinbase transaction or their order.
If a transaction is included in a block that gets overwritten by a fork it will be be treated as a new transaction to be considered for inclusion in the block. Provided there was no double-spend attempt, it should be included in the future blocks.


Create an OP_RETURN tx and validate it's existence in Regtest

I'm not familiar with the Java API you are using but here are the steps and a C# code sample that I used to create a valid transaction on regtest. The sample and steps are from my rough and ready dev notes so there may be a few leaps of faith (hopefully not).

You'll need to adjust the steps below for your own paths/OS/set up.

Step 1: The command line used for the local bitcoin full node in regression test mode (https://bitcoin.org/en/developer-examples#regtest-mode):

"C:\Program Files\Bitcoin\daemon\bitcoind" printtoconsole -datadir=f:\temp\bitcoind -server -regtest -debug=1

Step 2: The command line used to request the bitcoin daemon to generate a 101 height blockchain:

"C:\Program Files\Bitcoin\daemon\bitcoin-cli" -datadir=f:\temp\bitcoind -regtest generate 101

Step 3: If the bitcoin server node was initialised with an empty blockchains the getbalance command should now display a 50.00000000 which represents the coin base amount from the first block following the genesis block.

"C:\Program Files\Bitcoin\daemon\bitcoin-cli" -datadir=f:\temp\bitcoind -regtest getbalance

Step 4: To find the transactions available for spending.

"C:\Program Files\Bitcoin\daemon\bitcoin-cli" -datadir=f:\temp\bitcoind -regtest listunspent
["C:\Program Files\Bitcoin\daemon\bitcoin-cli" -datadir=f:\temp\bitcoind -regtest getrawtransaction  true]

Step 5: To get the private key to sign a spend transaction (MAKE SURE -regtest IS SPECIFIED OTHERWISE YOU COULD EXPORT YOUR LIVE PRIVATE KEY AND POTENTIALLY LOSE $$$).

"C:\Program Files\Bitcoin\daemon\bitcoin-cli" -datadir=f:\temp\bitcoind -regtest dumpprivkey

Step 6: After sending a transaction check whether it was accepted as valid and added to the mempool.

"C:\Program Files\Bitcoin\daemon\bitcoin-cli" -datadir=f:\temp\bitcoind -regtest getrawmempool

Step 7: If the transaction is successfully validated and accepted into the mempool then the next step is to generate a block that includes it.

"C:\Program Files\Bitcoin\daemon\bitcoin-cli" -datadir=f:\temp\bitcoind -regtest generate 1

Step 8: The address that the coins were sent to can then be checked to verify that the coins were received (not you can't use getbalance unless the send to address's private key is imported into the wallet).

"C:\Program Files\Bitcoin\daemon\bitcoin-cli" -datadir=f:\temp\bitcoind -regtest importaddress mssuKhM1CMDgcCm3LyGunA1o6129FnkHyk rescan
"C:\Program Files\Bitcoin\daemon\bitcoin-cli" -datadir=f:\temp\bitcoind -regtest getreceivedbyaddress mssuKhM1CMDgcCm3LyGunA1o6129FnkHyk

In the code sample below you need to replace the keys with the ones you extract using the bitcoin-cli steps above. There's undoubtedly an easier way to do this and these notes are from my first couple of weeks mucking around with Bitcoin.

using System;
using System.Threading;
using NBitcoin;
using NBitcoin.Protocol;
using log4net;

namespace SpendTransaction_WithCli
{
    class Program
    {
        static ILog logger = log4net.LogManager.GetLogger("default");
        static Network _network = Network.RegTest;

        static string _unspentTxId = "5d1db816efc865ab33eb8d5c9f0238501dfd849fc67cc941565236b36e43b234";    // Need to get this from bitcoin-cli (see Step 4 above).
        static string _unspentScriptPubKey = "03c1a1a614c8549373b2ec35f586aa8b33a3bf5ac3e0a1b8cf27e650bdb5a126f0 OP_CHECKSIG"; // Need to get this from bitcoin-cli (see Step 4 above).
        static string _sendFromPrivateKey = "cQYdUpoeJZP7FmxUeiaKSLPo9eHsDAYbWs17DgY44yHX2sATK2Cw";         // Need to get this from bitcoin-cli (see Step 5 above).
        static string _receiveToPrivateKey = "cR7X4Nd5WqA5mNwgX67th4Jo3K9vTTm28w8njLL9JT8hHPdbstL8";        // This is an arbitrary key that is used to send some coins to.

        static void Main(string[] args)
        {
            log4net.Config.XmlConfigurator.Configure();

            // Set up the private keys and addresses for the sender and receiver.
            Key sendFromPrivKey = Key.Parse(_sendFromPrivateKey, _network);
            BitcoinPubKeyAddress sendFromAddr = sendFromPrivKey.PubKey.GetAddress(_network);

            Key receiveToPrivKey = Key.Parse(_receiveToPrivateKey, _network);
            BitcoinPubKeyAddress receiveToAddr = receiveToPrivKey.PubKey.GetAddress(_network);

            logger.DebugFormat("Sending from {0} to {1}.", sendFromAddr, receiveToAddr);

            logger.Debug(sendFromPrivKey.ScriptPubKey);
            logger.Debug(sendFromPrivKey.PubKey);

            // Create the transaction to spend the bitcoin.
            OutPoint spending = new OutPoint(uint256.Parse(_unspentTxId), 0);
            Script spendScriptPubKey = new Script(_unspentScriptPubKey);

            var spendTx = new Transaction();
            spendTx.Inputs.Add(new TxIn(spending, spendScriptPubKey));
            spendTx.Outputs.Add(new TxOut(Money.Parse("49"), receiveToAddr.ScriptPubKey));

            spendTx.Sign(sendFromPrivKey, false);

            logger.Debug(spendTx.ToString(RawFormat.BlockExplorer));

            // Send the transaction to the local bitcoin node.
            using (var node = Node.ConnectToLocal(_network))
            {
                node.VersionHandshake();
                node.SendMessage(new InvPayload(InventoryType.MSG_TX, spendTx.GetHash()));
                node.SendMessage(new TxPayload(spendTx));
                Thread.Sleep(500);
            }

            Console.WriteLine("Press q to quit...");

            while (true)
            {
                var keyPress = Console.ReadKey();
                if (keyPress.KeyChar == 'q')
                {
                    break;
                }
            }

            Console.WriteLine("Exiting...");
        }
    }
}


How to consolidate a large amount of unspent outputs?

To consolidate coins to a single address, just send a transaction for the entire amount stored in your wallet to a new address. You shouldn’t need any outside tools, just use the wallet software to send a transaction to yourself.

You should pretty much never enter your private keys into an online website/service. Access to your private keys could allow that service to steal your coins, there is very seldom a reason you should need to trust someone else to not rob you of your bitcoin.


What is the currently most efficient and reliable method to store the Bitcoin blockchain in a local database?

There are roughly two approaches as you've noticed:

process the block .dat files from running bitcoind
rpc to a node, pull blocks or headers, and batch process them in parallel

For speed, probably doing #1 is best, as BitcoinDataBaseGenerator does.  Unfortunately, as you've noted, it stopped being maintained in early 2017 and so does not support Segwit.  I think in practice, a lot of people do 2, as you can then rely upon external nodes maintained by others.

I have a working prototype using #2, but will not link it here, as it is missing some things.  I only mention this to say that I did not find it tremendously difficult to do so (the work I did was scattered over a period of time where I was busy with other things also).  I think probably the real challenge is trying to construct the right tables for whatever you need; the actual work to persist the blockchain data into say, a Postgres db, is fairly straightforward.  It did take me a week or so to persist the data, but this was using a small EC2 instance.

It is rather surprising solutions aren't more widely available, but in the end, understandable.  I do think everyone needs to tweak their databases a certain way and it's just easier to process the data yourself in a way you understand.

Having said that, the Cross-Chain Group has a working implementation that connects to an Electrum server and persists it into sqlite.  Looking through the code, I don't believe it would be difficult to change the persistence code to persist to another db.  They've done the hard work of processing the block headers and transactions.


Why do prices of all cryptocurrencies move in sync?

The reason is that many altcoins are traded in BTC/ALTcoin pairs, not $$/ALT pairs.

So if an altcoin is trading 0.1 BTC/ALT, and the dollar price of bitcoin falls, then the $ price of the ALT will fall an equal amount.

Some altcoins trade against dollars as well, so their dollar price may be less coupled to the BTC dollar price. But for many of those alts, a large amount of the trading volume will still be from the BTC/ALT pair, and so the influence is still there.


So assuming node A sends a version message to node B then the two fields have the following meaning and value:

addr_recv: node A says "I believe you are reachable via this IP", hence its value is B's public IP address, the IP this message was originally sent to.
addr_from: node A says "I believe my external IP is this", hence this is what A believes its external IP to be (but may be different if A is behind a NAT and has not learned its true external address yet).


How can a cryptocurrency demotivate investment in favour of continued transactions?

You could try demurrage, where the value of one's holdings is intentionally reduced periodically. Freicoin is the only example I know of in the crypto space.


What are midstate and hash1 used for in mining?

1) Yes, it is correct.

2) It is deprecated. Generally, it is used to write the result of the mining over to be sent to the pool. This is to ensure the result is of correct length and adheres to some rules. In practice, it is always the same trailing string of numbers.


What is DrahtBot on Bitcoin Core pull requests?

The primary use of DrahtBot is to add automated comments to a PR that list other PRs that conflict with the PR you are viewing. It was written and is managed by Marco Falke but it is not currently open source (it is "ugly" code and wasn't written with the intention to make it open source). Marco stated on IRC:

DrahtBot is basically a while true; ./label_rebase.py ; done, where the Python script just imports a Github API library and then tags all pulls needing rebase

There could be additional features added to it in future. One idea Jeremy Rubin had on IRC is an additional label that shows when the PR was last updated so reviewers could assess whether merge conflicts with master had been addressed before reviewing. Another idea Jeremy had was counting commit tagged ACKs for the current Git tip as a heuristic for reviewers and maintainers.


Blockchain.info doesn't support API for Testnet network.

That API Pages for Mainnet network. What you can use blockcypher as an alternative, they're supporting Testnet for bitcoin.


Can "Digital Signature of the Block by the Miner" be used in place of "Nonce"?

This only raises the question of which miners' signatures are considered acceptable.  If anyone can be a miner and provide a signature, then there is no security and no way to objectively determine which of many conflicting blocks is authoritative.  If there is a fixed list of authorized public keys, then the currency is no longer decentralized.


Bitcoind under Windows 7; RPC port 8882 not opening

You need to be running bitcoind with the -server option set as well as -rpcuser and -rpcpass. These can alternatively be set as lines in your bitcoin.conf. The RPC port will only be open on 8332 if all three of these options are correctly set.


How can I generate a vanity Bitcoin address?

I guess you mean Vanitygen:
https://bitcointalk.org/index.php?topic=25804.0
From that page:

Vanitygen is a command-line vanity bitcoin address generator.
Vanitygen accepts as input a pattern, or list of patterns to search
for, and produces a list of addresses and private keys.  Vanitygen's
search is probabilistic, and the amount of time required to find a
given pattern depends on how complex the pattern is, the speed of your
computer, and whether you get lucky.


Transferering Bitcoins from Coinbase to Binance

Your question is a little unclear. Transferring funds between Coinbase and Gdax is free. You just have to sign up for an account with both.  See https://support.gdax.com/customer/en/portal/topics/939402/articles.  Gdax does have lower transaction fees than Coinbase.  You can easily transfer your BTC to Binance but there will be a mining fee associated with the transfer. Coinbase trades BTC, ETH, LTC, BCH. Binance offers many more altcoins to trade so unless you want to trade for these altcoins, I don’t see a big advantage for transferring your BTC to Binance.


calculate transaction ID TXID from JSON or raw transaction

Both the reference client (Bitcoin-QT) and a service like http://brainwallet.org/ show the transaction ID after signing but before the transaction is broadcast.

Take for example, this valid binary transaction:

01000000017a06ea98cd40ba2e3288262b28638cec5337c1456aaf5eedc8e9e5a20f062bdf000000008b48304502200addea57dd4c2871357165ed6d2bc94b117e322918073ac4c66d535637e74600022100dfaa0dce9e2e61aa2867c87fadca4e0fa3c70e9852a4689b3ef24b3f94809b4a014104e0ba531dc5d2ad13e2178196ade1a23989088cfbeddc7886528412087f4bff2ebc19ce739f25a63056b6026a269987fcf5383131440501b583bab70a7254b09effffffff01b02e052a010000001976a9142dbde30815faee5bf221d6688ebad7e12f7b2b1a88ac00000000

In JSON it decodes to:

{
    "txid" : "46b690f548f6eb70dca7fb2020ff4be369c42f3ea2375fd3f6b34890b640f8e9",
    "version" : 1,
    "locktime" : 0,
    "vin" : [
        { [... snipped ...]}
        }
    ]
}

With the transaction ID in the first key. If you were doing the signing yoruself, the TXID is literally a double SHA256 hash of the raw transaction. There's some more information about raw transactions on the wiki.


How convert a mnemonic phrase back and forth between different number of words?

Is it possible to convert back and forth between say, for instance, a 24-word phrase to a 12-word phrase, and what tools can I use to make the conversion?

No, that is not possible. The mnemonic words represent an entropy, for example the 24 word mnemonic phrase represents 256 bits of entropy while a 12 word mnemonic represents 128 bits of entropy. These mnemonic words are passed to a PBKDF2 function to generate a seed that will then be used to generate master keys for different tokens. It's also important to note that if you use a passphrase to your wallet, that passphrase will be used as a 'salt' in the PBKDF2 function and will generate a completely different seed, had you not used a passphrase.

  To my understanding, I could use the same mnemonic phrase in all wallets, even if some assets are not listed, if that's true I wouldn't have to store a different list of words for each wallet

Care has to be while doing that as many wallets use different paths of master key generation. If you use multiple wallets interchangeably, try to note the derivation path. For example, say hardware wallet A uses m/49'/0'/0' as the path, it will generate completely different addresses as compared to a wallet that will use a m/44'/0'/0' derivation.


No, all traffic is plaintext. The connections are hijackable and attacks against this have occurred in the past where ISPs redirected hashrate to themselves.


A more updated address clustering method?

Many wallet software obfuscate the information about payment and change address in order to protect the privacy of the user. When you see block explorer websites showing addresses in the outputs as change addresses, they are merely guessing as there is no sure shot way of knowing. Some of the techniques used to identify change addresses are below. I have also mentioned the current steps taken to prevent detection of such change addresses.

Sending change back to the same address: If you send the change back to the same address from which you are initiating the transaction, then there is high likelihood of that address being a change address. This is mitigated by preventing address re-use.
Change goes back to the same address type: If you initiated a transaction from a native segwit address (addresses starting with bc1) to a P2SH address (starting with 3). In some wallets, the change will be sent to the native segwit (bc1) address as that is the default for your wallet, thus leaking which output is the change. This is prevented by making the change address match the format of the payout address in order to mask privacy.
Coin selection: Assume you want to make a payment of 5 BTC for your coffee (let's hope that the coffee is that good :-)). Your wallet contains two UTXOs: 4 BTC and 3 BTC. To make a payment of 5 BTC, you will have to use both UTXOs and send 2 BTC change back to yourself. Now, the person looking at this transaction would think that if you wanted to make a 2 BTC payment you would have just used your 3 BTC output and sent 1 BTC as change as compared to using both the UTXOs. Thus it is revealed that the 2 BTC is in fact a change output rather than a payment output. Wallet softwares might create two or more change addresses in order to mask which is exactly the change address, or if multiple UTXOs exist, it will optimally select those UTXOs in order to prevent such leak.
Change address is the last output: If you build your transaction in such a way that your payment addresses comes first and change comes last, then it reveals which of the output is a change. For example, Bitcoin Core had a bug years ago, where it would never put change first despite randomization, which for single-payment transactions resulted in a deterministic position of change address (second). To prevent such deterministic ordering of change address in outputs, BIP 69 recommends lexicographical ordering of inputs and outputs. Outputs are arranged in ascending order of the amounts, followed by the scriptPubKey.


Is an SSD required to run a bitcoin full node and a lightning node?

A SSD is not required for running Bitcoin, but it certainly helps. You would definitely want one if you were running a production service using Bitcoin, but for something you're using personally it will just make synchronization substantially slower to use a hard drive. For a Raspberry Pi you absolutely do not want to be storing any data on the Micro SD card it uses as a boot disk, as this will result in corruption at some point.


I tried writing one in 2011-12.  I ended up doing a lot of volume, but I only broke even because of the commission.  I generated a lot of money for Mt. Gox though!

In general, writing an automated trading program is always going to be a difficult task, because anyone who can write a superior program can cut into the profits of the inferior program, which leads to a development arms race.  This is what some hedge funds do (not with Bitcoins), but any models they develop are only expected to make money for a short amount of time.

Even if someone released a high-quality open-source program, it would be difficult to make money by using it because so many people would run it.


Why was transaction malleability ever allowed?

Bitcoin transactions are intentionally malleable. Some forms of malleability are a feature, and by design. Many of the more advanced uses of Bitcoin transactions (see the Contracts wiki page) rely on the ability to modify transactions in specific - and limited - ways.

However, the current problems are unrelated, and because of unintentional malleabilities. Several are known (and have been known for years). Making them impossible requires changes to the protocol, to validation software and to wallets, so cannot be done very quickly. In fact, the reference client version 0.8 (released almost a year ago) made some types of malleability already non-standard, with the hope of someday being able to add a strict network rule to forbid it.

The reason why the transaction signatures do not sign the full transaction hash, is because that would require knowing the signature before signing. The signature is part of the transaction, so it influences the transaction hash. Because of the design of the scripting language, it however signs less than just not the signatures. This is the source of many (but not all) malleabilities. Some are due to ways in which the signature itself can be modified without invalidating it.


Yes, most exchange APIs fail at times. Add a sleep-and-retry to your code.


Yes, it looks like Proof-of-Stake or at least something very similar, and suffers from similar issues, for example:

  Note that this does not preclude a 2/3 majority of validators from publishing a blockchain fork after they had unbonded and sold their coins to an unsuspecting party. This is called a long-range double-spend attack. A user can
  avoid long-range attacks by syncing their blockchain periodically within the bounds of the unbonding period.


How exactly would compromising a private key cause you to lose your coins?

For P2PKH addresses (1.. addresses), the address is the hash of your public key and your public key is derived from your private key. When you spend, you must provide a cryptographic signature and the public key for your address. This cryptographic signature can only be created by using the private key. This is what makes it so that only you can spend your Bitcoin; you have the private key that makes a valid signature so you can make the spending transaction. If you lose that private key, you cannot make the signature and thus cannot make the spending transaction. However anyone who obtains your private key (i.e. steals your private key) can also make that signature and spend your coins, which is why you must keep it safe.


Who added the 21 million limit to Bitcoin?

This is the announcement of Bitcoin:

http://www.metzdowd.com/pipermail/cryptography/2009-January/014994.html

  Total circulation will be 21,000,000 coins.  It'll be distributed to
  network nodes when they make blocks, with the amount cut in half every
  4 years.

  first 4 years: 10,500,000 coins
  next 4 years: 5,250,000 coins
  next 4 years: 2,625,000 coins
  next 4 years: 1,312,500 coins etc...

It was part of it from the beginning, and it definitely wasn't secret.


Relationship of R/S signature in between signed message and DER signature

Bitcoin transactions use DER format for the signature (plus sighash byte), but bitcoin messages use 'plain' format (aka P1363, CVC, PKCS11, Microsoft, JWS and more) (plus recovery byte). The computation of the r,s values in an  ECDSA (which as Oscar correctly commented are not a point) is the same either way, but the data being signed for a message can never be the same as for a transaction so the signatures can never actually be the same value.

Your signature should not be and is not in DER format. The code you link to appears correct:

    $signature = base64_decode($encodedSignature);

    $flag = hexdec(bin2hex(substr($signature, 0, 1)));

    $R = bin2hex(substr($signature, 1, 32));
    $S = bin2hex(substr($signature, 33));

That correctly parses a plain-format signature (not DER), from base64.

    $derPubKey = Signature::getPubKeyWithRS($flag, $R, $S, $hash);

Without tracking down the code this calls, that looks like it should recover and encode the pubkey; whether it also verifies the signature is not obvious.


It is just a formatting issue.  Include "0x" at the beginning.


Colluding miners attack: Is the Bitcoin protocol compromised?

The report is not heavily disputed.

In the hours following the paper's release, several developers are discussing solutions:

http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03128.html

and

http://bitcointalk.org/index.php?topic=324413.0

There has not been any evidence that such an attack is imminent or likely even.  And remember, even an attacker with 51% cannot do much.  One risk is that a transaction could be canceled after it has confirmations, if the selfish pool is that much further ahead.


What makes Bitcoin transaction secure against attackers/hackers?

Bitcoin transaction works on low-level primitive constructs of scripting languages and cryptography. In simple terms, you lock your funds to an equation and anyone who can provide a solution to that equation can spend the money. So there are no account level data, just unspent transaction outputs (UTXOs). Every time you need to spend your bitcoins, you just include these UTXOs as inputs to your transaction, provide a solution to the locking equation and send your funds to another locking equation (which can then be spent by providing solution to that equation). Most of this unlocking equations involve asymmetric cryptography of providing signature from your private key.

The most important aspect of Bitcoin transactions is that every information related to a transaction is entirely public. From the moment, you sign your transaction with your private key and broadcast it, the entire data of that transaction becomes a part of the public record (be it in the mempool before confirmation or in the blocks after confirmation). Since the signing process of Bitcoin transactions involve signing the entire transaction data as the message, any person in between cannot change an iota of information as it will render the transaction as invalid (let's leave signature malleability alone for now). This makes transactions secure against attackers who might want to modify the data.

The only thing that needs to be kept secure are your private keys. As the old adage goes, "Not your keys not your funds". Thus, care has to be taken to ensure that you keep your keys safe. Most of the attacks that you read about involving lost bitcoins is because of careless management of keys. You can use cold storage like hardware wallets, wherein your private keys will never enter a network connected device and as such will remain immune to network attacks.

The private key associated with signing the transaction is a random number in the 2256 bit key space. From the private key, you generate a public key using elliptic curve multiplication. This process is one-way - that is you cannot get private key if you know the public key - unless you solve the discrete log math problem or you brute force (try every combination of private key to get the resulting public key). No one has found a solution to the first case, and the second case is impossible due to the energy requirements. Moreover, the public key is hashed using RIPEMD160 and SHA256 hashing functions to generate a bitcoin address to which you send the bitcoins. These hashing functions are also one way. Now, the solution to the equation (in many cases) I was talking to is to provide the public key that hashes to the address and a private key whose signature would be verified using that public key. So if you do not re-use your address, you have a 2-layer security from private key to the address.


According to their support site it should be on it's way without you doing a thing. I quote:

  If you choose to take settlement in bitcoin, BitPay will forward bitcoin payments to your bitcoin address on file. The minimum settlement is 0.01 BTC.

Maybe look on blockchain if there is an unconfirmed transaction to your address or reset Multibit if you are using that. Or you haven't hit the minimum settlement of 0.01 BTC.


It seems you're mixing up bitcoind and bitcoin-cli.

bitcoind is the Bitcoin Core daemon. It must be running first before you can do anything. bitcoin-cli is a tool to send RPC commands to a running bitcoind instance.

From the linked documentation page:

  bitcoind -regtest -daemon

No need to put a & after the command if you run with -daemon.

Once bitcoind is running, you can for example send the getinfo command using bitcoin-cli:

  bitcoin-cli -regtest getinfo

Or send generate 101 to generate 101 blocks:

  bitcoin-cli -regtest generate 101

To learn about other commands you can send:

  bitcoin-cli -regtest help

That way you could for example learn about the ping command. To learn more about that, you can send:

  bitcoin-cli -regtest help ping

You need to specify -regtest for every command, as you can have a daemon running for each network (one for mainnet, one for testnet, one for regtest), or more if you configure each to run in separate directories and network ports.

Note that bitcoin-cli is just a program that speaks JSON-RPC (which is a standardized protocol), albeit somewhat specialized for use with bitcoind. You can connect to bitcoind using any JSON-RPC client (for which libraries exist in all popular languages). To do so, you'll need to configure a username/password for connecting to bitcoind.

To explain what you are seeing:

./src/bitcoin-cli -regtest & won't work as bitcoind is not yet running, and you aren't specifying a command to send.
./src/bitcoin-cli -regtest -daemon likewise.
./src/bitcoin-cli -regtest 101 & looks almost right, except you missed the generate, so you're trying to send the non-existing command 101 to a daemon that is not yet running.


Is it possible to have a modified Proof of Work that does not require as much energy to secure the blockchain?

No, because by design PoW is assigning relevance proportional to power usage.

If the market pays N USD per day worth of BTC to miners (in subsidy + fees combined), then the mining ecosystem will converge towards spending N USD minus profit margins. Not all of those costs go to electricity (as there are also employment and hardware costs from failure and depreciation), but a significant fraction of the costs do go to power.

It is absolutely irrelevant what the actual PoW function is, from this perspective.


In Multibit HD, is there a way to see all of my receiving addresses?

I guess this question, unanswered for nearly 3 years, is obsolete
According to https://multibit.org/blog/2017/07/26/multibit-shutdown.html (retrieved 2018-08-17)

Multibit is No Longer Supported
July 26th 2017
Dear Bitcoin Community,
It is time for us to let Multibit go.
KeepKey acquired Multibit a little over 1 year ago. At the time, the engineers who originally built and supported Multibit had announced that they would no longer be working on it or providing support. Multibit played an important role in the Bitcoin infrastructure. We felt that it was important for Multibit to continue and hoped that with our existing support and development teams, we would be able to keep Multibit alive.
The reality is that Multibit is in need of a lot of work. It has stubborn bugs that have caused us and Multibit users much grief. Additionally, Bitcoin has gone through a fundamental change in regards to the way fees work. The addition of SegWit in the coming weeks will mean the Multibit software has fallen still further behind.
Unfortunately, KeepKey simply does not have the resources to support the current issues, nor to rebuild Multibit to ensure ideal user experience. By focusing our attention on the KeepKey device, we will continue building and improving the best hardware wallet available.
Thus, KeepKey will discontinue support and maintenance of Multibit, effective immediately.
We recommend that all Multibit users discontinue using it and you move your keys to other wallet software of your choosing.


Can someone explain to me all of the scaling proposals?

Segregated Witness (segwit) is a solution which redefines how the maximum block size is calculated (now called block weight) and creates new output types. These segwit output types are given a discount (compared to non-segwit output types) with the new maximum size calculation when they are spent. This means that a block will be able to have more transactions that spend from segwit outputs and thus increase the number of transactions that fit in a block. Segwit is currently not locked in nor active.

BIP 141 is the main specification for segwit. It defines the deployment parameters and the consensus rules. BIPs 143 and 144 specify the network and serialization parts of segwit. When people refer to BIP 141, they are referring to segwit's deployment parameters. These parameters specify that 1915 of a 2016 block window must signal for segwit by setting bit 1 of the block version field.

UASF and BIP 91 are methods by which segwit can be activated. When these activate, they require that all blocks must signal for segwit by setting bit 1 of the block version field. This rule remains in place until segwit becomes locked in. Any block which does not have this bit set will be considered invalid.

BIP 91 is currently active, so all blocks must now signal for segwit. It become locked in after 269 blocks of a 336 block window signaled for BIP 91 by setting bit 4 of the block version number. BIP 91 activated after another 336 block window passed.

UASF (BIP 148) activates when the median time (the median timestamp of the last 11 blocks) is after midnight on August 1st UTC. BIP 148 is currently not active. It does not have a lock in period.

Segwit2x is a proposal to activate segwit and then hard fork later to increase the maximum block weight. It contains BIP 91 and specifies that a hard fork will occur 12960 blocks after segwit activates.

Emergent Consensus (EC, aka Bitcoin Unlimited) is a proposal where the maximum block size is determined by miners. Miners choose a block size to mine at based on what they perceive the community is willing to accept. Users and miners set the maximum block size which they are willing to accept. Users and miners also set another parameter, Acceptance Depth, for the number of blocks that must be mined on top of a too large block before they accept that larger block. For example, I can choose to set my maximum to be 1 MB and set my Acceptance Depth to 6. This means that if I receive a 1.1 MB block, I will first reject it, then only accept it if 6 blocks have been mined on top of that block and the chain with the 6 blocks is longer than the chain that I am currently on.

EC does not have any activation parameters or a lock in period. It becomes active whenever a miner chooses to mine a block that is larger than 1 MB.

When people talk about "Core", they usually refer to the current status quo. However Core really also includes Segwit.


How to utilise more cores when I am cpu mining?

I don't really know about Litecoin-Qt but for a better result and to configure correctly the numer of threads I recommend you to use a software dedicated to LTC mining.

You can use https://github.com/pooler/cpuminer for only CPU and https://bitcointalk.org/index.php?topic=150331.0 for GPU.

You must have a pool but you can solo mine with the arg '-server' when launchin litecoin-qt.

I know it's more difficult than just use the LiteCoin-Qt miner but it is also more configurable and more efficient.


blockchain.info api for tor hidden services

Currently I do not think it is possible, atleast not without remaining "hidden".  What you could do is configure your bitcoind server to use a proxy: https://en.bitcoin.it/wiki/Tor

Other alternatives you may want to look into is BitPay as they are currently working on a tor implementation: https://github.com/bitpay/bitcore/pull/210

Also BitWasp will be releasing their marketplace soon which you will be able to configure to run on the Tor network as well.


How many non-web wallets discard private-keys? or How common are non-deterministic wallets?

None. No wallet that exists discards private keys. That would be superbly idiotic to do because that means that money could be thrown away permanently. No wallet would intentionally do that.


Yes, you can send bitcoins to any wallet at anytime you want.

The transaction will be shown in the wallet after it synced.


Ripple XRP value and market capitalization

It comes down to XRP's actual or perceived utility, then speculating on XRP's future; most seem to be bullish so there's price appreciation. Since XRP will act as a connecting joint between ALL currency pairs within the Ripple network, XRP will maintain its usefulness and in fact probably become more useful as time goes on and new bridges are made across previously isolated markets. XRP will help to lubricate the engine of the Ripple protocol. As long as the protocol is being used more each day and is "healthy", which it currently is, the price of XRP "should" increase along with it – just as a motor needs lubricating oil to maintain it.

There's also a chance it might become a sort of "reserve" currency in the future, assuming success of the Ripple protocol.


Miners no longer run full nodes. They connect to a mining pool that gives them work to do. The pool runs a full node.

If you mine solo you'll need to run a full node but solo mining doesn't make any sense anymore because of variance. You can get a more regular income flow if you join a mining pool.


Duplicate r value for an address: only an issue for a multi-input Tx?

Any reused nonce is a problem, it's not restricted to a single transaction.

No competent software will ever reuse nonces accidentally, so using a scanning script like that is just ruining your privacy for no real benefit. Bitcoin Core, Electrum and Armory all use RFC 6979 deterministic nonces so there is no room for RNG failure in these cases, though any software faulty enough to fall at that hurdle will have used the same RNG to make the private keys as well.


Bitcoin is not a money machine.

It is a currency created on computers through "minning" using computational power.

Due to its deflationary feature i.e the having and the hard cap of 21 million coins.  The value will theoretically go up due to basic laws of supply & demand.

So if you want to make money from bitcoin.

The most straight forward options are;

a) Buy and hold BTC, then sell incase of a profit(if the price appreciates).

b) Invest in minning infrastructure and sell minned bitcoins on exchanges  to cover maintenance costs + profit


Is there a limit for bitcoin withdrawal at Mt.Gox?

"They include bitcoin in the list below this statement too. Does that mean they will allow me to withdraw only number of bitcoins that currently has a value of 1000 USD?"

No, it means exactly what it says, that you can only withdraw $1000 a day.

That being said there is an entirely separate limit that they place on bitcoins. On my account under funding options and withdrawals it reads

  BTC : You can still withdraw up to 100.00000000 BTC provided you have enough on your account (your limit is 100.00000000 BTC per 24 hours )


The reference here for running the bitcoin daemon does not really clarify what maxconnections mean.
Furthermore, that maxconnections only controls the number of inbound connections and not outbound. Is this true?

maxconnections counts both inbound and outbound connections. If you have 8 outbound connections, you can only have 117 inbound connections.

Is 8 the maximum number of incoming peer connections?

No, 8 is the maximum number of outgoing connections.

I believe, effectively, blocking port 8333 will only stop peers from connecting to me (stops inbound) and not me connecting to peers (does not stop outbound). Is this right?

Yes, that's correct. Also, there's a setting to do this without firewall software - set listen=0

What implications do blocking port 8333 have on my bitcoin daemon from getting transactions? Does it get less transactions or get transactions slower?

That could happen in theory, but in my experience it still works pretty well.


Multi-destination transaction from paper wallet

You can do this with Bitcoin Core for example. You can find more details in this
answer. You need to import your private key in to Bitcoin Core first.


Is it safe to create a Bitcoin account for another party? Is this a scam?

This is unsafe and definitely a scam.

One common way it's done is as follows.  Using your login and password, the guy will secretly retrieve the recovery phrase for the wallet.  He will then let you change the password.  Then, he will make up some story to convince you to acquire some Bitcoins and put them in the wallet (or maybe he'll just wait until you decide to do so of your own accord).  You will think this is safe because he doesn't know the new password.  However, using the recovery phrase, he will be able to take all the coins from the wallet, even without the password.

If he really just wanted access to a Blockchain wallet, there would be nothing to stop him from just making one for himself.


How to build a bitcoin delegation server?

Let's break it down a little.

Things you need a node for:

Receiving new transactions and blocks
Indexing transactions
Building transactions
Broadcasting transactions

Things you don't need a node for:

Generating keys
Signing transactions

You could, in theory, just build a program that generates your keys and multisig redeem scripts, and converts them to addresses for your users. Then, you can use insight or blockchain.info or any one of several explorers to look up transactions for the addresses you generate, and build outgoing transactions.

Once you have the outgoing transaction, your program can sign it with the keys you previously generated, and then broadcast it via an explorer API.

Alternatively, you could run your own bitcoind node, and index incoming transactions yourself.

A wallet and a node are two separate concepts. Bitcoind can act as both, but it's core function is that of a node. Many people run bitcoind with absolutely no keys on it, and use light clients like Electrum or hardware wallets to store their actual BTC.


How do cloud hashing companies profit? (leasing hashing power)

When you're calculating the profit from Bitcoin mining, you take into account the current bitcoin price, how much hashpower you have, and the current difficulty.

Difficulty rises over time. (Generally speaking.) Between Jan '12 and Jan '13, difficulty rose by a factor of 2.9x.

Between Jan '13 and Jan '14, difficulty rose by 407.2x.

Between Jan '14 and now, difficulty has risen by 33.3x.

Unless they're guaranteeing 2.2 euros per day over the course of the contract, in which case they're either morons or liars. (If you really could guarantee that kind of return, investors would be all over you.)

Of course, as David Schwartz notes, it could also be a scam. They could give you good returns, then vanish after lots of people invest.


How can a 24 word seed know when I added or removed wallets at a later point?

I don't know about Ledger specifically, but for HD wallets in general, private and public keys are not generated randomly.  Rather, they are generated by a deterministic algorithm from the seed (in this case, the 24 words).  So they are absolutely "tied" to the seed.

When you add a wallet for another coin, keys for that wallet would presumably be generated from the same seed (using different parameters so that you don't end up with the same keys in all your wallets).    The seed itself stays the same and doesn't have to change to reflect the creation of the new wallet.

Should you ever need to restore, I assume you would need to tell the device which coins you had wallets for.  It will then regenerate all the keys for those wallets from the master seed, using the same algorithm as it used originally, and you'll have all the same keys you had before.  (If you try to restore some wallets that you weren't using or had removed, all that will happen is you'll find no coins in that wallet.)

Your public and private keys are not stored anywhere except within the device itself.


Why does the blockchain keep transaction history rather than balance?

Keeping the entire transaction history allows us to independently verify that everyone's balances (note that Bitcoin does not actually use accounts or balances) are correct. Without having the full transaction history, we cannot verify whether someone actually had the money; the only way to do so is to follow the trail of transactions all the way back to the creation of a coin and check that all of those transactions are valid.


How does blockchain.info resolve adresses?

There's no central directory for this information.  You could scrape the Blockchain list if you wished, but if you do so you're relying on the accuracy of their information.


Can someone ELI5 to me for Bitcoin Atomic Swaps?

I think this is easier to understand if you abstract a little bit. On a high level, an atomic swap is very simple: the two parties set up transactions such that they can both take their coins be revealing the preimage to some (pre-decided) hash H. Initially one party knows the preimage. They must reveal it to take their coins, so the act of taking their coins is sufficient to enable the other party to take their coins.

More specifically the Tier Nolan in the OP works as follows.

A chooses a random x and gives H(x) to B.
A sends her coins to a 2-of-2 output that can be taken by B if he reveals x. Similarly B sends his coins to a 2-of-2 output that can be taken by A if she reveals x. These are TX1 and TX3, respectively.
(Before broadcasting these, they create locktimed "refund" transactions TX2 and TX4. It's important that A's locktime is much longer than B's, so that if she gets her refund, B has had a long time to take his refund, and is not at risk of A revealing x to also take his coins.)
At this point, A takes her coins, revealing x.
Seeing this, B learns x and takes his coins.

There is a variant of this called coinswap where x does not hit the blockchain, where steps (4) and (5) are replaced by A revealing x off-chain and then the signers just give each other the coins, only using x as a fallback. This complicates the locktime structure and also requires differently-shaped transactions to keep x and its hash off the blockchain, which unfortunately make the protocol look super scary, but that's all that's going on.


What complexity class is Bitcoin's proof-of-work (hashcash) in?

There's a reason cryptographic hash functions, like the double SHA256 used for proof-of-work in Bitcoin, are not usually described using these complexity classes that classify asymptotic behavior. In fact, there are several.

A technical reason is that hash functions often do not scale. For example, it is not defined how one would extend the proof-of-work to operate on 512 bits. A natural choice would be to use SHA512 then, but going from SHA256 to SHA512 takes alot of essentially arbitrary choices, like changing the number of rounds from 64 to 80, which are standardized but not in a naturally scaling way and not for arbitrarily large hash sizes.
It is not relevant for the cryptographer. Even a NP-complete hash function, which would be the strongest amongst the complexity cases you listed for building a strong hash, does not guarantee all what we want from either a cryptographic hash or a proof-of-work function. To qualify for NP-completeness is merely a strong heuristic that the problem cannot be solved by an algorithm that is, asymptotically, less than exponential. But for a good hash function we want it to be, at the very limited bitcount we choose to use it at, maximally exponential in the sense that solving it is really as hard as trying every possibility in a hash function. For its corresponding proof-of-work function with such a difficulty that only a fraction x of the output range is acceptable, this would mean that we should expect to require a number of attempts of x/2 times the size of full output range to find a proof-of-work. Anything better than that would prompt an academic to call the associated hash function broken, even if it merely reduces the number of tries in half, which would still put it in an exponential complexity class and would easily be possible even with a NP-complete function.

An impressive (but only superficially related) example of how picking something seemingly NP-complete is insufficient to get something cryptographically hard is knapsack cryptography. Of course, there the problem was that by picking special cases the complexity of the problem was reduced. The point is that even a NP-complete problem can be less difficult than indeed having to try every solution, despite it sometimes being described that way! For cryptography-grade quality, having to try every input is meant literally; for the complexity analysis, it is good enough if the asymptotic scaling remains exponential in the number of bits. So if you could reduce the problem to another NP-complete function taking only every 1000th bit as input, that would be good enough for classifying the problem as NP (and even NP-complete if a similar mapping worked in reverse), but not for being of interest for cryptographic applications.
It's difficult! And I think this difficulty has already let you astray: Even your arguments for placing this problem in TFNP are, whilst really close to the truth, not true in the mathematical sense. For example, if I specify x=0, no y can produce hash(y) < x, contradicting your assertion. If all other x are fine or if there is a required minimum value for x probably depends on how you define the "strings" y you want hashcash to operate on. For Bitcoin with a limited number of bits entering the double-SHA256, I wouldn't be surprised if x=1 also does not have a solution, i.e. if no block hash can become exactly zero. Of course we'll probably never know. In practice, it is desirable that a hash function should produce total proof-of-work functions in the way you describe, but I don't think it is a proven quality. Disclaimer: I honestly don't know. You really should ask a cryptographer.

What remains to be done to answer your question, after finding how the hash function scales and verifying that it remains polynomial for arbitrary large sizes, is just this proof that the corresponding proof-of-work function is total. If this proof can be done using the pigeon hole principle, you have shown that it is in PPP, etc.

So where is the difficulty? For example, if y has at least as many bits as x, and if we change your hashcash to have a less-than-or-equal rather just less-than, and if we are willing to multilate it further to the point that either finding a proof-of-work or the existence of a hash collision is good enough to make "hashcash" true, then the pigeon-hole principle as explained in the wikipedia article you linked to would obviously apply.

But anything less than that, as best as I can see, would not suffice to apply the pigeon-hole principle and hence would not answer the question if hashcash is in PPP or not. To again refer to your linked wikipedia article: Only for very few problems the answer is know, even for PPP. For the special cases of PPP, PPA and PPAD, it obviously gets even harder. If you find a solution, post it to an academic journal, not just here!


Why should a miner choose the longest blockchain if another chain has a higher expected reward?

I think it's conceivable that this could happen. But under realistic cases, I don't think it actually will. If you don't mine on the longest block, the probability that your block will ever be part of the longest block drops drastically. Unless a block you mine becomes part of the longest chain and stays that way, you never get any fees or reward at all.


Coinbase Pro historical data not working

The reason it was pulling data when I dropped the "start" or "end" part of the code was because the API then ignored that parameter and returned the default result.

the solution was to import the 'datetime' package and format the 'start_time" and "end_time" objects using datetime. for example:

start_time = datetime.datetime(year,month,day)


How accept trade works on creating order

This "rails application" you would like to create, could be called an "exchange platform". A challenge hereby is to create a secure platform, as you will be taking responsibility for and handling other people's money.

One main difference between exchange platforms is how services facilitate the trade: I am aware of three different modi operandi:

Service only sells crypto. (e.g. Coinbase.com)

The service offers crypto currency at a given price.
The user accepts the current offer for a specific amount and provides an address where he wants to receive the crypto currency.
The user sends a fiat deposit to the service.
The service waits for the user's payment to clear, then sends the crypto to the user's address.

Service holds crypto in escrow. (e.g. Bitcoin.de)

User Alice sends a crypto currency deposit to the service.
Alice creates an offer on the service's platform to sell a specific amount of crypto at a certain price.
User Bob accepts Alice's offer.
Bob sends a fiat payment to Alice.
Once Alice receives the payment from Bob, she confirms the payment to the service.
The service sends Alice's crypto currency deposit to Bob, after taking their fees from it.
If something goes wrong, the service mediates the dispute.

Service holds deposits of all currencies. (e.g. Bitstamp.net)

User Alice sends a crypto currency deposit to the service.
Alice can now create a

sell offer at a specific price (limit order)
Which will remain in the order book until somebody is willing to pay the price she set.
sell immediately at the current price (market order)
Which will match the best buy offers until her order is matched completely.

Vice versa user Bob sends a fiat deposit to the service.
User Bob can now create a

buy offer at a specific price (limit order)
Which will remain in the order book until somebody is willing to sell for the price he set.
buy immediately at the current price (market order)
Which will match the best sell offers until his order is matched completely.

At any point, Alice and Bob can withdraw their deposits from the service.
You can find a more detailed example at How do buy and sell orders work?

Any of the above should also work for exchanging crypto for crypto.

In order to make the complete platform work, you will need:

User interface, i.e. a website
User management including fulfillment of local KYC, AML laws
Orderbook
Matching engine
Wallets for any tradable crypto currencies
Cold storage for any tradable crypto currencies
Payment processing for fiat currencies, maybe a banking partner
Customer Service
Legal advice

You might also find What would it take to create my own Bitcoin exchange? helpful, which goes more in-depth on the same topic.

Concerning your question for open source Bitcoin exchange software, this question has been answered here: Is there an open source Bitcoin exchange?


Is it safe to use HD Key Derivation with bip-schnorr?

Yes, it is designed to be.

  The bip mentions that you should not throw away the first byte of a generated key.

Perhaps this is worded confusingly.

It means that you can't use a variant of the signature scheme, which uses full public keys, but then throws away one byte of the public key at verification time. Doing so would just result in 50% of the signatures being rejected (because the public key wouldn't match what was used at signing time).

  It sounds like its safe for the prover to drop the extra byte but not the verifier.

This has nothing to do with safety, but about correctness.


It is an error to do with getting hold of a 'new version available' file from multibit.org. It means you won't get notification of new MultiBit versions but can otherwise be ignored.

Some versions of Java have problems with the HTTPS certificate on multibit.org.

I am going to change how the version.txt file is authenticated which will make this error disappear.


0.00603581 is in my bit coin wallet how much do I own?

You own every bit of it. Assuming you have the private key for the wallet. As far as the blockchain network is concerned, anyone with the private key is the "owner" and will transfer those funds if the correct private key is provided in the transaction request.

As long as your private key remains private and you know what it is, you own it.

Now, to send that Bitcoin somewhere else, you'll have to pay a fee. That's why miners mine the blocks. So while you (assuming above conditions are satisfied) "own" every Satoshi inside that wallet, you'll need to pay to move it somewhere else.

Note: Nuances, subjective considerations and opinions have all been crushed for the sake of brevity.