How do I Base58 Checked encode / decode an address in C#? What does "normalize leading zeros" mean?

To normalize leading zeros is documented in this link, namely this text at the bottom:

  In a standard base conversion, the 0x00 byte on the left would be
  irrelevant (like writing 052 instead of 52) but in the BTC network the
  left most zero chars are carried through the conversion. So for every
  0x00 byte on the left end of the binary address, we will attach one
  '1' character to the Base58 address.  This is why the main-network
  addresses all start with 1.

The following code will address the GC issue with over-allocation and discarding of the String type, however it  does not properly handle the leading zero bytes.  I either need to find a list of expected lengths per type or some other approach.

    public static String sBase58Alphabet = "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz";
    public static String EncodeBase58(BigInteger numberToShorten)
    {
        // WARNING: Beware of bignumber implementations that clip leading 0x00 bytes, or prepend extra 0x00
        // bytes to indicate sign - your code must handle these cases properly or else you may generate valid-looking
        // addresses which can be sent to, but cannot be spent from - which would lead to the permanent loss of coins.)

        // Base58Check encoding is also used for encoding private keys in the Wallet Import Format. This is formed exactly
        // the same as a Bitcoin address, except that 0x80 is used for the version/application byte, and the payload is 32 bytes
        // instead of 20 (a private key in Bitcoin is a single 32-byte unsigned big-endian integer). Such encodings will always
        // yield a 51-character string that starts with '5', or more specifically, either '5H', '5J', or '5K'.   https://en.bitcoin.it/wiki/Base58Check_encoding
        const int sizeWalletImportFormat = 51;

        char[] result = new char[33];

        Int32 iAlphabetLength = sBase58Alphabet.Length;
        BigInteger iAlphabetLength2 = BigInteger.Parse(iAlphabetLength.ToString());

        int i = 0;
        while (numberToShorten >= 0 && result.Length > i)
        {
            var lNumberRemainder = BigInteger.Remainder(numberToShorten, iAlphabetLength2);
            numberToShorten = numberToShorten / iAlphabetLength;
           result[result.Length - 1- i] = sBase58Alphabet[(int)lNumberRemainder] ;
           i++;
        }

        return new string(result);
    }


How to query all utxos of an address from a full node?

There isn't really a way to do this efficiently, as Bitcoin Core is not designed for that.

You can search using the the scantxoutset RPC command, but all that is doing is iterating over the entire database and returning matching entries (it's more powerful than just by address though; it can for example search for an xpub + derivation path too).

There is some work around adding support for an optional (and separate) address-based index to Bitcoin Core, but that will at the earliest be for v0.21.

Other than that, there are a number of other software packages that can build such an index (independently from Bitcoin Core).


how to transfer genesis block reward for blackcoin?

The reward of genesis block is unspendable.

see https://en.bitcoin.it/wiki/Genesis_block


Ripple difference between source and destination tags

The ledger itself doesn't really care what tags you attach to a payment. They're just used to help exchanges or wallet services know who to credit for a payment.

The standard use of the a destination tag is to identify the recipient of a payment. The idea is that whoever or whatever controls the account that received the payment will look at the destination tag and know how to properly credit the payment.

While the source tag is rarely used, it serves a complementary purpose. Say Jeff has an account at exchange A and wants to send XRP to exchange B. He fills in exchange B's account and a destination tag that exchange B knows means to credit Jeff and asks exchange a to make the payment.

Now, suppose for some reason exchange B can't credit Jeff. Maybe his account his closed. Maybe he got the destination tag wrong. If exchange B doesn't know who to contact, they might try to return the payment. But if they just send it back to exchange A's account, how will they know to credit Jeff?

This is where the source tag comes in. If exchange A uses a source tag that it associated with Jeff's account in the payment, then exchange B can use that as the destination tag if it needs to refund, return, or partially refund the payment. It can use the incoming source tag as an outgoing destination tag and Jeff will get his XRP back.


Blockchain shows a confirmed order still "unspent". How do I reclaim Bitcoin thru Coinbase, so I can place order again

When a transaction output is labelled as "unspent" it means that it is still available for spending. Assuming that the transaction output went to your wallet, it means that your wallet still has that unspent available for spending.


The documentation is incorrect. confirmations, time and blocktime are not fields in the output of the rest API. You aren't doing anything wrong; those fields don't exist.


What is the minimum infrastructure necessary for Bitcoin to work?

In case for some reason the Internet stops working, Bitcoin could be incorporated into any transmission medium with enough throughput to at the very least support block propagation. This would require ideally 1MB of data to be propagated through the globe in under 10 minutes. The bare minimum might make it very hard for Bitcoin to work effectively, but media such as radio, telephone or the like could probably handle the Bitcoin load without much problem. Synchronising new people to the Network might be very resource consuming, but still doable.

In case the traditional means of sending information through the globe would become impossible, the Bitcoin Network would become too fragmented to be reliable. While one would still have access to one's Bitcoins locally, one could never be sure if they are dealing with the longest blockchain, thus double-spends could be a serious threat for any transaction, no matter the (local) confirmations.

In such scenario only dealing with Bitcoins that are already stored offline if form of physical temper-proof currency could be useful - Casascius coins for example. One could expect, however, that the coins would depreciate in value along with the exchange rate of (now useless) Bitcoins.

All in all, as long as you can send information around the globe at a decent speed, you can still use Bitcoins.


How does a miner know if a transaction has already been included in the block chain? Does he traverse through the complete chain to conclude this?

A miner checks whether all of the inputs of an incoming transaction exist in the UTXO set. If at least one doesn't, the transaction is necessarily invalid. This doesn't necessarily mean the transaction has already been included in the blockchain, it can also mean that that UTXO never existed or that it has been spend in a transaction which isn't the same as the incoming one.

A miner doesn't even have to traverse the UTXO set because there are smart things like hash maps.

A miner's main incentive to include transactions is the transaction fee. Of course, keeping Bitcoin going would also be nice but if there's money in the game, most people go for the money. This is why miners prefer to include transactions with a higher fee and why there are recommended fees for getting a transaction confirmed within a certain time frame. If you want your transaction to be included right in the next block, you should pay a fee high enough so that there are less than [1 MB - your transaction's size] of other transactions which are more profitable (more fee per storage space) than yours because 1 MB is the block size limit. If you got more time, you can choose a smaller fee because random fluctuations in the time which passes between blocks will cause there to sometimes be more and sometimes to be less competition for transactions to be included in a block and yours can make it into one when there is less competition a few hours in the future for a smaller fee.


Why Bitcoin does not user bcrypt for hashing?

Because Bitcoin didn't start out that way, and there is a lot of economic investment tied up in hardware that can only perform SHA256d hashes.


What does the 'Estimated BTC Transacted' value mean on blockchain.org?

From Blockchain.info:

  The total estimated value of transactions on the Bitcoin blockchain (does not include coins returned to sender as change).

The salient point in the above description is "does not include coins returned to sender as change".  Since there is no reliable way to definitively know what outputs are change outputs, there is no way to be 100% certain of the actual volume of BTC transacted.  Blockchain.info makes educated guesses about the likely change outputs, which it deducts from the total transacted to obtain the estimated BTC transacted value.

For instance, if you look at this transaction, you can see a single input of 0.565975 BTC, with two outputs, one for 0.00145 BTC and one for 0.56 BTC.  While it seems reasonable to assume the transaction "spent" 0.56 BTC, with "change" of 0.00145 BTC, it may very well be the other way around.  In fact, blockchain.info believes the 0.00145 BTC is the actual transaction amount, with 0.56 BTC being the change amount.


How much can you compress a bitcoin for storage?

"A bitcoin" is not really a single concept. A bitcoin can be composed of 1000 outputs worth 0.001 BTC each, or 1 output worth 1 BTC, or any other such combination.

Bitcoin outputs are linked to private keys (for standard outputs). There are many ways to derive and encode private keys, and each of them would certainly fit in 868 bytes. However, you would likely have to extract the key into another device to actually use to to access your coins, which could be a security issue. You will most likely be better served, and more secure, by buying a hardware wallet.


The blockchain is around 30 gigabytes. Unfortunately, if you want to use a full node client like bitcoind, you need all of that data. It's possible to prune the blockchain to just the unspent transactions, but the core devs have not implemented this yet on bitcoind. So no, you can't reduce the blockchain size as you need all of that data for a properly running bitcoind.

There are alternatives like electrum which use something called SPV to make the footprint of the application much smaller. This does require that you trust electrum servers, but it's very hard to fake that data, so it's fairly safe.


Who decides who verifies Alice's transaction?

Both are working on those separate blocks, and each block contains information about Alice's transaction and it is just a matter of luck which miner solves it?

Mining a block is basically a race, the successful miner is usually the first one to find a valid block and send it to the rest of the network. In one respect, there is some luck involved, because hashing is purely probabilities, it might take you only one attempt to find a valid block or it might take you quadrillions of attempts. But obviously the more attempts you make, the more likely you are to find a valid block, hence why more mining power generally means higher success rates.

Sometimes, two miners find a block at almost the same time and a small fork happens where some nodes see one block first and others see the other, but this is generally resolved as soon as the next block is mined, because the nodes will move to whichever chain becomes longer.


Importing private keys creates different address

Prepend "p2wpkh-p2sh:" to the private key before importing it into Electrum. For example:

p2wpkh-p2sh:5Kkzs8XrJNAmf9VQDFeGBfaRvSByAvPK6DbDXw5BVqswWaXSG2Y


There is no minimum amount. You can send 0.00000001 btc and even 0.0 btc without fees and there is a possibility that this transaction would be mined by some miner. But the probability is very low, because "standard nodes" (by bitcoin devs) do not relay such transactions.

You should add a fee if you want to send less than 0.00005xxx (I do not remember the exact value). The fee is 0.0001 per kb for clients running 0.8.x and 0.00001 per kb for clients on version 0.9.x

Here you can see transaction which transfers small amount of btc with a higher fee. https://blockchain.info/ru/tx/b07f23ce5d6a3746a3f8bd5202daa1084686812aa4ecce290208fbe84e68f564


Where can I find a full list of all Bitcoin mining hardware ever used?

https://en.bitcoin.it/wiki/Mining_hardware_comparison and https://en.bitcoin.it/wiki/Non-specialized_hardware_comparison are the canonical lists. I'm not sure that will be useful to you; there's approximately 940 products across the two lists.

If you're making a visual presentation of how mining hardware evolved, you might also find this thread useful.


Is it possible to create smart contracts on Graphene?

Graphene smart contracts are blockchain wide, meaning they require a hardfork to be deployed. The reasoning behind this is that every node operator can review the contract code, ok it and then democratically vote by joining the hardfork.

It's kind of a hassle compared to ETH/ETC but that provides a few choices of very well tested contracts.

OpenLedger has proposed an enhancement to BTS that would provide a VM like EthereumVM and allow users to easily deploy smartcontracts. It's still under discussion: https://bitsharestalk.org/index.php?topic=25187.0


You would be wasting your energy, because the network will simply ignore your blocks.

The rule in Bitcoin is that the best(*) valid chain is to be accepted by nodes in the network. If you add a block that contains an invalid transaction, nodes will discard your block (and any potential successors built on top of that block, even if those contain only valid transactions).

(*) best is defined as maximal sum of difficulties across all blocks in the chain. In case of ties, the first-received tip is used to pick a winner.


Spending own generated unconfirmed change in the v.0.9.0 era

It is basically never a good idea to be spending from an unconfirmed transaction, regardless of transaction malleability fixes or other improvements. Unconfirmed transactions are not final and thus you shouldn't be spending from them unless you are willing to take the risk that transactions in the unconfirmed transactions chain can become invalidated. Since a transaction malleability fix is not a consensus rule yet, transactions are still malleable (and can still be after segwit too) and can be vulnerable to transaction malleability attacks.

As with any other transaction, you should only spend from it after it has at least 1 confirmation.


Is the generator G of the keypair always the same number for all different tx messages in Bitcoin?

No sufficiently efficient algorithm for division is known. Multiplication over a closed group is a lossy process.

For an imperfect analogy, consider multiplication over the group of 100-digit numbers where you just keep the last 100 digits of the result. Since you don't know what digits were discarded, you can't naively reverse a multiplication.

The corresponding algorithm in DSA is modular exponentiation -- (G^X) mod n, which is also, for practical purposes with large numbers, irreversible even if G and n are known.


Is a private blockchain better in any sense than a database?

It depends on what you mean by "private". The word private is not really associated with Eris as far as I can tell. Rather, the word "permissioned" is used instead, and therein lies all the difference and your answer.

A "private" blockchain might imply a blockchain that is not shared with anyone. Such blockchains would effectively amount to slow databases and nobody would have much need for them.

Eris' value proposition over traditional databases is simple: integrity through cryptographically signed history.

What's stopping twitter from editing my tweets and making it seem like I said something I didn't say? Little to nothing.

This is where a blockchain approach comes in. If twitter stored tweets in a blockchain that others could copy, then any modifications that twitter made to this chain would be caught.

Blockchains preserve the integrity of the data within a database. They prevent people from cooking the books. This is of extraordinary importance and value.

Comparison to git

Git does not have a smart contracts system within its protocol.
Git is more of a filesystem interface, whereas Eris seems more like a database interface, to be used in environments where databases are sometimes used. Git is rarely used like a database.


On a shared wallet, if one of the recipients deleted their wallets off their phone, is there a way to rejoin?

Any money sent to a 2-of-2 multisignature address will be forever inacessible if one of the private keys is deleted (e.g. by uninstalling the phone app that holds them) and no backup was made and no recovery phrase was recorded.

There's a common aphorism that circulates in the bitcoin world in various forms, sometimes described as Bitcoin Rule 0

No private keys -- no Bitcoin
Not your private keys -- not your Bitcoin

The latter refers to web-wallets where the wallet-provider business holds the private-keys and their customers do not, or where an online "friend" creates a watch-only wallet for you. The first form of the aphorism is apt here.

One fifth of Bitcoin is permanently lost


tiny-secp256k1 and ECDSA signing determinism

The secp256k1 library uses RFC6979 to generate deterministic nonce values (k). It essentially takes the hash of both the private key and the message being signed in order to get k. This means that signing the same message with the same private key multiple times will always result in the same signature.

Other libraries may not do this. ECDSA only requires that k be a random integer (or rather that k is indistinguishable from random). So some libraries will simply generate a random k and use that. RFC 6979 is another way to generate a k that is indistinguishable from random, assuming that the hash function used is a pseudorandom function (meaning it's output is indistinguishable from random). The hash function used by secp25k1 is HMAC-SHA256 which is considered to be secure.


Here's the function that implements this. Each annotation refers to the line below.

unsigned int CalculateNextWorkRequired(const CBlockIndex* pindexLast, int64_t nFirstBlockTime, const Consensus::Params& params)
{

If we're on a network without retargeting, don't retarget.

    if (params.fPowNoRetargeting)
        return pindexLast->nBits;

Don't adjust up or down by more than 4x.

    // Limit adjustment step
    int64_t nActualTimespan = pindexLast->GetBlockTime() - nFirstBlockTime;
    if (nActualTimespan < params.nPowTargetTimespan/4)
        nActualTimespan = params.nPowTargetTimespan/4;
    if (nActualTimespan > params.nPowTargetTimespan*4)
        nActualTimespan = params.nPowTargetTimespan*4;

    // Retarget
    const arith_uint256 bnPowLimit = UintToArith256(params.powLimit);
    arith_uint256 bnNew;

Take the old nBits in compact form, and turn it into 256-bit form. I explain that in more detail here: Difficulty target representation in bitcoin wiki

    bnNew.SetCompact(pindexLast->nBits);

Multiply by the timespan (the time between the first block in the retargeting period, and the last block in the retargeting period.) Then, divide by the targeted timespan.

    bnNew *= nActualTimespan;
    bnNew /= params.nPowTargetTimespan;

If the result would be less than difficulty 1, change to difficulty 1 instead.

    if (bnNew > bnPowLimit)
        bnNew = bnPowLimit;

Re-encode as compact form for bignums. This is the reverse of SetCompact(int32_t).

    return bnNew.GetCompact();
}

Let's also work through the example you give. 0x1c05a3f4 should change to 0x1c0168fd.

0x1c05a3f4
1c          05a3f4
^ exponent  ^ mantissa

To decimal:

369652 * 256^28

Let's work out the timespans, actual and targeted

Actual: 1279297671 - 1279008237 = 289434
Target: 2016*600 = 1209600
Actual/Target ~= 0.239

Note that Target is more than 4x larger than Actual. We need to cap this, so we don't raise the difficulty too fast.

Capped timespan: Target/4 = 302400

Final calculation:

369652 * 256^28 * (302400/1209600) = 92413 * 256^28

Back to hex:

1c          0168fd
^ exponent  ^ mantissa

Re-encode:

0x1c0168fd

...and that is in fact correct.


What economics/finance methods and tools can be used to analyze and predict the Bitcoin market?

Technical analysis is important, but right now I think that one should not rely exclusively on chart analysis and indicators to predict Bitcoin's price movement. For example, at the end of July and mid-August some indicators, such as MACD or RSI, clearly showed a trend inversion that did not happen.

One of Bitcoin's unique features is the mining system and I think that, right now, this plays an important role in price analysis. After Bitcoin hit $30 in July, many people invested in mining rigs and difficulty rose a lot. Those people are looking forward to get their investment back and, since Bitcoin is extremely infalctionary right now (50 new coins every 10 minutes), there is a big selling force at the markets.
If miners sell 30 coins out of each block, we need around 1 million dollars per month to keep the price at $5.

I also believe that the $30 spike was caused by media exposure. Such a small market can be easily manipulated by a few serious investors.

Main points:

Use Technical Analysis carefully.
Consider the number of coins per block and the money invested by miners
Keep an eye for important news that may attract new investors to the market

To finish, here is one stock behaviour that I could identify: the dead cat bounce.

  A dead cat bounce is a trading term used to define when a stock in a
  severe decline has a sharp bounce off the lows.


I used Bitcoin-QT to send BTC and it never confirmed. I used the zap command and resent with maximum fees, still no luck

The fee you sent is 97 satoshi per byte, which is good enough to confirm your transaction with in 1 or 2 hours.

1 or 2 hours because there is a large number of unconfirmed transactions now. And several hundred transactions of them have a fee rate larger than your transaction's fee rate.

Your transaction should be confirmed now, please check it.


It's normal, because the number of transactions are bigger. The blockchain size is very big one, and it depends in your internet speed, it can take even 4 weeks to download the entire blockchain


Multibit backup created partial transactions

Try Tools -> Reset Blockchain and Transactions in the backup wallet.


How to handle a ridiculous amount of receiving addresses?

There's absolutely nothing you need to do per address, so the number of addresses has no effect. You only need to process each transaction.


Need to access remote bitcoin node for Lightning

Instead of completely opening up RPC ports to the whole internet, I would do something quite different. Here, you're relying on the strength of your RPC auth credentials and the implementation being bugs free. Bitcoind itself strongly discourages to do what was suggested in the other answer:
  -rpcbind=<addr>[:port]
   Bind to given address to listen for JSON-RPC connections. Do not expose
   the RPC server to untrusted networks such as the public internet!
   This option is ignored unless -rpcallowip is also passed. Port is
   optional and overrides -rpcport. Use [host]:port notation for
   IPv6. This option can be specified multiple times (default:
   127.0.0.1 and ::1 i.e., localhost)

I solved it on a network level: Since I have SSH port open anyway (though on a non-common port just for that extra little bit of obscurity on top of the obviously non-obscurity-reliant security), I opted for SSH tunneling.
LN Node
Basically I have a systemd service on the LN node that starts after boot and creates an SSH connection to my Bitcoin node. Through that tunnel, it can access the node's RPC port 18332 (testnet). The port is not exposed directly to the internet this way, instead only reachable via SSH.
The service is mostly stolen from https://avizard.blogspot.com/2021/01/aggressive-yet-sane-persistent-ssh-with.html.
$ cat /etc/systemd/system/autossh_systemd_unit.service
[Unit]
Description=AutoSSH service to remotely access RPC of Bitcoin node
#After=network-online.target
# Use this instead if autossh will interact with the local SSH server
After=network-online.target sshd.service

[Service]
User=[NONPRIV_USER]
Environment="AUTOSSH_GATETIME=30"
Environment="AUTOSSH_POLL=30"
Environment="AUTOSSH_FIRST_POLL=30"

ExecStart=/usr/bin/autossh -M 0 -N -q \
-o "ServerAliveInterval 10" \
-o "ServerAliveCountMax 3" \
-o "ExitOnForwardFailure yes" \
-p [SSH_PORT] -l [USER] [HOST] \
-i [SSH_KEY] \
-L 18332:127.0.0.1:18332 #sleep 10
# We set 'sleep 10' to make ssh exit in case no TCP connections are forwarded in 10 seconds.
# Useful to get remote shell exit codes.

ExecStop=/usr/bin/kill $MAINPID
ExecReload=/usr/bin/kill -HUP $MAINPID

Restart=always
# On Linux TCP_TIMEWAIT_LEN is not tunable and set to (60*HZ), about 60 seconds. TCP_FIN_TIMEOUT also defauls to 60 seconds.
RestartSec=60

# See systemd.kill(5)
KillMode=process

[Install]
WantedBy=default.target

Bitcoin Node
Additionally, the ufw firewall on my Bitcoin node only allows SSH access from 2 specific IPs which are the one which my Lightning node runs on and another one from which I manage my stuff.
$ sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
8333                       ALLOW       Anywhere                   # Bitcoin Mainnet
18333                      ALLOW       Anywhere                   # Bitcoin Testnet
[SSH_PORT]/tcp             ALLOW       [LN_NODE_IP]               # SSH
[SSH_PORT]/tcp             ALLOW       [MGMT_IP]                  # SSH
8333 (v6)                  ALLOW       Anywhere (v6)              # Bitcoin Mainnet
18333 (v6)                 ALLOW       Anywhere (v6)              # Bitcoin Testnet

Lastly, all users can only be logged into with autorized SSH keys and the LN node doesn't hold a key to a superuser account, instead the only user that machine (server) can always access is a non-privileged user. This means in case the LN node gets taken control of, my Bitcoin node is still fine.
$ cat /etc/ssh/sshd_config
[...]
Port [SSH_PORT]
[...]
PubkeyAuthentication yes
[...]
PasswordAuthentication no
[...]

Additionally, an IDS would be advisable on both machines, but the setup for that exceeds the scopes of this question.
I would be interested to hear what other options people use!


Creating blocks while more transactions arrive and proof of work mechanics

The miner picks what transactions they want to include in the block, out of the ones they have received when they start working on that block, yes. Once they start mining a candidate block, it's usually inefficient for them to add more transactions, so transactions received during the mining process are more likely to be included a block later. Once the block is mined, the list of transactions included in it are broadcast through the network so all nodes can see which ones were included, request any they don't have, and verify its a valid block.

The block header is what is hashed, it contains a version number, merkle root of transactions (basically a cryptographic summary of them all to commit to which ones are included), timestamp, the difficulty target, and the hash of the previous block. See: https://en.bitcoin.it/wiki/Block_hashing_algorithm


Unless you have your private key, you will not be able to access that address.


How do bitcoin merchants know that it was YOU that payed them

because they most likely generated a new address for you to send your payment to.  Since you're the only one that was given that address, when the payment comes in for that address, they know it was  you that paid it.


Can I build a mining ASIC from parts I find online?

Technically, sure, you can cobble together parts from bitcoin ASIC manufacturers and make your own farm.

Practically, you are better off going to one of the "something brand name" guys and getting a mining rig.  The bits and pieces that you see around on various auction sites are most likely out of date and will cost you more in electricity then you make (not to mention possibly faulty if they are selling them in bits).

Of course, depending on where you are, the chances are that even with the latest gear you won't actually turn a profit.

The mining industry is very cutthroat these days and profit margins are thin.  The rig turnover is also very high with miners replacing their rigs every 6-8 months in order to get the most efficient equipment.


Should USD savers be concerned about the rising popularity of cryptocurrencies?

Considering that the US dollar has lost 90% of its purchasing power over the last 100 years you should be worried regardless of cryptocurrencies.


Q: What happened to CPU and GPU mining?

A: Their efficiency makes them irrelevant in the bitcoin mining world today

and the author has no interest in supporting alternative coins that are better

mined by these devices

from https://github.com/ckolivas/cgminer/blob/master/README


Once your logged in go to Security Center and then you will see a tab which says Advanced API key Creation click on that and you will see the permission options, a key name field, and a key generation button.


The IRS just issued a preliminary ruling on this and it will be treated as property.  The Q&A portion is particularly useful.

SECTION 4. FREQUENTLY ASKED QUESTIONS

Q-1: How is virtual currency treated for federal tax purposes?

A-1: For federal tax purposes, virtual currency is treated as property. General tax principles applicable to property transactions apply to transactions using virtual currency.

Q-2: Is virtual currency treated as currency for purposes of determining whether a transaction results in foreign currency gain or loss under U.S. federal tax laws?

A-2: No. Under currently applicable law, virtual currency is not treated as currency that could generate foreign currency gain or loss for U.S. federal tax purposes.

Q-3: Must a taxpayer who receives virtual currency as payment for goods or services include in computing gross income the fair market value of the virtual currency?

A-3: Yes. A taxpayer who receives virtual currency as payment for goods or services must, in computing gross income, include the fair market value of the virtual currency, measured in U.S. dollars, as of the date that the virtual currency was received. See Publication 525, Taxable and Nontaxable Income, for more information on miscellaneous income from exchanges involving property or services.

Q-4: What is the basis of virtual currency received as payment for goods or services in Q&A-3?

A-4: The basis of virtual currency that a taxpayer receives as payment for goods or services in Q&A-3 is the fair market value of the virtual currency in U.S. dollars as of the date of receipt. See Publication 551, Basis of Assets, for more information on the computation of basis when property is received for goods or services.

Q-5: How is the fair market value of virtual currency determined?

A-5: For U.S. tax purposes, transactions using virtual currency must be reported in U.S. dollars. Therefore, taxpayers will be required to determine the fair market value of virtual currency in U.S. dollars as of the date of payment or receipt. If a virtual currency is listed on an exchange and the exchange rate is established by market supply and demand, the fair market value of the virtual currency is determined by converting the virtual currency into U.S. dollars (or into another real currency which in turn can be converted into U.S. dollars) at the exchange rate, in a reasonable manner that is consistently applied.

Q-6: Does a taxpayer have gain or loss upon an exchange of virtual currency for other property?

A-6: Yes. If the fair market value of property received in exchange for virtual currency exceeds the taxpayer's adjusted basis of the virtual currency, the taxpayer has taxable gain. The taxpayer has a loss if the fair market value of the property received is less than the adjusted basis of the virtual currency. See Publication 544, Sales and Other Dispositions of Assets, for information about the tax treatment of sales and exchanges, such as whether a loss is deductible.

Q-7: What type of gain or loss does a taxpayer realize on the sale or exchange of virtual currency?

A-7: The character of the gain or loss generally depends on whether the virtual currency is a capital asset in the hands of the taxpayer. A taxpayer generally realizes capital gain or loss on the sale or exchange of virtual currency that is a capital asset in the hands of the taxpayer. For example, stocks, bonds, and other investment property are generally capital assets. A taxpayer generally realizes ordinary gain or loss on the sale or exchange of virtual currency that is not a capital asset in the hands of the taxpayer. Inventory and other property held mainly for sale to customers in a trade or business are examples of property that is not a capital asset. See Publication 544 for more information about capital assets and the character of gain or loss.

Q-8: Does a taxpayer who "mines" virtual currency (for example, uses computer resources to validate Bitcoin transactions and maintain the public Bitcoin transaction ledger) realize gross income upon receipt of the virtual currency resulting from those activities?

A-8: Yes, when a taxpayer successfully "mines" virtual currency, the fair market value of the virtual currency as of the date of receipt is includible in gross income. See Publication 525, Taxable and Nontaxable Income, for more information on taxable income.

Q-9: Is an individual who "mines" virtual currency as a trade or business subject to self-employment tax on the income derived from those activities?

A-9: If a taxpayer's "mining" of virtual currency constitutes a trade or business, and the "mining" activity is not undertaken by the taxpayer as an employee, the net earnings from self-employment (generally, gross income derived from carrying on a trade or business less allowable deductions) resulting from those activities constitute self-employment income and are subject to the self-employment tax. See Chapter 10 of Publication 334, Tax Guide for Small Business, for more information on self-employment tax and Publication 535, Business Expenses, for more information on determining whether expenses are from a business activity carried on to make a profit.

Q-10: Does virtual currency received by an independent contractor for performing services constitute self‑employment income?

A-10: Yes. Generally, self‑employment income includes all gross income derived by an individual from any trade or business carried on by the individual as other than an employee. Consequently, the fair market value of virtual currency received for services performed as an independent contractor, measured in U.S. dollars as of the date of receipt, constitutes self‑employment income and is subject to the self-employment tax. See FS-2007-18, April 2007, Business or Hobby? Answer Has Implications for Deductions, for information on determining whether an activity is a business or a hobby.

Q-11: Does virtual currency paid by an employer as remuneration for services constitute wages for employment tax purposes?

A-11: Yes. Generally, the medium in which remuneration for services is paid is immaterial to the determination of whether the remuneration constitutes wages for employment tax purposes. Consequently, the fair market value of virtual currency paid as wages is subject to federal income tax withholding, Federal Insurance Contributions Act (FICA) tax, and Federal Unemployment Tax Act (FUTA) tax and must be reported on Form W-2, Wage and Tax Statement. See Publication 15 (Circular E), Employer's Tax Guide, for information on the withholding, depositing, reporting, and paying of employment taxes.

Q-12: Is a payment made using virtual currency subject to information reporting?

A-12: A payment made using virtual currency is subject to information reporting to the same extent as any other payment made in property. For example, a person who in the course of a trade or business makes a payment of fixed and determinable income using virtual currency with a value of $600 or more to a U.S. non-exempt recipient in a taxable year is required to report the payment to the IRS and to the payee. Examples of payments of fixed and determinable income include rent, salaries, wages, premiums, annuities, and compensation.

Q-13: Is a person who in the course of a trade or business makes a payment using virtual currency worth $600 or more to an independent contractor for performing services required to file an information return with the IRS?

A-13: Generally, a person who in the course of a trade or business makes a payment of $600 or more in a taxable year to an independent contractor for the performance of services is required to report that payment to the IRS and to the payee on Form 1099-MISC, Miscellaneous Income. Payments of virtual currency required to be reported on Form 1099-MISC should be reported using the fair market value of the virtual currency in U.S. dollars as of the date of payment. The payment recipient may have income even if the recipient does not receive a Form 1099-MISC. See the Instructions to Form 1099-MISC and the General Instructions for Certain Information Returns for more information. For payments to non-U.S. persons, see Publication 515, Withholding of Tax on Nonresident Aliens and Foreign Entities.

Q-14: Are payments made using virtual currency subject to backup withholding?

A-14: Payments made using virtual currency are subject to backup withholding to the same extent as other payments made in property. Therefore, payors making reportable payments using virtual currency must solicit a taxpayer identification number (TIN) from the payee. The payor must backup withhold from the payment if a TIN is not obtained prior to payment or if the payor receives notification from the IRS that backup withholding is required. See Publication 1281, Backup Withholding for Missing and Incorrect Name/TINs, for more information.

Q-15: Are there IRS information reporting requirements for a person who settles payments made in virtual currency on behalf of merchants that accept virtual currency from their customers?

A-15: Yes, if certain requirements are met. In general, a third party that contracts with a substantial number of unrelated merchants to settle payments between the merchants and their customers is a third party settlement organization (TPSO). A TPSO is required to report payments made to a merchant on a Form 1099-K, Payment Card and Third Party Network Transactions, if, for the calendar year, both (1) the number of transactions settled for the merchant exceeds 200, and (2) the gross amount of payments made to the merchant exceeds $20,000. When completing Boxes 1, 3, and 5a-1 on the Form 1099-K, transactions where the TPSO settles payments made with virtual currency are aggregated with transactions where the TPSO settles payments made with real currency to determine the total amounts to be reported in those boxes. When determining whether the transactions are reportable, the value of the virtual currency is the fair market value of the virtual currency in U.S. dollars on the date of payment.

See The Third Party Information Reporting Center, http://www.irs.gov/Tax-Profession..., for more information on reporting transactions on Form 1099-K.

Q-16: Will taxpayers be subject to penalties for having treated a virtual currency transaction in a manner that is inconsistent with this notice prior to March 25, 2014?

A-16: Taxpayers may be subject to penalties for failure to comply with tax laws. For example, underpayments attributable to virtual currency transactions may be subject to penalties, such as accuracy-related penalties under section 6662. In addition, failure to timely or correctly report virtual currency transactions when required to do so may be subject to information reporting penalties under section 6721 and 6722. However, penalty relief may be available to taxpayers and persons required to file an information return who are able to establish that the underpayment or failure to properly file information returns is due to reasonable cause.

source: http://www.businessinsider.com/irs-bitcoin-is-property-not-currency-full-release-2014-3?op=1


Would it be possible to retarget difficulty in real time?

It's a security property that the difficulty is not retargeted quickly, not a technical or design limitation. It prevents a case where you can isolate a node, or a portion of the network, wait a brief period, and then mine at a vastly lower difficulty in order to defraud those users. If the mining rate drops, the fees rise, and more miners are incentivized to join the network- it's a self balancing system.


Why does getblocktemplate use priority for transaction selection?

Getblocktemplate builds a block based on configuration parameters. In recent versions, the default is to use fee per byte as criterion for the entire block.

History

In versions of Bitcoin up to 0.6, priority based selection was used for the entire block. It was a means to encourage the young Bitcoin economy to grow. However, it also had a minimum transaction fee that increased as the space in blocks grew closer to the limit.

In version 0.7 the -blockprioritysize setting was introduced, which divided blocks in a priority area and a fee area. The priority area was there to support a small number of low-fee transactions to continue, and was limited to 27 kB by default (50 kB since version 0.9). The fee area is sorted by fee per byte, and maximizes total fees for miners.

Recent versions

In Bitcoin Core 0.12 the default setting for the priority size was reduced to 0. It also introduced a more efficient algorithm for selecting transactions, which works suboptimally for the priority area.

In the upcoming Bitcoin Core 0.13 release the algorithm selection algorithm will be improved again and use Child-pays-for-parent (CPFP) logic. This logic uses fees from unconfirmed descendant transactions to determine whether to include parents. It increases the total fees that can be taken compared to the previous algorithm, and allows wallets to increase fees on a transaction by spending its change outputs with higher fee.


I want to transfer my bitcoin but i cannot

Uneconomical UTXO requested

This usually means the amounts you are trying to send are so incredibly tiny that the transaction fees will cost more (perhaps much much more) than the amount being sent.

See dust

See helpful comments to other similar unanswered questions:

cant send btc, Uneconomical UTXO requested
Uneconomical UTXO requested

Maybe its like using DHL or FedEx to send a small piece of a 1 paisa coin to someone.


How to check if raw transaction is signed?


Tracking Hash/sec of major pools and individual (solo) miners

How about http://blockorigin.pfoe.be which aims to provide a reliable source of information by scraping pool web sites to see which pool claims ownership of each and every block (hence avoiding the problem that Peter Wuille mentions).

See https://bitcointalk.org/index.php?topic=78391.0 for discussion.


Receiving payment in Lightning Network is a big problem?

I would like to be able to receive LN payment on online shop. In order to do this and in my understanding, I have to either

wait until my customers fund channels to me, or

find a node that already has many channels and get it connect to me with an ample amount of cap.

This is correct, but there are other options as well. For example, you could open a channel of your own, and spend some funds on LN. Your customers would then be able to spend funds back to you, until your channel balance is pushed back to you entirely.

But to answer your question, I think it is more helpful to consider the situation in this way:
When a user is going to make a payment using BTC, they may consider these two options:

Send an on-chain transaction
Open a LN channel (likely, for an amount in excess of the payment requested).

For anyone that wants to transact on LN, there is a requirement to acquire control of a LN channel. So users will have to open channels, and thus I think assuming that opening a channel with your shop is an unnecessary burden isn't quite correct. The first user to interact with your shop will have to open a channel, but then they will reap the benefit of being connected to the LN, in that they will be able to send & receive subsequent payments on the network.
The network's utility should increase greatly as more users join and use it. The bootstrapping phase does present a bit of a 'chicken-and-egg' problem, but any user that is motivated enough to participate will be ready to pay the costs of opening a new channel, so I don't believe it will be a critical issue in the long term. I also see no reason to assumer that 1 LN user = 1 LN channel, in reality I think many users will have multiple channels, as defined by their usage habits.
Perhaps also worth mentioning: viewing all merchants as as 'receive only' entities is probably not perfectly correct either, as I see no reason merchants couldn't also utilize LN to make payments of their own. You're right that LN isn't perfectly suited to a situation of 'making payments to an endpoint, that cashes out to dollars', but I see no reason to assume that all merchants would participate in this way.


Difference between originator of transaction and owner of the source fund

if Alice pay to Bob 0.1BTC, is that transaction signed by Alice?

Yes.

If I understand your quotation correctly, Andreas Antonopoulos is saying that Alice's personal assistant Charlie, could have prepared the transaction without any signature and passed it to Alice for approval and signing.

I don't know which wallets support this kind of arrangement. For most of us the preparation and signing are all handled together at the same time.


Have the users share a group, and write a wrapper it even a plugin to change the group and permissions on the rpc file. That's the normal Unix way...


Combining a Bitcoin transaction with one address holding USDT, but no BTC and using another address with BTC to pay for the fees?

You don't need to do anything special to make this work. The omni protocol allows you to have a second input to the transaction to pay for fees.

When you received the USDT, your first address should have at least a little bit of BTC in it. If you have already spent that, you will need to transfer a little more.

If not, you can consume that tiny input, and an input from a different address, and make a regular omni output + change to any address.

Unfortunately, to my knowledge, no omni wallet supports this kind of transaction, so you will have to build the rawtx using Bitcoin Core or Omni Core and sign it appropriately.


Is it still possible to recover Multibit Classic wallet from multibit.key file?

did you try the -md5 flag, the openssl decryption changed a few years back and the md5 flag should solve it


bch transfered to cashadrrs instead of legacy

It should show up in your Ledger.

Cashaddr is a representation of the underlying hash for that address. Each BCH address has a legacy and a cashaddr format. In your case, it is simply likely that the block explorer Coinbase links to defaults to showing the cashaddr format. There are explorers which will show you both, such as blockchair.

For instance, looking up the address 1FPS2Y71KhNQbugjMxAGKwsUFNbvfsYm2h on blockchair will show you it's cashaddr representation as well, which is qzwulnvalvs6gwfy9t7gz5qxs22t9fag45tpcgu32g. Funds sent to either of the above will be accessible by the same private key, in a wallet following either format. Both addresses refer to the same underlying script.


To include details from your comment: you were trying to send coins from your account at some sort of online marketplace.

Losing coins because of an address typo is generally not supposed to happen; however, preventing it requires that the marketplace has designed their software properly.  The fact that it got as far as it did suggests that they have screwed something up.  Whether the coins are actually lost is something you have to find out from them.

It will help to explain a little about the Bitcoin address mechanism.  A standard Bitcoin address (1xxxxx...)  has encoded within it a 160-bit public key hash, and a 32-bit checksum (actually computed via another hash).  When software wants to send coins to an address, it should normally:

decode the pubkey hash and checksum
verify that the pubkey hash and checksum match
generate a transaction sending out the desired number of coins, listing the pubkey hash as the destination (the checksum is not used after this point)
post this transaction on the Bitcoin peer-to-peer network
wait for the transaction to be confirmed.

In order for the recipient to eventually spend the coins, they have to be in possession of a private key whose corresponding public key has the same 160-bit hash as contained in the address.

Step 2 is where your typo should have been caught (barring extremely bad luck; see case 1 below).  After this point, no more checking is possible: there is no way for anyone to determine whether a given 160-bit string corresponds to a private key, unless they know what the private key is.  I would think any reasonable software design would perform step 2 as soon as you typed in the address, display an error, and refuse to proceed until a corrected address was given.  The fact that this didn't happen is a bad sign; it suggests that the marketplace's software is not well designed.  But we don't know what it actually did do.

So there are a few possibilities for what happened:

You were extremely unlucky, and your typo'ed address decoded to a hash and checksum that matched each other.  The probability of this happening randomly is about 1 in 4 billion.  You can check whether this is the case by entering your typo'ed address in a block explorer site like http://blockchain.info and seeing if you don't get an error message.  In this case, the marketplace may have gone through the whole process described above, and sent coins to a hash that doesn't correspond to your private key.  The transaction would be valid and been confirmed, but in this case the coins are now lost and nobody will ever be able to claim them.  If so, the marketplace should be able to give you a transaction ID for the transaction they created; you would be able to independently verify that the transaction exists, was confirmed, and corresponds to your erroneous address.  There isn't anything the marketplace can do to avoid this case (except maybe asking you to type the address twice).
The marketplace performed step 2 at a later stage of their processing, and discovered the error in your address.  In this case, they never created a Bitcoin transaction; they still have your coins, and should be able to re-credit your account.  Ideally they would do this automatically, but you might have to ask.
The markeplace decoded a hash from the address you gave, but never performed the step 2 check, and instead created a transaction sending coins to the incorrect hash.  Like in case 1, the coins are now lost, and they can send you a transaction ID which proves it (you can compute for yourself what the incorrect hash is, and verify that the transaction sent coins there).  Unlike case 1, this case would clearly be the marketplace's fault, for not performing the step 2 check which would have caught the error.  The right thing for them to do in this case would be to refund your coins out of their own pocket.  Of course, they may or may not actually choose to do that (especially if they are "shady").
The whole thing was a sham; the marketplace made it look like they were sending you coins, but in fact had no intention of actually doing so.    There isn't much you can do in this case except to try to pursue legal action (good luck with that).


Is there really a limited supply of bitcoin?

You can't go into an "infinite" amount of decimal places. The smallest unit of Bitcoin is the satoshi, which is 0.00000001 bitcoin.

There will be a total of 2100000000000000 satoshi.


What permissions should wallet.dat have to be as secure as possible and still work?

The bare minimum permission would be to have it owned, and only accessible to, a user you specially create for bitcoind. At least for creation, and addition of new addresses for change, it will need to be not only readable but also writable. I am not sure if you can make it non-writable for as long as you have not exhausted the unused addresses in it.


Send coins with Electrum from encrypted wallet created with Bitcoin Core

Every wallet can create it's own way of storing data. There's no protocol in bitcoin,that defines the way, how a wallet is structured. In your case it might be best to extract the private key, and load it into Electrum, like here:

http://docs.electrum.org/en/latest/faq.html#can-i-import-private-keys-from-other-bitcoin-clients


How to move only "blocks" and "chainstate" folders on an external USB hard-drive while running Bitcoin Client on connected laptop with Ubuntu?

The easiest way to do this according to the Bitcoin Core Wiki is to append the datadir option after running bitcoind to launch the client according to the following syntax:

bitcoind -datadir=/media/myusername/backup/.bitcoin

example provided thusly:

bitcoind -datadir=/media/alexanderjsingleton/SEAGATE/.bitcoin

Also, don't forget to mount the external USB hard-drive by using the ls -l /dev/disk/by-uuid/ option by command line or by GUI-method.


How does a miner’s pubkey get passed into miner.cpp?

Bitcoin Core does not set the payout address. It can only do that when you use the internal miner (i.e. use the generatetoaddress command, but only on regtest). Otherwise, external mining software sets the address. This is because Bitcoin Core does not just send a complete block that the mining software just works on.

Rather, those mining software use the getblocktemplate RPC which returns a block template. This template does not include a coinbase transaction. It just includes information necessary to construct the coinbase (such as amounts) as well as the transaction data to include in the block. But it is not a block itself and the external miner still has to construct their own coinbase transaction and block given the information in the block template.

So Bitcoin Core cannot force an external mining software to use a particular output script in the coinbase transaction. You have to configure your mining software to do that.


double spending , you can create money out of thinner air

To double spend BTC, you need to make one transaction to the person meant to receive the money, and one transaction to an address you control yourself. This would typically be another address in your wallet. The two transactions would spend the same bitcoins, but send them to different addresses. Those transactions would look like completely normal transactions.

Now, you will not be able to create any new bitcoins. Because the same money is spent twice, only one of the transactions can be accepted into the blockchain. That's why one should wait for confirmations before accepting BTC as payment, as there's no guarantee for which transactions will be accepted in the next block and which transactions won't.


How to make a simple payment with the python-bitcoinlib?

I just added sendtoaddress to bitcoin.rpc.Proxy:

from bitcoin.core import COIN, b2lx
import bitcoin.wallet
import bitcoin.rpc
try:
    # This moved between versions
    from bitcoin.base58 import CBitcoinAddress
except:
    from bitcoin.wallet import CBitcoinAddress

rpc = bitcoin.rpc.Proxy()
addr = CBitcoinAddress('1JwSSubhmg6iPtRjtyqhUYYH7bZg3Lfy1T')

txid = rpc.sendtoaddress(addr, 0.001 * COIN)
print(b2lx(txid))

Note quite as simple as bitcoinrpc, but that's the trade-off for having proper types and so forth.


Keep Wallet Safe While Entering United States

The Trezor (and other hardware wallets) use the BIP 39 specification for the recovery mnemonic. If your device is confiscated, you can use the recovery mnemonic to restore your wallet to another Trezor, hardware wallet, or software wallet. From there you can access your Bitcoin.


Library for generating HD keys/addresses (ideally for python)

Actually python library pycoin seems to be sufficient for both testnet and mainnet address. I had just missed it the first time I checked the library.

It also provides a powerful command line tool.


If you are only interested in the balance of multiple addresses I would suggest you use the following call in stead:

https://blockchain.info/balance?active=1NiNja1bUmhSoTXozBRBEtR8LeF9TGbZBN|1MrkWMnWLW53SQVQ5Pd2BsugY1F8H1oKio

But if you need to use multi address the limit flag seems to be wrong in the documentation, it should be 'n' and the minimum limit allowed seems to be 1. 0 will just return all transactions anyway.

https://blockchain.info/multiaddr?active=1NiNja1bUmhSoTXozBRBEtR8LeF9TGbZBN|1MrkWMnWLW53SQVQ5Pd2BsugY1F8H1oKio&n=1


What do the indicator lights mean on USB Block Erupter ASICs?

A steady light means no connection to the server delivering work, a short blip means the device has found a difficulty one share for submission. At the current time submitting a single difficulty one share is worth about about 0.000000035 BTC.


BTC-e funding/withdrawal methods. Anybody tried any of these?

I am using perfectmoney there for funding there and it goes always instant to get credit my account balance, i think that is nice method to use there.


Is it true that if I buy Bitcoin and plan to hold it for 10 years and sell, then Coinbase, Robinhood, or Gemini can prevent any theft?

It is said that Bitcoin can be subject to being stolen if I have it in my wallet on the smartphone, and is more secure in the Ledger.

That is wrong. They are both "in the Ledger".
Although we speak of having money in a wallet, in reality the money is all kept track of in the blockchain (which is more like a transaction journal than an accounting ledger). The only important information in a wallet is a secret number known as the master private key.
So the money is in the same place regardless of whether you use a wallet to control your money yourself or whether you give all your money to some business in return for an IOU that just gives the illusion of owning money.
If the business has the secret key on their computer - you have to hope their computer isn't hacked, is well-managed and that the business doesn't have a dishonest owner, dishonest employees or dishonest office cleaners.
If you have the secret number on your computer, you have to take care that your computer isn't hacked, you have to make backups and look after them.

is more secure in [a hardware wallet]

Yes, a hardware wallet such as the Trezor Model T or Ledger Nano are among the safest places to store a private-key. You still need to make a secure copy of the recovery-phrase in a separate and safe place. You still need to practice recovery.

if I buy it using Coinbase, Robinhood, or Gemini, ...  and suppose the account itself is not hacked, does that mean it is quite safe against theft?

History demonstrates that exchanges are not quite safe against theft
Although it depends what "quite safe" means to you.
See the story about Quadriga-CX. I'd say look at MtGox and all the others but for many of these we can't tell if they were hacked or if the owners colluded in the theft. Prior to failure, many of these were either the most trusted exchange in existence or among the most trusted.
You also open up another attack vector - access to your login credentials entered via your computer or phone (or cybercafe WiFi).
You might think big exchanges employ a lot of security experts, however their information systems complexity and security problems are much larger in scope than yours are when running a single-person's wallet on one device.
General advice is not to keep any money on exchanges that you are not currently actively trading.


Would it be a good idea to have several different *coin to protect oneself from fluctuations?

I don't see how different coins would protect against volatility, as Bitcoin is by far the leading cryptocurrency, and the others (even all of them combined) are really totally insignificant in terms of market cap and trading volume.

If you want to protect against volatility (given that you measure volatility in terms of value expressed in fiat currency), there's two options:

use Coinapult Locks
keep part of your money in fiat

Simple as that. Seriously, just not investing part of your money in something is the best and easiest way to suppress its volatility.


Would a transition to a different signature scheme be feasible?

Well, for starters I must say that the problem with ECDSA nonce can be avoided even when using ECDSA via the same method used in Ed25519, and indeed this method is not even novel to Ed25519. But, let's assume we need to change the signature algorithm for some reason.

OP_CHECKSIG does not support different key types per se. The public key given as input is either an uncompressed or compressed EC point, starting with 0x04, 0x03 or 0x02. Any other starting byte could be used for different transaction types, if desired. However, a separate opcode would (IMHO) be cleaner.

The only required changes are on the script side, either modifications to OP_CHECKSIG opcode or the introduction of a new opcode. And after this, miners need to start accepting transactions containing the new style signatures as "standard" scripts.

All "full" bitcoin clients verify all transactions that are present in a block (run all scripts). This means that they will refuse to accept a block that can not be verified (even if it only has one transaction failing verification). This means that if such a change is incorporated, the block chain will fork for the clients that do not support such transactions.

Nearly all clients will need to support the new signatures and the clients that do not will become unusable when encountering the first block that has a transaction with a new signature.


MultiBit developer here.

You'll need to use MultiBit Classic version 0.5.19 available as a download from the site https://multibit.org. This will allow you to open the .key file and synchronise with the block chain to recover all the funds associated with the private keys held in the file.

Once you have imported the keys, we strongly recommend that you upgrade to a HD wallet. The instructions to do so for MultiBit HD are here: https://multibit.org/en/help/hd0.2/how-to-upgrade-from-classic.html.

Essentially, you download MultiBit HD (the two can sit side by side without interfering with each other) and then spend from Classic into HD.

Always keep hold of your private key files in case someone spends to an old address.


Bitcoin's goal is a decentralized democratic value system.

It absolutely is not. A democracy is a system where the majority of participants can decide for everyone.

In Bitcoin, nobody can decide for you. A Bitcoin node will verify all blocks and transactions that others produce. It does not at any point what other participants in the network think or do, if they don't agree with the rules you enforce, they simply don't exist from your point of view. In other words, in Bitcoin, your choice of participation is choosing the rules the system has. If you disagree with those rules, you are effectively on a chain fork - which is essentially its own currency.

There is one exception to this everyone-validates-everything model, and that is double spending. If someone produces two conflicting transactions (which spend the same money) and broadcasts them on the network, the system somehow has to make a determination about which of the two is to be accepted. There is no objective rule that everyone can enforce here. You can state that the first one is to win, but unfortunately due to the finite speed of light, it is impossible for geographically distributed entities to jointly come to the same conclusion about who was first. To solve this problem, miners are introduced. Their only power is cooperating to building up versions of history, resulting in the ability to decide the ordering and timing of otherwise valid transactions, up to and including the power to delay transactions indefinitely.

For miners, hashpower majority matters. But this is not a democracy (it is not one miner one vote, it is one hash one vote), and they do not set the network rules through it. All they can do is either cooperate, or disrupt. The system is designed so that disruption is less profitable than cooperation.

Now, your main concern stands. Centralization of power in mining is a dangerous trend, as it gives small groups of actors a large power to disrupt.


Help with bitocin.conf - how to configure a testnet full node in a safe way?

You should use the one provided in the Bitcoin Core repository which you have linked above. That one has everything disabled by default (so only defaults are used and it will run fine out of the box and use the mainnet). All of the options that you are going to ever use are listed in that conf file with instructions on what they do and how to use them. They're all commented out.

  Maybe, I have to put it in another format, since it is meant to be a conf file for the bitcore implementation

You will need to do that because that format of conf file (JSON format) is not supported by Bitcoin Core.

The questions you asked regarding the bitcore conf are completely irrelevant to Bitcoin Core as it does not support those options.

Alternatively you can use this Bitcoin Core configuration file generator which lets you choose the options you want to enable and it will generate the file for you.


Can there be a blockchain without mining?

I don't know anything about Multichain so I'm not sure if this is the answer you're looking for, but here's one answer that might help you.

The interesting thing about proof-of-work (Nakamoto) blockchains is that they enable a constantly-changing set of unknown nodes on the internet to achieve consensus under certain assumptions about the adversary (i.e., the good guys are more "powerful" than the bad guys).

Before Bitcoin, no one knew how to do this (AFAIK) and all consensus algorithms required that the participants were known and that 2/3 of them were honest. Typically, an admission control process was used to decide who could participate and who couldn't. This was, for the most part, a human process.

Now, blockchains solve this very hard problem of permissionless consensus: How can you agree on a log of operations among N participants as they leave and join the system, without an admission control process? The answer: Use a little bit of economics to incentivize participants to behave correctly, no matter who they are (i.e., Bitcoin).

Now, with this understanding of the hard problem Nakamoto blockchains solve, you can image that a system such as the one you propose (if I understand it correctly), where users have to trust you to correctly dictate consensus, is not that interesting nor useful. It is well known how to achieve consensus with trust: just use any Byzantine agreement protocol and keep 2/3 of your nodes honest.

I am not sure if I properly understood your question and your system, so I hope this answer is not completely useless to you.


If your test coin source code has the same regtest mode as bitcoin, you can use that, it allows you to mine blocks instantly and it's a completely separate chain to the testnet or mainnet so it won't affect anyone else. You can run your coin with the -regtest argument, and then use the generate RPC to mine blocks and see how much reward you get. Note that in the source code, the regtest reward halving may be (and probably is) a different number of blocks to mainnet, this can be changed in chainparams.cpp


Is it safe to rent server to run a full node?

If you need only to receive bitcoins, or better only to check the balance of your wallet, you can setup a read only address that leave no way to send money through this server.
To setup read only addresses there are several command:
importaddress
importmulti
importpubkey
Instead if you need a full node that receives and sends bitcoins automatically, (despite the fact that the encryption is secure) the wallet cannot be encrypted and it can be risky (at least more than having physical possession of the server) and you have to evaluate if the savings of buying a VPS instead of a physical server compensate for the greater risk of theft.


How exactly does short selling with Bitcoins work?

Short selling is essentially an agreement between you and Bitcoinica where Bitcoinica pays you if the BTC/USD price decreases, and you pay them if the price increases, in an amount equal to the price difference multiplied by the number of bitcoins you sold short.

Presumably you trust Bitcoinica to hold up its end of the deal, but they don't know you and don't trust you, so they require you to make a deposit which they deem more than enough to be able to cover your obligations. It may happen that when the price changes they are no longer confident your deposit is enough; they will then do a forced liquidation, settling the agreement up to this point and only allowing you to make a smaller agreement going forward.

The deposit can be in either BTC or USD. If you have BTC, however, you may want to consider first selling the BTC (which is functionally equivalent to taking a short position), which may be done cheaper than in Bitcoinica, and then short-sell on Bitcoinica.

An alternative view of short-selling is that you borrow bitcoins from Bitcoinica, offering a deposit as collateral, and then selling them. With Bitcoinica out of the picture for now, short-selling can be done by literally finding someone to borrow bitcoins from.

You can also learn more about Margin trading in general on Wikipedia.


how can i coding wallet to build exchange to client withdraw

The most secure way is running your own full nodes per Blockchain.

Using third-party services such as blockcypher will put you & your business at high risk because of:

You're giving the keys to your home & revealing the password of your bank account to someone else! Because in order to use such services, they are the one who make the public & corresponding private keys for you. Even though particularly Blockcypher claims that they will never store your keys, relying on it (I'm not blaming them!) is a risky approach by design!
You won't be able to participate in verifying transactions on your own & maybe you're part of some attack (e.g. 51% attack even though its very unlikely).
You're centralizing the technology that has come into existence for the sake of decentralization!

If there was high costs or too steep learning curve on running your own full nodes & connecting to, Maybe using provided interfaces (e.g. JSON/RPC for bitcoincore) was a reasonable way to start with, & switch to your own nodes during next steps, But as there is no such barrier, you'd better launching your own nodes.


What happens when the verification of a manipulated transaction fail?

Nothing prevents a miner from creating a fork which contains invalid blocks. However just because they are in a blockchain does not mean that everyone will accept them. All of the other full nodes on the network (including other miners), will receive the block containing the invalid transaction and reject the entire block as invalid. So that block will not become part of their main chain and neither will any block built on top of it, regardless of how much work it has. So a malicious miner could do that, but the invalid block wouldn't become part of the Bitcoin blockchain and every other full node would just reject it and ignore it.

The miner could continue to mine this invalid blockchain. But if no one uses it, then his coins on that chain are valueless and thus the miner would be losing money to continue to mine it.


You do not understand correctly how does bitcoin network work. Your first transaction was sent to a network and will live there until all it is valid or all nodes forget about it.

Blockchain.info just notifies you that it was not confirmed into a block in reasonable time. Blockchain.info removed it from its memory, but there are nodes on the network which do not forget about it and one of them broadcasted this transaction to its peers.

  Why have both transactions the same ID?

These are not two transactions. This is one transacton, received by blockchain.info twice. First time you sent it. Second time blockchain.info received it fron one of peers.

  Why do Blockchain.info automatically create a transaction without asking the user?

They did not.


There was a transaction spendable only by someone who provided the double hash of the genesis block. How was that transaction created?

This transaction is described quite well on the wiki.

https://en.bitcoin.it/wiki/Script#Transaction_puzzle


Bitcoin-Qt listing all Transactions as occurring at same date and time

I've also had the same issue whereby importing a private key using RPC Console importprivkey will rescan and tag it with the time which the rescan takes place in btc-qt.

Even Multibit which uses the following format for private key (*.key) files is only dated such that the date corresponds to what is assumed to be the key's creation date:
Kwnononok7xQwSNIPSNIPSNIPSNIPssthcheckth1s 2013-09-18T09:42:28Z

As mentioned, the Blockchain is not being consulted for transaction history - a major flaw IMO.


How long it takes to mine them all?

DogeCoin has a block time target of one block per minute. According to its bitcointalk thread it follows a block reward schedule where the first 100,000 blocks get a random reward between 0 and 1,000,000 dogeCoins and every subsequent 100,000 blocks halves the of the previous reward's maximum.

Beginning with the 600,001st block, the reward will be a constant 10,000 dogeCoins per Block until the maximum of 100 billion dogeCoins is found.

Since there is a random process underlying, it is not possible to accurately predict which block will provide the last scheduled block reward until the first 600,000 blocks have been mined, however, the first 600,000 blocks should produce an estimated ~98.44 billion dogecoins, so there would be about 156k blocks with a 10,000 doge reward.

At 1 minute per block, 756k blocks would take 525 days, or just shy of 1.5 years.

  Is this measure accurate?

Yes. According to dogechain.info also, 21.45 billion dogecoins (21.45%) have been mined.

  When all dogecoins have been mined, how can transactions happen?

In short: Mining rewards are composed of both the block reward and transaction fees. The transaction fees will remain, and should suffice to reimburse the miners to continue just as before.
Please refer to Will the proof of work system end when all bitcoins have been mined? for a more comprehensive answer.

Update: Flat 10k reward forever

On February 1st, 2014 the Dogecoin developers announced that Dogecoin would not be capped at 100 billion dogecoins after all, but would continue to have a flat 10k dogecoin reward for each block after Block 600,000.


When you trade on an exchange where does the bitcoin or other crypto go to

I believe exchanges mostly hold Bitcoin in addresses that belong to the exchange, not to their customers.

This has benefits for them:

They can then transfer Bitcoin amounts between different accounts for users of their service without the need to create any Bitcoin transactions and pay associated mining fees.
They can then create aggregate Bitcoin transactions which reduce transaction fees when paying to non-customers or into wallets not controlled by the exchange. For example they can create one transaction with one input and ten outputs instead of ten transactions each with one input and one output.

There are implications for the customers of the exchange

The exact details will depend on exactly which "exchange" you are using and may change over time.

If you use the "exchange" to pay BTC to someone who is not a customer of the same "exchange", there will be a record in the blockchain but it may not be possible to identify which customer of the exchange initiated the transfer.

If you use the exchange to buy BTC with USD or ETH, or vice versa, there will generally be no transaction recorded on the blockchain if, as many do, they keep your account balance and other details in a database that is completely separate from any actual cryptocurrency-wallets.

This is analogous to the distinction between a "custodial-wallet" and a desktop-wallet. WIth the first you are not the actual owner of any Bitcoins, you are effectively the creditor of a debt denominated in Bitcoins.


Do we know who runs the big mining pools?

This list is not exhaustive, and the information is based on bitcointalk and coindesk discussion and articles. As of 1 Dec 2014, based on pool stats from few websites including https://blockchain.info/pools

GHASH.io is at 13 % , it is based out of Europe.
GHASH is closely related to CEX.io BitFury, Jeffrey Smith is the technical person at CEX.io.
Eligius 4 % is operated by Luke.Jr
Discus Fish 25%  is based out of china & coowned by Wang Chun.
Megabig power 2% in Washington operated by Dave Carlson.
KNC 8% is based out of Sweden , Sam Cole & Marcus Erlandsson.
Cointerra 2%  is based out of Texas. Timo Hanke & Ravi Iyengar.


How can one redeem a Casascius Physical Bitcoin?

The first 8 characters of the public address are on each coin, which allows you to obtain the full address or check the balance at FirstBits or a similar service. Beneath the tamper-evident holographic sticker on each coin is the private address which corresponds to the public address. Once you've obtained both the public and private address, the process for importing this information into an existing wallet has already been documented in this prior question.

Edit: On a side note, it's probably worth noting that this process is almost identical to the process used to redeem BitBills

Edit 2: Apparently these coins use a different private key format than standard. Casascius has published a utility to convert these private keys to standard addresses and more about the "mini private key" format can be found at the wiki. For those lacking a copy of Visual Studio, I've compiled a copy for your convenience. These keys may also be computed using any calculator or code capable of generating an SHA256 hash:

SHA256("S4b3N3oGqDqR5jNuxEvDwf") = 0C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D

Of course that's still in hex and needs to be converted to Bitcoin's modified Base58 but many wallet import tools will accept hex as well.

Edit 3: Just heard from Casascius that we may be able to redeem these coins, as well as any device bearing a mini private key directly at MtGox in the near future.

Edit 4: Support has officially been added


How does the Blockchain detect a cheater, who manipulates the blockchain?

What you are describing is a textbook example of a 51% attack. Bitcoin protocol is designed to accept the chain that has the most proof of work (most often this is same as the longest chain). If a miner needs to change block 90, he will have to recalculate hashes starting from block 90-100. To make his attack successful, the miner will have to mine blocks faster than the rest of the network so that he can broadcast the longest chain which then gets accepted by the network. So, probabilistically this would mean the miner should be in control of >50% of the total hashing power, so that he can mine blocks faster than rest of the network combined.


Is there a maximum fee per byte in satoshis?

Yes you can, there is no maximum limit for the fee. The fee is simply the difference between the sum of the input values and the sum of the output values, so if you wanted to donate 99 BTC to the miners there is nothing stopping you - no idea why you'd want to donate an entire house though ;)


Is the asymptotic performance of bitcoin O(n) relative to the block chain length?

You have to traverse entire blockchain. At the lowest bitcoin level there is no accounts, there is concept of "unspent output". Bitсoin clients (excluding light versions) should support index of all transactions with unspent output, in order to validate transactions quickly. That means bitcoin clients doesn't actually scan entire blockchain, they just know balance of all accounts.

You are right, it can cause scalability problem, if bitcoin become more valuable, and count of transactions with unspent output will grow very quickly.


Sending bitcoins to a "Sending address" in Bitcoin Core

In Bitcoin Core, the sending address refers to the address that you have saved as a "contact" in the client. You can save the address with a nickname eg. Coinbase address.
The receiving address refers to the address which you can use to receive coins. The way Bitcoin works is that a transaction spends the unspent output from the receiving addresses. Hence, it depends on which receiving address you received coins from, your coin control and amount.

E.g.
1. If you receive 1BTC on 1AddressA and spend 1BTC in the client, the blockexplorer will identify the origin as 1AddressA.
2. If you receive 0.5BTC and 1 BTC on 1AddressA and 1AddressB respectively and you spend 0.5BTC, the blockexplorer will identify the sending address is 1AddressA.
3. If the scenario is the same as 2, and you spend 0.6BTC, the sending address will appear as from both and there will be another output going to another address in your client. It is called the change and the address isn't showed within the client. However, you can spend it in your next transaction, I don't know why there's no balance but what I know that the transaction to these addresses shouldn't appear as they are change addresses.

Why are they not on transactions list?

Because Bitcoin core using bip32
and change addresses transactions have different derive path.

Example

m / purpose' / coin_type' / account' / change / address_index
Normal addresses path:

m/44'/0'/1'/0/i

Change addresses path:

m/44'/0'/1'/1/i


BTC Purchase - How To Invest For Capital Growth

You should not hold your coins in your coinbase (or any other exchange for that matter) account for extended periods of time. If you are only looking for a long term investment, you should transfer all your coins off of the exchange.

If you are looking to participate in higher frequency trading that involves day-to-day trading activity you should set a side a certain amount of money (or BTC) to do that with and leave only that much on your coinbase account at a time. The main "base" of your holdings should be taken off the exchange as soon as it is available and stored by you in paper storage or some sort of secure wallet that you have complete control over. If you store your BTC in keys that you alone control, you can rest assured that it is as secure as the entire bitcoin network itself. If you leave them on coinbase you are trusing coinbase with your money, and although coinbase is a "reputable" entity in this space, their future actions are totally unpredictable and you may not be protected by a justice system in the event of your funds being compromised


How to sweep a bc1... bitcoin segwit address using a mobile app?

You can use Bitcoin Wallet (F-Droid, Google Play) to sweep a paper wallet, including its bc1 (Bech32) address.


The QR code your friend sent you encodes a bitcoin address, which your wallet will use when creating a transaction that will pay your friend. So if you re-used the old QR code, that just means you sent BTC to the same address your friend wanted you to use in the past.

If your friend no longer has access to the private key for that old address (ie, he is locked out of the wallet for whatever reason), then they will be unable to spend the BTC you sent. The only way to recover those BTC, is to get access to that wallet/private key again.

  I do not believe that he cannot access that QR from just a few weeks ago.

You'll have to decide whether you trust this friend or not. It's difficult for me to say what the nature of the issue is on his end, but given the level of responsibility a bitcoin user must have in order to  secure their funds, it is not exactly routine to just 'lose access' to a wallet. Normally, it is recommended that every effort be taken to ensure you can securely maintain access to your wallet. If you don't, and access is lost, then your coins too will be lost forever.


How can I measure the total hashing power of the Bitcoin network?

Network hashrate calculated using formula: H ~= h / t , where t is time that took to find X number of blocks and h is approximate number of hashes it should have taken to solve X number of blocks, h = X * (D * 2**256 / (0xffff * 2**208)) Wiki:Difficulty

Bitcoin network hashrate stats available at bitcoinwatch.com and bitcoincharts.com .


You can take advantage of Blockchain.com's API (formerly Blockchain.info).
You can access BTC blocks based on their block height via a URL of the form https://blockchain.info/rawblock/<height+1>. We use <height+1> because 1 is used as the index of the genesis block, which is instead usually referred to as block 0, as it is defined to have a height of 0.
By default, this endpoint provides a JSON dump of the data in the block, but you can get the raw block data as a hexadecimal string instead by appending the query string ?format=hex. For example, https://blockchain.info/rawblock/2?format=hex will give you the data in the block after the genesis block (the block with height 1) as a hexadecimal string.
The block header is 80 bytes, or 160 nibbles (hexadecimal characters), so you can e.g. use curl to fetch the data, and then head to truncate it to just the header, and then save that hex string to a file:
curl 'https://blockchain.info/rawblock/2?format=hex' | head -c 160 > block-1.txt

You can use a simple Bash script to automate this for all blocks:
#!/bin/bash

latest_block_height=670288

for ((i=0; i <= latest_block_height; i++)); do
    if ! [ -f "block-$i.txt" ]; then
        curl 'https://blockchain.info/rawblock/'"$(($i + 1))"'?format=hex' | head -c 160 > "block-$i.txt"
    fi
    echo "Downloaded block $i."
done


How can I create a multi signature 2-of-3 transaction?

Actually, both receiving funds at and spending funds from a multi-sig address is already supported.

You can find the code to do so, plus comments, by Gavin:

TwoOfThree.sh


if my wallet is sufficiently secure, can I ever lose my coins?

I'll go through your question clause by clause:

  I've made an offline address

You're doing good.

  and only have the key stored on 2 encrypted flash drives stored in different locations

As long as only you know the password and the password is sufficiently strong, this is probably secure.

  with the private key written physically on paper and stored in 2 locations.

If either of these two locations are accessible by anyone other than you, then they are vulnerable. If someone else found either paper, and your keys are in plain text, then you could consider them compromised.

  Do I ever have to worry about my coins?

Yes.

  That is, could they ever be lost in software changes

Extremely unlikely, as the whole of Bitcoin depends on the safety of balances through upgrades. There are people who have very vested in ensuring that this never happens. Even a bug in the protocol could not erase history in an unrecoverable way, as a single offline client copied online or bootstrap.dat would refresh anyone affected.

  or is that as big of a never-going-to-happen as the 21 million limit being lifted?

Pretty much.

  I'm pretty sure I'm not touching that wallet for a long time. Is there any benefit to repeating this process for a more "fresh" address ever or does that not make sense?

Theoretically, you would never need to regenerate keys unless some kind of vulnerability was found in the software that generated your key, ala the Android random number generator flaw.

An unlikely occurrence would be some kind of change to the way private keys are imported, and your private key generated in 2013 cannot be securely converted to whatever format is expected in 2063, or whenever. I wouldn't get too paranoid about this.


Why is using a simple SHA1 in a scriptPubKey to emulate a "password" a security problem?

A simple Google search for eb271cbcc2340d0b0e6212903e29f22e578ff69b will reveal the preimage to you.


What standard is used for the ECDSA to verify transactions?

I just found the answer from https://en.bitcoin.it/wiki/Protocol_specification#Signatures:

  For ECDSA the secp256k1 curve from http://www.secg.org/collateral/sec2_final.pdf is used.

i.e. the curve is

  y^2 = x^3 - 7

and the prime

  p = 2^256 - 2^32 - 2^9 - 2^8 - 2^7 - 2^6 - 2^4 - 1.

See here for more information.


No. The whole point of Bitcoin is that it is decentralized and there is no single corporation behind it.


Bitcoin has already been recognized as a currency by many nations for quite some time. But that's only a prerequisite. It previously was seen as as commodity by many nations which in a lot of tax systems has a very bad implication:

If you buy something like food or electronics, that's a commodity. If you pay it with a currency, you have to pay sales tax for the value of the commodity you sold or bought (depending on the tax system). Now hat if instead of trading currency against commodity, you trade commodity against commodity? Can you evade sales tax by this? Of course not, the makes of tax systems thought about that and in most cases implemented a law making it highly undesirable to trade commodity against commodity: Sales tax has to be paid for both commodities which were exchanged so you basically have to pay twice the sales tax if you don't use a currency.

With bitcoin being recognized as a currency by many nations, this problem vanishes. However, it still doesn't mean that it's widely known and used which are the real factors for success. Of course, if payments in bitcoin are more widely accepted, demand for bitcoin rises which increases the bitcoin price because bitcoin is non-inflationary.

However, it is reasonable to assume that governments aren't exactly in favor of bitcoin becoming more widely accepted because it makes it harder for them to monitor and control the flow of money. As a government, you can force banks to tell you about all bank remittances. You can also add serial numbers to bank notes and force banks to tell you when which serial number was given out or taken in by which branch of which bank by which person. In bitcoin, money isn't associated with people's names and addresses except if this information can be derived from other information. This makes monitoring the flow of money considerably harder.

Furthermore, right now, governments can force banks to make money of certain people unspendable (to "freeze"/block accounts). This gives them great control but isn't possible with bitcoin.

Bitcoin doesn't enable you to not pay taxes. If your employer pays you in bitcoin, they and you will have to pay the same amount of taxes and whether these taxes are paid to the state in bitcoin or that state's fiat currency, doesn't really matter for the concept of it. The state you live and work in decides how much you have to pay in taxes, not the currency you're using.

However, just because your government can (and will) still force you to pay taxes (which are needed for a functioning society, after all), doesn't mean they have great control over bitcoin. Something like what you mean with "to be set a government control over it", isn't possible because it would require a national entity to be able to declare a block invalid if it contains a transaction it declared invalid. In bitcoin, the the longest valid block chain defines the history of transactions and who has control over how much money which ultimately is whether a money transfer was or wasn't executed.

In particular, the longest valid block chain defines how much money you have. If the government wants to make a transaction of money I sent to you invalid, it has to persuade the miners to not view the longest valid block chain as the effective block chain but the longest one which doesn't contain that transaction. A government can't make everyone do that. It can force the miners in the area it controls to stop mining on top of the (for everyone else) effective blockchain and make then fork their own one. But their's will just have no value as it isn't accepted by the people. If many governments do that by force (has to be done by force) in a joint effort, that would just be them making mining of bitcoin illegal, therefore restricting their peoples' freedom to a great extend. Would you want to live under a government which tells you which computations you can and cannot execute?

Ergo, governments can't control bitcoin. The best they can do to control it is to make it illegal.


Is mainline Bitcoin planning on switching to deterministic wallets?

It seems very likely, however it also seems to be a fairly long-term goal with no ETA as of yet: https://github.com/bitcoin/bitcoin/issues/5761


scriptsig-not-pushonly (code 64) during send transaction in regtest

One of the standardness rules (relay rules) in Bitcoin Core is that the scriptSig must contain only operations that push data to the stack. Since you have actual opcodes that do non-push things, this transaction is non-standard so your node is not accepting it.

On regtest, you can disable standardness checks by adding -acceptnonstdtxn to your startup command.


I have not tried it myself, but Peter Todd has a python script called dust-b-gone.py

https://github.com/petertodd/dust-b-gone


I made a payment of bitcoin into escrow for services that were not delivered and bitcoin not returned

You can contact the service provider, and the escrow agent to request a refund, but beyond that there is likely nothing that can be done. If you have lost a substantial amount of money, you could file reports with your local law enforcement agency, but understand that there is almost no chance they will be able to help you recover the funds.

Bitcoin transactions are not reversible, once confirmed several blocks deep in the blockchain history, the chance of that transaction being removed or replaced is basically zero. The only way those funds can be returned, is if the person who now controls them decides to send a transaction paying you back.

Sorry for your loss here, it is unfortunate to hear that even after employing an escrow agent, your trade did not go as planned.


Reject transaction because of illegal data

There have been miners that rejected transactions with OP_RETURN because its unnecessary spam. Virtually every node and miner limits OP_RETURN outputs by size.

The amount of data relayed or allowed by default is not very large, one of the reasons for this is reducing drama about "illegal data".

We've come up with even stronger techniques that could be used to prevent the inclusion of arbitrary data in transactions, if it were ever required.

But the idea the some invisible data squirreled away in an inaccessible location would be legally dubious seems impractical at least for small amounts of data: consider, any text could secretly convey a small amount of data-- so a hard-line adherence to that theory of liability would make it impractical to ever publish any text provided by a third party. I think there would be a creditable argument that in the US any law which attempted to do so would be invalid on its face by outright inhibiting the press.


bitcoin-cli "error: couldn't connect to server"

The --* arguments to bitcoin-cli should come before the RPC command. Those arguments are for bitcoin-cli itself. However the position you put them in are positions for the getinfo RPC command and not bitcoin-cli. You should instead be using the following command:

.\bitcoin-cli.exe --rpcport=54352 --rpcuser=admin --rpcpassword=admin123 getinfo


What is the NAT traversal technique used by bitcoin

Is this automatic opening mentioned actually UPnP way?

Yes. UPnP is disabled by default in Bitcoin Core due to some vulnerabilities in UPnP. You can enable it by going to Settings > Options > Network and checking Map port using UPnP

  And manually configuring the router actually bullet 1 mentioned above?

Yes.


The time between consecutive blocks follows the exponential distribution, with mean (roughly) 10 minutes. This means that the variance is 100 minutes^2.


Can a bad actor omit an unspent address from a pruned chain?

This is precisely why Bitcoin Core does not support pruning in this manner. However this does not always need to be the case. There are people working on things like UTXO set syncing where each block commits to the UTXO set as of that block. You can then use that to be sure that you have downloaded the proper blockchain.


Were bitcoins automatically converted to Bitcoin Cash?

BCH is basically a copy of the blockchain up until the point of the fork so all BTC on the bitcoin blockchain have an exact copy of BCH on the BCH blockchain. That means if you held BTC at the time of the fork, you get an equal amount of BCH as well - you have both. Yes, they are different currencies with different prices, and you can buy and sell them completely separately from each other


How can I find out who sent me bitcoins?

how can I find out who sent them?

Realistically, you cannot. You could see which inputs were used in the transaction that sent you the bitcoins, and attempt to find their owner. But there is no information encoded into the transaction that states who sent it.

If you met someone that claimed they were the one to send the coins to you, then you could ask them to sign a specific message of your choosing, with the private key of one of the transaction's inputs. Whoever sent the coins to you will have access to at least one of those private keys, so they would be able to prove themselves in this way.


Difference between RPC calls addmultisigaddress and importaddress

The difference between these two is that with addmultisigaddress, bitcoind stores the redeem script and the second one, bitcoind has no idea what the redeem script is and only stores its hash (which is essentially the p2sh address).

For watching the address, the two are essentially equivalent since you'll still know when bitcoins get sent to that p2sh address. The redeem script is necessary if you want to spend from the p2sh address to some other address. Even if you had the private keys in the multisig p2sh address, you wouldn't be able to spend it using importaddress since you still need the redeem script in order to be able to spend it.