Bitcoinj always gets 0 balance I am trying to use Bitcoinj for my app.
I am using regtest mode.
I have a balance of 42 BTC on my account:

bitcoin-cli -regtest getbalance mirko3
-> 42.00000000

My code follows:

public class ProvaBitcoinj {
    public static void main(String ... args) throws Exception {
        final DumpedPrivateKey dumpedPrivateKey = new DumpedPrivateKey(RegTestParams.get(), "cNDSqymhJbqmRJRpx3QPM8KBZuca2WePFkzj2uezp5TZhqHX4q4d");
        final ECKey key = dumpedPrivateKey.getKey();
        System.out.println("BTC address that will be added: " + key.toAddress(RegTestParams.get()));
        System.out.println("Private key that will be added: " + key.getPrivateKeyEncoded(RegTestParams.get()));

        final WalletAppKit kit = new WalletAppKit(RegTestParams.get(), new File("/tmp/bitcoinj"), "test_btc") {
            protected void onSetupCompleted() {
                System.out.println("Key chain size: " + wallet().getKeychainSize());
                for (ECKey k : wallet().getKeys()) {
                    wallet().removeKey(k);
                }

                wallet().addKey(key);
            }
        };
        kit.setAutoSave(true);
        kit.connectToLocalHost();
        System.out.println("Started!: " + kit.startAndWait());

        System.out.println("Keys: " + kit.wallet().getKeychainSize());
        System.out.println("BTC Address: " + kit.wallet().getKeys().get(0).toAddress(RegTestParams.get()));
        System.out.println("Private key: " + kit.wallet().getKeys().get(0).getPrivateKeyEncoded(RegTestParams.get()));

        System.out.println("Balance " + kit.wallet().getBalance());

//      kit.wallet().addEventListener(new AbstractWalletEventListener() {
//          @Override
//          public void onCoinsReceived(Wallet wallet, Transaction tx,
//                  BigInteger prevBalance, BigInteger newBalance) {
//              System.out.println("TX!!!!!!!!!!!!!");
//              System.out.println(tx.getValueSentToMe(wallet));
//              System.out.println(wallet.getBalance());
//          }
//      });
//
//      Thread.sleep(Long.MAX_VALUE);
        for (Transaction tx : kit.wallet().getTransactions(true)) {
            System.out.println(tx.getValueSentFromMe(kit.wallet()));
        }
        System.out.println("Stopping");
        System.out.println("Stopped!: " + kit.stopAndWait());
    }
}

This programs dumps the following output:

BTC address that will be added: mnJRedAFBzRScnnKp5eS5CgR165uGi75tm
Private key that will be added: cSY1oeXfTADVXg2WnMzR2uMqQWqXNNia424SF2mHRPr54Ruj9Fzs
Key chain size: 1
Started!: RUNNING
Keys: 1
BTC Address: mnJRedAFBzRScnnKp5eS5CgR165uGi75tm
Private key: cSY1oeXfTADVXg2WnMzR2uMqQWqXNNia424SF2mHRPr54Ruj9Fzs
Balance 0
Stopping
Stopped!: TERMINATED

I have verified that the key pair is correct:

bitcoin-cli -regtest getaccountaddress mirko3
-> mnJRedAFBzRScnnKp5eS5CgR165uGi75tm
bitcoin-cli -regtest dumpprivkey mnJRedAFBzRScnnKp5eS5CgR165uGi75tm
-> cSY1oeXfTADVXg2WnMzR2uMqQWqXNNia424SF2mHRPr54Ruj9Fzs

I have also noticed that if I run the commented out code and send some money using bitcoin-cli, I receive correctly events and the wallet is charged with the amount I have sent. At a certain point, I could see my wallet with 2 BTC, but the other 40 ones were never found and, anyway, after some tests also the 2 BTC have disappeared.

I am totally confused, any help would be greatly appreciated.

Thank you

Okay, so it's been a while since I've played around with BitcoinJ but the problem might be that you need to rebuild your BlockStore file. A BitcoinJ application is essentially made up of four main objects, a BlockChain object which is responsible for parsing and validating the actual blocks, a BlockStore object which is responsible for saving this data, a PeerGroup object responsible for actually getting this information from the bitcoin network (in the case of your regtest example it simply connects to your localhost bitcoind node), and a Wallet object that actually holds that data about the public/private keys you are interested in.

You are using WalletAppKit which is a boilerplate class BitcoinJ offers to bootstrap all of this for you. It creates a BlockChain object and relates it to an SPVBlockStore object that is related to a PeerGroup object which is itself related to a Wallet object. If you look at your /tmp/bitcoinj location I believe there should be two files, one a wallet file for saving the information about your addresses and the other a spv file that has a bunch of information saved about the blockchain. The SPV method that BitcoinJ uses doesn't actually download and verify the entire blockchain, it uses a more streamlined system (which you can read about here: https://en.bitcoin.it/wiki/Thin_Client_Security#Simplified_Payment_Verification_.28SPV.29). The SPV file doesn't hold any information about transactions, and if you want to get any information about an address from a previous point in time you have to rebuild this file and effectively force BitcoinJ to reparse the blockchain.

You should try deleting this /tmp/bitcoinj.spv file (I believe that the naming convention of BitcoinJ for WalletAppKit is two files with the path you specified with different file extensions but you might need to verify) and allow it to be rebuilt knowing that it should look for all activity on those watched addresses. Then you'll want to save that wallet to disk so that you don't need to reconstruct the SPV file again.


Transferring bitcoins out of an old multibit wallet A few years ago I bought bitcoins and I've kept it in a Multibit 0.5.15 (Mac OSX) wallet. Now I want to either sell thes bitcoins or send it to a different wallet. I already made a transfer but since I can't manually specify a higher fee in this old Multibit app my transfer stays on pending/unconfirmed.

My question is, how do I transfer this money? Is there any way to export either my wallet or transfer my money to another wallet?

Also I have no idea what to do with this pending transaction. I see no way to cancel it in Multibit 0.5.15.

Any help appreciated!

Pywallet I believe can sort all your problems out. Will let u import the wallet addresses and should let u send the btc again to invalidate the original transaction.

You can either export the private keys from the old Mac wallet and import them into a new wallet. Note once u have exported the private keys u should consider the address compromised and not leave any btc in it


How to use python rpc bitcoin to get the historical transaction record of a wallet address How to use python rpc bitcoin to get the historical transaction record of a wallet address？My computer has synchronized all btc blocks, and txindex=1 has been configured. I want to try to get all the historical transaction records of a wallet address. Do I still need to create a mysql or redis cache? Below is my configuration
datadir=/opt/bitcoin/bitcoin-data
dbcache=10240
txindex=1
rpcuser=*****hi
rpcpassword=****
daemon=1
server=1
rest=1
rpcbind=0.0.0.0:8332
rpcallowip=0.0.0.0/0
deprecatedrpc=accounts

I just want to input an address and connect to the local BITCOIN RPC to query all historical transaction records of a specific address
An empty message was returned
root@ubuntu:~# bitcoin-cli listtransactions  "3Fr1mGhnPAQ9YDf1dzg4B47PkX5TuvFtYv"
[
]

To communicate with your bitcoin core, you must change your bitcoin.conf and set
server=1
Then connect to your bitcoin core with "http://user:password@127.0.0.1:8332"


Selling btc but avoiding bank payment reversals If you sell some btc using a no-kyc p2p exchange, how do you avoid bank transfer payment reversals?

One of the best things about btc is that no one can reverse bitcoin transactions (unless some sort of smart contract is used I guess), however payment reversals are a problem with bank wire transfers.

Suggestions?

Note: Cash in person is not an option in this scenario.

however payment reversals are a problem with bank wire transfers.

"Different wire transfer systems and operators provide a variety of options relative to the immediacy and finality of settlement and the cost, value, and volume of transactions. Central bank wire transfer systems, such as the Federal Reserve's FedWire system in the United States, are more likely to be real-time gross settlement (RTGS) systems. RTGS systems provide the quickest availability of funds because they provide immediate "real-time" and final "irrevocable" settlement by posting the gross (complete) entry against electronic accounts of the wire transfer system operator."

Source: https://en.wikipedia.org/wiki/Wire_transfer

So you are probably not referring to a FedWire or SWIFT wire transfer (which are not reversible) but instead to something like ACH (U.S.), or other domestic national bank transfer method.  When a seller's advertisement specifies "wire transfer", the seller is not referring to these non-RTGS electronic funds transfer networks.

One property of most P2P Trading exchanges is that they provide a trust history/reputation of your counterparty.  While that doesn't guarantee that you won't be defrauded from a reversed payment, it is a tool in which you can use to significantly reduce the risk of fraud by not accepting a reversible payment method unless the counterparty has a great trust history.

One approach to lessen risk is to do several, smaller trades with multiple counterparties rather than a single large trade with one counterparty.

Additionally, having the buyer deposit cash into your account is a method with less risk (but not zero risk).

Otherwise, local, in-person cash trading is a safer method.


What is the new segwit network option on binance and how does it work? Recently Binance announced support for segwit deposits. I see old address and lot of other options on the right with segwit in the end. Is it a new network? What are the other options mentioned on Binance to deposit BTC and are they similar to segwit?

On 2020-12-24, Binance announced support for deposits to native segwit addresses.
Segregated witness ("segwit") refers to a soft fork that activated a series of Bitcoin improvement proposals (BIPs) in 2017. Among other things, segwit introduced two new standard output types, Pay to Witness Public Key Hash (P2WPKH) and Pay to Witness Script Hash (P2WSH). These native segwit outputs are more blockweight efficient than prior equivalent output formats, but wallets had to be updated to create them.
After three years, receiving payments to native segwit addresses is considered best practice, and almost all wallets and services are able to send to native segwit addresses.


I sent bitcoin address to user and he sent payment, I haven't recieved payment after 24hours? I sent bitcoin address to the user and he sent payment, I haven't received payment after 24hours ?

My transactions have been confirmed 120+ times. Here is a link to my transaction:

https://blockchair.com/bitcoin/transaction/36d073503d15b22d3877ded86798e50d819ea4f01307cd155806006bab8c7065#i=0

https://explorer.bitcoin.com/btc/tx/36d073503d15b22d3877ded86798e50d819ea4f01307cd155806006bab8c7065

I would like to know if there's a way to recover it back, or at least explain to me why this has happened and how to prevent it later on.

My transactions have been confirmed 120+ times

That transaction has been completed and the money received.

Your wallet might not know the money has been received but that is irrelevant so far as the Bitcoin network is concerned.

That transaction sent money to two addresses 1AP3T8gcHiUDdaPYQuBLbRL6Zqg8CF5GGz and 16z1nWRJDcbgDzyQFY62Q37gGHG2duWvKS. One is the payment and the other is change returned to the sender.

If either of these addresses are the address you gave the other person, it means you have received payment. I would check your wallet is fully synchronised and working properly. I would double check that the wallet knows of the address.

If none of these addresses are the address you gave the other person, it means this transaction is irrelevant and/or the other person made a mistake, or is not telling the truth.

  I would like to know if there's a way to recover it back

As I expect you know, Bitcoin transactions are irreversible. There is no way to cancel, undo or reverse a Bitcoin transaction with more than 120 confirmations.


Confidential Transactions on main chain I have seen discussion of CT being used on the a side chain. What are the chances it will be applied to Bitcoin Core itself?

Pretty good actually as it has become a lot easier after SegWit allowed for new script opcodes through soft forks. It might still be a few years out, as there are other priorities, but Gregory Maxwell is pretty active on CT.


Do I have to pay tax if I buy bitcoins with my USD? Theoretical question:

If I make $1000, which gets deposited into my bank account, and then I deposit that $1000 into a bitcoin wallet the next day, and just sit on it for one tax year, do I have to pay income tax on that $1000? Can the gov't track me down and get me to pay tax?

Thanks.

According to the guidelines currently provided by the IRS, you are only required to pay taxes if you sell those bitcoin and have made a profit on them. If you are holding, or made nothing, or lost money, you are not required to pay taxes on them. If you lost money, you may claim those losses when you file your taxes, if you wish. It is not practical for the IRS to track the bitcoin of every US citizen who owns some, and becoming increasingly difficult to do so, given the continuing advancement in bitcoin privacy enhancements. It is one of those categories where the IRS relies mostly on self-reporting. However, if you have been moving a ton of bitcoin and not paying taxes on it, then you get audited, this is something that could come up in a detailed investigation into your finances.


Blockchain length by number of blocks or transactions? It is my understanding that the longest blockchain is the one that should be used.

Is "longest" measured by the number of blocks or the number of transactions?

The longest blockchain is measured by the number of blocks, not the number of transactions. This is because the proof-of-work is linked to the creation of blocks, not transactions.


why OP_CHECKMULTISIG signatures must be placed in the signature script using the same order In https://bitcoin.org/en/developer-reference#term-op-checkmultisig

  Because public keys are not checked again if they fail any signature comparison, signatures must be placed in the signature script using the same order as their corresponding public keys were placed in the pubkey script or redeem script. See the OP_CHECKMULTISIG warning below for more details.

I wan't to Know, why public keys are not checked again? security or other？

Performance.

If you have an m of n multisig scheme, ordering the keys and the signatures  ensures that a minimum of m and a maximum of n signatures will be verified.

If we didn't use this approach the number of signatures to be verified could be as high as  n! / (n-m)! ( this is the worst case scenario).

Keep in mind that, in terms of resources, it is trivial for a transacting node to order the signatures, but it is not trivial for a verifying node to validate 500k transactions per day. We need to use the resources of a verifying node as efficiently as possible.


Why the same confirmed transaction in the Testnet has different block hash and other fields? Chain.com
http://explorer.chain.com/transactions/a4bfb8e21ae3d6232183dfb8ef5fcee8c9b8f223c2d25738e24765a75abd009b

Chain.so
https://chain.so/tx/BTCTEST/a4bfb8e21ae3d6232183dfb8ef5fcee8c9b8f223c2d25738e24765a75abd009b

hash of the transaction
a4bfb8e21ae3d6232183dfb8ef5fcee8c9b8f223c2d25738e24765a75abd009b

That's pretty common. What happens is that the chain forks for whatever reason and some miners are on each side of the fork. They will both have your transaction in their transaction pool and so eventually include it in a block. So your transaction ends up on each fork.

Ultimately it doesn't matter though as the network will eventually agree on which fork is correct.

Note that recently, testnet has been pretty unmanageable, with regular difficulty resets creating situations where 100s of blocks get created per minute. This creates a lot of chain forks and some can be really long, like in your case. Also due to the high number of forks, some nodes may not have learned about a given block/fork at all if it ended up "losing".

On the mainnet, forks are somewhat infrequent (couple daily) and much shorter (very rarerly more than a block).


Securely encrypting a cold storage wallet I'm going to buy bitcoin to exchange BRL to CAD currency, as it's gonna be a great amount I'm concerned about the security of my wallet. I don't want to use a physical backup like paper or device because I don't trust myself to not lose or burn anything.

By my study so far the best option is to generate a wallet in an offline and secure device and to encrypt the private key before to do a backup.

Does someone suggest me an App or strategy to do this?

Portuguese version
Eu tenho uma dúvida! Pretendo comprar bitcoins como forma de transferência para o exterior, como é uma grande quantidade estou preocupado com a segurança da minha wallet. Não pretendo fazer um backup em papel ou num dispositivo físico pq não confio muito em mim mesmo pra não perder ou queimar alguma coisa.

Pelo que estudei até então a melhor opção é gerar uma carteira num dispositivo seguro e offline e criptografar a chave privada antes de fazer um backup. Alguém me sugere algum App, ou bons jeitos de fazer isso?

Even if you seem worried about losing your coins, the safest way to store bitcoins is probably to acquire a hardware wallet. To mitigate the risk, you should store several copies of your wallet seed words in different locations. This is a form of backup that allows you to regenerate your wallet on another hardware wallet if you lose the first. It is highly recommended that you store the backups in a way that they are not easily accessible to other people that may use the backup to steal your coins.

If you're going to invest significantly more than $1,000, the one-time cost of acquiring a hardware wallet at ~$100 seems a reasonable investment to me.


What should I do if my friend runs a Bitcoin business but doesn't understand how it works? My friend doesn't listen to his head of engineering and doesn't fully understand how decentralized consensus based systems like Bitcoin really work. He seems to think a new untested/buggy implementation with conflicting consensus rules can be made to work with the existing implementations that follow existing consensus rules.

What advice can I give to him?

He should listen to his engineer. I think that's just about it.


Possibility of contructing a valid transaction without knowning private key From here you get that in step 2 of ECDSA sign process, you use
z, the Ln  leftmost bits of e = HASH(message/transaction) in both the process of generating and verifing the signature.

I understand that in bitcoin transactions signature and verification you do almost the same algorithm.

So...

You know that adress A has a transaction x to it that values in 1 BTC not spent.

You know also a transaction y1 from A with a certain signature and a certain value z1, as the algorithm in the link says.

Could you create a transaction y2 so that it sends the 1 BTC from A to adress B by creating it in a way that it had the same z1 (mentioned above) and consequently the same signature of y1? (since signature depends only on message (z), private key and the random value k)

This transaction y2 would be valid?

Yes, but that is hard. This is known as a collision, and you would be finding a collision in SHA256. Because you would be reusing a known hash, what you would be doing is performing a preimage attack. Since SHA256 has no known preimage attack for all 64 rounds done in a normal SHA256 hash, you would need to do 2^256 hashes in order to be guaranteed to have found a colliding preimage for that hash.

This is why a cryptographically secure hash is used for signing operations.


Why does re-signing a message in bitcoin-qt produce a different hash I just noticed that if you repeatedly sign the same message in bitcoin-qt, the signature changes.

Why is this?

Bitcoin uses ECDSA to sign messages. With ECDSA, signing requires as input the private key, the message, and also a random number k. Signing two different messages with the same k allows anyone with both signatures to easily recover your ECDSA private key. So every time you sign something with Bitcoin, a new k is generated, and this makes the signatures different. (The range of k is extremely large, so the chance of accidentally reusing a k when you generate one randomly is too small to seriously consider.)

Some elliptic-curve crypto algorithms specify that k be a hash of the message. This ensures that k is always distinct per message, making it more difficult to screw up when implementing the algorithm. With an algorithm that behaves like this, signing the same message with the same key would always get you the same signature. However, this is not standard for ECDSA, so Bitcoin doesn't do this currently.


What is the best way to prevent replay attacks in the event of a bitcoin hard fork? I originally thought it would be relatively simple to add replay attack protection (change something about how the tx hash is generated) in the event of a fork. But the BU folks mentioned that this would break SPV clients (including many mobile wallets). So it is not free to do that way, although still an option.

One solution we brainstormed, was using some coins that were only valid on one chain (for example newly mined coins) and adding 1 satoshi of "taint" to all generated transactions. This would work but is not perfect. For instance, newly mined coins can't be spent for 100 blocks, so at a minimum it would cause economic nodes to have a delay in the event of a hard fork. It is also non-trivial for all wallet software to implement this (fair amount of work, especially at scale). There is also an operational challenge that you would have to rush to get these newly mined coins while the hard fork was happening, so you could not prepare in advance. It would be a messy for sure.

Another option would be to try and double spend some coins across the forked chains (get a transaction with some coins going to two different addresses mined across the two chains). These coins could then also be used for "taint", but you wouldn't have to wait the full 100 blocks. This is a little bit better, but still not perfect.

I suspect there is a better solution though. What are people's thoughts?

One solution we brainstormed, was using some coins that were only valid on one chain (for example newly mined coins) and adding 1 satoshi of "taint" to all generated transactions. This would work but is not perfect.

It so sounds like you have two problems:

How to get some inputs that are only valid on one side of the chain.
How to mix these inputs in with all of your transactions.

I don't have any good answers for the second question; you'll have to mix in the inputs by either putting them in every transaction you send or by mixing them with a large amount of coins which you then split into dozens or hundreds of inputs that you'll use normally.

For the first question:

Coin splitting

The best way would be to push for replay protection in the hard forking client(s) as they're already changing the rules.  But if that's not possible, there are some potential differences between chains that can be used to get one version of a transaction confirmed on one chain and another version of the same transaction confirmed on the other chain.

I'll warn that (1) Bitcoin clients are not designed to operate under ongoing hard forks, so lots of things that would normally work just fine can end up resulting in monetary loss, (2) without replay attack protection, there's no guarantee that any of the mechanisms below will split your coins---so you should probably send the coins from yourself to yourself so that, if the split fails, you still have all your coins (minus any transaction fees), and (3) in a hard fork, any rule can be changed, so the following generic information may not apply on the hard-forked chain; check with the hard fork developers to be sure.

Methods:

Coinbase transactions: not the kind your company makes, but the kind miners use to claim subsidy and transaction fees.  As your question indicates, these are only valid on the side of the hard fork they're generated on but they also have to wait 100 blocks to mature.

Pros: simple, guaranteed to work

Cons: requires miner help, have to wait 100 blocks
nLockTime: if the two chains diverge in height, you can create a transaction with the nLockTime set to the height of longest chain.  That transaction can be immediately confirmed on that chain, but it can't be added to the shorter chain until that chain catches up to the same height---giving you a window of time into which to broadcast an alternative transaction on the shorter chain and split your coins.

Handily, Bitcoin Core has a feature called anti-fee sniping that automatically (in current versions) sets the nLockTime to the current block height for default wallet transactions, so this trick is pretty easy if you just want to split your Bitcoin Core wallet.

Pros: should be pretty effective because it depends on consensus rules

Cons: you still need to wait a few blocks after the fork to give the chains time to diverge in chain height.

(Credit: I first heard of a method like this from Peter Todd; I don't know if he originated it, nor if this is exactly the method he was thinking about---I had to guess at how it would work from him just saying "use nLockTime".)

You can also do the same thing with consensus-enforced nSequence, but it doesn't get you anything extra.
Fee differences: It's possible miners on one side of the fork may be mining transactions with lower fees than on the other side, so you can broadcast a low-fee version of your transaction on the low-fee chain, wait for it to confirm, and then broadcast a higher-fee version on the high-fee chain.

Pros: simple

Cons: you may still have to wait a few blocks for fees to diverge by much and since each miner has their own policy, you may need to try multiple times.  Also, many wallets don't let you chose arbitrary fees (they just give you a reasonable fee or let you choose from reasonable range of fees).

(Credit: I first heard this described today by @ElectrumWallet on Twitter.)
Find some other feature that diverges between miners on the two chains.  For example, as I write this, I think Bitcoin Core by default will not accept into its memory pool any transactions that require mining more than 20 ancestors first (this prevents abuse and allows the mining code to run more efficiently, since Bitcoin Core provides child-pays-for-parent (CPFP) mining); Bitcoin Unlimited, being based on an older version of Bitcoin Core, doesn't provide the CPFP optimization and so will allow an unlimited depth of transaction ancestors to enter the mempool.  This means you could get, say, 101 related transactions mined on one side of the fork and then you'd have up to five block to get a different 101st transaction mined on the other side of the fork.

There are potentially other of these relay-level differences between clients that could be used.

Pros: relay differences could possibly be used immediately after a hard fork to get a transaction mined in the first fork block (if you knew when that was going to happen) or the second fork block (if you started as soon as the first fork block was produced).  Also, they may be fairly simple.

Cons: these tricks depend on all miners on one side of the chain running one version of the code and all miners on the other side running a different version of the code.  The more overlap there is, the lower the probability these tricks will work.


Unconfirmed transaction, cannot see money in receiving account I sent 0.6 bitcoin from my coinbase account to my blockchain account. The money doesn't show up in my blockchain account and shows as pending on my coinbase account with 0 confirmations. It has been about 2.5 hours. I'm a little worried because blockchain changes the wallet id for each transaction, and I never requested the money but just scanned the QR code from my iphone. Am I just being paranoid?

Miners fee was 0.00115, or about $5

What happens if it never gets confirmed or that address is no longer valid?

Barring chain reorganizations, valid transactions are binary: either they are confirmed, then your money has been signed over to the recipient, or they are yet unconfirmed and your funds are still unspent.

A transaction can remain valid but unconfirmed indefinitely, if the miners never chose it for block inclusion.
Most wallets have a mechanism to forget unconfirmed transactions in order to be able to spend the funds elsewhere. When any of the funds used for the original transaction are used, the original transaction ceases to be valid.

Addresses do not become invalid after some time, and generally services keep records to associate addresses with the corresponding users even if an address didn't get used for a long time after it was generated.

For more general information on how to deal with unconfirmed transactions, please see: Why is my transaction not getting confirmed and what can I do about it?


Tracking transactions as a Receiver I have a question concerning the transaction of bitcoins. If, for example, I send some BTC to a specific address, does the receiver have any chance in verifying that I have already sent the BTC, before they are being registered in his wallet? I know there is http://blockexplorer.com/, where I can look the transactions up. But is there any functionality for it in the Bitcoin-Client, which I could use in RPC-Calls?

Use case for this: Assume there is an application that uses Bitcoin via RPC-Calls to the Client. I want to buy something via the application and the seller should be able to see that I paid the correct amount of BTC without having to wait for the transaction to be finally redeemed in his client.

Thanks in advance!

The client will often know about received transactions seconds after they have been sent. Transactions that have not gotten into a block yet are said to have 0 confirmations. You can see them by adjusting the parameters of listreceivedbyaddress, etc. so that they show 0-confirmation transactions.


Sent BTC from Coinbase, blockchain explorer says Confirmed. Is recipient lying or could something else be the issue? Sent BTC (approx $500) from Coinbase,  Blockchain explorer says Confirmed. Is recipient lying they have not received or could something else be the issue such as his wallet?
Recipient says it could be because his 'hard' wallet is set up in a way so it activates/acknowledges/receives with $1000 transaction minimum?
He is meant to send back a larger payment to my wallet ( from which i sent the payment) as part of some investment returns. Don't want to think i'm being scammed so giving the benefit of the doubt and seeing what the community answers with.

https://www.blockchain.com/btc/tx/8fc6a9b6a4678efa77d07c959652e2cd7a5c2a7a00b948766d6bcd551bcffec4

Is recipient lying they have not received or could something else be the issue such as his wallet?

Seems likely in this case.

  Recipient says it could be because his 'hard' wallet is set up in a way so it activates/acknowledges/receives with $1000 transaction minimum?

This is not a thing, you're almost certainly being scammed. Wallets don't require activation or acknowledgement to receive coins. If you sent coins, and the tx is confirmed, the wallet has received it.

  He is meant to send back a larger payment to my wallet ( from which i sent the payment) as part of some investment returns.

This is 100% a scam - Do not send this person any more money and cut your losses now.


I have lost my blockchain password and recovery phrase, how can I recover my wallet? I forgot my blockchain password and recovery phrase because it was saved in my phone— and i have lost my phone.
please help me if there are any chances for recover my funds that was in blockchain

Please note, you are probably refering to the blockchain.info wallet service. Not the blockchain itself.

I don't think it is possible to recover your funds if you lost your password and your recovery phrase.
You should have secured your recovery phrase somewhere where it can't get lost or destroyed. A phone isn't a good place for that.

Read here more for detail: https://blog.blockchain.com/2016/04/20/support-team-tips-why-your-wallet-recovery-phrase-is-so-important/

Next time, write it down on paper or store it encrypted on a cloud service where nobody other than you can access it.

You can try and contact support on blockchain.info, but I don't think they can help you as your private keys will probably be encrypted with your password and can be recovered with you recovery phrase. But as you don't have any of them, I think recovery of your funds is not possible.

For more on this, read here: https://support.blockchain.com/hc/en-us/articles/211205343-I-forgot-my-password-What-can-you-do-to-help-

It may be a bit salty, but learn how to deal with security and secure your passwords, use 2FA and save your recovery phrases and anything else in a secure place. This should be done for everything, not only the blockchain.info service.

COMMENT: Yes you can recover your funds without the password and wallet ID.
You can do that by requesting your wallet ID as a first step using your e-mail at this link https://login.blockchain.com/#/reminder, second step is to download the wallet.aes.json file and then its possible to brute force the password. A possible script for doing that can be found here: https://bitcoin.stackexchange.com/a/3037/46677


I've been asked to share wallet credentials to participate in mining. Is that a scam? Good day Everyone!!,

  I've been approached by at least two people on one of my social media accounts and they were claiming that they would be able to increase my bitcoin by linking my wallet to their miner.

Now what I was curious about is whether this was a scam and if not was there a way of keeping myself secure in the process????

The process from what I was being sold is as follows:

Open a blockchain wallet.
Send them the details of the wallet (user and password)
Change the password to whatever
Start earning after depositing a certain bare minimum amount (lets say 0.004)
I should theoretically start earning...

Its an obvious attempt of a scam. Don't ever do that. What the scammers will do is as follows:
they will make a copy of your key, then you will lock them out to access your key. It won't help because they would have already made a copy.

Changing your password prevents anyone from using that password to access your wallet and keys. It doesn't prevent anyone who already knows your secrets from just creating another wallet with the same secrets.


Double Spend Behavior on First Network Propagation Supposing there is a double spend, call the transactions T1 and T2. If someone propagated both transactions within a short space of time to the network, of course only one of them can make it into the next mined block. Do we know anything about the probabilities of which of T1 and T2 will make it, or is it 50/50? Obviously from block 2 onward the longest chain is most likely to remain. But for the very next block, do we know anything?

Bitcoin is a gossip network and relays transaction or blocks on a best effort basis. Hence you cannot determine the probability of one transaction being seen by the network versus the other.

Now in terms of mining the transactions in a block there are a couple of cases that needs to be considered. For assumption sake let us assume that we are considering a miner's node that first receives T1 and then after a few seconds receives T2.

Default case: Most miners still manage their mempool on a first seen basis. That means if a miner sees T1 first, it might reject T2 even if the fees provided by T2 are higher than that of T1.
Replace by Fee (RBF) is signaled: If T1 had opt-in RBF signaled (nSequence in any one its input is less than 0xFFFFFFFE) then the miner may replace T1 with T2 from its mempool.

Now the only remaining conflict can be if there are two blocks mined at the same time and at the same height, one containing T1 and the other containing T2. The chain version on which the next block gets mined will finally determine which transaction will attain practical finality.


Create a transaction from a wallet coins (UTXOs) with the bcoin library I have a multisig setup where the signing is done through external HSM's.
I am using Bcoin and its wallet to receive funds.
What I am trying to do is to create a transaction and sign it with the HSMs.
There are 2 approaches:

Manually create the transaction using MTX.
Use the wallet to create the transaction.

Method #1 solves my problem. The code is even shown here.
However, this method has a big drawback. It requires that I create the Coins. That means, I need to manually create the VOuts and VIns. Meaning that I need to get my UTXO set and choose the ones I need for the transaction. This is very tedious and error prone.

Method #2 solves this issue. When using the wallet, createTx() will create the transaction for you, choosing the VOuts and VIns from the UTXO set for that wallet. However, the problem with this approach is that createTX() signs the transaction. I do not want this as the signing needs to be done by other sources.

So, is there a way for me to get the raw transaction from a wallet without it signing?
MTX has the method toRaw() which gives the raw transaction. Is there any way I can get the wallet to create the transaction, or at least create the VOut/Vin sets?

Thank you.

createTX() doesn't sign the transaction. That is performed by sign() in wallet.js. If your private keys are offline anyway, what kind of unexpected behavior are you getting from createTX()? It wouldn't be able to sign without the keys...?

New functionality was also recently merged to return the MTX before the input scripts are templated (when the public keys are serialized and added to the witness): https://github.com/bcoin-org/bcoin/pull/557 I'm not sure if this helps out your use-case though.

You also might be interested in our own multisig wallet, bmultisig: https://github.com/bcoin-org/bmultisig

This application "plugs in" to the standard bcoin wallet (and full node) and offers hardware support like signing transactions from a Ledger device. Each counterparty of course can sign with their own hardware device at their own convenience.


what is best way to start bitcoin exchange @India we are bunch of Full stack developer whom wants to start bitcoin trading platform @india
- with very low cost
- easy process
- easy to use
- Top most security
- super fast

tech we will use for creating platform
- nodejs
- mondodb
- vuejs

In a nutshell:

If I were setting up an exchange, I would look for a back-end that already exists, with a front-end that I could "white label".

Firstly, I am a developer that works with Bitshares, so my advice can be considered tainted. In my position, I know the code. I do not necessarily know the business. So take everything I say and place it in context.

Secondly, I know very little about the intricacies of laws in India, and I never encourage illegal activity. So make sure you what you do is legal within your jurisdiction.

Now, on with the show...

Bitshares: The Code

Bitshares-core is an open-source (MIT licensed) blockchain project that is based on DPoS (Distributed Proof of Stake).

Bitshares: The Network

Scattered around the world are "Witnesses". They take care of making sure the transactions coming through are legitimate. Think of them as "miners" in the Bitcoin world.

Where you may fit in:

What some have done is provide a "front-end" to the Bitshares blockchain. They provide the customer service, the wallet, the website, etc. Bitshares takes care of the network pieces.

I would strongly consider building it with Bitshares as the back-end. It provides "stablecoins" that allow fiat-like balances to sit there without exposing it to the volatility of crypto currency. It provides a trading platform with some existing trading pairs, and you can create your own. There are open-source front-ends that you can "white label"


Sending RPC-JSON Commands to Bitcoin Peers Is it possible to send some commands to Bitcoin Peers? for example decoderawtransaction command?

The RPC interface of most nodes is password protected, so you can't send RPC commands to an arbitrary peer on the network. If you run your own node though, you can set it up with a password and the the RPC protocol to issue commands.


How does bitcoin core save raw transaction data? I had a few questions. I've looked extensively online and can't seem to get answers right on point.

I just started a full node using bitcoin core and it is currently syncing/validating the past blockchain and catching up. I understand that the default setting in bitcoin core is that non-wallet transaction data is not stored on your harddrive in the blockchain data. My questions are then:

Is transaction specific data (ie: bitcoin address, time, inputs/outpus, etc...) stored in any of my raw data (eg: blk.dat file)?
How does my node verify/validate the past blocks without knowing the transactions from that block? I'm assuming other nodes don't store the transaction data so how is it that my node obtains the transactions to do a full validation of the particular block?
If the transactions are not stored on my computer, how do I have a full copy of the blockchain? I thought this was one of the points of running a node - you have a full backup of the entire blockchain. How could I reproduce the entire blockchain (if needed) without having the transaction data within each block?
If transaction are not stored, what exactly is stored in the block data and how is that useful? Is there a way to decode or use a mechanism to obtain the transaction information from the raw block data files?
If transaction data is not stored in the block data of your computer (ie: txindex=0), how can you reproduce all the transactions if needed without having to download anything or connect to intenet to get it from other nodes if say you were the last node with a copy of the blockchain (eg: in case of an emergency if say, theoretically, all blockchains were somehow deleted and mine was the only one left)?
Do I need to enable txindex=1 to have raw transaction data stored on my node? Or is it stored and accessible if needed without this enabled?

would really appreciate your help!!

I understand that the default setting in bitcoin core is that non-wallet transaction data is not stored on your harddrive in the blockchain data

Actually the default is that it is stored, in the blk.dat files. There is another database for unspent outputs, in the chainstate folder. Your wallet will also index transactions for which you have imported the keys to either spend, or just watch.

  Is transaction specific data (ie: bitcoin address, time, inputs/outpus, etc...) stored in any of my raw data (eg: blk.dat file)?

Yes. Except that addresses are not stored, as addresses are an external format for specific types of scriptPubkeys, and timestamps are only in blocks, not transactions.

  How does my node verify/validate the past blocks without knowing the transactions from that block? I'm assuming other nodes don't store the transaction data so how is it that my node obtains the transactions to do a full validation of the particular block?

It does know the transactions from that block because it downloads the blocks from other nodes. The blocks contain the transactions.

  If the transactions are not stored on my computer, how do I have a full copy of the blockchain? I thought this was one of the points of running a node - you have a full backup of the entire blockchain. How could I reproduce the entire blockchain (if needed) without having the transaction data within each block?

They are, see above

  If transaction are not stored, what exactly is stored in the block data and how is that useful? Is there a way to decode or use a mechanism to obtain the transaction information from the raw block data files?

They are, see above. You can get the information with RPC commands using the cli such as:

$ bitcoin-cli getblock
$ bitcoin-cli getrawtransaction <tx-id>

  If transaction data is not stored in the block data of your computer (ie: txindex=0), how can you reproduce all the transactions if needed without having to download anything or connect to intenet to get it from other nodes if say you were the last node with a copy of the blockchain (eg: in case of an emergency if say, theoretically, all blockchains were somehow deleted and mine was the only one left)?

txindex=0 does not mean that the transaction data is not stored, it only means that it is not indexed. This means you can only get raw transactions by txid using the getrawtransaction command for transactions in the mempool, see getrawtransactions

  Do I need to enable txindex=1 to have raw transaction data stored on my node? Or is it stored and accessible if needed without this enabled?

Only to index the transactions, see above


Sending funds from a Segwit address to a non segwit I just generated a Electrum wallet with the Segwit option on. I wonder what happens if I try to transfer SegWit -> Non-SegWit or Non-SegWit -> SegWit: Will the funds be confirmed and get transfered or will it be lost forever?

what happens if I try to transfer SegWit -> Non-SegWit or Non-SegWit -> SegWit

As long as you are using software that supports doing so, this is perfectly possible and fine to do.

  Will the funds be confirmed and get transfered or will it be lost forever?

Bitcoin can never be lost forever because of an unconfirmed transaction. For an unconfirmed transaction, the bitcoin do not move from their starting address until they are confirmed in a block. Eventually a transaction may be confirmed, or the network's nodes will remove the old unconfirmed transaction from their mempool's, and you will be able to spend the coins again. There are a few of ways to push unconfirmed transactions through, like replace-by-fee (RBF) or child-pays-for-parent (CPFP).


Mini private key, PBKDF2 rounding There are two formats of mini private keys, one is based on SHA-256, other on PBKDF2. In the instructions for decoding the second one, we read:

"The iteration count is determined as follows: 2 ^ (n/4) rounded to the nearest integer, where n is the second byte."

Does the rounding refer to the value of (n/4), or 2 ^ (n/4)? For example, for n=9, we have:

n/4=9/4=2.25
2^(n/4)=2^(9/4)=4.75682846

If we round the result of the second equation, we get 5, but if we round the result of the first equation, we get:

2^2=4

Which is a bit of an inconsistency.

Where should one apply rounding for calculating the proper PBKDF2-encoded mini private key?

EDIT:
Moreover, should the division by 4 should be carried out arithmetically (rounding the number to nearest integer, with 0.5 being rounded up), or by a logical shift (the number is rounded down).

As it is already being discussed on the forum, the standard is currently not in use by anyone, so its implementation details can change over time.


Importprivkey problem for Litecoin clone I have cloned an older version of Litecoin using a tutorial. I chose the starting letter for the public addresses to be lower case "x". Everything is working fine except for importprivkey. It will always gives error 5 wrong format. I tried using paper wallet generated keys (paper wallet generated private keys starting with addreses K,L and J) while the windows-qt wallet dumprivkey dumps private keys starting with nr 2 but that can not be imported as well. Is it because of letter x? FYI I have compiled a clone using letter "L" (same like Litecoin) and everything works so i doubt there is a coding error.

It seems like you are trying to import an address with importprivkey, which is absolutely incorrect. An address is not a private key and thus cannot be imported with importprivkey. Addresses have different data and will have different prefix letters than private keys. Looking at your code, the prefix for private keys will be 2 and those should be able to be imported into your wallet IF they did not already exist in the wallet (i.e. import to another wallet). This has nothing to do with your address prefix.


My bitcoint-qt client is crashing due to insufficient file descriptors repeatedly even after I set the ulimits to 65535 What are the exact resource requirements for a bitcoin-qt client.
this is important and hard to find information.
In virtualization world those things need to be understood. :)

I am running a KDE 18.04 Vbox on a mounted 1TB SSD share with 4GB Ram 4 cores.

Cheers :)

and the answer is....

if you use a shared folder on a VM the linux open file desc spec is irrelevant.
So I created a diskimage directly mounted in the host...
and voilà problem solved by avoiding the vbox host shared folder service indirection.
maybe playing with the vbox host config and system config would have helped as well.....


Creating an account system I am using the bitcoind account system for my web app, but it doesn't work the way I want it to work. So I want to make my own account system in Laravel(probably opensource).

The main reason for the account system is that I can't know the fee when I send a transaction. With my own account system I can check if the fee is correct and then send the transaction.

But how can I setup a safe account system?

I was thinking about a table with all the bitcoin accounts(I am not using the users table so I can create accounts for an order for example).

Then an address table with all the addresses linked to an account.

But how do I handle incomming transactions? And outgoing transactions?
If I for some reason change something outside my account system, it will probably will break pretty easy.

Do I have to import all the transactions to calculate the right account balances?

And I want to make the system in a way that I can make transactions between accounts, without making a "real" transaction, just like it works now.

I think it isn't that hard without the account-to-account transactions and moving bitcoin addresses to other accounts features, just import all the transactions in the database and calculate the balance for every address. And than sum the address balance for every account, but I need it.

Does this kind of system already exists.
If not can someone help me with thinking this out.

I have the account system working! Only I didn't really test it, so it isn't stable.
https://github.com/jwz104/bitcoin-accounts

It works with an user, address and transaction table.

There is running a cronjob that registers all received transactions. If the adddress is found in the address table, it will add the transaction with the user id of the address. If the address has no user_id the transaction will not be added because it is a return transaction(Change).

When a transaction is created the package will send the amount of bitcoins to the address, and the bitcoin that are left are send to a return address(Address without user_id) so the user won't pay to much.


Who made Gavin project leader? I mean no disrespect to Gavin Andresen whatsoever. I think someone needs to be at the head of the project and Satoshi has stepped down / disappeared / gone back to the NSA / returned to his home planet / choose your conspiracy theory.

But why Gavin? What's the succession plan? What if Gavin gets tired of the project and chooses not to work on it any more? There certainly are core contributors, but exactly how is the "organization" set up? I know there's no actual "organization", but what I mean is the people in charge of the direction of the Bitcoin project.

Satoshi essentially named Gavin project lead by putting his contact info on bitcoin.org, giving him a copy of the alert key, giving him control of the SourceForge project, etc. Not many people have a problem with this, since Gavin has done a great job. I don't think anyone else in the Bitcoin community could have done better.

Gavin doesn't have exclusive control over many assets, so development can continue without too much trouble if he disappears without "naming a successor". Releases can even now be created and published on bitcoin.org without Gavin. bitcoin.org and the Bitcoin Forum are owned by Sirius, not Gavin. I have a copy of the alert key.

If Gavin disappears, I'd expect the project to continue reasonably well without a clear leader for a while before someone steps up to Gavin's responsibilities and is recognized by the community.


How do I generate coins on testnet? CPU, GPU, FPGA? Are there pools? Is it possible to mine coins on testnet using CPU? GPU?  How about FPGAs?

Are there any pools running on testnet?

The reason I am looking for this is so I can master the new API's relating to AddMultiSigAddress

Testnet is designed to test Bitcoin software - including parts that have to do with finding blocks. As such, it should be easy for developers to generate testnet coins.

Because of this, it will be easy to solo mine on a CPU to generate them, and you should not use anything heavier than that because you would ruin it for everyone else.

It is also not designed to test pools, by the way. If you need a pool for whatever you're doing you can do that (but don't bring too much hashpower to it), but if it's the pool itself you're testing, do it on the main net.


In HD Wallet recovery how does the wallets know which addresses to recover I have been reading the BIP32 proposal explaining how HD works but it didn't mention on any point how one wallet in one phone can recover from a simple mnemonic seed.

Does it just try all possible addresses related to that seed's master key by doing the entire blockchain look up for addresses at the same time ? (This seems impractical imo).
Are there standards on the max nth of address to generate from the wallet side ?

Does it just try all possible addresses related to that seed's master key ? (This seems impractical imo).

No, this is actually impossible to do since there is effectively an infinite number of addresses that can be generated from a single master private key.

Instead wallets generate keys at standardized derivation paths and assume that other wallets follow the same standards. This is generally a safe assumption. Wallets that do not follow the standard derivation paths usually have documentation stating what derivation paths they use so that you can specify in another wallet what derivation paths to use.

Most wallets follow the BIP 44 specification for derivation paths.

  Are there standards on the max nth of address to generate from the wallet side ?

No. Typically wallets generate addresses until they have generated n unused addresses (known as the gap limit). The gap limit is not standardized and many wallets allow you to configure it. In many wallets, the gap limit is 20 keys, however this probably is not sufficient when restoring. In other wallets, it can be 100 keys, and others 1000.


Is a gold standard commodity-backed bitcoin possible? I like bitcoin in the sense that it decentralizes currency. I would like to know though if it is a commodity-backed currency similar to the gold standard decades ago? Is it possible in the near future? As it is it seems that it is the same fiat money, except that it isn't the Fed issuing it. Is that correct to say? Thank you!

A true "gold standard" means that a unit of currency (e.g., "dollar") has a certain amount of commodity backing it (gold, in the "gold standard" instance), and that the currency can be exchanged for that commodity at the designated exchange rate.

The amount of gold per dollar is fixed under a gold standard, so a dollar on one day gets the exact same amount of gold as does a dollar the next day.

The U.S. went off the gold standard (currency "backed" by gold) in 1933.  After WWII it allowed central banks to exchange dollars for gold at a set rate ($35 per ounce of gold) however that ended in 1971.

But iust like gold doesn't have any "backing", there is no backing for Bitcoin.

There could be a paper currency (or electronic transaction) that has bitcoins as the backing.  Essentially that is what every hosted (shared) EWallet provider offers -- an account through their service which presumably every BTC deposited is still available for withdrawal (e.g., they haven't spent it, invested it, loaned it out, or lost it).

Redeemable codes would be an example of an electronic currency that is has backing where each BTC issued is 100% backed (with a BTC held).  There's no way to audit that to guarantee that they have full backing though.

So just like gold doesn't have any "backing", it makes no sense to have backing for Bitcoin.  Bitcoins themselves have value, due to their scarcity and other reasons.

If you are looking for a guaranteed value in case the bitcoin exchange rate drops then there are PUT options that you can buy.  That's an investment product though and not a part of the currency itself.

[Update: If you want a gold-backed electronic currency, Peter Schiff's Euro Pacific Bank Ltd (not available to those in the U.S.) essentially offers that.]


How does Bitcoin Gold implement replay protection? The creators of Bitcoin Gold claim that they have implemented full replay protection. How does this replay protection work?

I don't believe any replay protection has yet been implemented, they still have an issue open for it on the BitcoinGold repository here:
https://github.com/BTCGPU/BTCGPU/issues/51

I haven't dug into the code itself but I would imagine that they would have closed the issue if they had implemented something.

The statement by Bittrex also claims that they haven't implemented any replay protection: https://support.bittrex.com/hc/en-us/articles/115002320451-Statement-on-Bitcoin-Gold-BTG-

Update as of 3rd November 17:
A PR for replay protection has been merged, https://github.com/BTCGPU/BTCGPU/pull/109

They announced it via twitter here: https://twitter.com/bitcoingold/status/925600171425259520

It uses a new SIGHASH_FORKID to implement the 2-way replay protection.


Why is my LND node closing channels? I have noticed when running lncli closedchannels, that I have some channels that are closed by my node (close_type: local_force_close).

I am quite sure I have not initiated this manually myself. Is there some logic in LND that drops some channels?

Many!

If you look at the BOLTs ( lightning RFC) you will find many situations in which nodes must fail a channel (meaning a force close) if something happens in an unexpected way while communicating with a channel partner. This could be even as easy as an unresponsive channel partner while settling an htlc in which case you have to settle the htlc onchain. But there are many more conditions in which the protocol asks to fail the channel.


Can a miner just download the blockchain once and then delete it (don't have a full node)? I am wondering if all bitcoin miners need to be full nodes. Or is it possible for a miner to just download all the blockchain once, do all necessary computations to start mining and then delete the complete blockchain and only work on the "last blocks". I.e can a miner don't be a full node?

This is not a duplicate question.

If miners delete the blocks data, someone can fool them by sending a transaction that spends money it shouldn't be able to. In principle, some of them could do that and trust the other miners to validate transactions, but the more people do that, the more the whole network is vulnerable to fraud.

The same can be said for non-miners. If you don't run a full node, you're not actually running Bitcoin, but trusting people that run it to verify transactions for you.


Best simple linux cmd tool for offline transaction creation and signing? I tried to use sx, but it no longer works since bip62 (malleability fix). Nodes don't accept generated transactions, saying "high S signature".

What offline command-line tool would be the best?

There are many command line tools for creating and signing raw transactions offline, most of them written in Python: pycoin, python-bitcoinlib, pybitcointools and others.

If you use Electrum wallet, it has command line tools for offline transaction creation and signing:

$ ./electrum help createrawtx
$ ./electrum help signtransaction


Bitcoin consensus and server of miners I know consensus is what 51% thinking.My questions is where miners communicated?On what server,what port??Where??The must push own api (copy of blocks) for thinking of consensus.So where BTC miners pushing api,for where blockchain explorer used it,where?

The Bitcoin Network is a P2P network made up of independently operating nodes from all over the world. Miners will connect to this network in order to maintain a view of the network's state, which is crucial to their participation as a miner.

By connecting to the network, a node (and/or miner) will receive and relay information from its peers, about new transactions and blocks. Nodes communicate using TCP, and the standard port is 8333. For a deeper dive into the specifics of the gossip protocol, see this question.


I tried to use bitcoin to buy ethereum and failed, what will happen now? I tried to use some at the shifty exchange in the ethereum app, just for research. I sent money to the provided payment adress, but I think I included a to small fee.

My payment is now uncofirmed and in shifty the deal is expired, What will happen now with the bitcoin etc?

The Bitcoin won't magically revert back to your wallet. Contact the exchange and let them know, and they'll handle it, either by processing the exchange or refunding you.


In which cases could I find funds locked in a failed route? I received an invoice from node Z and my node (A) suggests me 4 possible routes.

If the first two routes fail, are there cases in which funds can get stuck in one of these routes until the HTLC expires?

Which are these cases? Are they avoidable?

If I try the routes with a failed hash can I avoid to have my funds locked in a failed attempt (or is it better to test routes with a few millisatoshis)?

The funds in the respective HTLC's get stuck for a time-out period if the payment_pre-image doesn't propagate back along the route to your originating channel. There is no guarantee beforehand that this propagation will be successful. That is why HTLC(sent)'s are always signed together with a respective time-out transaction, with a signed input that spends this HTLC output in such a failure scenario.

Testing with smaller amounts as you propose ensure that only smaller amounts are captured in the HTLC outputs of the commitment transactions in your channel, so only a smaller amount would be "stuck" (this HTLC output is spendable later by the respective time-out transaction during a channel close). So until the time-out period is over, you have the remaining channel capacity to transact with.


Beginner's Explanation I'm interested in learning more about how bitcoin, mining, and blockchain technology work. I'm a student and don't have a strong background in computing, and I'm looking for a layman's explanation of a few basic, yet critical questions surrounding the currency and the technology behind it. I plan on sharing the results with other interested students who want to understand more about this important concept.

Miners receive 25 Bitcoins every time they create a hash (is this accurate?)- where do the coins they receive come from - are they fabricated or do they already exist somewhere? What I'm trying to understand is how the supply of currency changes - are there a fixed number of Bitcoins in existence, or is currency simply "created" whenever a miner updates the blockchain? As time goes on, will the money supply expand at some rate roughly equal to the growth in transactions - is this kind of like how the supply of fiat money in most economies has grown over time?
Is there a single blockchain for Bitcoin, which contains a record of all the transactions made since the first transaction? If so, does that mean that the chain will just keep getting longer and longer as more transactions are recorded? If Bitcoin increases in usage and popularity, won't the blockchain continue to grow (maybe exponentially) and will that add to the complexity of the miner's task?
This may be too complex to explain to an average person like me, but how do transactions actually get coded/added to the blockchain? I know that it requires brute force computing power and is based off of cryptography, but that's really the extent of my knowledge... If I wish to transfer 100 coins to my friend, that simple transaction must be captured somehow and translated into the chain - but how is this translation performed? Is there a constantly-changing key that has to be iteratively solved for by the miners? If a person were to "look" at the blockchain (I assume this is possible) - what would it look like, just a seemingly random collection of characters?

I'll stop there, as I'm sure there aren't simple answers to these questions and I'm sure I've misused/misinterpreted terminology and how these things actually work. Many thanks to all who read my question, and special thanks to anyone who is willing to answer one or more of my questions. If there is a better forum for me to post beginner's questions like the ones above, I'd certainly like to know that as well.

I would recommend reading 'Mastering Bitcoin: Unlocking Digital Cryptocurrencies', by Andreas M. Antonopoulos.  This book answers all of the questions that you posed, and more, in a very understandable way.


Will more hashes per second increase bitcoins per hash per second? I read this article:

  We have paid 0.034 BTC for the 10 GH/s ... Yesterday we have received our first daily payout and it was exactly 0.00041279 BTC ...   Doing a quick calculation has shown that if the Bitcoin network difficulty remains the same and the daily payout is also the same as the one we got the first day we are going to need a little over 82 days to get back what we have spent for the mining contract.

In this case BTC per GH/s is 0.00041279/10 BTC/(GH/s). All of this is in one day, but for simplicity I removed day from the units.

Will buying more GH/s increase BTC per GH/s (in one day)? Since there is more power solving the problem, and there would be more probability to solve the problems?

How could I calculate decrease of BTC/day vs time with a fixed hashing speed?

The short answer is: No. The average number of bitcoins per hash is fixed, and is roughly equal to B / (2^32 * D), where B is the bitcoins per block and D is the difficulty. Every calculated hash is either a block or not; if it's not, it doesn't bring you any closer to finding a block.

However, for completeness it should be noted that there are several sophisticated attacks that allow superlinear gains on hashrate, such as lie-in-wait and hashrate amplification (also known as selfish mining). Superlinearity can also be a side effect of a short block interval. All of these require huge hashrate to be effective, on the order of a quarter of the network hashrate - not something which should be of concern to the average miner.


What is the quickest way to bring a bitcoind node up handling 99% of edge cases? Currently when syncing a bitcoind node from scratch the time of going from zero (0) to about 50% is a very fast process but somewhere between 50%-75% it slows down considerably and at 75%-85% it grinds to an almost halt.

Assuming that the blocks that are being verified during that time are what is causing the slowdown I'm wondering if there is a way to basically clone a node by still running and validating a full node but at least trusting the blocks up until some number that is far enough in the past to handle 99% of edge cases.

I know that cloning the disk is possible but transferring that to a new VPS for instance is not so looking for ways to speed up the process for everyone without sacrificing security.

Known Optimizations

Setting the dbcache to a higher value (currently using 2000 on a 4gb RAM machine which is 25% of the available RAM)

The problem is less so with validating the blocks and more to do with bandwidth constraints and the time it takes to write blocks to disk and update the databases.

As you sync more of the blockchain, the blocks become bigger and contain more transaction inputs and outputs. The outputs need to be added to the chainstate database and the inputs removed. This takes time especially as the database grows and the number of inputs and outputs per block increases. Even if you were to disable all block validation completely (which is not possible), it would still take a long time to build this database.

The best that you can get is to use the assumevalid=<hash> startup option. This can be added to your bitcoin.conf file or used in your startup command. What assumevalid does is it skips script verification for blocks that are ancestors of the block with the hash <hash>. Bitcoin Core already comes with a default value for this that was set before the last major release was made. You can set this value to a more recent block and get some performance improvements for blocks that have been mined since the last major release.


How do bitcoin exchanges work? I'm relatively new to the world of Bitcoins and understand the basic principles of wallets and addresses etc, but was wondering how exchanges (like Coinbase) work exactly.

Is the entire exchange basically one large wallet with each user having their own address? That would mean that an exchange would hold a wallet containing all their users Bitcoins, no?

When you buy Bitcoins from an exchange using a bank transfer or credit card, where are the Bitcoins you're buying sourced from? It was my understanding that you have to buy Bitcoins from an individual who's actively selling their Bitcoins. Do they just buy a massive amount of coins all at once and slowly sell them off?

First of all, Coinbase is a little different from the main concept of an "exchange".

Real exchanges, like MtGox or Bitstamp, are really just a medium between traders. People can set limit orders to buy / sell bitcoins for a certain price. The exchange will match buyers and sellers when conditions of both the buyer and the seller are met.

More concrete, there are two types of orders: limit orders and market orders. Limit orders allow a trader to buy bitcoins at a price lower than the current price or sell bitcoins higher than the current price. However, these orders will only be executed once another user accepts them. Market orders will just find the best matching limit order.

So, let's say the last trading price is 100 EUR/BTC. Two people want to sell bitcoins but not for 100 EUR. One sets a limit order for 105 and the other for 110. So the best price to buy bitcoins for is then 105. When a person places a buying market order, it will look for the best price and it will buy from the one trader for 105 EUR. If the buyer wants to buy more than just one bitcoin, he will continually take the lowest price available. Doing this, the "price" of bitcoin will increase as the lower-price sell orders are no longer available.

Coinbase is different because it, as far as I know, does not allow for limit orders. I'm not sure how they implement trading, but it's possible that they charge a little higher price and take the risk for themselves or they may just make your order at another real exchange they partner with. But in any case, if no limit orders are supported, it is not a real person-to-person exchange like most others are.


How does the Bitcoin Network verify whether the wallet has enough bitcoins for the transaction? How does the Bitcoin Network verify whether the wallet has enough bitcoins for the transaction?

I understand that it is verifiable by scanning the entire blockchain and see whether the wallet has the enough bitcoin in it so that it is possible to make the transaction.

However isn't it feasible if the size of the blockchain becomes really large? Is there any practical way that the current nodes verify whether the transaction is valid?

How does the Bitcoin Network verify whether the wallet has enough bitcoins for the transaction?

It doesn't. The network doesn't care about wallets or accounts at all. Those are constructs used by other programs to manage bitcoins.

The network just checks to make sure that the inputs a transaction uses are valid.

  However isn't it feasible if the size of the blockchain becomes really large? Is there any practical way that the current nodes verify whether the transaction is valid?

Nodes keep an efficient index of unspent outputs. They can then check the inputs of a new transaction to make sure they're in the index of unspent outputs. You have to scan the whole blockchain to build this index, but once it's built, accessing and maintaining it is cheap and efficient.

You can think of an account as a key and unspent outputs as locks. The nodes just have to check that the key fits the lock. It doesn't matter what other locks the key might or might not open. The person who holds a key wants to know what locks it will open, but to know if access is allowed, we just have to check if the key fits the lock it's being put in.


Bitcoin new receive addresses With the Bitcoin-ABC cli I can generate as many receive addresses by the following command

./bitcoin-cli getnewaddress "label"

But from my understanding the funds still go into the same wallet and if I send coins from the wallet it would always be from the same "from" address. Am I correct in my understanding?

Funds still go into the same wallet and
  if I send coins from the wallet it would always be from the same
  "from" address. Am I correct?

Not exactly. It depends on the amount of coins you'll send. Here is an example:

You have address A with 1 BTC.
Address B with 0.3 BTC.

Consider you want to send 1.1 BTC to the address C.

In that case the transaction would have 2(A,B) outputs and 2(C, X) inputs *:

Outputs: A with 1 btc and B with 0.3 BTC.
Inputs: 1 BTC to the address C and 0.1 BTC to the address C.
0.2 BTC will be your change, and it'll be sended back to you*.

The from address will be the collection of your income addresses(A,B, e.t.c.).

*Some wallets do let you manually select which address should receive the change from a transaction.

*In some cases client will create a new address for change.


Withdraw from a BTC wallet Ucoincash 24hours is still pending? I wanted to withdraw 0.62 Bitcoin back to my wallet and I did try to verify the receive wallet address as I submitted the request and it is still pending 24 hours later? On the blockchain, I see no transaction or received BTC? This request was sent Saturday Evening November 18th, 2017 at approximately 11 pm and it is 11 pm Sunday, November 19, 2017

Do you have a copy of transaction (tx) ID or the address of the wallet that you sent it to? If so, go to https://blockchain.info/ and copy/paste one of those pieces of information into the search box in the top right-hand corner of the blockchain.info webpage and hit 'ENTER'. If the transaction went through okay it will show up on the blockchain.

Over the past few weeks there has been in increase in bitcoin transactions and the transfer times have slowed down. I also had a transfer that took over 24 hours. It isn't common, but does occur during peak times.

The bottom line is that as long as you got the right wallet address for the transfer the bitcoin will be on the blockchain (i.e. you won't have lost it).


the maximum possible entries a network can accept in RAFT consensus? Suppose a network of 5 nodes uses RAFT consensus protocol. Each nodes maintains a transactions log which consist of list of log entries. Each log entry again consist of index, term and command. The current log structure which consist of transaction log of all nodes present in the network is as follows -

Then the maximum possible committed entries (i.e. the network can accept entries upto that command) are ?

In RAFT
First thing is leader must be elected.
To update a data in log, leader must get majority of voting.

In this case after first 2 rounds leader changes.
in 3rd and 4th round new leader updates data.
But in final round leader doesn't get opportunity to update the "e7" as the leader doesn't get majority.


Do I spare 80Gb to only keep the blockchain and do I need it to be always present? I am new to Bitcoin, reading a book and just downloaded a client. On site I read the note that I would need about 65-80gb to keep the whole history of transactions.

What happens when it downloads the whole data set? Do I have to keep it on my hard drive all the time I use Bitcoin? Or can I remove it once it syncs or whatever?

The other question is, does it seem realistic to use Bitcoin on mobile devices as the space needed for the blockchain is so huge for mobiles? What are the alternatives to having this data in the internal storage?

There are different ways of interacting with Bitcoin. If you just want to make an occasional payment, and don't want to handle large sums, you'll probably be happy to run a Thin Client on your smartphone. They rely on full nodes to provide data, but when you wait for a few confirmations are sufficiently secure. To learn more about different types of wallets, you may want to have a look at Choose your Wallet.

If you want to support the network or want to make extensive use of Bitcoin for business, you may be interested in running a full node. If you want to have and be able to serve a complete copy of the blockchain, you'll need to keep all of it, but if you're only interested in working off a fully validated representation of the network's state, you can instead opt to run in pruning mode. Nodes in pruning mode are as secure as other full nodes, but cannot serve all historical data.


Is there an easy way to check out the market cap of the alternative cryptocurrencies? Ideally, I'd like to see a pie chart with the whole pie being "Bitcoin-derived cryptocurrencies", and each major alternative represented as a market cap in Bitcoins and USD.
Currently, from what I gather we have:

Bitcoin - 7,415,750 BTC = $34,854,025 = 99.7%
Namecoin - 959,150 NMC = 25,897 BTC = $121,716 = 0.3%

I don't know where to get data on other cryptocurrencies right now, and if they even have any significant market cap.

Introducing ... Bitcoin Pie.

Supported Coins are Bitcoin, Tenebrix, NameCoin and SolidCoin. If your favorite coin is not supported, point me towards an active exchange (with or without an API), and a block explorer, and I'll integrate it.


Is UTXO synonymous with leftover money in an address? Is UTXO synonymous with leftover money in an address and the only reason UTXO is even a concept is due to security concerns of not changing an address after every transaction? Hence, your "unspent outputs" must be moved to x address.

Or am I missing something completely?

I read that you might have $10 balance in an address but your UTXOs might be $2 and $8 in the same address. How does this affect execution of a transaction on the blockchain?

Can somebody please shed some light on the difference between UTXOs and current address balance?

Thank-you!

Is UTXO synonymous with leftover money in an address and the only reason UTXO is even a concept is due to security concerns of not changing an address after every transaction? Hence, your "unspent outputs" must be moved to x address.

Not really. A UTXO is more like a particular bill or coin in that it's a specific "chunk" of value.

The reason UTXO is a concept is because bitcoin is designed as a set of UTXOs rather than as a balance. It's the same way cash is designed as a set of bills and coins rather than a balance. When you say, "I have $100.43 in cash", you mean that you have some set of bills and coins whose value totals to that amount. This is analogous to a set of UTXOs in bitcoin.

  Or am I missing something completely?

I think what you're missing is that bitcoin was not designed to have accounts with balances as the primary implementation but to instead have a set of unspent outputs.

  I read that you might have $10 balance in an address but your UTXOs might be $2 and $8 in the same address. How does this affect execution of a transaction on the blockchain?

The blockchain doesn't care about addresses. If you have two UTXOs that you have the correct key(s) to claim, you can form a transaction that claims those two UTXOs and creates some new UTXOs as its output.

  Can somebody please shed some light on the difference between UTXOs and current address balance?

A "current address balance" is the total value of all the UTXOs a particular key can claim.


createmultisig single point of failure I'm implementing multisig addresses which is a great solution to a problem, but as far as I can see there's no way to create the multisig address without knowing all the private keys at the start. Isn't that a single point of failure? Whatever system creates the multisig address knows all the private keys.

I was expecting to be able to create a partial multisig address (me) pass the hex result to someone else to add their private key and then off to the escrow to add their private key... kinda like signing of multisig transactions.

You can see in Gavin's example he has all 3 keys at the begining: https://gist.github.com/gavinandresen/3966071

Thanks.

You're correct that Gavin has all three private keys available to him at the start, but you're missing that he only uses the public keys to create the P2SH multisig address.  Specifically, this line from the example is listing only public keys,

./bitcoind createmultisig 2 '["0491bba2510912a5bd37da1fb5b1673010e43d2c6d812c514e91bfa9f2eb129e1c183329db55bd868e209aac2fbc02cb33d98fe74bf23f0c235d6126b1d8334f86","04865c40293a680cb9c020e7b1e106d8c1916d3cef99aa431a56d253e69256dac09ef122b1a986818a7cb624532f062c1d1f8722084861c5c3291ccffef4ec6874","048d2455d2403e08708fc1f556002f1b6cd83f992d085097f9974ab08a28838f07896fbab08f39495e15fa6fad6edbfb1e754e35fa1c7844c41f322a1863d46213"]'

The createmultisig RPC will let you mix addresses (corresponding to private keys you have in local storage) and public keys (for cases where you don't have the private keys---like when creating a multisig address with your friends).

There's a step-by-step create-and-spend multisig example on the Bitcoin.org Developer Examples page  (you probably want to start by reading the immediately previous examples, as they build up to P2SH multisig).


What happens if a miner receives a block but not its previous? Suppose the following:

A miner has stored the current blockchain A-B-C.
It stops listening for blocks during some time.
During that time, blocks D and E are mined and broadcasted.
The miner reconnects and immediately listens to the block E, before even knowing about D.

Will the miner simply ignore that block? And, how will the miner update to A-B-C-D-E (step by step)?

Will the miner simply ignore that block?

Yes, the block will be just ignored by the miner.

  how will the miner update to A-B-C-D-E (step by step)?

When the miner's node gets online and start connecting to peers, it will start a “handshake” by transmitting a version message, which contains all basic identifying information, including BestHeight (the blockchain height of the node). Since v0.10, the nodes sync with 'headers-first'. This means that the nodes when restarted first ask peers for block headers and validate those. The getheaders message requests a headers message that provides block headers starting from a particular point in the blockchain. The connected peers will respond with a headers message that sends block headers to the node which requested certain headers with a getheaders message. The disconnected miner's node will then verify the difficulty until the tip. This allows a peer which has been disconnected to get the headers it hasn’t seen yet.

In a second stage, when the headers have been discovered, the node can then download the blocks. However, as the node already know about the whole chain in advance due to the block headers it has received, the blocks can be downloaded in parallel from all available peers. These blocks are received through getdata requests.

The above process describes the syncing of node when it was disconnected for some time. To make the answer more complete, I'll expand a bit further as to how new transactions and blocks are broadcasted. Nodes unsolicitedly transmits inv message (inventory message) containing one or more inventories of objects known to the transmitting peer. It can be sent to announce new transactions or blocks. The receiving peer can then compare the inventories from an inv message against the inventories it has already seen, and then use a follow-up getdata message to request unseen objects.


Is it possible to retrieve bitcoins from a Bitcoin address and possibly a private key? While mucking about with Bitcoin a couple years ago, I setup a Bitcoin address and added a couple bitcoins.

I have the Bitcoin address and possibly a private key, but I cant remember how or where I set it up.
Using blockchain I can see the wallet and its contents.

Is it possible to access the wallet and retrieve the coins?

If you have a private key, you just need to import it into your client. After that you'll get access to your coins from the old wallet.


Can the Antminer S3 mine Bitcoin using Scrypt algorithm? Because I can use my PC to mine Bitcoin using the Scrypt algorithm. I use NiceHash. They have an option to select which algorithm we want to use. So I was wondering, once I get my Antminer S3, is it possible to point it to NiceHash's Scrypt stratum and mine using the Scrypt algorithm?

No. Bitcoin does not use Scrypt, so you cannot use something that mines Scrypt to mine Bitcoin. Furthermore, the Antminer S3 is a Bitcoin miner, it can only mine SHA256d coins, such as Bitcoin. So it cannot even use the Scrypt algorithm or mine any coins that use Scrypt.


How does Ripple synchronizes its ledger? Bitcoin decides on a global clock by the blockchain - every mined block is another tick of that clock.

In Ripple, there is a global ledger that keeps advancing in time - the ledger number keeps increasing all the time, and the ledger represents the state of the system at time t.

What synchronizes this ledger? How do different Ripple nodes know when they should advanced their ledger counter?

There are two separate issues. One is initial synchronization assuming you don't know anything. The other is how servers advance the ledger in synch.

For initial synch, you monitor the network and watch for signed validations from validators you trust. You check the timestamp on them and if they are current, you can then begin tracking the ledger chain. Once you know what they are claiming the current ledger is, you can fetch any data you're missing, walk the hash chains and transactions, and convince yourself that the ledger they are claiming is valid is in fact justified by the transactions attached to it and that it hooks up to your last ledger, if you have one.

Once you are in synch, you can participate in the consensus process. You will see live transactions relayed, you will see proposed transaction sets, you can send your own proposals. When you see a consensus on a transaction set, you apply it to the last ledger, and you then have the next ledger. You can then sign it and send a validation.

The actual timing of the ledger close is a bit complicated. If there are no transactions, a ledger will typically close every 20 seconds. If there are any unconfirmed transactions, the ledger will close two seconds after it opened and the network will try to form a consensus on them. This two seconds gives nodes a chance to finish processing the previous ledger before they need to start processing the new one.

The actual synchronization occurs using a sophisticated delta algorithm. The ledger is a tree so if a branch hasn't changed, you will discover that without having to traverse that branch. Ledger nodes that you need can be fetched from the network and servers will also predictively return nodes they think you will need based on the nodes you said you did need.

For initial fetching of large amounts of history, the server can request a "fetch pack" from any server that has the history. This contains those ledger nodes the server knows are unique to that particular ledger and help to reduce the number of queries needed.

All validated transactions, all ledgers, and all states the network has ever had form a giant hash tree. Once you know the hash of the current ledger, you can walk the hash tree to find any of those things securely and provably. Validations are not in this hash chain though. They are stored separately and individually signed.


Are bitcoin transaction confirmation times limited by block size? The following commentator writes:

  When transactions are announced to the Bitcoin networks, they appear as part of a ‘block’. Bitcoin blocks are produced on average every 10 minutes. Bitcoin blocks have a maximum size, so if there is no room then your transaction will be delayed. If you are desperate to have your transaction included in a Bitcoin block promptly, you will have to increase the transaction fees that you pay to the Bitcoin network.

Now it seems if you had a flexible block size - this transaction confirmation time issue would be addressed.

My question is: Are bitcoin transaction confirmation times limited by block size?

https://en.bitcoin.it/wiki/Block_size_limit_controversy

Here it states that larger block size would allow more transactions per second.

If blocks have around constant mining rate (1 per 10 minutes) and fixed "amount" of transactions can fit in one block the statement logically follows. How are the size of one transaction and block size defined is a separate question.

The link also gives some context about the size limit.


How many characters you need to mistype at minimum to get another valid address? Is it known the minimum amount of characters you need to mistype to get another valid address?

Addresses contain checksums, and also must follow some specific rules, so I guess this could be calculated: I wonder if someone did.

Check sum is a result of 2 hash-functions: SHA256 and RIPEMD160. The length of checksum is 4 bytes. Hash functions are indistinguishable from random oracle, so it is possible, if you make 1 mistake in non-checksum character, you get the same checksum. But probability of this is 1/2^32.

Added later: not exactly correct due to base58 encoding. Correction in the another answer.


How to Reset Dragon Miner 1TH/s IP Address? How can I reset the IP address of a Dragon Miner 1TH/s machine?

Mistakenly, I entered the wrong IP in the miner when changing the network IP address, and now my miner is not visible on the network. What I entered was like "IP 192.168.1.100.4".

So how can I reset my miner?  It has the SD card option.

This happened to me.

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

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

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


Does my wallet need to be unlocked to mine? Currently I am mining at around 775Mh/s and have been for only 12 hours.  I want to make sure everything is setup properly.

I have encrypted my wallet and Bitcoin is reporting that the wallet is encrypted and locked.  Does the wallet need to be unlocked in order for the mining process to yield its results?

This question was helpful.

No, it doesn't have to be. Mining doesn't require private keys, only (part of) the public one. Having only the address of the destination is enough, so the wallet can be locked.


How can I make GUIMiner use the CPU for mining? I am trying to setup GUIMiner together with mining.bitcoin.cz. As I am working on a laptop with an Intel graphic card I am (probably?) unable to use GPU mining. So, just for a test, I tried to run GUIMiner without GPU support, that is as a CPU miner (if this is the correct word).

Clicking the start mining button doesn't seem to make anything run. I might be mistaken, but the lower right corner of the application keeps saying stopped.

The console tab says:

  2013-04-03 17:51:51: Running command: poclbm.exe :@api2.bitcoin.cz:8332 --device=0 --platform=0 --verbose -r1`

But no error message, either.

So, I go to cmd.exe and copy poclbm.exe ***:***@api2.bitcoin.cz:8332 --device=0 --platform=0 --verbose -r1. This results in

No PyOpenCL
Not using OpenCL
Nothing to mine on, exiting

which can be taken as an error message. I believe that "OpenCL" indicates that the program wants to use a GPU (although) I am not sure. I just want to test the mining functionality and see if I can particiapte in the mining pool, at the moment without graphic card, only the CPU. Is this somehow possible?

If you start the bitcoin-qt client from the command line with the bitcoin-qt.exe -gen 1 command, then it will generate bitcoins using your CPU. Alternately, use cpuminer. (Builds)


How to prove bitcoin ownership without revealing amount? Is it possible to use some cryptographic scheme to prove bitcoin ownership without revealing any information about value held in addresses?

Dagher et al. Provisions privacy-preserving proofs of solvency may be what you are looking for:

  The objective of Provisions is to enable an exchange E to publicly
  prove that it owns enough bitcoin to cover all its customers’ balances
  such that (1) all customer accounts remain fully confidential, (2) no
  account contains a negative balance, (3) the exchange does not
  reveal its total liabilities or total assets, and (4) the exchange
  does not reveal its Bitcoin addresses.

Full version of the paper available in J. Bonneau's web page.


How automatically to forward bitcoins from one address to another? I have a bitcoin wallet address (the private key is known by other people). I periodically receive payment on this address (and cannot change it/receive to other address).

I need:
When I receive a payment on it, automatically and immediately (at 0 confirmations, like in BlockChain.info wallet) send/forward them to my new wallet address (the private key is known only by me).

Is this possible and how?

You may use /etc/crontab on your Ubuntu:

* * * * * root /bin/bash /usr/local/bin/bitcoin_resender

And script shall looks like:

$ cat /usr/local/bin/bitcoin_resender
#!/bin/bash
if [ $(echo "$(bitcoind getbalance) > 0" | bc) -eq 1 ];then
      bitcoind sendtoaddress YOUR_NEW_ADDRESS $(bitcoind getbalance) "Comment for resender"
fi

It will check every minutes your bitcoind balance and resend each bitcoins to YOUR_NEW_ADDRESS.

Your probably need to check the fee.


Simultaneously Solo and Pool Mining It's possible to send shares both to a localhost GBT "pool" (e.g., Bitcoin Core's) and to a remote Stratum pool.* Now, if I discover a block, won't both my localhost GBT "pool" and the remote pool claim it as theirs? This appears to be known as the "selfish mining attack."

*using, e.g., bfgminer's #allblocks option, which offers "Support for submitting found blocks to a local Bitcoin GBT server (bitcoind or Bitcoin-Qt with -server flag): just append #allblocks to the end of your bitcoind's URI." (source)

Now, if I discover a block, won't both my localhost GBT "pool" and the remote pool claim it as theirs?

No. That isn't possible. Changing the coinbase transaction (what controls where a block reward goes) invalidates the block. All that happens is that the block propagates slightly faster.

Cheating on pooled mining

  This appears to be known as the "selfish mining attack."

Actually, that's something else.

Luca Matteis explains:

  You're missing the main point: when a selfish miner finds a new block,
  he keeps it private, does not broadcast it to the network, and starts
  mining on top of that privately.

  The rest of the network is still mining on a block that was actually
  already found, but not broadcast.

  When the rest of the network finally finds this block, the selfish
  miner broadcasts his version, in an attempt to replace it.

  By invalidating blocks this way a selfish miner is effectively wasting
  other people's cycles, and has a head start for winning the next
  block, because he started mining on it before the others.