GNU Screen is often the ideal tool to run interactive programs in the background. You can also run it with --syslog and/or --api-listen to have a more traditional daemon-type process.


In a perfect world, should RIPE160 be used as the block ID or transaction ID?

The malleability problem is not with the hashing function, but with what is being hashed (or not). The hashed data is malleable, not the hash directly.


I don't think that is possible with only nLockTime. There are however "smart" contracts, by using a 2-of-2 multisignature where each party deposits an insurance worth more than the shared secret. The economic loss is more than they gain if both parties don't follow through on their part of the deal.

On a note, this would actually be possible with the technology currently used ZCash. Using zk-SNARKS, you could generate proof that a piece of content is encrypted by key X. In that same zk-SNARK signature you could prove that hash(X) = Y and create an economic construct that will only allow a transaction after X is revealed, creating Y and allowing a party to get their money.


In ScriptSig, which form of the public key is considered canonical?

Both are valid and accepted as canonical. They are NOT interchangeable however - the same public key in compressed form is hashed to a different address than that in uncompressed form. You can only use compressed form if the unspent output address is compressed.


If you are starting off, I will assume you do not have the computing power to solo-mine.

It's just easier to join a pool, and with regards to trusting one, I would stick with something that has been around for a while. For Litecoin I've used wemineltc and have no complaints.


Bitcoind daemon keeps getting "killed" on AWS

Configure some swap space, you are probably running out of memory, check with

dmesg on your instance for additional messages.


It doesn't have a 24-hour block time, it issued all its PoW coins in the first 24 hours of existence.

The math you're looking for is nTargetSpacing * LAST_POW_BLOCK, which multiplies to 86400, the number of seconds in 24 hours.

As you can see from their home page (screenshot), that worked out about as well as you'd expect.


Zcash is based on a base currency. As far as I know it is bitcoin, right?

Zcash is not based on a base currency; it is an independent block chain. The code was built on a fork of Bitcoin Core 0.11.2 (and since then has had numerous backports of subsequent upstream changes).

  I guess the coins in the shielded pool are zcoin, right?
  How about the unshielded pool? Are they bitcoins or zcoins? (i.e. the marketcap of zcoins consists only of the coins in the shielded pool or both pools?

All pools within the Zcash block chain contain ZEC. There are three pools within Zcash:

The unshielded pool (containing ZEC stored in transparent addresses).
The Sprout shielded pool (containing ZEC stored in Sprout shielded addresses).
The Sapling shielded pool (currently zero, but will start being used once Sapling activates).

ZEC is moved between the various pools when transactions send ZEC from one type of address to another, e.g. from a transparent address to a Sprout shielded address (see this blog post for more details).


Can Bitcoin mining hardware be used for other Crypto coins?

You can do, if they are using the same mining algorithm. Bitcoin is using SHA256, here is a list of other coins using the same algorithm:

SHA256-Coins

Other coins like Litecoin are using the Scrypt algorithm, those are not compatible with bitcoin mining hardware.


There's no way to go backwards from the public key to the private key, that would mean that anyone could steal your Bitcoin.

You might be able to do something with that passkey you have saved though. Is it a list of words? Do you remember what app you were using?

Edit: Looks like you actually have a passkey that was used to generate a private key and not a Mnemonic backup. Have you tried putting the private key into the 'wallet details' section of this website: https://www.bitaddress.org/ ?

Note that you can use the site offline and I recommend it.


Does blockchain.info retain the wallet password in client-side memory?

I guess that it must have, because it updates the server after any modifying operation is made, without asking for a password.

That is DannyHamilton claims as well. See also.


How to generate the hash of public key in Bitcoin

I'm starting to wonder how difficult it is to find people who are helping others in this site

I don't have your same idea, but sorry for the delay in the answer but in Italy exist at the moment the alert "coronavirus".

My test to resolve your problem

I don't know the language of the code that you have public in the question but I have a project to decompiler script bitcoin but is in the start phases.

I'm answering with C++ code.

Exist two types of Public key, that is compressed and uncompressed, the difference is:

Compressed public key started with a flag "02" (I think this is your cases)
Uncompressed start with the flag "03"
If the you key start with "04" doesn't is the public key but is a P2PK script.

But a good reference that explains the compressed public key is this What is a compressed Bitcoin key?

So, I think your error is the public key input,your public key is 02b4632d08485ff1df2db55b9dafd23347d1c47a457072a1e87be26896549a8737 and not 2b4632d08485ff1df2db55b9dafd23347d1c47a457072a1e87be26896549a8737, you have lose the the part of flag of the compressed public key.

So, my C++ code to test my idea is this:

    cout << "Test for Bitcoin.stack question" << endl;
    cout << "Public Key: " << "02b4632d08485ff1df2db55b9dafd23347d1c47a457072a1e87be26896549a8737\n";
    string keyTmp = "02b4632d08485ff1df2db55b9dafd23347d1c47a457072a1e87be26896549a8737";
    string flag = keyTmp.substr(0, 2);
    if(flag == "02"){
          cout << "Compressed with y event";
    }else if(flag == "03"){
      cout << "Compressed with y odd";
    }else{
      assert(flag == "04");
    }
    Bytes bytesTmp = hexBytes(keyTmp.c_str());

    //SHA256
    Sha256Hash shaHash = Sha256::getHash(bytesTmp.data(), bytesTmp.size());
    uint8_t result[Ripemd160::HASH_LEN];
    Ripemd160::getHash(shaHash.value, sizeof(shaHash), result);

    cout << "Hash Public key: " << ToString(result);

The hash public key ofter run this code is: 93ce48570b55c42c2af816aeaba06cfee1224fae

References

The reference of the project are off-topics here but I think without it this post can be fake, so I'm adding the reference of the library used to implement my code in this answer.

Bitcoin-Cryptography-Library
decompiler-bitcoin-script: this is my start project to undestend how bitcoin script work, so you can found the idea if you want implement other feature inside your work.
Github gits code


bitaddress.org: is the public key the same as the Bitcoin address?

No, they're not the same thing. Paper wallets are not generated differently as/in to comparison to normal wallets.
a bitcoin adress is part of a public key.

The address is at its most basic just a hash of the public key. The hash functions involved (RIPEMD-160 and SHA256) are cryptographic hash functions. They are often also referred to as one-way functions, which is exactly the reason why you cannot derive the public key from the address.
Oneway functions provide exactly that a = f(pk) so that given a you cannot derive pk.

So, an adress is basically the hash of a public key. x/x
Some good more indepth explanations of the differences here -> https://www.reddit.com/r/Bitcoin/comments/3filud/whats_the_difference_between_public_key_and/ctp3fc7/?st=jald5nmq&sh=620d5934
And, how the adress is derived from the public key is explained here ->
https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses


How many bitcoins will there eventually be?

Every block introduces 50 new coins in the system. This quantity (50) halves every 210,000 blocks. So, getting the limit of coins it is possible to generate is quite easy : it's the sum of a geometric series.

Also, note that this is an upper bound ; the actual quantity will probably be a bit lower due to rounding issues (BTC has a finite number of decimals, 8).


How do I determine the balance of an address I don't own? (WebAPI or local API)

You can query the unspent outputs of an address with this:

 http://blockchain.info/unspent?active=$bitcoin_address

You can get the transaction history for an address with this:

 http://blockchain.info/address/$bitcoin_address?format=json

For more information see http://blockchain.info/api/blockchain_api


From "The Unreasonable Fundamental Incertitudes Behind Bitcoin Mining" (page 40):
  With current bitcoin software [6, 7], at certain moments in time the reward for mining is divided by two in one single step. This is NOT compensated by the fact the the diffculty of mining increases all the time. It just adds sudden adjustments every 4 years to a diffculty curve which typically goes systematically up due to a steady increase in the production of new hashes. We predict that in the future the difficulty curve will have a discontinuity at the moment of the 4-year halving. Until now it has not happened because apparently only very small percentage of active mining devices were switched off on 29 November 2012.
  Inevitably, on one day many devices will stop being profitable and many people may lose their interest in bitcoin. We are talking about the human factor. Investors may decide that they are no longer going to give lots of money to a high-tech industry which has just decreased production of hashes per second and is binning many mining machines at a massive scale due to a strange rule which has no justification and could easily be modified. They might move their money elsewhere and invest in another cryptocurrency. Overall we expect that a sudden slump in profitability of mining is likely to provoke some sort of a much larger ripple in the bitcoin markets, potentially lasting up to 4 full years.

The paper appears to make the argument, that the miner compensation is already decreasing through the rising difficulty, and that the reward halvings will cause sudden drops in mining power which in turn will "provoke some sort of a much larger ripple in the bitcoin markets, potentially lasting up to 4 full years." As "people may lose their interest in bitcoin", when their devices stop being profitable. This is because "We are talking about the human factor.".

The presented argument is weak and thinly supported. While the taking effect of the reward halving is sudden, it is well-known and predictable years in advance within a reasonably small timeframe. Professional miners can easily plan their mining capacity and purchases to factor in the reward halving. There is likely to be a reduction in mining capacity, but it is not obvious, let alone inevitable, why the halving event should turn away people. Also, the mining equipment which will be obsoleted would mostly be comprised of less efficient older models, likely to present a smaller portion of the total mining power.

Further, it seems likely that corporate entities with a sufficient stake in Bitcoin would consider either some in-house mining or subsidy of global mining an acceptable cost to protect their previous investments by supporting the network, should the security of the network be in serious doubt.

Should Bitcoin become sufficiently pervasive, we might actually see Bitcoin mining financed as a public good, similar to other networks such as electricity and roads.

Conclusion: The paper does not comprehensively discuss potential effects of the halving, but rather asserts a specific scenario, which it supports unconvincingly.


What happens if you set prune= to a value between 0 and 550?

It turns out that prune=1 is a new special case which enables manual pruning. For values of N from 2 to 549, prune=N shows an error.

Bitcoin Core parses configuration arguments in the init.cpp. Depending on the value of prune=<N>:

N < 0 – returns the error: "Prune cannot be configured with a negative value."
N = 1 – Activates manual prune mode as described in Pieter's answer. It causes Bitcoin Core not to advertise blocks anymore and enables the pruneblockchaincommand, but it doesn't automatically prune the blockchain data.
1 < N < 550 – returns the error "Prune configured below the minimum of N MiB.  Please use a higher number."
550 ≤ N – Sets N as the limit of MiB available for block data.


No, private keys are randomly picked from the space of 256-bit numbers. A private key cannot be recovered from the address, otherwise anyone could take any other user's funds at will. If your friend doesn't have additional information such as e.g. a set of seed words, or a backup, it is infeasible to rediscover the private key.


You are not being hacked.  These are not two separate transactions; it is one transaction with two outputs.  The second output was automatically created by your wallet client and sends back to a new address which also belongs to you.  This is a normal and necessary feature of how Bitcoin works, called "change". See How does change work in a bitcoin transaction?

If this transaction were malicious, it would mean that someone had access to your private key; if so, they would also have stolen your earlier transaction.  Moreover, they would  have stolen the coins as soon as they obtained the key; they wouldn't have waited for you to make your own transaction.


Why doesn't the block-chain have an offline functionality?

https://en.wikipedia.org/wiki/CAP_theorem

Point.


Is performance really important when choosing a language for a trading bot?

The latency for gathering information and executing decisions will swamp the performance difference between languages. That assumes you don't write horribly awful code, but you can do that in any language. You should use whatever language you are most proficient in or whichever one you find easiest for the task.


The bitcoins were received by the address and then spent, leaving the address with no balance. It appears both transactions are confirmed.


Redeem script. script hash, witness script and witness program

The scriptPubKey is the script as it is placed in the transaction output.
The redeemScript (P2SH only) is the script pushed as the last scriptSig item. In P2SH scripts, the scriptPubKey is equal to OP_HASH160 <Hash160(redeemScript)> OP_EQUAL.
The witness script (P2WSH only) is the script in the last witness stack position.
The witness program is Hash160(pubkey) for P2WPKH, and Hash256(witness_script) for P2WPKH. For native segwit outputs the scriptPubKey is OP_0 <witness_program>; for P2SH-wrapped segwit outputs the redeemScript is OP_0 <witness_program> (and thus the scriptPubKey is OP_HASH160 <Hash160(OP_0 <witness_script>)> OP_EQUAL.


Are there any services offering blockchain.info-like API for multiple currencies?

BlockCypher is adding support for Litecoin, we're currently downloading the LTC block chain and will put it out next week. All the  Bitcoin APIs will work in the same way for Litecoin.


sign and verify a message in Bitcoin Core 0.13.1 (OSX)?

The message signing function in Bitcoin Core uses a different extra compact format for encoding signatures. The algorithm is also intentionally incompatible (through an extra hashing step) with the one used in transactions, to avoid people being tricked into signing a transaction.


Most current such systems (Ethereum, Neo, WAVES, etc.) rely on proof of work to secure the blockchain and issue the native token (ether and waves are issued, Neo was all generated at genesis).

The incentives in these cases are:

Transaction fees gained by executing contract transactions
Block reward, if it exists

There are also a number of private blockchain systems, such as Hyperledger, where the incentive is that the businesses maintaining the network will presumably reap some benefit from its continued functioning.


What wallets are compatible with Satoshi Dice?

Satoshi dice uses the same address bitcoins were sent to send them back. There no wallet that does not permit that, how could you spend coins if at first you cannot receive them. The kind of "wallet" satoshi dice is refering to is like you try to spend bitocoin from a broker service (like Mt.Gox) the address they use is not assured to be yours (and the coin will not return back to you)


How to run bitcoind (command line client) without connecting to other nodes?

I see two approaches:

Use --connect <hostname> with the hostname set to something that doesn't exist.
Unplug from the network.


Bitcoin does not work with strings and hashing, you first need to convert to binary. On Unix systems, you can use xxd to convert string to binary (into file).

See also here:

Verifying a bitcoin trx on the Unix cmd line with OpenSSL?


Is it possible to have a failed Bitcoin transaction on the block chain?

No. Invalid transactions do not get included in blocks in Bitcoin.

There is also no receipt concept in Bitcoin. All nodes run full verification and check transactions against their own UTXO set when importing a block. Therefore any invalid transaction will also cause a block to be invalid as well.


What are atomic multi path payments (AMPs) and why/how is it being implemented in Lightning Network?

The Current Problem

The major challenge in the current routing mechanism is finding channels with sufficient balance on one side of a node to forward an incoming payment. To be more descriptive, the channel_announcement or the channel_update messages that are broadcasted contains the short_channel_id through which lightning nodes can look up the transaction in the Bitcoin blockchain and find out how many bitcoins are locked in that channel. However, one does not know how much each node of the channel holds. This creates an issue in terms of routing a payment as one side of the channel may not have enough balance to forward the transaction resulting in a routing failure and the origin node has to retry the payment using a different route.

The second issue is with origin node channel balances. Say I am buying a cup of coffee from Starbucks that costs me 20,000 satoshis. Now I have three open channels in the lightning network with my balance equal to 9,000 satoshi in each channel. Neglecting channel reserve balance and transaction fees for now, I can only make payments of 9,000 satoshis in each channel, which makes me incapable of buying that cup of coffee in a single payment. The get around would be to make three payments to the same payment invoice that Starbucks offers me when buying that cup of coffee across all three channels. But this renders security issues, from hash re-use. A node having channels across the paths can use the pre-image it learnt from one path to fulfill a payment along the other path. Also, if only a partial payment went through then I would be at the mercy of Starbucks to refund me the partial payments I did earlier.

The third issue is that at the moment (although temporary) we have a limit of 232 milli-satoshi (~0.0429 BTC) on a single payment size. Payments above this limit needs to be done via multiple payments. But this again brings the risk of one payment going through and subsequent payments failing to reach the receiver. You are then left to ask the receiver to process a refund to you.

The Solution

Conner Fromknecht and Olaoluwa Osuntokun proposed Atomic Multi Path (AMP)  payments in order to solve both the above issues by breaking a larger payment into smaller ones while at the same time not re-using any payment hashes across all the smaller payment flows, and adding a strong guarantee that the receiver won't be paid at all until all partial payment flows are completed (atomicity).

Their proposal required the sender to send some secret s_i to the receiver in each smaller payment i. When all payments have been received by the receiver, it will then construct the base payment (BP) secret by taking XOR of all the partial secrets that were sent by the sender, such that BP = s_1 ^ s_2 ^ ... ^ s_n. Now each payment pre-image is SHA256(BP || i). This had the advantage that the receiver could not create the pre-image until all partial payments have been received, thus solving the partial payment as well as the hash re-use issue.

This form of payment proposal is really helpful if done between friends, however, for business usage this proposal has a weakness. We consider the receipt of a pre-image as a cryptographic proof that a successful payment has occurred. If the sender knows and can calculate the pre-images in advance, this destroys the whole principle of a cryptographic receipt that you will get from the receiver of the payment. Since the proposal required the sender to create the shared secrets and the payment_hash, the sender knew the pre-images in advance.

To solve this issue, Basic MPP (multi-path payments) was proposed. Basic MPPs use the same payment_hash for all paths through which the payment will be made. The receiver however, does not release the payment pre-image until all successful payments have been received to thwart the possibility of an intermediate node using the pre-image from one leg of the payment and satisfying the other branch. Since proof-of-payment is valuable then no rational payee will accept partial payments until all parts of the payment have arrived and as a result will not release a pre-image. However, if it releases pre-image along one path, it is in the economic interest of the payee to release the pre-image along all the paths.

Implementation

A new type-length-value (TLV) format is now being followed in the Lightning Network protocol as compared to a fixed length byte stream in earlier versions. The use of TLV permits a space saving, potentially leaving more space for application data over the wire or in an onion payload. Nodes supporting such variable payload routing onions indicate it by setting the global_features flag, bits 8/9 (var_onion_optin). Moreover, the lightning invoice generated needs to set the basic_mpp feature.

Base AMPs uses the same payment_hash for all paths through which the payment will be made. If the final node receives an onion packet which includes a basic_mpp field, then the payment MAY be a "base" AMP. Setting the basic_mpp flag is a promise by the sender that the rest of the payments will follow in succeeding HTLCs. All the HTLCs that will be received that fulfills the payments having the same payment pre-image are called as "htlcset".

Upon receiving an onion with basic_mpp, the receiver should wait at least 60 seconds for all other payments to come through. If the payments are not received in sufficient period of time, the final node must fail all the htlcs in the htlcset. However, if it fulfills any HTLCs in the htlset, it must fulfill ALL of them. This subset restriction prevents the pre-image from being released before all the partial payments have arrived: that would allow any intermediate node to immediately claim any outstanding partial payments.

Future Releases

Work is being currently done on High AMPs. It combines both the original proposals of AMP and the current Base MPP, retaining proof-of-payment (which was sacrificed by the original proposal) and ensuring cryptographically-secure waiting for all parts (rather than the mere economically-incentivized of Base AMP).

This however, requires that we switch to points and scalars instead of hashes and pre-images. An invoice will now contain a payment point which is basically generated by  multiplying a scalar (equivalent to private key) with the standard generator point on secp256k1. Proof-of-payment does not require revelation of the scalar, but a signature using the scalar behind the public key is sufficient to provide proof-of-payment. This also allows support for payment de-correlation (additional scalars are added at each hop, and the sum total scalar is told to the payee), while not requiring either proof-of-payment or spontaneous payments (it can work with either). This is basically Scriptless Script usage on Lightning. Instead of HTLCs we have Scriptless Script Pointlocked Timelocked Contracts (PTLCs).

However, implementation of this would require Schnorr implementation on the Bitcoin mainchain which might be couple of years out.


Bip32 bitcoin core wallet `hdseed` format from xprv master key

You simply cannot. The HD seed is used to derive the master private key, not the other way around. This derivation uses a hash function so it only works in one direction: HD seed to master private key. Given the master private key, you cannot get the HD seed used to produce it.

BIP 39 mnemonics are used to create a HD seed which is then used to create the master private key. However BIP 39 specifies that the HD seed be created using SHA512 (within PBKDF2) so it will always output a 512 bit seed. But Bitcoin Core cannot take 512 bit seeds, so you cannot use a BIP 39 mnemonic with Bitcoin Core at all.


Tell them that actions of others doesn't necessarily reflect the organization you're in. Gangsters and drug dealers use USD everyday as well, their wrongdoings are not yours.


Coinbase IPN test page not posting data?

Instant Payment Notification callbacks are POSTed in the form of JSON data.  The issue may be that you're attempting to iterate over regular http params that aren't there, instead of parsing the response body as JSON.  I've never used ASP.net before but this topic looks like it may help:

https://stackoverflow.com/questions/3398926/how-to-retrieve-json-via-asp-net-context-request/3411775


Why Bitcoin Mining requires "Hash Guessing" problems, even though Consensus algorithm exists to tackle BFTP?

The "consensus algorithm" you are referring to is predicated on the "hash guessing" you are trying to eliminate.
If we skipped "hash guessing," the resiliency and reliability of the blockchain would be completely destroyed.
This question assumes at least 2 false premises and cannot be meaningfully answered.


Compared to Slush's pool, how exactly does Eligius payout owed bitcoins to the miners?

How does Eligius pay miners directly from the newly generated coins?

It simply generates the coinbase transaction to include payments directly to its miners, instead of only a transaction to itself.

  What are the pros and cons of this compared to how Slush does it?

Here are some I can think of:

Pros:

No transaction fees necessary for these payouts (except for the opportunity cost of some transactions you're not including in the block; but unless the block is at the max size, this is 0 cost)
Some people like having freshly minted coins, for anonymity and just because it's cool

Cons:

Harder to predict when you'll get a payout (because you have to wait for the pool to find a block)
If you're far down the queue, it might take several blocks and/or a manual payout before you finally get your payment

  Are there other pools that do the same thing?

Yes, at least a few. BitPenny and P2Pool, for instance.

  Is this only possible with BTC and it's clones or can Litecoin pools do it too?

It's possible with any Bitcoin-like coin, including Litecoin.


Is there a secret number that is only known by the sender and the receiver after making a transaction?

Yes. You can view a transaction as being a public link between a number of public keys. If different people have the secret keys for those public keys then they have all the necessary information to calculate shared Diffie-Helman elliptic curve points. So in the simple case that you transfer all the bitcoins in an address to someone else's address then you can use his address and your private key to calculate a point which will be the same as the point calculated by him using his private key and your address. Nobody else can calculate these points.


Multibit download stats

MultiBit is a thin-client based on the BitCoinJ library. It is written in Java and comes with installer packages for Mac, Windows and Linux. It is intended to be used by the general public who don't have a great deal of knowledge about Bitcoin and just want to send and receive payments in the simplest manner possible.


What is "safe mode" and how does it affect RPC Commands?

When Bitcoin-Qt detects that something is seriously wrong with the network, it disables most RPC functionality in order to prevent automated Bitcoin sites from losing a lot of money due to network problems. (The okSafeMode functions are not disabled.) All versions since ~0.3 go into safe mode when the longest chain is invalid (illegal transaction, creating too much money, etc.). Upcoming versions will also go into safe mode when a large fork (valid or invalid) is in danger of overtaking the current chain.


Is there an implemented color coin demo for bitcoin?

Probably chromawallet is the more advanced implementation. http://chromawallet.com/

I think people are only using it on testnet for now.


how and when does block and transaction validations take place?

Generally each transaction is validated when it is added to the mempool of the node. This happens when the node first sees the transaction, it doesn't wait til it is added to a candidate block for mining. The candidate block for mining would be formed out of the transactions already in the mempool - those which have already been validated by the node.
If another node receives a block then yes, it will validate the proof of work and other factors such as the timestamp, and it will also validate each transaction in the block that it hasn't seen before. The ones it has seen before will simply be removed from its mempool and do not need to be re-validated.
Re 3., nodes will not accept two conflicting transactions into their mempool. Each node will accept whichever valid transaction they see first. This may not be the one that ends up in the block eventually, but the node will correct this once one of the two conflicting transactions has been mined.


Multibit HD 0.5.1 with Unconfirmed transactions for months now

I got help from BTC Portugal (Portuguese slack channel, thank you @riclas, @shutaru and @malmen) and was able to solve this issue.

This is what I did (ETA: 10 minutes):

Close all running Multibit HD wallets you have. I really mean all, no computer in this planet should be running your wallet at this moment.
On a "new", clean computer, or in a Virtual Machine, install Multibit HD, a fresh installation.
When the new Multibit HD installation asks you, instead of creating a new wallet, chose the restore wallet option.
Insert your seed words and date.
Voila! It will now take some minutes to synchronize your wallet with the chain, but it should load only the confirmed transactions.
Go to the other computers, uninstall Multibit HD completely.
Make sure you delete everything in folders such as C:\Users\<user name here>\AppData\Roaming\MultiBitHD (or /Users/<user name here>/Library/Application Support/MultiBitHD/ for OSX) or simply search for MultiBitHD files on your disk and delete them all.
Install the wallet once again in those computers and recover just like you did in steps 3 and 4.
Profit!

If you are really in a rush, just perform steps 6, 7 and 8.

Don't do any of this if you don't know your words and date for recovery!

UPDATE: This doesn't actually solve the issue. In fact the wallet thinks that all your transactions are confirmed, until you try to spend the money. Then you'll get a Low spendable balance detected. some of your bitcoins are tied up with ongoing transactions. error.

The thing is that the wallet refuses (or the network refuses) to double spend that money, because they see the unconfirmed requests already broadcasted.

For what I've read these requests will never timeout from the mempool. This is a known issue of BTC, and is making this coin hard to scale to the rising numbers of transactions (as of now only 3 transactions are processed per minute, which is ridiculous).

The only way I can perceive now to "solve" these unconfirmed transactions, is to use accelerators.

These accelerators are basically mining pools (a huge team of miners), where you ask them "pretty please" to consider adding your transaction to their next created block. This will confirm your transactions. However, this solution is at very least, not accessible.

You can try asking it for free here: https://www.viabtc.com/tools/txaccelerator/

After I get my money back, I'll consider not using Multibit HD anymore, since issues like these made me lose some money so far...


Cannot get BITCOIND RPC connection working on Ubuntu 12.04 or Windows 7

Netstat(1) will give you open ports (in this case listening TCP ports): netstat -lnt.

To make sure you know which port your bitcoind daemon is using, start it with paramter -rpcport. In your example, use exactly -rpcport=8332, then use the same port when connecting to it.


Both Bitcoin and Ripple are systems made of many components. One such component is a method to synchronize transactions and secure against double-spending; Bitcoin uses mining based on proof of work for that, while Ripple uses a consensus mechanism. Another component is the initial issuing of coins - Bitcoin uses mining for that as well, while Ripple uses central issuing. Of course, the key component of Ripple, which Bitcoin lacks, is a credit network with pathfinding.

You could build a system which is like Bitcoin in every way except that it uses consensus for synchronization rather than mining. It is likely that the total energy spent on generating new coins will be lower than the total energy spent on synchronizing transactions; so replacing that part with a mechanism that requires less energy is welcome. However, the consensus mechanism is not as proven as the mining mechanism, and is less decentralized thus less consistent with Bitcoin's overall vision.


What function does Mt. Gox's "Open Transaction" withdrawal option perform?

I just asked on the #mtgox IRC channel, and was told:

06:36 < dooglus> what does the "Open Transaction (6 Confirmations)" option
                 do when withdrawing BTC?
06:48 < Cory> If the Bitcoin address you're withdrawing to is a MtGox address,
              it will use the network and blockchain anyway.
06:49 < Cory> Otherwise, if that option is not checked, they will only internally
              transfer the funds.
06:53 <@MagicalTux> and instantly

So there you have it.

I suggested they should label it differently:

07:13 < dooglus> it would be better to use some different text for that option -
                 like "use bitcoin network even for transfers to mtgox deposit
                 addresses" for instance
07:19 <@MagicalTux> dooglus: it use to be something like that, but people were
                    complaining it was not clear enough


Can a Bitcoin response contain multiple Bitcoin messages?

In TCP communications it is common to use a technique known as "piggybacking".
Let's say A and B are communicating over TCP. Normally, after receiving a message from A, B should send an ACK message to let A know he received it correctly. In order to minimize the number of messages, B can "encapsulate" the response message into the ACK, so that A will receive the response along with the ACK.

Since Bitcoin works on TCP, it is reasonable that the same technique is applied.


huobi.com API to get latest trade price, bids and asks?

I had some trouble finding it there but then I found it in "reference"
https://github.com/huobiapi/API_Docs_en/wiki/REST_Reference

You can use normal http queries like on other exchanges so to get an orderbook you use this for example: https://api.huobi.pro/market/depth?symbol=ethbtc&type=step1


How can I work out why a transaction isn't being included in any blocks?

The transaction needs a fee.

I mistakenly thought that testnet transactions didn't require fees, but the requirements are just lower. Given that this is spending a recent output and the amount is very small, it is being ignored.
Do testnet networks require the same main network fee?

A transaction including a fee went through successfully: https://live.blockcypher.com/btc-testnet/tx/0119445bfc577bcd032a079b03d1534be91b01e789874a02f88b9234ab72429d/


Has anyone ever gained control of the blockchain?

I think it is safe to assume that the creator once had full control of the blockchain. And at the beginning, there probably were times when someone had 51% hash power.

However, those people would have no incentive to perform an attack, so my guess would be that it has not happened yet.


Why does a malicious miner need more hashing power than the rest of the network combined?

I don’t quite understand why a malicious miner needs more hashing power than the rest of the network combined

Generally speaking, a malicious miner is one attempting to perform a double-spend or reverse the block-chain.

A miner can attempt to broadcast any block, but it will get rejected if the receiving nodes do not agree with it (checking against consensus rules).

It is important to remember that Bitcoin nodes will always favor the chain with the most amount of proof-of-work (chainwork); this is specified in the protocol's node implementation. The malicious miner needs sufficient hash power to recalculate more blocks than the current chain such that it will have more proof-of-work. Once the attacker's chain has greater chainwork, nodes will discard the existing chain in favor of the attackers.

The miner is indeed required to have more power than the rest (the "honest" part) of the network combined. The miner would need a majority of the hashing power. You will often hear this referred to as a 51% attack.

Additionally as Learn Cryptography suggests:

  Hitting 51% network control is not a guarantee of success, just the point where success is likely. In fact, you could attempt this sort of attack with much less network control, but your odds of success would be very low.

This is also why it is recommended for users to wait until a transaction has over 6 confirmations as it gets exponentially more difficult for an attacker to double-spend as confirmations build on top of the transactions current block. With 51% hash power and 1 confirmation, the attacker is practically guaranteed to be successful in a double-spend.

You can calculate your own attack probabilities for this here

  When miners are solving a hash puzzle, aren’t they solving the puzzle individually?

Miners do their hashing independently, yes. Each miner will check many nonces for the current block until either a solution is found that meets or is below the target, or the block has been broadcast by someone else.


Explain this comment on nNonce from the bitcoin miner.cpp source?

What does it mean that the input buffers are 16-byte aligned? Is that important for calculating the hash?

It means that the lower four bits of the starting address are always zero. I assume that this was done for speed reasons. There are instructions that won't work on non-16 byte aligned addresses. Also, some CPU caches might prefer it. I don't know.

It doesn't affect how mining is done, though.

  All of the arrays already have a length that is divisible by 16, what's the need for the extra 16 chars?

Not quite. Notice how it gets those addresses. It declares an array, then manipulates the pointer to that array. There's no platform-independent way to ask the OS for an aligned section of memory. Instead, you have to ask for something slightly larger than what you want, and increment the pointer until it lands on the boundary that you want.

Side note: This is an off-by-one error. Really, the array only needs to be 15 bytes larger than normal. Probably not worth fixing.

  And why only try 0xffff nonces? Is this just an artificial limit put so that the hashing doesn't take forever?

It tries all nonce values. However, it returns from the function every 65536 iterations, so the parent function can check

that it's still mining on the top of the chain,
that it's still actually connected to the network,
that the transactions are not out of date, and
that the nonce is not going to wrap around.

Basically, all of the complicated logic is implemented in its caller, BitcoinMiner.

PS: That comment is wrong. It appears to describe ScanHash, but it's actually talking about this section of code within BitcoinMiner:

    // Check for stop or if block needs to be rebuilt
    boost::this_thread::interruption_point();
    if (vNodes.empty() && Params().NetworkID() != CChainParams::REGTEST)
        break;
    if (nBlockNonce >= 0xffff0000)
        break;
    if (mempool.GetTransactionsUpdated() != nTransactionsUpdatedLast && GetTime() - nStart > 60)
        break;
    if (pindexPrev != chainActive.Tip())
        break;

Somebody should probably move the comment.


bitcoind API rpc calls to encrypt an arbitrary message and create a script

I would recommend that you use a purpose designed encryption tool like GPG to encrypt messages. If you need to bind it to a Bitcoin address for some reason, the recipient can signmessage their PGP public key using the signmessage functionality.

Secure general encryption is a complex subject area, and any "bitcoin encryption" would almost certainly be half baked and insecure in some applications compared to a real encryption tool.  Because of this there is no support in Bitcoind for message encryption and I don't expect any to be planned.


I'm not sure if bitcoind stop still works as RPC with newer releases, since somewhere in help sections it says RPC funcionality removed from bitcoind.

Try bitcoin-cli stop.


Can we use a Paper Private Key that has been loaded in the Bitcoin client?

1.) The web page at BitAddress.org can be loaded from a file on a thumb drive or other storage.   Most browsers let you save the web page using a View Source (right click maybe), and then Save File to a thumb drive.

Then from the offline computer you open the file from the browser and the BitAddress page will load.

2.) The private keys don't expire or invalidate after they've been imported into the client. You correctly identified the problem with that is how if you spent any of the incoming funds, the client creates a new address for "change" and thus the wallet may show a balance that includes funds not in any of the addresses from the imported private keys.  So wallet backups are still important.


How do I debug Taproot functional tests using pdb?

The Bitcoin Core test documentation provides some guidance on attaching a debugger. The functional tests are in Python so you are correctly choosing pdb (rather than gdb, lldb etc) for the job.
A python debugger can be attached to tests at any point. Just add the line:
import pdb; pdb.set_trace()
anywhere in the test. You will then be able to inspect variables, as well as call methods that interact with the bitcoind nodes-under-test.
If you're unsure where is a good point to attach the debugger one good place is after the random_checksig_style(pubkey) helper is defined in feature_taproot.py. This creates a random CHECKSIG Tapscript that requires only a valid signature on the witness stack.
There is a good video tutorial here from Simeon Franklin on pdb here. There are a large number of pdb commands but the key ones you are most likely to use are:
l(ist)
n(ext)
c(ontinue)
s(tep)
r(eturn)
b(reak)

As Franklin states:

l shows you where you are in your code. n steps to the next line of execution. c leaves debugger control and executes your code normally. s steps into the next line of execution including into function calls if they exist. r steps to the end of the currently executing function and b sets breakpoints. It is important to realize when you are debugging that from the pdb console you can type in any valid Python, changing variables or execution flow of your program and inspecting their values.

(Also p expression for printing an expression value or pp expression for pretty printing an expression value. And whatis expression for printing the type of that expression).
More detailed guidance on using pdb is on python.org but the above should be a good introduction.
Remember that you are making edits to Pieter Wuille's taproot branch locally and will not ever push them to GitHub so you can make whatever changes you want. If you want to revert back to Pieter Wuille's code before you started making edits (and discard all of your edits) you can run
git reset --hard HEAD

and then you should be back to the state before you started experimenting.


Antminer U1 running on raspberry pi not accepting shares

The line connected to mint.bitminter.com diff 512 means that the remote pool will only accept shares with an effective difficulty of 512 or above. Your miner has not yet found any shares with satisfy this rule, as noted by the line best share 57. It may take a number of hours at this speed to find a significantly difficult share that the pool will accept, when you do the log will print a line saying accepted or rejected depending on the pools response.

diff 947/128 in this case means the remote pool was asking for minimum difficulty 128, and the miner managed to find a difficulty 947 share which satisfied this requirement.


Not enough funds usually means that you've confused the unit of account i.e. mbtc vs. btc or you're not accounting for transaction fees including 2fa fees if you have a 2fa wallet. I suggest you use the exclamation point in place of a numeric amount to see what is the max amount you can send. Decoding the generated transaction should be illuminating.


Why SHOULD the funding tx consume BIP 141 inputs?

The following is my humble understanding, I am not an expert in BOLTs.

First, the reason to include this requirement is indeed transaction malleability. If malleable outputs are consumed for the funding transactions, then:

funding_txid may change after the transaction is broadcasted;
checking the status of the tx may fail (funding_locked);
the channel will never be established even though the funding tx is send.

Second, as to why this is a SHOULD instead of a MUST. This has to do with the IETF definition:

  SHOULD   This word, or the adjective "RECOMMENDED", mean that there
  may exist valid reasons in particular circumstances to ignore a
  particular item, but the full implications must be understood and
  carefully weighed before choosing a different course.

SHOULD is not critical to the specifications and some clients may have a reason to ignore this recommendation. For example, I may write a client that does not include on-chain BIP141-only bitcoin wallet and instead connects to an existing one. This will make setup easier and cheaper for some users (no additional on-chain transaction). But I need to understand the implications and handle malleable transactions in case their txid changes.


How fast does a processor have to be to mine bitcoins

After the creation of specialized hardware, created ex-professo for mining bitcoins, difficulty has climbed so high that it's not profitable to mine them in anything but an ASIC (if you can afford it). Anything else and you'll lose money or barely pay the electricity consumption.

Plus, it's definitely NOT recommended to do mining on a laptop - having either the GPU or the CPU running at 100% the whole day long produces a lot of heat and will significantly reduce the life-span of components.

Having said that, if just for fun, you could try mining Primecoin, Protoshares or Quarkcoin some hours a day - they're minable only with CPU (for now). Or better yet: mine a scrypt-based with your graphic card (it's usually much more profitable). Maybe mine dogecoins for 3-4 hours a day - Dogecoin and the dog meme are fun :)

Just don't expect you'll get a lot of any coin mining partial-time.


Bitcoin Core txindex vs default mode vs pruned mode in depth

TxIndex
Most use cases do not require a tx-index. The wallet keeps track of the relevant transactions (if you run a wallet). A complete tx-index may be useful for block-explorer-like interfaces or for research, etc.
It requires some disk space.
Pruning & TxIndex: You can't use a txindex with a pruned blockchain. Pruning will throw away scanned blocks. Having an index that points to a tx in a block that is no longer on your disk seems a waste.

Pruning
Autopprune (-prune=550) allows you to reduce your historical blockchain data to a given target (in MB, example uses 550 which is the minimum). You can't throw away all blocks because you may need to "roll back a couple of block" if there is a chain reorganisation.
If you set prune=1 (== manual mode), you can then manually prune your blockchain (use RPC call pruneblockchain <height>) [since 0.14]
The only reason to keep old blocks (say deeper then 144 blocks) is to allow other peers to bootstrap the blockchain and to serve (filtered) blocks to SPV client.
There are little "end-user" use case (expect the txindex) to keep old block.
UTXO set
Important to know is, that your full node will keep track of all unspent transaction (only those are relevant for validating blocks/the chain).
This database is (at the moment) roughly 2GB large and will (and must) also be present in pruning-mode. This database is essential for a full node.

Default mode
Keep all blocks (take up ~80GB of disk-space). This will allow other peers to verify the blockchain and it allows SPV peers to ask for relevant transactions in all possible blocks.
If no one will run in this mode, the blockchain history may be lost (exaggerated).


I am eager to know details about distribution of bitcoin

According to Steven Englander: Best estimates are that there are about one million holders of Bitcoin;  47 individuals hold about 30 percent, another 900 hold a further 20 percent, the next 10,000 about 25% and another million about 20%, with 5% being lost.

Read more: http://www.businessinsider.com/bitcoin-inequality-2014-1#ixzz2rEi2kG5g


It's normal for it to take a long time, the whole blockchain is >120 GiB at this point. You can download a bootstrap.dat torrent, but at this point, as you have already a lot of it downloaded via Bitcoin Core, it won't be any faster.

On the other hand, perhaps you would want to reconsider running a node. 120 GiB is quite a lot and you neither can hope for block rewards nor is your security any better* compared to a light wallet, such as Electrum. There are many other light wallets, I just don't know much about their security.

* See below:

  Simple Payment Verification (SPV) is a technique described in Satoshi Nakamoto’s paper. SPV allows a lightweight client to verify that a transaction is included in the Bitcoin blockchain, without downloading the entire blockchain. The SPV client only needs download the block headers, which are much smaller than the full blocks. To verify that a transaction is in a block, a SPV client requests a proof of inclusion, in the form of a Merkle branch.


How do I monitor the performance of my P2Pool instance?

p2pool has a higher difficulty, so you won't be submitting many shares, with 30MH/s you will have a greater variance.  p2pool is not the perfect solution for those of us with a low hashrate unfortunately.

The p2pool tells you how many shares you submitted but it's in the lines above the one you pasted, look for where it says Shares: 3 (2 orphan, 0 dead)

Also compare the Pool stales to your own stales.  To have a reliable number, keep p2pool open for at least 24h, but the numbers should be almost the same.  If your own stales percentage is higher than the pool's, you are earning less than you should.  If it is below, you are earning more than you should.


How can I remove the charity features in my Devcoin clone?

int64_t nFees = 0;
int64_t minerValue = GetBlockValue(pindexPrev->nHeight+1, nFees);
int64_t sharePerAddress = 0;
if (coinAddressStrings.size() == 0)
    minerValue -= fallbackReduction;
else
    sharePerAddress = roundint64((int64_t)share / (int64_t)coinAddressStrings.size());

LogPrintf("coinAddressStrings: %d\n", coinAddressStrings.size());
for (unsigned int i=0; i<coinAddressStrings.size(); i++)
{

This is the code in miner.cpp. I think what you should try is changing the following line:

sharePerAddress = roundint64((int64_t)share / (int64_t)coinAddressStrings.size());

change it to

sharePerAddress = 0;

That should remove any payment to the beneficiary.


If bitcoin have a 21 milion limit...what happens with the lost bitcoins?

It is never possible to determine which bitcoins have been lost, and which are merely being held unused.  In either case, it means they are effectively removed from the economy.

This means that they aren't being offered for sale on an exchange, nor being offered in exchange for goods and services.  This creates scarcity, and as economists tell us, scarcity (in general) makes the value go up.  It means that those who are offering to sell bitcoins on an exchange have less competition, and can charge a higher price.


How do I migrate to Bitcoin XT from Bitcoin Core?

The two clients are based off of the same code base. To use Bitcoin-XT, you only need to make sure your Bitcoin Core client is shut off when you start the Bitcoin-XT client. The two programs use the same data directory and wallets, so all your coins will still be there.

See "Should I be running Bitcoin Core or Bitcoin-XT?" for more info regarding the differences between the two software packages.

In the README.md of Bitcoin-XT, it even says:

  XT uses the same data directories as Core so you can easily switch back and forth.


How many possible addresses per bitcoin private key?

It depends a lot on the kind of locking condition you want to satisfy. The addresses that you have mentioned would depict 'standard' locking condition where the user reveals their public key and associated signature in order to spend the locked bitcoins. However, you can create custom scripts and then convert them into standard addresses.

For example, locking some bitcoins in a CLTV script using the same private key will generate a completely different address. You can use CSV or any other custom opcodes like OP_ADD to generate those custom scripts and then wrap the script in P2SH or P2WSH. When you spend the funds you need to reveal the custom script and the signatures should match. When you include the possibility of generating standard addresses from the custom made script, the possibilities are endless.

Also, a point to note is that a compressed public key will generate a completely different address as compared to an uncompressed public key.


In brief, so-called lightweight wallets have to trust the nodes they communicate with, full-node wallets don't have to trust other nodes.

Bitcoin's creator, Satoshi Nakamoto, wrote about Simplified Payment Verification (SPV):

  As such, the verification is reliable as long as honest nodes control the network, but is more
  vulnerable if the network is overpowered by an attacker. While network nodes can verify
  transactions for themselves, the simplified method can be fooled by an attacker's fabricated
  transactions for as long as the attacker can continue to overpower the network.


What would be the benefits of 10x the energy spent

Note first of all that "10x the nodes" and "10x the mining energy" are different things.  A "node" is just a computer that participates in the Bitcoin network by receiving and relaying transactions.  Most nodes don't do any mining, but conversely a single node may support an unlimited amount of mining power.  So there is no real relationship between the number of nodes and the amount of mining power on the network.

Having 10x as many nodes would make it slightly easier for a user to connect to a node to send and receive transactions, and would make the network somewhat more robust against a network split (where not all nodes are able to communicate with each other).  However, it might also make it take slightly longer for a transaction to get to a miner, since more hops would be needed.  There wouldn't be any major positive or negative effects that I know of.

If the network had 10x more mining power, the main benefit would be security against 51% attacks, since an attacker would now need 10x more mining power of his own to mount such an attack.  (Of course, if mining hardware became more efficient in the meantime, this might not actually increase the costs of such an attack versus today - but they would still be 10x higher than without the mining power increase.)

There wouldn't be any long-term improvement in confirmation speed, since as you say the difficulty would adjust to keep the block time at 10 minutes.  (If all the mining power came online at the same time, there would be a temporary increase in confirmation speed for the first few days, since the difficulty adjustment happens only at specified intervals and the maximum adjustment at each such interval is by a factor of 4.)

I am not sure what you mean by "censorship resistant".  A mining power increase wouldn't do anything to help prevent a government from trying to block Bitcoin traffic from the Internet.

There wouldn't be any other major end-user effects that I can think of.  Resistance against 51% attacks is the main one.


How does a constant opcode become negative in Script

I was not sure how it would work there but it is in fact basic arithmetic, we have this x^2 + x = 6 then we substract 6 from both sides x^2 + x - 6 = 6 - 6 then we simplify x^2 + x - 6 = 0


Why do we need Proof of Work in bitcoin?

Imagine I have 1 bitcoin. And imagine I can form a transaction to send that bitcoin to Alice or I can form a transaction to send that bitcoin to Charlie.

Now, what stops me from forming both transactions? Nothing.

So, if I do that, how will people know which transaction is valid? Clearly, without some reliable way to tell which of those two transactions are valid, the system is doomed.

This is what PoW does. A miner cannot contribute PoW to both transactions at the same time -- he must pick one.


Valid public key check in transaction output

The standardness check will verify a multisig output for valid EC points. If these points do not pass this verification, the output script will be considered non-standard and not propagated by the implementations which I know of.

This can be verified by checking the implementation source.


How do you send to multiple addresses by paying a one time fee? Which wallet supports this?

TL;DR: Just read the second paragraph of "Concrete Numbers".

Wallet Recommendation: Electrum

Doing this in Electrum is very simple. Just switch to the Send tab and then (in the menu) choose Tools → Pay to many. The "Pay to" field will become a text area and a popup will open, telling you how to send money to many addresses.

Note that the unit of the amount can be changed in the settings (Tools → Preferences → Appearance → Base unit) and is mBTC by default.

The amount field will be automatically filled in once you have at least one valid line in the "Pay to" field:

The amount field probably isn't grayed out from the beginning because you technically can switch between pay to many mode and pay to single address mode without choosing Tools → Pay to many by just hitting enter in the "Pay to" field which automatically makes it a text area.

The Fee

As the fee by default is paid per transaction – not per transaction output –, you only have to pay it once even if you send money to a large number of addresses. It can be adjusted as a linear function of the transaction size in Tools → Preferences → Transactions.

Adjusting the Fee in Electrum

Alternatively, you can check the box Dynamic fees in Tools → Preferences → Transactions to use Electrum's dynamic fees feature which changes the fee function to not only depend on the size of the transaction being submitted but also on the network conditions (the number of pending transactions and the current rate at which transactions are processed).

In any case, Electrum shows you the fee in a popup before the transaction is sent if you check check View transactions before signing in Tools → Preferences → Transactions (not sure whether it does if you don't). If you use the dynamic fees feature, you will receive a warning if the fees are currently unusually high due to inconvenient network conditions.

As an alternative even for that, you can check the checkbox Set transactions fees manually in Tools → Preferences → Transactions which lets you set the fee manually for every transaction.

The Amount of Fee

As for how much the fee will be, let's say you pay a fee of ρ/Byte where ρ is around 10 Satoshi. This is equal to what you mean by

  Would it be .0001 x 20 = .002 in fees?

if you mean ".0001 BTC/kB" by ".0001" because .0001 BTC/kB * 100'000'000 Satoshi/BTC / (1000 B/kB) = 10 Satoshi/B

You can inform yourself about fee recommendations in articles like this one.

For simplicity, let's assume you use P2PKH with compressed keys (which is standard), have a UTXO large enough for the entire transaction but not of just the right size, so you need a change address (which is almost always the case).

Under these assumptions, you have to use 148 Byte per input and 34 Byte. In addition to this, the transaction header needs 10 more Bytes.

We can now write down a function φ : ℕ×ℕ×ℝ → Satoshi which tells us the transaction fee provided the number of inputs and outputs as well as ρ. This function is: φ(ni, no, ρ) := (10 + ni*148 + no*34) * ρ * Satoshi

Let γ : ℕ×ℝ → Satoshi be the function which tells us the fee for a transaction with 1 input, 1 change address, and and n addresses you want to send money to. This function is defined as: γ(n, ρ) := (192 + n*34) * ρ * Satoshi

Concrete Numbers

If you pay the 20 people individually, you will spend 20*γ(1, ρ) = 4'520*ρ*Satoshi = 0.0452*ρ*mBTC as the fee. On the other hand, if you pay them all at once, you only spend γ(20, ρ) = 872*ρ*Satoshi = 0.00872*ρ*mBTC. If we assume ρ=10, that's 0.452 mBTC or 0.0872 mBTC respectively.

The difference is that you would spend (0.452 mBTC)/(0.0872 mBTC) = 5.18 times as much of a fee if you made individual transactions compared to if you made one cumulative transaction.

If you pay the 200 people individually, you will spend 200*γ(1, ρ) = 45'200*ρ*Satoshi = 0.452*ρ*mBTC as the fee. On the other hand, if you pay them all at once, you only spend γ(200, ρ) = 6'992*ρ*Satoshi = 0.06992*ρ*mBTC. If we assume ρ=10, that's 4.52 mBTC or 0.6992 mBTC.

The difference is that you would spend 6.46 as much of a fee if you made individual transactions compared to if you made one cumulative transaction.

Data Import

Furthermore, it's probably easier to make one big transaction than to make many small ones. If you have such a table in LibreOffice Calc, you can just save it as a CVS (comma-separated values) file and feed it to Electrum as it itself describes it in the popup seen in the first screenshot.


How to Reset Dragon Miner 1TH/s IP Address?

This happened to me.

I got it to work again, by updating the miners firmware:

I flashed this image to an SD card: https://www.dropbox.com/s/clafawqo2oo4jrb/dragon_miner_mxnschmod_firmwarev1.2_20160108_ip254.rar?dl=1.
I then popped it into the miner and waited a few minutes.

When I logged into the IP, it wass working better than the original. You can use the win32flasher tool to do the flashing of the SD card.


Difference between "time" and "mediantime" in getblock?

mediantime is better for your purpose. The timestamp is chosen by the miners, and has some restrictions on it such as it can't be too far in the future/past (no more than 2 hours into the future), but it is not strictly increasing. Mediantime, on the other hand, is. Mediantime is the median time of the past 11 block timestamps, and a block must have a timestamp greater than that median time, so the mediantime always increases.


How can a wager with SatoshiDICE be proven to be fair?

[Going to answer this one myself.]

Unlike games of chance where you need to trust a machine or a human, SatoshiDICE's results are verifiable, thanks to cryptography, once the secret is released (the next day).

This can be verified without needing any software installed.  Here's how:

So for your wagers from Jul 10, 2012 (UTC), get the secret from:

http://satoshidice.com/secretlist.php

That has been released, and it is:

ctygmtZjw7xTnLou7u9cWVYiOd79xAMJK5aJJBBD3w2Su8vGMHPDwP1f4O1eBPek

Then create the SHA-256 hash of that secret with:

http://md5online.eu/3,sha-256

Which yields:

d75e37bc91915af566276e34624e7477c2a6771fb7898bc4dd1b30ccc0022cfe

Then verify that the resulting hash from that jives with the has from hash.keys for Jul 10, 2012:

https://s3-eu-west-1.amazonaws.com/satoshidice/hash.keys

So next you grab the transaction ID for your transaction (from the Transactions tab of Bitcoin.org client, or using BlockChain.info).

Then plunk those values in ... for Text to convert, paste the Transaction ID, and for Shared Secret Key use the secret for the day that you verified above.

http://hash.online-convert.com/sha256-generator

After you click Calculate hash, you'll get a hex string in the results.  The first four alphanumeric characters is the hex representation of your lucky number (from 0000 through ffff hex, or in decimal, 0 through 65,535 decimal).  You can convert those values to decimal here:

http://www.binaryhexconverter.com/hex-to-decimal-converter

So if you had bet the "less than 8,000" wager and your lucky number was 8,000 or higher, ... that specific wager didn't win.

As long as the hashes to the secrets are known in advance (and they are, that hash.keys was published in April, a copy of which has been archived here) you can always verify if you should have gotten a winning payout or not:

https://raw.github.com/sgornick/satoshidice/master/hash.keys


Can TREZOR sign transaction with input address beyond gap limit?

Yes, you can sign with that. Hardware wallets don't care about your gap limit, they aren't deriving individual keys when you setup the wallet. Rather they just store the master private key (or the seed used to derive the master private key) and then derive the individual keys needed on-the-fly. So if you tell it to sign with the 999,999th key, by giving it the correct derivation path, it will do so without complaint.


Bitcoin cash, is centralized, and it is difficult to run a full node of it, and it does not have a great developer strenth.

Bitcoin (the original) have many developers developing new tecnologies like the lighning tecnology. And it is fully descentralized. But the mempool is crowded right now wich makes the fees quite high.

I think in the short term Bcash (Bitcoin cash, nickname) will be more usable, with lower fees, but in the long term in cannot compete with Bitcoin.


How can I prune my Bitcoin Core correctly? The other way did not work for me. Have I done any unnoticed mistake?

From your description it sounds to me that you may have edited your configuration file while Bitcoin Core was already running.

prune=1100 is a startup parameter. It will take effect once you restart the program.

If you add a parameter to the startup instructions,  parameters start with a dash (-prune=1100), e.g.:

"C:\Users\<username>\AppData\Roaming\Bitcoin\bitcoin-qt.exe" -prune=1100

Please make sure you use the correct path for the actual directory you installed Bitcoin to.
If you add it to the configuration, the parameter must be listed without a dash in the bitcoin.conf:

prune=1100

If you're unsure how to locate your Bitcoin data directory, please see: Where is the configuration file of Bitcoin-Qt kept?

There is no need to manually delete any files from your Bitcoin directory, or to start over the initial blockchain download to enable pruning.
You merely need to restart Bitcoin Core after you've edited the bitcoin.conf. If you don't know how to restart a program, you may find it simpler to shut down and restart your computer.


What is an "insecure transaction type", as mentioned by Bitcoin Wallet for Android?

TL;DR:

It seems that Bitcoin Wallet for Android incorrectly labels nLockTime transactions as OptInRBF due to a bug in bitcoinj. The issue has been reported. You don't need to do anything.

Apparently, Bitcoin Wallet for Android recognized your transaction as OptInRBF (as pointed out by the code you found). The warning you are seeing was only added to the app on March 10th 2016.

What is OptInRBF?

OptInRBF is short for "Opt-in replace-by-fee", which was added to Bitcoin Core in 0.12.0. The new version allows Bitcoin Core to receive and correctly treat replace-by-fee transactions. However, Bitcoin Core cannot create rbf transactions, yet. Wallets have to "opt-in" to send them.

Replace-by-fee is a flag that can be set on transactions to communicate that one might want to change the transaction before it is included in a block. Therefore, such transactions shouldn't be considered reliable until they get their first confirmation. After they are included in a block, they are just as safe as any other transaction.
Mining pools that support rbf will allow a newer version of the transaction to replace the older, especially if the newer transaction pays a higher fee. This is for example useful for increasing the fee on a transaction when it is stuck, or to combine multiple transactions into one when you decide to send another transaction before a previous is confirmed.

Where does the warning come from?

Looking at the raw data of the first transaction, it turns out that the transaction's sequence number is indeed below max value: It shows 0xFEFFFFFF while the maximum would be 0xFFFFFFFF. The sequence with an E in second place is an unsigned little endian long for "one below maximum". This is the sequence of a nLockTime transaction.

OptInRBF have sequences that are smaller than the nLockTime sequence, i.e. sequence < MAX - 1. Therefore, it appears that either bitcoinj or Bitcoin Wallet for Android misclassifies nLockTime transactions as OptInRBF. The problem is that since Bitcoin Core 0.11 all transactions have an nLockTime sequence.

At first glance, the bitcoinj code that checks whether a transaction is OptInRBF seems fine:

public boolean isOptInFullRBF() {
    return sequence < NO_SEQUENCE - 1;
}

However, Java natively uses big endian format instead of little endian format.
<speculation>Therefore, there may be an issue withNO_SEQUENCE - 1 which might resolve to 0xFFFFFFFE and the nLockTime sequence 0xFEFFFFFF read as big endian would appear much smaller than that and could therefore be labeled as OptInRBF.</speculation>1

I've reported the issue and am trying to craft a bug fix.

1 It turns out that my speculation was incorrect. BitcoinJ and Bitcoin Wallet for Android handle transactions with the nLockTime sequence fine, and parse it using little endian format as required. So far, the maintainer was unable to reproduce the described issue with the provided transactions (instead they were shown correctly without warning). Therefore, the reason for the warning's appearance is still unknown.

Thank you to Pepijn Schmitz, Gregory Sanders, Andreas Schildbach, and Wladimir van der Laan for help in figuring this out.


The bitcoin opcode seems to have a flat rate

If by "flat rate" you mean that each opcode costs the same amount in transaction fees, then yes, Bitcoin does have a "flat rate". Opcodes don't have a direct fee themselves, the fee is based on the size of the transaction, and since each opcode is one byte, they have the same cost.
It is unnecessary to have an opcode cost scheme like Ethereum because opcodes are not very computationally expensive and do not have the same effects as Ethereum opcodes do. Bitcoin script is not Turing complete so it is impossible to loop. Each opcode can only be run a single time.
Furthermore, the more computationally expensive signature verification opcodes do have an additional cost in the form of the "signature operations" (sigops) limit. Sigops are factored into the calculation of a transactions weight which will then effect the transaction fee, but this effect is only present in extreme cases where there are a lot of sigops in a single transaction. Blocks are limited in the number of sigops that they can include.


Delete the Bitcoin Core datadir:

Linux ~/.bitcoin/regtest directory.
Windows %appdata%\bitcoin\regtest directory.
MacOS $HOME/Library/Application Support/Bitcoin/regtest directory.


If I connect to a specific DogeCoin Node, is it possible to determine the transactions that originate at that node?

No. And if you could, that would be considered a bug.

Think about it. Say I create a transaction. I send it to exactly one node, and only one node. How can that node convince you that it got the transaction from me rather than that it originated it itself? How can that node know whether I originated that transaction or got it from some other node?


p2pool: Is it setup correctly? "???" in efficiency

You won't see a value there until you mine a share, so seeing a ??? is normal for the moment. The efficiency is a measure of how many shares have been counted in the share chain verses the ones you have found.

At 2GH/s you should be expecting to see a share soon, given an average of 2 days 8 hours to find a share at 2GH/s at difficulty 88800 (the current for p2pool).


Is backward syncing viable for full nodes?

In bitcoin we add unspent entries to the UTXO when created inside a block, and delete them when they are spent. Syncing “in reverse” would be a messy process that wouldn’t allow for the verification of authenticity of the blocks being imported until the sync was entirely complete, where going forwards we have complete confidence in blocks as they progress.

The software can reverse blocks to undo changes to the state during a block reorganization, but this is excruciating slow as it requires going back to the older blocks using a reference list and reinserting the UTXO entries that were previously removed.

  "UTXO commitment" could eliminate the need for downloading old blocks.

UTXO commitments don’t remove the need for full validation, they introduce a new weaker level of node operation where they trust that miners have included valid commitments.

UTXO commitments also require an extremely large amount of hashing to achieve, which makes them implausible for use in the production network without other changes.

  the user has to download the whole gigantic blockchain all over again if a rescan is required (typically after importing privkeys/addresses/wallet.dat).

BIP157 allows for wallet rescans without the block data being retained.


Should i send bitcoins to hash160 or normal address

Both P2SH and P2PKH use HASH_160. That's what the h stands for in them.

Each HASH_160 is valid in both addresses. As to which address you need to send your BTC to depends on if you are using a redeem script or a public key to spend it.

If you send it to an address starting with 1, your output is encoded as OP_DUP OP_HASH160 <PubkeyHash> OP_EQUALVERIFY OP_CHECKSIG. To spend this, you require a private key that leads to the public key to which the hash belongs, and sign the tx using that.

If you send it to an address starting with 3, your output is encoded as OP_HASH160 <RedeemScriptHash> OP_EQUAL. In this case, to spend the output, you need to provide a redeem script for which the HASH_160 equals the one used in the address (along with any information that the redeem script might use, such as the signatures for a multisig address, or witness for a segwit address).

Due to this, each HASH160 can effectively be used to generate two addresses. Blockchain.info defaults to showing the 1-address.

DO NOT send any coins to the 1-address if your original address was a 3-address, and vice-versa. You will not be able to recover them.


How is it possibile to verify payments without running a full network node?

You are right, in order to prove that a transaction is confirmed in a block you need more than only the Merkle root. The information needed is called the Merkle path and consists of the left/right leaf to your transaction node and the right/left parent, and so on up to the root.

Here is a graph depicting a Merkle path:
http://chimera.labs.oreilly.com/books/1234000001802/ch07.html#merkle_tree_path

The Merkle root and path, and also the block headers of the blockchain, are requested from a selection of random Bitcoin nodes.
Your SPV client cannot verify that the transaction is valid (not a double spend, correct signatures, etc.), but since it can verify that the transaction was included in a block with X confirmations, it can assume that the Bitcoin network accepted the transaction. Thus your SPV node will accept the transaction by trusting that the Bitcoin network only includes valid transactions to the blockchain.


Does the btc price depend on the reward?

Does the actual bitcoin price depend on the mining profitability?

Strictly speaking Bitcoin doesn't have a price, it is a currency that has exchange rates with other currencies.

The exchange rate between BTC and, for example, USD seemingly depends on

market sentiment.
supply and demand.

Changes in production costs, for example due to the halving of the mining reward, have some influence on the exchange rate but not as much as, for example, the influence of government reactions to the Covid-19 pandemic.


This comes from the free e-book Mastering Bitcoin by Andreas Antonopoulos:


The prices you present are pretty steep, but hopefully this is just for clarity;).

If you don't want to run a daemon yourself in a loop, you can always try using Strongcoin's API:

https://strongcoin.com/blog/bitcoin_micropayments_with_strongcoin

It sends notification to your website when a transaction that you are interested in appears (whether it is to one of your addresses or anyone else's). It might not necessarily be exactly what you want (say, if you require 6 confirmations), but it definitely is a good place to start if you just want some notifications.


I just need some advice or assistance if possible? I'd really appreciate anyones 2cents on this

This is from LAtoken faq:

I can't see my deposit
If you have made a deposit to your LATOKEN account, but the amount is not
reflected in your balance, it might be caused by one of the following:

Deposit was below minimum deposit, please refer to min amount on
deposit screen. In this case, deposits are considered unrecoverable.

Deposit has wrong/missing memo - create a ticket and tell us the
correct memo, we will deposit it manually (may take up to 1 week).

Deposit was not yet processed on the blockchain. Here are the
approximate time frames after which you should create a ticket:

~30 minutes for ETH, ERC-20, NEO;
~1.5 hours for BTC;
~3 hours for NIMIQ, Mircoin;
~30 days for BAYR.

My guess is that your deposit is below minimum deposit but I don't have an account there and can't check; if not, you can send the transaction ID to their support following the link above and ask them to verify.


Error handling is not particularly well done. If you are specifying format=json errors should respond with status 500 and a text/plain message. But there may be errors HTML based errors as well.

If the response is not JSON parsable then it should be considered the server has encountered a generic error.


In bicoin-qt open Help > Debug Window > Console.

An type the following commands.
First you need to list all addresses with funds, look for every line that has an address and take note.

listuspent

Second, you unlock your wallet

walletpassphrase "YOUR-PASS-PHRASE" 120

Then for each address, you should get the private key

dumpprivkey "1BITCOINADDRESS"

take note of every private key and  import them in another wallet. Take care when handling private keys and don't save them in clear text.
Instead of having an online wallet, what you can do is install Electrum which is a SPV wallet and import your private keys there.


how to move bitcoin from watching only wallet to standard wallet in electrum 3.3.8?

I accidentally swiped my bitcoin into a watching only wallet in electrum ...  from a paper coin

The way you describe this makes it difficult for me to work out what happened but I am unfamiliar with Electrum so it may make sense to someone familiar with Electrum.

Watch-only

A Watch-only address is a bitcoin address for which the wallet has no record of the private-key from which the address was generated.

A Watch only wallet would be a wallet that contains a watch-only address (without the corresponding private key).

Sweeping

When you "sweep" bitcoin from one "place" into another, I believe that usually means creating a Bitcoin transaction on the blockchain which transfers control of the money from one wallet to another. The target wallet can create this transaction if you give it the private-key of the donor wallet. However, there is no way this transaction should result in a watch-only address - where the target wallet does not know the private key of the target address.

Importing

The alternative process is to import the private key from the paper wallet into the target wallet. Again there is no way the target wallet could end up not knowing the private key which controls the money.

Recovering control

I would dig out the old paper wallet (which you called a paper bitcoin), create a new wallet and import the private key from the paper wallet. I would do this on a new PC or first carefully back-up the existing wallet (and preferably test the backup can be recovered).

If you would like more detailed advice, it would probably require you to say how the paper wallet was obtained - e.g. "it was printed by an Acme-coinomatic BTM, in Idaho in June 2017".

If you have disposed of the paper wallet, your Bitcoin are probably lost forever.


When the UTXO in the cache is full, what strategy is used to replace one UTXO with another in the cache?

The UTXO set cache is not a fixed size and the limit isn't a hard limit. New entries can be added to the cache without regards for the maximum cache size. In fact, the cache object itself doesn't even know what the limit is.
Rather what happens is that the cache is flushed periodically. Because the UTXO set only changes during block validation (mempool UTXO set is handled separately elsewhere), this periodic flushing is primarily tied to incoming blocks rather than a timer. After each block is validated, the node determines whether it should flush the cache to disk. There are several conditions that would cause a flush, including being close to the cache limit, and being over the cache limit.
So if during the validation for a block, the cache became full, it would actually just keep growing until the block is fully validated. Then at the end, the entire cache would be flushed to disk and the cache emptied.
Note that LevelDB itself has a cache that is independent of the UTXO set cache.


When Bitcoin-qt synchronizes with the network, it is not only downloading blocks (lists of transactions) but also verifying them: checking cryptographic signatures, etc.  This gives you independent verification that the blocks you've received are true and correct, and that you're not being sent fake data by some malicious peer on the network.  However, it is computationally intensive, especially given the large volume of Bitcoin transactions, and I am not sure that Bitcoin-qt has highly optimized code.  Other clients may do a reduced amount of verification, saving time and CPU, but at the expense of some security.


How do block explorer sites show information that is not available on Bitcoin Core?

How can they list the unspent transactions and the current amount of an address which "is not in their wallet"?

Block explorer sites maintain a separate database of information which is built by continuously scanning the Bitcoin blockchain. If block explorer sites see a standard locking script in the outputs of the transactions, they scrape the addresses out of those locking script and the amount associated with that output. This information is added to their database. Also, when a user spends bitcoins, he has to reference the txid and the output index in the input of the transaction. The block explorer sites uses this information to locate that output and check the output locking script, from which they derive the 'input address'. All of this information and continuous lookups allows block explorer sites to associate funds with addresses and show whether the bitcoins sent from a transaction have been spent or not. However, if you lock a transaction in a custom script, the block explorer sites won't be able to decode this information.

  How can they possibly have information from this newly generated address?

They continuously scan the blockchain from which they can get transactions included in blocks. Also block explorer sites run full nodes that helps them collect transactions relayed by other nodes in the mempool that haven't been confirmed in blocks yet.


I havent seen a proper answer on the internet so I did the test myself using bitcoin-0.18.1 with the -testnet flag and after downloading the chain ~2 GB I monitored the traffic of the bitcoind process with nethogs for 24 hours.

I got 40MB download and 20MB uploads so 60*30 = 1800MB

You can expect 1.8GB of traffic from the bitcoin testnet compared to the 200GB+ they advise for the bitcoin mainnet


Do transactions affect the discovery of a block?

There's no such thing as 'aborting'. It's all random anyway. The chance of solving a block on the first try is equal to the chance of solving one on the 1000th try.

It's like the difference between picking the same lottery numbers all your life or picking different ones each week. There is no difference.


Does running a pruned node support the syncing of other nodes in the network?

does such a node support the syncing of other nodes in the network?

Nodes that are pruned unset the NODE_NETWORK flag, which means that they don't advertise themselves as a potential source for block synchronization. Nodes won't consider peers without this flag as a potential source for downloading blocks.

In such an early state, before pruning kicked in, does such a node serve the subset of the blocks that it has to the network?

The same flag is not set here either. During sync most nodes are typically at 100% utilization and tend to behave very sluggishly, so they wouldn't be a particularly good source for anybody else.


Mathematical areas of research within the Bitcoin field?

You could approach bitcoin and maths under many and different aspects.
You could talk about cryptography (hash function, elliptic curve digital signature,...) or about the economy.
You could talk about probability (mining, solo vs pool,...).


It seems like that's the case... I mined a min-difficulty block only 13 min after the previous block(only for testnet).


Transaction too large

Is your wallet made up up of many, many small amounts? Have you visited any sites giving small amounts of Bitcoin away for "free"? If so, your client is coughing up on the fact that all the small transactions are costing more than the fee they incur to spend.


What is is minimum possible number for an ECDSA private key?

The all-zero bitstring doesn't have a corresponding public key per the standard (according to "Are all possible EC private keys valid?" on Crypto.SE), so it's 000…001.


An uncle is a block that, in bitcoin, would be considered a stale block because it is not on the longest chain (it's an alternative block at the same height as your parent).
Ethereum incentivizes miners to include a list of uncles when they mine a block.
This has two main effects:

It decreases the incentive to centralize by rewarding miners that produce stale blocks on account of them not being part of a large pool and hence hearing about blocks later (due to network propagation delays)

It increases the security of the chain by augmenting the amount of work on the main chain by the work done in the uncle blocks (so, no work, or at least much less work, is wasted on stale blocks)

That being said, uncles introduce additional economic complexity that I'm not sure is well understood (like incentives to mine empty uncles)
Additionally, consider this paper here
(Grabbed from a Reddit post)


You can use bfgminer or the FPGA/ASIC window in MacMiner without removing parts of Mac OS

http://fabulouspanda.co.uk/macminer/

you can download just bfgminer and/or cgminer compiled for Mac OS X here:

http://fabulouspanda.co.uk/commandline/

Then you won't have to kextunload every time you restart your computer.


How to tell if Lightning nodes are lnd, c-lightning, eclair

As far as I know there is no way of knowing this on a protocol level... What you could do is to set up your own nodes (each node with a certain implementation) or some people say publicly which nodes they run. For example my node is c Lightning, ACINQ is using eclair and I believe rompert is running on lnd.
Also on 1ml.com some owners register their nodes and tell what they are running. Of course they could lie...


Hopefully, this following quote from the Github Source will help to shed some light on your trouble to get BFGMiner to use your CPU:

EXECUTIVE SUMMARY ON CPU USAGE:
By default, BFGMiner will NOT mine on CPUs unless it is explicitly compiled with
support and told to do so. CPU mining for bitcoin is generally considered to be
obsolete as it requires considerably more power per hash computed than either
GPU, FPGA or ASIC based mining. If you still wish to mine using CPUs you will
need to build a custom binary with support enabled (refer to the build notes in
README for further information).

The page continues to enumerate flags for the usage of BFGMiner with CPU.


My question is if the Wallet.Dat file on my computer (from the QT client install) were ever compromised, could that be used to steal my BTC from the blockchain?

Note that there is no such thing as "stealing Bitcoin from the blockchain". Bitcoin cannot be sent to or from the blockchain, that is not how Bitcoin works.

To answer your question, if your wallet.dat were to be compromised, your Bitcoin will be safe assuming that you have properly transferred your Bitcoin to a Ledger Nano S. By properly I mean that you generated a seed using your Ledger Nano S and creating Bitcoin transactions from your Bitcoin Core wallet that sent your Bitcoin to addresses from your Ledger. If you did that, then if your wallet.dat is compromised, your Bitcoin will be safe. The private keys your Bitcoin are associated with are on your Ledger, not in your wallet.dat file.

Of course Bitcoin sent to addresses from your Bitcoin Core wallet will still be in your Bitcoin Core wallet and not on your Ledger. Those coins can be stolen if your wallet.dat is compromised.

Even with a new wallet, it is advised that you hold onto your original wallet.dat and keep it in a secure location. You never know when you may need those private keys; someone could send you Bitcoin to an address in that wallet.


Using Armory Watch-Only wallet in Electrum?


Mining is a zero sum game so pool size has no effect other than to reduce variance not average payout.  Your goal would be to acheive 100% of fair value per share.

Some factors:

Inclusion of block fees.  While small pools which keep block fees
result in lower payout than solo mining.
Merged mining.  Currently adds a roughly 5% bonus relative to BTC only mining.
Hop proof reward algorithm.  Proportional pools are vulnerable to pool hopping.  As mining is a zero sum game anything pool hopper's gain 24/7 miners lose.
Pool fees.  Any fee paid to pool reduces revenue per share relative to solo mining.
Pool efficiency.  This one is tough because pool source code is often closed source.  If pool has a bug which results in extra 1% stale shares then that in effect is a 1% hidden fee.
Pool uptime.  A pool with 0.5% downtime is in effect costing you a 0.5% fee.  This can be partially mitigated by using miner which supports backup server.
Pool latency.  The slower communication is between you and pool
server the greater percentage of shares which will be lost as stale
in a block change.  Part of this is due to server resource
limitations but some of this also comes from geo-location.  If your
miners are located in China a pool which only has a server on East
Coast US ISP is going to have a longer than average latency.

So the most efficient pool would be one that includes transactions fee, charges no pool fee, has low latency connection to your miners, offers merged mining, has high uptime, and has no hidden back end bugs which reduce efficiency of shares.


You're right, the reverse parameter was added recently and the example in API docs were not updated.

https://bcoin.io/api-docs/#get-tx-by-address

The method now accepts a second parameter which is an "options" object. The line in the example should look like this now:

const result = await client.getTXByAddress(address, {reverse: true});

If you want to ask more specific bcoin questions you can find the developers on IRC #bcoin or on slack: https://bcoin.io/slack-signup.html

EDIT: Actually after a second look at the client code, the new options may not be available in the JS method. So thanks for asking! I'll open a PR for this ;-)


How do I receive bitcoins for a game server?

I've fiddled a bit with the plain vanilla reference bitcoin client, with the JSON-RPC server enabled, and it's all there. You can create accounts, so you can pass an address per user they can wire BTC to, query if any funds are there already (with a minimum number of confirmations), even pass the money on, to other local accounts, to remote addresses (other users or your cold wallet)

https://en.bitcoin.it/wiki/API_reference_%28JSON-RPC%29
https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_Calls_list


You can use blockonomics, its pretty fast. It also has API to give balance of given xpub.

If you don't want to submit your xpub to server you can use https://github.com/dan-da/hd-wallet-addrs. This will select random balance API service for each address and do HD walkthrough.

Added example code using blockr api, fetches balances for 20 addreses at once, should be pretty fast

import pycoin.key
import sys
import os
os.environ["PYCOIN_NATIVE"]="openssl"
import requests
BATCH_SIZE = 20
BLOCKR_URL= "http://btc.blockr.io/api/v1/address/info"
def get_used_addresses(xpub, account_type):
  xpub_subkey = xpub.subkey(account_type)
  index = 0
  addr_batch = []
  output = []
  while True:
    addr = xpub_subkey.subkey(index).bitcoin_address()
    addr_batch.append(addr)
    if (index+1)%BATCH_SIZE==0:
      results = requests.get("{}/{}".format(BLOCKR_URL, ",".join(addr_batch))).json()
      addr_batch = []
      used_addrs = [x["address"] for x in results['data'] if not x["is_unknown"]]
      if (used_addrs):
        output.extend(used_addrs)
      else:
        break
    index += 1
  return output

def main():
  xpub = pycoin.key.Key.from_text(sys.argv[1])
  result = []
  result.extend(get_used_addresses(xpub, 0))
  result.extend(get_used_addresses(xpub, 1))
  print result

if __name__ == "__main__":
  main()


How Multisignature Wallets are affected in case of a hard-fork?

No, multisig addresses are not special in any way that is effected by forks. They are just like any other output on the blockchain.

The reason it is hard for Coinbase is because they need to implement support for signing and creating transactions for those forks which requires significant engineering effort. It's the same reason that they don't support every fork in the normal Coinbase wallet - it is difficult to implement such support so they won't.


Could a hacker replace Bitcoin QT in some Linux repository and steal Bitcoins?

You know you don't have to trust the repo. The developers of Bitcoin-QT actually recommend using their binaries rather than the distro's. So you can just keep up to date with those. Official binaries are signed with a Bitcoin-QT developer's PGP keys.


What is the most widely distributed crypto currency?

As you noted, a lot of this depends on how you define your terms. In an Objectivist sense, all currencies are equally fair. :)

If we look at fairness in terms of information disparity, we can see some clear winners and losers. Information disparity is important because if insiders know that their coin is technically sound before the general public does, they can snap up coins while they're cheap.

SolidCoin had 50% of its mining controlled by special accounts that were handed out to secret parties in a secret process. (Or possibly they weren't handed out at all. There's some disagreement on that point.)
Litecoin published its source code prior to it's launch, and allowed people to mine on a test network. At launch, its code was well-understood.

If we define fairness in terms of "one person, one coin:"

AuroraCoin is a clear winner. They issued an equal amount of coins to all icelanders. They actually verified that the people claiming coins were distinct people, and not scammers.
One of the heavily premined altcoins (there's plenty of 'em to choose from) is a clear loser.

You also ask about which coin has the most distribution, which is a different question from which one is distributed the most fairly. In terms of active users, Bitcoin probably still has the most users. (Dogecoin is catching up, though.)

In terms of inactive users, AuroraCoin theoretically has 300,000 owners. (Of course, by that measure, you could increase adoption of your *coin of choice by putting money into private keys and emailing them to random people on the Internet.)


Negative balance after sendfrom bitcoind

Read this issue:
https://github.com/bitcoin/bitcoin/issues/2079

As  gavinandresen commented December 06, 2012

  Yes, that is a 'WONTFIX'.

  A sendall account  command that took the account to exactly
  zero might be a good solution, although you can still run into edge
  cases like "what if the account contains 0.000001 BTC" (fee to sendall
  might be greater than that).


Do we have to pay transaction fee if we transfer bitcoins from one wallet to another ?

No, you don't have to pay the transaction fees if you want to switch to a different wallet. If you have the private key of the first one, just import it into the second one and there you go.


Bitcoin addresses can be created anywhere with any programming language.
they're just like the result of 1 + 1 = 2.

if you are looking for the function they're using for getting a new address here you go:
https://github.com/bitcoin/bitcoin/blob/4ad3b3c72c73d61e0a0cab541dca20acf651320d/src/wallet/rpcwallet.cpp#L135

When you make RPC call 'getnewaddress' that function will be called, and addresses keys are already generated (keypool) and saved into wallet.dat file.


What are the security considerations for hosting *your own* Electrum server?

Electrum servers don't save any private information. All they do is create an interface to a bitcoind instance that is exposed in such a way the Electrum client, which stores the important and private data, can read it.

The only 'evil' thing an Electrum server could do is lying about certain transactions, feeding you misinformation. When you run your own server this is the only thing you will gain.

Encryption won't be needed, but is a good practice overall. No wallets will be saved on the server, except the wallet from Bitcoind. This wallet however will always be empty.