When making an altcoin copy of Bitcoin, where should one start?

You should study the current alt-coins world:

en.bitcoin.it: List of alternative cryptocurrencies
bitcointalk.org: List of all cryptocoins

The most interesting alt-coins today on my sight are:

Quarkcoin (QRK) blake, bmw, groestl, jh, keccak, skein
Primecoin (XPM) First non-hashcash proof-of-work in cryptocurrency, pure prime number based proof-of-work
Litecoin (LTC) scrypt

The fastest way to understand what must be changed is take a source bitcoin-0.6.3-linux.tar.gz and source of litecoin 60300.

Thereafter, extract both archives into two directories and simply diff -rHvn bitcoin litecoin.

Change the names of configuration files, number of ports, etc... And change the hash function, if you wish.

You surely will meet two common troubles:

Kill network by difficulty. Someone may come to your network with >50% of power, increase the difficulty and then disappear. After that, your network participants would found next block with BIG delay, which will break the stability of transactions, etc...
ASIC miner. Today, any gamer with a TOP video card can't mine, in the top pool, not even ONE Bitcoin for years, because of ASIC miners. What to say about a finding of block, solo-mining.

First can be solved, I think, by reinventing dependence on the difficulty by adding a dependency on Time. For example:

  Next block must be with 10 zeroes in the start, but after one minute the
  number of zeroes would be decreased by one, at the second minute decrease
  this doorstep again, etc...

Second, the ASIC miner, may be conquered by the really hard hash algorithm. Look at the QRK: probably nobody will draw such circuit while the game isn't worth the candles. But here you'll meet next attack: someone may analyze the cascade of hashes and find a much easiest way to getting blocks.

You can observe the world of alt-coins and you will realize that nobody needs your new coin. There are about 30 very active alt-coins and about 100 in incipience. I predict: "In the next year this numbers would be multiplied by 10!": 300 active alt-coins with various difference from bitcoin and 1000 full clones, differing only by labels.

You could blow up the market with super innovation.

One of the most interesting and costly thing is traceability of money, on my sight. E.g. Look at zerocoin.

The second is a dying of mining. The market of bitcoin might plop in.

Edit: Also, there is rippled/xrp, sometimes ago it has become opensource.

https://github.com/ripple/rippled/
https://ripple.com/wiki/Introduction_to_Ripple_for_Bitcoiners

Also, look at granpa of ripple:

https://classic.ripplepay.com/login/

One day, surely, there will appear a child of bitcoin and ripple. Kind of crypto-money-mutant.

I leave here a little space for the future to add more interesting questions and answers.


I think the issue is electron cash which uses a different seed format to other wallets. First, to be safe, move your BTC from it's current wallet to a new wallet,

Then put that seed you tried to put in to Electron Cash in to a different wallet like 'Bitcoin.com wallet


You can use RPC bitcoin framework for creating the request to the node to get information.

With python exist more library, I preferer this python-bitcoinrpc but a list the library is here

For configuring the node to accepting the request look this reference

other util references

Complete bitcoin.conf file
Gui generator bitcoin.conf
Api reference with other language
Official documantation command rpc


The design of the blockchain is such that such a scenario is not possible. By definition, the genesis block does not have an ancestor block. While it has a field for the previous block hash, this field is set to all 0's to indicate it is null and has no value set. This means that there are no blocks that come before the genesis block.
Additionally the genesis block is special in that it is both treated specially and hard coded into software. Nodes do not download the genesis block - they have the block in its entirety written into the software itself. This gives the genesis block special treatment, with one such special treatment being that the view of the blockchain is instantiated with the genesis block as the very first block.

While it is most certainly possible (and probable) that blocks were created before the genesis block, these blocks would have been ones that Satoshi created during testing and belong to a different blockchain. Those would not be valid on the Bitcoin blockchain because they refer to their own genesis block, or are their own genesis block. The actual time they were created does not matter, only whether they refer to blocks which eventually refer to Bitcoin's genesis block.


Getting statistics on bitcoin >transactions< - breakdown by size

Yeah what your saying makes a lot of sense. Blockchain info graphs offers allot of charts to show the data that you are referring to. Do you want something in more detail, if so there are probably some api's around that you can use to your hearts desire.


Is there an easy way to consolidate Dust Microtransactions

Let's take a step back and define dust: dust is an transaction output with a very low value.  When creating an input to a new transaction that spends that output, you have to use 36 bytes to reference it (the outpoint), about 72 bytes for the signature, either 65 or 33 bytes for the public key (depending on whether it was compressed, plus about 10 more bytes for other things.  Let's round it to 150 bytes.

Transaction fees are usually computed per kilobyte, so if you pay 0.0001 BTC per kB, dust is not worth spending if its worth less than 0.0000015 BTC.  Hopefully, defining all this will make the following answers a bit more clear.

Bitcoin Core's "raw" RPCs let you choose what outputs to spend.  You'll typically run listtransactions to get outputs available to your wallet, createrawtransaction to create a transaction spending specific outputs, signrawtransaction to sign the transaction, and sendrawtransaction to broadcast the transaction to the network.  If you do this, you want to be very careful---once a transaction has been broadcast, it's very difficult to change any mistakes in it.
As you alluded to in your question, Peter Todd's dust-b-gone will purge a Bitcoin Core wallet of dust transactions by giving them to someone else (Todd, I think, but it could go to 100% transaction fees---either way, nobody is getting rich off dust).  I haven't used it, but the instructions look simple.
Yes, if you transfer everything in the wallet, the dust will be gone.  That's because dust is an output from a previous transaction---once you use that output as an input in a new transaction, all that matters is the value of the output in that new transaction.

Although I've never used Bitcoin Core with dust, it's likely to be the smartest Bitcoin wallet about keeping dust-related transaction fees low---so if you want an easy graphical solution, I suggest just using Bitcoin-Qt.


CHECKMULTISIGVERIFY with public key hashes?

I think I've figured out how to do it. (Not neatly, though.)

Here's a 3-of-5 pay to multi-pubkeyhash:

scriptSig: <key1> <key2> <key3> <sig1> <sig2> <sig3> <pos1> <pos2> <pos3>
scriptPubKey: <hash1> <hash2> <hash3> <hash4> <hash5>

// key1

// get the key <key1> and hash it
+2 13 OP_PICK OP_DUP OP_HASH160
// copy pos1
+1 9 OP_PICK
// check 2 < pos1 < 7
+0 OP_DUP 2 7 OP_WITHIN OP_VERIFY
// copy to alt stack
+0 OP_DUP OP_TOALTSTACK
// get hash at pos1
-2 OP_PICK OP_EQUALVERIFY
// check signature
-1 11 OP_PICK OP_SWAP OP_CHECKSIGVERIFY

// key2

// get the key <key2> and hash it
+2 12 OP_PICK OP_DUP OP_HASH160
// copy pos2
+1 8 OP_PICK
// check 2 < pos2 < 7
+0 OP_DUP 2 7 OP_WITHIN OP_VERIFY
// check pos2 < pos1
+0 OP_DUP OP_FROMALTSTACK OP_LESSTHAN OP_VERIFY
// copy to alt stack
+0 OP_DUP OP_TOALTSTACK
// get hash at pos2
-2 OP_PICK OP_EQUALVERIFY
// check signature
-1 10 OP_PICK OP_SWAP OP_CHECKSIGVERIFY

// key3

// get the key <key3> and hash it
+2 11 OP_PICK OP_DUP OP_HASH160
// copy pos3
+1 7 OP_PICK
// check 2 < pos2 < 7
+0 OP_DUP 2 7 OP_WITHIN OP_VERIFY
// check pos3 < pos2
+0 OP_DUP OP_FROMALTSTACK OP_LESSTHAN OP_VERIFY
// get hash at pos3
-2 OP_PICK OP_EQUALVERIFY
// check signature
+0 9 OP_PICK OP_SWAP OP_CHECKSIG

(The number at the start of each line is how many stack elements that line adds or removes.)

The idea is that the spender provides the keys, the signatures, and the index of the hash that they're signing for. (keyN, sigN, and posN.) To prevent someone from providing the same index three times, we check that pos1 > pos2 > pos3. It's much longer than an equivalent multisig script, but on the plus side we do fewer signature verifications. (Normal 3-of-5 multisig will do up to 5 signature operations, but we only do 3.)

(Standard disclaimer about using untested scripts applies. If I made an off-by-one error above, all your money's gone.)


How can bitcoins be used for daily currency if their value changes erratically?

If Bitcoin becomes the predominant worldwide money system, the volatility due to speculative FX would greatly diminish. The problem is that it is not, and will not likely be the reserve currency any time soon (if ever).

I can not think of any counter-measure within the current design of Bitcoin, except to exchange into dollars (or gold since we are in a gold bull cycle) for storing and only use Bitcoin for a short-term holding for transactions. However, many Bitcoiners ostensibly prefer to speculate on its appreciation and hold it.

Every small cap currency has this problem, because of economy-of-scale network effects they will always be measured against the reserve currency.

This is why there was a U.S.A. Treasury official who was rumored to have quipped in reaction to some smaller country's protest, “it’s our currency, but your problem”.

So the small cap currency has no choice but to try to make itself stable relative to the reserve currency, unless it just wants to be a small cap “investment” speculation. It may be impossible to maintain stability in all scenarios. For example, the Asian Crisis of late 1990s was caused by speculative capital flows, that stampeded to Europe to invest in speculative opportunities opened up by the creation of the Euro at the turn of this century.

This is precisely why I propose an alternative design for Bitcoin.


How can I get the block number of given transaction?

According to the Wiki, the gettransaction <txid> call return a JSON object with the following information

"amount" : total amount of the transaction
"confirmations" : number of confirmations of the transaction
"txid" : the transaction ID
"time" : time associated with the transaction[1].
"details" - An array of objects containing:
"account"
"address"
"category"
"amount"
"fee"

Now just use getblockcount and subtract "confirmations" of the JSON object.


Set up eclair wallet 0.3.1 but cannot send onchain funds

Seems like onchain send functionality is not implemented yet. Workaround until then is to import the 24-word seed into another wallet. This can be run in parallel with eclair without problems.


Debugging Bitcoin Core with gdb - how to turn off compiler optimizations

Bitcoin Core disables -O2 and enables -Og when --enable-debug is set. -Og is intended for debugging; however, it removes some of the debugging information and is buggy. To disable it and to improve debugging experience, I suggest changing between L256 and L278 to:

CXXFLAGS="-ggdb3 -ftrapv"

-ggdb3 is more powerful than -g3, it uses a GDB-only, LLDB-incompatible dialect for debugging. This will also get rid of -O2, except in libsecp256k1.

Edit: Sipa suggests a more elegant way without altering autoconf files, which is adding args for configuring.

./configure CXXFLAGS="-O0 -ggdb3"

O0 is needed in this case.


How can I get address wise UTXO balance for Zcash t-address

You can get UTXO balance for Zcash t-address using https://chain.so/api/ api https://chain.so/api/v2/get_tx_unspent/ZECTEST/t2BqpZq16caHXC92LDTWg2pc8RQdmRFw5dF in testnet.


After Setting up my Bitcoin core Server, I need to create wallets for each of my client on a website may be thousands

I need to create wallets for each of my client on a website may be thousands

There are several ways to generate addresses in bulk. Using Bitcoin Core exclusively you can create individual wallets with the createwallet command in the RPC and then create new address with getnewaddress although you will have to do this programmatically as there is no built-in functionality for the creation of X number of addresses at a time.

A faster alternative outside of Bitcoin Core would be to use a vanity address generator such as VanityGen. The initial intention of VanityGen was to allow for the creation of unique/custom addresses with specified prefixed characters otherwise known as "vanity" addresses. Luckily this tool has an array of command-line parameters useful for bulk addresses generation too. VanityGen utilizes your graphics card (OpenCL-compatible) making it significantly more powerful than the standard CPU generation found in the Bitcoin Core client. Similarly, it works both online and offline.

Using the 64-bit Windows binaries provided on the project's GitHub, I can use the following command-line options:

vanitygen64 -o key_pairs.txt -v -k 1

-o Specifies file to write key pair to (Pattern, Address, PrivateKey)

-v Makes output verbose (Provides Pattern, PublicKey, PrivateKey, Address in stdout)

-k Continues search after finding a match (run infinitely until exited)

1 This is what the vanity generator will look for as a prefix.

All of the generated addresses and their private keys will be listed in the output file (key_pairs.txt in the example). You can parse this file and assign each of your "clients" a private and public key pair as well as the address that goes along with it.


Can you use any Bitcoin address as a Counterparty token receiving address?

Yes, you can use your Bitcoin addresses to receive Counterparty tokens. Make sure you have the private keys to your addresses backed up.

Counterparty is a layer built on top of the Bitcoin protocol which basically allows you to embed data into the Bitcoin blockchain. This data can be used to represent tokens which will be recognised by the counterparty protocol as being owned by a particular Bitcoin address. You will need a small BTC balance at the holding address in order to send those tokens to a new address.


What are the benefits of Invertible Bloom Lookup Tables for Bitcoin?

Invertible Bloom lookup tables can be used in many different ways, but the first paper you linked to explicitly proposes to use them to find differences between two data sets stored on different hosts without transferring the entire data set from one of the hosts to the other.

In context of Bitcoin, suppose that two nodes have just established a connection. Now they need to synchronize their transaction pools to make sure that each node knows about every transaction the other node knows about. A trivial solution is to send the list of transaction IDs for all transactions in the pool from one node to the other, but this list can be large. At the same time, each node will probably have most of the transactions that the other node has, so the number of transactions that have to be transferred is small.

The problem is to find which transactions should be transferred, and this is the problem that invertible Bloom lookup tables can solve. Rather than sending the list of all transactions IDs, a node only sends an invertible Bloom table, which is smaller, but it is only usable if the number of differences (transactions which are present on one of the nodes but not on the other) is small. The table can be made of different sizes, and the larger the table, the greater is the number of differences that it can resolve.

For Bitcoin, this means that the amount of unnecessary communication will be reduced, and that nodes will be able to synchronize their transaction pools more quickly. Bitcoin nodes need to synchronize the block chain as well, but because of its linear, append-only structure, there are simpler and more efficient algorithms for this, and such algorithms are used in Bitcoin from the beginning.


How will a bitcoin ETF be any different from a bitcoin exchange?

You don't get the bitcoins themselves.  Your investment fluctuates in response to the exchange rate.  From the brothers W:

  The investment objective of the Trust is for the Shares to reflect the
  *performance* of a weighted average price of Bitcoins, less the Trust’s
  expenses.

In other words, if the average exchange rate USD/BTC is $230, and you buy $230 worth of the ETF, when the average rate goes to $250, you could sell the ETF shares for around $250 ("less the Trust's expenses").  All of your transactions would have taken place on a US stock exchange, using US dollars.

You could do this yourself, by buying and selling BTC on a variety of exchanges, but your profits would be more than eaten up with the commissions for buying and selling.

The ETF, on the other hand, would presumably have the benefit of volume, and may not even have to invest all incoming funds when there are outgoing funds (from redemptions) at the same time.


Does the main Bitcoin client blacklist addresses?

There is a ban mechanism which is handled in net.cpp.

Any node which misbehave by more than -banscore (defaults to 100) is banned for -bantime (defaults to 60×60×24 seconds = 1 day).
However, nodes with a local ip address are exempted, and for those a warning is shown in the logs after each misbehavior.

Also bans are not persistent, they are lifted when the client is restarted.

So, during development, just make sure that your app connects with a local address to the bitcoin client, and you will not be bothered by bans.

Here is the relevant piece of code:

bool CNode::Misbehaving(int howmuch)
{
    if (addr.IsLocal())
    {
        printf("Warning: local node %s misbehaving\n", addr.ToString().c_str());
        return false;
    }

    nMisbehavior += howmuch;
    if (nMisbehavior >= GetArg("-banscore", 100))
    {
        int64 banTime = GetTime()+GetArg("-bantime", 60*60*24);  // Default 24-hour ban
        CRITICAL_BLOCK(cs_setBanned)
            if (setBanned[addr.ip] < banTime)
                setBanned[addr.ip] = banTime;
        CloseSocketDisconnect();
        printf("Disconnected %s for misbehavior (score=%d)\n", addr.ToString().c_str(), nMisbehavior);
        return true;
    }
    return false;
}


I have an old blockchain wallet and a .txt file of 43 words, but the site wants 12 words?

I figured it out. You can input legacy phrases here
https://login.blockchain.com/wallet/forgot-password
It spits out your password and wallet ID. I logged in. It's an empty wallet :(


How a transaction proves its ownership of the its source, which can be one or multiple unspent output?

Assume you understand how public-key cryptography works. In short, one can verify the ownership of an address by checking the signature. A valid signature can only be generated by the private key owner.

The detail of signature verification in Bitcoin is described here

Without digging into the details, OP_xxx are stack operations. For example, OP_DUP is to duplicate top of the stack. Basically it

first hashes the public key by operation OP_HASH160 and check if the result is identical to pubKeyHash by operation OP_EQUALVERIFY
then verifies sig and pubKey by operation OP_CHECKSIG

You can read more about OP_CHECKSIG here


See Is there a way to prove ownership of a transaction?, which suggests using the private key to sign a message. You could send a signed message to your professor with the transaction id. However, since you say you're in different groups, it can still be that someone from another group just uses your transaction id, and doesn't get caught.

I would suggest asking your professor to give everyone a different wallet address to transfer the money to, or to request that everyone signs his transaction id with the private key used for the transaction.


How to create different paper wallets for different currencies?

1)
It depends on the currencies you want to store. You could store Bitcoin and BitcoinCash on the same paperwallet because they use the same private and public keys. Just for a better overview I would recommend storing those on different paperwallets as well and labeling them accordingly.
You cannot store completely unrelated cryptocurrencies on the same paperwallet.
2)
The algorithms to create the private key and to create the public from a private key are/can be different for each crypocurrency out there. You would have to find tools for each one you want to store on paperwallets.


scriptPubKey consisting of the only hash

That's a transaction generated by p2pool. You assumed correctly in that it is designed to store data, it's used to store some metadata about the current state of the pool. In the future it would probably be better to use OP_DROP, as the output is provably unspendable and is able to be pruned from the mempool and blockchain.


Which transaction would get confirmed in an uncongested network?

On an uncongested network with an average tx fee of ~20 cents. Which transaction would most likely go through?

The transaction which confirms is the one chosen by the miner which finds the next block. There is no way to know which one they may choose. It may be the first one they saw, or it may be the one with the highest fees, or it may depend on some other factor that is relevant to the miner in question. It is simply up to them.


How do extremely difficult vanity addresses get found in the first place?

Funds are spendable by public keys and addresses contain public key hashes. Vanity addresses are created by hashing lots of public keys until the hash is in an expected range. What you mentioned is an example of a burn address, not a vanity address. Burn addresses are crafted by manually editing the public key hash with a specific the corresponding address in mind. Burn addresses do have corresponding public key(s), but since we it is impossible to find the public key from the public key hash, burn addresses cannot spend their funds. They are similar to addresses whose owners mistakenly deleted their wallets, where the funds are in a locked state.
The last digits of burn addresses is random is because addresses also contain a checksum which is the hash of everything else encoded in the address.


How does a node find a transaction in the blockchain?

You can read the bip37 specification for all of the gritty details.

  how does the full node find this transaction (or the UTXOs) in the blockchain?

The client builds a filter which contains what they're interested in, be it output script (addresses), public keys, or TXID. They then send this to the node they are connected to. When they request data for a particular block the node filters it to only contain things which match the clients bloom filter, and sends it to them. To find all of their unspent UTXO, they request every single block in the chain in turn and look for things that could be theirs. As you mostly worked out, this does involve for every client the node loading 80GB of blocks from disk and performing extremely expensive filtering operations on them.

Modern nodes recognise how terrible of an idea this is, and allow users to disable the functionality completely due to the massive load and denial of service risk involved. With specially crafted transactions, a remote peer with a single command of less than 50 bytes can cause a node to load a 1MB block from disk, hash it over a million times, and then return nothing.


Does 20 XRP become unusable once deposited in a wallet?

If it's a native wallet on the ledger, then 20 XRP will not be transferrable, though you can use it to pay transaction fees. Exchanges typically have you pay into their account, so there's no reserve that you need to pay. For reasons that nobody has ever figured out, Poloniex does make you pay the 20 XRP reserve.


Passwords and Pass-phrases

I have [...] passphrase (a good guess on it)

...

when I installed years ago Copay, I did set a password also.

I'm not 100% certain that you mean two different things by the words I highlighted. People play fast and loose with these words.
Password or Pass-phrase can refer to the same thing or to different things.

A Password or Pass-phrase can be used to protect the wallet. Typically by using it, directly or indirectly, as an encryption key to encrypt the wallet contents. This is not needed when using the seed-phrase to recover control over money and create a new wallet.

A BIP-39 pass-phrase is, as I understand it, simply additional words appended to the seed-phrase. This pass-phrase is chosen by the user, the seed-phrase is typically generated randomly by the wallet, not chosen by the user. The seed-phrase is sometimes called a recovery-phrase or backup-phrase.

So if your pass-phrase is just a multi-word password, as in case 1 above, you can ignore it.
BTCRecover
See https://github.com/gurnec/btcrecover/blob/master/TUTORIAL.md

BIP-39 Passphrases
Some BIP-39 compliant wallets offer a feature to add a “BIP-39” or “plausible deniability” passphrase to your seed (mnemonic),

It seems to me that you use the bip-39 option and just add the BIP-39 pass-phrase to the token list, but a careful study of the documentation ought to make this clear.


Bitcoind not publishing blocks via ZMQ after reorganization

Is this expected behaviour? During a chain-reorganization, can I only expect ZMQ to publish the tip of the new chain

Yes, a ZMQ notification is emitted any time the active tip of the chain changes.

If you have a chain B1-B2-B3, and there is a 1-deep reorg that rewrites B3, you end up with B1-B2-B3'-B4. The tip changes here from B3 to B4; it does not go back to B2 in between.

  leaving me to figure out that a reorganization has occurred and then having to manually retrieve the new blocks?

You have to do that anyway. ZMQ is not a reliable protocol, so you must be able to recover from missing messages (and in general, with a node going down temporarily). Dealing with this means discovering that the latest tip is a reorganization compared to what you had before.

This is true in general for ZMQ, you can use it as a notification mechanism to perform an update right when it happens, but you need infrastructure for fetching to recover too.

For more information, see the ZMQ documentation for Bitcoin Core at https://github.com/bitcoin/bitcoin/blob/master/doc/zmq.md.


How do mining pools connect to the Bitcoin network and miners connect to pool?

How do mining pools connect to the Bitcoin network to propagate transactions and blocks?

They connect in the same way that everyone else connecting to the Bitcoin network does. Miners are still nodes, they do everything that a full node does.

  Do they run their own full node?

Yes.

  If yes, how many of full nodes?

At least one. It doesn't matter how many nodes a miner is running, so long as they are running a node. At least one node is needed in order for them to see transactions and blocks and for them to broadcast their own blocks. Large mining operations may have multiple full nodes. Small ones may only have one. It is difficult to know how many and what nodes belong to miners as they look like any other node on the network.

  How do miners connect to a pool? Is there any server running by mining pools so miners can connect to?

Mining pools operate servers which give out work to miners with that pool. The miners have to connect to those servers in order to get work to do. They can connect using a variety of protocols. The two protocols in use today are stratum and getblocktemplate.


can I use elements of the blockchain to protect the integrity of a leaderboard without central servers?

In general, as mentioned in the comments. Your problem in these games resemble a Byzantine Generals Problem where you may experience non-compliant/malicious actors in the network. To achieve consensus in this context, there are multiple avenues.

Firstly, there's Bitcoin's approach. Bitcoin enables every full node to perform independent verification of the Blockchain. The Blockchain is simply a store of a series of past events leading to the current state. Where "past events" (i.e. transactions) are stored in Blocks and the "chain" refers to the hard requirement that each subsequent block is required to be dependent on the previous block based on a set of requirements. Access to the write permissions to the Blockchain is governed by means of Proof-of-Work, where you must burn CPU cycles to create a new block which implicitly grants you a write permission to append to the Blockchain. A key difference here is that the Proof-of-Work need not be done in a collaborative manner as it is a Poisson Process, meaning my chances are just as good as anyone else's, assuming that everyone has the same hash power. In other election algorithms, you may have to negotiate collaboratively and it is not necessarily fully byzantine-failure tolerant.

So how can some elements of this be applied in your gaming context is left for you to decide. But in principle, yes, elements of Bitcoins are applicable in the context you've described, but again I'd reiterate, it is somewhat "overkill". Maybe in the context of the game, you'd set the leaderboard to have some condition that requires some proof of some action that proves that the player has actually done something to mutate the leaderboard? Otherwise, it'd probably be simpler to do it in Lockstep as in RTS games.


Is there a way to detect a mining cartel?

An entity having over 50% of the hashing power can continue operation as it would while having less than 50% of the hashing power. It then can go undetected when carefully choosing how it distributes its newly fonud blocks.

However, given its share of the total hashing power is φ (for φ > .5, obviously), it only makes about φ of the total money made from mining. Once an entity has over half of the total hashing power, there is a very lucrative thing it can do: Make all the money made from mining. This is done by simply ignoring all blocks others mined and only mining on top of its own blocks. Because φ > .5 and the law of large numbers, every time someone else mines a block, it can be sure to at some point have the longest blockchain which then becomes the effective blockchain, redering all the money the entity made on it valid.

The blocks others mined then never are part of the longest blockchain for long, making them orphans.

For the orphan rate σ, this means that σ = 1 - φ if the entity with φ of the total hashing power operates at maximum profitability (never accepts blocks mined by others).

We don't see a high orphan rate.


Do bloom filters protect against a persistent eavesdropper?

See this paper for a good discussion:

On the Privacy Provisions of Bloom Filters in Lightweight
Bitcoin Clients


Raw data of dates in all blocks using PHP or R

I've written this simple PHP code with an explanation for each comma

PHP code

<?php

$lastBlockEnd = $this->MyRPC->BitcoinCoreCommand('getblockcount' , []);
// https://bitcoin.org/en/developer-reference#getblockcount

for ($i = 0; $i <= $lastBlockEnd; $i++){
    $blockHash = $this->MyRPC->BitcoinCoreCommand('getblockhash' , [$i]);
    //https://bitcoin.org/en/developer-reference#getblockhash
    $blockData = $this->MyRPC->BitcoinCoreCommand('getdata' , [$blockHash]);
    //https://bitcoin.org/en/developer-reference#getblock
    $block[$i]['time'] = $blockData['time'];
    $block[$i]['hash'] = $blockHash;
}

print_r($block);

Code Explanation

We are getting total available blocks number, say its 65443
we will start looping from block number 0 to 65443

  Note: You should send "batch request" instead of calling each block separately
  - we are getting block hash, then we're calling getdata and passing that block hash.

Now we've got the following response:

{
    "hash": "00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048",
    "confirmations": 447014,
    "strippedsize": 215,
    "size": 215,
    "weight": 860,
    "height": 1,
    "version": 1,
    "versionHex": "00000001",
    "merkleroot": "0e3e2357e806b6cdb1f70b54c3a3a17b6714ee1f0e68bebb44a74b1efd512098",
    "tx": [
        "0e3e2357e806b6cdb1f70b54c3a3a17b6714ee1f0e68bebb44a74b1efd512098"
    ],
    "time": 1231469665,
    "mediantime": 1231469665,
    "nonce": 2573394689,
    "bits": "1d00ffff",
    "difficulty": 1,
    "chainwork": "0000000000000000000000000000000000000000000000000000000200020002",
    "previousblockhash": "000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f",
    "nextblockhash": "000000006a625f06636b8bb6ac7b960a8d03705d1ace08b1a19da3fdcc99ddbd"
}

Finally, We are storing time and block hash in an array and printing it.


What will a miner do when a high-fee transaction comes but he has constructed his block and is solving the puzzle?

A modern mining system will do both.

Today, miners and mining pools have more hashpower than required to check all iterations of a nonce and extraNonce for a single block template. They get around this by consecutively operating on multiple block templates, usually varying on the block timestamp, data in the Coinbase transaction, and the list of selected transactions.

These updated block templates are constantly generated in parallel to the actual hashing operations - as more attractive transactions are discovered, the next set of block templates generated will be updated to contain those transactions. As soon as the mining hardware finishes with its current block template, it will grab a new, likely optimal template from the pool.

If a single worked discovers a valid block with a suboptimal template, miners will broadcast that block - there is little sense in discarding a block over a relatively small fee increase and giving up the entire block reward.


My Bitcoin wallet is out of sync after connecting for the first time

The official Bitcoin software has to download the details of every single address, transaction and confirmation block to be synchronised. If you've just installed it then it's going to take you 1-5 days to download that data depending on your Internet and computer speed (just leave it running on your computer).

There are other options to avoid this but as a rule of thumb it's more secure to use a "full client" such as the official software. Once it has sync'd every time you use it after that it will only need to sync the data since it last sync'd so is much, much quicker.


Restricting a wallet to a specific destination address

The protocol itself doesn't allow such a restriction but M of N functionality might be a way to implement something like this.

How will multisig addresses work?


Best practices for storing the bitcoin blockchain?

I have done extensive tests without SDD, and later on with SSD. For sure downloading the bitcoin blockchain does not (!) require an SSD. However, everyone knows, it is faster using an SSD. There is heavy disk I/O, storing the blockchain, and there is also heavy CPU usage (re-) calculating the values, before they are stored on the local drive. One can give parameters to the bitcoin core client to increase memory usage (to speed up process), and you can for sure try to play with OS cache. So you need a fair amount of power to get along, and balance the parameters.

The bitcoin blocksize growth is pre-determined, so Moore's law is less relevant, and the blockchain growth is much, much less than Moore's law. Back to SAN: I had an older 1GB/sec attached SAN drive, with redundancy behind, and downloaded the blockchain on a 2 CPU machine. There was no problem, and it took only ~30% of my comparable desktop machine with an INTEL i7 processor (Unix OS).

Reliability of data is given through the SAN architecture, and the query speed is sufficient: you query the blockchain "sequentially", and for sure this is slow. Depends on your use case... But this is independant from the disk subsystem. However, the big "online explorers" (blockchain.info...) re-index the blockchain into the specific addresses, tx IDs and more, so that requests attain a satisfying speed.


What do the red and green blocks mean in a price chart?

red block - price was going down
green block - price was going up


Is it possible to use a PGP key as a bitcoin address?

No, this is not possible.

Recent GPG versions do have support for Elliptic Curve crypto, with associated EC keys. The EC curves supported there are different from the one used in Bitcoin, though (they don't have the same size, so they certainly can't be isomorphic).


Can I use same bitcoin address for Mt.Gox deposit multiple times?

Of course you can. The reason for using different address every time is:

to provide you more anonymity. It will be harder for people to
associate your with your other addresses (but not impossible)

But if you need to make many transactions, it might be a little bit tedious. So it is up to you to decide what exactly do you want.


Is it possible to figure out whether two addresses are in the same wallet?

It is possible to tell that two addresses are in the same wallet if they both appear as an input of a transaction. This indicates that one person owns both of them as they can spend both of them.

It is also quite likely that when you are sending a transaction that has one neat input (say, 1BTC), and one not so neat (say, 0.59721364BTC), that the latter is most likely a change left over from a transaction you sent to someone and is being sent to another address you own from the same wallet. This claim could be possibly deniable, but should be true in most cases.


Is there a way to blacklist or track ransomware bitcoin addresses?

There are two parts to your question:

Blocking: Blocking would entail either nodes refusing to relay transactions paying the crooks, or miners not confirming such transactions. Even if the criminal's address is public and unchanging, which is unlikely due to most wallets generating a new address for each payment, it would require a change to Bitcoin's source code.

If such a thing were to actually get implemented, miners would not update, as choosing transactions based upon anything else than fee per kB would cause them to lose money. In theory, governments could force more than 51% of hash power to not mine blocks that confirm transactions to known ransomware authors, but if a government can launch such a 51% attack, we have bigger problems.
Tracking: Transactions are public, so anyone who downloads the blockchain can map all the transactions in a graph and follow which coins went where.

Companies like Elliptic and Chainalysis are doing exactly that, and given that ransomware identification sites run by the police, such as No More Ransom, collect the ransom notes including the payment addresses, it is expected that malware authors are being actively tracked through the blockchain.

These bitcoins are still valid despite the taint, meaning they will be accepted by wallet software, transferrable to anyone, and spendable anywhere they accept bitcoins. Except, of course, for the police attention they attract when spent.


Yes, Bitcoins are the same no matter where you bought them, and you can transfer them anywhere you want.

(One thing to watch out for, though, is that Bitcoin Cash is a different currency from Bitcoin, and you can't directly transfer one to the other.)


The pool's mining server gives each miner a template to use for generating blocks. When the server wants to update which transactions are included or which block to build upon it will push a new template to each miner.

To generate work for itself the miner is allowed to change the nonce, the timestamp and the extranonce.

The nonce is just a 32-bit number with no special meaning. All possible nonce values are quickly scanned by modern bitcoin ASIC hardware, so with the same timestamp and extranonce you only have a tiny amount of work.

The extranonce is part of the generation transaction, the transaction that generates new coins, which is the first transaction in the block. The extranonce has no special meaning.

The server must never send out the same block template twice, to ensure that the same work is not done multiple times. In the stratum protocol the extranonce is split in extranonce 1 and extranonce 2. Extranonce 1 belongs to the server and is in a part of the block template that the miner is not allowed to modify. To prevent sending the same work twice the server must never reuse the same extranonce 1 value unless something else (that is not modifiable by the miner) in the template has changed. For example the other (non-generation) transactions, or the previous block (the block we are building upon). As part of the template the server will tell the miner how large the extranonce 2 should be, usually 4 bytes. When the miner has tried all possible nonce values it can generate new work by changing the extranonce 2 value.

The timestamp (known as ntime) can also be useful to generate work. This can reduce the work load on a slow controller feeding work to fast ASIC chips. The controller only has to generate enough work to keep the ASICs busy for 1 second, using different extranonce 2 values. After that the ntime can be incremented by 1 every second and the same extranonce 2 values reused. This is known as "roll ntime" or "roll time", as the ntime field of the block is rolled forward. The ntime value can also be incremented every second for the purpose of more exact timestamps on blocks without reusing extranonce 2 values.

In this way the server and client cooperate to generate work and the same block is never hashed twice.


14nm will hash more with the same power consumption of a 22nm assuming your basing it on power only. But if both were 1/ths the 14nm would save more electricity. Obviously the 14nm would cost more as its newer tech. You'd have to weigh your electric cost vs hashing power.


So, would it make sense to increase block sizes at least for these intervals and decrease afterwards?

The key problem here is miners can introduce transactions in a block for free. In other words, miners can create lots of transactions with high fees for free. And there is no easy way to distinguish these transactions from regular legitimate  user transactions. Therefore, there is no easy way to measure the actual demand of unprocessed txs. This essentially provides block-space for free to miners and opens up DoS attacks.

  Would such mechanism might help Bitcoin in a way ?

Such a mechanism would certainly be helpful, but as pointed above there is no easy to make it work.


I sent some USDT Tether to a Bitcoin Paper Wallet. Can I still claim it back?

Yes you can since USDT is built upon the Bitcoin Blockchain thru a protocol layer known as the Omnilayer. You will still be able to access the USDT within that wallet address so long you have the private key.


"Can I double spend this transaction?" as long as the transaction is unconfirmed you can try to make a new transaction with the same transaction-details but a noticeable higher fee. then you must hope that your new transaction (with the higher fee) will be executed before your b9d6d...-transaction will be executed. if this works the result would be that the b9d6d...-transaction will never be executed in future because there are not enough funds on your 1GDvWJUd7Hy...-adress. did you mean this by writing "double spend"?


Are Tor .onion-addresses IP address independent?

Yes. The channels are announced with the node ID. If the ip Address changes we get a new node announcement message so it takes some time until the information is through the gossip protocol. But moving a node to a new server is no problem


Blockchain.info's wallet is based on the code at https://github.com/blockchain/My-Wallet. (no license is specified that I can see, but it seems apparent that they wish you to have the right to use it to own your keys) But let's take the worst-case view we can regarding this: Blockchain.info is suddenly offline, and their My-Wallet code with all of its forks on github are removed. You have a backup (encrypted or double-encrypted) and you wish to restore it.

pinheadmz has created an open source blockchain.info wallet decryption tool, based on a tool that blockchain.info has temporarily removed.

I have downloaded the existing Import Wallet page and tweaked it to dump the private keys in an alert window. This works with all of the encryption schemes that blockchain.info currently supports. It's quite unpolished, but does the job. It outputs each private key in the format in the backup (usually base58, which is somewhat unusual) and hex. You can download it at this link.

To ensure that you can easily make use of the above output, you might also want to have an offline copy of the (open source, public domain) Brainwallet site, which I've made a copy of here.

You and I are hardly the only ones to think of such things. This thread offers some good tips on using your Blockchain private keys offline (e.g. enable the option for automatic backups to be emailed to you when your wallet changes). I think it's quite safe to say that (as long as you have a good backup and know the password(s)), with a little help from the Bitcoin community, you will always be able to recover your Blockchain.info private keys for use elsewhere.


How does not practicing address reuse hurt my privacy?

There's a bigger attack surface for someone that wants to doxx you. They only need to link a single transaction to your real life person to know all the transactions you've participated in. A single payment to newegg, for instance, will identify you across all transactions.

Very few transactions are completely anonymous. But yes, if they're all completely anonymous, then you won't be hurting your privacy. However, that's much more the exception than the rule and you're probably leaking much more information than you think you are.


Litecoind answers "getnewaddress" RPC request with "Method not found"

The answer is to recompile the Litecoin daemon, making sure to call the configure script with the --enable-wallet option:

./configure --enable-wallet

From there, make and make-install will give you a binary that has the getnewaddress RPC method available.

This reason behind this is that - instead of just disabling the methods around using the daemon as a wallet, or throwing an error in the case they're used without the --enable-wallet compilation option - the methods themselves are not compiled into the binary at all. This is likely due to the use of litecoind as a wallet requiring an extra library - the Berkeley DB library - and the path of least resistance being to not try to compile that section of the code at all in order to avoid issues with referencing the library, but that's conjecture.

This should also solve similar issues in other coins forked from the bitcoin source, and for bitcoin itself.


How does an SPV wallet use the headers that it downloads?

The SPV uses the Merkle Root in the header to verify transaction information full nodes provide. As a header refers to the previous block by hash, an SPV wallet can be somewhat sure that it has real blockchain information.

To hear about transactions relevant to it, an SPV requests to get information about any transactions involving a provided set of public keys (some of which actually belong to the SPV, but not all) from a full node. The full node does the look-up, then tells the SPV which blocks have transactions that are relevant for it. Now, the SPV doesn't have all transaction information, and if it only got transation C, it would have no way of knowing that this information is accurate. However, this is where the Merkle root comes into play, as a way to provide minimal information to verify the existence of transactions.

An Example:

Let's say this block X has three transactions A, B, and C; the transaction C being relevant to the SPV.

See the following picture for an overview how the Merkle Root is derived from the three transactions.

Now, if the full node would just provide C, the SPV would have no idea if the transaction is actually in block X, but by providing also H(A|B), the SPV can re-derive the Merkle root, allowing it to verify that C is in the block.

To read more about some shortcomings of SPV wallets please refer to Bitcoin's answer.


getblocktemplate fails in regtest mode even when it is connected to the other node

You need to mine a block so that the software thinks that the blockchain is fully synced. The most recent block in the regtest blockchain is probably old so you just need to mine one more block to make the blockchain "recent".

Just use the generate command. You can do:

./src/bitcoin-cli -regtest -port=8333 -rpcport=8332 -rpcuser=test -rpcpassword=test generate 1

to mine one block.


Following are API’s, that provide wallet creation, transaction
  management, withdrawing coin etc. Each one have their own
  specifications.

https://block.io/docs/basic

Widely used
Multi signed i.e. Require two signatures for all withdrawals.
Currently we can trade only Bitcoin, Litecoin and Dogecoin.
We can create address
Send coins to other wallets as well as Withdraw coins etc
Get last/All/specific address transactions
Good Documentation.

https://accounts.blockcypher.com/

Multi featured
Currently we can trade only Bitcoin, Litecoin and Dogecoin.
We can create address
Send coins to other wallets as well as Withdraw coins etc
Get last/All/specific address transactions
Good Documentation
More Features avaible than above. i.e Analytics, events & hooks for notifications much more

https://github.com/Overtorment/Cashier-BTC

Self-hosted Node.js Bitcoin payment gateway.
Open Source & free.
Less Documented hence Hard to implement
No 3rd parties (works though Bitcoin Core node)
Transactions are signed locally. No private keys leak
How much coin we can trade: Working on it.
May be payable in future.
Battle-tested in production
SegWit compatible : Working on it.

https://chain.com/

Specially built for Financial services
Permissioned network access
Multi-signature accounts: Secure, multi-asset account management for individuals, businesses, and institutions
Instant settlement
Transaction privacy
Awesomely documented.
How much coin we can trade: Working on it.

https://github.com/bitpay/insight/

Provided by well known BitPAy
Descent Documented
Multi-signature accounts: Secure, multi-asset account management for individuals, businesses, and institutions
Fees : Working on it.
How much coin we can trade: Working on it.
Secure


Can somebody show me a working gettxoutproof / verifytxoutproof pair?


Why is the change address for a transaction the same as the originator address?

Many wallets let you control where to send the change. In most cases it is advisable to send to a new address to reduce traceability and increase your privacy a little, but not everyone does and sometimes it makes sense not to do it. Most modern wallets will create a new address automatically unless you stop them.
Bad reasons to send change to the same address

Fees. Some people think that they will pay less fess if all their funds are in the same address. That is not the case, fees are determined by number of inputs (and age, signatures and outputs), not addresses. 1 BTC in address A and another one in address B will cost to send the same than 2 BTC in two different inputs in adress A
Convenience. Some people think that having many addresses is more difficult to manage. This is wrong, all wallets will do this automatically.

Good reasons to send change to the same address

Multisignature addresses (those that need several parties signing transactions). Those work in a different way than regular addresses and don't "live" in a wallet. Users need to create them one by one, usually for very good reasons (like needed two signatures to pay with shared money) and sending change to a new non multisignature address would defeat their purpose.
Accountability. If someone publishes an address so others can check what he does with the funds it makes sense to always send the change there so it is easier for those who check.


Is it true that sending from an address exposes the public key of a bitcoin address?

This is mostly not correct.

First of all, the address is a hash of the public key only.

Also, if one has a private key, the corresponding public key can be computed directly.  So the most straightforward brute-force attack looks something like this:

Pick a number to use as a private key (an integer between 0 and 2^256, roughly)
Compute the corresponding public key
Compute the RIPEMD-160 hash of the public key
See if it matches the target address (or any other address containing coins)
Repeat

Knowing the public key in advance isn't relevant for this attack.  In fact, since the private key is 256 bits and the hash is only 160 bits, it is overwhelmingly likely that if the attack succeeds, it will be by finding a private key which produces a public key that is different from the original public key but has the same hash.  (Of course, it is overwhelmingly unlikely that this will actually succeed before the end of the universe.)

The whole point of public key cryptography is that it remains secure even when the public key is made public, and ECDSA is believed to be a secure algorithm in this respect.  There are no known attacks in which knowing the public key makes it feasible to recover the private key or otherwise produce valid signatures.  So it's not accurate to say that addresses with an exposed public key are "at risk" of having the coins stolen.  This is not a real risk, as far as is known.

There are theoretical attacks based on quantum computing that might make it much easier to determine a private key from the corresponding public key.  See What effects would a scalable Quantum Computer have on Bitcoin?  If those attacks (and the requisite quantum computing technology) should eventually become possible in practice, then there would be a real increased risk to addresses with an exposed public key.  That is not the case today and as far as I know, it is not likely anytime soon.

I don't know of any compiled list of funded addresses with exposed public keys.

See also Is that safe to expose public key to the mainnet


Bitcoin core verification keeps reseting

As 0x49D1 reported: reducing the Bitcoin Core database cache helped to reduce memory usage, which caused the crashes while syncing.

In bitcoin.config dbcache=<n> or as command-line argument -dbcache=<n> where n is the database cache size in megabytes (default: 300)

Source


Would it be possible to create a mining pool service that specifically processed only certain transactions?

From what I understand, you are asking whether one can customize a client running at a mining pool to favour some transactions based on factors like what metadata they contain or where they were sent from.

The answer is, yes, it would be pretty easy if you would be able to program a custom client or pool software.

Searching for a piece of information in a transaction is pretty easy and shouldn't require too much processing power (one could for example use OP_PUSHDATA and later OP_DROP to store some data without affecting the transaction). The downside is that anyone could see which transactions were potentially prepared like this.

If you wanted to discriminate based on where the data came from (for example, your own eWallet, or custom wallet running on a computer), you'd need to spend some more time coding, but one couldn't distinguish between your special transactions and the normal ones. You could for example encode the client to wrap the transaction up in some data packet and sign it using a specific key and algorithm before sending it to your server. You'd have to write some special code to check the signature and relay the information to the pool, but it shouldn't be too hard.

Such service would certainly go against the spirit of Bitcoin, and probably you'd get some backlash from the community if it found out, but it is possible none the less. Unless such a pool would hold a considerable amount of Bitcoin network's hashing power however, it would not disturb how the network works. However, if it was to reach 51+% percent of the hashing speed, as it is always with such an attack, it could control the entire network.


Is verification of a blockchain computationally cheaper than recreating it?

Is verification of blockchain computationally cheaper than recreating it?

Yes, far easier

  How do you verify the blockchain integrity? Don't you also have to recalculate all the values to see whether they are valid?

No.

The miner has to find a value for parts of the block they can choose a value for, such that a hash of the block has a certain number of leading zeroes. This is impossible to predict without actually calculating the hash. So miners have to try a very large number of different choices before finding one that produces the hash with the required number of leading zeroes.

The verifier only has to recalculate that hash once because they don't need to vary any part of the block.

(note, the above is a simplification but the principles apply)

Reference:

Nonce
What exactly is Mining?


Does having a pruned node reduce its network score?

What's the meaning of the score in getnetworkinfo?

When you look up getnetworkinfo in the Bitcoin Developer Reference, it says about score:

  The number of incoming connections during the uptime of this node that have used this address in their version message

If I understand that correctly, this means that the score is the number of times incoming connections have been established with your node since it started.

Network services and pruning

Nodes on the network announce the services they offer by setting their network services flags.

There are currently five flags in use:

NODE_NETWORK (1)
NODE_GETUTXOS (2)
NODE_BLOOM (4)
NODE_WITNESS (8)
NODE_XTHIN (16)

Out of these, NODE_NETWORK indicates that your node will serve historical blocks. Currently there is no way to announce that you can only serve a subset of all blocks, so just like nodes that cannot serve blocks at all, pruning nodes don't advertise NODE_NETWORK.

Pruning nodes don't get referred by DNS seeders

This has a direct effect on the number of incoming connections pruning nodes get, as DNS seeders only refer nodes that advertise NODE_NETWORK when new nodes request additional peers to connect to. This means that pruning nodes only get incoming connections when they are referred by non-DNS seeder nodes.


I have been using this for a long time, and I always skipped the fields. Now that you mention it, here is a partial answer:

1.) I do not know.

2.) The transaction hash appears at the end of the list; it also appears in the link you provided.

3.) Another good question. I do not know.

4.) The fields which are signed come from the previous transaction where, basically, the whole data structure is signed with the exception that the "scriptSig" field is filled with the "pubkey" script.

There are three great sources of documentation on transaction structures:

1.) Bitcoin.org Developer Guide

2.) "Mastering Bitcoin" by Andreas Antonopoulos

3.) Bitcoins the hard way: Using the raw Bitcoin protocol

I hope this was beneficial.


Why can a wallet not compute the private-key from a public-key?

Your post is a series of questions, each of which I'm having trouble understanding specifically, but in general it seems that you are confused about the role of private and public keys in bitcoin. So, as a high level answer:

Bitcoin uses public key cryptography to verify that users are allowed to spend some bitcoin. A user will create a private/public keypair, and then create a bitcoin address from the public key. Any bitcoin sent to that address is only spendable if the private key signs a transaction spending it (the transaction includes the public key, so that the network can verify the signature).

The way public key cryptography works, it is computationally infeasible to work backwards from the public key, in order to find a private key. So a wallet cannot 'find' the private key for a given public key.

A bitcoin wallet can be thought of as a keychain app, because it stores the user's keypairs. So the wallet will manage your keypairs, create and sign transactions, etc. A private key is not used to sign into the wallet, for that you would use a secure login system (PIN, username, password, 2FA, etc, depending on the type of wallet).

To keep bitcoin safe, it is best to keep your private keys 100% offline, using hardware that never connects to the internet to generate (and potentially store) the keys.

With this setup, there is no reason to specify an 'owner' of an account or wallet, the network only cares about whether or not a signature is valid.

Any good wallet software will generate keys using a proper random number generator, and the keyspace is so large that the chance of ever generating the same private key twice is pretty much zero. The only way to create the same keys in two wallets is to either create the key in one wallet, and then import it to the second wallet, or use an HD wallet architecture and then use the same mnemonic seed phrase to create multiple wallet instances.


What happens when transaction bandwidth is exceeded?

A search for definitive information turned up literally nothing, so, what happens when transaction bandwidth is exceeded for an extended period?

The same thing as always happens: miners decide, at their own discretion, which transactions to include in their blocks.  Most likely they will choose those that have the highest fees.  Transactions that don't go in the blocks remain unconfirmed.  There is no special handling for such a case.

  After a period of two weeks (default) transactions are dropped from mempool, if this continues for three months then all transactions from weeks one through eleven will need to be resubmitted a) when the load on mempool dies down a bit or b) with higher fees excluding some other transaction in its place.

That's correct.  If the user still cares about having the transaction confirmed, they (or their software or their wallet provider) will need to do one of those two things.

  I have seen mempool with over 50,000 transactions for many days in a row, perhaps weeks, so, should this actually be called a quasi-payment system where it is possible any given transaction may eventually be forgotten about if the user does not keep on top of it?

It's true that Bitcoin does not provide any guarantee that a given transaction will ever be confirmed, and it never did.  That simply isn't a design feature.  Feel free to call it a "quasi-payment system" if you like that term better.


Your question involves quite a bit.
Mining is done with conjunction of a wallet.
A lot of the work is handled by the wallet.
See the RPC getblocktemplate
Also run help getblocktemplate to see more information, that will point you to a few BIPs (B22, 23, 9, and 145) for further reading.

Basically (simplified) you do a getblocktemplate and then you repeatedly hash it (while incrementing the nonce) to get a hash that meets the difficulty criteria.

I hope this is enough information to get you started


What is QuoteAssetVolume and BaseAssetVolume?

baseAssetVolume is the quantity shown as the amount of coins received by the buyer whereas the quoteAssetVolume is the amount paid by the payer


How do I build bitcoin transactions graph?

The database schema is located here: https://webbtc.com/api/schema

You might be disappointed to find out that it's not as simple as an amount and a sender for each transaction. What there are is a list of inputs (references to previous outputs), and a list of new outputs. Each output with an amount and a pseudonymous address. Each input has a TXID and output index to reference which previous output it is spending. Unless you know who owns specific addresses, though, you can't determine the identity of the sender(s).

You can use the prev_out and prev_out_index from a row in the inputs table to find the associated previous output, which will tell you the amount and address.


If people in general would more often pick lower integers as private keys than larger integers, then it would be a good strategy for an attacker to start with lower integers.

However, the opposite also holds. If people would more often pick larger numbers, then atackers would ideally start at the end and work their way backwards.

In practice, no such bias exists. As long as people use decent proper random number generation, every integer is just as likely as any other, and it does not matter in what order an attacker tries things. He'll need to go through half of private key range on average regardless.

So no, there is no minimum number to start at. Yes, you have an extremely small chance of picking a number between 1 and 1000. But similarly you have an equal chance to pick a number between 76136428194729137 and 76136428194730136. An attacker has no reason to think you're more likely to pick something between 1 and 1000, so why would an attacker start at?

Also, whenever the attacker has the public key, there exist far faster (but still completely infeasible) algorithms to find the private key. These algorithms inherently operate in random order, so it does not matter.


Under what circumstances will a full node disconnect a peer?

For a node to be disconnected the default threshold of banscore is 100. In versions prior to v0.18, the default time to keep the misbehaving peer from reconnecting is 86,400 seconds or 1 day. However, this was circumvented by attackers with multiple IP addresses.

v0.18 release, allows peers that your node automatically disconnected for misbehavior (e.g. sending invalid data) to reconnect to your node if you have unused incoming connection slots. If your slots fill up, a misbehaving node will be disconnected to make room for nodes without a history of problems (unless the misbehaving node helps your node in some other way, such as by connecting to a part of the Internet from which you don't have many other peers).

Following are the reasons for disconnection, or increasing the banscore.

Peers which provide a chain with less work than the minimum-chain-work during IBD are  disconnected
If the node is providing invalid data like mutated block or data not meeting consensus requirements
If the compact block had a valid header, but contained invalid txs, the peer should not be punished
Ban outbound (but not inbound) peers if on an invalid chain.
Invalid header, invalid block checkpoint, and invalid previous block will result in outright ban
If previous block is missing, the banscore is incremented by 10. This is done so as to prevent DoS attacks
If the peer sends a getblocktxn with out-of-bounds tx indices it will result in a ban
There are other items related to bloom version and bloom size which might result in ban
First message should be a version message and each connection can send version message only once. If not, the banscore is incremented by 1
If the node is sending addr messages with more than 1000 addresses, then banscore is incremented by 20
Sending inv messages that exceeds the max size, then banscore is incremented by 20.
Sending header messages with more than 2000 elements, resulting in incrementing banscore by 20.
Nodes must NEVER send a data item > 520 bytes or misbehaving score is incremented by 100

There are other couple reason which might have been ommited. You can search "misbehaving" in the netprocessing.cpp file for all the reasons.

  Do full nodes disconnect from connections that don't send enough data?

Not particularly but somewhat yes. When the chain tip does not advance for over 30 minutes, the full node assumes that the tip may be stale and hence will try to connect to an additional outbound peer. There is a periodic check that ensures that if the extra peer connection is in use, the node will disconnect the peer that least recently announced a new block.


Are there services which I can offer to earn bitcoins?

The best I can suggest you is to offer some services to third parties and get paid in cryptocurrencies.

If you have any skill which can be "sold" on the internet you should use this to try and earn some crypto money. This can range from coding to video editing, freelancing, writing, etc.


import multisig wallet into bitcoin core, Vpub keys are not valid. how to?

this is a script that works for me, it imports a 2of3 HD multisig wallet.
I have very basic knowledge of bash so you may want to double check it before running it, anyway, what finally worked for me was to understand that I had to wsh(sortedmulti(2,${pub1}/0/*,${pub2}/0/*,${pub3}/0/*))to derive the receive descriptor and wsh(sortedmulti(2,${pub1}/1/*,${pub2}/0/*,${pub3}/0/*))for receiver.
I also found this good converter here:
https://jlopp.github.io/xpub-converter/
#!/bin/sh

wallet=$1
pub1=$2
pub2=$3
pub3=$4
startfrom=$5
range=$6

wallet="${wallet:=test}"
pub1="${pub1:=Vpub1...}"
pub2="${pub2:=Vpub2...}"
pub3="${pub3:=Vpub3...}"
rescanblockchain="${startfrom:=1934907}"
range="${range:=[0,100]}"

p1=$(echo $pub1 | cut -c1-10)
p2=$(echo $pub2 | cut -c1-10)
p3=$(echo $pub3 | cut -c1-10)

printf "\n\nWorking on '${wallet}' from ${p1}... ${p2}... ${p3} starting from ${rescanblockchain}\n\n"

# create wallet if needed
if [[ $(bitcoin-cli listwallets | jq '. | index("'$wallet'")' ) == "null" ]]; then
    echo "Making wallet '${wallet}' from ${pub1} ${pub2} ${pub3}"
    bitcoin-cli createwallet $wallet  true
fi

# convert keys format from vpub to tpub https://jlopp.github.io/xpub-converter/
pub1=$(node converter.js ${pub1})
pub2=$(node converter.js ${pub2})
pub3=$(node converter.js ${pub3})

# get descriptor for receive addresses
raw_receive_descriptor="wsh(sortedmulti(2,${pub1}/0/*,${pub2}/0/*,${pub3}/0/*))"
receive_descriptor=$(bitcoin-cli getdescriptorinfo $raw_receive_descriptor | jq -r '.descriptor')

# get descriptor for change addresses
raw_change_descriptor="wsh(sortedmulti(2,${pub1}/1/*,${pub2}/0/*,${pub3}/0/*))"
change_descriptor=$(bitcoin-cli getdescriptorinfo $raw_change_descriptor | jq -r '.descriptor')

# import receive addresses
bitcoin-cli -rpcwallet=$wallet importmulti  '[{"desc": "'$receive_descriptor'", "internal": false, "range": '${range}', "timestamp": "now", "keypool": true, "watchonly": true}]'  '{"rescan": false}' | jq .

# import change addresses
bitcoin-cli -rpcwallet=$wallet importmulti  '[{"desc": "'$change_descriptor'", "internal": true, "range": '${range}', "timestamp": "now", "keypool": true, "watchonly": true}]'  '{"rescan": false}' | jq .

# rescan blockchain
bitcoin-cli -rpcwallet=$wallet rescanblockchain "${rescanblockchain}" | jq .

# just print out few receive addresses
bitcoin-cli deriveaddresses  ${receive_descriptor} "${range}" | jq .

# print out balance
bitcoin-cli -rpcwallet=$wallet getbalance


How do I join the NXT 2.0 (Ardor) distribution if it isn't an ICO? And how does it affect NXT 1.0 holders?

The Ardor launch will happen in 2017, but the distribution of the main ARDR tokens will be based on the Nxt 1.0 balances. And yes, as far as I know it is the first scalable blockchain platform using 100% proof of stake.

Starting the next 14th of July, the Nxt network will take a snapshot of all the account balances every hour. This will last for three months. At Nxt network block 1,000,000 (due for October 12th) every Nxt account will receive an amount of Ardor assets equal to the average of all the snapshots taken - so you'll get as many Ardor tokens as the average of your NXT balance during those three months. So anyone who holds NXT during the snapshots period, regardless of when the NXT were acquired, will participate in the initial Ardor distribution.

After Nxt network block 1,000,000 your account still keeps the NXT you are holding at that block, as usual. And from that moment, ARDR assets also become tradable in the Nxt asset exchange.

When the Ardor network goes live next year, the tokens for the main Ardor chain will be distributed according to the number of ARDR assets held in each Nxt account at the moment of launch. This main chain and the ARDR tokens are the backbone securing the whole network, including all child chains transactions.

As for the Nxt 1.0 system, it will stay running and it will have its own roadmap aside from Ardor.

There's another aspect to keep in mind: as said, Ardor will have a main chain, fueled by the ARDR tokens, that secures all the transactions done in the whole Ardor platform, including all of the child chain transactions that may be created by platform users. The first among these child chains will be included at Ardor launch, and while the main ARDR chain will only include basic transaction types and the staking/forging operations, this first child chain will use a "transactional" token and include all the features currently working at Nxt 1.0, like the Asset Exchange, Voting or the Monetary System.

The token for this first child chain (called "FNX" in development discussions so far) will also be distributed according to the existing Nxt 1.0 balances at the time of Ardor launch, and a percentage of this first child chain tokens will be held to fund the platform development. Initially a 50% of these first child chain tokens was proposed to sustain Ardor funding in the long run, but the percentage is still open and it might be smaller depending on how things unfold in this upcoming months.

So, as a tl:dr;

Nxt 1.0 users will receive at network block 1,000,000 an amount of Ardor tokens equal to the average NXT balance in their accounts from July 14th to block 1,000,000. The NXT will remain in Nxt 1.0 account balances, and then ARDR can be traded in the Nxt Asset Exchange.

At the moment of Ardor launch in 2017, every account will receive an amount of Ardor tokens equal to the number of ARDR assets it holds, and an amount of the first child chain tokens ("FNX") equal to the amount of NXT in their balance at that moment, multiplied by a % coefficient to be determined, but at this moment set at 0.5 (i.e. 0.5 "FNX" for every 1 NXT)


BIP 22 is the draft specification for getmemorypool, and should answer all the questions you asked.


A few elements of answer:

Difficulty readjustment can be done for each block on some altcoins.
Mining is a highly random process, if you keep on flipping a coin all day, you will get long series of faces. Similarly, the miners may get unlucky. Even in bitcoin you see gaps of over an hour.
The above is compounded for altcoins as miners switch from one to another depending on profitability.

So nothing really unusual. As for a fix, bitcoins' testnet uses a rule where difficulty drops to 1 when no block has been found for 20 min. But the security implications should be thought through.


How do I recover newly created bitcoin addresses from an older wallet.dat?

Unfortunately, this is not possible. One of the disadvantages of non-deterministic wallets is that when new keys are needed and the key pool is empty, they are generated randomly. If the new wallet is lost, there is no way to extract those keys from an older wallet.


Is it accurate to refer to Bitcoin as "money"?

Money is something that is used as

a medium of exchange
a unit of account
a store of value

in a given socio-economic context.

In the context of the Bitcoin community, Bitcoin is being used as a medium of exchange (payment vehicle) and – as the existence of "hodlers" shows – as a store of value.

You apparently agreed with Bob that some specific amount of Bitcoin would be sufficient to repay your debt to him. Therefore, you are denominating your debt in Bitcoin, i.e. using it as a Unit of Account.

Under these circumstances, both Bob and you should consider "I already gave you the money, Bob!" an accurate usage of the term money.

In other circles, there is discussion especially about whether Bitcoin fulfills the "Unit of Account" property. Hence, others may disagree that Bitcoin is money.


In this particular case, the parameter script code refers to a public key script.

Usually, the function SignatureHash is invoked to either sign a transaction or to verify a signature. Thus it refers to a transaction input (this is either the transaction input for which we want to generate the signature that will then be placed in the signature script or the transaction input from which we have extracted the signature that we want to verify). This transaction input refers to an unspent (at the time of creating the transaction) transaction output, and this transaction output contains a script that should match the script in the input. It is this script that is passed as a parameter.

On my blog, I have a detailed post on the process of signing a bitcoin transaction which you might find helpful.


What exactly is the transaction fee? The fee of finding a block? The fee of transferring the btc reward to another account?

Transaction fee is a method by which anyone who creates a transaction incentivizes the miners to include that transaction in the block that the miner will mine. Bitcoin blocks can have a maximum 4MB of block weight, which means there are only certain transactions that can be included in the block that is being mined. So you include a fee so that miner picks your transaction over others to include in the block. Transaction fees also serve another purpose of preventing DoS attacks. If there were no fees, people in order to spam the network would send between between addresses they control so as to deny the service to legitimate people. Transaction fees ensure that there is a cost associated for launching such attacks.

To be more thorough, you do not send a transaction fee to a particular address, but it is the difference between the input and output amounts. So consider a transaction that consumes 1BTC and sends 0.8BTC to one address and 0.15 BTC to another address, then the transaction fee is 0.05BTC. When the miner creates the coinbase transaction for the block he is mining, he will pay out the block reward (12.5 BTC currently) and sum of all the fees of the transactions that are included in the block to the pool participants.

As to your other question about how they pay transaction fees vs block reward, that is more of a service related question and is more suited to the customer relationship department of each pool.


There's a core of truth in your question. Indeed, eventually it will reach a point where you can trace it. But there might have been a lot of transactions/hops before that happens.

If it has switched that many hands, how can you be sure that it is still in the hands of the cybercriminals? The money might have been yours but it has been used in quite a few legit transactions. On top of that, finding out the identity of the last person doesn't help in catching the bad guy.


What are some of the GitHub alternatives that you consider for Bitcoin Core and other Bitcoin related projects?

A list of some GitHub alternatives is here.

GitLab
BitBucket
SourceForge
Launchpad
Google Cloud Source Repositories
AWS CodeCommit
Phabricator
Gogs (Self-Hosted)
Gitea (Self-Hosted)
Apache Allura (Self-Hosted)

This GitHub Repo Full Downloader written by Andrew Chow may also be of interest.
Discussion on whether to move from GitHub and where to move to should be had on IRC and GitHub rather than here. StackExchange isn't set up for discussions and conversations and it will get very noisy if everyone expresses a view here.


Setup a full node on server for frond end Wallet

Yes, but a few important points.

Don't forget to enable txindex, it will allow you to query your node for all transactions.
Don't use the RPC API on the front end. RPC is needed to make transactions, but it might allow others to withdraw your coins. Keep the RPC in the back end.
The HTTP REST API is suitable for front end use.
Don't keep your funds on a client on a cloud server unless you trust them.
The front end shouldn't contact the node to make transactions or handle the private keys, instead, you should use BitcoinJS or Bitcore-lib to create transactions on the front end.


Check the Bittrex api page.

The buyLimit endpoint says that the rate must be the rate at which to place the order.

In order to get the current ask price, use the getticker api which will return something like:

{
    "success" : true,
    "message" : "",
    "result" : {
        "Bid" : 2.05670368,
        "Ask" : 3.35579531,
        "Last" : 3.35579531
    }
}


How long on average would it take to discover all other nodes in Bitcoin network and connect to them? Are there technical obstacles to this?

how long on average would it take for a node to discover all other nodes

No normal node ever does this.
A normal node only connects directly with a very small number of other nodes (e.g. max 8 outbound, max 125 inbound) and relies on those other nodes to pass on information to the small number of nodes they are in contact with. This way information diffuses across the entire network.
Since nodes are continually appearing and disappearing any attempt to contact all nodes would be essentially endless or both incomplete and incorrect (it would include nodes that have been removed since the start of the discovery process)


java.lang.NoClassDefFoundError: org/spongycastle/util/encoders/Hex in Java when dealing with Bitcoin addresses

You need to resolve the dependency org.spongycastle.util.encoders.Hex, more than likely you need to add this dependency to your pom.xml file if you are using Maven. If you are not using maven, you will have download the JAR file from somewhere and I add it to your build path in Eclipse.

From a quick Google search this appears this is  the dependency that you want.


Folding@home work is not compatible with the required properties of the work that needs to be performed for bitcoin. In particular, the computation work required for bitcoin mining needs to assure:

(a) difficulty of getting a 'good' result
(b) ease of verification of a good result once it is found
(c) precise scaling of difficulty depending on total network power.

The folding@home problems provide neither assurance of difficulty nor are in any way easy to scale depending on network power (since each folding problem is unique). They probably do meet the (b) ease of verification, but not the other criteria.


Based on the coinmarket cap api, how do they calculate the bitcoin percent change

Well, you have all the information you need:

Compute the price of your coin 24h ago (in USD)
Get the price of the bitcoin 24h ago (in USD)
Compute how much bitcoin your coin was worth in BTC 24h ago using the two previous results
Compare with the current BTC value of your coin

Done :)


IF you still have your wallet:

This means you still have your private key
This also means you have your public key (you call it the same email address i assume)
syncronize the blockchain on your bitcoin client in case of using bitcoin-qt. This will take some time (+-2 days)
Copy your public key and go to blockchain website and past you key in the search bar. This will show you if the bitcoins still exist.
In case they still exist on the blockchain then once the blockchain has been syncronized and completed it will also appear in your wallet.

If you lost your wallet and you never wrote your private and public key down then they are lost for ever!


How do I recover from a cryptocurrency scam?

You don't. At least, you don't recover your money. I guess you recover by learning from the mistake and doing things more safely in future. It may be worth asking an accountant if the financial loss on your investment can be offset against other taxable income.

  I contacted my bank to see if they could do anything about this situation

The whole point of cryptocurrencies is to take control away from banks.

  Local police say it’s impossible to get my money back.

True. for any loss less than $100000 the police are likely to only hand out advice. It isn't worth their while to try and investigate most cases where people willingly give their own money to unknown people in faraway countries. Foreign police forces often just ignore any requests for help in such matters.

Although there's nothing I can find in the writings of Satoshi Nakamoto about law enforcement and Bitcoin, the blockchain is deliberately designed to promote privacy and an effect of this is to make it harder for police to investigate Bitcoin related crime. It is obvious that privacy was important to the designers of Bitcoin.

  Can anyone help me ?

No.

However plenty of scammers will offer to help you. Ignore them.

  This has made me really frustrated as I invested all my savings.

This is understandable. Sorry for your loss, I hope you are able to put this behind you and move on.


What would be the fastest way to query for a certain txid to get its inputs?

A quick and relatively fast way (probably much faster then Bitcore) is using a recent version of Bitcoin Core and run it with -txindex and -rest.

Then use the REST interface to query for a txid.

Example:
curl localhost:18332/rest/tx/0e3e2357e806b6cdb1f70b54c3a3a17b6714ee1f0e68bebb44a74b1efd512098.json

You can even bypass the JSON encoding/decoding if you look for faster processing by using .bin instead of .json in your request URI.

Internally, Bitcoin Core uses levelDB for the txindex which tends to be blazing fast and once the file & disk position has been loaded from the levelDB, the according block file will be opened, then the file pointer seeks to the tx-position and deserialises only the requested tx.

Also don't forget, that Bitcore uses Bitcoin Core under the hood (very likely an outdated version since Bitcore is AFAIK no longer maintained).

Using a blockexplorer (or say web API) will make you trust a third party and will pretty sure be much slower.


bitcoind - how to find out what is affecting the verificationprogress

The verification progress is an estimate, based on how many transactions have been seen versus known statistics about the transaction rate on the network.

If the latest block timestamp is in the past, the verification progress will be below 1. If the latest block timestamp is in the future, the verification progress will be above 1.

Nothing is wrong by it persistently below 1. It's a side effect of blocks only appearing every 10 minutes.


Online trading testing sandbox for Bittrex

I don't think Bittrex has a sandbox mode, I googled it and there wasnt so much information around...

You can look for testnets and testnet coins faucets if you want to test cryptos without spending real money.


Is there a way to sign a transaction with BTC or any Altcoin without a computer using only pen and paper?

He cannot for a bunch of reasons:

He has no idea what the unspent transaction hashes are (not memorized).
He does not have a good way to know where he's sending the coins.
In order to actually sign the transaction, Satoshi would need to do ECC math on the SECP256K1 curve, which he hasn't memorized.

Supposing that he's given an unsigned transaction to sign and he somehow has memorized the parameters of the SECP256K1 curve, it would be possible, but it's likely to take him a very long time to sign a single transaction. Point doubling alone is 14 operations of 256 bit numbers using Jacobian coordinates. For signing anything, you usually need to double the generator point 256 times.

Basically, he can if given all these numbers, but it's likely not (A) secure since he'll leave have the paper around which has evidence of his private key which he needs in order to sign and (B) efficient in any sense of the word since it's very likely he'll make mistakes and a single mistake will render the signature invalid.


Problems checking BTC current balance using blockchain.info's API, am I correct here?

Just ran almost the exact same code in perl and this works:

#!/usr/bin/perl

use WWW::Mechanize;

my $btcaddress = "1Enn7YW22vBGvCWrsPQN7vDhnQCYhy221V";

my $mech = WWW::Mechanize->new();
$mech->get("http://blockexplorer.com/q/getreceivedbyaddress/" . $btcaddress);   # Check transactions on each address as per masterlist
my $getreceived = $mech->content;

print $getreceived . "\n";

$mech->get("http://blockexplorer.com/q/addressbalance/".$btcaddress);   # Check balance on of each address as per master list
my $addressbalance = $mech->content;

print $addressbalance . "\n";

Note the address is a random one I found on blockchain.info.


Location of blockchain locally on different platforms, and structure of blockchain file?

You will find the .dat files in the following locations:

Linux: ~/.bitcoin/blocks
MacOS: ~/Library/Application Support/Bitcoin/blocks
Windows: %APPDATA%Bitcoin\blocks
WinXP: C:\Documents and Settings\YourUserName\Application data\Bitcoin\blocks
Win7/Win8/Vista: C:\Users\YourUserName\AppData\Roaming\Bitcoin\blocks

I always found the following attached image helpful in order to understand the structure of the dat files. I am sure it will help you too.


It looks like you included fees of about 35 sat/B on your transaction.

Take a look at the table on this page, and you can see with that fee, many transactions with that fee take a VERY long time to be confirmed (nearly infinite).

You can not expect a transaction to be confirmed in 24 hours at that fee.  It may take over a week, or it may never get confirmed.

The recommended fee is currently around 420 sat/B, or more than 10x what you paid.


Which API provides the website URL for a cryptocurrency?

CryptoCompare's API has the website URLs if you use CoinSnapshopFullById:

CryptoCompare API


It is the hash type, in this case it is SIGHASH_ALL. To verify the digital signature inside of the Script language, it is required to have a hash type appended to the end of the digital signature. However if you verifying the signature using something like openssl, the bitcore signature would be valid.


Are there any online services available to exchange prepaid cards into BTC?

You can buy a Target or Walmart gift card and trade it for Bitcoin in https://cardforcoin.com/


A list of Bitcoin-related financial investment services:

http://en.bitcoin.it/wiki/Trade#Financial


What bitcoin is really easy to purchase and sale to the any person in cash?

There are millions of users of Bitcoin, who are interested in Bitcoin. If you want to sell your Bitcoin a year later, you will find a good buyer. When you want to sale it, maybe localbitcoins.com is a good choice. Millions of transactions are listed on this website. Buy some bitcoins, and then enjoy it. But first you need some knowledge about how to save your bitcoin by bitcoin-wallet. you can get started from here.

If you don't want use your own bitcoin-wallet, you can buy some bitcoin on a web exchange, like Poloniex or Bittrex, or you can choose a exchange by yourself, list of bitcoin-exchange.


If an address appears in the vout list, it is incoming for that address.

If the address is in the vin list, it is an outgoing transaction for that address.

Addresses may appear in both the vin and the vout.


Why is my pruned node downloading old blocks?

Pruning just means it doesn't store the blocks forever, but it still must download them all at least once to verify the chain and track the unspent outputs which form the UTXO set. Once the blocks are downloaded and verified then they can be automatically deleted


How many nodes have to confirm a transaction for it to go to a mempool? Or is it somehow based on hashing power?

None. The mempool is composed by unconfirmed transactions.

If you send a valid transaction to other nodes, the first node that receives can be a miner, then it puts on his/her mempool. Or it can send it to other nodes unit it eventually reaches a miner. There's no limit for how many nodes relay it.


Accessing a wallet from multiple devices

There is an Android version of Electrum. Just enter the seed words.


Once SegWit is implemented, could updated miners still choose to ignore SegWit transactions?

Transaction selection is up to the miners. The only mandatory transaction is the coinbase transaction (the transaction that collects the transaction fees and pays them out with the block subsidy as the block reward).

Besides that they may select anything between no transactions at all, over only regular transactions or only SegWit transactions, to the mix of all transactions that gives them the most transaction fees.


Simple, default, "hello world" smart contract for an auction? (winner wins, all the rest gets refunded)

If Bitcoin has smart contracts, I would like to see how to create a simple "hello world" auction - winner wins, those who didn't win get refunded.

Your question isn't clear about the details of how you would expect this to work, so I'll start with some assumptions:

The seller has put something up for auction. There are two possibilities: the item being sold is a digital asset native to the Bitcoin chain, or it is not.
The bidders are placing bids (assumedly using BTC, but any on-chain asset will do I suppose)
The 'auctioneer' that orchestrates all of this is some sort of 'smart contract', that sends the winning bid to the seller, the item sold to the winning bidder, and returns all other bids to the non-winning bidders, if necessary.

So the 'auctioneer' must be some bitcoin script, that is capable of determining the result of the auction. Here we encounter a problem: Bitcoin script does not allow us to create a transaction which considers the status of other transactions in order to determine how the transaction being created can be spent. In other words, you can't use Bitcoin script to create some logic that says "after some time, forward the largest payment sent to auction_address on to seller_address, and return all other payments to back to the non-winning bidders".

The 'smart-contracting' capabilities of Bitcoin Script are intentionally limited, to quote the article you referenced:

  Bitcoin’s solution to this problem is to simply not have Turing-completeness. This makes the contracts easier to analyze as the possible states of the program are easier to enumerate and examine.

All of that said, if we do not expect the entire logic of the auction to fit neatly into a single transaction's script, then we can perhaps use some more 'simple' constructions and protocols to accomplish our goal. For example, see this clever answer by Luke-jr. In this case there is no fancy smart-contract used, just financial incentives (to take the highest bid), coupled with consensus rules (a coin cannot be double-spent). This answer elaborates further on this type of construction.

More broadly, and as mentioned in the article you referenced, the oracle problem is a critical consideration: in order to participate in this auction, do you need to trust any third party? If the answer is yes, then it is prudent to consider if using a smart contract is a reasonable approach to solving your problem. For example, if the item up for auction is not a native digital asset, but is instead physically deliverable, then you need to trust the seller to deliver in any case!

All this isn't to say that Bitcoin script can't be utilized to create a 'better auction experience'. For example, by using a multi-sig constructions, bidders and auction-houses could enjoy a more trust-minimized set up of certifying and transferring funds to be used in the auction. But 'smart contracts' don't just magically enable us to 'make everything trustless', and indeed in many cases such a thing isn't possible anyways.

Additionally, it is possible to create a protocol that includes a Turing-complete language that runs on top of Bitcoin (eg the RSK EVM you mentioned), but this seems to be outside the scope of the question.


Bitcoin gone with "this transaction is not yet confirmed"

If nothing else in the help works, you can move your wallet to blockchain.info:

https://multibit.org/en/help/v0.5/help_movingAWallet.html


Self assembling of hardware for bitcoin mining

You can't build ASIC hardware yourself. It costs hundreds of thousands of dollars to develop an ASIC and, by definition, you can't buy them off the shelf. (The "AS" stands for "Application Specific", that is, it must be designed for a particular purpose.)


Which full node implementation(s) supports SegWit

Bitcoin Core has supported segwit for a long time and will have decent segwit support in the GUI/RPC in version 0.16 which is going to be released hopefully within the next couple of weeks. Knots also supports segwit, as does btcd I believe. Others like bcoin probably do too but I'm not sure, someone else might know better

You can look at this page for some general ideas: https://bitcoincore.org/en/segwit_adoption/


Output Descriptor for an Arbitrary Script

Output script descriptors do not currently support any arbitrary script. However once extended by Miniscript, descriptors will be able to support any script logically. Minscript is an extension of descriptors which allows for arbitrary scripts, within certain parameters. While you cannot specify any arbitrary script, you can use Minscript to create an arbitrary script that does what you want. This will not necessarily be the same as an arbitrary script that you come up with, but it will be logically identical.


Does BitMinter not use CPU's for mining at all?

GPUs are obsolete for mining. You won't get any reward worth even close to your electricity and hardware degredation cost. This has been true for over a year at least.

CPUs are 1000x more wasteful.

You're too late to the home-mining game.