From the help for the sendfrom RPC/command line command:

  Arguments:

  "fromaccount"       (string, required) The name of the account to send funds from. May be the default account using "".
  "tobitcoinaddress"  (string, required) The bitcoin address to send funds to.
  amount                (numeric or string, required) The amount in BTC (transaction fee is added on top).
  minconf               (numeric, optional, default=1) Only use funds with at least this many confirmations.
  "comment"           (string, optional) A comment used to store what the transaction is for.
                                   This is not part of the transaction, just kept in your wallet.
  "comment-to"        (string, optional) An optional comment to store the name of the person or organization
                                   to which you're sending the transaction. This is not part of the transaction,
                                   it is just kept in your wallet.

Parameter 4 is for minconf. You can't just add minconf=0 to the command, though, you have to give arguments for the first 3 parameters and then specify the 4th. For example:

sendfrom "" "1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa" 0.1 0

If that still doesn't work, make sure the funds show up in getbalance "" 0. Also note that you need to leave some for a mining fee (you actually need a little bit more than the amount you want to send in order to make a transaction go through, because of the fee).


The certificate for www.bitaddress.org is issued by PositiveSSL. Chrome trusts them (PositiveSSL), firefox does not.

There are an awful lot of issuers, and different browsers are bound to have slightly different lists.

If you trust them or not is up to you. If you trust Chrome's security, then you can trust that certificate.

If you "add exception", then BEFORE confirm security exception, you can "View..."; you can check the fingerprint (SHA1 & MD5), and if they match, then the security is the same between Chrome and Firefox (not necessarily good, just the same between the two browsers). If they are different, then someone is doing something SERIOUSLY FLAKEY!

Of course, you shouldn't trust a website that throws up a warning, just because some guy on the internet told you to :)


Nicolas' docker-bitcoin image has 0.17.0 tag available, so changing that image to that version should just work:

version: "3"
services:
  bitcoind:
    image: nicolasdorier/docker-bitcoin:0.17.0
    container_name: bitcoind
    ...


Safely convert paper wallet to encrypted online wallet

Not completely what you asked for, but if you have a significant amount of money in bitcoin it makes sense to store them on a hardware wallet like trezor, ledger, ... . These cost 100$ or less and are totally worth it for ease of use and peace of mind.

I would sweep the paper wallets with mycelium and send the btc to your hardware wallet. This completely eliminates the threat of your computer being infected/hacked/etc. Since you have 10 paper wallets, I'm presuming the individual amounts might be ok to store on your phone for a few minutes.

Regarding storage, all addresses on the hardware wallet are generated starting from a 24 word seed. So you could write down 2 or 3 copies of this seed and distribute them in vaults/to trusted people. These 24 words can of course also be encrypted etc. If your hardware wallet breaks, all bitcoins can be retrieved by using these 24 words and a new compatible hardware/software wallet.


Bitcoin Testnet API that allows transaction lookup and submission of raw transactions

Blockchain.com API  could be an option. I use it for checking incoming transactions and confirmations. It is free.


Ok, I've found the problem.

Input has 52 5-bit groups. 260 bits. Remember that every encode calls convertBits to convert from 8 bit groups to 5-bit groups. But 260 bits made of bytes is impossible! So there were 264 bits originally, = 33bytes. 264 bits need to be padded by convertBits (convertBits can/will pad when encoding but won't while decoding). So we have 265 bits. 53 5-bit groups. So you need to add a zero at the end of your input to achieve the intended result.

While decoding, convertBits will, until the number of bits is a multiple of 8, check that the last bit is 0, drop it. In your case, the last bit is not zero, so the only way not to discard it is to pad it, which it's not allowed to do while decoding.

TLDR all 5-bit groups as input are converted from 8-bit groups (addresses are designed for hash outputs and hashes output full bytes). If decoding can't decode to 8-bit groups without padding, the address is considered invalid.

Let's try to do what convertBits does to decode!

First, to simplify ignore first few multiples of 40 bits in the input. The last few bits remaining are:

10000 00110 01001 10001

Convertbits, while decoding converts from 5 to 8:

10000001 10010011 0001

Does the last group have exactly 8 bits? (In that case no further action would be needed) No.
Does the last group have zeros only? (In that case we can just erase the last group) No.
Throw an error. We either need to discard bits or pad, which is not allowed while decoding.

This is why the address you generated is can't be decoded. (Try it)


Can I retrieve missing Bitcoins that failed to process as Wallet is corrupt?

If you know the password to your wallet.dat, you should try to retrieve the private key adresses and import them in a wallet such as Electrum, and see if that fixes your issue.

This is a bit of a hassle when you have lots of changeadresses though, but it is better then not being able to access your funds.

When you unlocked your wallet.dat in bitcoin core, simply go to the console and

Use

  listreceivedbyaddress 0 true

OR, if you have generated new change adresses

  bitcoind listaddressgroupings

To get a list of all the adresses that you are currently using / have balance.

Then,

  walletpassphrase "your walletpassphrase here" 600
  dumpprivkey [your Bitcoin address here]

OR, you could dump all the private keys at once, if you were using alot of different adresses using the following command:

  dumpwallet

And import these keys in a wallet such as electrum.

See if this resolves your issue.


Are there Bitcoin users in Asia especially Southeast Asia ? I'm from Malaysia

At LocalBitcoins.com you find some Malaysian traders:

Malyasian LocalBitcoins.com trades country listing

Also, there is Asian specific discussion forum.


What is the address of the servers that run the BlobVault and authd API?

The correct domain addresses for Ripple Labs are listed at https://ripple.com/ripple.txt.

See https://wiki.ripple.com/Ripple.txt


Is there a minimum number of transactions in a block?

A block may contain only one transaction: the coinbase transaction. However, the time it takes to mine a block is not affected by the number of transactions in that block, so mining blocks with fewer transactions does not benefit the miner. On the other hand, miners collect fees from the transactions they include in a block, so by including more transactions in a block, they may collect more fees.


Address no longer shows up in Bcoiner account

Unfortunately if this is a Bcoiner bug only them can recover your address and your Bitcoin.

When you generate an address, you generate a private key (linked to your bcoiner account) if Bcoiner can't recover it I'm afraid you have lost your bitcoin forever.

The best solution is then to contact them.

Remember : use a local wallet (Bitcoin-qt for example) and make a bakup of your wallet periodically, if you want to use an online service then make a local backup of your wallet to avoid this kind of problems.


Why does the median-past time average the last 11 block timestamps and not the last 12?

BIP 113's goal is not to aim for a specific offset.

Its goal is guaranteeing monotonicity (treating every block's timestamp as strictly larger than the timestamp of each of its ancestors). It does this by leveraging the existing consensus rule which states that the median of the timestamp of a block has to be strictly larger than the median of its 11 predecessors.

As to why the number 11 eleven was chosen in that existing consensus rule, we don't know. It was chosen by Bitcoin's creator.


what gives order books the V shape

I’m not sure what other shape could it be? (other than flat- no orders)? The order book represents all of the bids/asks of buyers/sellers in the market. Generally, it’s displayed in the ‘V-shape’ you mentioned, where the Y-axis of the chart displays the total cost to fill all orders between the market price, and the corresponding x-coordinate on the chart. So as you move further from the market price, there will be more orders to fill to reach that new price.

  Is it mostly as simple as that?

Yeap, it’s just the orders that traders have submitted to the order book, easy as that.


Sending getblocks message but not getting inv message response

I actually do receive the inv message. The problem is in the way that I try to decode the inv message.

The getblocks message seems to work fine.


What's the risk of publicizing a Bitcoin address?

For privacy, Bitcoin relies on "pseudonymity", which means that the only way people can choose not to disclose their identity, is by making it hard to link addresses to people/businesses/....

Publishing an address publicly obviously makes you give up that privacy, but that's not a problem. everyone is free to choose so of course. The problem is that it also makes it easier to trace the identity of others, by linking addresses after following transactions in the block chain. Publishing addresses may in this way decrease the privacy of many people using the system, including people who are unrelated to you.

Even just reusing the same address for multiple receiving transactions is already bad for the network in this sense, as it increases the ability to link transactions and addresses.

The general advice is to use each receiving address just once. This also makes it easier to distinguish incoming transactions, for example.


How to get the outbound and inbound capacity of a node using LND?

lncli listchannels will tell you the local balance and remote balance of each channel (in satoshis).

You could simply sum up the the balances of all your channels to find the total outgoing capacity (local balance) and incoming capacity (remote balance) you have. Here is a one-liner that reports the sum of your inbound capacity (requires jq):

lncli listchannels | jq -r '.channels[].remote_balance' | awk '{sum+=$1} END {print sum}'

lncli channelbalancewill give you the total outgoing capacity you have, but until AMP is commonplace, it may be more useful to know the capacity of your largest channel alone.


What is the ecological effect of increased work for the Bitcoin chain?

Blockchain.info reckons the network used    156.51 megawatt hours of electricity in the last 24 hours. This random physics page I googled up reckons a car driving at 40mph takes 100kW (so, 2.4 MWh in 24 hours).

So by these (very) rough figures, running the Bitcoin network takes about as much energy as driving 65 cars.

How many vehicles are used in the transportation of physical cash? Not to mention the energy costs of physically storing and securing cash. I'd say Bitcoin is almost certainly a net positive for the environment to the extent that it displaces physical cash.


How can I use bitcoin testnet in coinbase php

Yes, Coinbase now supports using the Testnet.


What problem set is the Minisketch library designed for? What is it currently used for and what could it be used for in future?

libminisketch is a library implementing the PinSketch set reconciliation algorithm and was covered in this Bitcoin Core PR review club. In theory it could be used for any problem where you have two sets of data and want to work out how those data sets differ (which specific elements are present in one but missing in another) as efficiently as possible.
The primary use case for Minisketch at the time of writing (February 2021) is Erlay on Bitcoin.
Erlay is a proposal for more bandwidth efficient transaction relay in Bitcoin and was covered in this Bitcoin Core PR review club. The Minisketch library is used in Erlay for set reconciliation between peers (peers generally have slightly different sets of transactions in their individual mempools).
There is also potentially a Lightning use case for Minisketch which was described by Rusty Russell in this lightning-dev mailing list post. Lightning nodes exchange gossip messages in an attempt to understand the topology of the network (nodes and channel sizes). They use this understanding to construct a route for a payment to a specific destination. This idea has not been implemented at the time of writing (February 2021). More centralized solutions such as LN-sync are currently used to address this problem.
There are also potential use cases unrelated to Bitcoin for Minisketch too. Pieter Wuille stated on IRC:

One of the most deployed uses of efficient set reconciliation algorithms is in the way PGP keyservers synchronize (or at least used to); that's using cpisync (an earlier algorithm before pinsketch was invented, which has far worse performance)

For additional possible applications of Minisketch see the Applications section of the README.


I can imagine that an SPV node encodes the transaction(s) it's interested in, into a BF and sends it to full node. What I don't understand is that what does the full node do after that?

The full node goes through every transaction on the blockchain. (Or, at least, every transaction that happened after the wallet was created.) It checks the following things against the bloom filter.

  Test the hash of the transaction itself.
  For each output, test each data element of the output script. This means each hash and key in the output script is tested independently. Important: if an output matches whilst testing a transaction, the node might need to update the filter by inserting the serialized COutPoint structure. See below for more details.
  For each input, test the serialized COutPoint structure.
  For each input, test each data element of the input script (note: input scripts only ever contain data elements).
  Otherwise there is no match.

(Source.)

If it matches, it's sent to the SPV node. The SPV node discards the false positives.

  If the goal is to preserve the privacy of the SPV's query, then some sophisticated approaches such as private information retrieval or oblivious ram must be used but they are not efficient for the bitcoin setting.

I don't know of any private protocol that doesn't require the full node to scan through the entire blockchain for every request.

If you know of one, let me know. :) Always interested to hear about that kind of thing.


How can I sign a message with a litecoin private key and also generate a litecoin address from a string?

bitcoinjs already has support for litecoin, a quick look at /src/network.js and the README reveals this.
https://github.com/bitcoinjs/bitcoinjs-lib/blob/d853806/test/integration/basic.js#L30

See how they set the network: litecoin variable, that is probably used consistently through the code (atleast for address generation).

Nothing really major changes for signing to be honest, take a look at https://github.com/bitcoinjs/bitcoinjs-message

WIF and address generation
Do not take the warning about the cryptographically secure random number generator lightly. If you do not change it then you will constantly generate the same address and it will be horribly insecure.

//import bitcoinjs libs
var bitcoin = require('bitcoinjs-lib') // v2.x.x
var bitcoinMessage = require('bitcoinjs-message')

//set a litecoin variable equal to its network type, which we'll use throughout the example
var litecoin = bitcoin.networks.litecoin

//let's generate a litecoin keypair from a string
//WARNING: YOU MUST REPLACE rng() WITH A FUNCTION THAT ACTUALLY RETURNS CRYPTOGRAPHICALLY SECURE RANDOM DATA!
function rng () { return Buffer.from('MAKE SURE THIS IS NEW RANDOM DATA EACH TIME RNG() IS CALLED') }

var keyPair = bitcoin.ECPair.makeRandom({ network: litecoin, rng: rng })

var wif = keyPair.toWIF()
//You should store the output of the variable wif here, this is the actual key to the litecoin address (contains the private key) and is crucial to signing messages, do not share this and handle with care.

var address = keyPair.getAddress()

console.log("wif: " + wif + "\n")
console.log("address: " + address + "\n")

Message signing using WIF from example1

This takes your WIF and then signs a message.

//import bitcoinjs libs
var bitcoin = require('bitcoinjs-lib') // v2.x.x
var bitcoinMessage = require('bitcoinjs-message')

//set a litecoin variable equal to its network type, which we'll use throughout the example
var litecoin = bitcoin.networks.litecoin

// add the wif key you stored
var wif = 'WIF key goes here'

var keyPair = bitcoin.ECPair.fromWIF(wif, litecoin)
var privateKey = keyPair.d.toBuffer(32)
var message = 'This is an example of a signed message.'
var messagePrefix = litecoin.messagePrefix

var signature = bitcoinMessage.sign(message, messagePrefix, privateKey, keyPair.compressed)
console.log(signature.toString('base64'))

Replace the WIF by the one you generated in the previous example.

Message verification using the address from example1, and signature output from example2

//import bitcoinjs libs
var bitcoin = require('bitcoinjs-lib') // v2.x.x
var bitcoinMessage = require('bitcoinjs-message')

//set a litecoin variable equal to its network type, which we'll use throughout the example
var litecoin = bitcoin.networks.litecoin

var address = 'THE ADDRESS FROM EXAMPLE1'
var signature = 'THE OUTPUT OF CONSOLE LOG OF EXAMPLE2'
var message = 'This is an example of a signed message.'
var messagePrefix = litcoin.messagePrefix

console.log(bitcoinMessage.verify(message, messagePrefix, address, signature))


I Think there is some confusion here regarding the generating of new address's within a wallet and the generation of Vanity Address's. Based on

  Is there any easiest way to generate coin address for all coins or can anybody tell how cryptsy do this for all coins?

I Believe what you are asking is how can you setup a system which enables users to have address's for all the different alt-coins.  This being the case you cannot do this using JUST the bitcoin software, you would need a copy of the client software for each coin you would like to generate address's for.  Then assuming you are trying to setup a Cryptocoin trading exchange similar to Cryptsy then from within the balances page (using Cryptsy as the example) when you click on a currency here and go to "Deposit / Autosell "  It then has the "Generate New Deposit Address" This will most likely be making a call to the client for the currency you have selected like:

altcoind getnewaddress $cryptsy-username

or something similar obviously altcoind would be amended forthe currency you actually wanted to generate the address for,  and the actual code to make the RPC call will be very differnt from the above, and will vary in different languages.  A good guide on implimenting RPC call's into code can be found here: https://en.bitcoin.it/wiki/API_reference_(JSON-RPC).


Blockchain.info service will not accept testnet coins so you can only test with regular coins.
As you can see in their site the minimum transfer amount allowed by their system is 0.0005 BTC so that's the minimum and no fee is required for that amount.

As you will be on the sender and receiving ends you can send any amount, if everything go as it should nothing will be lost.

On the other side I have heard about problems and delays using blockchain.info services, I don't know if they are fixed by now but probably if you are going to be using a bitcoin payment service usually you can go and check other commercial services out there.


Which account is entitled to forge the next block depends on several things.

The last block added to the blockchain includes a 32-byte "generation signature" (actually a hash). This signature is concatenated with the public key of each account attempting to forge the next block, then sha256 hashed to produce a new generation signature to be included in the next block, the block currently being forged. The 8 most significant bytes of the new signature are combined into a 64-bit integer in reverse order (little endian) to determine the "hit" value of each account.

These hit values are effectively random and can't be known before the latest block is added to the blockchain, but after that they are known throughout the network. Any account receiving a newly forged block from the network can verify that the generating (forging) account is eligible to forge, because it knows the last block's generation signature and the public key of the forger, both of which are included in the new block, and thus can compute the hit value for any account.

Because the hit value is effectively random, every account with a non-zero EffectiveBalance has a chance to forge. A low hit value is desirable, because then even an account with a low balance can get a hit. The formula for getting a hit is

hit < BaseTarget * EffectiveBalance * TimeSinceLastBlock

The BaseTarget is dynamically adjusted with each new block so that a hit occurs somewhere on the network about once per minute. A hit will eventually occur even if the hit value is by chance very high, because it becomes easier to get a hit with each passing second because of the TimeSinceLastBlock (in seconds) term.


Who has admin privilages for the bitcoin wiki?

Any mediawiki installation have a special page giving you the list of all the admins .

For the bitcoin wiki,find it at :

https://en.bitcoin.it/w/index.php?title=Special:ListUsers&group=sysop

See also :

https://en.bitcoin.it/wiki/Special:ListGroupRights


What is the normalized transaction hash of a transaction?

It is a hash of the transaction without the input scripts.  SIGHASH_ALL says all inputs and outputs are included in the hash.  These are the areas covered by the standard payment methods and they cannot be modified without invalidating the transaction.  One of the problems, though, is that there are other payment methods which do change the inputs and thus the normalized transaction ID would change in those cases.  But it does cover the common transactions.


if a Bitcoin mining nounce is just 32 bits long how come is it increasingly difficult to find the winning hash?

It is not the looping that is difficult, it is generating a hash for each iteration of that loop.  Furthermore, as @Nate pointed it, a miner will likely have to change more than just the nonce.  As more transactions are coming in from the network, a miner will add/swap them into the block they are hashing, presumably based on maximizing transaction fees.  Each time the transaction set is modified, all tried nonces can be tried again.

As for why it gets more difficult over time, that is a core part of the protocol.  Every 2,016 blocks, the target hash re-adjusts so that blocks will take about 10 minutes.  As more hashing power enters the network, the faster blocks are found, which in turn will trigger the re-adjustment after 2,016 blocks.


The default port I think should be 8332 not 8832, however if you modify your config file to include:

RPCPort=8832

Then restart server and it should work


How does Electrum wallet list my transaction record?

Electrum is backed by a number of electrum-servers (electrumx is a more recent implementation). These servers maintain the full utxo set, and also serve information such as block headers to electrum clients.

Since both your electrum installations are using the same seed, they will always generate the same addresses.

When you start electrum, it will contact an electrum server to retrieve the latest blockchain information. It will then utilize a simplified payment verification (SPV) system to query the node for transactions relating to your addresses. As it realizes addresses have been used, it will generate more addresses using the seed words.

The process of how addresses are created from a common root is described in BIP32. The SPV protocol is described in the whitepaper, and also by MultiBit (another wallet that utilized SPV systems)


You can import your private key into a new wallet, most wallets support private key imports. The private key is all you need to know.


What is the best way to recover from an accidental double-spend?

Apparently to get the RPC command removeprivkey you'll need a build of the Bitcoin client which includes pull #220 (which has been merged into main).  The latest version (currently v0.12.1) contains this feature.

Here are the instructions to do that:

Step 1. Back up your wallet.  You are performing wallet surgery here, ... and doing things you might not have intended.

Run Bitcoin as a server, e.g.,

  $ ./bitcoin-qt -server

Then

If you've encrypted your wallet you'll need to open it for RPC

  $ ./bitcoind walletpassphrase [passphrase] 1000

Then

  $ ./bitcoind dumpprivkey [bitcoin address]

Then copy and paste the private key it provides.
Then

  $ ./bitcoind removeprivkey [bitcoin private key]

Then close bitcoin-qt.

After that

  $ ./bitcoind -rescan


why banks are trying consensus algorithms like ripple

Double spending doesn't just include cases where a participant tries to spend his own funds twice, but it also includes cases where two honest participants each want the same liquidity.

For example, say I have 100,000 Euros that I'm willing to exchange for 113,000 USD and there are two people who each want to take me up on that offer. Somehow, we have to agree on which of those gets the offer, and that's precisely the same issue as a double spend.

You either need a consensus algorithm or you need a central authority.


Is there an opensource crypto-currency exchanges engine?

Yeah it's called buttercoin here is their code.


Obtain the information about a bitcoin address

If you dont want to use ANY 3rd party service, you will need to parse the entire blobkchain and put it inside a database so you can query whatever information you want.

To do that you have two options:

code your own parser for blocks/transactions, and here i suggest you using the rcpapi (its all json, nothing crazy) instead of doing it the hard way like this
use some software which can do it (something like blockexporer or Abe)

Another piece of advice: before you start downloading the blockchain, you need to set this in your bitcoin.conf

# look up historical transactions
txindex=1

Which allows you to get detailed information about "old" transactions, but this will make grow the blockchain size in your disk significantly


What is "Script Hash" address exactly and how does it work?

The P2SH, as defined in BIP 16, states that

  The purpose of pay-to-script-hash is to move the responsibility for
  supplying the conditions to redeem a transaction from the sender of
  the funds to the redeemer.

  The benefit is allowing a sender to fund
  any arbitrary transaction, no matter how complicated, using a
  fixed-length 20-byte hash that is short enough to scan from a QR code
  or easily copied and pasted.

Hence it allows any client implementation to fund a transaction with an arbitrary script, without the client necessarily having to understand it. You see, there are some quite complicated possibilities for transactions to state their claiming conditions, which may put different implementations of clients under a dilemma: each time a new script type surfaces they'd have to implement it so that the client can send transactions that make use of them.

P2SH has the advantage that the client does not necessarily have to know how to build such a script, it just has to know how (given an arbitrary script, or indeed its hash) building a script that first verifies the script and then uses that script to verify the claim itself works.

Suddenly, if I provide you with a hash of a claiming condition (script) you can send me bitcoins without actually having to know what security mechanisms I put in place to secure that only I can then spend them.

As an added bonus it really keeps the addresses small (25 byte script) which can easily be displayed in a QR code or may even be typed by hand.

The reason transaction 4005d6be is included in so many blocks is all of those blocks are orphaned, so the miners that included them supported a version of P2SH but never got a majority. The fact that this transaction is still unconfirmed is probably due to it being not a true P2SH script.


Why does my withdrawal fee not match the transaction fee I'm seeing on a block explorer website?

As an aside, Bitcoin transaction fees are paid in BTC, not in dollars. To understand how and why bitcoin transaction fees work, you need to consider them in this way.
From what you have written, it sounds like Coinbase batches withdrawals, which means they will pay many of their customers at once, in a single bitcoin transaction. A transaction can have 1 or more inputs, and 1 or more outputs, so if you have to pay many people, you can save costs by sending one transaction, which pays all of those people at once, rather than individual transactions witch pay them one at a time.
When Coinbase processes your withdrawal, they can charge you whatever they would like ($2 in this case). But the actual transaction fee that Coinbase paid to make that bitcoin transaction was apparently around ~$80 worth of BTC. Whether the sum of all fees they charged their customers would be equal to this amount, or more, or less, is all just a matter of Coinbase's company policy.


What security weaknesses result from using off chain solutions?

TL;DR:

The security assumptions of using a LN channel for payments:

The blockchain is functioning well (confirming transactions quickly)
Channel nodes can keep secret data safe
There aren't any significant bugs in the software

With the Lightning network specifically, the security of the off-chain payment always depends on being able to take the transaction onto the real blockchain "if needed". When both parties cooperate, the number of on-chain transactions is minimized, but both parties rely on being able to cash out, using the real blockchain, if the other party stops cooperating or goes offline for an extended period of time. In addition, if the other party acts maliciously, you rely on being able to use the blockchain to punish their malicious actions.

One security risk lies here: if you cannot get transactions confirmed into the blockchain, you won't be able to get your money out of the channel, or to take counter measures when the other party tries to cheat you! So a well-functioning blockchain (confirming transactions quickly) is a definitely one security assumption of using the lightning network. So block crowding is one risk, since there won't be enough room for your transactions. Miners could also be bribed to not mine your transactions, although this is not a severe risk since it is likely that a different miner would confirm your transaction.

To understand some of the other security assumptions used in the lightning network, consider the following example. Suppose Alice has a payment channel open with Bob. First the channel balances read:

Channel Balance 1:
Alice: 0.5 BTC
Bob:   0.5 BTC

Then Alice makes a payment to Bob for 0.1 BTC, and the updated channel balances read:

Channel Balance 2:
Alice: 0.4 BTC
Bob:   0.6 BTC

But Alice decides she wants to try to cheat Bob! She tries to broadcast the transaction for Channel Balance 1, in which she gets 0.5 BTC, which is more favorable to her than her balance in Channel Balance 2, just 0.4 BTC. What's to stop her from doing this?

First, there is a waiting period before she can actually spend the funds from her 0.5 BTC output in Channel Balance 1 (technically the wait period applies to Channel Balance 2 as well). This wait period exists to give Bob sufficient time to notice that Alice has closed out the channel, and possibly take action if Alice has broadcasted an old version of the channel. In this case, since Alice closed out the channel with an older version of the channel state, Bob can actually take all of the funds in Alice's 0.5 BTC output! Hence, Alice is disincentivized from broadcasting old versions of the channel state.

The problem is that if Bob can't get his transaction that took the 0.5 BTC from Alice into the blockchain, then the wait period will end and Alice will have the opportunity to take the 0.5 BTC, successfully stealing 0.1 BTC (because she should only be allowed to take 0.4). So Bob depends on being able to take counter measures against Alice in the real blockchain before a wait period ends if Alice tries to broadcast an older version of the channel state.

(Note that this wait period also applies to Bob if he needs to get funds out of the channel without the help of Alice. Even if he broadcasts the most recent state of the channel, he has to wait. While this wait period may be inconvenient for Bob, Alice also has to abide by the wait period, which is what gives Bob a chance to take all of the funds in the channel if Alice tries to broadcast an old version of the channel. If things go as planned, though, and no one goes offline, then Alice and Bob can agree to make a new transaction to close the channel, where neither one has to wait to spend their funds.)

There is also a data security risk. Proving to the other channel party that you will not try to broadcast previous versions of the channel balance state involves giving the other channel party a bit of secret information, typically the preimage of a hash. Usually you only reveal this data to your channel counter-party when you update the state of the channel and receive a new guarantee of payment (just with a different balance). After you receive the new payment, you can reveal the secret information that invalidates the previous payment by giving them the ability to steal the funds from that old channel state if you try to broadcast it.

But if the secret data associated with the current state of the channel is revealed or stolen before you get a separate payment guarantee transaction, then effectively all of your transactions have been revoked and your channel counter-party can steal all the funds from any channel transaction you broadcast! So, the security of a LN payment channel depends on being able to keep data safe.

Another risk is simply bugs in software. If your software doesn't automatically handle all the edge cases of broadcasting the right transaction at the right time, and your counter party discovers that, they can take advantage of it and steal funds from the channel.


How Bitcoin-Core does decide whether high fee during sendrawtransaction?

What exactly is the high fee that Bitcoin Core is talking about? Does this client have exactly fixed number?

Bitcoin Core has a hard limit for what it considers to be an absurdly high fee, which is 0.1. Other node software may not impose this limit, or may have a different value for it.

Note that this is not part of the standard tx rules. It is simply a check to limit the fees for a single transaction.

  Can I broadcast a transaction programmatically without any fee restrictions as intended if I use custom client?

You can remove the fee check from validation.cpp.

  If 2 is possible, can hackers make spamming attacks by setting fees lower than the current minimum limit(0.00001 BTC/kB)?

You can just change the minrelayfee flag to go under the limit. There is no flag to override the high fee parameter, as far as I'm aware.

There are plenty of nodes on the network that will broadcast a high fee tx. Indeed, there have been a few cases of very high fees in the past, such as 13.65 BTC, and even 200 BTC (this one was before the high fee check was added in 2015, though)!


how to stop bitcoin transfers from unknown parties?

Receiving Bitcoins is entirely passive. The receiver plays no part in the process whatsoever. There is no way to refuse a Bitcoin transaction, other than to transfer the Bitcoins back to the sender.


Is there a source for historical LTC trades available?

These files contain every LTC trade from day 1 through about 2:20pm UTC on 31-3-2013.

LTCBTC @ BTCe Oct 2011 through March 2013
http://www.mediafire.com/view/?5cwjmviou15k32h

LTCUSD @ BTCe Oct 2011 through March 2013
http://www.mediafire.com/view/?cn5qxi44j6egrad

also Kraken LTCEUR charts are here:
http://api.bitcoincharts.com/v1/csv/

I'm looking for 2013 and 2014 BTCe LTCUSD and LTCBTC.

please help


Bitcoin Wallet Empty after importing using key phrase

Any idea what has happened and if/how I can recover my Bitcoin?

First of all, try to find out what software have you used originally. Was it a desktop/mobile wallet? What was the name of the application you set up the wallet through?
Please check out this website and check the column Paths. If your original software wallet supported path like m/0' but due to software upgrades the new version supports a new path like m/44'/0'/0' or it's maybe a completely different software wallet that supports other paths like m/49'/0'/n' - in these cases new wallet won't show you any balances as addresses are being derived differently in these different paths.
If you know your addresses from a previous wallet you may also try the Iancoleman tool, remember to use it in offline mode and I would personally not use it for bigger amounts anyway.


Is there any way to track an individual bitcoin (or satoshi)?

Here is a possible schema describing transactions from two addresses A and B that contain initially 50 BTC each:
     (A) 50 btc --tx1-----------------------> 25 btc (C)
                   \
                    `-> 25 btc (D) --.
                                      \
                                       tx3--> 50 btc (*)
                                      /
                    .-> 25 btc (E) --'
                   /
     (B) 50 btc --tx2-----------------------> 25 btc (F)

There are three transactions here, and they mention only values: those transactions are stored in the block chain like:

tx1: (input on A: 50BTC; output on D: 25BTC, output on C: 25BTC)
tx2: (input on B: 50BTC; output on E: 25BTC, output on F: 25BTC)
tx3: (input on D: 25BTC,  input on E: 25BTC; output on *: 50BTC)

Only global amounts are involved, not individual satoshis. Could you tell where each of the satoshis in * came from? A or B? Just impossible.
Conclusion: There is no such thing as individual satoshis, they don't have identities in the Bitcoin framework.
(And it's the same, or even worse, for bitcoins. An individual bitcoin is not well defined. It might be a grouping of smaller amounts in the same place (wallet), or at the same address, or in the same transaction, but at a given point in time.)
It is however possible to track money flows between addresses, which may “dilute” into other flows, as illustrated in this answer.


How Do Peers Choose Which Peer To Trust?

either I broke some rule, or the other person did; In this case, how does my client find a trusted peer

Your client does not trust any peer. It fully validates the blockchain. In the event of multiple conflicting blocks at a given block height, your node will choose to go with the first block it hears of. However it will still retain and validate all of the other blocks that it has received for that block height. Only after more blocks have been mined does it actually choose which of those conflicting blocks becomes part of its main chain. It chooses based upon which branch has the most cumulative work.

There is no trust in this process; it uses first heard initially and then will readjust if later blocks belong to a different branch. These reorganizations are why it is recommended to wait for multiple confirmations as one block reorgs are not uncommon.

Also, the blockchain with the most cumulative work (typically referred to as the longest blockchain) is not the only determination for what blockchain to use. The blockchain also has to be valid, it can't just have the most work.

  2: Lets say I stopped my client for 100 days, during those 100 days there was 500 new transactions, which means that if I was to compare my last block with someone elses then my client would be outdated, therefore it needs to download the extra blocks, where does it find these blocks and how does it determine which peers to sync to and to trust?

Your node does the normal peer discovery process every time it goes online. Your node will then randomly choose one of the peers it has connected to to be the "sync node". It doesn't actually sync much off of this node, just the block headers. It downloads the block headers from this node and validates them. Then it will download the blocks for those headers from the other nodes it has connected to.

Once the headers chain of one node has been synced, it will request the headers of other nodes to get an idea of what their best headers chain is in order to determine if the sync node was dishonest.

Again, there is no trust in this process as all blocks and headers are still fully validated. Since the download involves checking against multiple nodes, it is unlikely that your node will have the incorrect blockchain as not just one node dictates what chain you download.

  so the question is what is the real need for the nonce?

The nonce is completely unrelated to validity except for the fact that it is part of the block header which is hashed. The nonce's sole purpose is to have something to change when mining. It provides no security characteristics nor is it related to the consensus rules (except for the fact that it has to exist, it could be zero). Miners could very well just not do anything to the nonce and change something else to get a different hash. It exists solely as a convenience.


Are there any hardware privkey/pubkey generators out there?

There are no devices I know of which are dedicated to nothing but generating secp256k1 key pairs.  I suspect there never will be---that's a super-niche market possibly consisting of just you.  Moreover, I think you should be suspicious of any hardware designed to generate private keys for Bitcoin: corrupting such hardware to produce predictable keys could be highly profitable---at your expense.

In general, messing around with private keys directly has a high probability of ending in lost bitcoins.  A $50 USD used netbook from eBay to use as an offline signing-only wallet will be much easier to use and at least as secure as any system you think up yourself, provided you choose a secure wallet.


Is there any way that when requesting the peers list of a node, the node could provide a fake peers list with a number of 'bad' nodes?

Certainly. It's impossible to check whether nodes are good or bad without connecting to them. A node can just return whatever IP address and port combinations it wants and the receiver will need to determine for itself whether they are good or bad.


is there any other way to recover it from r s z ?

What is the purpose of private key, if anyone would be able to recover it from other data?

  is it possible to recover any private key using random R values ?

the probability is the same as trying random values for guessing private key itself


The minRelayTxFee specifies a feerate acting as a lower bound for a node's mempool. A node will not admit unconfirmed transactions below that feerate to its mempool and thus will not relay them to its peers. The minRelayTxFee is a configuration setting and can be specified by each node operator independently. The value only impacts unconfirmed transactions, transactions included in a block are processed even when they do not meet the minRelayTxFee. Note that contrary to its name's implication, the minRelayTxFee is not an absolute fee, but a feerate.
The current default value for the minRelayTxFee in Bitcoin Core is 1000 satoshi/kB (= 1 sat/B). A node operator may specify a different value via the startup parameter -minrelaytxfee=<amt> or the configuration parameter minrelaytxfee=<amt> which takes an <amt> in [BTC/kB].
The minRelayTxFee also serves as the basis to calculate the minimum cost increments for replacement transactions per BIP-125 (Opt-in RBF). It was also previously used to calculate the dust limit which has since been decoupled into a separate feerate called DUST_RELAY_TX_FEE with a default value of 3000 sat/kvB (H/T Darius).
minRelayTxFee should not be confused with:

minTxFee, which is a wallet configuration setting that sets a lower bound when creating new transactions
mempoolminfee, which is an independent lower bound for mempool acceptance that dynamically increases when the mempool limit is exceeded

Bitcoin Core 0.13.0 introduced a new, optional feefilter P2P message, which will tell neighboring nodes not to send transactions below the filter's feerate. Older nodes do not communicate their minimum feerate, but rather just drop incoming transactions that doesn't pass it.
You may retrieve the current values for your node by calling the getmempoolinfo RPC.


Which cloud server provider is best for accepting bitcoin payments with BTCPay Server?

Actually, it's my video :D
Lunanode provides easy "1 click install" process. You can host btcpay server on any other VPS server (like azure, aws, digitalocean etc.) but the process will be just a bit more complicated, and will require downloading and configuring btcpayserver.
As always any solution will have some tradeoffs, like cost or how easy it is to use, how reputable is the provider, etc.
All methods of hosting are presented in this document.


The whole point of Elliptic Curve Cryptography is that it is not possible to do such an operation. If it were, ECC would be broken, along with everything that uses it.
With current technology and algorithms, it is not possible to do what you are asking.


Because they aren't the same. It appears that this script IDE interprets things inside of angle brackets (< and >) as strings, not as hex values. However a hash is not a string, it is a sequence of bytes which may be represented using hexadecimal values.

So what your script is actually doing is putting the string 1PUzZ61FSVTn12CafJC85Vy1ts3BoFcXdU on the stack and then hashing it and putting the byte value E105E01B92119CC55D753248CE3A32C82A9BB308. But then you push the string E105E01B92119CC55D753248CE3A32C82A9BB308 onto the stack except this has a byte value of 45313035453031423932313139434335354437353332343843453341333243383241394242333038. The OP_EQUAL is then comparing the two byte values E105E01B92119CC55D753248CE3A32C82A9BB308 and 45313035453031423932313139434335354437353332343843453341333243383241394242333038 which are obviously not equal to each other and thus the script fails.

Instead you need to tell this program that you want to push the byte values E105E01B92119CC55D753248CE3A32C82A9BB308 to the stack, not the string representation of these hex characters. To do that, just don't surround it with angle brackets. This works for me:

<1PUzZ61FSVTn12CafJC85Vy1ts3BoFcXdU> OP_HASH160 E105E01B92119CC55D753248CE3A32C82A9BB308 OP_EQUAL


Is https://www.bitaddress.org/ safe to create a paperwallet?

Yes it is, because the 100% of entropy (randomness) is generated by the user.

Just make sure you're downloading it from https://github.com/pointbiz/bitaddress.org > green "clone and download" button > download as zip.


Bitcoin uses TCP. Configure your firewall to open TCP port 8333.


How to get started with a Bitcoin wallet

No need for Tor at all (unless you intend to buy drugs or weapons, but in that case you're better off using cash dollars or euros).

I'd recommend to read up on Bitcoin to understand what you're doing. Then you can find an overview of wallets on bitcoin.org, but for a quick start, the fastest way to get started is:

Desktop (Windows/Mac/Linux) : Electrum or MultiBit
Android : Bitcoin Wallet by Andreas Schildbach
iOS : Bread Wallet
Windows phone : Get an Android phone instead
Web wallet, accessible anywhere : Coinpunk

These are all fairly easy to use, and don't bother you with all kinds of advanced options.


While I did wait for the blockchain to download and to see if Bitcoin-Core could simply read its own file. The program failed to read in any of the info from my wallet.dat file, even after following the instructions in the post listed in my initial question. I ended up using walletool, which worked without a hitch. It gave me a list of every public and private key associated with the wallet. It has a script for checking your balance, but I was unable to get it to work reasonably quickly and ended up manually checking the balances of each address using bitref.


How to retrieve BCC mistakenly sent to BTC Electrum wallet?

Can you find the BCH on a block explorer website? What address are they currently in? Is it one that you control the BTC keys using electrum? If yes, then do the following:

You'll need to take the seed from your BTC Electrum wallet, and use it to generate a new BCH wallet using BCH software. Your BTC Electrum wallet will not show a BCH balance, since BCH is a different network (that uses the same addressing scheme).

It is a good idea to send ALL of the bitcoin out of your wallet, before you generate the BCH wallet using the seed. This is important, it ensures the keys that control your bitcoin remain safe. If the BCH software you use is malicious for some reason, it might check the BTC balance of the addresses you control, and steal the bitcoin from you.

Even if there is a small chance of this, you can be safe by just transferring all of your bitcoin out of electrum first, and then deal with the BCH.

Also, don't transfer the btc back to that wallet afterwards. You can still use electrum, you just have to make a new wallet with a seed that is different from the first one.


I used CoinSwitch.co for a couple of altcoin conversions. They provide best rates, as we can compare the rates first then only we can create orders. Their live chat support is also good.


Given a private key, how do you get a public address

In ECDSA public keys are usually generated from a random private key. The simple answer then would be, that instead of using a random private key, you use the given private key and it should generate the public key. After that, perform the steps listed in the Wiki to find out the conventional notation for the public key you can use anywhere.


How to get value of incoming transactions from Blockchain.info API

Check to see how many outputs total for the tx using .length and then do a for loop and run through every output for each transaction. Use an if statement to check if that particular output has your desired address in the 'addr' field. If it does match then print that value to the screen.

I made a fiddle that I think should work, I didn't test it though... http://jsfiddle.net/nmgus1fa/

var btcs = new WebSocket('wss://ws.blockchain.info/inv');

btcs.onopen = function()
{
btcs.send( JSON.stringify( {"op":"addr_sub", "addr":"15wsV4TYvGPrJnhoyCed6kWcNUuSo5ykRi"} ) );
};

btcs.onmessage = function(onmsg)
{
  var response = JSON.parse(onmsg.data);
  var getOuts = response.x.out;
  var countOuts = getOuts.length;
  for(i = 0; i < countOuts; i++)
  {
    //check every output to see if it matches specified address
    var outAdd = response.x.out[i].addr;
    var specAdd = "15wsV4TYvGPrJnhoyCed6kWcNUuSo5ykRi";
       if (outAdd == specAdd )
       {
       var amount = response.x.out[i].value;
       var calAmount = amount / 100000000;
       $('#messages').prepend("<p>" + calAmount + "</p>");
       }
  }
}


OP_PUSHDATA1 is not allowed inside redeem script of P2SH?

OP_PUSHDATA1 and even OP_PUSHDATA2 are allowed inside P2SH scripts fine. However, there is another policy in Bitcoin Core to require that all pushes are minimal in standard transactions. That means you can only use OP_PUSHDATA1 when a direct push is not possible (up to 75 bytes), and only use OP_PUSHDATA2 when an OP_PUSHDATA1 is not possible (up to 255 bytes).

Also, in general: when experimenting with scripts, try things on testnet first.


Somebody sells at 4k instead of 40k. Who gets it?

AFAIK, if it is the same as stocks, then it is "The person who entered it first", meaning:
If somebody put in the limit order to Buy At $33,000, before you, then your $4000 will be matched to his limit order, but because he entered it first, then the transaction between you and him will be $33,000.  That's the rule.
There are tons of buy orders to buy at $33,000 or $32,999, so the $4000 will be matched by those numbers first. (and it will be sold at $33,000 or whatever the highest bidder is).


How will node handle two branches of same length?

This phenomenon is known as a chain-split (i.e. the bitcoin network can no longer agree which chain is the canonical chain).

Nodes will be network-partitioned until one chain becomes dominant.

Therefore:

  Is the information of the length and accumulated difficulty broadcasted along with mined block?

No.

  How will the recipient node handle this situation?

Nodes will handle equal branches on a First Come, First Serve basis, so there will be a network partition where some nodes agree chain A with length N+4 is the canonical chain and the other set of nodes will assume chain B with length N+4 is the canonical chain. In the event of such a chain-split, the race is on for miners to produce a new block-tip and broadcast it across the bitcoin network ASAP to achieve convergence. When the contention is resolved, the node can switch to longer branch and obsolete the old branch.


Lightning: why do we need decrementing timelocks in multi-hop payments?

I use the following scenario for both questions:
Alice wants to pay 1 BTC to Dave via the route:
Alice -> Bob -> Carol -> Dave

Why do we need timelocks?

Lets assume that the payment route has just been established. Meaning: Each hop in the route (A, B, C, D) has an HTLC with its neighbor hop(s). However, the HTLCs would not have any timelocks. Now Dave sends the secret R to Carol who in turn sends R to Bob. However, Bob doesn't respond (e.g. because his node crashed). Unfortunately Alice has no clue why Bob doesn't send R to her. So she has to wait until Bob becomes responisve again. Now that could take an hour, a few days, a few weeks or maybe he will never respond again. The problem for Alice is that the HTLC between her and Bob is valid indefinitely. So without a timelock the money committed to this HTLC may be stuck for a very long item and Alice cannot do anything about it.

What's the benefit of decrementing timelocks?

Decrementing timelocks are useful for intermediate hops (all hops other than the first and last one). In our example the route is:

 A -> B -> C -> D

So B and C are the intermediate hops. Now according to the HTLCs, an intermediate hop can claim money from the previous hop and has to pay money to the next hop. For example: Carol can claim money from Bob and has to pay money to Dave.

Generally speaking that means: A hop „HOP“ has to make sure that after the next hop „NEXT“ claimed the money from HOP, HOP will be able to claim the money from the previous hop „PREV“ before the HTLC between PREV and HOP is invalidated (timed out). And an easy way to do this is by ensuring that the HTLC-timelock between HOP and NEXT is (significantly) lower than the one between HOP and PREV.

Here's an example of what could happen if all HTLCs would have the same timelock. For this example we assume that the timelock is „T+10 blocks“ (T = a fixed block number). So when the blockheight is at T+10 blocks or later all HTLCs „timed out“ and:

Bob can reclaim his committed money from the HTLC with Carol
Carol can reclaim her committed money from the HTLC with Dave

Now after the payment route has been established the following happens:

After a delay (at T+8 blocks) Dave sends the secret R to Carol. By doing this he proved Carol that he can (legitimately) claim the money from their HTLC. As both parties don't want to close their channel yet, they update the channel state accordingly instead. By doing this, Carol has just irrevocably paid money to Dave.

However, Carol hasn't received any money from Bob yet. So she sends R to Bob. But Bob doesn't respond! This is unfortunate for Alice as in 2 blocks (~ 20 minutes) Bob can reclaim his money! To prevent this, Carol has to immediately close the channel with Bob by broadcasting the Committment Transaction that contains the HTLC. At the same time she also has to send another „delivery transaction“ that (intends to) actually transfer the money from the HTLC (between her and Bob) to herself. However, unfortunately there is no guarantee that both transactions are actually included in the next block (T+9). But if only the HTLC is included in block T+9, Bob can broadcast his own „delivery transaction“ that (intends to) transfer money from the now confirmed HTLC (via the output's „timeout path“) to himself. So now there are two „delivery transactions“ in the mempool that use the same HTLC-output. As we know, double-spending is not allowed. So only one of these transactions will be included in a subsequent block. And if Bob's transaction will be included, Alice will lose her money.

Having said all that, I think technically it would also be possible to do trustless multi-hop payments without decrementing timelocks. But this concept is probably much easier to implement and maintain..


Bitcoin Vanitygen > how to edit .cl kernel file to so that it will verify the public key directly instead

Each additional specific character you want in your vanity address will make the search 58x as long. In other words, you will find 58x as many 9 character matches, as 10 character matches. If the vanity generator is working otherwise, just keep searching.

  how to edit the .cl kernal file see verify the public key directly instead of converting it to an address and then comparing it

No, there is no way to tell what the address will be, without converting the public key to an address. Part of the address derivation involves hash functions, so you cannot know the output just by looking at the input value, you must invoke the hash function to get this. The best you can do is to randomly pick private keys, and then derive the address of each one and check to see if it matches your desired string.


Qt is a cross-platform application and UI framework for developers using C++. It's is used for UI in Bitcoin-Qt. See http://qt-project.org/


No, in general wallets are just tools to manage bitcoins already in your possession. The only exception I can think of is Mycelium, which includes a functionality to find buyers and sellers nearby.

To find out how to get bitcoins, check out How do you obtain bitcoins?.


how fast does a Sapphire R9 280X Varpor-X Tri-X can and how can i calculate the bitcoin i can have pers day?

Hashrate for the Saphire can be found here:

https://litecoin.info/Mining_hardware_comparison

Don't bother GPU mining, especially for SHA-256 (bitcoin). You can blow one of those out of the water with a $20 used USB ASIC on ebay. The days of casual mining are over, you will be operating at a loss unless you have some of the cheapest electricity in the world and a large mining setup.


Blockchain.info: Which address should I give for "New Shared Address"?

The one marked "Address". It will forward it to the one marked "Forward To".


A life-cycle of a transaction - correct?

Transacions don't have input and output addresses, they have input and output scripts. Addresses are just short-hand notation for particular scripts.

When making a transaction, you don't just say what the input and output scripts are. You have to explicitly reference which UTXO (unspent transaction outputs) a transaction spends, and then you also make a set of new UTXOs. Each UTXO has an amount associated with it.

  t2 has input address as a1 as described here - What does a transaction look like?

If t2 is trying to spend the coins that were sent to it in t1, then it would need to reference t1 (not a1 or a2). Specifically, it would need to reference the UTXO in t1 that credited the a2 script.

  Because t2 does not mention a2, the anonymity of a2 is preserved.

Not really. Anonymity is only preserved by not linking your address to your name, such as by posting on a social media website.

  t2 is confirmed because unspent balance of a2 at this point is 50.00 BTC. (Not sure how, but sounds like it.)

If t2 were confirmed, spending the UTXO made in t1, then, yes, it would be successful because the total inputs is more than the total outputs. Actually, it's total inputs are 10 BTC more than it's total outputs, so that 10 BTC would just go to the miners (and not be left on the 'address balance').

  After t2 is confirmed, unspent balance of a2 is 10.00 BTC.

Not actually, like mentioned above, it doesn't really work like that. Transaction outputs are either completely spent or are unspent. So after t2, the output is completely spent. If the 10 BTC is not sent to another output in t2, then it is just assumed to be a very generous miner fee.


What is the use case of bitcoind ZeroMQ?

ZeroMQ is a publisher / subscriber messaging system. In the case of Bitcoin Core it is a socket which other applications can connect to and get notifications of new events in real time, without having to repeatedly ask the daemon if there are any new events. ZMQ support is useful for any systems interfacing with the network like miners and wallets, which can choose to subscribe either to just transaction notifications or block notifications as their situation requires. It covers a lot of the same use area as the prexisting walletnotify and blocknotify systems, but with significantly improved performance and ease of configuration. These older systems have the unfortunate side effect of spawning a new process for every notification, which tends to incapacitate the host if not used extremely carefully.


is it okay to disconnect Antminer like S7 >

While you aren't connected to the internet you can't submit shares to your pool, so you won't earn anything during that time period. That's why it's recommended for miners to have fast, low latency connections.


Are wallets compatible with different clients?

Almost every client has the option to export your Private keys.

MultiBit also has this option.

You can think of a wallet file as a container for your Private Keys and a list of your transactions. This wallet may be in a different format for different clients, but you can always export your Private key, and that is what matters most.

Bitcoin-qt has a wallet with a key pool and addresses that does not show. The best way to move your coins is to send them to a new address in your new wallet. But if you have a favorite address you want to keep, you can export from the Console with "dumpprivkey".

Here is my answer, how to export from every client

But there are also services that keep the Private keys.  These services do not allow export.

Coinbase
Coinkite (You get your private keys - but encrypted)


How do I get a vanity address from a hierarchal deterministic wallet?

You can do this but the advantage of HD wallets effectively diminishes. You can simply brute force by iterating over all the indices of the HD wallet until you find one that has the vanity characteristics you want. However, its possible that it is sufficiently hard enough to find that you will have to save off the private key anyway.

The entire point of HD wallets is that you only need the master private key/seed to generate all your addresses. If you end up with an index that so far out from the last used address, you might not be able to find it in the future without also having saved the private key for the vanity address.


How do you create a transaction from a UTXO in BitcoinJ?

Sort of. Here's some code to get you started. It creates a transaction with one input and two outputs. One output sends some coins, another one commits some data. However, it still uses Wallet::sendCoinsOffline to complete and commit the TX, but I think you could get rid of it if you understand what Wallet::completeTx and Wallet::commitTx do.

public class App extends WalletAppKit {
    public void commitStatement(String statement) throws InsufficientMoneyException {
        Address addr = getSomeAddress();
        TransactionOutput prevLink = getSomeUtxo();
        NetworkParameters params = RegTestParams.get(); // regtest mode

        byte[] data = statement.getBytes();
        if(data.length > 80) {
            throw new RuntimeException("OP_RETURN data cannot exceed 80 bytes");
        }

        Transaction tx = new Transaction(params);

        log.trace("prevLink TX for '" + statement + "': " + prevLink.getParentTransaction());

        tx.addInput(prevLink);

        Coin feeAmt = Transaction.REFERENCE_DEFAULT_MIN_TX_FEE;
        Coin opRetAmt = Transaction.MIN_NONDUST_OUTPUT;
        Coin changeAmt = prevLink.getValue().minus(opRetAmt).minus(feeAmt);

        // 1st output: send coins
        tx.addOutput(changeAmt, addr);
        // 2nd output: commit some data
        tx.addOutput(opRetAmt, ScriptBuilder.createOpReturnScript(data));

        log.trace("TX for '" + statement + "' before SendRequest: " + tx);
        SendRequest req = SendRequest.forTx(tx);
        // Want inputs and outputs to keep their order
        req.shuffleOutputs = false;
        req.ensureMinRequiredFee = true;

        log.trace("SendRequest for '" + statement + "' before completeTx: " + req);
        wallet().sendCoinsOffline(req);

        // NOTE: At this point, the TX is saved in the wallet!
    }
}

Later edit: So here's an example of how you can modify completeTx and sendCoinsOffline. I actually had to do this today for my own purposes by subclassing the Wallet class. You probably need to take a different route than subclassing Wallet but this should give you an idea of what you need to do.

Warning: This modified code takes care of signing and paying the fee only for these special-kind of transactions with one input and two outputs. Seems to work so far as I've tested it.

public class MyWallet extends Wallet {
    private boolean payFee(Transaction tx, Coin feePerKb, boolean ensureMinRequiredFee) {
        final int size = tx.unsafeBitcoinSerialize().length;
        Coin fee = feePerKb.multiply(size).divide(1000);

        if (ensureMinRequiredFee && fee.compareTo(Transaction.REFERENCE_DEFAULT_MIN_TX_FEE) < 0)
            fee = Transaction.REFERENCE_DEFAULT_MIN_TX_FEE;

        TransactionOutput output = tx.getOutput(0);
        output.setValue(output.getValue().subtract(fee));

        return !output.isDust();
    }

    public void myCompleteTx(SendRequest req) throws InsufficientMoneyException {
        lock.lock();
        try {
            // Print the output value
            Coin value = Coin.ZERO;
            for (TransactionOutput output : req.tx.getOutputs()) {
                value = value.add(output.getValue());
            }

            log.debug("Completing send tx with {} outputs totalling {} (not including fees)",
                    req.tx.getOutputs().size(), value.toFriendlyString());

            // Check for dusty sends and the OP_RETURN limit.
            if (req.ensureMinRequiredFee && !req.emptyWallet) { // Min fee checking is handled later for emptyWallet.
                int opReturnCount = 0;
                for (TransactionOutput output : req.tx.getOutputs()) {
                    if (output.isDust())
                        throw new DustySendRequested();
                    if (output.getScriptPubKey().isOpReturn())
                        ++opReturnCount;
                }
                if (opReturnCount > 1) // Only 1 OP_RETURN per transaction allowed.
                    throw new MultipleOpReturnRequested();
            }

            // Pay for the TX fee, depending on the TX size.
            Coin feePerKb = req.feePerKb == null ? Coin.ZERO : req.feePerKb;
            if (!payFee(req.tx, feePerKb, req.ensureMinRequiredFee))
                throw new CouldNotAdjustDownwards();

            // Now sign the inputs, thus proving that we are entitled to redeem the connected outputs.
            if (req.signInputs)
                signTransaction(req);

            // Check size.
            final int size = req.tx.unsafeBitcoinSerialize().length;
            if (size > Transaction.MAX_STANDARD_TX_SIZE)
                throw new ExceededMaxTransactionSize();

            final Coin calculatedFee = req.tx.getFee();
            if (calculatedFee != null)
                log.debug("  with a fee of {}/kB, {} for {} bytes",
                        calculatedFee.multiply(1000).divide(size).toFriendlyString(), calculatedFee.toFriendlyString(),
                        size);

            // Label the transaction as being self created. We can use this later to spend its change output even before
            // the transaction is confirmed. We deliberately won't bother notifying listeners here as there's not much
            // point - the user isn't interested in a confidence transition they made themselves.
            req.tx.getConfidence().setSource(TransactionConfidence.Source.SELF);
            // Label the transaction as being a user requested payment. This can be used to render GUI wallet
            // transaction lists more appropriately, especially when the wallet starts to generate transactions itself
            // for internal purposes.
            req.tx.setPurpose(Transaction.Purpose.USER_PAYMENT);
            // Record the exchange rate that was valid when the transaction was completed.
            req.tx.setExchangeRate(req.exchangeRate);
            req.tx.setMemo(req.memo);
            //req.completed = true; // FIXME: ALIN: This field is private, can't set it to true, but thankfully this is just for debugging.
            log.debug("  completed: {}", req.tx);
        } finally {
            lock.unlock();
        }
    }

    public Transaction mySendCoinsOffline(SendRequest request) throws InsufficientMoneyException {
        lock.lock();
        try {
            myCompleteTx(request);
            commitTx(request.tx);
            return request.tx;
        } finally {
            lock.unlock();
        }
    }
}


Has consensus been reached regarding the block size?

There is and has been huge consensus since the scalingbitcoin.org conference in Hong Kong in December 2015 in favor of going with the Segregated Witness solution. SW had been implemented half a year earlier in a side chain but in Hong Kong Peter Wuille (starts around 35 minutes or later repeated here: https://youtu.be/NOYNZB5BCHM ) announced that a way to smoothly incorporate it into existing Bitcoin (via a Soft Fork) had been found.

The main goal of SW was to eradicate transaction malleability but it has many other advantages, as well as the nice side effect of making the effective block size larger. To around 1.8MB, although the exact amount depends on the type of transactions people do, it could be more.

The finishing touches are being applied to SW in a test network right now, while wallet software is also being updated to make use of SW transactions so their users will enjoy its benefits. Last I heard SW is scheduled to be rolled out in April 2016.

Pretty much everyone agrees, including on the opposing team, that SW is a great solution. Unfortunately for political reasons, the classic team have decided to keep spreading untruths and FUD about SW and the Core team. For example that SW is more complex than a straight up doubling of the block size through a Hard Fork or that such a Hard Fork could be rolled out faster. As well as unfounded conspiracy theories about ulterior evil motives of members of the Core team.

Fortunately classic is an irrelevantly small group of people who for the most part clearly don't know anything about Bitcoin.

Core has almost unanimous miner and community support and is streaming ahead with improvements, SW and many others.


Can a merchant find my other bitcoin addresses in the same wallet if it sends me money to one?

If you are only receiving funds then no, the merchant cannot link the addresses. The problem is if you are also sending them funds. With most wallet software when you create a transaction it doesn't ask you select the specific unspent outputs to spend so it could possibly spend from one of the addresses you are "not supposed" to be associated with.

So let's say merchant sends funds to Alice and Bob, but you're actually both when the merchant thinks you're two different people. If you then accidentally use unspent outputs for Bob when you are supposed to only be Alice (for example, later buying something from that merchant or issuing a refund) -- then the jig is up, the merchant now knows that Alice also has Bob's key(s).


nTime rolling is just an optimization for large/fast pools, correct?

Is this understanding correct?

Basically, but you've failed to account for the small size of the header nonce space (32 bits) and the speed of modern hardware (on the order of 10 terrahashes per second per miner).

A 32 bit nonce can only provide 2 ** 32 = ~4 billion combinations.  That corresponds to 4 gigahashes.  A single modern miner can do more than a thousand times in half a second, so the nonce space is almost always exhausted without finding a block.

When Bitcoin hash rate was first increasing through the FPGA and early ASIC eras, nTime rolling was implemented so that miners didn't have to make significant changes to their hardware and software to deal with the problem of nonce space exhaustion.  However, that hack of a solution was increasingly less useful the faster hardware got, as a typical block can only move time around in a range of about two hours (3,600 one-second increments) and sometimes much less than that (this is especially the case when other miners are using nRollTime as they can use up the acceptable time values available to subsequent miners).

The correct solution was to put an extra nonce in the coinbase field of the generation transaction[1], something that was actually implemented in the original Bitcoin 0.1 software.  Changing any transaction in the block also changes the 256-bit merkle root in the block header, eliminating the risk of nonce space exhaustion.  This technique is now universally used by Bitcoin miners and usually implemented directly in the hardware (I think usually using a small FPGA for the extra nonce updates and merkle root regeneration).

[1] The coinbase field currently allows miners to add up to 96 arbitrary bytes without affecting any protocol features.  The company Coinbase is named after this field but has no other relationship to it.


If there were fewer miners, Bitcoin would be less reliable and you'd have to wait much longer to get the same level of security against a double-spending attack. We need as much mining as possible because mining secures the blockchain.

If I have 10 Bitcoins, I must be able to send them to Jeff. Otherwise, I don't have 10 Bitcoins. If I have 10 Bitcoins, I must be able to set them to Mary. Otherwise, I don't have 10 Bitcoins. But if I could send them to both Jeff and Mary, the system would break. So somehow, sending them to Jeff must prevent me from sending them to Mary too.

Bitcoin does this by having miners pick one of those transactions and heap a massive amount of computations on top of it. Among valid blockchains, Bitcoin prefers the one that likely took the most calculations to do. Miners pile calculations on top of the legitimate block chain to distinguish it from alternate chains. To "undo" a Bitcoin transaction, you must pile more computations on top of it than the rest of the miners combined piled on top of the legitimate chain that includes that transaction. The more mining, the faster you can accumulate sufficient calculations that undoing a transaction is impractical.


What is the limitations in Bitcoin's network that can't be change by a Soft Fork?

Bitcoin.org's developer documentation has a pretty good description of the consensus rules, but it does not and cannot describe them fully. This is because the consensus rules are dictated by the code that enforces them, not by a document. AFAIK, there is no list of things that can be hard forked and things that can be soft forked as such lists would be infinite. A hard fork can do anything; a soft fork can do much less, but with some "tricks", a soft fork can do just about anything too.

In general, a hard fork is a change which makes something that was previously invalid, valid. This would mean things like changing the transaction and block formats, the current scripting system, etc.

In general, a soft fork is a change which makes something that was previously valid, invalid. This would mean things like changing when the OP_NOP (no operation) opcodes are actually no op and not. Soft forks can also add extensions to what currently exists, but not always change what already exists. So a soft fork could add something to the transaction format, but it can't change the current transaction format to something else. Changes like these would be segwit and extension blocks.


As of Feb 2015, what's the most technically secure wallet for Android?

It's a difficult question to answer because an Android rooted device is never going to be secure 100%.

That being said, the safest options will be 2FA enabled wallets at a bare minimum, and multisig solutions being the best bet.

GreenAddress.it allows for wallet functionality on par withBlockchain.info but with increased security through P2Script using ntimelock. It also allows for 2FA: be sure to use TOTP (eg Google Authenticator); do not use the same device for mobile SMS authentication since intercepting sms on a rooted device is extremely simple.

GreenBits is a new app which integrates with GreenAddress and utilises 2FA and P2Script also.

Options like BCI and Mycelium are not ideal for a rooted phone as the security concerns make either choice quite vulnerable to being emptied by malicious software stealing the pin code.


What is the story behind MtGox and their French bank?

The important answer is on https://support.mtgox.com/entries/20568322-all-eur-transactions-will-be-temporarily-suspended-within-europe-with-immediate-effect

quote :

  "While Bitcoin at a European level is so far not directly impacted by
  this decision, the Bank de France (France's central bank) has
  confirmed that because of European banking rules, monetary transfers
  (deposits and withdrawals) through a single entity are subject to
  financial regulation and therefore can only be performed by licensed
  financial institutions such as banks or Payment Service companies (the
  European Equivalent to a Money Service Business). This decision has
  forced us to find other payment processing partners within Europe that
  will allow us to quickly resume all EUR transactions for our European
  customers soon."

To be allowed to accept deposits, keep your funds, and allow withdrawals, mtgox ( and any other European based exchange, like virwox for example ) have to be registered as a Payment Service Company (the European Equivalent to a Money Service Business).
 Since virwox is in Europe, they are probably illegal if they dont have this Payment Service Company license

This is true for any website or company wanting to accept deposits, keep your funds, and allow withdrawals, bitcoin related or not
 This decision is not related with bitcoin, it applies to anyone.

Registering as a Payment Service company takes time and is very expensive.

more details for :
Money Services Business  : http://en.wikipedia.org/wiki/Money_services_business
Payment Service provider : http://en.wikipedia.org/wiki/Payment_service_provider


Is Coinbase.com combining / commingling transactions or funds?

Yes, simply put, Coinbase and some other wallet/merchant services have internal bookkeeping.

So you've deposited 2 BTC. Soon thereafter coinbase will move funds around:

to cover other deposits/withdrawals
to exchange
to put in a hot/cold wallet

Once you've deposited your Bitcoin, just like a bank, you're effectively given an IOU (unless for services like Blockchain.info you own the private keys) and your withdrawal will draw upon either a single or multiple inputs to reimburse you.

The main reason this is done is twofold:

to cut down on Txn fees
because the bitcoin protocol always sends the full input amount (the remainder is sent as change)

By coupling change outputs as credits this allows for internal bookkeeping.

(It's worth noting that the txn fee wasn't paid by you directly. It's just a standard multi input txn)


Bitcoin Core is the name of the software you are referring to, and it is the software that runs Bitcoin. Computers that run Bitcoin Core are usually called nodes on the Bitcoin network. It is open source, and there are hundreds of developers around the world that have and are contributing to it over the last 10+ years.

The software can be run by anyone, and so the wallet that is included with the software must be secured by you. Online exchanges may or may not use Bitcoin Core, but likely have their own wallet implementation. You do not need to run your own node to transact in bitcoin, the wallet software will submit transactions to a node, however.

To create and view a private key for an address in bitcoin core, use:

$ bitcoin-cli getnewaddress
<your new address>

$ bitcoin-cli dumpprivkey <your new address>
<your private key in WIF format>

Encrypting your wallet just makes it so if someone opens your Bitcoin node, they must have your password in order to be able to spend your bitcoin. It is highly recommended to do so. This password is unrelated to the private keys for your bitcoin addresses. The 12 word mnemonics you are referring to is not implemented in Bitcoin Core, and not generally recommended.

Docs for the RPC commands can be found here: https://bitcoincore.org/en/doc/0.18.0/


Error running BITCOIND in Ubuntu 12.04 Desktop

Do you have a file named .bitcoin. in your root directory? If so, delete it with rm /home/sim/.bitcoin and try running the server again.


Can decentralized blockchain technology like bitcoin be used to store medical information?

The blockchain is used for more than just storage of data. To store data, all you need is a harddrive of some sort. What kind of things would you like to be able to do with this 'medical blockchain'?

I think that in general, everything medical would be considered confidential, so even if it could be stored in a blockchain, no one would want to.


Can't get the tx with gettransaction or getrawtransaction methods

gettransaction is a wallet RPC. It only works for transactions your wallet knows about. Presumably this is not the case for a transaction from 2013.

getrawtransaction is a node RPC. It works for all transactions, but needs help to find them. One possibility is to enable the transaction index (put txindex=1 in bitcoin.conf, or -txindex on the bitcoind command line). Another option is specifying which block the transaction is in.


Is there a way to figure out what wallet a transaction came from, because I fave a few??

No, wallets just hold private keys, and the private key is all you need to spend coins sent to a "normal" bitcoin address starting with a 1. From the public view, all that can be seen is the address the coins were sent to, there is no more information about that address such as what wallet generated it or where the private key is held.

  I think the transaction is in limbo

If the transaction was confirmed back in 2013, and it is unspent since then, it won't be in limbo, you just need to find the wallet which holds the private key for the address that transaction was sent to :)

I'm afraid there isn't much else anyone here can do to help you, if you have lost the private key then your bitcoins are lost, so I hope you find them in one of your wallets!


Accurately calculate fees to sweep all coins

It seems there is some discrepancy between your estimatedFee variable and the feerate being used in the fundrawtransaction step.

I think you could try simplifying your code to not use the estimatedFee during the vendorXBalance calculation, and then when calling fundrawtransaction, use the subtractFeeFromOutputs option to just have the fee deducted equally from all specified outputs. For example:

balance = Bitcoin.rpc.getbalance '*', 1, true

vendorABalance = vendorAIncome * 95%
vendorBBalance = vendorBIncome * 95%
vendorCBalance = vendorCIncome * 95%

systemBalance = balance - vendorABalance - vendorBBalance - vendorCBalance

rtx = Bitcoin.rpc.createrawtransaction [], [
  { 'Vendor A wallet' => vendorABalance },
  { 'Vendor B wallet' => vendorBBalance },
  { 'Vendor C wallet' => vendorCBalance },
  { 'System wallet' => systemBalance },
]
Bitcoin.rpc.fundrawtransaction rtx, { includeWatching: true, conf_target: 6, subtractFeeFromOutputs: [vout_index,...] }

# On a offline machine
rtx = bitcoin-cli signrawtransactionwithkey rtx ['private keys']

# Back on the online machine
Bitcoin.rpc.sendrawtransaction rtx

Here is some relevant text from bitcoin-cli help fundrawtransaction (v0.17.0.1):

"subtractFeeFromOutputs" (array, optional) A json array of integers.
     The fee will be equally deducted from the amount of each specified output.
     The outputs are specified by their zero-based index, before any change
     output is added.
     Those recipients will receive less bitcoins than you enter in their
     corresponding amount field.
     If no outputs are specified here, the sender pays the fee.
       [vout_index,...]


Easiest way would be to look at the latest block and see how much is the reward e.g. block 5846 has reward of 3.65385 ZEC
Or you can drectly see current reward here https://explorer.zcha.in/statistics


Should I verify the Bitcoin Core release signing keys?

Is it recommendable/indispensable?

Yes, it is a MUST not just recommendable. There are a number of ways in which an attacker could modify the binary that you download from the bitcoin.org website.

Attacker can compromise the Bitcoin.org website, so any information hosted on that page could be modified by the attacker for its own benefit
Attacker can compromise the SSL/TSL connection by compromising a Certificate Authority and issuing fake website certificates
Attacker can launch a man-in-the-middle attack on people visiting the bitcoin.org website and tricking them into believing that they have landed on the original website

Once the attacker has fooled you into downloading a clone of the Bitcoin software with a malicious bug, it could steal all of your coins, use your machine to launch attacks on the Bitcoin network, crash or wipe your computer clean or might place a worm in your machine that acts as a surveillance tool.

In fact, Bitcoin Core developers issued a warning during the release of v0.13.0 binary (in 2016) as they had suspected that the release could be targeted by the state sponsored attackers.

It is also recommended that you verify the signatures and hashes of the binaries from multiple sources and developer signatures. You can use the gitian signature repository to get other signatures and verify multiple signature data through multiple channels.

  Can I still check the keys once it is up and running?

You could possibly check the binary once its up and running by evaluating the SHA-256 of the binary in the /usr/bin/bitcoind. But there might be a chance that a malicious code separated from the actual binary during its first execution and now is located in some place you might never find without a thorough forensic analysis.

  Will I have to reinstall and download the entire blockchain again?

If you reinstall a new binary and verify it with the signatures, you can just sync it with the network. If the blockchain that you had downloaded from the previous release matches the true version of the Bitcoin blockchain (that is it was not tampered), then you need not download it again.


Why did Bitcoin Core wallet send my coins to this address?

The transaction that shows up as confirmed (8f1fb5fa1) was confirmed almost a year ago in block 345970, although your client is showing it with a recent date. I think you might have not synchronized with the network before attempting to transfer the coins to your new wallet, at which point the client still showed the coins in your balance. You later caught up with the blockchain and your wallet noticed that the coins were no longer available, marking your new transaction as a conflict/doublespend.

If this is indeed the case, then this is perfectly normal. If this were your address then the wallet would notice this automatically and credit you with the coins. It could either be that you migrated your funds at some point to a new wallet or that malware was involved.


Found old 'key' to bitcoin wallet but don't know which wallet?

I think I found a bitcoin private key

So far as I know, a private key is 64 characters long in Hexadecimal (a mix of digits 0-9 and letters A-F only) or 51 characters long in WIF/Base58 (which includes a mix of any uppercase and lowercase letters as well as digits). There's also a mini format that is 22 characters long.

It's 33 letters long

That's likely to be an address. If it starts with a 1 or a 3 then it is almost certainly an address.
You can't recover control over money if you only know an address.
If you are sure you have an address and not a private key, you can safely enter the address into any blockchain explorer to see if there is unspent money at that address.
Obviously you should never enter a possible private key into any website.

from 2013

In late 2013 BIP39 was published - which defined seed-phrases (also called recovery phrases or backup phrases). These consist of a list of 12, 18 or 24 words from a standard list. If you have a set of such words you may be able to use it to recover control.
If I remember correctly, at least one wallet, Electrum, had a different seed-phrase system earlier (maybe a year earlier). So if you find 12 random seeming words, you could try them in Electrum.
Many people startr in Bitcoin without finding out about custodial and non-custodial wallets. If you had an account with a custodial service, you might have old email that might help you recover access to money in and account with some business. However quite a few such businesses are no longer around.


How to monitor balance for addresses other than by using importAddress?

Is there any way, other than importaddress, to watch balances of specific addresses?

No, creating a watch-only address is the way to do this using a wallet such as Bitcoin-core.

  how it is possible for wallets and explorers to give information ... even though importaddress takes some time?

Once the blockchain has been initially scanned for transactions involving an imported address, the wallet need only check new blocks for mentions of that address as it receives the new blocks, there should be no need to rescan the blockchain.

Blockchain explorers can maintain an index per address and continuously keep track of balances for all addresses. They don't need to recompute this from scratch for every new enquiry.


What are the differences (and value adds) among all the different Crypto Currencies?

99% of altcoins claim an "innovation" that is broken or unproven.

I would say that the first thing to do is look at unique codebases that aren't based on Bitcoin, which basically means (besides Bitcoin) you should look at Ethereum, Ripple, NXT, Monero, BitShares. Then if you're bored, PeerCoin / NuBits and Lisk.

Once you are done with those you can look at altcoins that just clone Bitcoin, but if they don't have whitepapers with cryptography that explains what they're doing then they're just full of hot air.


"bitaddress.org": It generates a BTC or BCH address?

1) A Bitcoin address/private key is the same as a Bitcoin Cash address/private key.

2) To prevent confusion, one year ago Bitcoin Cash started to use a new address format called CashAddr. They can be used interchangeably if the wallet/service doesn't support the CashAddr format, using the official address translator or mine. Today, most of the services accept both types of the BCH addresses.

To sum up, Bitaddress is compatible with Bitcoin and Bitcoin Cash, but you should convert it to CashAddr before receiving Bitcoin Cash so that they won't send you bitcoins by mistake. (Both 1 and CashAddr addresses are accepted by BCH services while BTC services don't recognize CashAddr, intentionally)

BTW, there's Bitaddress fork named cashaddress.org that generates CashAddr by default.


What can I expirement with BitcoinCore on my own?

There are lot of things you can learn and try from below link including designing complex bitcoin scripts:
https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line


What provably fair Bitcoin gambling sites work well on a mobile?

Provably fair means the player can prove the operator didn't cheat.  With website-based provably fair systems, the generation of a random number and/or client seed is easily to see and monitor.  Unless a mobile app is open source, this same capability is not available.

So a provably fair website that provides an app doesn't mean the app provides provably fair online gaming as well.   An open source app could be provably fair.

You won't find any of (or at least not many of) these apps on the Google Play store since they are online gambling that is a prohibited app on their service.  But the apps can still be installed from external sources:

Seals With Club poker has a mobile app.
Bitcoin Video Casino has an Android app.


Send and receive money, payment gateway with Golang

There is a Bitcoin client implemented in Go called btcd which you might want to check out. This should allow you to send and receive money, if you read more about it, I'm sure you'll find plenty of examples.


Which peers does a node broadcast a new block to?

All peers are treated equally when relaying chain-extending blocks (as James C. stated in a comment on another answer). The node will announce the block to all of its peers and since that block was just found, all of the peers should request the new block.
Many miners will also announce new blocks on Fast Internet Bitcoin Relay Engine (FIBRE) in addition. Any new block on FIBRE will be immediately broadcast to all participants in a compressed format based on compact blocks (BIP152).


Can AntMiner L3+ mine any scrypt coins or just lite coin

The L3+ is the best option right now (however if you're ordering now, you won't get a new one for some time, and the second hand ones are being resold for huge profits), however this will change as more of them are made/released.

The L3+ is a Scrypt miner, so it could in theory mine any Scrypt based coins, Litecoin being the big one.

Bitmain don't appear to be shipping anything out any time soon, Avalon (http://canaan.io) or Ebit (http://miner.ebang.com.cn) also sell alternative miners, they're not as power efficient as the S9 (and slower), but cheaper, so if you're dipping your feet into the water to test the temperature, it's an alternative.


Error message in cgwatcher with intel hd graphics 4000

You must set the miner path before you can start mining. Click the manage profiles button in the settings tab to open the profile manager, where you can edit the profiles miner path


How can services that use the bitcoin blockchain help secure it?

The Bitcoin network is fairly simple in terms of its core security, so technically there are three things these companies/projects can do to contribute:

Run and/or encourage development of the bitcoind codebase (including code reviews)
Run and/or encourage a higher number of solo miners
Run and/or encourage a higher number of full nodes

Point 3 is especially important and a no-brainer for any project that depends on the blockchain. Running your own full node(s) is a must, so that you don't have to trust a third party node. The tragedy of the commons does not apply to this point.

Each full node adds a layer of security to the network by verifying all transactions and blocks, reducing the chance for foul play, even from "malicious" miners.


Recovering My BitCoin Core Account/Wallet

Access to wallets can be recovered by means of a recovery phrase, private key (string or QR code) or backup file (in this case a copy of wallet.dat).

If you have none of these you will not be able to prove ownership of the wallet and will not have access to the funds.