How much can I earn with AntMiner S7 miner

Well, BTC limitation is not a true. But yes, sha256 world is not quite big.
Mining btc on antpool will give you basic statistic, it's depends on your local costs and power limits more than the your Antminer can do)

Ok, I have custom build S5 with 4 hash boards that can provide ~2Th on freq@275(this is my own limitations).

Okay back to PnL, so I'm able to mine ~0.001/day BTC on antpool.
Then I moved to multipool and started mining alt coins that provided much more profits for me, depends on coin ~ ~0.002-0.004/day BTC
https://www.multipool.us/dashboard/pools/sha256

You may try to find another alt coin pools, but keep in mind your antminer works with SHA-256 algorithm only.

Hope it helps.


lncli pendingchannels output: difference between `pending_closing_channels` and `waiting_close_channels`

Found an answer for this by asking the slack community:

pending_closing_channels: waiting for confirmation blockheight after cooperative closing and publishing on the blockchain (standard case)
waiting_close_channels: closing request being processed
'pending_force_closing_channels': waiting for confirmation blockheight of unilaterally closing the channel (Commitment Transaction)


How to verify a signed message by bitcoin core?

The preimage used when signing messages with Bitcoin Core is a combination of the "Magic" phrase: Bitcoin Signed Message:\n and the Message you are signing. However there is one caveat, being you must have a VarInt prepended to both the "Magic" and the Message. The VarInt encodes the byte-length of the message (encoded in UTF-8). Since the "Magic" value never changes, its VarInt value will always be 0x18.

For your example, the message is nothing, therefore your VarInt will be 0x00. Your preimage and sighash becomes:

Preimage: 0x18426974636f696e205369676e6564204d6573736167653a0a00
Sighash: SHA256(SHA256(preimage)) = 0x80e795d4a4caadd7047af389d9f7f220562feb6196032e2131e10563352c4bcc

    0x18       0x426974636f696e205369676e6564204d6573736167653a0a        0x00      (empty)
MAGIC_VARINT                       MAGIC                           MESSAGE_VARINT  MESSAGE


There is P2Pool and Pushpool being the two options to get your own pool running.

These provide the backend services, the GUI must be built by yourself with any features you may wish to include.

The former is almost unused at this time, although considered to be more resilent to attacks (such as DDOS)

If you were to consider running a pool the requirement of a very high bandwidth server is needed as it consists of using a LOT of traffic (depending where your located this may be VERY difficult to find)

Building a user base may be difficult but with merged mining it may increase profit for running such an enterprise.


Can Multibit be used as an offline cold storage solution similar to a setup with Bitcoin-QT?

MultiBit cannot do true cold storage where your transactions are signed offline and then you transport them to a different machine and broadcast them.

The underlying library, bitcoinj, does support it but it is not in the user interface.

If the size of the blockchain is the main factor, Electrum might be worth looking into. I am pretty sure you can sign a transaction, move it and broadcast it on a different machine. I think this is done on a command line.

It is still several months away but a nice solution will be Trezor where the signing is done on a hardware device and the host machine is used to broadcast it. I believe all of MultiBit,  Electrum and Armory are planning to support Trezor.


Where are the Main network magic bytes stored in bitcoin's source code?

See the file chainparams.cpp in the constructor for class CMainParams:

pchMessageStart[0] = 0xf9;
pchMessageStart[1] = 0xbe;
pchMessageStart[2] = 0xb4;
pchMessageStart[3] = 0xd9;


Will an approved Bitcoin-like system replace Bitcoin?

It's near certain that other Bitcoin-like currencies will continue to be introduced from time to time. Some of them will likely gain some traction.

Over time, more and more deficiencies of Bitcoin will become apparent and newly-designed competitors will be able to fix them. While Bitcoin can certainly make some changes, it will always have a trade-off because significant changes risk shaking to confidence of current users. At some point, Bitcoin's accumulated deficiencies will be too much and it will lose significant share to some competitor.

Of course whether that will be next year or next century, I don't think anybody knows.

Some such systems will likely coexist with Bitcoin without much interaction. Others may design in interaction with Bitcoins directly into their fundamental design. Nobody has a crystal ball though.

Some have imagined high-speed, high-volume systems that would move Bitcoins outside the regular blockchain with the existing Bitcoin system used only to "settle up" large transfers between smaller, faster systems. Will that be what happens? Who knows?


How is mining profitable if a $10.000 ASIC will generate like $63.23 per month?

That particular miner is way overpriced.  Nobody should buy it at that price.  The seller either listed an incorrect price, or is very confused about the current market for mining hardware, or is hoping to find a customer who is a sucker.

For comparison, the Antminer S5+ has a (claimed) hash rate about 7x higher and costs about 1/4 as much, making it about 28 times more economical.


When you don't explicitly specify any RPC credentials, bitcoind will autogenerate them for you and store the password in the $DATADIR/.cookie file.

You can then use the username __cookie__ along with the password from that file.


Although those particular CPUs aren't listed, you can infer from the other CPUs in that table that the hashrate will be only a few Mhash per second. CPU mining isn't cost effective today. (Which is why the list of hash rates for CPUs is fairly out of date.) See also this question about whether CPU mining is worth it.

To answer your follow up from the question comments, it's not entirely clear how ASICs will change mining because the number of ASIC machines shipped has been so limited.  If ASIC vendors could deliver in volume at the promised amounts of GHash, yes, they would probably be the only lucrative way to mine going forward. But all predictions regarding the future of mining have to be taken with a grain of salt: it's always hard to predict the future. The end of GPU mining has been predicted for a couple years now, but the rising exchange rate has been keeping it alive.


ERROR: ReadBlockFromDisk: Errors in block header at CBlockDiskPos(nFile=0, nPos=8) in altcoin

The error means that your genesis block has an invalid Proof of Work.


Profit by programming a Bitcoin service (wallet) in an "only-now" bc adopting country?

Use your domain to sell bitcoins for fiat in your country. That's the most profitable thing you can do.


What does it means "get a new address and then make the Bitcoin offline" and make it extremely secure?

Bitcoin wallets never contain money. The only important content is one secret number. This secret number is called a private-key. In most current wallets, the secret number is instead a seed from which a series of private keys are generated in a predictable (deterministic) way.
The only place you can find out how much money you control is in the public replicated journal of transactions called the blockchain. Every wallet has a copy or access to a nearby copy. Blockchain explorers let you search their copy.
You see how much money you have by making a list of the addresses* your wallet created and looking through the whole transaction journal for mentions of those addresses receiving or spending money and add up the amounts. Subtract the debits from the credits to calculate a balance.
The Bitcoin network doesn't encrypt any data.
You use a new receiving address for every transaction so that senders can't see what other money has passed through your address. For privacy.
You use offline wallets for security - a wallet on a computer that is connected to a network can potentially be hacked into. especially if it is a computer you also use for browsing web-pages and for downloading and playing games. An offline wallet in a computer that is never connected to a network is much safer.
All well-formed addresses are valid. They are just large numbers, all large numbers are valid (you may have to add a few checksum digits) but almost all of these large numbers will never be used because there are so many of them.
You don't have to publish addresses explicitly or separately, you just use them in transactions. Unlike street addresses, Bitcoin addresses do not identify people or locations - they are just a random-looking number without any special meaning. You don't have to claim ownership of an address. You can use mathematics to prove you know a secret number (private key) from which that address was derived. The proof doesn't disclose the secret number. The proof is what allows you to spend money, it doesn't matter who you are. The Bitcoin network doesn't keep accounts for people.
A Hierarchical Deterministic (HD) wallet creates new private and public key pairs as needed (usually a few in advance of need) from one master private key.
Your wallet will take care of all these details for you.

Related

Is each Bitcoin address unique?
What's stopping someone from taking over all the bitcoin addresses?
Can two private keys generate the same (public) Bitcoin address?
Can Bitcoins be duplicated if two private keys share the same public key?
Theory: brute-force key search


If the computer calculation rate becomes 100x faster, would the value of bitcoin drop to 1% of the previous value?

TL;DR: Change of computer calculation power doesn't affect the price at all.

Market Price of anything determined by supply and demand, bitcoin is not exception the only difference is that the supply side is constant, 50 BTC per ten minutes at the moment. Regardless of how much computer power used to generate bitcoins the rate of produced bitcoins will not change because Bitcoin network difficulty will adjust to make it harder or easier to find new bitcoins depending on total network computer power, bitcoin price change purely because of change of demand.

Also there is a controversy about certain aspects of Bitcoin, but there is no designing flaws that I know of.


Altcoin peers do not sync with each other

Solution found!
Bitcoin client use checkpoints to prevent 51% attack. What are checkpoints?

Modifying checkpoints in chainparams.cpp solve this sync problem.


Does P2SH unlocking script only consist of operants?

Can I put common operants and operators in the P2SH unlocking script?

No, you can not.

1) Unlocking script ( scriptSig ) should contain only push operations, yours contains OP_CHECKSIG

2) It has no sense to put signature sig2 into the redeem script and check it with OP_CHECKSIG because such script definetely fail on execution. If you want to put any data in the redeem script - you can do it in other way.


What is the meaning of "service bits" in Bitcoin?

The service bits are a field in the version method which indicate what services a node supports. These services are features that a node supports and tells other nodes which connect to it what it may or may not be able to request from the node. They also indicate what that node can receive.

For example, if a node has the NODE_SEGWIT service bit set, then when another node connects to it and they see NODE_SEGWIT, they know that they can send segwit blocks and transactions to that node, and can expect to receive segwit blocks and transactions from that node. If they did not see NODE_SEGWIT, then they would know to strip segwit blocks and transactions of their witnesses before sending the transaction to that node.


After generating my own private key, what's the proper way to add it to official wallet software?

In Core, go to "Help" and "Debug Window". Go to the console and type importprivkey [key]. This might also interest you: How do I import a private key into Bitcoin-Qt?


Where could I post an article about Electrum to get it reviewed?

I would try posting it to /r/electrum, /r/bitcoin, or the Electrum section of BitcoinTalk.


What was the last block before BIP91 activated?

The last block that did not have BIP91 rules active was the one with height 477119, with hash 00000000000000000022552c92fdc5ac6c31a95f54d9ed9fcdf0fe00ff134773.

BIP91 uses BIP9, but with modified period sizes and threshold. It uses windows of 336 blocks, and requires 269 blocks to signal on bit 4. The window that ranged from block 476448 to 476783 (inclusive) had 284 blocks that signalled on bit 4. As a result, BIP91 locked in, and the next window of 336 blocks, ranging from 476784 to 477119 (inclusive) was spent in the locked in state. As of block 477120, BIP91 transitioned to the active state, and nodes that implement BIP91 will require signalling for bit 1 as of that block.


Should I continue using this Bitcoin Doubler?

It is definitely a scam. They typically pay people who paid in before with the payments of the people who pay in later. This is unsustainable and it will collapse leaving those who paid in later without any money. Furthermore, most of them will simply take your money and leave. This is a scam and so is everything that promises absurd rewards. This includes doublers, HYIPs, ponzi schemes, etc. You pay in at your own risk and if you lose money, then that is all your fault and there is nothing you or anyone else can do to get your money back.


Largest number of bitcoins at a single address at one time?

Here's a complete list of 'record setting' address balances over time:

   date        block  transaction       balance                    address
-----------   ------  -----------   ---------------   ----------------------------------
Jan 03 2009        0   4a5e1e4b:0       50.00000000   1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa
Jan 14 2009      496   a3b0e9e7:0       61.00000000   1BBz9Z15YpELQ4QP5sEKb1SwxkcmPb5TMs
Jan 15 2009      586   4d6edbeb:0      250.00000000   19QKDUJtx9n7Vaga6nX1bVHdsnT4Khfyi6
Jan 19 2009     1055   8897ea9c:0      500.00000000   15oUEZFKAC8E8BTLt1s1jx4fPxumwB3ecr
Jan 22 2009     1296   59bf8acb:0      875.00000000   12higDjoCCNXSA95xZMWUdPvXNmkAduhWv
                              [36 records omitted for 12higDjoCCNXSA95xZMWUdPvXNmkAduhWv]
Jan 15 2010    34887   ffcea1e6:0    72374.36000000   12higDjoCCNXSA95xZMWUdPvXNmkAduhWv
Oct 02 2010    83231   689f1772:0   110001.00000000   1LUPDXYf9XD9Ee1AqCuM3gZCA3ZMKgTcgw
Oct 02 2010    83240   0ee1f4e6:1   120001.00000000   1NJWs6g6hQsgxqtpRxXLhZJwHYhH2P2bvx
Oct 02 2010    83243   31b00090:0   122001.00000000   1NJWs6g6hQsgxqtpRxXLhZJwHYhH2P2bvx
Jan 27 2011   104770   8f821069:0   400000.00000000   1AYtnRppWM7tWQaVLpm7TvcHKrjKxgCRvX
Jun 12 2011   130281   a09ac44c:1   432109.87654321   1KLahQtqDNAXvrjNyfvgSBtAhwco5ZxLp4
Jul 18 2011   136856,  e4762860:1   434242.43424242   1eHhgW6vquBYhwMPhQ668HPjxTtpvZGPC
                              [36 records omitted for 1eHhgW6vquBYhwMPhQ668HPjxTtpvZGPC]
Jul 18 2011   136870   b96a37e4:1   474320.43424242   1eHhgW6vquBYhwMPhQ668HPjxTtpvZGPC
Nov 16 2011   153509   29a3efd3:1   500000.00000000   1M8s2S5bgAzSSzVTeL7zruvMPLvzSkEAuv

And this shows for record setting transaction sizes:

   date        block   transaction       amount
-----------   ------   -----------   ---------------
Jan 03 2009        0     4a5e1e4b        50.00000000
Jan 14 2009      496     a3b0e9e7        61.00000000
Jan 15 2009      586     4d6edbeb       250.00000000
Jan 19 2009     1055     8897ea9c       500.00000000
Jan 26 2009     1945     5559270f      1000.00000000
Feb 09 2009     3645     cec658ac      2200.00000000
Mar 16 2009     7677     e6f00fa6      2400.00000000
Apr 20 2009    11666     eebd343e      3500.00000000
Jul 20 2009    19863     123a3968      6049.53000000
Oct 16 2009    25095     4aa98b18      9700.00000000
Oct 22 2009    25618     1aae9d58     11950.00000000
Oct 24 2009    25788     5d793270     12250.00000000
Oct 27 2009    25969     3cd9410f     13000.00000000
Nov 04 2009    26402     6029e51c     15500.00000000
Nov 19 2009    27525     f2e5fdd3     21850.00000000
Nov 19 2009    27528     67fc73c7     22500.00000000
Mar 06 2010    44006     23709241     23247.39000000
Jul 12 2010    65566     ba62e528     35000.00000000
Jul 26 2010    70527     b9d69463     46753.13000000
Jul 28 2010    70870     73ac0fdc     50000.00000000
Nov 04 2010    89583     3bc57f90     50000.01000000
Nov 06 2010    90003     70dab592     55000.00000000
Nov 08 2010    90505     1ec28eee     96999.00000000
Jan 27 2011   104770     8f821069    400000.00000000
Jun 12 2011   130281     a09ac44c    432109.88745232
Jun 23 2011   132749     3a1b9e33    442000.00000000
Nov 16 2011   153509     29a3efd3    550000.00000000

So both the biggest balance and the biggest transaction are in block 153509.

The transaction is 10% bigger than necessary due to some sub-optimal coin selection code in the default client.  It makes sure, when using a set of different coins to make up the transaction inputs, that the selected coins total at least one cent more than the transferred amount.  This is an attempt to prevent sub-cent change which would trigger transaction fees.  However, in some cases there is no need for any change at all.  In this case the 'spare change' it allocated was a 50k BTC coin.  I've since submitted a fix for this issue.  This 500k coin and its subsequent movements caused the spike in global Bitcoin transaction volume referred to in this question.

Data is accurate as of February 9th 2012.


What does the global transaction limit mean in practice?

The Bitcoin network uses the blockchain to form consensus on the journal of transactions. The blocks commit the network to a specific order of events and guarantee propagation. Blocks are found roughly every ten minutes and are limited to 4,000,000 weight units (or 1,000,000 vbytes). Said blockweight limit and cadence of blocks are what limits network's transaction confirmation rate: with about 2,000 to 2,500 transactions per block every 600 seconds, the transaction rate is currently closer to 3.5 tps in practice. Note that a transaction may perform more than one payment.
Before transactions are organized into blocks by miners, the unconfirmed transactions are tracked in the memory pool (mempool) of each node. A node's mempool can hold about half a day's worth of transactions by default. Miners generally pick the transactions with the highest feerate first to build their block to optimize their revenue. When peak demand subsides, the network eventually chews through the backlog, also confirming transactions with lower feerates. Altogether, this forms a market for blockspace in which users can bid with transaction fees to signal the urgency of their payments.

Indeed, how many actual payments would it take a (good or bad) actor to fill the network (or would the payments simply get all grouped together infinitely), is the limit perhaps 3.5*4million per sec?

As described above, miners generally pick the transactions with the highest feerates to form their blocks. If the attacker wants to monopolize all blockspace, they'll have to continuously displace all other transactions from the top of the queue. However, other users are free to resubmit their transactions with an increased feerate to vie for the top of the queue. This would either break the attack or quickly drive up the cost, as all other users acting independently would outspend a low feerate spam attack.
In the 2017 bubble, we saw over a dozen organic blocks with more than 12 BTC in fees. Assuming that an attacker would need to pay a corresponding ~1,200 sat/vB to monopolize blockspace, their attack would cost about 72 BTC per hour.


if you have tar.gz file do like that to extract files:

tar xzf bitcoin-0.14.2-x86_64-linux-gnu.tar.gz

install it

sudo install -m 0755 -o root -g root -t /usr/local/bin bitcoin-0.14.2/bin/*

finally, run it

bitcoind -daemon

if you mean by "you copied all the files" that you copied .bitcoin directory so do like that after the previous step:

mkdir ~/.bitcoin

move the files you copied to this directory and execute

bitcoind -daemon


Note that, like "the mempool", there is no "the UTXO database". You can change the UTXO database for one node and only that node. Such changes will not effect other nodes and does not change the state of the network. By modifying a node's UTXO database, that node has the possibility of forking off of the actual Bitcoin blockchain.

Is it possible to manually add utxos to the utxo database?
Could this be done by editing the chainstate file?

Yes it is possible to modify a node's UTXO database. It is just several files which you can modify directly. Bitcoin Core uses LevelDB so you will need to use something that can read and write to LevelDB databases.


Why do some transactions take minutes and others take hours?

Four factors affect this:

1) The size of the transaction. Smaller transactions get a lower priority. Abnormally small transactions look like spam.

2) The transaction fee. Abnormally low transaction fees may mean the transaction isn't even relayed. Miners have an incentive to include transactions with higher fees.

3) Luck. Some miners don't include any transactions. Some don't include any transactions without fees, even if the fee would normally be zero. So it comes down to who mines the next block or blocks. Also, 10 minutes is just the average. You could create a transaction and then by sheer bad luck the next block isn't mined for 20 minutes.

4) Security. The client 'dribbles' out its own transactions rather than broadcasting them to try to conceal the origin.


How can I tell if someone is trying to hack port 8333?

You are looking for ways to improve the client's protections against flaws?

Here's a list of its current protections:

http://en.bitcoin.it/wiki/Weaknesses#Denial_of_Service_.28DoS.29_attacks


What is Skrill's policy on its use in BTC trading?

Section 6.7 of the Skrill ToS bans sending payments that are "in connection with any money changing or transmitting business, including but not limited to bureaus de change or currency exchanges"

Bitcoin trade counts as currency exchange, so yeah.


How can I build litecoin from source in Visual Studio (2010 or 2012)?

its a fork of bitcoin so this should be the same https://bitcointalk.org/index.php?topic=24670.0


How to send a payment through a route saved in a json?

I think the problem is that you are trying to pass the file name as an argument instead of the content of the file. Try passing the json through the standard input instead:

cat routes.json | lncli --network=testnet sendtoroute --payment_hash=...


You can make another transaction with a larger fee to override the previous one.


Permissioned blockchains on EVM: are these private ledgers os it all on ETH main net?

They are completely separate networks, with a different genesis block.

Geth and parity support running your own private networks that can utilize the features of ethereum (and the ecosystem of tools for it), without having to interact with the public network.


Is access to mining the only obstacle to centralised bitcoin-like currency?

Mining is the part of the decentralizing, to make a centralized currency you simply need to skip the publicly maintained blockchain portion, which includes mining. But without the publicly maintained blockchain, you really have only have a database that keeps track of transactions.


Is the bits field a unique representation of the target?

In short: no, the nBits encoding is not unique (there may be multiple 32-bit values that correspond to the same 256-bit target), but the nBits value as required by the network consensus rules is unique.

The reason for that is that all calculations happen on the target, which is then converted (using a deterministic algorithm) into nBits format. That nBits value is then required to match the value in the block header.


Connecting to a node and opening a channel

When you connect to a node in the lightning network, you are opening a network connection to that node. You begin exchanging messages about the lightning network and can gather information such as other open channels, other nodes that can be connected to, etc. This information can help you build a better channel graph and decide whether you want to open a channel with this node or with some other node.

Once you have connected to a node, you can open a channel with it. Opening a channel requires creating a Bitcoin transaction, broadcasting it to the Bitcoin network, and waiting for it to become confirmed. When you open a channel, you must also be connected to the other node as you need to send information about the channel, such as channel updates, to that node.


Is there a bitcoin market for CPU time / memory space / disk space?

Maybe not exactly what you are asking for but CoinLab have a mining pool that intends to use the computing power of their members for jobs other than hashing.

From the Bitcoin talk forum topic:

  We’ve identified a number of opportunities to monetize our growing GPU cluster at a higher rate than Bitcoin mining, particularly for NVIDIA cards:  Protein Folding, Computational Finance, and Big Data Analysis, just to name a few.


No, that's not possible.

Public notes are a feature of blockchain.info and only exist in the blockchain.info database (and not in the Bitcoin blockchain).

The only way to add a public note to a transaction on blockchain.info seems to be by using their wallet.


Is it possible to create a blockchain network which will not increase in difficulty?

It is possible, but very stupid to do. If you keep the difficulty the same, hardware will get better and better over time (or just more of it is used to mine your altcoin) and this will cause blocks to be produced faster and faster and faster. This makes attacks much easier to take place too.


Start the client on the command line with the flag -reindex.


the bitcoin wallet spendable amount is not updating

Definition of Watch-only Adress:

An address or pubkey script stored in the wallet without the corresponding private key, allowing the wallet to watch for outputs but not spend them.

So you should find your private keys in order to spend these adresses


How convert Bitcoin Privat Key Compression to public address?

If I get your code and use "e41b45e722251672c01a28e4fada590471fea09f90d13b143033ed3a1107ef49" as secret hex value AKA secret private key... then I get result: "12sF1DbBbPaoNYrs28Qm7waiCcAVoF93Nn" which is uncompressed public address.
Check my script, it is more extended, but with a copule of imports for an educational point of view, to show all the process. You will get compressed and uncompressed public keys from a given secret in hexadecimal value.
First, the script will get uncompressed private key and compressed private key in hex:
'04417A55413D948D79F5194F1F2CD670F078CB7F6D3A2F2B12E8CDF9A3268CAD3BAAA3251D2587D4E57ACBCE7991B72355EA33C44DBCF260D09B6C921879A61AA4'
'02417A55413D948D79F5194F1F2CD670F078CB7F6D3A2F2B12E8CDF9A3268CAD3B'

Then it will get both public uncompressed and compressed public keys.
The code:
#!/usr/bin/python3
from hashlib import sha256, new
import binascii

PCURVE = 2 ** 256 - 2 ** 32 - 2 ** 9 - 2 ** 8 - 2 ** 7 - 2 ** 6 - 2 ** 4 - 1  # The proven prime
N = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141  # Number of points in the field
ACURVE = 0
BCURVE = 7  # These two defines the elliptic curve. y^2 = x^3 + Acurve * x + Bcurve
Gx = 55066263022277343669578718895168534326250603453777594175500187360389116729240
Gy = 32670510020758816978083085130507043184471273380659243275938904335757337482424
GPOINT = (Gx, Gy)  # This is our generator point. Trillions of dif ones possible

def modinv(a: int, n: int = PCURVE):
    # MAXIMO COMUN DIVISOR: Extended Euclidean Algorithm/'division' in elliptic curves
    lm, hm = 1, 0
    resto = a % n
    high = n
    while resto > 1:
        ratio = high // resto
        nm = hm - lm * ratio
        new = high - resto * ratio
        lm, resto, hm, high = nm, new, lm, resto
    return lm % n

def ECadd(a, b):  # Not true addition, invented for EC. Could have been called anything.
    LamAdd = ((b[1] - a[1]) * modinv(b[0] - a[0], PCURVE)) % PCURVE
    x = (LamAdd * LamAdd - a[0] - b[0]) % PCURVE
    y = (LamAdd * (a[0] - x) - a[1]) % PCURVE
    return x, y

def ECdouble(a):  # This is called point doubling, also invented for EC.
    Lam = ((3 * a[0] * a[0] + ACURVE) * modinv((2 * a[1]), PCURVE)) % PCURVE
    x = (Lam * Lam - 2 * a[0]) % PCURVE
    y = (Lam * (a[0] - x) - a[1]) % PCURVE
    return x, y

def EccMultiply(gen_point: tuple, scalar_hex: int):  # Double & add. Not true multiplication
    if scalar_hex == 0 or scalar_hex >= N:
        raise Exception("Invalid Scalar/Private Key")
    ScalarBin = str(bin(scalar_hex))[2:]  # string binario sin el comienzo 0b
    Q = gen_point  # esto es una tupla de dos integer del punto de generacion de la curva
    for i in range(1, len(ScalarBin)):
        Q = ECdouble(Q)
        if ScalarBin[i] == "1":
            Q = ECadd(Q, gen_point)  #
    return Q

def private_to_hex_publics(hex_private_key: hex):
    public_key = EccMultiply(GPOINT, hex_private_key)
    public_uncompressed = f"04{hex(public_key[0])[2:].upper()}{hex(public_key[1])[2:].upper()}"

    if public_key[1] % 2 == 1:  # If the Y value for the Public Key is odd.
        public_compressed = ("03" + str(hex(public_key[0])[2:]).zfill(64).upper())
    else:  # Or else, if the Y value is even.
        public_compressed = ("02" + str(hex(public_key[0])[2:]).zfill(64).upper())
    return public_uncompressed, public_compressed

def hash_256_from_hex_string_like_bytes(hexstring: str):
    return sha256(bytes.fromhex(hexstring)).hexdigest()

def ripemd160_from_hex_string_like_bytes(hexstring: str):
    return new('ripemd160', bytes.fromhex(hexstring)).hexdigest()

def b58encode(hex_string, expected_length=None):
    v = binascii.unhexlify(hex_string)
    alphabet = "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz"
    lev, number = 1, 0
    for char in reversed(v):
        number += lev * char
        lev = lev << 8  # 2^8
    string = ""
    while number:
        number, modulo = divmod(number, 58)
        string = alphabet[modulo] + string
    if not expected_length:
        return string
    elif len(string) != expected_length:
        raise Exception(f"b58encode: Expected length={expected_length} obtained length={len(string)}")
    else:
        return string

def sha256_get_checksum(hex_string_to_checksum):
    hasha1 = hash_256_from_hex_string_like_bytes(hex_string_to_checksum)
    # print("HashA1", hasha1)
    hasha2 = hash_256_from_hex_string_like_bytes(hasha1)
    # print("HashA2", hasha2)
    return hasha2[:8].upper()

def sha_ripe_digest(hex_string_to_checksum):
    hashc1 = hash_256_from_hex_string_like_bytes(hex_string_to_checksum)
    hashc2 = ripemd160_from_hex_string_like_bytes(hashc1)
    return hashc2.upper()

def wif_from_private(privkey: hex):
    # put 80 for bitcoin and concatenate with privkey
    prepend = "80"
    private_key_str = hex(privkey)[2:].zfill(64)
    prepended = (prepend + private_key_str).upper()
    compressed = (prepend + private_key_str + "01").upper()

    if len(prepended) != 66 or len(compressed) != 68:
        raise Exception("WIF conversion: Wrong prepended or compressed private key, length not 66")

    uncompressed_checksum = sha256_get_checksum(prepended)
    compressed_checksum = sha256_get_checksum(compressed)
    private_key_uncompressed_checksum = prepended + uncompressed_checksum
    private_key_compressed_checksum = compressed + compressed_checksum
    private_key_WIF_uncompressed_Base58 = b58encode(private_key_uncompressed_checksum, 51)
    private_key_WIF_compressed_Base58 = b58encode(private_key_compressed_checksum, 52)

    print("PREPENDED:\t\t\t\t", prepended)
    print("PRIV_UNCOMP+CHECKSUM:\t\t\t", private_key_uncompressed_checksum)
    print("Private_key_WIF_uncompressed_Base58:\t", private_key_WIF_uncompressed_Base58)
    print("PRIV_COMP+CHECKSUM:\t\t\t", private_key_compressed_checksum)
    print("Private_key_WIF_compressed_Base58:\t", private_key_WIF_compressed_Base58)
    return private_key_WIF_uncompressed_Base58, private_key_WIF_compressed_Base58

def hex_public_to_public_addresses(hex_publics):
    uncompressed = hex_publics[0]
    public_key_hashC_uncompressed = "00" + sha_ripe_digest(uncompressed)
    checksum = sha256_get_checksum(public_key_hashC_uncompressed)
    PublicKeyChecksumC = public_key_hashC_uncompressed + checksum
    public_address_uncompressed = "1" + b58encode(PublicKeyChecksumC, 33)
    print("Public address uncompressed:\t", public_address_uncompressed)

    compressed = hex_publics[1]
    PublicKeyVersionHashD = "00" + sha_ripe_digest(compressed)
    compressed_checksum = sha256_get_checksum(PublicKeyVersionHashD)
    PublicKeyChecksumC = PublicKeyVersionHashD + compressed_checksum
    public_address_compressed = "1" + b58encode(PublicKeyChecksumC, 33)
    print("Public address compressed:\t", public_address_compressed)
    return public_address_uncompressed, public_address_compressed

if __name__ == "__main__":
    privkey = 0xe41b45e722251672c01a28e4fada590471fea09f90d13b143033ed3a1107ef49
    print(f"PRIVATE KEY:\t {hex(privkey)[2:].zfill(64).upper()}")

    # Public hex test
    hex_publics = private_to_hex_publics(privkey)
    print(hex_publics)
    print()

    # WIF creation test
    wif = wif_from_private(privkey)
    print(wif)

    # Public keys
    public = hex_public_to_public_addresses(hex_publics)
    print(public)

The script is inspired by this site.
Finally you will obtain the two public keys, uncompressed and compressed:
'12sF1DbBbPaoNYrs28Qm7waiCcAVoF93Nn', '1BMKGYmgjrvmSDtvLZvKjyVMnbi6FLmcVi'

Hope this will help you.
Note: it will give you the WIF format too.
Full output:
PRIVATE KEY:     E41B45E722251672C01A28E4FADA590471FEA09F90D13B143033ED3A1107EF49
('04417A55413D948D79F5194F1F2CD670F078CB7F6D3A2F2B12E8CDF9A3268CAD3BAAA3251D2587D4E57ACBCE7991B72355EA33C44DBCF260D09B6C921879A61AA4', '02417A55413D948D79F5194F1F2CD670F078CB7F6D3A2F2B12E8CDF9A3268CAD3B')

PREPENDED:                               80E41B45E722251672C01A28E4FADA590471FEA09F90D13B143033ED3A1107EF49
PRIV_UNCOMP+CHECKSUM:                    80E41B45E722251672C01A28E4FADA590471FEA09F90D13B143033ED3A1107EF496CB6A884
Private_key_WIF_uncompressed_Base58:     5KYkFr9FMmBVcwjLbJinAw94b985tgyt4PL9Jhcjsk6J6ZRfxjM
PRIV_COMP+CHECKSUM:                      80E41B45E722251672C01A28E4FADA590471FEA09F90D13B143033ED3A1107EF4901070CD9AC
Private_key_WIF_compressed_Base58:       L4s7vXuQNe1KKeZsURDQNqxaqgrGb9U4MwZVf8GkEyCNTKyEk3iK
('5KYkFr9FMmBVcwjLbJinAw94b985tgyt4PL9Jhcjsk6J6ZRfxjM', 'L4s7vXuQNe1KKeZsURDQNqxaqgrGb9U4MwZVf8GkEyCNTKyEk3iK')
Public address uncompressed:     12sF1DbBbPaoNYrs28Qm7waiCcAVoF93Nn
Public address compressed:       1BMKGYmgjrvmSDtvLZvKjyVMnbi6FLmcVi

Editing original code by Jon Do request
import ecdsa
import hashlib
import base58

def bytes_to_hex_string(b: bytes):
    return ''.join('{:02x}'.format(x) for x in b).upper()

def get_prepend_if_even_or_odd_for_compressed(x_point):
    y = int(x_point[64:], 16)
    if y % 1 == 1:
        return "03"  # odd
    return "02"  # even

private_key = "e41b45e722251672c01a28e4fada590471fea09f90d13b143033ed3a1107ef49"

# Convert hex private key to bytes
private_key = bytes.fromhex(private_key)
print(f"Private key hex string: \t\t {bytes_to_hex_string(private_key)}")
print(f"Private key bytes: \t\t\t {private_key}")
# Derivation of the private key
signing_key = ecdsa.SigningKey.from_string(private_key, curve=ecdsa.SECP256k1)

verifying_key = signing_key.get_verifying_key()
print(f"Verifying key, x and y points (bytes):\t{verifying_key.to_string()}", type(verifying_key.to_string()))

x_point = bytes_to_hex_string(verifying_key.to_string())
print(f"Uncompressed private key (hex):\t\t 04{x_point.upper()}")

even_odd = get_prepend_if_even_or_odd_for_compressed(x_point)
print(f"Compressed private key in (hex):\t {even_odd}{x_point.upper()[:64]}")

# public_key = bytes.fromhex("04") + verifying_key.to_string()  # this is error, you're using uncompressed private key
public_key = bytes.fromhex(even_odd) + verifying_key.to_string()[:32]

# Hashes of public key
sha256_1 = hashlib.sha256(public_key)  # now public_key contains compressed private key
ripemd160 = hashlib.new("ripemd160")
ripemd160.update(sha256_1.digest())

# Adding prefix to identify Network
hashed_public_key = bytes.fromhex("00") + ripemd160.digest() # hashed_private_key is public key

# Checksum calculation
checksum_full = hashlib.sha256(
    hashlib.sha256(hashed_public_key).digest()).digest()
checksum = checksum_full[:4]

# Adding checksum to hashpubkey
bin_addr = hashed_public_key + checksum

# Encoding to address
address = str(base58.b58encode(bin_addr))
final_address = address[2:-1]  # change 2

print(f"Public compressed key (hex): \t\t {final_address}")

The new output is:
Private key hex string:                  E41B45E722251672C01A28E4FADA590471FEA09F90D13B143033ED3A1107EF49
Private key bytes:                       b'\xe4\x1bE\xe7"%\x16r\xc0\x1a(\xe4\xfa\xdaY\x04q\xfe\xa0\x9f\x90\xd1;\x1403\xed:\x11\x07\xefI'
Verifying key, x and y points (bytes):  b'AzUA=\x94\x8dy\xf5\x19O\x1f,\xd6p\xf0x\xcb\x7fm:/+\x12\xe8\xcd\xf9\xa3&\x8c\xad;\xaa\xa3%\x1d%\x87\xd4\xe5z\xcb\xcey\x91\xb7#U\xea3\xc4M\xbc\xf2`\xd0\x9bl\x92\x18y\xa6\x1a\xa4' <class 'bytes'>
Uncompressed private key (hex):          04417A55413D948D79F5194F1F2CD670F078CB7F6D3A2F2B12E8CDF9A3268CAD3BAAA3251D2587D4E57ACBCE7991B72355EA33C44DBCF260D09B6C921879A61AA4
Compressed private key in (hex):         02417A55413D948D79F5194F1F2CD670F078CB7F6D3A2F2B12E8CDF9A3268CAD3B
Public compressed key (hex):             1BMKGYmgjrvmSDtvLZvKjyVMnbi6FLmcVi


Is it possible to schedule a transaction in the future?

Yes, there is tx.nLockTime. A transaction mined before its nLockTime is invalid, so you can send your funds to yourself on some newly created address, then send it back with a locktime and destroy the private key for the newly created address.  Transactions with nLockTime can be amended, but since you destroyed the private key, you actually can't, thus preventing them from being spent before that time has passed.

See here, here, or here.

Note that nLockTime transactions may not be stored/relayed by the network. So you need to keep the transaction in a safe place and broadcast it at the right time.


Stealing a correct hash because of an invalid block

It's not a valid working process: all transactions commit to the block hash.
First of all a miner cannot "find a right hash" then insert a double-spend transaction. This would invalidate the hash (and the block, actually).
For the same reason, a node receiving the block cannot malleate the coinbase transaction. It would not be able to "immediately produce a block" either.
In addition, blocks have consensus rules and a valid block does not only consist of a block header hash inferior to the target but must respect a number of other rules as well (locktimes, existing outpoints, valid scripts, ...).
The cost of producing a valid PoW is so high that you would not expect a miner to commit energy to an invalid block.


How does Coinbase / GDAX calculate volume in historical candles?

I can't answer for the discrepancy that you're seeing, but the "right" way to calculate volume would be to add the "total" column from each trade that occurred during the period. That is, assuming that candle charts are based on stock market candle charts.

It doesn't surprise me that you're seeing this discrepancy, however. I've noticed a few different cryptocurrency APIs that have no idea how to calculate OHLCV data the right way. If your candle data isn't correct, then none of the traditional TA-Lib functions will mean anything!


Any 256-bit value can be a valid secp256k1 ECDSA private key. Strictly speaking, there's an upper limit that's slightly lower than 2^256, but you can just wrap them around.

So yes, you can just use SHA256(passphrase) to generate a private key.


How do Bitcoin nodes with dynamic IP addresses maintain connections?

Bitcoin works over the TCP layer which requires knowing the IP addresses of two ends of the connection. If one IP address changes, the connection will terminate.

In general, to manage disconnects, Bitcoin Core tries to maintain 8 outgoing connections at all times. It stores the IP addresses of every node that it knows about. These nodes can be ones it has connected to previously or ones that other nodes has told it about. When it loses an outgoing connection, it will attempt to make another outgoing connection to replace that connection.

Thus if all connections happened to be dropped due to a dynamic IP address change, all outgoing connections will be replaced by new outgoing connections from the new IP address. Unfortunately incoming connections will not be replaced and the node will have to wait for its new external IP address to be advertised again by its peers.

A node does not directly advertise its external IP address. Instead other nodes learn of its external IP address from hearing about it from other nodes that have connected to that node.


Integrity of ensuring the correct recipient of a BTC public address?

Yes. Somehow, you need to tell the client what public key/address to send to. If the attacker has full control over the client, or your server, they can replace your address with whatever they'd like.


Is there a legal way and free way to open a Bitcoin exchange in the United States?

There is a free way. There is a legal way. There is not a free, legal way.
Free way
Get a DynDNS account, and a Raspberry Pi. Host the exchange on your home internet connection.
I can't think of any reason why someone would trust their money to my_exchange.dyndns.biz, but I suppose you could do this.
Legal way
Money service businesses are generally regulated state-by-state, so it's difficult to give you general advice. I would suggest that you find a lawyer that practices law in that state and who specializes in banking law; they can tell you what you need to comply with. If you do not know a lawyer like this, I suggest going to a lawyer you do know and asking for a recommendation.

When are the legalities surrounding exchanges like coinffeine, where two anonymous users exchange and coinffeine acts as the intermediary?

Those two users are breaking the law. Operating an unlicensed money service business is against the law, and people have been arrested for exchanging Bitcoins. (Also, if you operate an unlicensed MSB, you're automatically also committing a federal crime.)
Whether Coinffeine is also breaking the law is a very interesting question that I am totally unqualified to answer.


Can*t call chainActive.Tip()->nHeight in core.cpp

As SajithP commented:

  modify the makefile to include the object of the class which has the chainActive as a member. e.g 'x.o' where chainActive is a member of class 'x'


How to manually verify a signature given scriptSig and scriptPubKey?

Remember that 'scriptPubKey' and 'scriptSig' are scripts.  They are intended to be executed by an interpreter.  The reason your naive attempt didn't work, is because these values are not simple numbers, but are executable lines of code.

What happens, is that scriptSig is executed first, leaving values on the stack.  Then scriptPubKey is executed to check if the values left by scriptSig are valid.  Because scriptPubKey is the script specified by the output being spent, it encumbers the bitcoins, and is also called the encumbrance script.  So whoever last spent the bitcoins, gets to decide the terms by which the bitcoins are encumbered.  Usually it says something like "pay this output to whosoever has the private key that matches this public key"...but it doesn't have to.  This is how the system can handle multisig transaction, storing data, smart contracts, and multiple types of payments.  It's actually fairly complicated, which is why there is a programming language used rather than static keys and signatures.

Unfortunately, the best reference on how this code executes would be the interpreter.cpp file of the reference client (Bitcoin Core).  I know that's probably not the answer you were looking for, but this is really at the heart of what makes Bitcoin so flexible.


Unconfirmed bitcoin transaction (Need help)

The transaction you link builds on a chain of approximately 30 unconfirmed transactions. As far as I saw when skimming through, they all pay decent fees with 295sat/B, however due to them being unconfirmed for more than two weeks, probably some have been dropped from the mempool since.

You should make sure that all the transactions are broadcast to the network again, then I think they would confirm easily within an hour or two, as currently transactions at <80sat/B get confirmed.


How does Bitcoin choose to which miner the reward will go?

It's all about probability. In about 10 minutes, a miner among those 100 will finally achieve to solve the proof of work for the given block before others will. So, he then will write that block on the blockchain, using it's address in the receiving address field of the coinbase transaction, thus obtaining it's reward.
what happen if they all mine the block at the same time
In that case, the blockchain would be temporary forked on the block at height X, given X the number of the block been mined at the same time by more than one miner. This won't last forever. Remember the golden rule of bitcoin: the longest chain win. Among those forks, one will definitely be resolved (again, it's all about probability at the end of the day), meaning more hashrate will be brought to it, so it will grow faster (speaking about blockheight) than the other. That one will become the current blockchain.
What happens to the other forks? Well, they're simply not valid blockchains. They contain outdated data. If forking miner continue to mine on those blockchain, they'll do at a lost, because they will get rewards on a blockchain which is not the main one
Is there some priority protocol? No, absolutely. Just probability. The more hashrate you have, the more probably you can mine the next block
how the precise time of completion is calculated (is it using the miner's computer clock as timestamp? From the bitcoin wiki

A timestamp is accepted as valid if it is greater than the median
timestamp of previous 11 blocks, and less than the network-adjusted
time + 2 hours. "Network-adjusted time" is the median of the
timestamps returned by all nodes connected to you. As a result block
timestamps are not exactly accurate, and they do not need to be. Block
times are accurate only to within an hour or two.Whenever a node connects to another node, it gets a UTC timestamp from it, and stores its offset from node-local UTC. The network-adjusted time is then the node-local UTC plus the median offset from all connected nodes.


They don't wait for confirmations, but they check if a transaction has appeared in mempools of some miners. They could also just check if the preceeding transaction (the source of 10 BTC) exists on the blockchain.


EDIT: while your transaction did go through (see below), you sent a different amount (~11 or ~19 mBTC depending on which is the change address) from what you said the recipient wanted.

Looking at https://blockchain.info/tx/abef483d268dc61214fd5bf25c602256cf447aa65bec2e539fee42f59a3b90b3, it seems that your transaction is not stuck at all. It has been confirmed over a thousand times as of today. So there's three possibilities here:

a) the recipient of the transaction doesn't know how his wallet works and is somehow unable to see the received transaction

b) they gave you a wrong address or you mistyped or mis-copypasted it (which would mean the coins were sent to an address somebody else owns, or nobody at all)

c) the recipient is lying to you.


Why are block header bits necessary? (Valid difficulty is already implied by chain history)

They aren't really necessary. The reason that they are included can only be known by Satoshi, and AFAIK, he did not state why he chose to include nBits in the block header (or many other things that are just arbitrary). This is one of the many things that Satoshi chose to do and no one really knows why. It remains in the block header today because removing it would require a hard fork and there really is not much benefit to be gained by removing it.

The nBits field can be useful, and it likely was included as a convenience sort of thing. Instead of having to have the full chain history in order to know the current difficulty, you can instead look at the nBits. But that is just speculation, and full nodes don't use the nBits to determine the current difficulty (except those of the genesis block).


When are private Keys created on Wallets?

In the default Bitcoin client, and most clients based on it (including Dogecoin-QT), 100 private keys are pre-generated, so that the wallet you backup is useful both for existing and some future transactions (roughly 50 transactions, assuming you receive on a new address and send change to a new address each time). When you ask the client to generate an address for you, it pulls from a private key from this pool (and generates another to put the pool back up to 100 at some point), from which a public key and address can be calculated. This pool size is configurable in your .conf file:

 # Pre-generate this many public/private key pairs, so wallet backups will be valid for
 # both prior transactions and several dozen future transactions.
 #keypool=100


How exactly would anyone know from where I got a given "bit of Bitcoin", or who I send it to?

All Bitcoin transactions are public information, and each transaction is uniquely identifiable via its txid. Each piece of bitcoin (called a transaction output) is uniquely identifiable as well by means of the transaction that created it, and the index of the output on the transaction. This makes the "outpoint" txid:vout the unique identifier of a UTXO.

So, what your trading partner learns is your name via the bank transfer, the address you gave them, and the transaction output they created for you. That alone is not very informative as you noted, but it can become useful in combination with large swaths of other information. For example, if multiple of your counterparties on Bisq collected the names of whom they trade with, they could cluster your addresses and unspents to the same name. They can also track your on-chain activity: when you spend the funds, they will assume that any other funds used in the same transaction are also owned by you, clustering the other addresses to you. When you send to a recipient and receive the remaining funds back as a change output, they may be able to guess which of the two outputs went to a recipient and which went back to you. In that case, they will be able to probabilistically associate your next payment to you as well. They may have information on the address that you sent to, because you paid into a KYC'ed entity like a payment provider or Bitcoin exchange. In that case, they learn more about the purpose of your payment, or potentially could even look up other account activity if you deposited into an account.

So, basically your bitcoin activity is generally private, in that no personally identifiable information is directly collected in the bitcoin network, yet it is also inherently pseudonymously associated with you which reduces your anonymity set depending on how traceable your activity is. However, since the blockchain is a permanent record, anyone sufficiently motivated and well-connected may be able to fill in the transaction graph to trace back step by step to you.

If you want to read more about privacy in Bitcoin, I would recommend this excellent treatise on the Bitcoin wiki: Privacy


Who receives the money when a bitcoin is purchased?

Newly mined bitcoins don't "cost" anything (I'm simplifying - there are costs such as electricity and the cost of the mining hardware).

New bitcoins are simply discovered by the miner who is lucky enough to discover them.  The concept is similar to finding gold in the ground.  Once you find the gold, you take it to a market and sell it to someone who wants gold, and is willing to provide money in return for gold.  In the case of bitcoin, a miner runs a large number of mathematical equations searching for an answer that matches the difficulty requirements, and other technical criteria.  Once the answer is found, a block is produced containing the answer along with a number of new bitcoins.  The miner then either retains the new bitcoins, or trades them for some other currency.


As Ugam Kamat commented:

  20 in decimal is equal to 14 in hexadecimal

(Community-Wiki answer to remove Q from unanswered list)


This error occurred because my blockchain was not synchronized, I waited for it to sync and then repeated the process and it worked


What does it mean when a block is "kicked"?

The term seems to have been defined in this GitHub issue: https://github.com/zone117x/node-open-mining-portal/issues/138#issuecomment-42396180.

Kicked basically means orphaned one way or another. Apparently, the creator of this pool software was seeing some strange behavior in the way the daemon would report blocks as being orphaned, and decided to just call them all "kicked" blocks than to differentiate how they were orphaned.

If you are unsure what orphaned blocks are, look at this: What are orphaned and stale blocks?. Essentially they are solved blocks that are not accepted by the network, usually because a different block at the same height was solved at nearly the same time.


Are there any Bitcoin payment providers with an API’s for allowing unconfirmed transactions?

I will design it to cancel the subscription and ban the user’s account if the transaction does not appear in the blockchain 6 blocks later.

It's better if there is a system that waits for few hours before sending an email to the user that subscription maybe cancelled if transaction is not confirmed soon (1 confirmation). If the user fails to make the payment or reach support via email, subscription is cancelled. The reason I am suggesting to use time instead of blocks is because there is no fixed time interval between two blocks. It can take anything from few minutes to few hours for 6 blocks to be mined. The transaction may or may not be included in next 6 blocks depending on the fee rate used in this transaction and fee rate used in other unconfirmed transactions (mempool). Also1-2 confirmations are considered safe to accept a transaction as final.

If I’m not giving refunds and I make sure not to withdraw pending coins myself, what attacks am I vulnerable to like Mt. Gox?

Not sure if I understand your question correctly, If you can implement the above described process in your web app with no vulnerabilities, there shouldn't be any issues.

Are there any online payment services which already accept BTC instantly with an API for reporting false transactions?

You should research more about btcpayserver and  discuss things with the devs involved in it.


Rolled out my own no-fiat service. What will the tax man need?

If you receive 500 EUR as a payment, how do you declare it?

Easy, you declare it as however much GBP it was at the time. If you receive it as a wire transfer your bank will even make this conversion for you!

So with BTC if you receive 2.5 BTC you have to see what the GBP value is and declare that as your receipts, and pay VAT and whatever other taxes on it.

Of course you can choose to lie to the tax man, but remember that Bitcoin is a lot easier for them to track than even your bank account, unless you are very good at operational security and you use something like Monero to separate your transactions. Obviously this is not worth it if you end up having to turn most of it into fiat to pay suppliers anyway.


Is there a reliable way to measure bitcoin wealth distribution?

The protocol gives no information about who controls an address. In an extreme case, every address could be controlled by just one person, or every address could have a unique owner. However, a degree of traffic analysis is possible, and if you have access to other data from outside the Bitcoin network, you could correlate transactions with these non-Bitcoin events and infer who the real-world owners of the addresses are.

For example, if you had access to ISP records of who uses an IP address that has just mined a block, you could start to build profiles of the owners of new coins.

But there are many barriers to achieving the total information awareness that you would need to build a comprehensive profile of all coin owners, so the short answer is no, there is no reliable way to measure Bitcoin wealth distribution.


Transaction do not shows up in my android wallet

Try changing the wallet and make sure that you use a bitcoin wallet since this is a Bitcoin transaction

If you have the private key of the destination wallet, then your funds should be okey


Edit: I apologize I was for some reason still thinking MultiBit classic, if you are using HD there is a possiblity you created seed words which you would be able to restore from.

Information is per: https://multibit.org/try-multibit-hd.html

Classic:
You're going to need the backup wallet or private keys that were automatically created for you by MultiBit. By default they would have been located in a sub-directory of the folder your original MultiBit wallet was created in.

This information is per: https://multibit.org/en/help/v0.5/help_walletBackups.html

If you do not have any of these files/private keys you are out of luck with regards to recovering the funds. The wallet address alone will only allow you to view the funds, there is no way to recover funds with a bitcoin address alone.


Why is a transaction with outputs of less than ฿0.00005460 rejected?

Anything lower than 5460 satoshis is currently considered dust, that bloats the blockchain, while transferring a value that is lower than what it costs to store the resulting output on disk. From the bitcoinj source:

  Any standard (ie pay-to-address) output smaller than this value (in
  satoshis) will most likely be rejected by the network. This is
  calculated by assuming a standard output will be 34 bytes, and then
  using the formula used in getMinNonDustValue(BigInteger). Currently
  it's 5460 satoshis.


Can you always derive a public Bitcoin address from a message and a random signature?

Now, if I send the same signature and a completely different message, will it derive all the time a valid random Bitcoin address ?

Yes.

  And if yes, doesn't this have some serious security implication allowing people to prove they control an address without having the private key ?

No. In order to prove you control an address, you must do much more than just produce a signature generated by that address. Otherwise, if you were in possession of anyone else's proof, you could claim it as your own.

The validation process consists of three steps:

1) Ensure the signature correctly signs the message.

2) Ensure the public key used for the signatures matches the Bitcoin address you are expecting proof of.

3) Make sure the signed payload actually proves the person you think controls the address.

Your mutilation would break step 1. Since you're changing the message, the signature no longer signs the message.

The verifymessage command does steps 1 and 2. Step 3 must be done by higher-level code depending on the context.


When a fork exists with two equal-work branches, it is not unreasonable that the one we saw second will get extended.

There is little DoS risk in downloading both, as an attacker must spend an enormous amount of work to even make us do so.

At the same time, it is useful to be prepared for the blocks in a reorganization, as it reduces the time needed for such a block to propagate through the network.


How can we look up any transaction in a blockchain if they are encrypted?

Hashing and encrypting are separate things, and not really relevant to your question actually. You can read up more on them separately.

When a transaction is broadcasted, the raw serialized tx is broadcasted. This includes the inputs, outputs, and signatures. The transaction hash is actually the hash of this serialized tx.

When blocks are mined, they simply include a block header, plus the serialized transaction data for each transaction in that block. Once again, the block hash and tx hashes are the hashes of the block header and the serialized txs.

Since the serialized data contains the inputs, outputs, and signatures, it is possible to view the history by simply going through the blockchain.


Unable to view coinbase transactions on blockchain.com

Since a Coinbase account is custodial, Coinbase can move money from internal account to internal account without recording it on the blockchain. These sort of internal transactions between Coinbase and its customers are not normal Bitcoin transactions. So far as the Bitcoin network is concerned, Coinbase own the money not you.
I'm not sure what a Coinbase account "BTC wallet address" would be, but I guess either it isn't a valid Bitcoin address (but instead something proprietary and internal to Coinbase) or it was mis-typed or just hasn't been used yet for any on-chain transactions.


Keeping valid shares for it's own when mining in a pool

The address the block reward goes to is in the data that is being hashed. That address is the pool's. If a miner finds a hash that meets the block difficulty, changing the address to the miner's own will cause a different hash, and you don't have control over the distribution of the bits in that second hash. So you don't get a block if you change the address.

Going the other way is the same: if the miner mines using his or her own address, that miner will not be able to send shares to the pool to secure part of next block the pool finds.

A miner can withhold the winning share though, which is detrimental to the pool, but cannot pocket the reward.


How do miners send blocks to network peers?

Blocks are usually sent using BIP152. This transmits blocks using an 80 byte header, 6 bytes per transation, plus the coinbase transaction.  To give a concrete example block 000000000000000000117f0033fd8cff18a9fa4601da7f93e6eb3e084caab586 took 16244 bytes to transmit.

If sending to a peer that doesn't already know the transactions (or not supporting BIP152) the node sends the raw block, which is half the size of the hex.  In the case of that block the raw block is 1,125,118 bytes long.


Can my wallet lose funds because of the gap limit?

You won't ever lose funds due to the gap limit; they don't become lost forever. You can still retrieve them.

The gap limit is really only an issue for restoring backups. When restoring a backup, the gap limit is used by the wallet to know how many addresses to lookahead in order to ensure that all funds are seen. If the gap limit is too small, then a long string of unused addresses can cause the wallet to miss funds at higher indexed addresses as it does not generate them when restoring the backup.

The gap limit is not an issue for normal use. It only effects backup restoration and, when doing such restores, it is easy to just increase the gap limit if you find that not all of your funds were seen by the wallet,


My guess is that you have an address (or addresses) in Wallet 1 to which you do not also have the private key. This would account for both having more money that you should as well as the fact that you can't spend it.


First of all, exchanges keep track of transactions by their TXIDs. The TXID can be changed by 3rd parties, but not the transaction data.

  I can't understand how, say, Bob can change Alice's signature in a Alice->Bob transaction if that signature doesn't belong to him in the first place.

Old versions of Bitcoin Core used OpenSSL to verify signatures (now libsecp256k1). OpenSSL is lenient about signature encoding.

An ECDSA signature is an (R,s) pair. (R,-s) also makes a valid signature.
OpenSSL allows encoding algorithms other than DER.

which means there are more than one possible way to encode signatures. Different but equivalent signatures allow 3rd parties to change the signatures without knowing the private key, thus changing the TXID.

Details: BIP 62


No pool today includes non-standard transactions in blocks.

To be correct, there are a number of conditions and pool options. Some pools have strict rules, some pools - no. But all pools today have their own policy rules for accepting or rejecting transactions to a mempool.

There is no correct answer to your question without knowledge what kind of standardness do you mean. The only thing you can do is connecting to all nodes and broadcasing your transaction hoping someone will accept it.


Is it possible to win the Bitcoin lottery?

Yes, it's possible to solo-mine using your PC. The odds are astronomically small, however. You can look up what hash rate your CPU will get here. The best possible CPU the Xeon Phi 5500 gets 140 MH/s. Current network hash rate is 570,000,000,000 MH/s. So every block, you have a 0.000000000245% chance of finding the block. You'll find one block every 76,000 years if the hash rate were to stay constant.

The electricity costs of running your PC are far, far higher than the expected payoff of mining with your CPU. Heck, the wear and tear on your computer is probably a lot higher cost than that expected payoff.

And note, too that this is the best possible CPU. Your average CPU is about 10x worse.


GHOST is outdated, the more relevant protocol based on recent research by Aviv Zohar et al is called "SPECTRE" - https://medium.com/@avivzohar/the-spectre-protocol-7dbbebb707b5, https://eprint.iacr.org/2016/1159.pdf.

It has many advantages over the traditional longest-chain rule of Bitcoin, but:

It requires a hard fork, something which has never been done intentionally in Bitcoin.
It is a huge departure from Bitcoin's protocol, and as such it will require extensive research and testing before it is even considered for inclusion in Bitcoin.

There are alts under development that are trying to implement SPECTRE, if it works well for them it can be a first step towards consideration in Bitcoin. You don't risk untested ideas on a $100B production system.


lower bound of block size towards increased speed of propagation

There is a lower bound: Blocks must include at least one transaction, the Coinbase. ;)

The advantage of a smaller block has been somewhat overstated in the past, as it usually doesn't matter much, especially since the relay network got improved with Compact Blocks, a compressed block format that significantly reduces the peak bandwidth required to propagate blocks.

Basically, for a smaller block to have a relay advantage over a larger block the two blocks would have to be found within less than 5 seconds of each other. This only occurs once every two to three days and thus is hardly a significant quantity to optimize for in comparison to the chance of even finding a block to double spend with in the first place.


what's the purpose of the chain_id in merge mining?

I discovered the answer in a blog:

it is necessary to make sure that a miner cannot mine on different
branches of the same child blockchain, as this conflicts with the
rules of the underlying Nakamoto consensus mechanism and would make
double spending attacks possible. Hence, each cryptocurrency must
specify a unique ID, which can be used to derive the leaf of the
Merkle tree where the respective block hash must be located.

Source: https://alexeizamyatin.medium.com/a-technical-deep-dive-into-merged-mining-5b67706e1a19


Bitcoin-Qt icon not showing in Top Edge Panel (Linux Mint)

Known issue:

http://github.com/bitcoin/bitcoin/issues/1242


What does "operation not valid with the current stack size" mean?

The signrawtransaction RPC will verify the input scripts of the transaction after it signs it. If the transaction has not been fully signed (i.e. it isn't complete), then the script verification will fail and produce this error.

This also happens with multisig transactions. When you don't have enough signatures, the script will fail to verify with the error that you see.

See also: https://github.com/bitcoin/bitcoin/issues/9988


Converting WIF as Base58 string to byte array in bash

You need to use the decode flag -d:

printf "5HueCGU8rMjxEXxiPuD5BDku4MkFqeZyd4dZ1jvhTVqvbTLvyTJ" | base58 -c -d | xxd -p
800c28fca386c7a227600b2fe50b7cae11ec86d3bf1fbe471be89827e19d
72aa1d

To have xxd output all on one line, give it a large column number -c flag:

$ printf "5HueCGU8rMjxEXxiPuD5BDku4MkFqeZyd4dZ1jvhTVqvbTLvyTJ" | base58 -c -d | xxd -p -c 1000
800c28fca386c7a227600b2fe50b7cae11ec86d3bf1fbe471be89827e19d72aa1d

If you really want the checksum included 507A5B8D (the last 4 bytes), omit the -c flag which denotes checksum encoding:

$ printf "5HueCGU8rMjxEXxiPuD5BDku4MkFqeZyd4dZ1jvhTVqvbTLvyTJ" | base58 -d | xxd -p -c 1000
800c28fca386c7a227600b2fe50b7cae11ec86d3bf1fbe471be89827e19d72aa1d507a5b8d


How nodes solve cryptographic hash by random guesses in bitcoin network

Moreover, the hash function creates something like a 32byte number might be using SHA256. So, I want to know who creates random numbers? and how nodes do guessing?

It's a 32-bit number. There are only 2^32 possible values for a 32-bit number, about 4 billion, and realistic bitcoin mining hardware attempts trillions of hashes per second. So miners are just designed to try all of them which typically takes much less than a second.
Of course, the odds of any of them producing a valid block are very close to zero, given that only one miner succeeds on average every ten minutes. So the vast majority of blocks that miners attempt to mine turn out to be unmineable and the miner must try all 2^32 possibilities on a different block.


Hashrate comparison for multiple hash algorithms

It is not true (at least not in a direct ratio) for all hardware. Some algorithms will benefit more from more memory, or particular assembler instructions (eg, AES-NI). Some will benefit more from more hardware threads. So while most algorithms will follow a rough upcurve as system specs improve, you'll se more or less linear ones, and more or less plateauing or decelerating ones, and ones with different slopes on the more or less linear ones.


Don't know what the question is, so...

You sent
from:154Ky1D5jKLoViPA1ep1FqaxGa8LNWzmJh
to:  37gsnq1RYrUQrFy5jJvwUSBJBQYqSGdWnn

The payment is done and confirmed.

So, the address 37gsnq1RYrUQrFy5jJvwUSBJBQYqSGdWnn has the funds and it IS spendable.  You can only spend it if it is YOUR address.  If you sent the funds to someone else, then you likely know who you sent them to.  They can spend the funds.


Why use `update_add_htlc` when paying directly across a channel?

It is not necessary to use htlcs in the case of a direct payment. However as the protocol was designed with the idea to have a network of payment channels. This should allow multi hop atomicity of payments via htlcs.  For that the process with the htlcs to move forward the state in the channel operation protocol were necessary
I think from a design perspective it was cleaner to reuse this protocol for direct payments instead of implementing two protocols and make case distinctions


Does cancelling an order in BTC-E carry a fee?

A fee is charged over the filled portion. Either the whole order or partial.
If an order was cancelled before a trade took place (0% filled), no fee is charged.
If an order was cancelled after a portion was already filled, the remaining part is cancelled and no fee is charged over the remaining.


Where do I include my wallet address after finding the hash less than target - bitcoin

Mining a valid block involves multiple steps.

To begin with, you must know which block you are mining on top of, which is specified by the previous block hash.

Then, you must obtain a merkle root that locks in a valid set of transactions. Usually, this is a set of transactions from the mempool + the coinbase transaction, such that there are no double spends or invalid transactions. These transactions are assembled into a merkle tree, from which the merkle root is placed into the block header.

The coinbase transaction in particular is important, as it must follow the coinbase transaction rules (inclusion of block height, correct output for the block reward, extraNonce). It must be placed as the first transaction in the block, and contains the output that sends the BTC to your wallet.

Finally, you must add in the other fields such as block version, time, nonce, etc.

This complete block header of 80 bytes is the payload that is hashed and compared against the target value. If your resulting hash does not meet the target requirements, you must change the nonce in the block header, the extraNonce in the coinbase transaction, or any of the transactions in your merkle tree to obtain a new merkle root, and hash the new block header. This process is repeated until you find a valid hash for the target.

In order, your approach would be like:

Get a list of transactions you'd like to include (this can be an empty list)
Select your wallet address to receive the block reward
Build a coinbase transaction that pays this reward to your selected address (plus any transaction fees)
Make the coinbase tx the first one in your list
Build a merkle tree from this list
Select the merkle root from this tree
Proceed as you're doing already


How to sign a transaction with multiple inputs?

I found the way to do it, so, if anyone is interested, here is how to do it:

When you have more than 1 input, you don't have to remove the inputs that you are not going to sign, you have to remove only their scripts. So, if you want to sign the transaction posted in the question, the first hash would be calculated like so:

'version': 1,
'inputs': (2)
    {
    'output_tx_hash': 'aaaa',
    'output_position': 0,
    'script': the original script, like: '76a914' + hash + '88ac',
    'sequence': ffffffff,
    }, {
    'output_tx_hash': 'bbbb',
    'output_position': 1,
    'script': '', # Nothing
    'sequence': ffffffff,
    }
'outputs': (1)
    'value' : 100000
    'script' : '76a914' + hash of btc pub key + '88ac'
'locktime': 0

And the second hash:

'version': 1,
'inputs': (2)
    {
    'output_tx_hash': 'aaaa',
    'output_position': 0,
    'script': '', # Nothing
    'sequence': ffffffff,
    }, {
    'output_tx_hash': 'bbbb',
    'output_position': 1,
    'script': the original script, like: '76a914' + hash + '88ac',
    'sequence': ffffffff,
    }
'outputs': (1)
    'value' : 100000
    'script' : '76a914' + hash of btc pub key + '88ac'
'locktime': 0

Hope it helps anyone.


Intuition for Simplicity's CheckSigHashAll

Your understanding of the commitment root is correct.  Taking advantage of Haskell's laziness, feel free to put undefined into the signature when computing the commitment root.

At the moment, the witness root is not used in the protocol.  There are some ideas on how to use it in more sophisticated protocols, but those ideas haven't been realized yet.  However, the witness root has some uses in testing and development regardless.

Simplicity doesn't use BIP-Schnorr per se.  Rather checkSigHashAll is a Simplicity expression that implements an old draft of BIP-Schnorr.  If you want a signature scheme that supports key recovery, you could implement such a scheme in Simplicity.

Neither the commitment nor witness roots contain any transaction data, mock or otherwise.  Instead the checkSigHashAll Simplicity expression contains primitives that, during Simplicity execution, return the transaction's locktime and version

To make a simple 2-of-2 multisig you could write something along the lines of

 pkwCheckSigHashAll <pubkeyA> <sigA> &&&
 pkwCheckSigHashAll <pubkeyB> <sigB> >>>
unit

Since both branches are used in a 2-of-2 multisig, there are no MAST branches.

To make a 1-of-2 multisig you have some options.  One way is

 witness <value of type (Bit, Sig)> >>>
 cond (scribe <pubkeyA> &&& iden) (scribe <pubkeyB> &&& iden) >>>
 checkSigHashAll

However, even after pruning (turning the case within the cond into an assert), the program appear a lot like a 1-of-2 multisig.

Another implementation could be

witness <value of type Bit> &&& unit >>>
cond (pkwCheckSigHashAll <pubkeyA> <sigA>)
     (pkwCheckSigHashAll <pubkeyB> <sigB>)

In this case after pruning it looks like a 1-sig-or-something else.  Pruning transforms the above expression into something like

witness <0> &&& unit >>>
assertl (drop (pkwCheckSigHashAll <pubkeyB> <sigB>))
        (commitmentRoot (drop (pkwCheckSigHashAll <pubkeyA> <sigA>)))

where only the commitment root of the untaken branch is revealed.

Be aware that as of the time of writing this, pruning has not been implemented, nor is it the case that pruned expressions are yet enforced by the implementation.  You can still prune expressions by hand though.


Track transactions for a list of addreses not in a wallet

Bitcoin Core does not allow you to track transactions for addresses that are not in your wallet.

If you wish to do this, you will need to maintain a separate index outside of the bitcoind node, either by scanning each incoming block for transactions involving your address, or by using an external api such as Blockchain.com or insight to query for your addresses.


Sure, it's possible. In fact, this is exactly what the Large Bitcoin Collider does - It has successfully located a few private keys, mostly from a puzzle transaction that seems to have been made to test its progress.

That said, it would still take you an unreasonably long amount of time - The Large Bitcoin Collider took 1 year and 3 months to search 8,000,000,000,000,000 keys (8000 trillion).

There are 2^256 possible keys. Even if you are able to search 1000 trillion keys per second, it would take you 2.7×10^44 × age of the universe to go through all the keys. It's simply not feasible.

As pointed out by G.Maxwell in the comments, the Large Bitcoin Collider should be not be interpreted as a viable, secure, or even reasonable approach to this problem. There have been concerns about its safety and accuract (reddit source).


You are using the testnet which uses 2 instead of 3, but as far as i know it is impossible to tell if something is a multisig or segwit adress when they both start with 3 on the "real" bitcoin chain, It could be both..

However you can indeed be sure that it is a segwit adress when they start with BC1, these are so called bech adresses. See more here, https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki


Is it possible to brute force bitcoin address creation in order to steal money?

It is possible to brute force some Bitcoin addresses, because some people generate their private keys in an insecure manner.  Any (non-zero) 32 bytes can be a private key.  So running sha256 over a passphrase gives an apparently random, but brute force-able private key.

Take sha256("sausage") for instance:

$ echo -n 'sausage' | sha256sum
30caae2fcb7c34ecadfddc45e0a27e9103bd7cfc87730d7818cc096b1266a683  -

Load up bitaddress and paste that private key into the 'wallet details' tab to get the corresponding Bitcoin address, then look it up on blockexplorer:

$ GET http://blockexplorer.com/q/getreceivedbyaddress/1TnnhMEgic5g4ttrCQyDopwqTs4hheuNZ; echo
0.01000000

and you'll see that the address held one bitcent for about 2 days in February 2012.

See also: "fuckyou", which held 2.5 bitcents for 12 festive days at the turn of last year.

So in practice it's possible to brute force bitcoin address creation, but only for poorly chosen passphrases.  These were probably just people playing around with the idea of "storing bitcoins in their head" which is why they are for such small amounts, and why they weren't left funded for long.

No address balances were harmed in the making of this answer.


The bitcoin-explorer (bx) command at mnemonic-to-seed throws exceptions if the checksums don't don't add up.

When you find combinations of BIP 39 words that pass checksum tests, then perform an operation like this to identify Bitcoin compressed Bitcoin addresses that might have funds:

% echo "bunker wreck real edge inflict aerobic buddy mercy divorce wolf bright immune fat foot poet section sustain reveal unique reflect have latin problem chapter" | bx mnemonic-to-seed -p 123 | bx hd-new | bx hd-private -d -i 44 | bx hd-private -d -i 0 | bx hd-private -d -i 0 | bx hd-public -i 0  | bx hd-public -i 0  | bx hd-to-ec | bx ec-to-address -v 0

1Ec2nBkUMSQmmhxWeXMB98gFVCKTmHbRJb

Then examine the results of https://blockchain.info/address/1Ec2nBkUMSQmmhxWeXMB98gFVCKTmHbRJb to see if there was ever any wallet activity for M/44'/0'/0'/0/0.

This approach for older BIP 44 P2PKH addresses can be automated with scripts. This approach can also be extended to accommodate newer segwit-related BIP 49 P2WPKH-nested-in-P2SH addresses that begin with the number 3. The basis for doing so is provided below.

% echo "bunker wreck real edge inflict aerobic buddy mercy divorce wolf bright immune fat foot poet section sustain reveal unique reflect have latin problem chapter" | bx mnemonic-to-seed -p 123 | bx hd-new | bx hd-private -d -i 49 |  bx hd-private -d -i 0 | bx hd-private -d -i 0 | bx hd-private -i 0 | bx hd-private -i 0 | bx hd-to-ec | bx ec-to-public | bx bitcoin160
351d3fffea471eb3740a5661cf059b5eb73483dd

% echo "0 [351d3fffea471eb3740a5661cf059b5eb73483dd]" | bx script-to-address -v 5
35QwHbjUTo31tyTJruMPbrokCqjaTVdmTr


Why is average time for block 8 minutes, when the target is recomputed to keep it 10 minutes?

The network difficulty is recalculated every 2016 blocks.  The difficulty is adjusted based on the duration of the most recent 2016 block interval.  The difficulty can adjust up or down at most by a factor of 4.

Currently, the network is growing rapidly.  The network finds blocks at a faster rate than one per 10 minutes because the current difficulty is based on the hashrate of the previous difficulty interval.


How can I create a node on Liquid Sidechain?

The Liquid sidechain is a private sidechain. To get access to it, you must contact Blockstream. See https://blockstream.com/liquid/


Why do we trust that the person who got a chance to add block will add a valid transaction block?

Miners don't calculate nonces, they calculate cryptographic hashes using nonces as one of the inputs.

A cryptographic hash is a function that takes as input some arbitrary data and produces as output a unique string.[1]  They always produce the same output string for the same input data.  Here's an example using the sha256 hash function (the basis for the function used in Bitcoin):

$ echo foo | sha256sum
b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c  -
$ echo foo | sha256sum
b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c  -
$ echo bar | sha256sum
7d865e959b2466918c9863afca942d0fb89d7c9ac0c99bafc3749504ded97730  -

In the above, "foo" and "bar" are the input and the strings starting with b5bb and 7d86 are the output.

What miners attempt to do is find a hash output that has a certain number of zeros in a certain location (we usually call this the start or front of the hash[2]).  To do this they start with the data they want to add to the ledger and then increment a nonce (or otherwise adjust the block) until they get the desired value.

For example, let's say we want to add a transaction of "Alice pays Bob 10 BTC" to the ledger and the number of zeros we want at the start of the hash is just 1.  We start by doing this:

$ echo "Alice pays Bob 10 BTC | nonce: 0" | sha256sum
39a946f968d6986b2d560bbb0d63af04578352f02f48c1bfd71e535cd1148a6f  -

As you can see, our first nonce of "0" didn't produce a hash starting with 0.  So we try again:

$ echo "Alice pays Bob 10 BTC | nonce: 1" | sha256sum
dce8dff1c536cdb43861e4ea1bc843e6f110e82768cfcca656d8c5f53cc7fc1d  -

Again, we don't get the desired result.  So we keep trying over and over until we do get the desired result:

$ echo "Alice pays Bob 10 BTC | nonce: 18" | sha256sum
005b8307be5a9447be13ba6f026e9d3b695bfd5dc6ce633ac928de8cd8634a1f  -

So we had to do the work of generating a hash 19 times before finding a hash starting with the number zero.  This is called proof of work.

Now the person who found this proof of work can share all of the data---both the transaction and the nonce---to other people, and those people can verify that the input data of "Alice pays Bob 10 BTC | nonce: 18" does equal the a hash with one zero worth of proof of work.

One zero worth of proof of work isn't much (it's 4 bits or odds of 1:15), but real miners deal with much greater amounts and producing all of the work requires consuming a large amount of electricity.  Normally miners are rewarded for consuming that electricity by receiving a reward for protecting transactions with proof of work---but they only receive the reward if the transactions they protect are valid.[3]  Otherwise any proof of work they generate is wasted, meaning the electricity they use is wasted and they'll be less profitable than other miners who protect valid transactions.

For example, in the above example, if Alice didn't have 10 BTC to give to Bob, then that transaction would be invalid and so it wouldn't matter that the hash of the data starts with a zero---users who verify every transaction using what's called a "full node" will simply ignore that transaction and its proof of work.

So in short, what prevents a miner from adding an invalid transaction to the ledger is a combination of users who reject invalid transactions with their full nodes and an economic incentive paid to miners who mine valid transactions.

[1] Hash functions don't always work like this, but that's the ideal.

[2] But that's because Bitcoin displays hashes weirdly.  To any other tool, it'd be the end or back of the hash.

[3] Technically, they only receive the reward if other people think their transactions are valid.  Currently, there are a lot of Bitcoin users who verify every transaction, so it's not possible to sneak in an invalid transaction.  In other cryptocurrencies or a sad future where Bitcoin becomes less secure, that may not be the case


What is the bitcoind command to send all coins to another address?

To be strict, OP asked to send all coins, which @mschuett didn't answer.

The key thing to do this is the last optional bool argument of the sendtoaddress RPC command called subtractfeefromamount. The way to use it is:

bitcoin-cli walletpassphrase <passphrase> <timeoutInSeconds>
bitcoin-cli sendtoaddress <bitcoinaddress> `bitcoin-cli getbalance` "" "" true


A lot of people who accumulated thousands of coins in the early days spent them on silly things or cashed out during the 2012 bubble.  Lazlo for example, spent 10,000 bitcoins on two pizzas. Nobody knew that bitcoin would rise to the prices we briefly saw in 2013 or that we have today. The same thing will happen again, people have a price and will very likely sell on the way up thereby distributing their 'cheap' early coins to others; it should all balance out in a decade or two.


How to get a readable format of curl with a transaction?

This was just a problem of the terminal I used on a mac.

Adding | python -m json.tool to the command does the trick, as described here.

Output now is:

bitcoin@raspberrypi ~ $ curl https://blockchain.info/unspent?active=1Cdid9KFAaatwczBwBttQcwXYCpvK8h7FK | python -m json.tool
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  3571    0  3571    0     0  10043      0 --:--:-- --:--:-- --:--:-- 10087
{
    "unspent_outputs": [
        {
            "confirmations": 314772,
            "script": "76a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac",
            "tx_hash": "f2c245c38672a5d8fba5a5caa44dcef277a52e916a0603272f91286f2b052706",
            "tx_hash_big_endian": "0627052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2",
            "tx_index": 47854970,
            "tx_output_n": 1,
            "value": 8450000,
            "value_hex": "0080efd0"
        },
        {
            "confirmations": 259155,
            "script": "76a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac",
            "tx_hash": "0365fdc169b964ea5ad3219e12747e9478418fdc8abed2f5fe6d0205c96def29",
            "tx_hash_big_endian": "29ef6dc905026dfef5d2be8adc8f4178947e74129e21d35aea64b969c1fd6503",
            "tx_index": 71083209,
            "tx_output_n": 0,
            "value": 100000,
            "value_hex": "0186a0"
        },
        {
            "confirmations": 251314,
            "script": "76a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac",
            "tx_hash": "d9717f774daab8d3dd470853204394c82e3c01097479575d6d2ee97d7b3bdfa1",
            "tx_hash_big_endian": "a1df3b7b7de92e6d5d57797409013c2ec8944320530847ddd3b8aa4d777f71d9",
            "tx_index": 75974855,
            "tx_output_n": 0,
            "value": 1000000,
            "value_hex": "0f4240"
        },
        {
            "confirmations": 245427,
            "script": "76a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac",
            "tx_hash": "3f1df69df90d097981ca9c97ad8b6a32daed345565a433f8c8e472b2dab2ac79",
            "tx_hash_big_endian": "79acb2dab272e4c8f833a4655534edda326a8bad979cca8179090df99df61d3f",
            "tx_index": 79887883,
            "tx_output_n": 1,
            "value": 719787,
            "value_hex": "0afbab"
        },
        {
            "confirmations": 165236,
            "script": "76a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac",
            "tx_hash": "417bdb6f5db3e830407f94d1a82d1667e738b19da3679b7263ebfb913394efdd",
            "tx_hash_big_endian": "ddef943391fbeb63729b67a39db138e767162da8d1947f4030e8b35d6fdb7b41",
            "tx_index": 170905487,
            "tx_output_n": 0,
            "value": 10000,
            "value_hex": "2710"
        },
        {
            "confirmations": 162698,
            "script": "76a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac",
            "tx_hash": "d049d6039f9d1cb2625bac294d7465b4b1077bd5bc0e30e01e02b184db524c1f",
            "tx_hash_big_endian": "1f4c52db84b1021ee0300ebcd57b07b1b465744d29ac5b62b21c9d9f03d649d0",
            "tx_index": 174630347,
            "tx_output_n": 0,
            "value": 11100,
            "value_hex": "2b5c"
        },
        {
            "confirmations": 161792,
            "script": "76a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac",
            "tx_hash": "b8a6470c7a38d0983effed00a3f75c74ba371da1387352f35d1df155851ea8d1",
            "tx_hash_big_endian": "d1a81e8555f11d5df3527338a11d37ba745cf7a300edff3e98d0387a0c47a6b8",
            "tx_index": 175949432,
            "tx_output_n": 0,
            "value": 10000,
            "value_hex": "2710"
        },
        {
            "confirmations": 161783,
            "script": "76a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac",
            "tx_hash": "a2b9570e26e3991fc999c42dc8c6eea7b06514b61814da1a71b56c6ba2ae651c",
            "tx_hash_big_endian": "1c65aea26b6cb5711ada1418b61465b0a7eec6c82dc499c91f99e3260e57b9a2",
            "tx_index": 175955161,
            "tx_output_n": 0,
            "value": 10000,
            "value_hex": "2710"
        },
        {
            "confirmations": 161783,
            "script": "76a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac",
            "tx_hash": "05230cb8cd8c6a3788ed41433dfdd68a1a608cc8feb3bc1c29d97ce84bec070e",
            "tx_hash_big_endian": "0e07ec4be87cd9291cbcb3fec88c601a8ad6fd3d4341ed88376a8ccdb80c2305",
            "tx_index": 175955664,
            "tx_output_n": 0,
            "value": 10000,
            "value_hex": "2710"
        },
        {
            "confirmations": 76598,
            "script": "76a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac",
            "tx_hash": "bd345c2bdbb8c17a0c66a8579ea701830e8248ba21b2d73a5dca21d8e9175fee",
            "tx_hash_big_endian": "ee5f17e9d821ca5d3ad7b221ba48820e8301a79e57a8660c7ac1b8db2b5c34bd",
            "tx_index": 338789479,
            "tx_output_n": 1,
            "value": 3020,
            "value_hex": "0bcc"
        },
        {
            "confirmations": 44566,
            "script": "76a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac",
            "tx_hash": "892275c430610334994cc5836436515057284cc4572775487c1b06a1b49c5ab4",
            "tx_hash_big_endian": "b45a9cb4a1061b7c48752757c44c28575051366483c54c9934036130c4752289",
            "tx_index": 384311717,
            "tx_output_n": 1,
            "value": 6236,
            "value_hex": "185c"
        }
    ]
}


Whats the use of QR-codes during wallet to wallet transfer?

The QR code is simply a convenient way of sharing an address, to avoid having to type it.  It encodes exactly the same information as the alphanumeric address and provides no additional security.  If you have another way of giving someone an address (e.g. sending it to them by email), there is no need to use a QR code at all.

How the other person verifies that the address is yours is something that you have to solve for yourself; Bitcoin itself doesn't provide features to help with this.  For instance, you could send the address via a PGP signed email, or make it available on an HTTPS website, or ask the person to telephone you and verify the address.  But it is an important issue; if an attacker impersonates you and the other person pays their address instead of yours, the attacker will get the coins and there will be nothing anyone can do about it.

There is nothing you need to do after receiving coins.


So according to this wiki[1] your GT430 can run at 20 MHash/s. And if you plug 20 MHash/s into the mining calculator[2] you're looking at around $0.08 a day in revenue. Your daily power consumption will be larger than that.

Or to think of that another way, the current rates mean $0.41 USD/24h@100MHash/s, and you're one-fifth of that.

8 cents per day. That's a long way to save for a car.

[1] https://en.bitcoin.it/wiki/Mining_hardware_comparison
[2] http://www.bitcoinx.com/profit/


Does mnemonic phrase contain everything in my wallet including future keys?

Generally, yes, mnemonic phrase contains enough data for software wallets to derive the keys. With the caveat.
Some software wallets imports are supporting only 12 word or 24 word combinations. Some support different BIPs and thus path derivation schemes (32/44/84) by default, and some only single one of them. Some have additional feature for a specific seed passphrase. All of the differences you can check on https://walletsrecovery.org/
And there are at least three popular mnemonic schemes:

bip39 - used in most cases
aezeed for lnd
electrum format

So to answer your question in practice - you have to install the wallet that uses the same seed format and path derivation as the one you've originally created for it to work.
Answering edit section:
Because BIP44 (which coinomi uses) defines derivation as:
m / purpose' / coin_type' / account' / change / address_index

You can derive multiple types of independent cryptocurrency paths from a single seed by changing coin_type parameter, creating a subtree for every coin type. This is a list of registered coins:
https://github.com/satoshilabs/slips/blob/master/slip-0044.md


In the Ardor platform, what are all the different "types" and "subtypes" in a transaction?

Use the getConstants API and check the "transactionSubTypes" JSON array for a mapping of transaction types and sub types to their display name.

"transactionSubTypes": {
    "AssetIssuance": {
        "isPhasable": true,
        "subtype": 0,
        "mustHaveRecipient": false,
        "name": "AssetIssuance",
        "canHaveRecipient": false,
        "isGlobal": true,
        "type": 2,
        "isPhasingSafe": true


Previous versions of bitcoin core included a miner, and you could use the RPC call setgenerate to activate it. However, this functionallity was removed on Bitcoin Core v0.13.0. In any case, this does does not seem to work on regtest (I have tried it with v0.11.1 and it returns a message saying to use generate instead).

Whenever I need to "simulate" nodes competing to mine in a regtest network, I define their mining power and randomly select which one of them is going to mine taking into account their defined mining power. Then, I send a generate 1 RPC call to the miner that has been selected.


How does lnd make sure it does not reuse the same route twice for a retry after the first payment failed?

So I went ahead and looked at the LND implementation here: https://github.com/lightningnetwork/lnd/blob/master/routing/pathfind.go and this is the comment block above the function findPath:

  findPath attempts to find a path from the source node within the ChannelGraph to the target node that's capable of supporting a payment of amt value. The current approach implemented is modified version of Dijkstra's algorithm to find a single shortest path between the source node and the destination. The distance metric used for edges is related to the time-lock+fee costs along a particular edge. If a path is found, this function returns a slice of ChannelHop structs which encoded the chosen path from the target to the source. The search is performed backwards from
  destination node back to source. This is to properly accumulate fees that need to be paid along the path and accurately check the amount to forward at every node against the available bandwidth.

If this is the case then I don't think your scenario would play out. It appears LND wouldn't return the path A --> B --> C --> D because it does not have sufficient balance/bandwidth.


When you add or alter a DNS record you need to update the serial number in the zone data and take into account the TTL (time to live) which is used by clients as a cache refresh interval.

If you are using a hosting provider's web-based control-panel, it probably takes care of the serial number for you but it won't adjust the TTL in advance of the change. Therefore your change can take a while to propagate through third-party and client DNS caches.

NXDOMAIN means "no such domain" - so far as the nearest DNS server is concerned, it has a still-valid set of data for the parent zone and that does not contain the delegation you enquired about.

$ dig +nocmd +multiline +noall +answer machinenode.de
machinenode.de.         600 IN A 50.63.202.40

$ dig +nocmd +multiline +noall +answer dnsseed.machinenode.de
dnsseed.machinenode.de. 30 IN A 92.242.132.15

Those numbers 600 and 30 are the TTL values.